You are here

Close
Do you like what you are reading? Do you want to receive more content like this, in your inbox?
I send out articles just like this to my newsletter about once per week. Subscribe now:
* indicates required
Close
Do you like what you are reading? Do you know people who might be interested too?

Share This Page:

We Need Estimates for Our Customers

This is the third article in the mini-series "Why Do We Need Those Estimates".
Never miss one of my articles: Readers of my newsletter get my articles before anybody else. Subscribe here!

The reasoning goes like this: "Our customer only hires us on fixed price. We need detailed estimates to calculate that price, so we can even enter the bidding process". Of course, there are variations to this reasoning. But the bottom line always is: We need estimates for our customer.

In this article I first want to discuss fixed price projects, and then move on to other ways for running a project. Then we'll look at how estimates fit into this picture, and what kinds of estimates are useful and what kinds are not.

The Problem With Fixed Price

There are some customers who only want to hire you for a fixed price. This even happens within companies: The software development department has to quote a price to the specialist department (the "internal customer"). Based on that, they agree on a budget for the requested features and sign a contract. The software development department basically has to deliver a fixed price project within the same company.

Customers often argue that they need the predictability of a fixed price project. Sure, they might end up paying a bit more than necessary, but they have to know when they get what exact feature set for which price.

Here's the problem: A fixed price project harms everyone involved.

  • Since the developers have to deliver within the allocated budget, they have to pad their estimates heavily. The customer potentially pays much more than they'd need to.
  • There is a huge amount of risk involved for you, the supplier. If the customer does not accept the software, and it was your fault, you don't get any money until you have fixed all the problems. You might be bankrupt by that time.
  • If the customer does not accept the software, and it is their fault, you still don't get any money. You have to get a lawyer and drag them to the courts. Suppose you will win (because it was clearly the customer's fault) - You still might be bankrupt by then.
  • There is no predictability for the customer. Well, the price is fixed, but the project might still be delayed. The supplier might even not be able to finish it at all. Or they might ship a very low quality product. Sure, the customer won't have to pay for it when they don't get it within acceptable quality, but when the need the software, that does not help them.
  • To make fixed price work, you have to freeze the requirements at the start or have a very rigorous change management process. Remember, 27% of your requirements will change within a year! So, if your fixed price project runs for longer than approximately 6 months, you, as a customer, will get outdated software at the end.
  • Because of the fixed requirements, the developers are constrained to a specific solution. If they discover a better or cheaper way of doing things as they go, they cannot implement it.

There are customers who will only hire you for fixed price projects. But do you really want to work with them?

Is Your Customer More Flexible Than You Think?

If you want to find better ways to work together with your customers - whether they are "internal customers" or other companies / individual - You'll have to ask them. And you'll have to work out the better way together with them.

Only like this you can convince them that the way is actually better - That they will save money and/or time. And that they will still have predictability - but maybe in a somewhat different way.

From Fixed Price To Fixed Budget

As a first step, go from a fixed price to a fixed budget. The agreed budget is the maximum amount of money that the "project" will cost. But the feature set is not yet defined. In fact, the feature set of the project will only be known after the fact - When you deliver the software.

Then, work together with your customer to maximize the value they get for their money. Show them intermediate results (Working Software!) early and often. Have an ongoing communication about which features are most important and how those features should work like for the users. You'll need a strong Product Owner in your team to guide the customer and make sure that they work towards a greater vision - And not lose themselves in details.

Allow the customer to stop the project at any time, whenever they are satisfied - Then they will get the software that is ready at this exact moment. Your customer can potentially get the software cheaper than originally planned when you do it like that. You have to be able to deliver the software at a moment's notice, so you really have to care about "potentially ship-able software".

Reducing Risks (For Both Parties)

The above suggestions pose a couple of risks to both parties - you and the customer. You might run out of work when the customer stops the project early. The customer gains a lot of flexibility, but loses most predictability - And many customers care more about predictability.

What can we do to reduce those risks?

  • Incremental Funding: Split the "project" into a series of very short cycles, where you only fund the next cycle if you are satisfied with the current. For example, start with a 4 weeks project to create a prototype, and after 2 weeks you'll decide whether you'll fund the next stage. This next stage could be an 8 weeks project to implement the most important features.
  • The first sprint is free: Allow your customers to see some results without paying anything. For the first 1, 2 or 4 weeks of the project, agree with the customer that they only have to pay them when they want to continue the project. Also agree that they can only use the results of your work when they continue the project.
  • SLAs / Retainers: Guarantee to your customers that you'll have capacity to provide a minimum number of developer days per month for them. They will have to pay for those days, even if they don't need them. For example, your customer pays for 20 developer days per month for the next 6 months (maybe at a reduced rate), and you guarantee that your developers will be available for at least those 20 days, even if you have other projects.
  • "Money For Nothing": Say you are on a 6 months project with 5 developers. The total budget is 500000 Euros. The customer is happy with your solution after three months and cancels the project. This is a huge risk for you, since you need a new project right now. How can you mitigate that risk? Well, you can agree with your customer to split the remaining budget (e.g. 40% - 60%) when they cancel early. Your customer pays 350000 Euros (250000 plus 40% of the remaining 250000). You won some time to find new projects, and they still get the software cheaper than planned.
  • Continuous Delivery: As I already said, you always have to be able to deliver to pull this off. The easiest way to achieve this is to always deliver. Deliver working software to your customer as frequently as possible - Strive for multiple times per day.

Estimates and Experiments

So, how do estimates fit into this picture? Maybe you want to stop estimating altogether and always deliver in very short, incrementally funded cycles. That might work, but you probably don't want to do it. I guess most companies and teams want at least some predictability when it comes to their income or the price they'll pay for some software.

You should give indirect, abstract, coarse-grained estimates a try. I have worked with several teams where story points or average cycle times worked very well for them. They need some "calibration time" before you get some predictability, but this is O.K. - You can start to work with the numbers very early, and just know that your predictions will get more accurate as you collect more data.

But then you'll recognize that your predictions will never be really 100% accurate. Don't give in to the temptation to switch to direct, concrete, fine-grained estimates, like "hours to complete a task". They don't increase your predictability but only provide an illusion of accuracy. And they can lead to several kinds of bad behavior.

You should anyhow design your work in small, safe-to-fail experiments. Deliver something small, then get feedback. Then deliver something small, get feedback. Then deliver something small... This is your best chance to increase predictability of the desired outcome - The satisfaction of your users. Even if the delivered feature set is completely different from the original requirements.

And Now?

What if you are in a situation that is the exact opposite of where you want to be right now? Like, you negotiate development budgets for multiple-month projects long before you write the first line of code. Requirements are defined in detail even before the budget negotiations. You have to get the estimates right, because your customers always ready to switch to a cheaper supplier, so your margins are low. Where do you start?

The cop-out answer (a.k.a "consultant answer") is "it depends". Of course it depends on your exact situation, but you have to break the cycle at some point. And you have to do so in a rather safe way, so you probably want to take a small step.

Ask yourself: What is the smallest step in the right direction you could take? Can you move budget negotiations closer to the project start (only days or weeks and not months before you write the first line of code)? Can you replace one of the detailed requirements with a high-level goal? Can you agree with your customer to split a one year project into two 6 months projects? Can you make a small part of some of the requirements "optional" (so you can move a little bit into the direction of "fixed budget")? What can you do to become a "high-value supplier" or "strategic partner" for you customer, so you don't have to compete on price?

Those are small steps that don't really solve your problems, but they are steps in the right direction. And if you use them to build up trust with your customers and users, they might allow you to take a bigger step next time you ask...

Now I'm interested in your situation... Where does your team or project stand right now with regards to estimates and project budgets? What are your problems? What are some first steps you could take? Where can I help you? Please tell me!

You might also be interested in:

My name is David Tanzer and I have been working as an independent software consultant since 2006. I help my clients to develop software right and to develop the right software by providing training, coaching and consultanting for teams and individuals.

Learn more...