- Time and material vs fixed price: Details on differences
- Why can fixed price projects fail?
- Why do time & materials projects fail?
- Time and materials vs fixed price contracts – What to keep in mind
- How does Archer Software approach fixed price projects?
In the IT industry, there are two basic pricing formulas when it comes to software development: fixed price (FP) and time and materials (T&M). We’ve been working in software development for over 20 years and our portfolio includes numerous projects of various sizes for a variety of business models using many applications and technologies. We’ve gained lots of experience working with both fixed price and time and materials contracts so we crafted this guide for our readers who want to figure out which is the right pricing model for their project.
Previously on our blog, we published an article covering the difference between time and materials vs fixed price, as well as the pros and cons of these two approaches. Below we’ll go into detail about the reasons why projects can fail using either approach and give you some tips on which model might fit your project best.
Time and material vs fixed price: Details on differences
The fixed price model in contract management includes a:
- Fixed budget
- Fixed scope, features, definitions, and usually timeframe
- Fixed payment schedule
The time and materials model in project management includes:
- A budget estimate in terms of project magnitude, but not a fixed cost
- Scope, features, and timeframe are flexible and adjustable
- Payments are generally made on a monthly basis as you use resources
The key difference between T&M and FP lies in the extent to which you can control your budget and change or add functionality to your project. With the fixed price model, you have a rigid budget and delivery timeframe which can be a constraint if you need more flexibility to deliver the best value when the requirements change.
With a time and materials pricing template you have less clarity on the final price, but your software development partner is more committed to the delivery and quality of the functionality needed. A change of requirements is less painful for both you and your partner with this type of contract.
Technology blogs talk about success stories and provide tips on how to avoid failure. Here we’ll try to approach the problem from another angle and start with why projects using both types of contracts can fail.
Why can fixed price projects fail?
The lion’s share of FP projects fails because changes are made at the development stage. Why do those changes come so late in the process? These are some common reasons:
- Initial requirements were not clear or defined because an in-depth analysis of everything that was needed was not made during the project definition and planning stages.
- The technical team underestimated the complexity of the tasks involved.
- There is no flexibility to make changes. Modifications are possible at the prototype stage if the product does not suit the client’s expectations or the prototype inspires ideas that require changes.
Even if the customer is convinced that changes won’t be needed and everything will proceed according to the plan, in our experience 90% of projects require changes in the development process and that becomes a big problem when there are many adjustments. If the change represents 10-20% of the project development, the development company can add[t those changes without increasing the price tag. But if the number of changes goes up and keeps growing, there’s a great risk of the customer losing money on the development project and getting no viable product.
In other words, the failure of the project can lead to loss of money. The fixed-price contract model doesn’t guarantee a result so the customer bears all the risk.
Fixed price project failure example: You’ve got an idea for a product and a budget. However, at this stage, nobody can estimate with confidence how long it will take to complete this project and whether the idea can be developed. You sign a FP contract and mid-project you realize that the idea cannot be implemented. In this example, you are at risk of wasting your budget and not getting a working prototype.
What can you do in this scenario?
To avoid going over budget when the finished product is far out of reach, you have to divide the project into small parts, each of which produces a result getting you closer to your ultimate objective while having a fixed price safety.
To do this, you divide your project in accordance with the stages of the project life cycle. The result of the first stage will be the precise definition of requirements. This means you get a realistic estimation of how your idea will work for a small amount of money. What would be the point? You decrease your risk of not realizing the idea at all and save the rest of your budget if you find out that there are no technical capabilities to bring your project to life because you find that your budget is not big enough to accomplish the goal. If the estimate works for you, you can proceed to the second fixed stage.
The second stage deals with a detailed solution design (it can refer to interface design or the project architecture, for example). Oftentimes the same functionality is seen differently by the customer and the developer. Moreover, the two can have different views on the appearance of the interface. At the design development stage, you gain insight into whether the interface you want fits your budget.
You can save your funds in this case because you’ve spent only a small part of it to get two completed tasks for your product. That way you can make a more deliberate decision on whether you should proceed with development or not. The second stage can also involve the proof of concept (POC) step. Here you check the technological feasibility of your product modules. Proof of concept is applied for complex and original products that need a more thorough and exact estimation.
The third stage involves the software development cost estimate. Based on the previous two stages, we can give you a final price. At this stage, we can remove some features from the project to fit in the budget as we know how long it will take to develop each of them. This again allows you to avoid wasting the budget without getting a result.
What doesn’t work with the FP model?
The very idea of the fixed price model implies that the customer is paying once for the whole project and they get the final solution as a result. However, it doesn’t work this way in the software development domain. To ensure you get a ready solution you have to divide the process into small iterations, which will have a fixed price and result.
Why do time & materials projects fail?
One of the biggest disadvantages of the time and materials pricing model is the necessity to motivate the developer’s team to do their best work. You have to keep an eye on the team constantly to make sure that they are working toward delivering the approved scope within the agreed amount of hours. This risk is on the customer solely. However, you can minimize it by hiring a project manager.
Another reason for project failure is low budgeting control. The overall cost can go far beyond the expected budget and make your project unviable.
The core difference between a time and materials contract vs a fixed price one is who bears the risks. With the FP model, all risks are carried by the customer, and with the ТМ model, it is the provider who has risk exposure.
This model has a distinct advantage. if you realize the current team or developer is not up to the task, you can always replace them in the process of product development. Moreover, you can stop the development process at any time without spending all of your budget.
This model is the developer’s favorite as it increases the provider’s involvement in the development process dramatically.
Time and materials vs fixed price contracts – What to keep in mind
When is a fixed price contract viable, and when should a time and materials contract be used instead?
There is no absolute answer, but there are some markers that can help you make the right decision. For instance, the larger the scale of the project, the better the chance that the time and materials pricing model is the best move. The fixed price model is more suitable for small projects with a development time of up t three months. Keep in mind that a considerable part of the FP budget is spent on management.
Another difference between time and materials vs fixed price models is in the degree of customer involvement in the development process. With the FP model, the customer assumes everything will be done without them taking part, and with the Т&М model, the customer is more involved in the process as the customer can have input on the process.
How does Archer Software approach fixed price projects?
There are some cases where a Fixed Price model is preferable. FP can be used in fields where formality is needed like healthcare, military, or the law. It can work for very well-defined systems, with external limitations on possible changes such as low-level hardware or security applications.
Dmytro Gryniuk, Delivery Director at Archer Software, gives some advice on project development with the fixed price model
When working on a project which is estimated to take 6-10 months, you’ll encounter additional requirements that are capable of changing the initial price estimates dramatically. To minimize this risk for both the customer and the provider, we at Archer strongly recommend developing the project on a step-by-step basis. At that, the maximum, a particular stage should take should not exceed three months using the iterative Agile approach to development. The key goals of such an approach are:
- To release the first version of the product, which is the minimum viable product (MVP), with working functionality in a short time as possible, and launch user testing of this version. This will reveal both defects and new functions that users need.
- Using the Agile approach with short (up to two weeks) iterations, to release updates including the most in-demand ones with user functionality. When working on the project using the fixed price model, it is necessary to divide the project into comparatively small steps with clear and concrete results for each step. On completion of several basic stages, you can proceed with cyclic (iterative) functionality development in accordance with priorities.
The phases of development for FP should include:
- The idea including architecture and the general design of the application. At the end of this stage, you should have a dummy application and a description of its architecture.
- Planning and estimation. Here initial re-estimation of the development cost of the application functionality is made in accordance with the design and functionality agreed upon at the previous stage. Also, here the initial functionality priorities are set. The result of this stage is the formulation of a minimum viable product.
- MVP development. At this stage, the detailed functional design of an MVP is created with subsequent development of the first app version to be released for user beta-testing. You also collect user feedback at this point. The result is the internal beta version of the product.
- Transition to application cyclic development. At this stage, you plan the completion of the project in which a new version of the application is released with new functionality and, possibly a new design based on priorities from users during beta testing. At this stage, you also plan and release a commercial version of your application.
Based on our experience, this approach allows the customer to obtain a workable version of the application as soon as possible while minimizing risks and costs. Taking user reviews into account will allow your application to fulfill user requirements.
Upon completion of stages 1-3, it is possible to replace the provider if you don’t like the work. Also, the provider can get insight into the infrastructure, which will result in more exact estimates of the development schedule and cost, as well as providing more clear accountability for such estimates. If the scope of work is big enough, you can involve two providers to create a competitive development environment and cross-check code, which will allow dramatic quality improvement of the developed functionality.
When choosing between T&M and FP models, it is essential to weigh all the strengths and weaknesses of each contract type and how they fit with your product development. We hope this article helped you decide which approach is best for you. If you have additional questions or need advice from our experts, just contact us at firstname.lastname@example.org to learn more.