Don’t Regret Choosing The Fixed-Price Model. How To Change Project Requirements?
Introduction
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.
Fixed Price
First, let’s explore the model in more detail. Here are the key features of it:
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:
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.
The Fixed Price Reality
Conclusion
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.
