Project Management

Please login or join to subscribe to this thread

When a project falls behind, should we accelerate immediately or first understand why the delay occurred?

linkedin twitter facebook   Construction   Scheduling  
avatar
SANJEET TERI
Community Champion
Consultant| Timely Nexus Project LLP Greater NOIDA, Uttar Pradesh, India

A delay may be caused by lack of resources, late approvals, design changes, procurement issues, productivity problems, or activities outside the team's control. Adding resources or overtime may not solve the underlying problem and can sometimes increase cost without recovering the schedule.

Before deciding on acceleration, we should understand the cause, impact, critical path, available options, and cost of recovery.

When a project is delayed, should the first priority be to understand the root cause and develop the right recovery strategy or should we accelerate immediately to protect the completion date?

Sort By:
avatar
Aaron Porter
Community Champion
IT Director| Blade HQ Payson, UT, United States
What do project and organizational leaders value?

I can't speak for project managers in all industries or companies, but in my experience there are circumstances where you can both accelerate and investigate, especially if the cause is in the past. You can prefer one over the other, but if you aren't fully blocked and your investigation into root cause leads to further delays you may be pressured to get the project moving, again, before you have all the answers. Yes, this can lead to further problems. It often becomes a question of tradeoffs and the risks/opportunities that have the decision-makers' attention.
I’d understand the cause first. Adding more resources or overtime can sometimes make things worse if the real issue is dependencies, competing priorities, or people already being stretched across other projects. The recovery plan should address the actual constraint, not just the delayed schedule.
avatar
Keith Novak Tukwila, Wa, United States

I would argue that the first step is not to find the root cause, but to understand the impact of the delay. The root cause of some problems are difficult and time consuming to identify, while bringing the project back on track may be critical, and the root cause may only help avoid future problems not fix the current one.

First figure out the implications of the schedule impact, and then triage the solutions. If the project was an emergency room patient who had severe bleeding from a car accident, the first step would be to stop the bleeding, not to check whether the car had faulty brakes.

avatar
Luis Branco CEO| Business Insight, Consultores de Gestão, Ldª Carcavelos, Lisboa, Portugal
Sanjeet, I would separate a delay from the decision to recover it.

Before accelerating, we first need to establish whether the delay actually threatens a relevant milestone or project completion date. An activity can be late and still have sufficient float, while another seemingly small delay can alter the critical or near-critical path.

Root-cause analysis matters, but so does forward-looking schedule analysis.
We need to understand what caused the variance, whether that cause is still active, which recovery actions can actually change the forecast, and what additional cost, risk or rework those actions introduce.

So I would not frame the choice as analysis versus action. The stronger question is: what minimum understanding do we need before committing to a recovery action, and is protecting the date worth the trade-offs required to recover it?

Please login or join to reply

Content ID:
ADVERTISEMENTS

"A nod's as good as a wink to a blind bat"

- Eric Idle, Monty Python's Flying Circus

ADVERTISEMENT

Sponsors