Fixed Price vs Time & Material Contracts

While outsourced software development projects used to be executed under a fixed price agreement between the client and the software development company, mainly for waterfall projects, there is now another abundantly used agreement called Time and Material which suits the Agile nature of projects these days, and it's mostly adopted to ensure the best outcome is achieved for both the client and the service provider.

Desired outcome, what matters most in our view is that you, as the client, receive the best value for your investment in software, that brings added-value to your stakeholders within reasonable timeframes and budget appropriate for the level of service we provide. On our side, we would like to stay in business by earning a healthy and reasonable profit and create a positive experience for you, in a way that you would trust us next time with your software project again as well as referring us to your colleagues if they had similar needs.

What matters most in our view is that you, as the client, receive the best value for your investment in software, that brings added-value to your stakeholders within reasonable timeframes and budget appropriate for the level of service we provide.

We then need to find a commercial model that would support the above outcome, and like any other project, four elements of timeframe, budget, scope as well as the final quality of the product need to be taken into account, before any decision could be made around contact type.

In this post, we cover the above topic and go through the pros and cons of different contract models commonly used for software development projects, which are Fixed Price and Time & Material.

Fixed Price Contracts

A fixed-priced software contract is an agreement in which the client has a specific budget and a set deadline for a given scope of work which indicates precisely how the software works.

As you might have had experience in the past with building software, you know that almost in every software project, one of the below situations could happen,

• Customers start giving you feedback, and you start realising what they really want
• The business rules behind your software might change by your organisation or market during development
• You need to apply the changes introduced by a third-party dependency that your software depends on
• As the development progresses, you will have new ideas or suggestions which could be added to the feature set

However, these items go against the set-in-stone nature of fixed price agreements, as we have a set price, scope and the timeframe to deliver the project, and eventually, you might end up with a product that doesn't fully meet your user requirements, if any of those cases happens.

In this situation, there are two options available,

• Wait till the end, of the project and then apply the intended changes. This option might take some time, and it also could be somehow expensive, as some of the changes might require rework, and restructure in key software components, and hence impacting other features.
• Go through the change process, of the contract, and re-negotiate the scope, price and deadline to onboard the new changes. You can imagine if there are many of these changes, there will be a lot of time and effort spent on this process which will cost money and time, the time which could have been spent productively implementing those changes.

Although you might argue that the set price and timeline are quite critical to you and your company, and you are EXACTLY sure how the final user experience should look like, which in that case it makes sense to go with the fixed price agreement.

Slower process? Fixed Price agreements could be beneficial for waterfall projects, where each stage of development has to be finalised before the next stage begins. As every single detail needs to be fleshed out and be crystal clear for later stages, sufficient level of time and focus should go into the initial design phases upfront to document every single scenario. This by itself will delay the whole project as the team can't start the development until the design is ready. As you can see, the larger or more complex the project is, the later the whole development team will start the development.

Complex projects, in which the level of ambiguity in the project specs is high at the beginning, and the team is uncertain about scope and direction, are not good candidates for Fixed Price, as it is impossible to document and design what we don't know. Simply put, if you go ahead with a fixed-price contract with complex/ambiguous requirements, you might end up spending all your time negotiating changes with the other party. This is of course, in the unlikely scenario that you decide to continue and finish the project, with so much unknown and a restrictive contract involved.

Set and Forget, as your level of involvement during project execution will be minimal, and you won't need to be heavily involved as project specs have been defined clearly upfront. You would only be involved when milestones are reached, and there are deliverables, or if there is a key decision that needs to be made in regards to deliverables.

 

Communication gaps, as some details could be missed from the project specifications due to communication gap, or assumptions. The more critical the missed details get, the more expensive they would be to fix after the product is delivered.

Quality might be a concern in large and complex projects under fixed-price agreements, as it would be harder to estimate the real cost and the effort required to deliver the project, and considering all the unexpected complications that happen during the lifetime of a software development project, the developers will be under much pressure to meet the deadline, under a fixed budget and scope. This, a lot of times, will push the developers to compromise on the quality of the software and how it is built just to meet the deadlines.

More expensive at the end? Considering all the change process, the time spent to negotiate those changes, cost and risk of miscommunicated specifications, higher cost of applying your customer feedback after the project is delivered, and the risk of building a software that doesn't fully solve your problems at the end because you didn't have all the insights you could gain during project execution, in our view makes the Fixed Price contract a lot more expensive, despite its promise of saving on cost on paper.

This is on top of the fact that under fixed-price agreements, the development team is carrying most of the risk involved in the project estimation in giving you the right price that covers their expenses as well as leaving some buffer for their profit. As software development projects are quite likely to experience unexpected complications, software companies will add a contingency $ amount on top of their final estimate to ensure they cover the risks involved in their estimation process, which would make the final fixed price even more expensive.

Summary,

• Budget is fixed
• Deadline is set
• Scope of the work is pre-determined
• No change after the contract is signed, unless the Change Process is activated
• Quality will be possibly compromised in case of large and complex projects
• It is probably the more expensive contract type compared to Time and Materials

When,

• The project specifications are crystal clear, and you know EXACTLY what you need
• There is no need to gather feedback from your customers
• The project is simple/small enough that the estimation could be accurate enough for the developers, so they won't be under pressure to sacrifice on quality

Time and Material Contracts

As the alternative to Fixed Priced contracts, in Time and Material engagements, the client pays for the time of the Software Development Team spent on building the application, and it allows you to make changes to the product, priorities, and features, and to pivot and react to market changes. You are the product owner, and until you are happy with the produced outcome, which could happen at any time, the project continues. On the other side, if you would like to terminate the contract for any reason, because you are not happy with the progress or your budget runs out, you can also terminate or pause the engagement at any time. The notice period is typically from the moment you decide to pause until the last day of the following month.

The notice period is typically from you decide to pause until the last day of the following month.

You might have noticed that this is the type of contract that fits very well with our Agile development methodology, in which design, development, test and deploy happen iteratively, without the need of a rigorous and lengthy initial design process, which gives you a log of flexibility in terms of scope, deadline, and budget.

Early feedback can be gathered from your customers and applied right away as we develop the product. You might deprioritise some features as you realise customers receive more value from other features, and as a result, you also could remove redundant features from the backlog, all as you are developing the software.

Flexible backlog, as with time and material, the features on the backlog are fluid and can change as the product matures. The project could also finish earlier as you might decide the MVP (Minimum Viable Product) we have developed is good enough based on the feedback you have received from your customers while developing the product.

Fast start, as there is no substantial early design phase and you could start the development right away by building what your end-users need, getting their early feedback, and feeding that into your backlog right away.

Transparency because you, as the product owner, have full control and visibility around what the development team is working on, and what features get prioritised/deprioritised. Features which are essential to your sales lifecycle and bring more revenue, for example, could be prioritised and built first, so you can start engaging your customers from early on.

Trust? However, you might say that Time and Material contracts might go over the budget, and the software developer could slow down their development to charge more after a while. The solution is to shift your focus from adding all the possible feature, to just building the MVP, and by doing that you only build the essential features. By the time that is done, you would already know what the development team velocity is, and if you are happy with their speed of delivery, you should expect them to continue with the same velocity for the rest of the project.

Higher engagement as in time and material contracts we need your involvement as the product owner to steer the development team, prioritise the backlog by focusing on your business value, analyse the customer feedback and help the development team apply the feedback back to the product. Hence it won't be set and forget, and you need to spend more time communicating with the team and steering the engineers.

Iterative development, |The best approach to building software that helps your customers get what they need, and adds absolute value to your business, is the one which is iterative and is based on the confidence you gain from your customers' feedback while you build your product.

High quality is built in because the focus of the team shifts from delivering monolithic phases/deliverables toward iterative cycles of improvements of the core features, the engineering team has enough time to focus on quality and business-value based deliverables as you go, and they won't be under last-minute pressure just to meet the deadline.

Too much flexibility might cause problems due to the risk involved in not hitting the deadlines as more suggestions come from the customers as the product owners would like to apply them all. The key point here is to define the MVP clearly as the project progresses and make decisions based on the priorities to the business, defining 'Must-Haves' as opposed to 'Nice to Haves'.

Maybe cheaper? You exactly pay for the work which has been done, and there is no contingency involved on the final price, and you can stop the project whenever you are happy with the produced outcome (or MVP), and you spend less time and effort on negotiating the potential change requests after you signed the contract. We believe this makes the project was cheaper and less risky than fixed-price.

Summary,

• Budget and pricing model is flexible and transparent
• You could pause/finish the project at any time, either because you are happy with the MVP, or any other reason
• The backlog is fluid, and you can change the features at any time
• Quality won't be compromised as the team has enough time to embed quality in all the features
• It is probably the cheaper and certainly the less risky contract type compared to Fixed Price overall

when:

• You intend to build a software that covers the real market need
• If the project is complex, and the requirements are not clearly defined upfront
• You have a new idea, and you would like to experiment with different features and see which one works best for your customers
• You care about quality, how the product is built as well as how it works

Our Recommendation

We recommend Time and Material for all our contracts by default, as you will save time and money doing the actual project rather than spending much time discussing things that may not even happen upfront.

For complex projects with lots of uncertainties, when there is a need for flexibility, we only proceed with Time and Material.

For larger but straightforward projects, if there is a need to have clear estimates before we begin, we recommend having a mix of Time and Material and Fixed Price contracts, with a change management process in place for the fixed price part.

Also please note that finishing a project, within a set time frame, under a set budget with a predefined scope, almost never happens. Even if the budget and the time frame could be met, the scope is a bit challenging to be met, as you learn more about the product as you develop it while facing unexpected complications, or wanting to add (or remove) features.