Don’t Regret Choosing The Fixed-Price Model. How To Change Project Requirements?
When you sign a Fixed Price contract, you get a price tag and a deadline with it. This is the main reason why customers choose this pricing model. But in some cases fixed price can cause unnecessary confusion. Let’s see what happens if you need to change project requirements with the fixed price model.
What Pricing Models Are There?
Fixed Price – you pay a fixed sum and get the product that you’ve agreed on with the software developer. You will also know the deadline in advance.
Time & Material – the software company will estimate the budget and the timeframe. Basically, you pay for the hours that the team works on your project.
Dedicated Team – the designers and developers will be managed by the customer.
First, let’s explore the model in more detail. Here are the key features of it:
It comes from the name: the budget is approved in advance. It remains the same unless the client wants to make edits.
Before the project starts, the customer and the software company sign documents that will describe the product from all sides. These can be Vision & Scope Document, Software Requirements Specialization, Technical Solution Document, etc.
Fixed Time Frames
Deadlines are very important. On one hand, you can be sure that the software company will make the deadline. On the other, if you want to edit anything during the development, the deadline gets moved.
All new features and adjustments require additional agreements. Each agreement means additional fees. Changes increase the budget and move the deadline.
Higher Price Rates
The fixed price model is riskier than T&M, so software development companies include these risks in the price tag. In the end, such projects are more expensive.
Potentially Lower Quality
There are three variables in project management: the price, the timeframe, and the end quality. If the price and the deadline are set in stone, there’s only one thing left to optimize – the quality. In that case, a software company can use existing templates and libraries. A reliable software company will plan the project. Yet, sometimes the world is unpredictable, especially in the long term.
Why Can Requirements Change?
Building a software product is a lot like building a house. Both projects need structure and precision. So let me give you a construction example to explain changes in requirements.
Think about a young family that wants to build a house. They find a construction company and sign a fixed-price contract. The construction company begins building. In a few months, the family decides to get more space by combining the living room with the kitchen. They ask the construction company not to build the wall between the rooms, but it turns out to be a bearing wall. Without it, the house will fall apart. So the family has to put up with a separate kitchen and living room.
A few months later, they decide to change tile flooring to wood. Yet, the company has already bought and installed tiles. The maintenance workers can still change the flooring, but the family would pay for extra materials and working hours.
The same thing can happen with software development. When the project is settled, it’s not possible to make high-level changes on a fixed-price contract. It may be possible to tweak minor things, but the company may already have spent time working on the previous requirements. If you want them to work on changes, you’d need to pay extra fees and move the deadline.
A software product begins with a business idea. You need to set a commercial goal, work on the product vision and think about your target audience. That’s why the software company learns your business needs and documents the future product. For large projects, this usually takes a month. But even then companies mostly collect upper-level requirements: which features does the product need and which ones it doesn’t?
The problem is that no specification document can include every little detail. Inevitably, some aspects of the project don’t get documented.
Here’s Why Project Requirements Can Be Changed
- A customer may rethink the system. For example, a school wants to build an iOS schedule app for students. Later on, they realize that many students have Android phones, so they either have to build 2 apps (for both iOS and Android) or build a web platform instead;
- The requirements may not be detailed enough. If the customer doesn’t mention a font that they want to have, the choice is up to the software company;
- The customer solves a business problem after the development starts. New features can be game changing;
- A competitor launches, while the project is being developed. The competitor’s product may look or feel similar to the customer’s. If they don’t want to look like a copycat, they need to rethink the product;
- Stakeholders can change. Long-term projects take months of work. While the software team is working on the project, the customer can hire a new CTO or project owner. New stakeholders can have a different vision for the project;
- Something changes on the customer’s side. Companies can run out of financing, they can get reorganized or bought out. In these cases, projects are often reevaluated;
- Something changes in the world. There can be political changes, economic recessions, or simply new bills passed. For example, the GDPR law that was passed in the EU made companies rethink how they collect private data.
The software company may upgrade its tools, frames, or technologies. In these cases, they can build better products, but the fixed price contract still requires building a more dated solution.
Can You Make Changes To A Fixed-Price Contract?
No, a fixed-price contract is set in stone. But sometimes it’s possible to sign additional agreements. This is how it happens:
- Agree on a change request form with your vendor. Without one, your change request can get lost;
- Check if the change is technically possible. High-level architectural changes are impossible to draw back. So be careful when creating project requirements. Some of them stay for good;
- Make sure that the change will bring value. Changes increase budgets and deadlines. That’s why your project may be better off without some of them. Take a look at the original product idea and see if the change will actually help the project. Talk to your vendor’s business analyst. He or she will help you stay on the right track;
- Negotiate the price and timing;
- The vendor will reschedule the project;
- The developers will work on the changes.
What Happens After The Change?
As you can see, changing requirements cause lots of extra work. Here’s what you can expect afterward:
Even if your request gets rejected, the software company still spends time analyzing it. If you don’t want to pay extra on a fixed-price contract, avoid changes.
All changes require additional work, so the deadlines will be moved.
Some changes may go against the original architectural solution. In these cases, developers have to find workaround solutions that undermine the original system.
Whenever a change happens, the team should stop developing and revise the whole project. This way it’s harder to prioritize and stay focused on the project.
Unlike with Agile, on fixed-price projects, the developers build sturdy architecture that is not supposed to change. When it does, the team can lose focus. The product quality may go down as well.
With fixed-price contracts, clients plan budgets and timelines more rigidly. If changes happen, clients tend to be less satisfied with the result even if all the requirements are met.
When To Use The Fixed Price Model
For some companies, it’s especially important to know the deadline and the final price in advance. The fixed price model can both help or hinder such projects.
With fixed-price contracts, changes are far more expensive and distracting compared to the T&M model. To avoid changes, use the model on small projects with clearly defined scope. If you realize that you may add new features or simplify the product, go with another pricing model.
Here’s a thing we’ve noticed for the 9 years that we’ve been in business. At the start of large projects, customers rarely have a full grasp of their future products. That’s because it’s impossible to plan every little detail. There is always something to improve, and new ideas come in the process. It explains why tech giants like Google and Meta still work on their products for years after they’ve been released.
Most companies reserve fixed-price contracts for smaller projects. They build long-term ones with the Time & Material model. This way changes are made iteratively. As the project develops, both the customer and the software company get a deeper understanding of the product.
It’s tempting to start a long-term project on a fixed-price contract. But be careful signing it. You may end up paying more for a weaker product.