Do less, finish earlier

 

There are three commonly referenced approaches for reducing schedule duration: crashing, fast tracking and scope reduction. Crashing is the addition of labor or equipment to effort-driven activities in the hopes of shortening their durations. Fast tracking involves executing activities which had discretionary dependencies in parallel (either wholly or partially). And scope reduction enables schedule compression by eliminating activities or by enabling crashing.

A few weeks ago in one of my classes, when I mentioned that crashing a schedule will generally result in cost and possibly other impacts to a project and might not improve the time lines enough to offset these impacts, a learner challenged this stating that they had worked on many projects where there were no impacts and there had been a reduction in the duration.

I qualified my initial statement by saying that the benefits would outweigh the costs if specific conditions for the activities being crashed were met including:

• They were not optimally staffed to begin with
• They are effort-driven activities
• Minimum onboarding or ramp up time was required by the added team members such that the impact to existing team members was negligible

And costs wouldn't necessarily increase if the work effort remained constant for the activities being crashed.

In the projects I've managed or supported, I've rarely seen all of these conditions met, but would accept that they might be common in certain domains.

The feedback inspired me to post a poll on PMI's LinkedIn Project, Program and Portfolio Management discussion group soliciting feedback on which of the common schedule compression techniques were most frequently used.

With a sample size of 117 responses, it was not a surprise that a combination of techniques garnered 50% of the votes as rarely does a single schedule compression technique suffice to achieve a desired duration reduction. Fast tracking was next at 20%, then scope reduction at 17% and finally crashing at 14%.

I am glad to see that crashing, which tends to be the tactic often suggested by senior stakeholders when a project won't meet a deadline, was the least popular choice. I would hope that this implies that most project managers are aware of Brooks' Law.

However, it is unfortunate that scope reduction was not the favorite option. Fast tracking usually increases the risk of rework or creating other types of waste whereas scope reduction, where contractually possible, usually reduces delivery risk.

As usual, it comes down to understanding a project's primary constraint. If schedule is truly that critical, then we shouldn't be afraid of delivering less.