Why in the world would you want to “crash” a project plan? The very use of the word “crash” seems to purvey a sense of doom.
If you’re not familiar with the “crashing” process, it involves taking a current project plan’s Gantt chart and looking for opportunities to make the chart predict an earlier completion date.
In some cases, this is a completely legitimate practice. If you have tasks that can be done at the same time by two different people or tasks that are erroneously dependent upon each other, you can possibly shorten the timeline by crashing.
However, I’ve also observed the practice of having an already promised date set for a project, and then having your project managers actually figure out how long it will actually take. When realistic expectations are inevitably longer than promised, the discrepancy will either be:
- Allowed to slip for the time being if comfortably close to the original promised date.
- Immediately scrutinized for tasks that take “too long”. (Build a highway: 1 year… Change that to 2 days.)
Ultimately, there will be a process of crashing either at the start of the project or in the middle of the project. Unfortunately, response to reality taking longer than promised is often to redefine what reality should be instead of actually trying to accept reality.
The end result becomes a crashing of the project instead of the project plan.
Leave a Reply