Outware Insights

Browse by category

Introduction

For Project Managers, estimation is a necessity, whether we like it or not. Often we need to estimate with little or no information, and this ambiguity can make it challenging to estimate accurately. The variability of an estimate is highly correlated to ambiguity. The higher the ambiguity, the higher the variability, and vice versa. In this post I will outline examples of ambiguity at different project stages, and some estimation techniques to consider.

Ambiguity at different project stages

Ambiguity is part and parcel of everything in life, and projects are equally (if not more) prone to ambiguity. The chart below gives a picture of the ambiguity associated with various stages of the project.

estimation ambiguity

Some examples of ambiguities associated with various project stages are:

  • Project goals and objectives are defined at a very high level
    • Requirements may not be in place at this stage
    • Build versus Buy” decisions have not been made
  • Requirements exist, BUT
    • Not all requirements have been outlined
    • Requirements are not sufficiently detailed
    • Exception scenarios may not be outlined
  • Design in place, BUT
    • Sequence diagrams are not in place
    • System boundaries are not outlined
    • System interface definitions are not available
    • Technology unknowns are not yet addressed 

We can easily understand that variability of estimates will be high early on, and variability progressively reduces as uncertainty decreases. Estimating during early stages can be tough but is necessary. Estimates may be required for project return on investments to make “Go – No Go” decisions. If the project is given the go ahead, estimates may be used for budget allocations during financial planning.

Estimation types to consider

So, what do we do when we are asked to estimate at very early stages? (NB: The following assumes some budget and time is available so that we can go beyond plucking numbers out of thin air).

Analogous estimating may be a good technique to start with if the organisation is keeping track of effort and cost on tasks and deliverables. So how do we determine what qualifies as a similar project? Projects as a whole may or may not be similar, but by breaking down the project into tasks and deliverables, we have a higher chance of finding similar tasks and deliverables in the historical data. We can then tweak this information to reflect differences between the past and the present.

We should be able to refine initial estimates by investing more time and budget. A bit of elaboration goes a long way to flesh out some of the concepts. Elaboration can take the form of preparing wireframes (even pictures drawn on whiteboards are good), listing the interfaces that will be exposed by different components, or a system architecture diagram (with new components, changed components, unchanged components). 

We can organise for some experts from different teams to come together for an estimation session. We need to ensure representation from different teams such as solution architecture, UX, BA, and developers from different areas. We can start by presenting what has already been fleshed out, and get the team to ask questions, come up with different ideas, and list assumptions being made. Finally, get the team to estimate using different techniques, such as “Expert Judgement”, “T-Shirt Estimation”, and “3-Point Estimation”.  

Set Expectations

Once the estimates are in place, we need to set the right expectations when we present the estimates to stakeholders. Estimates can range from “Rough order of magnitude (+75% to – 25%)” to “Definitive Estimates (+10% to -5%)”.  It is very important to communicate this to stakeholders so that they are aware of this and factor it in for any actions planned based on the estimate.

In conclusion

Early on estimates are difficult to get done and will always be off, despite of our best efforts. As project managers, we need to ensure that our project team feels secure sharing estimates even when ambiguity exists. The team will need to make assumptions to move forward. Last but not the least agile delivery methods are designed to achieve best possible results using the given amount of time and cost. 

That’s all for this post. Let me know your thoughts.

Recent Articles