Project Planning is the necessary evil to all projects. Project Managers hate it, Customers hate it, and the people actually doing the work – developers for now – hate it, and every walks away from the process feeling singed, beaten, intimidated, or even lied to. The customer thought this was an easy project and hoped it would be done in two weeks. The developers gave their honest estimates and they were cut in half. The Project Manager got a series of junk estimates and tweaked them without hesitation. Everybody lost and the project starts off in the wrong tone.
The customer – aka The Person Paying for the Work – had a preconceived notion of a timeline and cost.
The developers – aka The People Doing the Work – had their professional integrity mocked.
The Project Manager – aka The Person In Between – has potentially doomed the project to failure.
Why does this happen? The reason for this is simple: none of the stakeholders' needs are met.
The fundamental management problems here* are beyond the scope of this entry, but the Project Planning is not. I will address the developer side today and the Customer side tomorrow.
PERT may be a way of addressing some of these concerns. The process involved in PERT is quite similar to the standard project estimation techniques with one major exception: Instead of stating a single estimate for a task, three estimates are produced.
- An Optimistic or “if things go well” estimate is provided. This is equivalent to “1% of the time, the task will only take X hours/days/months”.
- A Pessimistic or “if things go badly” estimate is proivded. This is equivalent to “99% of the time, the task will be complete after X hours/days/months”.
- A Most Likely or “if thing stay the same” estimate is provided.
Expected = ( Optimistic + 4 x Most likely + Pessimistic ) / 6
These three estimates are weighted accordingly and averaged to get an Expected time.
Now, simply sticking with the PERT analysis, a Project Manager can take these estimates and project various ending dates for a project based on different probabilities. This can be used to track which tasks are on the Critical Path and which ones could become Critical Path tasks with slight delays in preceeding tasks.
Here's where PERT and a good Project Manager can be a killer combination. When the Project Manager elicits the Optimistic or “if things go well” estimates, he simply asks the follow up question: “What would help things to go well?” The developer already had those things rolling around in their minds and here's the chance to say them.
It could be a whole series of things: less phone support, no client visits, a better IDE, staying healthy, a second monitor, timely customer feedback, and a variety of other things. Now, you as the Project Manager have a hitlist of items that if you choose to ignore, you do so at your own peril.
Wow, so you've just instilled a bit of confidence in your developer and opened the door to being a better Manager. That was easy… next I'll address the Customer.
* For a good read on people & projects, check out PeopleWare by Tom Demarco and Timothy Lister