What I Look For When a Project Is in Trouble

Not every project runs smoothly from beginning to end. Even with careful planning, experienced teams, and clear goals, unexpected challenges appear. Requirements change, technical problems take longer than expected, and important work falls behind. Sometimes I am asked to help a project that has already started to slip, and sometimes a project I am running hits a rough stretch of its own. None of that means the project has failed. It means the project needs a different approach.

In almost every case, the biggest challenge is not the delay itself. It is uncertainty. People are unsure of the real status. Different reports show different things. Some of the team are hopeful, others believe it is much worse than anyone is saying. Without a clear view of reality, good decisions become almost impossible. So steadying a project in trouble is a particular skill, and it begins with staying calm when others are not.

Finding the Truth Before Trying to Fix Anything

When a project is in trouble, people naturally want quick solutions. A new plan. A new deadline. More people. More meetings. I have learned that none of that matters until I understand the real situation, and finding the truth is often the hardest part. As a project falls behind, people become uncomfortable sharing bad news. Some hope the problem will solve itself. Others worry about disappointing the client or the leadership. Over time the reports start to look better than reality, and that is dangerous, because decisions are then built on information that is not true.

I once took on a retail and logistics delivery, a new warehouse dispatch system, that the reports still showed as broadly on track. When I sat with the team and asked plain questions, the honest answer was that we were about six weeks behind and the plan on paper had stopped meaning anything. That gap between the report and the reality is common, and it is why I always begin by talking directly with the people doing the work rather than relying on a status update. What has been completed? What is still waiting? What is preventing progress? Which tasks worry you the most? Those conversations give a far clearer picture than any report.

Creating the right environment matters just as much. People should feel safe explaining what is really happening without fear of blame. If team members believe they will be criticised for raising problems, they will hide them, and I cannot solve a problem I am not allowed to see. When they know the goal is to solve things together, they become much more open.

I also compare progress against the original plan, because the numbers alone can mislead. Sometimes a project looks only slightly behind, but the remaining work tells a very different story. Other times the delay looks serious, yet most of the hard work is already done. Only once I have that clear picture do I start making recovery decisions. Before then, every solution is just a guess.

Focusing on the Few Problems That Matter Most

Once I can see the real position, I resist the urge to fix everything at once. A project that has fallen behind often looks overwhelming. Missed dates, unfinished features, technical issues, shifting priorities, and growing pressure from stakeholders all arrive together, and at first every one of them feels urgent. In reality, usually two or three problems are causing most of the difficulty. My job is to find those first.

I start with a simple question. What is stopping the project from moving forward today? The answer is often surprisingly clear. On that dispatch system it was two things. A single connection to the carrier’s booking service kept slipping, and it was the one piece of work the whole launch depended upon. And the software had become too unstable to test properly. Rather than spread my effort thinly across a hundred smaller worries, I put the team’s attention on those two. Once the biggest obstacle is removed, many of the smaller problems begin to solve themselves.

I also make sure every critical task has one clear owner. Shared responsibility sounds positive, but under pressure it creates uncertainty, because when everyone assumes someone else is handling an important issue, progress simply stops. So we gave one named person responsibility for the carrier connection. A single owner creates accountability and makes communication far simpler.

Then I reduce unnecessary work. When a project is already struggling, adding new features or accepting more requests rarely helps. The team needs stability before it can take on anything more, so we stopped adding new work until the software became stable enough to test. This also helps the team regain confidence. Instead of staring at a list of problems that feels impossible, they start achieving real progress one step at a time, and each completed piece builds momentum and reminds everyone that recovery is possible.

Bringing Back the Basics, Gently

Once the biggest problems are identified, the next step is rebuilding the way the project is managed. Very often a project is in trouble simply because the ordinary discipline has fallen away. There is no plan anyone believes in, the risks are not being watched, and no one is quite sure what finished means any longer. Rather than introduce new processes, I bring the fundamentals back, one at a time.

The first is a realistic plan. I will not keep using dates everyone knows are no longer achievable, because that only breeds frustration and drains confidence. So I agreed a fresh, realistic schedule with the team and treated it as the new line we would measure against, instead of pretending the old dates still held. It may not be the plan we originally wanted, but it is one people can believe in, and every discussion and decision is measured against it.

I also brought back a simple, honest way of marking where each part of the work stood. These progress reviews are not about blame. They are about understanding what has moved, what is blocked, and what support the team needs, and keeping them simple and consistent lets small issues get resolved before they grow. Part of that honesty is letting bad news be visible. I let the carrier connection be recorded plainly as being in serious difficulty until it deserved better, because a status that hides trouble helps no one.

Alongside that, I restore the review of risks and a shared understanding of what finished means. A project under pressure often stops thinking about future problems because everyone is buried in today’s work, yet naming new risks early gives the team time to prepare instead of reacting at the last moment. And when a task is reported as done while testing is unfinished or feedback is still pending, progress reports stop being reliable. Putting these small things back calms a project more than any dramatic gesture, because recovery does not come from one impressive meeting. It comes from following a clear plan every day.

Being Honest About What Can Realistically Be Delivered

One of the hardest parts of recovery is the honest conversation about what can actually be delivered. When a project falls behind, there is real pressure to keep the original promises, and people hope the team will somehow recover the lost time without changing the date or the scope. Sometimes that happens. Most of the time it does not, and a project in trouble usually cannot keep all of its original promises. Pretending otherwise only makes matters worse.

So I look at what can genuinely be delivered with the time and people available, and I ask a simple question. What is the most valuable outcome we can still achieve? The answer is not always every planned feature. On the dispatch system, I explained that we could still meet the peak trading season if we reduced the scope. The returns handling feature was important, but it was not essential for the initial launch, so it could follow in a fast second release. That protected the date that actually mattered to the business, and it brought the six weeks back to a fortnight against a date people could believe in.

I always involve the client and key stakeholders in these decisions. A recovery plan should never arrive as a surprise, so I explain the current situation, the options, and the effect of each one. When people understand the reasons behind a recommendation, they are far more likely to support it. And I never make a promise simply because it sounds encouraging. An unrealistic promise buys a little confidence today and a bigger disappointment later. I would rather set a realistic expectation and meet it.

This also protects the people doing the work. When expectations stay unrealistic, teams work longer and longer hours to chase lost time, and that is rarely sustainable. Tired people make more mistakes, quality slips, and recovery gets harder. A realistic plan lets the team work with focus instead of constant pressure. People can cope with difficult news. What they cannot cope with is being led on and then let down.

A Real Project That Reinforced These Lessons

The warehouse dispatch system I mentioned showed all of this in one place. According to the regular status reports, everything looked reasonably healthy. There were a few delays, but nothing that suggested serious trouble. Before making any decisions, I spent time with the team, and instead of trusting the reports I asked simple questions about what was done, what was still pending, and the biggest challenges they faced. The conversations revealed a very different picture. The project was about six weeks behind, the plan no longer reflected reality, and the team had already stopped using it as a guide.

Once we understood where we truly stood, we looked for the issues causing most of the delay. There were many small problems, but two stood out: the carrier booking connection was still incomplete, and the software had become too unstable for reliable testing. Rather than solve everything at once, we put all our attention there. We gave the carrier connection one clear owner and paused unnecessary work until the software was stable enough for testing to continue.

At the same time, we accepted that the original delivery plan was gone. Together with the client, we reviewed the remaining work and identified what carried the greatest business value. The returns handling feature was important but not essential for the first launch, so we agreed to move it into the next release and protect the core dispatch system for the busiest trading period. That single decision took a great deal of pressure off the team while protecting the goal that mattered most. Throughout the recovery we communicated openly. There was no attempt to hide the delay or manufacture false confidence. We shared the updated plan, explained every decision, and reviewed progress regularly. As the team completed the most important work, confidence slowly returned, because people could see real progress instead of feeling permanently overwhelmed.

By the end we had recovered most of the lost time. We did not hit the original schedule, but we delivered the core solution in time for the business to use through its busiest season, and the remaining feature followed shortly afterward in a second release. I rarely remember the six week delay now. What I remember is how quickly things improved once everyone accepted the truth, focused on the right priorities, and worked toward a plan they genuinely believed they could achieve.

Common Mistakes I Still See

After helping recover several struggling projects, I have noticed the biggest mistakes are rarely technical. Most come from the way the project is managed once problems appear.

The first is refusing to accept the real situation. People keep reporting that everything is under control even when the project has clearly fallen behind, hoping the team will somehow recover without changing the plan. Hope is not a recovery strategy. The sooner everyone understands the true position, the sooner real action can begin.

The second is trying to solve every problem at the same time. Under pressure everything feels urgent, and teams jump from one issue to another without real progress. Recovery becomes far easier once the team names the few problems causing the greatest impact and solves those first.

The third is following a plan nobody believes anymore. The dates no longer reflect reality, yet they stay unchanged because people are afraid to update them. That breeds confusion and drains confidence. A realistic plan can be hard to accept, but it gives the team a clear direction and lets everyone measure genuine progress.

The fourth is avoiding the difficult conversation. Some managers delay telling a client the project is behind because they hope it will improve. That almost always makes the final conversation harder. Honest communication, even when the news is difficult, builds trust and gives stakeholders time to make informed decisions.

The fifth is blaming the team. When a project struggles it is easy to focus on who made a mistake, but that rarely helps. People who feel blamed become more careful about sharing problems, which makes recovery harder. It is far more productive to understand the cause and solve it together.

And the last is continuing to accept new work while trying to recover an already delayed project. Every new request divides attention and makes recovery harder. Wherever possible, I stabilise the current work before allowing any more change. Recovering a project is not about finding perfect solutions. It is about making clear decisions, communicating honestly, and restoring confidence one step at a time.

The Biggest Lesson

If there is one lesson that has stayed with me, it is that projects are rarely saved by working longer hours or asking people to try harder. They are saved by clear thinking, honest leadership, and realistic decisions. Early in my career I believed recovering a project meant finding a way to catch up with the original plan. Over time I realised that is not always the right goal. Sometimes the original plan is simply no longer possible, and holding on to it only creates more pressure and more disappointment. The better approach is to understand where the project stands today and build a recovery from that point.

People respond far better to honesty than to false confidence. No client wants to hear that a project is behind, and no team enjoys admitting work has taken longer than expected. But once everyone understands the real situation, meaningful decisions become possible, and trust starts to return because people know they are working with accurate information instead of hopeful assumptions. Recovery is also about creating focus. A struggling project feels chaotic because too much is happening at once, and my job is to reduce that. Name the most important priorities. Remove the distractions. Give the team a clear direction. When people know exactly what they need to achieve, confidence and steady progress return.

Finally, I protect the team. People working on a project in trouble are often tired and discouraged, and a manager who adds pressure and blame only makes things slower. The developers on that build were not short of effort. They were short of a clear, achievable path and someone to absorb the noise from above. So I gave them the reduced scope, the honest plan, and the confidence that we would get there together. A steady hand and a calm plan can turn a project around, not because the problems were small, but because the people were given a reason to believe again.

Key Takeaways

• Stay calm before making any decisions.
• Find the truth before trying to fix the problem.
• Speak directly with the team to understand what is really happening.
• Focus on the few issues causing the biggest delays.
• Build a realistic recovery plan that everyone can believe in.
• Be honest with clients and stakeholders about what can realistically be delivered.
• Reduce unnecessary work and protect the highest business priorities.
• Give every critical task a single clear owner.
• Support the team instead of placing blame.
• Rebuild confidence through steady progress, clear communication, and realistic expectations.