3 Ways to Be More Agile in a Fixed-Price Project

Business is becoming more and more complex, yet we still have to operate within fixed budgets. In a fixed-price project, a team must agree to deliver software with a defined set of features for a price that is agreed upon up front.

There are several risks with delivering on fixed-price contracts: requirements may be too vague and the team will underestimate them, the client may have forgotten requirements and want to add them in later for no additional cost, or the client may not know what they really want until they see it. 

Fixed-price projects can also be quite large and risky, and this causes even more struggles between the team and client. Unfortunately, these risks put cost at the center of the project instead of value, and that is not good for the customer.

Fixed-price projects are a challenge to manage when using agile practices, as software teams need the flexibility to change what they are building based on customer need, and that often alters what can be done within a fixed budget. While this is certainly a challenge, there are ways to achieve agility even within a fixed-budget constraint.

Here are three ways to make a fixed-price project a win for all parties involved.

Define what you want in small deliverables by prioritizing features

The client knows their business, but it’s unrealistic to expect them to come up with all the required features for their project up front.

Instead, the team and client should work together to break up the project into smaller releases and come up with a short list of releasable “must-have” features. You can consider the rest of the features just “nice to have” until a later release.

It is important to do this prioritization at the beginning of the project, regardless of whether the client has a limited budget. As a good IT partner, it is important to guide clients so they can get the maximum return out of an investment. This prioritization approach focuses them on choosing what is most important first, and allows you to create a minimal viable product you can build upon.

When there are multiple business stakeholders involved, it is possible that your original list of must-have features will change, so get everyone on the same page as quickly as possible. Incrementally creating smaller releases within a larger fixed-price project will help everyone make informed decisions about what to develop and when.

Define prices to understand the cost of each feature

When we think about a fixed-price project, we generally envision the entire product we want to build. However, I think it’s more efficient to come up with a list of features and then define the costs of each feature for development.

In my mind, it is extremely important to understand the cost of each feature so that we can estimate the cost and align it with our budgets. Priority should always be given to the features where less investment is required for the highest return.

You will have to spend some time up front to define the cost for each feature, but doing so collaboratively with your client will eliminate most of the ambiguity and provide greater confidence that estimates are correct. If you estimate the amount of time each feature should take to develop as well, everyone will know what features can fit into smaller releases.

Define smaller, features-level contracts

Fixed-price contracts are usually for the entire product development effort, which may include 20 or 30 large features over a couple years’ time. This is much too large of an effort to try to accurately scope! 

Plus, this approach provides almost no opportunity to gather customer feedback and change scope as needed. Also, if the product is fully developed within a long-term, fixed contract, then any changes will have to go through a costly change management process or contract negotiation, causing constant tension between the client and the team.

However, if contracts are kept small, like to two or three features, then it will provide the team greater flexibility while allowing the client team to pick and choose what features are most important as things change.

For instance, if the customer realizes early on that the product being developed is a duplicate of another product that is not gaining traction with end-customers or stakeholders, then they can stop development easily without worrying about a long-term contract where they have to deal with penalty causes and a potential broken relationship with their vendor team. Giving out small, feature-level contracts also allows client to engage multiple IT vendors or teams when they want to expedite development.

Businesses can combine these three ways to address risks in a fixed-price project into a structure that will work for both the customer and the team. Once you lay down the approaches you want to use, cycle through your process to continuously deliver your product. Doing so will help you and your customer create value while controlling costs.