Crashing the Schedule
I recently changed a flat tire in a busy section of a public parking garage, just as the nearby office buildings surrounding it were emptying for the day. Streams of cars passed by me as I changed my tire. Some of those driving home were undoubtedly coworkers, and the thought occurred to me that they might stop to offer help.
Honestly, I hoped no one would stop. I can change a tire in less than 10 minutes if no one “helps.” Fortunately, no one stopped, but my thoughts turned to crashing the tire-change schedule. Would 50 people thrown at this task have helped? Or, would the overhead of managing 50 people have increased the time involved in changing the tire?
Of course, this reminded me of work and the tendency to crash delivery schedules on information technology projects. In my experience, most attempts to crash schedules — by throwing lots of people at a task — have marginal benefits, at best. And often, the overhead of managing all of those extra people offsets any gains.
Crashing a schedule really only works when the schedule is truly crashable. Not all schedules benefit from crashing. Project leaders sometimes try to speed up a project that cannot be sped up by running steps in parallel and adding people. Like changing a tire on a car, most projects cannot be accelerated simply by adding more people. The crashing technique should only be used in specific and relatively rare circumstances, such as changing four tires on a car at once, for instance.
On the other hand, it is possible to dramatically improve the time required to change a tire by using better tools instead of adding more people. Scissor jacks are slow, as are the lug-nut wrenches that come with most cars. Replacing these tools with a hydraulic lift and a pneumatic impact wrench, for example, will cut the time required to change a tire from 10 minutes to two. In other words, the most effective way to “crash” a tire-change schedule is to upgrade to better tools and perhaps select a few people who can optimize the effectiveness of those tools. Think of a race-car pit crew, changing all four tires in less than one minute.
I once managed a project in which one of the major deliverables was document coded in eXtensible Stylesheet Language Transformation. XSLT is a scripting language used to map fields in two different eXtensible Markup Language (XML) documents, so that systems with different nomenclatures can communicate with each other. It was a large task because there were hundreds of fields that needed to be mapped between the two document types, and it was further complicated by the fact that the XSLT syntax is difficult to read and interpret. The project team plodded along rather unsuccessfully, falling further behind every day, until one day I sat down with one of them and observed how they were performing their work.
What I saw shocked me. They were building the XSLT by hand, a laborious and mind-numbing task. No wonder progress was slow. I immediately set out to purchase one of the many fine tools for building XSLTs, and before long, the project was back on track.
Improving the way we work by improving the tools we use has a much more dramatic effect on progress than increasing head count does. Never ask the question, “Can we speed this up by adding more people?” without also asking, “Would this go faster if we had access to better tools?” You just might find a better, cheaper and more permanent way to crash the schedule if you do.
