-
Project Management Foundations - Understanding the Maturity of Your Project Office
May 20, 2013
-
Why Are Companies “Good” but Very Rarely “Great” at Project Management?
May 19, 2013
-
Project Management Institute’s 2013 “Pulse of the Profession” Survey
May 18, 2013
-
Personal Time and Project Management Tips From America’s Top Universities
May 17, 2013
-
5 Things To Do On Your Small Project
May 17, 2013
-
The 7 Project Manager Personalities: Which One Are You?
May 16, 2013
-
Project Management - Organizational Influences
May 16, 2013
-
The Inconsistency of Agile
May 15, 2013
-
PMP Certification Mindset and the Training Dilemma
May 14, 2013
-
Chromatophobia - Fear of Project Status Reports
May 13, 2013
Top 10 Estimation Best Practices
February 21, 2008 | Author: PM Hut | Filed under: Activity Duration Estimate, Agile Project Management, Cost Estimating, Cost Management, Time Management
Top 10 Estimation Best Practices - Managing Expectations via Ranges (#4 in the series Agile Estimation)
By Mike Griffiths
I have written a few posts now on estimation and so I thought it was time for a summary. Also, I am planning to create a series of one page best practice summaries / cheat-sheets for agile and this seemed like a good candidate.
(I am a real fan of one-pagers; there is special value in getting everything visible and presented on one page that brings unique scope comprehension and clarity. Toyota and other lean organizations make heavy use of A3 reports, a one page summary of an issue, its root causes, countermeasures, and verification steps to summarize problems and planned solutions - they are powerful tools.
Incidentally, when I first started work I had a wise and cantankerous project manager who was full of oxymoronic proverbs. One I remember was “If you cannot summarize it on only one page, you need to go off and learn more about it!” An astute paradox.)
Anyway, here’s the summary; if you want more explanation on any of the points, refer to my previous posts (Upfront Estimates, Estimation Techniques, Estimate Ranges) on agile estimation.
Top 10 Estimation Best Practices
1. Use more than one person – By engaging the team in the estimation process we gain the benefits of additional insights and consensus building. Additional people bring different perspectives to estimating and spot things individuals may miss. Also, the involvement in the process generates better consensus and commitment for the estimates being produced.
2. Use more than one approach – Just as one person is likely to miss perspectives of estimating so too are single approaches. Use multiple estimation approaches (comparison to similar projects, bottom up, user story points, etc) and look for convergence between multiple approaches to reinforce likely estimate ranges.
3. Agree on what “It” and “Done” means – make sure everyone is estimating in the same units (e.g. ideal days), have the same assumptions, and are based on standard developer ability/effort. When asking for estimates spell out what you are asking them to estimate. What does “Done” include? Coded, unit tested? How about integrated and system tested? What about refactoring contingencies? User meeting time?
4. Know when to stop – estimating an inherently unpredictable process (custom software development with evolving requirements) will never be an exact science. Balance enough effort against the diminishing returns and false accuracies of over analysis. Look for broad consensus between team members at a course grained level and then move on. It is better to save estimation time for periodic updates than over analyze.
5. Present estimates as a range – We call them “estimates” not “predictions” because they have a measure of uncertainty associated with them. Manage the expectation of project stakeholders and present them as a range of values. E.G. Between $90,000 and $120,000
6. Defend / explain estimate range probabilities – If stakeholders automatically latch onto the low end of an estimate range explain the low probability of achieving this and steer them to a more likely value. If you organization persistently fails to understand, present a range of likely values (e.g. around the 50% to 97% probability range)
7. Don’t reserve estimating for when you know least about the project – Estimation should not be reserved for the beginning of projects. Instead done throughout as we learn more about the emerging true requirements and ability of the team to build and evaluate software.
8. Be aware of common estimation omissions – Consult lists of common estimating omissions (such as Capers Jones’) and ensure these items are taken into account. Look back at retrospective notes for things that did not go so well, and tasks that were missed or ran late – make sure we include enough time for these.
9. Embrace reality early – As the project progresses, it is tempting to think development will get faster and faster now all the technical problems have been overcome. However don’t under estimate the load of maintaining and refactoring a growing code based. Especially if the system is now live; support, maintenance, test harness updates, and refactoring can quickly erode the velocity improvements anticipated, so use the real velocity numbers.
10. Review, Revisit, Remove head from sand, Repeat – Our first estimates will likely be our worst. Don’t leave it there; review the project velocities to see how fast we are really going. Revisit the estimates armed with the real velocities to determine likely end dates. Embrace the reality you see, “The map is not the territory”, reprioritize and repeat the estimation process often to adapt and iterate to the most accurate estimates.
Mike Griffiths is an independent consultant specializing in effective project management. Mike was involved in the creation of DSDM in 1994 and has been using agile methods (Scrum, FDD, XP, DSDM) for the last 13 years. He serves on the board of the Agile Alliance and the Agile Project Leadership Network (APLN). He maintains a leadership and agile project management blog at http://www.LeadingAnswers.com
Related Articles
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.
- Agile Project Management
- Ask the Hut
- Certification
- Change Management
- Communications Management
- Computer Based Information Systems
- Concepts
- Corporate Transformation
- Cost Management
- Critical Chain Project Management
- Delegation
- History
- HR Management
- Implementing Project Management
- Integration Management
- Lessons Learned
- Management
- Miscellaneous
- People Issues
- PMBOK
- PRINCE2
- Procurement Management
- Program Management
- Project Lifecycle Phases
- Project Management Advantages
- Project Management Advantages
- Project Management as a Career
- Project Management Best Practices
- Project Management Charts
- Project Management Definitions
- Project Management Ethics
- Project Management for Beginners
- Project Management Guides
- Project Management Musings
- Project Management Office
- Project Management Proposals
- Project Management Templates
- Project Portfolio Management
- Project Workforce Management
- Quality Management
- Requirements Management
- Risk Management
- Scheduling
- Scope Management
- SCRUM
- Soft Management
- Time Management
- Training
- Uncategorized
1 person has left a comment
This is really useful for project estimation. Thanks.