Time and Material Projects

Last time I’ve written about fixed price projects, and was quite negative regarding them. In this article I’ll look at another type – the time and material project. Here the client is invoiced regularly for the hours and expenses for the development.

You’ll spot a problem with it right away – the provider will have an incentive to make the project as long and as costly as possible, as that guarantees more revenue.
Another negative aspect for the customer – you keep paying your invoices every month, but that doesn’t mean you also have a software you can use, nor that you ever will. At some point you may decide the project is no longer feasible, but the money is already spent. So all you’re left with is a big hole in your budget. At least with a fixed price project, the provider has the contractual obligation to deliver something, at a defined deadline.

As to the advantages for the client, you have more flexibility with regards to the scope, as you are not tied to a rigid contract. You can change your mind, re-prioritize the features and add or drop features without all the hassle of a fixed scope.

Of the two described methods, as the provider, I prefer time and material. It is crucial though, to have a good, trust-based relationship with the customer. How do you achieve that? Through previous projects, but that’s a chicken and egg problem. Communication and transparency are vital here, and using an iterative/agile project methodology helps a lot in that regard.

The client needs to be able to see what has been done, what is being done, and how much is there left to do. What are the risks, what are the challenges, what will we implement in the next sprint/iteration? The customers needs to be a central part of that. You think a task will go over budget? Communicate that as early as possible, don’t just hope it’ll even out. All this goes towards building a trust relationship with your customer. Which means your project will have a much greater chance of succeeding.

Fixed price software projects

At my workplace we have quite a few fixed-price projects. Projects involving the government, local administration or official institutions are just about always like this.

Now, to be clear from the start, I’m not a big fan of this kind of projects. Why? Because I think they are fundamentally flawed. They have you (as the provider) and the client pulling in opposite directions from the very beginning.

It already starts when you submit your offer. You have to offer a competitive price. So you’ll offer the very minimum that covers the requirements of the client. If you don’t, and try to think of a fancy solution, you’ll be too expensive, and won’t win the project.

Once the project starts, it’s just a matter of time until the first “In Scope or Change Request” discussion with the customer. For them, everything is part of the agreed scope, so they don’t need to pay. You’ll need to push in the opposite direction. You can’t just play nice and do every change they request for free, cause you’ll lose money.

Sometimes you’ll have a great idea on how to implement a feature in a nicer/more maintainable/more user-friendly way, but it’ll cost more. How do you bring this idea to the customer, especially if they are very strict on sticking to the budget, or are very tough negotiators when it comes to project scope? You risk another of the discussions I’ve mentioned above.

That’s not all. End-to-end, same project, same scope will be more expensive with a fixed price model. The risk is higher for the provider, so you’ll calculate a higher margin, to make up for that risk. Of course there is also the risk that you grossly underestimated, and will have to pay out of your pocket to get the project done.

So why are they used so much? Well, it’s only natural to want to know what something will cost you, before you buy it. If you go to the shops, you’ll look at the price before putting the item in your shopping cart. If you want to build a house, you’ll want to know if you can afford it. Same goes for software projects. But there’s a catch. Software projects are very dynamic. You may agree on a scope and a price, and 1 year later, when the project is finished, end up with something that doesn’t match your needs any more. So you’ll have kept the project within budget, but ended up with something you can’t use.

In the end, what a fixed price guarantees, is that the customer will spend the agreed price, and get some software in return. Which may or may not match what they actually wanted.

Unfortunately the rules in the public sector won’t change soon, so these projects are a kind of  necessary evil, that we’ll keep encountering for a long time.