 Reforming Project Management |
||
|
|
||
|
Saturday, August 31, 2002
Project Reliability Soars when Work Is Ready
Ok, so if that makes so much sense, then why don't we systematically and organizationally address the issue of making work ready? One reason is that we act like announcing what must be done vis-a-vis a master schedule is enough for responsible people to successfully perform their tasks. That is all too often insufficient. Sure, all good projects have an always up-to-date master schedule representing what 'should' be done, but what about what 'can' be done? By 'can' I mean tasks that are in a ready state: the wherewithall has been addressed for both starting and completing the task. While this might appear to be sufficient, it still lacks one essential element: someone says it 'will' be done by a specific time. Only when an individual commits or promises to complete a task do we have a scheduled item that we can rely on. Within the lean project community we refer to this as should-can-will planning. Are we done? Not quite yet. We don't want to leave reliability to chance on projects, therefore someone must take responsibility for seeing that the work that should be done is in a ready state so that it can be done and elicit promises from project participants so that it will be done. We call that role the project manager. Thursday, August 29, 2002
So What Do Dependence and Variability Have to Do with Projects?
In the usual practices of project management establishing precendence relationships is a key step in creating a network plan for the project. Along with that the planner often establishes early and late start dates and a finish date. But these dates have nothing to do with what will be done when the time comes for the task. Why? One reason is due to the variation of task completion throughout the project. We can count on each task taking a different effort and duration than was originally planned. Let's consider an example: The engineering specification expected to take 20 hours and due on the 15th of the month actually took 30 hours and was completed on the 20th. Further, the task was planned for one person, but that person needed others' help. To the extent that other work couldn't begin 'til the spec was ready (a usual case for a spec), the project accumulates delay. Further, there is less engineering hours available than were originally planned due to the variance in effort of the enginneer and the help provided by others. While it is true that some tasks take less effort than estimated, our project experience tells us that we rarely benefit from early completions. So we have a project that will require more hours and more duration than originally planned. What can be done? First, one must identify the situations that are likely to vary from the planning estimates. Then, buffer other tasks from that variability and work to reduce the variability. How? For recurring tasks one can study the flow of work, reduce the waste, minimize ambiguity, and appropriately staff the task with necessary skills. Is this enough? No, because we have variablility popping up all over. The solution then must be systemic and organizational. (more to come) Monday, August 26, 2002
Microsoft Eats the Dog Food
Lean Project Consulting welcomes MS to the table. In this September '02 Fast Company article MS shows off how they have made MS Project 2002 post-modern, or should I say lean. They offer four 'new' axioms for successful projects -- all of course now supported by Project 2002. They are:
1. Expect the unexpected. We've been saying this for quite sometime. The world is uncertain and unknowable. Plan your projects that way.
2. Measure work done, not hours spent working. The lean approach using the Last Planner™ system is to measure the 'percent of plan complete' on a week-to-week basis. Not only do you stay on-track with completions, but you have a basis for investigating and improving the variances to completing work as planned.
3. Don't crack the whip; share the work. The work, that is, of planning. Rather than doing the typical top-down plan to the gnat's ass, MS is now acknowledging that a better result will come from collaborating with the folks closest to the work.
4. If you want the right people, you have to know what you're looking for. Project success depends on having people who can do the job. So, MS now has resource descriptions rather than just individual's names.
What are they missing? Good question! Here's one list. More to come later.
.. Dependence and variability
.. Working on only that work that should, can, and will be done
.. Promising reliably
.. Leadership
Still, I can't wait to get my hands on Project '02!
Visit the Archives for more postings |
 Reference Papers
|
|
| ||
