 Reforming Project Management |
||
|
|
||
|
Saturday, November 02, 2002
How 'bout some fun?
I'm just a little burnt out after reading Lauri and Greg's paper over and over and over again. So, how 'bout a little fun. The following is a list of anagrams for the same word or phrase. What is it?
Friday, November 01, 2002
Behind the Facade of Project Management
Lauri Koskela and Greg Howell (K&H) do a marvelous job of capturing the experience of projects on page 11 of The Underlying Theory of Project Management is Obsolete:
"The deficiencies of the theory of the project and of the theory of management reinforce each other and their detrimental effects propagate through the life cycle of a project. Typically, customer requirements are poorly investigated at the outset, and the process of requirement clarification and change leads disruption in the progress of the project. The actual progress starts to drift from the plan, the updating of which is too cumbersome to be done regularly. Without an up-to-date plan, the work authorization system transforms to an approach of informal management. Increasingly, tasks are commenced without all inputs and prerequisites at hand, leading to low efficiency or task interruption and increased variability downstream. Correspondingly, controlling by means of a performance baseline that is not based on the actual status becomes ineffective or simply counterproductive. All in all, systematic project management is transformed to a facade, behind which the job actually gets done, even if with reduced efficiency and lessened value to the customer."Most projects do eventually complete. We can thank project participants for their "in spite of it all" approach. We see project participants acting contrary to the stated practices and standards of the organization and in so doing they deal with the problems of the project. K&H show us the problems are not:
Let's bring down the facade and the misery and waste that go along with it. Thank you Lauri and thank you Greg for getting us talking. Thursday, October 31, 2002
Set It and Forget It? Hardly!
In Koskela's and Howell's (K&H) paper The Underlying Theory of Project Management is Obsolete they describe thermostatic control is the principal espoused (or inferred) theory of control on projects. Examples:
What's wrong with this theory? You just can't set it and forget it. Unlike temperature or path, there is no one correct path on the project. The path to completion shifts throughout the project. Sure, we have a good idea of what must be done to finish, but the sequence can change and some of the tasks will fall off while other required actions will be discovered. Thermostatic control at best locks us into a naive plan...uninformed by the world that has unfolded. The good news is we find the theory-in-use doesn't conform to the espoused theory. In response to out-of-date plans and execution that fails to consider the readiness of performers, controlling activities function as negotiation between the directors and the performers. Referring to this breakdown of control, people disparage the team by saying they are out of control rather than acknowledging they are likely better off than operating to an obsolete plan. Where is this headed? The six σ advocates might suggest we must identify the variables and bring them under control (as if we can). But perhaps the machine metaphor has served its useful life; project control is more like navigating a boat. The crew with their hands on the wheel and the lines rely on visceral signals -- a fluttering in the sheet, tension in the line, a slight list to starboard -- to make their adjustments. Execution and control combine as performers rely on their intuition and experience. The destination is reached even though the boat may never be on course. Wednesday, October 30, 2002
Management-as-Determining?
The PMBoK® describes 10 planning processes out of a total of 13 core processes for project management. These 10 processes comprise what Koskela and Howell (K&H) call management-as-planning in their paper The Underlying Theory of Project Management is Obsolete.
It's no surprise there are 10 planning processes. We go to great extremes on projects to plan. The value of planning seems to arise out of the concern for mimimzing risk. More time on planning is supposed to lead to fewer unforseen conditions. The usual practice is for smart and experienced people to spend time up-front thinking through one possibilty after another finally landing on an approach that makes sense (to them). The plan is put to paper (or in scheduling software) then is 'sold' to project participants and the customer as the (one right) way to go. Often, planning then stops. Execution begins. This distinct break -- planning as separate from execution -- is seen by K&H as consistent with the general field of operations. Planning is the process of deciding what to do. Those in execution get their direction from the plan in a usual dispatching process...following the "simple process of issuing orders". Management-as-planning in conjunction with planning-as-determining, becomes management-as-determing in the everyday practices of projects. We can understand from history that computer time for scheduling programs was expensive. Doing a good job once, or maybe twice was all the project could afford. Further, some project activities are deemed expensive to change mid-way through the project, like changing the layout of a building or adding functions to software. So in an effort to minimize rework project teams fix the requirements and the schedule. But the future is uncertain. Plans can't possibly determine results. At best, planning prepares for the always-uncertain future. Our herculean efforts to get the project plan in place at six levels of detail early in the life of a project is not just a waste of time, it uses key people who could be used throughout the project to better end. It is crazy to give the greatest effort to detail when we know the least about the project...at the beginning. Better (much better) is to add detail no sooner than it is needed (acting a the last responsible moment) taking advantage of what is revealed and learned. AND do this with people who are close to the project...people who actually perform the tasks. Tuesday, October 29, 2002
IPO Theory is Incomplete
Koskela and Howell (K&H) claim in their paper The Underlying Theory of Project Management is Obsolete the theory-in-use of project management is based on a production theory and a management theory. The production theory is transformation: input-process-output (IPO). The management theory is closed-loop: planning-executing-controlling, with the emphasis on planning (management-as-planning, the dispatching model, and the thermostat model of control). For this posting I'll focus on the transformation model. Tomorrow I'll comment on management-as-planning.
The transformation model is so pervasive in our experience and thinking that we don't see the world a different way. The approach is reductionist -- break the project down into milestones, phases, activities, and tasks. The project management mechanism for defining and organizing plan items is the work breakdown structure (WBS). K&H argue that IPO theory misses two complementary theories: flow and value generation. Both theories have been around for quite some time, 1920s and 1930s, respectively. But in our machine-dominant world tbe IPO model pervades, missing the attention these other theories give to time and to what is of value for customers. So where do we go from here? Some people contend that we can just put the three production theories together in our practice. In my experience, our practices for creating the WBS get in the way of this. Other approaches must be pursued. Some of the more promising approaches are business process mapping (workflow), story-boarding, and the scrum development approach of iterating. In the meantime, perhaps there's a litmus test for defining or accepting plan items. Ask, "Would my customer be willing to pay for (see value in) what I plan to do?" If not, then adjust the plan. Monday, October 28, 2002
Why the Interest in Project Management Theory?
I'll start my comments on Koskela's and Howell's (K&H) paper The Underlying Theory of Project Management is Obsolete by addressing the interest in theory. Many of you may want something of more practical value. Although the engineers in the group may be quite comfortable with a discussion of theory. Why should we all be interested. Our interest is more than academic; it is quite practical.
Let's start by considering that K&H might be right. If the theory in use is obsolete, then it would explain why we don't get the results we're after. Like 15th century navigators believing the world was flat or earlier astronomers who thought the sun revolved around the earth, there are anomalies of project performance that can't be explained. It is with the intent of explaining past behavior and predicting future behavior that we are interested in theory. Readers of this weblog will note I often recommend adopting one behavior or another. I also criticize familiar behaviors as not effective. K&H's discussion of theory will allow you to participate in selecting practices for your project. Their paper also provides a jumping off point for developing a more encompassing theory. We have been distracted by colleges and the PMI. We've been told if you want successful projects, then do those things recommended by the ANSI standard for project management. What is that standard? It is the PMI Body of Knowledge®, ANSI/PMI 99-001-2000. (Did you notice the designation of the registered trademark? Trying to refrain from cynical comments let me say might there be commercial interests involved?) We've been told to do more of what we've been doing. To get more people certified by PMI, to do a more comprehensive job of creating project schedules, and to always keep our CPM schedules up-to-date. It seems to me doing more of the same only benefits the status quo: the providers of software, training, and consulting. Yet we all know of projects where they are doing everything PMI recommends, and the project is still late, over budget, missing key functions, or all three. It is this anomaly that so interests K&H. Let's all have a practical interest in theory so we can do a better job of selecting practices, so we have a basis for creating new practices, and so we can get the results we're after on our projects. Sunday, October 27, 2002
Koskela and Howell Argue for a Reform
Lauri Koskela and Greg Howell presented their original paper The Underlying Theory of Project Management is Obsolete at PMI's bi-annual Research Conference this past July. A number of people have asked me to comment on it. I'm struck by how persuasive Lauri and Greg are. It takes them just 12 pages to evaluate the anomalies and argue for a reform to project management. My postings for the coming week will attend to Lauri's and Greg's paper. Download your copy. Read ahead. And please join me in discussion with your comments and questions to each posting.
Visit the Archives for more postings |
 Reference Papers
|
|
| ||
