Schedule Crashing
Planning a project is a lot of work. There's dependencies, resources risks, assumptions, competing stakeholders and more. You've got to juggle all of those thoughts and demands and somehow come up with a project plan that gets you from nothing to something.
And then you realize some task won't get completed on time... There's just too much work. Luckily there's a way to help speed that up - crashing. Crashing a task is basically throwing more people at it to get it done faster. Only have one person and have ten widgets to build? Get five people and go five times as fast.
It is a great option for o help speed things up, but has several limitations that need to be understood....
You need to right resources
Every task in a project has a specific set of skills needed to complete. For example building a website requires someone who knows HTML and CSS. This need should be accounted for in planning to ensure the task can be accomplished, however, it doesn't mean you'll have others with the skill available to crash a task.
Depending on your team you could get lucky and have multiple individuals who have the necessary skills available to crash something. You might even be able to get by having one resource quickly train others (although this introduces a risk that they'll do something incorrectly...).many times, however you simply may not have the correct resource available.
Crashability
Many tasks can benefit from crashing. Data entry is one example I frequently run into... Two people will update a spreadsheet twice as quickly as one. Some physical tasks, like moving materials or preparing a work site are also good examples as multiple people can work together to speed them up.
There are, however, tasks where that isn't true... The standard example is having a baby - there simply isn't a way to speed that process up. Some tasks require waiting - for example proofing bread - that cannot be sped up even with more resources.
The challenge is to understand the difference - which takes can you crash, and which can you not? There are some characteristics I look for when trying to figure out if a task is crashable:
Repeatability - Are aspects of the task repetitive? If they are then the task may be a good candidate for crashing. Since the action actions happen multiple times they’re easier to train up others on, and there are more opportunities for others to help. Data entry is a good example of this.
Complexity - Simpler tasks tend to be more crashable as the skills needed are more widely available. This makes it more likely that your team has the skills spread across multiple resources.
Resource Availability - Getting more resources to work on a single task is more expensive - either in time, money or opportunity. There may be times when you simply cannot afford to crash since your resources are tied up elsewhere.
Crashing can be a great way to get things done in time - but like any tool you need to know how it’s best used, and the tradeoffs!
