7 warning signs your IT project is losing control

For weeks, a project may still look normal. Meetings happen, the team stays busy, reports sound reassuring and invoices follow the schedule. Yet nobody can answer a few basic questions: what works today, what remains, why the latest date is credible and what it will cost to finish.

That does not automatically mean the project has failed. It does mean it may be losing control.

PMI's Pulse of the Profession 2026 reports that, across complex projects in multiple industries, 28% of respondents identified budget overruns and 34% identified stakeholder decision delays as consequences of poorly managed complexity. Both mechanisms are familiar in technology delivery.

1. You have not seen a working end-to-end process for weeks

A list of completed tickets is not the same as a usable outcome. Interface, API and database tasks may all be marked complete while the user still cannot finish a real business process.

Ask the team to demonstrate a critical flow in the test environment using realistic roles and data. Working software is harder to cosmetically improve than a percentage on a status slide.

Control question: What can a user complete end to end today without a manual workaround?

2. The date moves, but the new date is not based on remaining work

A delay is not automatically a crisis. A replacement deadline with no bottom-up forecast is a warning sign.

“Two more sprints” is not a plan unless the remaining scope, dependencies, team capacity, testing and deployment work are visible. The forecast should explain its assumptions and what could invalidate them.

Control question: Which specific tasks and assumptions produce the current completion date?

3. Essential items keep appearing “out of scope”

This often indicates an incomplete or differently interpreted specification rather than deliberate misconduct. The situation becomes dangerous when launch-critical elements — migration, permissions, error handling, production setup or documentation — repeatedly require new funding.

Classify each disputed item as a defect, agreed scope, clarification or genuine change before discussing its commercial treatment.

Control question: Which contract, requirement or approved decision supports each side's interpretation?

4. Changes are approved, but nobody knows their combined impact

Change is normal. Uncontrolled change is expensive.

Every meaningful request should record the reason, classification, cost and schedule impact, effect on other scope, recommendation and decision owner. If accepted changes do not update the backlog and forecast, the change log is only a diary.

Control question: What is the total cost and time impact of all approved changes?

5. The status remains green despite visible problems

A permanently green RAG status can mean reporting is designed to calm stakeholders rather than trigger decisions. Agree objective thresholds for green, amber and red, then connect the status to current risks, deviations and required actions.

Amber is not a failure. It is useful early information.

Control question: Which facts justify the current colour, and what would cause it to change?

6. You know how much has been spent, but not what finishing will cost

Spend to date does not predict the remaining effort. What matters is the estimate to complete (ETC): the time and money required from today to a usable release.

Late work often includes expensive uncertainty — integrations, migration, end-to-end testing, performance, security and production readiness. Build the ETC from the remaining scope, not by subtracting spend from the original budget.

Control question: What will it cost to reach the smallest useful production scope from the current state?

7. Meetings focus on blame rather than resolution

When every discussion becomes a defence of responsibility, the project needs a shared factual baseline: agreed scope, decisions, changes, delivered outcomes, open risks and obligations on both sides.

Responsibility still matters, especially contractually. But recovery is difficult when the client and vendor do not even agree on the current state.

Control question: Do both parties agree on the facts, even if they disagree on liability?

Two-minute project control test

Answer “yes” only when you can identify a document or person who can confirm it. Count the “no” answers.

1. Can you show what works end to end today?
2. Do you know the specific remaining scope?
3. Is the current deadline based on an estimate of that work?
4. Does every significant change have an assessed cost and time impact?
5. Do you know the estimate to complete?
6. Are acceptance criteria clear to both sides?
7. Do client and vendor agree on the current project state?

0–1 “no” answers: basic control mechanisms are operating, even if the project has issues.

2–3 “no” answers: run an internal review and rebuild the missing information.

4 or more “no” answers: the organisation probably no longer has a reliable overall view.

Regardless of the result, do not make another major funding decision based only on money already spent. Sunk cost is not evidence that continuation is rational.

One practical test

Ask the vendor for a list of the most important business processes currently working end to end in the test environment, with the date each was last successfully verified.

If the list appears within hours, delivery may be under control despite delays. If it takes a week or produces ambiguous answers, you have a concrete reason to inspect the real project state.

For an independent review, see IT project recovery and health check or describe the situation.

Data source

• Project Management Institute, Pulse of the Profession 2026: Driving Success in Complex Projects: PMI report.