Connect@OnGraph

Try doing this little interesting exercise in a group when you are looking for some fun. Estimate how long would it take to visit all tourist spots in London. Assume that everyone has enough money and only public transport is allowed. Take 2 minutes for estimation and 10 minutes for discussion in the group to revise your individual estimates.

You can do this exercise and come back later to read this further :-), but I can tell you the result right away.

If you are 5 people in the group, you will get 5 different answers! If you ask 1 person to estimate the same task at 5 different times, you will get 5 different answers. Interesting, isnt it?

Well, lets accept it. Estimation is a hard exercise and if you master it, its one real skill. Good estimation results in better decision making and effective planning. Bad estimation results in poor planning and project failures.

Here at OnGraph, we follow a proven defined process for estimation of projects, in order to give an accurate and upfront picture to our clients, for better planning and execution at the technology level and downstream business level.

In this post, I am trying to summarize our practices and cover what actually does an estimate mean, different components of an estimate, different types of estimates, root causes of poor estimation. Part 2 of this post would cover various stanard estimation tools and practices, how to prepare an estimate and how to use those estimates effectively.

What Should Your Estimate Look Like

- For software industry, there are 2 types really.

Duration estimate - how much time would it take to build this software application
Effort or Cost estimate - how many $$ need to be spent to build this software application

- Your estimate should NOT a number. It should be a range of numbers with a probabilistic factor associated

- Your estimate should always include estimation method employed

- Your estimate should always declare associated risks and assumptions

Classic Examples
- The Good : “Building this automated tool would take between 100 to 140 hours of coding, and 4 to 6 weeks of effort. This assumes that the class design and database schema is already frozen. The time/effort would shoot up if the requirements document is not completed 1 week before the development activity can start”. Wow, you got the job!

- The Bad : “Building this automated tool would take around 120 hours of coding and around 6 weeks of effort. There may be some minor slippage in the above estimate depending on how things go”. Hmmm, may be you should see us next time!

- The Ugly : “Building this automated tool would take 100 hours of coding and 4.2 weeks of effort. No problems, we will do it”. Ahem, do we know you? Who let you in?

Components Of Your Estimate
- Always give a range of numbers, that can bound your estimate

- If possible, attach a probability statement to indicate your confidence from statistics perspective

- Give a basis for your estimation, that can justify your figures

- Always mention the associated risks and assumptions to cover up for unknowns

Basis Of Estimation And Types Of Estimation
- Use your historical data, experience data or analysis data to prove the validity of your estimate

- Most of the times, your estimates would be based on data collected while doing similar effort or tasks

- Give a Rough Order of Magnitude (ROMEst) estimate when you are in scoping phase of a project. This should just be used to determine feasibility of the project

- Give a Budgetry Estimate (BEst) when you are in project initiation phase. This should be based on requirements and work breakdown structure for the project

- Give a Detailed estimate (DEst) prepared for each iterative cycle of development for a project. This should be based on complete approved requirements and micro level work break down structure for the project

- ROMEst is wider and least accurate, BEst is narrower and more accurate, DEst is narrowest and most accurate.

Benefits Of Good Estimation
- You gain predicatibility. You can see clealry whats coming in the project.

- You gain repeatibility. You know that you can only do better next time and not worse

- You gain credibility. Your clients are happy because you mostly deliver on time. Your organization is happy because you always do right planning

- You gain strong position to drive results since you know what is going to be delivered when

- You gain a better decision making power. That helps you in almost every sphere of life.

Causes Of Poor Estimation
- We fail to follow a proven and defined process. We know the process but we get lazy in following the process

- We suffer due to lack of requirements or ambigous requirements

- We fail to bring the assumptions and risks upfront

- We fail to manage sufficient resources and sufficient time

- We fail to take hidden factors into consideration, like ramp-up time, learning curves, skill development, productive time.

Summary
- Your estimate should not be a mere number

- Your estimate should be a probability statement

- Your estimate should be made more objective rather than subjective

- Your estimate should be made more consistent and easier to understand

- A good estimate is possible only by follwing a process consistently and using your own historical data

Tags: best practices

This entry was posted on Tuesday, April 22nd, 2008 at 8:20 pm and is filed under OnGraph Best Practices. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.