HOW TO: The 8-Step SDLC Method of Estimating Development Effort Quickly & Accurately
2011-12-22 MV: Among the most vital components of any development project – any project at all for that matter – are The Estimates. Yet estimating continues to be poor at best, not the least of which is because typically The Chain of Command requires it… but they neither use accurate estimating techniques nor bother to teach them.
In a project-centric world where the estimates are demanded all down The Chain of Command, from the CxO to the VP to the Managing Director to the Practice Director to the Engagement Manager to the Project Manager to The Architect to The Developers, several things become clear:
- A single common, consistent method for estimating is superior to myriad inconsistent ones;
- This method must be intuitive, simple and fast;
- This method must be documentable, using whatever materials (e.g. SharePoint lists, workplans, spreadsheets, whiteboards or even pencil & paper) are available;
- This method must be logical and therefore defensible;
- This method must be scalable, effective on estimating The (smallest) Task all the way up to The (entire) Project.
Here then is a method which I’ve used and taught for years which has served me so well on all my projects. It can be used initially on something as impromptu as The PM asking The Developer (in a standup) “how long will that take?”, scaled up to MS Word tables, then to MS Excel spreadsheets, then to MS Project Workplans, and finally even to my beloved MS SharePoint, where what look like simplistic lists are in fact very powerful, siftable, pivotable, aggregate-able tools from which myriad such lists each living on individual project websites can be near-instantly transformed into a large-but-intuitive Project Dashboards for use by The PMs, which in turn can feed into Program Dashboards for use by The Program Manager, which in turn can feed into Department Dashboards for use by Department Managers, which in turn can feed into Corporate Dashboards for use by The CxO.
But you can see it al begins with The Developers, and it must be SO very easy & obvious that they adopt it.
Surprisingly, it’s roots are in the traditional Software Development Life Cycle (SDLC), which in my opinion is part of what makes it intuitive, and therefore memorable.
The SDLC traditionally divides The Project up into several solution-centric phases:
- Situation Analysis
- Business Needs Assessment
- Requirements Definition
- Solution Design
- Solution Prototyping
- Solution Construction
- Solution Testing
- Solution Deployment
Interestingly, these phases ARE in fact quite scalable, and are the very core of this the SDLC estimating technique.
Here’s how it works on a single task:
The PM barks out “”How long is that gong to take?”, and then waits for an immediate-but-100%-accurate estimate right on the spot;
The Developer walks up to the whiteboard, recalls the 8 steps of the SDLC, clearly states The Deliverable, then sketches out the following letters to start The Estimate:
DELIVERABLE: DailySalesImport() Method
The Developer then OUT-LOUD walks The Team through his though process, encouraging observation & interaction in the next step, which is to address a RANGE (never a single number) of values – say in hours, the most common currency of estimating.
The Estimate now looks like this:
DELIVERABLE: DailySalesImport() Method
- A .25 – 1.0
- N 0 – .5
- R .25 – 1.0
- D .25 – .5
- P .5 – 1.0
- C .5 – 1.0
- T .5 – .5
- D 0 – .5
Total: 2.25 – 6.0
There are several things to note:
- This estimate was completed in the time it took to jot down the numbers – it is NOT a “slow” method in any sense of the word;
- Estimating this way forces The Developer to actually think through every that’s really going to happen;
- Everyone in the room sees the thought process, and is actively engaged in The Estimate;
- The range between low & high communicates very effectively the level of confidence & understanding of The Deliverable;
- The smallest unit of measure in estimating 15 minutes;
- It is perfectly ok to put “0” if a phase is either unnecessary or completely known;
- The PM will ever & always only look at the SMALLEST estimate, yet The Wise PM will pay attention to The Range of The Estimate in determining The Risk;
- Everyone in the room can at this point weigh-in on each “phaselet” of The Estimate, until all feel it is accurate.
Pretty darn simple… yet powerful.
And scalable – let’s now estimate an larger “module”, by simply putting everything into a spreadsheet:
(note cool use of Conditional Formatting to color-code high estimates)
And still more scalable – let’s see this in a workplan:
[[INSERT project workplan here]]
And ultimately most scalable – here is the same technique in a SharePoint List:
The proposed 8-Step Estimating Method is based on the SDLC. While 8 steps might seem like alot, in practice they are not; all developers are familiar with the SDLC, so each phase comes to mind quite naturally & readily. This familiarity is what makes this so very powerful – it possesses inherent credibility, far superior credibility than standing there with a dumb look when asked “how long will this take?”, and then blurting out a single seemingly snatched-out-of-thin-air … a “SWAG” I think it’s called.
Give this method a try, but use it at ALL levels, and teach EVERYONE on the team to use this same technique when asked to estimate anything – and I do mean EVERYTHING related to The Project.