Okay, so we kind of concluded fixed-price contracts are evil but what are the alternatives?

Before we move on, let’s get the terminology right. Erik van Oosten rightfully commented we might have to start using the terms fixed-feature and fixed-term on top of fixed-price. To take it to a bit more general level, in a project there are three basic variables: a collection of features (or scope), the deadline (or schedule) and the budget (or resources). I’m specifically naming them scope, schedule and resources as these are the exact same terms Scott Ambler came up with in his article titled The Broken Iron Triangle Software Development Anti-Pattern. In his paper, Scott argues that ‘refusing the recognize the implications of the iron triangle’ is ‘one of management’s more popular approaches to hamstringing an IT project’. He goes on to say ‘we really need to question the ethics of “fixed-price” IT projects‘, which confirms what we’ve already settled upon.

The next thing he says (and this is completely obvious, if you’ve ever encountered an agile project done right) is you should be prepared to vary one (or even two) of the factors involved. Vary the scope, schedule or the resources that is, based on what you encounter during a project.

That’s nicely said and all, especially if you’ve won the client’s trust already, but what are you going to tell a customer that has a budget of say €100k for which you’ll quite likely implement something nice that suits his needs. The client puts out an RFP and invites three suppliers to answer to the RFP. You now it’s best for the client to end up in a situation where in cooperation with the client you can vary either scope, schedule or resources, but you have to win the client’s trust first.

I think the answer lies in the response to the RFP plus a certain amount of risk you’re willing to take as supplier to win this deal and this is where the list of contracts comes in that I got from Martijn Dashorst of Wicket fame. The list, by Alistair Cockburn provides various options for drafting a cooperation between the client and the supplier, varying from fixed-everything to fixed-nothing.

I’ll be digging through this list in the coming weeks to see if there’s anything usable. In the meantime, one thought I had was to be upfront with a potential client and offer him the various options for drafting an agreement (or at least, the ones we feel comfortable with). I’m not sure this will work in all scenarios. There are plenty of RFPs for example that require you to come with a response without being able to discuss possible directions with a client (how weird that may sound).

At JTeam we’ve been doing projects for ages and generally speaking we’ve always done things the agile way. Convincing the customer of the importance of agility and flexibility is something we’ve never found to be a hard sell. How to write this up in a proposal and how to draw up a contract around such an agile project however is rather challenging. In the past, the way we’ve written our proposals and drawn up our contracts has worked reasonably well, but it never hurts to try to improve it in order to satisfy our customers even more.

This is why I’ve been reading up on what others have to say about this subject. What I found was pretty interesting and I’d like to share my findings with you and also reflect a bit on these findings.

Are fixed-price contracts evil?

Generally speaking deals where for a fixed amount of money a project will be executed result in the client having no or little incentive to accept the project as being done or complete. After all, broadening or changing the scope of the project can be done at no cost, since the price has been fixed at the start of the project. The risk is entirely at the supplier side.

Naturally the supplier wants to minimize this risk, so usually demands or forces the customer to be very precise about the scope before the start of the project. In addition he asks for changes to be done using change requests, which subsequently are charged at a certain rate.

In his turn, the customer then puts as many feature in scope as possible, thinking that if he does so, the chances will increase that the features he really needs are among those in scope, hence not needing any change requests.

The end result:

• Way too many features initially in scope, many of which will be left unused in the end product
• Too much time and money spent on these features
• A situation where the customer is encouraged not change his mind too much
• A situation where the supplier is not encourage to think along with the client during the process as this again results in change

In other words: fixed price deals result in fix bid projects where both budget and scope are tightly controlled and change is kept to a minimum.

We’ve all concluded in the past that agility and flexibility during a project’s execution is something that’s desirable. Given this and the above, fixed price deals are not the way to go if you want agility and flexibility.

So, what is the answer then?!

So if we know that fixed price contracts are not the solution if projects that accommodate change are a desirable thing, what contractual agreement should be used? Well, this is a question not easily answered.

Seth Schubert states things very elegantly in his blog entry on {codesqueeze}:

It is very difficult to arrange a contractual agreement that accommodates change. At the end of the day, your client’s accounting department is going to want to know how much the project will cost, and when they can expect to receive working software.

A bit further on Seth states that

a client will tend to perceive a fixed bid contract as less risky. By controlling the scope and budget in a project, the client’s stake in the project are seemingly protected. The risk of project failure by defining scope to early is not altogether intuitive or obvious.

He talks about the exact risk that we identified above. The risk of implementing too many or useless features, the risk of the supplier not thinking along with the client to prevent him from running into pitfalls, et cetera.

Next, Seth states that:

Even when presented with this information, a new client may still may be unwilling to enter into an open ended contract.

This is what it comes down to: having no prior relationship with the supplier, customers often simply cannot relinquish control over either budget or scope right at the start of a new project. To some extent, I find this completely understandable; after all, how can a customer trust the supplier in his doing the right thing? It’s the first time he’s met the supplier.

Based on this, the question still remains: what contractual agreement makes it possible for the customer to let go of budget or scope in the long term?

There’s in fact plenty of research out there and examples of contractual agreements that facilitate this, some of which I might highlight later on. For now, we’ll first discuss some of the alternative at JTeam and see which ones are suitable for our practice. I’ll report some more of my findings later on.

In the meantime, if you have experiences in this area, you’re obviously more than welcome to share them here .