Process of Effort Estimate for Managers
In this blog, I will talk about the process to be followed for estimating efforts for software development.
Many first time managers struggle to create a holistic estimate of the efforts that is needed for developing a software module.
The reason for this is mainly due to not adopting the process of estimating the effort.
The basic estimation technique is called as Three-Point estimation.
In this technique the estimation of effort is carried out for 3 cases or scenarios.
1. Optimistic or best case (O)
2. Pessimistic or worst case (P)
3. Most likely or accurate case (M)Then, Final Estimate (E) = (O + P + M) / 3
In this blog, I will talk about the process of estimation, that will help you to properly estimate and helps to set the right expectation early on.
Estimation Process
Estimating any work is a process in itself, which managers must follow. It is not just opening an excel sheet and writing random numbers.
In my opinion, estimation has 3 main steps.
1. Selecting the right estimation strategy
2. Identifying the assumptions
3. Identifying the risks
Without the above steps, your estimation is not complete. Let’s look at each step in more detail.
▸ Select estimation strategy
I have summarised the commonly used strategies below.
- WBS (Work Breakdown Structure)
✶ Used in iterative or waterfall model of development.
✶ The entire work is broken down to the most granular level task.
✶ The estimate is provided for each granular level task.
✶ Low level design might be needed before estimating. - FBS (Functional Breakdown Structure)
✶ Used in iterative or waterfall model of development.
✶ The entire work is broken down to functional blocks
✶ The estimate is provided for each functional block.
✶ High level design might be needed before estimating. - Planning Poker
✶ Used in Agile model of development.
✶ Project managers assign multiple estimated values for each card
✶ The team votes for the value for each card.
✶ The team selects the value with the most votes. - T-Shirt sizing
✶ Used in Agile model of development.
✶ For each card, a sizing will be either small, medium, large or x-large.
✶ Based on scope team members will select the t-shirt size. - Dot Voting or Story pointing
✶ Used in Agile model of development.
✶ The method prefers prioritisation over estimation.
✶ For each card, team decides the priority by voting for the points
✶ The highest story point cards are picked up first.
▸ Identification of assumptions
Irrespective of the estimation strategy, there will be always some assumptions that will be made.
It is always good practices to document these assumptions while estimating. So that during execution, if any of the assumptions becomes incorrect, you can immediately get to know the impact of it.
All the assumption should be documented and validated with stakeholders.
- Scope
What are your assumptions on scope? Examples, the interface between two module will remain the same; scope change will not be more than 10%. - Technical
What are your assumptions on technical aspects of the work? Examples, the technology assumptions, what framework will be used, whether any support from other teams are needed, assumptions on infrastructure. - Estimation
What are your assumptions on estimation? Examples, did you estimate keeping a senior resource in mind or junior resources; how much buffer is added to the estimate.
The documented assumptions on the above areas, will give you an opportunity to set the right expectation with the stakeholders and get the necessary feedback earlier on.
▸ Identifying risks
Any work will have risks, so documenting it will give an idea of the impact that each risk can make on the overall progress.
It is always good practice to identify probable risks earlier on. It will help you to be prepared and making all stakeholders aware of the risks.
The risks have to documented for three main areas.
- Scope
What are your risks with respect to scope? Examples, what happens when there is a change in scope of 10%? What happens when the understanding of scope changes? What happens when additional scope will come? and so on. - Technical
What are your risks with respect to technical or implementation? Examples, what happens when the current framework will not be suitable? What happens when the requested infrastructure is not available on time? What happens when the design becomes complicated than it was anticipated? - Estimation
What are your risks with respect to estimation? Examples, what is the impact on estimation when the scope changes? What happens when design becomes complex?
By documenting the impact on estimation will help to assess the cost impact and in-turn profits and margins early on.
Final Thoughts
As a manager, do not make effort estimation for name sake. At least use the basic strategy mentioned at the start of the blog to make better judgement on estimations.
By applying estimation process, you can set the right expectation with all the stakeholders.
As you gain experience in running projects, always retrospect on how estimation impacted, what assumptions and risks should be added for newer projects.
As you gain experience with the estimation processes, try to add your own steps to make it more reliable and trust worthy.
The objective of using the estimation process should be that the estimation should not be “gut feel” nor “wishful”, it should be very close to actuals.
Happy management!
