How to use project crashing to work smarter

Everyone knows that change is a constant in the business world — but so is time. 

The time you have (or don’t have) dictates project schedules, product delivery, and even business strategies. And it doesn’t stop when roadblocks arise.

Completing a project on time can maximize profits, minimize stress, and help you plan for future endeavors. And on-time, or even accelerated, deliverables might be just what you need to impress clients and customers.

If you’re starting to rush, project crashing is a powerful strategy when time gets tight to fast-track tasks — without compromising quality.

Project crashing is a strategy that accelerates completion by cutting down the time it takes to complete one or more tasks. There are several ways to apply it, and each depends on how or where your project needs compressing. 

Some of the most common techniques you might encounter are:

• Allocating additional resources — this includes assigning more team members and equipment or bringing in external resources to expedite a necessary task.

• Adjusting task dependencies — you could rearrange sequential tasks to run concurrently to complete them faster.

• Reducing project scope — eliminating product features or non-essential tasks are both ways to adjust your project scope and compress your delivery schedule.

The basis of project crashing is time reduction, making it intrinsically tied to the triple constraints of the : cost, time, and scope, with quality right in the middle. 

Reducing the time involves allocating more resources to tasks, thus increasing costs. So to balance out the triangle, your project scope needs narrowing. These adjustments will affect the quality of your product or service. Crashing a project is a delicate system, and the goal is to find a way to save time while keeping costs down and quality up.

While effective, crashing is generally a last resort tactic because it could skew your project timeline template and increase cost. But there are still several strategic reasons you might choose to go this route. These include:

• Unrealistic scheduling — clients and stakeholders might push forward an important project might get pushed forward, forcing a time crunch.

• Critical path delays — delays could hold tasks up due to scope creep or other unanticipated occurrences.

• Incentive bonuses — faster project completion could lead to higher profits and other rewards, encouraging the team to adjust the timeline.

• Competition — it may be crucial to get your product out to market to maintain or establish a competitive edge.

• New projects — you could need to free up time for team members who need to on other projects.

While the above reasons are common, this is by no means an exhaustive list. There are myriad scenarios to consider before crashing the schedule you initially developed. The key is to carefully weigh the pros and cons of each situation that comes up.

If you do need to crash your project, it doesn’t have to be a recipe for disaster. There are six steps to follow to do it right:

Before you begin crashing, understand its need and what it accomplishes. Because it’s a last-measure strategy, other options might be wiser. You could find that reducing scope removes any reason to shorten task time, or that adjusting the project’s overall deadline fixes the problem.

Review the list of all tasks in your existing project timeline. Separate the essential (critical) tasks from the secondary (non-critical) ones to establish which ones you absolutely have to complete on time — also known as your critical path. Crashing a non-critical activity might not reduce project time, so focus on the ones that are high-priority and high-reward. 

Compressing project tasks directly affects budget and scope, so handle this step with care. Calculate and compare the costs of your time-saving tactics to help decide the best route to take. Remember that the cheapest might not be the best, because you shouldn’t lose quality from the picture.

Each task will reach a point where crashing is no longer possible. This could be due to a lack of resources or high expenditures. Knowing these limits will help you optimize your crashing strategies.

After reviewing all of your options, it’s time to determine your course of action. Make sure the whole team understands all of the trade-offs they’re making, and allow for flexibility if you think further changes might come up. Strive for a balance between saving time and keeping your budget within reason — again, without sacrificing quality.

Now that you know which critical tasks to crash and how you plan on doing so, it’s time to create the amended budget and present it to your stakeholders for approval. The plan might need some adjusting, so give yourself time to find the right path.

Every project is unique, and you need to tailor your crashing strategies accordingly. Here are some practical tips and best practices to maximize your chances of success:

The earlier you decide to crash a project, the easier it is to manage the process. This is especially true if your crash involves major changes to your project plan, such as adding and training new team members or seeking out less expensive suppliers. Early crashing also minimizes the need to reduce project scope late in the game.

As a general rule, the longer it takes to complete a task, the more room you have to crash it. Knowing the length of time required for each activity allows you to visualize where time-cutting is most tangible and effective. Keeping track of task float is a good practice, regardless of whether you end up crashing later.

Decide which tasks to crash by comparing the costs with the benefits. Consider elements like your available resources, training, and any equipment you may need to purchase. Sometimes, it’s worth it just to complete something late instead of going over budget or risking team burnout.

Having everyone on the same page is critical when project crunching. You want your team to know the expectations and timelines — and understand why things are changing. Failing to communicate could lead to confusion or low morale.

Even if the pressure is on to shorten your project’s timeline, make sure the crash you propose has feasible timelines and achievable outcomes for everyone involved. Finishing a month-long campaign might be possible hypothetically, but it’s more difficult in practice. Be honest about what you can actually accomplish.

Although crashing a project is sometimes the right approach for completing your project quicker, it does come with risks. Navigating these risks, and project crashing as a whole, is easier with meticulous planning, informed decisions, and the right tools — but that doesn’t eliminate every downside.

Some things to look out for are:

1. Team burnout — crashing has the potential to your team thin, especially if they’re taking on additional or unanticipated work. Work hours or task loads could increase, which may lead to tired, stressed-out team members.

2. Increased costs — because you’re bringing in more resources during your project crash, your project budget will probably increase. This may cause delays while you try to get approvals, and it could worsen your profit margins down the line.

3. Communication issues — as things get hectic, issues such as miscommunication and ineffective task delegation may come into play, complicating your project instead of streamlining it.

4. Quality of work — squeezing tasks too tight might involve cutting corners or eliminating features, which can affect the final quality of the deliverable.

Project crashing is an effective method when you need to expedite timelines. But it’s a delicate system, and your team needs a project management workspace that supports it.

Notion’s templates give you the tools you need to crash your project without it falling. Automatic effort and project trackers can help you plan out the details, and you can refine goals and keep an in-depth schedule in the same place. Do it all with Notion.