Laurila on Contract Models

Our CTO has an issue with fixed price.

I have a fireplace at home. I love it, but like any piece of technology, it requires maintenance. A couple of years back I had my chimney swept. After the job was done the sweeper came to me with an expression on his face that looked like bad (expensive) news. I was right — the coating on the inside of the chimney had been fractured or damaged in some way and needed to be redone.

So I asked around a bit and got recommended a guy to do the job. He came over, had a quick look at the chimney and came to me with a number. “We have this thing called fixed price”, he explained, as I was cocking my developer's ears. He told me that it means that they carry the risk if something unexpected would happen.

I refused. I asked him what their hourly quote was and if they could just give an estimate and charge me time and material based. While puzzled, he agreed. Once the job was done I ended up paying a bit less than the original fixed price. It only makes sense — as I was now carrying the risk, I should be able to make a profit too. But this is not why I wanted this contract model.

So, what if something unexpected would've happened? Maybe the contractor found out that the chimney was in way worse condition than they originally thought and needed some additional repair work, not just the coating. In a time-and-material-based model they had come back to me and told about the situation so I could decide on how to proceed: Was the old chimney worth the extra cost? Do I want to repair it now or maybe later when I have saved more money? For the contractor it's all the same, they will get paid in any case.

With a fixed price, the situation would be totally different. No matter how much extra effort they put in, they will never get paid more. So basically, they have no incentive to repair the chimney properly, quick and dirty would do. Sounds like a bad idea to me.

Now, you might say that this wouldn't work in software development because no one has an unlimited budget. Luckily, software development is very different to chimney repair work. It's very dynamic, which allows us to decide on a budget, schedule and high-level plan and then execute it implementing the most valuable features first. With this approach we don't know the exact features we'll get, but we do know that we'll get the best possible product within the given budget.

Another problem with fixed scope project is that you have to put a lot of effort into planning and estimations, the latter being 100% waste in a sense that it doesn't add any value to the final product — it only serves the project. Planning is obviously not all waste, but given the fact that in real life implementation details often slightly change when writing code, there is a lot of waste in detailed planning, too.

This all might seem a bit puzzling to someone used to the waterfall project model. Instead of gathering the functional and non-functional requirements¹ to a huge document followed by an RFP process, how should it be done? Here's my suggestion:

  1. Gather your business requirements. What is the business goal you want to achieve? What is the problem you are trying to solve?
  2. Innovate and find the core solution and the basic approach. Don't focus on details. This can be done in-house or with a partner.
  3. Looking at the potential business benefit and the rough size of the solution, agree on a budget. It makes sense to do this together with the contractor(s).
  4. Choose a contractor. You already know the price, so pay attention to their competence, references and try to evaluate if they have truly understood your business needs.
  5. Implement in an agile² way. Be involved in the process! It's your baby, not theirs. First, implement the core features so that they work; don't dive into the details in the first phase! Just make it work. Fine-tuning comes after that.
  6. Release as early as possible. No internal testing or user study can replace feedback from real-world users.

Don't go waterfall.

¹ I've always found the concept of non-functional requirements a bit silly. Why would you want something in your product that doesn't do anything?

² There are many agile frameworks and there are books written about their differences. I recommend choosing one and committing to it, maybe the one your contractor prefers or suggests for the job.

Lasse Laurila

Co-Founder, CTO

Raging electric vehicle enthusiast