Thursday, September 14, 2006

Great project management practice

The subject of project management came up recently, and I thought back to my first experience with it, which was exceptionally good. At the time, I was an engineer assigned to design a particular subsystem of a larger product. My manager, one Hr. Ulbricht, had me create a simplified PERT chart (with actions on the arcs, which I still think is more consistent with project management philosophy than actions on the nodes) for the project along with a design specification. He reviewed both, and then he had me post a copy of the PERT chart on the wall next to my desk. As I reached each milestone, I was to write the actual date on the chart. The tools we used were straightforward: a mechanical pencil, a ruler, A4 quadrille paper, and a copier. He would review my progress weekly.

I made the first few milestones exactly as promised, and his review was brief. Then I missed a milestone on the critical path by a week. In a very quiet, serious, and thoughtful way, he asked me to slip all the remaining items by an identical amount. As a young, optimistic engineer, I protested: I could certainly pull up some of the remaining tasks by, oh, working harder, working smarter, or something. I didn't want to cause the entire program to slip because of my problem. I didn't want the embarrassment.

He refused with an argument based on data: of all the milestones on my project so far, I had either estimated the time exactly right, or I had underestimated the time by one week. Unless I could show him evidence why I had overestimated the time required for later tasks, he figured the data indicated I would finish the entire project a week late at best, and it might indicate I'd be even later.

I wasn't happy, but I complied. What's more, I now understood that he regarded each milestone on the PERT, not just the final one, as a commitment, and I focused even more carefully on meeting all the rest of my now slipped commitments, which I did!

That experience taught me several lessons:

  • Pay attention to the data, not to your's wishes, in monitoring and controlling a project.
  • If you make project timing commitments, make them carefully, and treat them all with the appropriate respect.
  • The best project management tool may be your pencil, paper, and ruler.
  • Instead of tracking programs on one large PERT chart, consider letting each person or subgroup make a PERT for their work, and keep the top-level PERT simple.
  • If you do that, let each person or subgroup be responsible for their own pieces of the project. Monitor progress, and attend to exceptions.
  • When a milestone slips, take the appropriate schedule hit right away. That's one reason you did the PERT chart: to be able to understand the ramifications of schedule changes.

If you follow those guidelines, you might show initial project schedule fluctuations that other project managers don't show. As people understand the importance of making good schedules and then meeting those schedules they make, your actions might just help your project teams to meet their schedules much more often than the average project.

After over three decades and with great increases in technology and some in theory (critical chain theory comes to mind), that project still stands out for me as having one of the best project management practices I've experienced.

What have you seen for great project management practices?


Post a Comment

<< Home