During the month of January, ProjectManagement.com will focus on PM Technical Skills.
One area that a lot of Project Management Professionals struggle with is estimation of Time/Cost/Budgeting. For this month's Hot Topic, I'd love to hear what is your top tip for how you estimate in your projects (this could be for any area: Time/Cost/Budget).
My tip is to look towards your SMEs for effort estimations so that you work with them on realistic estimates and not just on your best guess. My team will be able to tell me if something is realistic or if i'm being overly optimistic in my planning.
Let's share knowledge and maybe also say what hasn't worked for you? Saving Changes...
What many folks tend to forget is that an estimate is an educated guess and while the fidelity of that guess might improve as we get closer to completing work, it will never be 100% accurate until the work is done!
The updated PMI estimating Practice Standard does a good job of reviewing key estimating principles and techniques so what I'd share is:
1. Combine estimation methods where possible to be able to sanity check them
2. Favor multi-point over single-point estimates
3. Remember bias
That's a great point! The updated standard gives some great advice for us.
I make a point of explaining the come of uncertainty to my stakeholders as there's a lot of people who struggle to take estimates for what they are.
Are there any estimate tooling which you favour in your projects?
Unless we are dealing with highly predictive contexts or have lots of historical data to go on, I prefer relative sizing over real-world estimation. Saving Changes...
Hi Vincent, breaking down the work into smaller packages is a great piece of advice.
How would you handle a client that does not like the relative sizing? Have you been successful in convincing them?
...
1 reply by Vincent Guerard
Jan 28, 2020 3:34 PM
Vincent Guerard
...
Why the client? That is the way internally I have done in IT and construction and seen others do.
With Agile and iterative release, you break it down. The client may not like a too-small package, present them regroup to a size they could accept.
Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
We use relative sizing to determine how much work the team can deliver in a given sprint. The prioritized work is aligned on and sized in focused sessions with the team.
This can then validate our longer-term deliverables in the release plan based on the cadence at which the team can deliver.
Our approach is to abstract time as much as possible to avoid unnecessary noise and constraints. Instead, along with relative sizing, we'll use a Now, Next, Future approach for the roadmap. This allows for better maneuverability in adapting to unknowns or feedback. Saving Changes...
Hi Vincent, breaking down the work into smaller packages is a great piece of advice.
How would you handle a client that does not like the relative sizing? Have you been successful in convincing them?
Why the client? That is the way internally I have done in IT and construction and seen others do.
With Agile and iterative release, you break it down. The client may not like a too-small package, present them regroup to a size they could accept. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
"Interestingly, according to modern astronomers, space is finite. This is a very comforting thought--particularly for people who can never remember where they have left things."
