Skip to main content

Kleios Technologies

PROJECT MANAGEMENT GUIDE

How to Take Control of a Project That Is Falling Behind

Projects rarely fall behind for one reason. Delayed decisions, unclear priorities, coordination problems, resource constraints, and unresolved issues can gradually affect delivery. This guide provides a practical approach to understand what is happening, regain control, and move the project forward.

Practical Guide · Project Management

The Project Challenge

A project rarely falls behind because of one missed activity or a single bad decision. In real project execution, delays often develop gradually as several problems begin to interact. A decision takes longer than expected, a team waits for information, a supplier misses a commitment, priorities change, or an issue remains unresolved while other work continues around it.

At first, these problems may appear manageable. A few days of delay here, an incomplete deliverable there, or a pending approval may not seem serious enough to require immediate intervention. But when these issues affect dependent activities or consume already limited resources, the impact can spread across the project.

The situation becomes more difficult when different teams have different views of what is causing the problem. The project team may see a resource constraint, while management sees a performance issue. A contractor may be waiting for a decision, while the project team assumes the work is progressing. In complex projects, dependencies between teams, organizations, technologies, and external parties can make these gaps even harder to identify.

Another common challenge is visibility. Project leaders cannot take effective corrective action if they do not have a realistic and timely picture of what is happening. Project information may be spread across different teams, systems, contractors, reports, and meetings. By the time an important execution problem reaches the right decision-maker, the project may have already lost valuable time. McKinsey’s research on major capital projects highlights this problem: delays can take days or weeks to reach leadership, while inconsistent or outdated information can make it difficult to identify the underlying cause and respond quickly.

The pressure can then increase. Teams may try to recover time by adding resources, accelerating activities, working longer hours, or changing priorities without first understanding the actual cause of the delay. These actions may provide temporary relief, but they can also create rework, additional coordination problems, quality issues, or new dependencies if applied without proper assessment.

This is why taking control of a project that is falling behind is not simply a matter of speeding up the work.

The project manager first needs to establish what is really happening, understand why the project is losing momentum, identify which problems matter most, and determine where intervention can make a meaningful difference.

The objective is not to make every activity move faster. The objective is to restore the project’s ability to move forward in a controlled and coordinated way.

That is the practical challenge this guide addresses.

Why Projects Fall Behind

Projects usually fall behind because several execution problems interact rather than because of one isolated delay. A project manager therefore needs to look beyond the immediate missed activity and understand what is creating the loss of momentum.

1. Decisions and Approvals Take Too Long

Work often stops or progresses slowly when the project team is waiting for a client decision, management direction, design approval, technical clarification, commercial decision, or regulatory approval. PMI/KPMG found delayed decision-making and regulatory approvals to be significant contributors to time overruns in Indian infrastructure projects.

The problem becomes more serious when the waiting time affects several dependent activities. A decision that appears small at management level can prevent an entire team or contractor from moving forward.

2. Teams and Activities Depend on One Another

Projects are networks of interdependent work. One team’s output may be another team’s starting point. When an input, drawing, specification, approval, material, system, or deliverable is late, the impact can move beyond the original activity.

PMI research on schedule risk identifies dependencies and missing inputs as recurring causes of schedule disruption.

3. Priorities and Requirements Keep Changing

Projects can lose momentum when teams repeatedly change direction. New requirements, design changes, revised priorities, or additional work can create rework and disrupt commitments that were already being executed.

This is particularly challenging when changes are introduced without properly assessing their effect on existing work and dependencies. PMI research on project delays identifies design changes, added scope, and rework as recurring contributors to delay.

4. Resources Are Not Available When Needed

A project may have sufficient resources on paper but still experience delays because the right people, equipment, materials, or specialist capability are unavailable at the required time.

This can happen because resources are shared across projects, priorities change, suppliers are late, skilled personnel are difficult to obtain, or equipment becomes unavailable. PMI/KPMG’s India study specifically identified skilled-resource availability as a significant factor in infrastructure project overruns.

5. Problems Remain Unresolved for Too Long

Some projects do not fail because problems are unknown. They fall behind because known problems remain open without effective ownership or resolution.

An unresolved technical issue, procurement problem, interface issue, commercial disagreement, or resource constraint can continue affecting work week after week. By the time its cumulative impact becomes obvious, several other activities may already be affected.

6. Information Does Not Reach the Right People in Time

Project execution depends on timely and reliable information. Teams can lose time when drawings, specifications, decisions, progress information, approvals, or other inputs are incomplete, inconsistent, or communicated too late.

This is particularly difficult in projects involving multiple organizations. PMI research has identified delays in obtaining information as a significant source of schedule slippage.

7. Rework Consumes Planned Capacity

When work has to be repeated because of errors, incomplete requirements, design changes, poor coordination, or quality problems, the project loses productive capacity.

The impact is not limited to the time spent doing the work again. Rework can also disrupt other activities, consume resources that were committed elsewhere, and create additional coordination requirements. PMI’s research on the rework cycle highlights how projects can move behind schedule when teams fail to account for the need to rework their plans and activities as conditions change.

8. The Project Plan No Longer Reflects Reality

A project can continue using an outdated plan even after the actual conditions have changed significantly.

If priorities, resources, dependencies, requirements, or external conditions have changed but the project continues to be managed against assumptions that are no longer valid, the reported position can gradually become disconnected from reality.

The result is often a project that appears manageable in reports but is increasingly difficult to execute in practice.

9. External Factors Disrupt Execution

Some causes are outside the direct control of the project team. Regulatory approvals, land or site access, market conditions, weather, supply-chain disruption, contractual disputes, and other external factors can affect delivery.

PMI/KPMG’s Indian infrastructure research found external factors—including regulatory approvals, land acquisition, and market conditions—to be material contributors to time and cost overruns.

10. The Project Team Reacts to Symptoms Instead of Causes

This is where several problems become particularly dangerous.

When a project starts falling behind, the immediate response may be to add resources, increase working hours, accelerate activities, or pressure teams to deliver faster. But if the actual cause is a delayed decision, unresolved dependency, missing information, or repeated rework, simply increasing effort may not solve the problem.

PMI practitioners discussing delayed projects similarly emphasize identifying the causes of delay and distinguishing internal from external causes before deciding how to recover the project.

What Should You Do?

Taking control requires a structured response rather than simply trying to accelerate the work. The following steps help you assess the situation, address the main causes, align the right people, and restore project momentum.

1. Establish the Current Position

Start by creating a realistic picture of where the project stands today. Do not begin by asking the team to recover lost time. First determine what has actually happened compared with what was expected.

Review the status of key deliverables, current commitments, unresolved issues, decisions awaiting action, resource availability, external dependencies, and work that cannot proceed until another activity or decision is completed.

Speak directly with the people responsible for delivery. Project reports provide useful information, but they may not always reveal why work is not progressing. A short discussion with the responsible team member, contractor, technical lead, or stakeholder can expose constraints that are not obvious from a status report.

The objective at this stage is not to assign blame. It is to establish a shared and realistic view of the current situation.

Ask:

  • What was expected to be completed by now?
  • What has actually been completed?
  • What is currently preventing progress?
  • Which commitments are at immediate risk?
  • Which decisions or approvals are still pending?
  • Which teams or activities are waiting for inputs?
  • What has changed since the original commitment?

Once these questions are answered, you have a better foundation for deciding what needs attention.

2. Identify the Main Causes

Once the current position is understood, determine what is actually causing the project to fall behind.

Avoid treating every late activity as a separate problem. Several delays may have the same underlying cause. For example, five activities may be late because one required design approval has not been received.

Group related problems and look for the constraints that are affecting multiple parts of the project.

For each significant problem, ask:

  • What is happening?
    Clearly describe the problem.
  • Why is it happening?
    Identify the immediate cause.
  • Why has that cause not been resolved?
    Look for the underlying constraint.
  • What is the impact?
    Determine which commitments, deliverables, teams, or decisions are being affected.
  • Who can influence the situation?
    Identify the person or organization capable of removing the constraint.

This distinction is important because the visible problem is not always the problem that needs to be solved.

For example, if installation work is behind, adding more workers may appear to be the obvious solution. But if the team is actually waiting for approved drawings, additional workers will not recover the situation. The constraint must be addressed first.

3. Prioritize What Needs Immediate Attention

A project that is falling behind can quickly produce a long list of problems. Trying to solve everything simultaneously can make the situation worse.

Instead, identify the issues that require immediate management attention.

Prioritize problems based on factors such as:

  • Impact on important project objectives
  • Number of downstream activities affected
  • Urgency of the decision required
  • Availability of alternative solutions
  • Resources required to resolve the issue
  • Potential for the problem to become more difficult or expensive
  • Dependence on external parties

A useful question is: “If we resolve only three problems this week, which three will make the greatest difference to the project?”

This forces the project team to focus on outcomes rather than activity.

Some issues may be important but not urgent. Others may be preventing several teams from progressing and therefore require immediate intervention.

The purpose of prioritization is not to ignore less important problems. It is to ensure that limited management attention is directed toward the constraints that have the greatest effect on recovery.

4. Develop Practical Recovery Actions

After identifying and prioritizing the main causes, define specific recovery actions.

Each action should answer four questions:

  • What needs to happen?
    Clearly describe the required action.
  • Who is responsible?
    Assign one accountable owner rather than leaving the action with a group.
  • When should it happen?
    Set a realistic commitment date.
  • What outcome is expected?
    Define what will change when the action is completed.

For example, instead of recording: “Resolve procurement issue.”

A stronger action would be: “Procurement Manager to confirm the supplier’s revised delivery commitment and identify an alternative source for the critical component by Friday.”

The second action is specific, owned, time-bound, and produces a clear outcome.

Recovery actions should also be realistic. Do not create a recovery plan based entirely on longer working hours, additional resources, or optimistic commitments. Consider whether the proposed actions can actually be implemented within the project’s constraints.

Where the problem is outside the project manager’s authority, identify the required escalation rather than allowing the issue to remain open.

5. Align the Project Team and Stakeholders

A recovery effort can fail even when the actions themselves are appropriate if the people involved do not share the same understanding of the situation.

Once the immediate priorities and recovery actions are established, communicate them clearly to the relevant project team members and stakeholders.

Explain:

  • Where the project currently stands
  • What has caused the main problems
  • Which issues have been prioritized
  • What actions have been agreed
  • Who owns each action
  • What decisions or support are required
  • When progress will be reviewed

Be factual rather than defensive. The purpose of communicating a difficult project situation is not to protect the project’s previous status. It is to create the conditions needed to improve the actual situation.

Where stakeholder decisions are required, make the decision request specific. Explain what decision is needed, why it matters, what happens if it is delayed, and when the decision is required.

This makes escalation more effective because stakeholders can see the consequence of inaction rather than simply receiving another project status update.

6. Monitor Whether the Project Is Recovering

Creating recovery actions does not mean the project has recovered.

The project manager needs to determine whether the actions are actually changing the situation.

Monitor whether:

  • Critical problems are being resolved
  • Decisions are being made within agreed timeframes
  • Blocked work is becoming available to the team
  • Recovery actions are producing their expected outcomes
  • New issues are emerging
  • Stakeholder commitments are being fulfilled
  • The project’s immediate priorities are becoming more manageable

Do not measure recovery only by the number of completed actions. An action can be marked “complete” without solving the underlying problem.

For example, a meeting may have been conducted and an issue may have been discussed, but if the required decision has not been made, the constraint still exists.

Regularly compare the current situation with the situation that existed when recovery started.

If the project is improving, continue the recovery approach while gradually returning to normal project management.

If the situation is not improving, reassess the causes. The original diagnosis may have been incomplete, or the selected actions may not be addressing the real constraints.

The objective is not simply to produce a recovery plan.  The objective is to restore controlled project execution and prevent the same problems from continuing to push the project further behind.

Practical Example

Putting the Approach Into Practice

Consider an infrastructure project that is several weeks behind its planned delivery commitments. Several work packages are incomplete, the project team is under pressure, and management is asking when the project will recover.

At first, the situation appears to be a resource problem. The delivery team reports that additional people are needed to accelerate the work. However, the project manager does not immediately add resources.

  • First, the project manager establishes the current position. The review shows that several activities are incomplete, but the most important issue is that a critical technical approval has been pending for several weeks. Two teams are waiting for this approval before they can proceed with their work.
  • Next, the project manager identifies the main causes. The delayed approval is one constraint, but the review also identifies incomplete information, unclear ownership of the approval, and poor coordination between the technical team and the stakeholder responsible for the decision.
  • The project manager then prioritizes the problems. Rather than trying to accelerate every delayed activity, attention is first given to the approval because resolving it will allow multiple dependent activities to move forward.
  • Recovery actions are then established. A specific owner is assigned to obtain the required technical clarification, the responsible stakeholder is given a clear decision date, and the affected teams prepare the work that can proceed immediately once the approval is received.
  • The project team and stakeholders are aligned around the recovery priorities. Everyone understands the immediate constraint, who is responsible for resolving it, what support is required, and when progress will be reviewed.
  • Finally, the project manager monitors whether the recovery actions are producing results. Once the approval is obtained, the previously blocked teams resume work. Progress is reviewed regularly to confirm that the project is actually regaining momentum rather than simply showing more activities as “in progress.”

The important lesson is that the project did not need to accelerate everything at once. By identifying and removing the constraint that was affecting multiple areas of the project, the project manager was able to focus recovery efforts where they could make the greatest difference.

Common Mistakes to Avoid

When a project starts falling behind, pressure can lead to quick reactions. Some responses may appear helpful but can make the situation worse if the underlying problem has not been properly understood.

Trying to Recover Everything at Once

A project manager may try to address every delayed activity simultaneously. This spreads attention and resources too thin. Focus first on the problems that have the greatest effect on project delivery.

Adding Resources Without Finding the Real Problem

Adding people, equipment, or working hours does not automatically recover a project. If the actual constraint is a delayed decision, missing information, or unresolved dependency, additional resources may have little effect.

Treating Symptoms as Root Causes

A late deliverable is often a symptom rather than the underlying problem. Before deciding what to do, determine why the deliverable is late and whether the same cause is affecting other areas.

Keeping Problems at the Project-Team Level

Some problems cannot be resolved by the project team alone. When a decision, approval, or stakeholder intervention is required, delaying escalation can allow the problem to affect more work.

Creating Recovery Actions Without Clear Ownership

Actions such as “follow up,” “expedite,” or “resolve the issue” are difficult to manage without a responsible owner and clear expected outcome. Every important recovery action should have accountability.

Measuring Activity Instead of Recovery

More meetings, more reports, and more completed actions do not necessarily mean the project is recovering. The real question is whether the underlying constraints are being removed and whether project performance is improving.

Hiding the Severity of the Situation

Trying to protect project status by minimizing problems can delay the support and decisions needed for recovery. Accurate information allows stakeholders to respond before the situation becomes more difficult.

Assuming the Recovery Plan Will Work

A recovery plan is a hypothesis about what will improve the project. Monitor its results and be prepared to change the approach if the expected improvement does not occur.

Key Takeaways

Taking control of a project that is falling behind requires more than increasing effort. The project manager needs to understand the situation, address the causes, and focus recovery efforts where they can have the greatest impact.

  • Establish the real current position before deciding what needs to change.
  • Look beyond visible delays and identify the underlying causes and constraints.
  • Prioritize the problems that matter most rather than trying to solve everything simultaneously.
  • Assign clear recovery actions and ownership so that corrective efforts can be tracked.
  • Monitor the results continuously and adjust the recovery approach when expected improvement does not occur.

The goal is not simply to recover lost time. It is to restore controlled execution and prevent the same problems from continuing to affect the project.

References

FEATURED PROJECT MANAGEMENT GUIDES

Practical Guidance for the Challenges Project Professionals Face

Managing projects requires more than knowing established processes and concepts. Our featured guides focus on practical situations, challenges, and decisions that project professionals encounter, providing clear guidance to help them respond effectively.

How to Identify Early Warning Signs in a Project

Recognize emerging signals of project problems, understand their potential impact, and determine when investigation, corrective action, or escalation may be necessary.

How to Manage Difficult Project Stakeholders

Learn practical approaches for handling conflicting expectations, difficult conversations, delayed decisions, and stakeholder pressure while keeping the project focused.

How to Make Better Project Decisions

Use a structured approach to understand project situations, evaluate available options, involve the right people, and make timely decisions with greater confidence.

RELATED KNOWLEDGE DOMAINS

Continue Your Learning Across Related Knowledge Domains

Project Management is closely connected with specialized disciplines that support successful planning, execution, governance, performance measurement, and professional growth. Explore related knowledge domains to expand your expertise, develop complementary skills, and access practical resources across the complete project management ecosystem.

Expand your expertise one domain at a time and build a well-rounded project management skill set.

Why Explore Related Domains?