Occasionally the question comes up as to who should estimate tasks and who should create the work breakdown structure (WBS) for a project. Should the technical lead estimate the tasks for the developer? Should the developer estimate their own tasks? And if either the task estimation or the WBS creation take more than one person to do, doesn’t it get expensive to do all that planning? Two principles from my studies in prepping for the Project Management Profession (PMP) exam immediately come to mind (both from Rita Mulcahy’s excellent study guides):
- Estimating should be done by the person doing the work whenever possible, and,
- The project plan, for which the WBS is one element, should follow the BARF principle.
BARF stands for: <ul”> </ul”>
- Bought into
- Approved
- Realistic
- Forma
For the WBS to be bought into and realistic, it must be created with the help of the team. Of course, there are always exceptions. Perhaps you don’t yet have all the people who will be doing the work staffed on your project or even know who they are. But when questions like this come up it’s good to know there are at least generally accepted best practices for guidance. And if you cut corners, don’t be surprised if down the road you find yourself wishing you spent a bit more time on the planning phase of your project.
Estimating Your Next Solution
Have questions? You can contact my team directly for more insights.
This sounds reasonable and thanks for introducing the term BARF to me. I’m studying for the PMP myself and have Rita’s book along with the Hot Topics flip chart guide.
I think that every developer should be given the opportunity to contribute to the WBS and estimate the duration of tasks. It is also quite possible a developer can be used to document task dependencies and possible lead/lag information.
In the monitoring and control stages, the project manager can gauge how well each developer did in their estimations and then adjust any of their future estimations accordingly. Sound reasonable?
Cheers,
Dwayne Wright
FMP 10, 9 & 8 Certified Developer
Dwayne,
Sorry for the late reply – I missed seeing your comment earlier. Your suggestion of gauging an estimator’s accuracy over time and then adjusting future estimates based on actual data makes a lot of sense. In theory, it’s a no-brainer. In practice however, the challenge is collecting, synthesizing, and analyzing the information. And even if you do that well, there are other challenges, like missed or misunderstood requirements and how that effects the differences in actual costs.
There are some products out there that claim to make this easy, like Joel Spolsky’s bug tracking software. Would be interested hearing about any tips or challenges from your experience.