 Reforming Project Management |
||
|
|
||
|
Saturday, October 05, 2002
Business 2.0 - The 101 Dumbest Moments in Business
Business 2.0 - Magazine Article - The 101 Dumbest Moments in Business
#15. Two years after announcing its plan to build a state-of-the-art $400 million supply chain, Nike (NKE) cuts its earnings outlook for the current quarter by more than $50 million, citing problems caused by supply-chain software supplied by i2 (ITWO). Nike CEO Philip Knight tells analysts, "I guess my immediate reaction is 'This is what we get for $400 million?'" i2 counters that the problem was Nike's implementation of its system; meanwhile, i2 shareholders sue the company for failing to promptly disclose its Nike troubles.
Maybe a change in project management would help. But maybe not!
Friday, October 04, 2002
Let's Not Be Fooled
Planning is conversation.
The future is uncertain and unknowable. Commitments must be adjusted as the future unfolds. Those adjustments can be done by the project manager or anyone on the project team. However, only those people involved in planning the project will be in the position to notice and then assess the need for adjustment. So, why use critical path? All planning is practice. Each time through a project plan the participants prepare themselves for the future that is unfolding. Will it turn out just as they plan? Of course not. But taking the time to plan prepares them for the eventuality of the future being different than they expected. Do you want your projects to finish on time and on budget?
Thursday, October 03, 2002
Fool Me Again and Again!
Task durations depend on the quality of the conversations.
Schedules are not commitment. We have been fooled enough to know that! Just because we say a task is on the critical path doesn't mean it will get done. Only when the intended performer promises to perform will it get done (and even then, maybe not). Commitment is produced in conversation. When people freely promise there is a possibility of commitment. Absent conversation, tasks will not complete as desired. Declaring complete is the key action for keeping any project on track. People do not do what the schedule says they should do. Yet, project managers too often expect that people will do just what the master schedule says they should do. Why? We can’t do tasks that are not ready to be done. Tasks on the critical path necessarily must wait for the task preceding it. Unfortunately, performers in sequence may not be in conversation with each other. They don't know that a task is complete therefore releasing the work for the next person in line. These performers may work in different divisions, companies, or just not be aware that another person is dependent on them. Declaring complete -- saying, "I'm done" -- is the step to keep work flowing. One-way communication doesn't work. Project members are informed of the schedule. Performers are told which tasks they should do. Status is given as a report by someone other than the performer. None of this produces commitments. You must be in two-way conversation to have people perform to the schedule. Only the fool thinks "telling" suffices. Wednesday, October 02, 2002
First Thoughts on Control
This series of notes is about control. It will begin with the basic rules for simple systems and move to applications in more complex circumstances. I was an undergraduate when I first started watching crews work using timelapse photography. What I saw through the lens didn't line up with what I was being taught or was being told by managers in corner offices. It wasn't obvious to me why work happened the way it did. My interest what caused work to be the way it was, what controlled it grew. The disconnect between observed practice and explanations appeared to be a real opportunity. Following intuition, I became more and more convinced we were on to something before the now obvious underlying concepts were in place.
Early enough we were thinking about the systems, teams and the processes involved in getting work done. Goldratt taught us about dependence and variation and we could see that work planning was unreliable. Glenn Ballard coined the term, Last Planner, giving us a different perspective, a new unit of analysis. And then I read "Out of Control" - a powerful book with a clever title, by Kevin Kelly. He argues that we need to reconsider how nature controls complex biologic systems. The sharp line between things that are born and things that are made is becoming very blurry. We are now applying techniques used in making things to that which is born -- genetic engineering, and making things almost as complex as that which are born -- the internet. Projects, particularly complex fast moving ones, seem to be near this line and pose real challenges for control. Kevin traces the development of modern control to Norbert Weiner. Young Norbert was raised to be a genius. His father wanted a Nobel Prize in the family. His work provided the foundation for cybernetics. It started when he joined the effort to make uniformly thick sheet metal. The stakes were high because uniform feedstock would allow machines to make car parts -- fenders, auto bodies etc. Three variables were obviously involved - the heat of the metal, the pull tension and the roller setting. But no one had found the magic relationship that could assure a long uniformly thick roll. Norbert cut through the problem. He showed with a simple mechanism that controlled the last variable produced the desired result as long as the other variables were within in a range. Being "right" didn’t matter as much as the ability to adjust quickly. His device detected the thickness of the metal just past the rollers adjusted them in response. Controlling the last variable with rapid feedback was all that was required as long as the other variables were within some range. I was struck by how well the Last Planner System™ conformed to this rule. Work is made ready as it moves forward to action and only released to certain criteria. Control of the planning system is applied just as in Norbert's sheet metal manufacturing process. Detectors just downstream provide feedback to make performance more reliable. Feedback in both systems is very quick. The sensing and adjustment mechanisms are tightly linked. Adjustment is so quick the product stays within tolerance. There is more to say about control of more complex systems but the first rules are clear. Control the last variable while keeping the others within some range, and tightly couple the detection of variance to the control gate. A system that follows these rules will produce uniform sheet metal and predictable release of work from one crew to the next. CPM: Fool Me Again
Task durations vary.
Experienced project managers will tell you the critical path moves on a project. Why? Tasks don’t start and finish as represented in the project schedule. This would be fine if all the performers for critical path tasks were always available to perform on the project, but this is not the case. In most organizations people are working on more than one project at a time or project work is in addition to their normal work responsibilities. This creates the situation where they must manage priorities – "Do I spend my time on this or on that?" We don’t know all of what must be done. Oftentimes ad hoc work (those tasks that seem to arise in the course of doing the other work) encompasses as much time as the planned work of the project. To the extent that this ad hoc work requires the same resources as the work on the plan we see projects get behind. Performing this work often shifts the critical path. Tuesday, October 01, 2002
CPM: Fool Me Twice
Task durations are fabrications.
Let’s say you produce a critical path (for whatever reason). The generally accepted approach is to ask each key performer to provide durations for the tasks and the precedence relationships. With this data you can find the longest path through the network of tasks. With this approach you overcome one of the problems previously identified. So, is there still a problem? You bet.
Success with the critical path method hinges on knowing task durations – how else are we to coordinate action? Each person will estimate the time it will take them to perform. If they are at all risk averse, then they will also buffer that duration based on their experience performing similar tasks. Why? Because they don’t want to be the person responsible for getting the project off track. However, we don’t know what those buffers are. One person might add a 20% buffer while another adds a 500% buffer. Eli Goldratt, author of Critical Chain, and founder of the Avraham Goldratt Institute, suggests we can safely assume that all durations are at least twice as long as they need to be. What are we to do? We must investigate task level of effort (estimated hours to perform) for every task on the critical path and consider carefully its application. Durations alone are not sufficient. We are fooled twice when we accept durations as stated. Monday, September 30, 2002
CPM: Fool Me Once
Task durations are estimates.
The critical path method (CPM) is considered THE standard for managing projects. Customer contracts often require developing and maintaining the critical path schedule in great detail. Universities teach CPM in project management courses. CPM is the primary function of the best-selling project management software. Large plots of project schedules hang in construction trailers and project management offices depicting the network diagram and the critical path. No project professional in his or her right mind would start a project without calculating the critical path. So, if it is so widely used, then why are projects late, over budget, and dissatisfying customers?
We are fooled by the critical path. The central presumption for establishing a critical path is that we know how long each activity or task will take. When the activities are then strung together according to precedence relationships one can find the minimum time through the project. That is the “critical path.”
So what is the problem? How could you know what the real time will be for completing a task? You can’t. It is complicated by not knowing exactly who will be performing the task. (Rookies take longer than experienced people.) And it is further complicated by not knowing the circumstances (or situation) for performing the task. (Even experienced people can be distracted or can have an “off” day.)
So what does this mean for anyone managing projects? If you think that managing a project means just keeping your eye on the critical, then you are mistaken. Knowing who will perform and the circumstances for performance make more of a difference. Don’t be fooled.
Visit the Archives for more postings |
 Reference Papers
|
|
| ||
