Planning to Build vs. Building the Plan
Apparently, Dwight D. Eisenhower once said “In preparing for battle, I have always found that plans are useless, but planning is indispensable.”
I collect quotes like this when it appears they might have some relevance in the work I do. I’m actually dubious about whether Mr. Eisenhower really said this in his life, as I am about all the things attributed to Mark Twain, Albert Einstein, and all the others that are the source of so much wisdom. Whether or not they actually said these things, it is always interesting to run into a situation where the expressed wisdom holds true.
I ran a couple of project management training sessions in the past few months. Both with the same material, for the same organization, but different groups. Throughout the session, we run a simulation where the students are tasked with physically building a small but complex device, with several components finally being integrated into the final product. Initially they try to build with virtually no planning, with results as you might expect. They get another crack at it with this experience behind them, and generally they do a bit better.
We then dive into a discussion of project management ‘hard skills’, culminating in an extensive exercise where the teams are tasked with constructing a detailed project schedule for building the device, just before they try one last time to lower their actual times to build the device. The goal is to have a completed project network, fleshed out with estimates for each activity, an understanding of the critical path, and an expectation of how long it will take them to do the job.
Through all of this, there is the time pressure to build their device as quickly as possible, injected by competition across the groups – “the other group got to this point in this much time – can you beat that”? All great fun.
With the first group, this network planning session was an extremely chaotic time as people scurried about the room, generating all manner of side discussions. It was difficult to discern any progress with the team. Several people voiced some frustration during the exercise, and indeed, nobody in the group managed to put together a complete network. Nobody could express which tasks were on the critical path, and nobody had a defendable expectation of how long the overall project would take.
For the second group, there was far more visible organization. The teams disseminated and shared their knowledge very effectively. At the end of the planning session, each of the four component teams produced schedules that looked very similar, with critical paths and durations that all came in within 20% of each other. Every one was a credible plan of attack for building the device.
With both groups, everyone was fully engaged throughout. Indeed, as I called for breaks leading up to the planning exercise, nobody would leave the room, as they were busy strategizing what do do when they had a final crack at building the device. Both groups managed to identify all of the same optimizations that would bring the overall project duration down, and had a good idea of how to resource the project effectively.
The results when they were unleashed to build the device one last time, armed with this planning experience? The first team, that had been so chaotic in the planning stages and never did generate a complete schedule, ran like a fine tuned engine and completed the project in record time. The second group, despite building a credible schedule of activities and reasonable expectations for duration, ran out of time and didn’t quite complete.
The real kicker here is that the group that finished in record time, did so in a time that was within 10% of what was expected from the other group’s schedules! It appears that while one group did a great job of building a schedule, the other group did a great job of planning how to build the device. Perhaps there is a distinction to be made between project planning and organizing to build a plan.
In the real world, clients couldn’t care less how pretty the schedule is if you never manage to deliver the product. While one group was busy figuring out how the tasks would fit together on the network, the other group was busy ironing out the details of who needed what from whom, and when they would get it. They worked out all the handoffs, everyone knew their role to play, and the actual building went without a hitch. That chaos during the planning activity was the necessary walking through of how they would coordinate to get the job done.
This is not so cut and dried, to be sure. In hindsight, the second group suffered significantly as they never had an opportunity to try to integrate the components of the device in either of their first two attempts, and this threw them for quite a loop in their final attempt. They did progress significantly as a result of their planning efforts.
So it really isn’t the plan that is important, but the activity of planning. The discussions and debate, sometimes heated arguments, can go a long way towards helping the team arrive at a common understanding of what needs to be done, regardless of whether a nice Gantt chart pops out the end of the exercise. I’ve seen many stale Gantt charts up on walls over the years, and many projects have succeeded without a Gantt chart to work with. To my mind, I’d happily lean towards the deeper discussions of how we’re going to coordinate to achieve our goals.
Apparently, Eisenhower also once said “What counts is not necessarily the size of the dog in the fight, but the size of the fight in the dog.” It seems that Dwight was a pretty wise fellow. – JB