Closed-scope
First of all, we need to revisit what a closed-scope project means, but before we begin, you must remember this: closed-scope is good when you are entirely sure about what you want. So, imagine you have to ask a team to build a simple machine, like a lighter. You will have to provide the blueprints and inform all the desired characteristics you want. Based on your request, the team will give you a price point and a target time for execution. The more precise your blueprints and description are, the more assertive the price and execution timing will be, which means building the lighter will be a closed-scope project.
Closed-scope projects are good when you know exactly what you want and how the user will utilize your product. The lighter was an excellent example because you know how users will use it, and your blueprints were close to perfection, right? Well, not so easy! Perfect understanding of what users want and having perfect blueprints is rare, like a unicorn. The pitfall here is to imagine what you know but must realize your users’ minds are going in another direction. Perfection can be achieved, but it usually costs more than the client wants to pay and consumes a high investment level before the project starts.
And guess what: your blueprint may have needed improvement after another engineering team evaluated and scrutinized it. Believe me, it happens all the time.
Open-scope
Open-scope projects shine for scenarios where mathematical perfection and certainty are partial or unavailable. Now let’s imagine you need to build the lighter again, but now you need deep collaboration with the building team to put in perspective all the pitfalls and intrinsic risks related to your project. The building team will scrutinize your blueprints in solid cooperation and support you in the challenging process of user understanding.
Here the price and execution time are related to the effort associated with the necessary tasks to bring your product to life. You will have a projection of time and money spending and control over what the building team will make and when the team makes it. You can make route corrections immediately; as soon as the problem happens and adjust the route according to your expectations and milestones. Opting for an open-scope project will give you more control and less contract litigation when mathematical precision and perfect understanding are unavailable.
On the other hand, closed-scope projects without perfection from the client put tons of pressure on the contract. And this is terrible for all the people involved because you and the building team will spend a massive amount of energy negotiating the contract to accommodate corrections and route changes when all of this power should be spent by both sides building the product—and this brings us to an enormous cat-and-mouse game with no winners.
Which one suits you better?
Now you understand why to decide between closed-scope and open-scope for your next project, but the simple four questions below will help you with your definition. If you answer NO to one or more questions, you can consider going with open-scope:
– Are you absolutely sure about every single aspect of your product?
– Do you have blueprints, low-fidelity sketches, or wireframes showing every single part of your product?
– Do you have a complete and understandable comprehension of your users’ journey using your product?
– Is this the second or higher version of your product?
Good! Now, is the time to express the pros and cons of each one to make your decision clearly:
Closed-scope pros
- Excellent when building an almost immutable product with complete blueprints and a full understanding of users’ journeys
- Suitable for new versions or features of products with almost immutable users’ journeys.
- Perfect for companies with senior (and expensive) product and engineering teams that provide excellent descriptions and almost zero-error blueprints.
- Since perfection and immutability are on your side, you can have an almost perfect contract with some light headaches.
Closed-scope cons
- Terrible for mutable products with incomplete blueprints and incomplete user journeys.
- Usually does not suit new products.
- It cannot be used without a high investment in mathematical perfection.
- Requires high experience in contract formulation, negotiation, and litigation avoidance.
Open-scope pros
- Excellent when building a mutable product with incomplete blueprints and partial understanding of users’ journeys.
- Suitable for new products or existing mutable products.
- Perfect for new or existing companies without high product or engineering teams investment.
- Low investment in contract formulation and litigation avoidance.
Open-scope cons
- Demands a high level of trust from both sides.
- Without full transparency and proximity, it tends to fail quickly.
- Consumes your time and attention during all project phases.
- Requires a high level of availability and fast interactions to succeed.
And last but not least, here is an essential piece of advice if you decide to go open-scope:
You and your service provider must be transparent during all project phases, and mutual trust is the key to success. If you have any doubt, verbalize it immediately, and remember: the sum of small doubts will only become a massive problem if you do not address it directly.
Now you are ready to take a crucial step for the success of your project, and I hope this article helps you. Remember to choose the right partner to bring your product to life; the best partners usually do not say what you precisely want to hear; they say what is necessary for your success, and sometimes this goes against common sense. Keep that in mind in your next negotiation.