Moving Beyond Obsolete Theory
March 11th, 2007 by Hal
It's my pleasure to speak again at a meeting of the Puget Sound PMI Chapter. Two years ago I gave a rather long and complicated presentation on obsolete theory, Fayol, Flores, and what can be learned from construction project management. This time I'll be attempting a much shorter and less complicated talk. Originally I titled it "An Update on Obsolete Theory", but I've reconsidered. After rereading my updated Notes on the Underlying Theory of Project Management is Obsolete and a paper Greg Howell and I prepared for IGLC-13 Managing Promises with the Last Planner System® I decided to speak more practically. I'll make my slides of Moving Beyond Obsolete Theory available later this week now. In the meantime, have a look at the IGLC paper.
Interested in more theory and practice? Have a look at the Project Management Theory lens.
Related Posts
- Slides Available for Moving Beyond Obsolete Theory Moving Beyond Obsolete Theory...
- Notes on Obsolete Theory People have written me in the last two weeks asking about my comments on Lauri Koskela's and Greg Howell's paper The Und...
- Converging on a New Theory Lauri Koskela and Greg Howell (K&H) argue successfully that current theory is obsolete in their paper The Underlyi...
- When it Comes to Project Management Theory Can You Go by the Book? In PMI's September 2006 PM Network CareerTrack section Karen Bannan has an article titled, In Theory: You can't always...
- Towards a New Theory of Project Management Today I complete my comments of the paper The Theory of Project Management: Explanation of Novel Methods by Lauri Kosk...
March 12th, 2007 at 10:12 am
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!