Coding is like gardening...

Billing with Integrity (part 2)

(You may want to read part one first).

We left off saying that fixed price projects had a number of disadvantages. One other problem with these types of projects is that they’re implicitly set up to pit client and supplier against each other. This wastes valuable project budget on working out what to do when the project changes.

Imagine a client and developer have come to an agreement and spent a lot of time writing the spec for a project. The contract is signed for a developer to deliver the spec for £4,000. Immediately we have two contrasting forces at work:

• The client is wanting the maximum amount of features that the developer will give him, so he gets the best return on investment.
• The developer is hoping to spend the minimum amount of time on the project to get the work done, so that he can cram as many projects in and make as much money as possible.

Good developers and good clients will mitigate these forces, but each party will always need to protect their interests to some extent, or they’ll go out of business.

There’s enough tension in the above relationship as it is. What happens when the client wants to add in another couple of features? The client might argue that the new features aren’t really new, but part of the original spec, so that he can try and get as much as he can for his money. The developer is likely to argue that everything that differs from his interpretation of the spec is new, and therefore should be charged for. The result is usually a fight, hopefully a compromise, but always a big waste of time and energy. Who wants to plough through a huge change process just because the original spec wasn’t clear enough? That time could be better spent actually delivering more features and providing more value to the client.

In practice, specs are never clear enough, and always require changing. Therefore at the beginning of the project you are committing to spending a fair amount of time arguing about the spec. If the change is a big one, then you’ve got a big problem: a lot of time has been spent already getting this spec “right”, and now it’ll need to be thrown away or rewritten significantly. There’s also more pressure to rush this new spec, which results in a worse spec the next time, causing more problems down the road.

The net result of all this is less efficient and more costly projects, bad feeling between clients and developers, and an overall reduction in the success of the project. Forget that ‘ongoing high quality relationship’ both sides wanted at the beginning: for serious failures often the only priority is to escape without a lawsuit.

It’s not all doom and gloom: some fixed-price projects do go as planned, but setting up projects in this way makes it all that much harder to see them through. I’m also not against specs: clearly it’s important for the client to communicate what they want! I’ll discuss how we use specs (although we call them something different) in a later post.

So take heart: there are more modern project management methodologies which ensure that there’s that much more chance that projects succeed and that everyone gets along. Next time we’ll look at some fundamental laws of software development in the search for a better way.

Tune in next time for the four variables of software development (you may want to subscribe for the latest updates). If you’re in a hurry for an “answer”, you could always peek at our pricing pages if you want to know how we bill :)

Posted on: Friday, January 16th, 2009 at 12:02 pm In category: business. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.