Thanks for visiting again. Please leave a comment or ask a question.
Article Series - Notes on Obsolete Project Management Theory
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 is crazy to give the greatest effort to detail when we know the least about the project…at the beginning.
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.
? Guy Kawasaki wrote, "Less is the new more." Easy to learn: symmetry, seduction, subtraction, and sustainability. Very valuable to do. Step 1: Read Matt's book!! just 140 keystrokes.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=03314884-90d1-47e5-acf3-2821313e9fdc)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=4ce3f392-8989-448a-a97a-c1432dd3fce6)
{ 4 comments… read them below or add one }
Hi,
I would just like to comment on one of your last sentences,
>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.
Sometimes, it`s hard to pinpoint the last responsible moment and sometimes you have to stake your claim early in a project otherwise you have a repeated discussion on decisions you make later in the project.
Imagine an IT project where you state that the language of choice is xyz for the apropriate reasons…
Now if you state this early in a project, all involved can get accustomed to the thought and in the end they will follow.
Now if you decide on such a vital detail in the middle of a project this decision might be exploited for various targets like e.g. an excuse why the project is late…
And you might get into repeated arguments when you least need them (in the middle of a running project)
So it`s a tough call to make this last responsible moment…
Even though I like the concept, I find it hard to implement.
Bye
Buck
A set-based design concept can be very useful for thinking about when to make decisions. Delaying decisions is the equivalent of maintaining options, a very find economic approach to business. In design, one maintains options by defining the constraints of choices, rather than making a choice and iterating on it. As time progresses and more knowledge is gained, the constraints are narrowed. This is the way Toyota designs cars. Of course, a fine sense of timing is required to know when decisions have to be made, but my observation is that we have a great tendency to want to ‘lock in’ decisions as soon as possible, while the bias to make them as late as possible tends to be counter to our ‘culture’.
I like to divide planning into two types:
1. Plan to Learn
2. Plan to Execute
The first type of planning is good. The second type of planning has a great tendency to make decisions before their time. It is the failure to keep options open, even when there is little cost to doing so, that makes ‘planning to execute’ ineffective in a changing environment.
Hi Hal,
>proneness to naivete.
I don`t think it to naiive
only sometimes you just have to adapt to your environment and if you are in
a rough environment you have to adapt, sometimes…
I always have to take that into account when I´m writing PM Handbooks for different companies.
Depending on the whole interpersonal chemistry that is current in a company
I sometimes have to spell out every step right down to the smallest detail, including escalation chains and sometimes it`s ok to wrap it all up in 10 pages…
It´s a strange world out there
Bye
Buck
P.S. I like the anagramm, although I haven`t found the solution yet…