Business Savvy Software

Your boss walks in and says, “Customer X is going to cancel their contract unless we can deliver xyz functionality. I have a meeting with them in 15 minutes – when can I tell them it will be ready?”

Never, never, never give an answer of the top of your head because it will immediately become gospel. The answer is, give me 15 minutes and then do the following (adapted from Steve McConnell’s “Software Estimation”)

1. Breakdown the project

If you create one estimate for the entire project, then your margin of error is going to be high. If you break the project into the smallest pieces possible in 15 mins, then you will still have a high MOE for each individual estimate, but with a large number of estimates, the MOEs will cancel each other out, giving a more accurate estimate.

Without a detailed design, you may need to break it down into:

1. How many use cases?
2. How many forms?
3. How many web pages?
4. How many features?
5. How many unit tests?
6. How many database tables?
7. How much graphical design?
8. How much user interaction design?
9. How much requirements/design/architecture?
10. How many business functions?
11. How many reports?

Write down a worst case and best case estimate for everything in your breakdown – ie 5 webforms x 1 day per form = 5 days. For worst case, think about if everything went wrong. For best case, think about if you could just sit down un-interruped and build it. Once you have these, think about the most likely case for each estimate – which should be somewhere between best and worst. You can then calculate the expected time using:

expected time = (best case + (4 x most likely case) + worst case) / 6

Add the expected times to give an overall estimate.

2. Understand the accuracy of your estimate

Cocomo II’s “Cone of Accuracy” says that an estimate can only become more accurate by making decisions and removing variables. Therefore, since you can’t define all the requirements, complete the UI design and architecture in 15 minutes, you need to understand the accuracy of giving an estimate based on a concept. If you already have the requirements and design, then you can give a more accurate estimate.

You estimate will only be as accurate as:

Initial Concept - anywhere from 0.25x to 4.0x your estimate
Approved Product Definition - anywhere from from 0.5x to 2.0x your estimate
Requirements Complete - anywhere from from 0.67x to 1.5x your estimate
User Interface Design Complete - anywhere from from 0.80x to 1.25x your estimate
Detailed Design Complete - anywhere from from 0.90x to 1.10x your estimate

For example, if you estimate that the feature will take 4 weeks, based on the concept only, then your accuracy is between 1 and 16 weeks. If you have completed the requirements, then your accuracy is between 2.68 and 6 weeks.

However, telling your boss it will take between 1 and 16 is most likely just to piss him off, so you need to take into account your past history of estimating and delivering projects and you might say 4-6 weeks, 6-8 weeks or 8-12 weeks depending on how accurate your estimates normally are.

3. Differentiate work from time

Maybe its going to take 4 weeks of work and you can assign two developers to it, but if they also have support & maintenance work and are finishing off other work, they may only have 1/3 of their time available to complete the work – so it will take 6 weeks to deliver.

4. Use the right precision

Most people corelate precision with accuracy, therefore if you say, “20.5 days”, they expect this to be accurate to +/- half a day. If you say “20 days” – they expect it to be accurate to +/- a couple of days. If you say “4 weeks” – they expect it to be accurate to +/- one week, etc. Make sure you deliver your estimate using a precision that matches your accuracy from step 1.

5. Understand the risk

So, you come back to your boss and say “Based on the concept – I estimate that it will take 6-8 weeks”. Of course, your boss immediately says – “I need it done in 4 weeks, because that’s when the customer’s next payment is due and I don’t want this delaying their payment”.

We now have an estimate of 6-8 weeks, which is from an expected time of 4 weeks, but based only on the concept – so has a real accuracy of between 1 and 16 weeks and your boss has just given you a business target of 4 weeks. A business target should never be confused with an estimate. Tell your boss that you will specify the requirements/design etc and determine how much you can deliver within 4 weeks – ie phase 1. The rest will have to wait until phase 2 & 3 etc. This way you mitigate the risk of having an estimated delivery time that is much higher than the business goal because the last thing you want to do is make a high-risk promise to a highly-volotile customer.

The larger the gap between the estimate and the business target – the higher the risk. Make your boss aware of this.

Part 2: Estimating a software product.