In one of my recent discussions on IIBA group in LinkedIn, related to whether BA's should be involved in estimation, a point came up about when does an estimate become a commitment for an organization. Thanks David Owens for participating in that discussion and raising a question that inspired this post!
I have observed all extremes in committing to estimates, specially in the world of outsourced software development. Estimate commitments range from a ballpark to an estimate being given only after preparing detailed System Requirements Specification (SRS) and screen designs.
Ballpark is dangerous.... I don't think I need to say anything beyond that :) anybody who has been in IT business long enough would have faced the scare of ballpark.
Not committing to an estimate till detailed SRS and screen designs are done is also not the right approach - it is unfair to a client who genuinely wants a figure for budgeting. It is understandable if a client says "I don't want to invest in defining requirements unless I know what entire project could cost".... that is a valid concern, specially if it is a new client not aware of how your BAs go about the process of requirements elicitation. What if, at the end of it, you put forth an estimate that client cannot afford?
So what is the right time to commit to an estimate? The cone of uncertainty provides the answer, and I particularly like Construx's interpretation of the cone of uncertainty. As its cone of uncertainty poster says, the right time to commit to an estimate is when detailed technical requirements are complete, and possibility of estimate variation is within 20-25%. I call it a Scoping Exercise - a scope that is unambiguous and close ended (it is explicitly agreed what is not included in scope). Opinions may vary about what is unambiguous and within 20-25% of estimate variation range, I will share mine in a separate post!
As business analysts, we need to -
- make it a point that we define a scope first (breadth of requirements) and do a deep dive after scope is agreed
- be pragmatic about extent of detail we go into when thinking of scope - any degree of lopsidedness can be harmful
- convince stakeholders that scoping exercise is necessary
- negotiate a reasonable timebox with stakeholders for completing the scoping exercise to limit the cost and time of such effort
- obtain stakeholders' commitment to timebox for scoping
Since a picture is worth a thousand words, let me portray this on the cone of uncertainty -
If we successfully do the above, I believe we get the right start in process of estimation and avoid making it a black art.
