Image source: https://flic.kr/p/4bjHBj, under Creative Commons License

Haven't we all learned in project management courses that fixed-price contracts are not necessarily an advantage for the buyer-side? Weren't these problems the very reason why agile project management principles have been invented? However, it is a matter of fact that many customers still insist on fixed project prices. In this blog article I want to share our approach of making fixed-price and agile go together.

The Myth of Risk Reduction and Fixed-Price Contracts

Many software projects fail. At least many are seen as failures by the involved customers for a variety of reasons:

1. Project budget was exceeded.
2. Time schedule did not hold.
3. Promised features weren't delivered.
4. Desired business value could not be achieved.
5. Users did not accept the software.

What do we usually do to reduce risk? We buy insurance. We pay a bit of extra money so that someone else takes over our risks. In analogy to that, many companies prefer fixed-price contracts over time-and-material. It is obvious that a fixed-price contract has one major precondition:

The deliverables have to be specified in details before the contract is signed.

If not, suppliers have to calculate exorbitant risk surcharges or work with dirty tricks when it comes to even minor scope changes ("change requests"). As a result, buyers who insist on contracts with prices fixed upfront for explorative projects are not really reducing their risks.

In my experience, especially large organizations with large projects are still having policies in place that require upfront fixing of prices. However, they don't want to (or are not able to) invest the necessary time and money for a proper project startup phase (e.g. requirements elicitation, prototypes, evaluating involved technologies, feasibility studies, proof-of-concept projects, etc.). Such customers forget that fixing prices goes hand in hand with fixing the project's scope upfront, too.

Studies have shown that large projects fail more often and tend to deliver less [Gartner]. The iterative and incremental approach that especially agile project management approaches argue for, offer a solution.

However, customers are in fear that time-and-material agreements are like giving a blank check to their suppliers. Therefore, fixed prices and iterative, agile development somehow have to come together. I want to describe three important strategies that we use to do the splits.

Strategy 1: Knowing Your Environment Enables Fixed Prices

"Everything is simple until you think about it" (Niffenegger: The Time Traveler's Wife). This quote is true for many software development projects, too. Fixed-price contracts are more likely to work if buyer and supplier have profound knowledge of the domain and the involved technology. Here are some reasons for that:

• The buyer is able to express her needs more exactly.
• The supplier can detect missing pieces in specifications and ask questions like "You did not ask for X. In our experience, customers in your domain need X. Are you sure you don't need it?"
• The supplier can draw knowledge from similar projects she did in the past (I have written about this topic in a separate blog post).
• Typical problems can be anticipated or at least identified at an early stage if buyer and/or supplier know the domain and technology.
• Supplier and buyer might have experienced teams on both sides that are used to work together.

As a buyer, value proven experience (domain-specific and technology) of potential suppliers if you want to go for fixed prices. As a supplier, try to standardize at least parts of your offerings and use economy of scope effects to enable fixed prices to a certain extent.

Our Approach

Whenever we offer our own product time cockpit to customers, we try to be very clear in our communication:

1. What is part of the standard and/or offered for a fixed price?
2. What is part of our daily business and can be priced upfront although requirements might be a bit unclear or existing artefacts needs some project-specific customization? Here we can offer a fixed-price if we (transparently) calculate a small "slack" that could cover unforeseen problems.
3. What is totally project-specific and/or unknown for us (e.g. no or unclear requirements, unknown domain, unknown technology)? Here we say "no" to fixed-price contracts and suggest to use the power of agile methods (in our case Kanban).

Strategy 2: Start with Time-and-Material, Switch to Fixed-Price Contracts Later

Fixing a price at the beginning of a reasonably large project is a huge challenge. Typical reasons are:

• Requirements are not fully known yet.
• Project is under time pressure so there is no time for in-depth upfront planning.
• Buyer and supplier do not know each other. Therefore they lack of an existing trust relationship.
• Project requires the use of unknown technologies.
• Fixed-price offers from multiple vendors are too different so they cannot really be compared.

Buyers should consider starting small (see also concept of Minimum Viable Product) with a time-and-material contract. Learnings from projects with limited scope can tremendously help planning the big follow-up project and evaluating a supplier.

It is important to note that this approach only works if the teams on both sides stay more or less the same over time. If people constantly change, the learning effect and trust relationships will be much less or even eliminated.

Our Approach

If we offer time cockpit in larger organizations, we do not try to close the big deal at once. We structure our product's pricing (e.g. no minimum contract duration, not minimum number of users, etc.) and our consulting offers so that customers stepwise gain trust into our offerings and we learn to understand their needs. Here are some examples from real-world customer scenarios:

• Start with implementing the software in a certain department or subsidiary and see if it helps.
• Focus on the absolute must-have-requirements in the beginning. Delay nice-to-have-features for later optimization projects which will then have fixed prices.
• Offer generous evaluation options (e.g. extended free trial period if necessary, full support during evaluation phase, small customizations for free during evaluation period, etc.).

Strategy 3: Capped Costs with Incentives Instead of Fixed-Price Contracts

The idea is to agree on a cost cap to reduce the buyer's risk and to let the buyer benefit from unused budget "slacks" at the same time. Granted, as a supplier you will likely not become super-rich on short sight with this strategy. However, you will get loyal customers on the long run.

In our experience, this approach needs a few rules to work:

• Small scope changes are ok and do not change the cost cap.
• If the scope changes massively, buyer and supplier have to sit together and find a fair solution for both sides.
• It is in the responsibility of the supplier to state loud and clear if the buyer behaves in a way that puts the success of the project at risk (e.g. massive scope changes, poorly worked out requirements, missing engagement from the buyer side, etc.). If the supplier did not warn upfront, budget exceedance is her problem.
• The supplier has to get incentives (e.g. higher rates, additional orders, etc.) if she manages to be more efficient than expected.

Note that honest project reporting is a precondition. The effective effort has to be transparent to buyer and supplier (I have dedicated an entire blog post to this topic).

Our Approach

Whenever we offer consulting projects, we always offer a bandwidth for the effort:

• Lower Bound: We don't think we can make it faster than that.
• Upper Bound: You have to expect that the project can cost up to this amount. We will try to keep costs lower but it could happen that we charge you this much.

We supply customers with detailed reports about efforts on our side even in fixed-price projects. We even report effort for bug-fixing or effort that they do not have to pay for because the project's budget is already exceeded. Our goal is to always have an open and honest discussion about prices and estimations.

Further Readings

1. Stropek: How to Sell and Estimate Agile Projects
2. Stropek: Project Reporting in Agile Projects
3. Selecting the Type of Contract in Project Management for Instructional Designers http://pm4id.org/
4. Van Cauwenberghe: Agile Fixed Price Projects Part 1: "The Price is Right"
5. Highsmith: Exploration versus Optimization in Agile Software Development Ecosystems

comments powered by Disqus