Following up on my Not interested in yesterday post from a few weeks ago, I have another reference to Manager Tools. This time is is their Project Management Drumbeat Meeting (Part 1 and Part 2). And this time, I am not totally in sync with their recommendations - though I suspect there is something underneath that I appreciate.
The basic guidance they provide in Part 2 is "hold your team to their deadlines." If they don't hit a milestone, don't let them slide. Get a new commitment and hold them to that - and that new commitment gives them much less time, since they should have been working on the first one already. The common assumption here is that as long as every task is on track, the project will surely come in on time.
Arghhh!
The problem is that it just takes one task to go off the rails - maybe. And any kind of human-centric activity is sure to have variability, which means that some work is going to take longer / shorter than expected. That's the nature of variability. Projects are linked networks of tasks, so a delay on one task will ripple through the network. Of course, people know this, so they plan for it. They add padding between the individual tasks ("slack," anyone?); they pad their task estimates (and then waste the padding by starting late or not reporting early finishes); they multitask across many activities and projects; etc. Even when management try to trim the estimates, there is plenty of wait time embedded in those task estimates.
That "maybe" up there? Along with the built-in knowledge that "everyone pads," there is also the fact that projects are networks of tasks, not just a simple chain of events. There are multiple paths that weave through projects. And it is only the longest path (or the longest resource-dependent path for CCPM fans) that you really need to worry about. When there are delays on that road, it affects the whole project. When there are delays on the other roads? It depends on how tightly they blend with the main road. Is there slack at the integration point? How much has been consumed?
Here is my problem with management-by-milestones: it treats all tasks with the same level of importance, when we know that isn't true. There needs to be a way to ask people to move as quickly as possible without berating them for missed internal milestones. It is the overall project that project teams should be worried about. The individual tasks are one way to get there. How can we help each other get there as quickly as possible while still meeting scope and budget requirements of the customers?
Another example of the ill effects of holding people to milestones is the negative reinforcing loop of "schedule chicken." (I am sure The Manager Tools guys would go ballistic at the thought of this.) Schedule chicken is where no one admits their part of the project is slipping until it becomes inevitable that one person has to admit problems. And then everyone breaths a sigh of relief that they weren't the person to admit it. And by that point, it is often too late to do anything about it. Have a look at the 2:00 mark in this set of clips from HBO's miniseries From Here to the Moon.