In a recent post I wrote about a not-too-uncommon scenario in which a customer wants a fixed price software project to be delivered, but is still trying to figure out all those pesky details and then I asked the question on wether you would take the project on or not?  Even if it meant turning down a massive potential upside for your business and therefore, for you.

Now for those who know me, they'd know the answer would be a flat out "No!". Even if the end goal is clear, the steps needed to get there hardly ever are and, just like death and taxes, it's a guarantee that something will change and that some tasks in the project will be a lot quicker than expected while others will take a lot, lot longer.  The nature of tasks is that you can never get more than a 100% improvement on a single item (ie when it doesn't need to be done) and yet it's quite common to have tasks that blowout by much more than 100%.  This simple fact combined with changes in requirements is why most software projects run late and over budget.

Now it's easy to say we should face up to reality and admit that this will happen.  Heck, let's expect it to happen and change our practices accordingly.  Let's start using an agile process like Scrum, XP or Crystal Clear.  Let's get our teams thinking about things differently, get them involved earlier in the process and have us working towards a solution instead of blindly following a someone else's myopic plan towards certain failure and a likely death march project.  It's what I would recommend 10 times out of 10.  You're not guaranteed success using agile, but the chances of succeeding and having a happy customer are so much better using agile than with any traditional development methodology.

And then the "other reality" sinks in.  The world is run by accountants.  Most CEO's come from a finance background, they have profit as their primary goal (not successful projects), their #1 confidant is usually the CFO, their sales people are given financial targets, their project managers are told to minimize costs, the customers don't want to spend more than they have to and in these days when we all have to legally cover our collective asses the accountants want us to wrap up all business dealings in a contract so that when things don't go according to plan we can have a way to apportion blame appropriately and get the money we want.

It's this "other reality" that means that fixed price, fixed duration contracts are the norm.  It's this other reality that makes the introduction of agile processes so hard and why it's so hard to keep them in place.  Agility is about cooperation; "reality" is about combat.

A while back I did a few weeks of sub-contracted technical work for a large firm who had taken on a fixed price project.  The project was doomed to failure from the start and the scary thing is that they knew it and yet they still took it on!  Why?  Because of the revenue involved (yes, that "other reality" again).  What the customer wanted and the time and budget they had just didn't match up but the money was good.  The firm figured that they'd do what they could within the strict terms of the initial contract and then pick up extra time through massive overestimation on change requests.

What an awful way of doing a project.  Yet this attitude is rife within the industry. No wonder the software industry is seen as largely being run by snake-oil merchants and used car salesmen.

 

If fixed price contracts are the way businesses want to operate what can we do?  Udi has an interesting take on it, but I'd rather try something that's a little less grey.

I'd rather try and be different from the start.  Get a reputation for openness and honesty.

I think it's still possible to do fixed price work but instead of going for one single massive up front bid I'd rather apply agile's iterative approach to the proposal.  I'd like to suggest something like the following with timeboxing as appropriate:

1. Project Induction & Training Session

An explanation of why things are different and how it's an improvement on the past.  This is the most critical aspect.  You need to change peoples mind sets.  You want to get the customer involved, you want to establish trust, you want buy in and visibility with senior management, you want the end users (who usually have no voice) to speak and you want to prepare the customer for a new way of working.

When organisations are used to throwing an RFP (typically prepared by a large business consulting firm) over the fence and hoping to magically get a result some time down the track, then using an agile approach is going to be extremely foreign and potentially unnerving for them.

You can explain the iron triangle, talk about the massive number of failed projects in the industry, talk about agile bringing about a change for the good, and you can explain how sprints/iterations work and how the delivery of the solution will happen. You can answer the "what-if" questions over scope management, blame allocation, costing overruns, trust, mistrust and non-trust and the other myriad questions that come up, but until the customer sees it in action they still won't really "get it".

This is why the next 2 steps are also important.  It's when the customer can and experience agile for themselves.

2. Create a Product Backlog

Get in with the customer and spend the time to understand their requirements in more detail.  Do workshops, watch them work, feel their pain, listen to why they want what they are asking for, etc.  Do whatever you can to understand the requirements in more detail and get them thinking about their needs in a way they haven't before.

Once this is done, build up a project backlog.  Base it on the RFP, the workshops, conversations, etc and get them to prioritise items using whatever method you find appropriate.  Explain to them that it's their backlog and they own it.

3. Do Iteration/Sprint #1

Run the first iteration, try and target the high risk areas first.

Yes, this project may be similar to other projects you've done but no two projects are the same and no two projects have the same velocity.  You need to get at least one iteration under your belt to get a feel for what this project's velocity will be like.

You also need to do it to show the customer how agile delivery works in practice.  Once they've experienced it you'll be able to answer any further questions that arise and you'll hopefully have even more buy in from the customer.

Also, the cost of a single iteration does not represent a large financial commitment on the behalf of the customer.  If they don't like it, you shake hands and walk away.  If they do, you'll be much more likely to have a successful project and you'll probably have a customer that starts talking you up in the marketplace.

 

Price out these 3 steps and supply a fixed price quote for the work.  Agree to supply further pricing information after the first iteration is completed.

Now you need to take the velocity you've calculated, apply it to the product backlog and work out how long the project can be estimated to take and how much it might cost.  If this is beyond the customer's budget, then you have a great starting point to talk with them about scope reduction.

Regardless of how you finally structure the pricing, ensure that you keep the reasoning open and clear.  At the end of iteration #1 the customer should be able to work out the expected price before you give them the quote, because they can do the maths just as easily as you can.

 

P.S. For other peoples views on this subject have a look at:

Steve McConnell - Estimation of Outsourced Projects

Jeremy Miller - Trying to answer hard questions about Agile development.

Ayende - Fixed Bids, Agile Projects