Selling Agile Projects Part I – Setting the Stage

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 :-).