Project managers need to be able to stand up to sponsors

Ever done a post-mortem on a project to figure out why it blew budget and schedule? If your projects are like the ones I have witnessed for the last 23 years, many times there may be a single root cause to this problem.To search for that root cause, let’s play a game I call “Why Did That Happen?”
Here’s how we play. Let’s pretend we are closing out a project, and we have assembled the project team and sponsor to do a post-project review that found us 40 per cent over budget and four months late. The game starts when the following question is asked: “What went wrong with this project to cause it to run over budget and time?”
“Testing took longer than we thought.” So now the games begin as your meeting facilitator asks:
“Why did that happen?”
Answer: “The code had to be sent back several times for rework.”
“Why did that happen?”
“Because we were still designing requirements while we were coding and there was not enough time to finish the coding and unit testing properly.”
“Why did that happen?”
“Because we didn’t understand the requirements when we put the project plan together. As a result we kept modifying the requirements going to the developers. Basically we did not understand the project scope when the schedule and budget were put together.”
“Why did that happen?”
And this answer comes streaming in like a confession: “Because the sponsor needed to have a final budget and schedule by Jan. 15, to get project approval. We later learned that the solution involved a lot more coding and testing and that the equipment would cost more than we thought.”
Bingo. The game is over, every one loses, and the PM is to blame.
How do you avoid this? Do what the pros do. Tackle project estimating and delivery in three stages. Stage 1: If there is a desire to do this project, provide very rough estimates that are not binding. In Stage 2, hammer out the details of what is required and understand what the solution will cost. This allows the project to have a natural checkpoint after some detailed planning where the business can evaluate the risks, cost and schedule and decide if this project is still worth executing. You will have a much better chance of keeping the project on schedule and budget if the plan is not based on wild guesses and unknowns. Finally, Stage 3 is the detailed execution project, based on a detailed built-from-the-ground-up estimate produced in Stage 2.
Why do I blame the PM? Because he or she must have the backbone to resist the kind of project planning in which estimates are built based on the bellowing and barking of the sponsor. If you hide behind the excuse that it is just the way that projects are planned around here, then you need to clearly publish this as your No. 1 risk in the project.

Would you recommend this article?

Share

Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication.


Jim Love, Chief Content Officer, IT World Canada

Featured Download

Featured Story

How the CTO can Maintain Cloud Momentum Across the Enterprise

Embracing cloud is easy for some individuals. But embedding widespread cloud adoption at the enterprise level is...

Related Tech News

Get ITBusiness Delivered

Our experienced team of journalists brings you engaging content targeted to IT professionals and line-of-business executives delivered directly to your inbox.

Featured Tech Jobs