Fixed Price (FP) contract in project management:
- Fixed Budget;
- Scope, features, definitions, and often timeframe are fixed too;
- Payments are usually made by the scheme:
The downside of the Fixed Price model is that it is very rigid when it comes to changes and involves a lot of bureaucracy to make significant amendments to software development, sometimes it even takes a whole contract to be re-concluded.
Use case: Fixed Price is the right pricing model if you're building a landing page or a fairly simple corporate website, where the functionality is clear, limited and delivery will be short-term. For the majority of the projects that last longer than one man/month, however, this approach will result either in a lack of the right features or problems with their integration. And here's why: a deeper vision of the necessary functionality for a product comes with the project's progress, and understanding of the target audience's needs and expectations comes with users' feedback. Therefore, the most valuable product features often start taking much better shape closer to the end of the MVP development stage rather than when the initial requirements are defined. And the FP model by definition is not meant to accept changes to the original scope.
Summary: With FP you get your software development partner committed to the budget constraints rather than being flexible to deliver the best value if the requirements change.
Time and Materials (T&M) contract in project management:
- Software development budget is estimated in terms of magnitude but not fixed to a specific amount;
- Scope, features, and delivery plans are flexible and open to on-the-go changes to a rather high (but justified) degree;
- Payments are usually made on a monthly basis for the resources used within the past month.
The downside of the Time & Materials model is that the final cost of the project is not defined and fixed but rather narrowed down to some decent range.
Use case: For large projects without a clear close date, and/or with substantial functionality to be developed, big development team engaged, and/or implying long-term ongoing development, support, and scaling of the product, the T&M model proves far more suitable than FP. T&M enables agility and the ability to pivot development if needed at any stage of the project. It might seem a bit contradictory, but T&M also gives better control over the budget as the client is billed on a monthly basis which leverages short-term ad hoc planning.
Summary: With the T&M model, you get your software development partner committing to the delivery and quality of the needed functionality with adjusting fast and within the budget constraints if the requirements change.
What if the vendor team is new and you are not sure about their quality, skills, and trustworthiness?
You want risks to be carried by the vendor, not by you. But the truth is, the Fixed Price approach does not solve this problem, at least it is not doing it any better than the T&M model.
From the first glance, it seems like you're only risking to waste your pre-payment (and time, of course) if the new vendor fails to deliver against the FP contract. But if you look closer this doesn't have any difference from the first 2-week sprint with the team running the project under the T&M contract. You can evaluate the results and make a decision to stop the work if you are not satisfied with the skills/quality/communication.
The mixed or Proof-Of-Concept approach has proved to be far more useful when it comes to checking the quality of a new vendor. In this case, you have your vendor deliver a simple and small prototype while researching for the biggest technical risks and proving the technical ability to build the project as planned. This allows you to verify the idea itself, the vendor team skills and approach, and see if the chemistry between your team and theirs is right and will set your product up for success.
What if you have a limited budget to develop the product and there's no way to increase it?
When dealing with an outsourcing partner offering a T&M model follow these process:
- Request a vendor to estimate the range of the resources needed to complete the scope.
- Freeze, let’s say, 20% off your limited budget for a while. Depending on your own understanding of the ultimate product functionality you can tweak the size of this buffer – the clearer the definition of the feature is, the smaller the buffer can be.
- If the budget leftover is within the estimation range, start the work and be with the team under T&M with every 1 or 2-week delivery.
- Start working with the core features first – the most important or the most representative for the app.
- Tweak the scope and change the features priority if needed, and if the Project Manager provides you a clear understanding of the impact these changes will have on your budget, product value, and timeframe.
- When getting closer to the end of the project budget, consider if the 20% buffer you froze is worth spending on completing the initial set of features or on new features from the backlog that you need now.
In fact, following this format, with T&M you will have a business-level control of your product (unlike with the FP process).
One of the challenges with FP is that the vendor here would be that, on their side, they will reasonably try to balance the risks that you are putting on their team and will have to add the resource buffers to cover the technical and management risks. That means that in an average situation with FP, not only will you pay more than you have to, but you will also have your requirements frozen.
Under the T&M pricing model, this delta if available can be spent to implement some extra nice-to-have features and tasty delights. In a worst-case scenario, when the outsourcing vendor starts to run out of time and budget, he will choose the only workaround available and not fixed in Fixed Price Contract – a decrease in quality. So in fact, while running the project under FP you control neither the features nor the quality of the product implemented.
No the other hand, there're a few cases when FP will be an appropriate model and will work for you:
- Medical, governmental, military and other projects where the quality bar is obliged to be so high or the business cost of change is so dramatic (e.g. additional licensing procedures are required) that all the requirements are strictly defined, clarified, documented, approved and officially frozen by business and development teams.
- Small prototype-alike, temporary solutions, or apps for internal usage where the quality bar is not important and product needs are not dependent on the market.
“Fixed price works well for small, well-defined projects. If you use it for anything else, you will pay a price in product and technology-implementation quality” - Andrey Akselrod, Co-Founder & CTO, Smartling.
Contact us at firstname.lastname@example.org to learn more.