Everything You Need to Know About the Fixed Price Engagement Model in Software Development

While a classic in the sphere of software development, the fixed price model is losing momentum in the rapidly evolving environment. It provides predictability and certainty at the price of flexibility and transparency. Read on to find out how it works, when it works, and when it doesn’t. Part 2 of 4. (Read Part 1, Part 3 and Part 4.)

In the first part of this series we talked about why you need to choose your engagement model carefully, and we outlined the three most widely used models in the sphere of fintech, blockchain technology, and web and software development. Now it’s time to dive deeper into the most classic one of them all — the fixed price engagement model.


What Does it Mean, Exactly?

With the fixed price engagement model, you and your vendor of choice agree that they will complete a project with a specified scope within a specified time frame and a specified budget, all of which are clearly laid out in the contract. The main implications of that simple explanation are the following:

Cost

You know right from the beginning exactly what sum you’ll be liable to pay at exactly which points in the project development — provided no changes to the initial scope of the project are made. If the project goes over budget — for example, if there’s a need to hire more software developers in order to meet the deadline — those additional costs don’t affect the final price. Instead, the supplier takes this possibility into consideration while determining the price and includes a safety factor, which is meant to protect them from loss and which is payable whether such additional resources end up being necessary or not.

Time

You and your vendor agree on the exact time frame of the project. It is the vendor’s responsibility to keep to the specified budget and time frame.

Scope

Your vendor knows from the beginning of the project exactly what software they need to build. That means that if unplanned for changes need to be made, they will have to be set out in a new contract with a new set of requirements, a new budget, and a new time frame. It also means that your requirements need to be very clear in order to avoid ending up with a product that’s nothing like you imagined it. (A good vendor will help you out here by asking you plenty of questions before accepting vague requirements.)

In the sections below, we will break these characteristics down into pros and cons and look at which projects could benefit from a fixed price engagement model. But before we get on to that, let’s look at how exactly a fixed price project works.

How Does the Fixed Price Model Work?

1. Requirements

Every fixed price project begins with a full set of requirements. That includes clear and detailed descriptions of each functionality, feature, or characteristic of the desired product; full designs (if your supplier is not also handling the design for you, in which case you need to provide them with mock-ups that are as detailed as possible); and acceptance criteria for each of the above.

2. Request for proposal

Once you decide on the requirements for your project, they are organized in a request for proposal (RFP). This document outlines the business needs of the company, the software that’s to be developed, all its specifications, and evaluation criteria. It could also include a breakdown of the tasks that the project will consist of and a timeline for completion.

3. Clarification

When the vendor receives your RFP, it’s time to clarify the requirements. The more questions they have, the better — it means less chance of wrong assumptions and a final product that’s not exactly what you imagined. The clarified requirements are accepted and the vendor starts the process of estimating the necessary time and budget for completing the project. In case you specified the timeline in the RFP, the vendor needs to estimate how big a team they will need to meet those deadlines, which will affect the cost.

4. Offer of implementation

You receive an offer of implementation from the vendor, which includes the fixed scope of the project (divided into milestones, each with its relevant acceptance criteria — examples of typical milestones are design, front-end development, back-end development, testing, etc.), the schedule for delivery and payment, the terms of the agreement (including the terms for issue resolution), and the procedure for change requests, as well as risk mitigation. Once you accept the offer of implementation, the scope specified in it becomes final, and no changes can be made, except by following the procedure for change requests. Usually, at this stage a pre-payment is made, typically 50% of the final price.

5. Development

Development of the intermediate products begins, and at each delivery date, you are due to receive the specified milestone. Keep in mind that you do not receive a functioning product until the very last stages of the project. For example, if your vendor is handling design, the first deliverable you receive will be a full preview of the appearance of your final product, without any functionality.

6. Alpha version and refinements

At this stage, your new software is in a testing environment, in which you are free to play around and see if it meets the acceptance criteria. The last stage consists of refinements, which means the product will be tweaked according to your feedback and suggestions, but any major changes will have to go through the procedure for change requests and be billed separately.

7. Going live

The last milestone is typically uploading the finished product on a production server. That’s when it goes live and real users start interacting with it.

8. Acceptance period

Most vendors will include an acceptance period after the product goes live — that’s usually between 5 days and a month. At this stage, the development team will fix any outstanding bugs without additional charges. The time the team spends fixing bugs does not count against the acceptance period.

9. Finalization

When the acceptance period runs its course, the project is finalized, final payments are made, and you receive any outstanding deliverables, such as the source code of the project, along with all documentation relating to it.

As you can see, it’s a complex and long-winded process from the birth of an idea to the release of the final product to the market. Let’s now look at the types of projects this model is suitable for, as well as the pros and cons of the model itself.

When is the Fixed Price Model the Right Fit?

Short-term web development projects with a limited and very clearly defined scope

If your project will take less than 3 months to bring to completion, fixed price might be the way to go. You’ll be able to plan your budget for the quarter, and there’s a smaller chance that changing circumstances would dictate a shift in the requirements. For example, if you own a start-up, but you haven’t got any big investments yet, a small and well-defined MVP aimed to sell your idea to potential investors would benefit from a fixed price engagement model. However, any lack of clarity will work against you, so you need to be very specific about vision, goals, expected results, target users, inherent risks, and so on, before the onset of the project.

Limited budget or complex budgeting procedures

If you have an exact sum that you can spend on the project, or if you need to get your budget pre-approved without the option to adjust it afterwards, fixed price seems like an obvious choice. In our experience, this is usually the case in the banking and the government sectors, in which a predetermined price is essential for the acceptance of the offer of implementation.

Rigid timelines

If you have an immovable deadline you need to meet, fixed price gives you a guarantee that the project will be completed by that time. (We’ll look into the implications of that in the pros and cons sections.) If you are in this situation, however, you need to be exceptionally careful with the clarity and accuracy of your requirements — in the case that changes need to be made, these will come with their own deadlines and the rigidness of the timeline will become fuzzier.

Test drives for new suppliers

The fixed price gives you the certainty that if the vendor of your choice turns out to be less qualified than advertised, you won’t end up paying for their mistakes. This is a shaky option that we don’t recommend because while you won’t be paying extra money, you don’t want to end up with a product of subpar quality.

Lack of capability to be involved in the project

This is the only model that lets you hand off the requirements and forget about the project for a couple of months, so if you cannot or don’t want to be engaged in the development process, this might be a last-resort option.

Pros of the Fixed Price Model

  • Low monetary risk. This is the only model that gives you an exact figure you can plug right into your budget planning. There’s no danger of going over budget and having to figure out additional funding. If the project goes overboard, the supplier bears the cost.
  • No surprises. Everything is laid out in the requirements and, provided they are clear and detailed, you know exactly what you’re going to get at the end of the project.
  • Clear deadlines. All the stages and terms of development are agreed upon by all the stakeholders, so deadlines can be reasonably expected to be met.
  • Efficiency. Finishing the project in a timely manner is in the interest of the supplier, so the developers are highly motivated to be productive.
  • Ease of management. Payments are pre-determined both cost-wise and due date-wise. What is more, little involvement on your part is necessary for the day-to-day carrying out of the project. Once you do your part of the work — providing the requirements — you can hand the project over to the supplier and not worry about it until its completion date.

Cons of the Fixed Price Model

  • Lack of flexibility. Once the requirements have been approved, they are considered mostly set in stone. If they need to change due to a shift in the market environment, the needs of the business, or new and better ideas, that has to be done through the procedure for change requests, which might be cumbersome and frustrating.
  • Danger of confrontation. It’s natural. You as a client want a product that will serve your needs perfectly; the development team wants to build the product you requested without any changes to it. Nobody is wrong here, but the fixed price model could lead to a tug-of-war situation in which you and your supplier work as opposing forces, rather than as partners. This is why it’s imperative that the contract detail the terms of issue resolution between the parties.
  • High cost. You pay the agreed price, regardless of how long it actually took for the project to be completed. That might be good in some cases, but most of the time, you will pay more than necessary, because of overestimations or time spent on features that you later decide are unnecessary. The fixed price contract includes a risk premium as well, which is meant to compensate the supplier in the situation that the schedule turns out to be an underestimation.
  • Unclear vision. It’s much more difficult to know what you want beforehand than to look at a product and decide what needs to be different.
  • Lack of transparency and control. The fixed price model doesn’t provide for regular discussions, reports, and feedback sessions.
  • Unrealistic deadlines. As the supplier is bound to the pre-determined deadline, if the latter turns out to be unachievable, the quality of the product might suffer in the frantic rush to complete everything before the delivery date. The more unclear the initial requirements, the bigger the danger that the timeline of the project will be inaccurately estimated.
  • Longer time-to-market. This is due to two factors: the long pre-development stage, in which you need to get the requirements to crystal clarity, and the fact that you only get a functioning product at the very end of the project term. This leads to postponed revenue and the risk that the product will become outdated before it has even seen the light of day, which is why we strongly advice against the fixed price model in fintech and blockchain technology projects, which are a very dynamic and fast-evolving environment.

The Verdict

The fixed price engagement model is a classic, but its use cases are getting narrower and narrower all the time. It’s reliable, predictable, and relatively low-risk, but it’s highly inflexible, which makes it unsuitable for the rapidly evolving world of today. It’s viable for small scale web development projects, in which you know in detail exactly what you want your end project to look like, but for anything that would take longer than two months to develop, you might want to look into the other two models of engagement — the time and materials model and the dedicated team model.


About INDUSTRIA

INDUSTRIA is an award-winning global consultancy and development firm that creates web, blockchain and fintech solutions, helping both companies and ecosystems significantly reduce the costs and complexity of doing business. Official partner of R3.

INDUSTRIA delivers quality web and software solutions based on the fixed price model. To talk to us about bringing your idea to life, contact us here or follow the links below.

Follow us on Twitter, our blog, LinkedIn and Facebook.