Comments on: Moving Beyond Obsolete Theory http://www.reformingprojectmanagement.com/2007/03/11/779/ The magazine for the project age Wed, 08 Oct 2008 08:32:38 +0000 http://wordpress.org/?v=2.0.5 by: Diana Hutchinson http://www.reformingprojectmanagement.com/2007/03/11/779/#comment-14069 Mon, 12 Mar 2007 15:12:36 +0000 http://www.reformingprojectmanagement.com/2007/03/11/779/#comment-14069 Thanks for your provocative thoughts on why project management theory is obsolete. I would agree with you that the "PMI" model of project management is a machine type model. Current PM tools can be useful and provide some good methods for PMs to increase how successful our projects are. For example, by writing out the work we think we will have to do (at least at a high level) it helps us determine if we could accomplish it in a certain time with the resources we were planning to use, or if we need to get more resources or time. And often when our teams discuss risks, we bring up potential issues that can be addressed and mitigated, rather than wait for them to surprise us. But, I had not really thought about how the PMs seem to think that if we could just spend more time in planning and defining up front, we could "get it right" in the execution. This method probably makes sense for some projects where there is a big penalty for any errors during the execution phase (such as something that has to happen during a plant shut down where every minute costs $$, or in space where there isn't a chance to fix a problem). I have also tried the method of writing down a detailed WBS at the beginning of a project, and quickly determined that it was not worth the effort to try to update each task, especially as tasks were often "partially done" -- for example the test completed but report not documented. I like the model we used at Motorola and a similar one here at Woodward for engineering new product development. In this model of project phases, the solution becomes better defined as we go. We start out with a high level definition and decide if there is a business case to proceed. Then we tackle the biggest risk areas in a conceptual phase, and meet again to decide to proceed or not. Finally we have the detailed development/qualification testing, followed by pilot production to qualify the manufacturing process. As always, the challenge is to run a project with a tight enough timeline so team members have a sense of urgency (and therefore avoid the student syndrome of putting off the start and allowing other work to fill in, or the Perkinson's continual tweaking to fill the time allowed); while allowing flexibility to respond to new information (for example a long term quality problem or improvement). And the balance of estimating a budget that provides a reasonable ROI but is also realistic in terms of accounting for those unknown pieces of information that will surface during the project. I would be interested to see your presentation to the Puget Sound PMI... and talk more about bringing you to the Mile Hi PMI to challenge us out here! Thanks for your provocative thoughts on why project management theory is obsolete. I would agree with you that the “PMI” model of project management is a machine type model. Current PM tools can be useful and provide some good methods for PMs to increase how successful our projects are. For example, by writing out the work we think we will have to do (at least at a high level) it helps us determine if we could accomplish it in a certain time with the resources we were planning to use, or if we need to get more resources or time. And often when our teams discuss risks, we bring up potential issues that can be addressed and mitigated, rather than wait for them to surprise us.
But, I had not really thought about how the PMs seem to think that if we could just spend more time in planning and defining up front, we could “get it right” in the execution. This method probably makes sense for some projects where there is a big penalty for any errors during the execution phase (such as something that has to happen during a plant shut down where every minute costs $$, or in space where there isn’t a chance to fix a problem). I have also tried the method of writing down a detailed WBS at the beginning of a project, and quickly determined that it was not worth the effort to try to update each task, especially as tasks were often “partially done” — for example the test completed but report not documented.

I like the model we used at Motorola and a similar one here at Woodward for engineering new product development. In this model of project phases, the solution becomes better defined as we go. We start out with a high level definition and decide if there is a business case to proceed. Then we tackle the biggest risk areas in a conceptual phase, and meet again to decide to proceed or not. Finally we have the detailed development/qualification testing, followed by pilot production to qualify the manufacturing process.
As always, the challenge is to run a project with a tight enough timeline so team members have a sense of urgency (and therefore avoid the student syndrome of putting off the start and allowing other work to fill in, or the Perkinson’s continual tweaking to fill the time allowed); while allowing flexibility to respond to new information (for example a long term quality problem or improvement). And the balance of estimating a budget that provides a reasonable ROI but is also realistic in terms of accounting for those unknown pieces of information that will surface during the project.
I would be interested to see your presentation to the Puget Sound PMI… and talk more about bringing you to the Mile Hi PMI to challenge us out here!

]]>