You take over a team and find the project reported as on track is months late. What do you do?

Find the truth from artefacts, not opinions

You have two conflicting accounts — a status history saying green and your own instinct saying otherwise — and the first mistake available is escalating on instinct. A new manager who declares a project red in week one and turns out to be wrong has spent all their credibility on a guess, and a new manager who spends six weeks investigating has become part of the problem. Give yourself days, not weeks, and get the position from things that exist rather than from what people believe.

What counts as evidence: run the software yourself and see what it does, in whatever environment is closest to production. Look at what has actually merged over the last two months rather than at tickets, since a board can move without anything shipping. Read the last three status reports against what was merged in those weeks. Find the integration points and check whether anything has been integrated end to end even once, because "each piece is nearly done" and "nothing has been connected" coexist very comfortably. Ask what testing exists for the parts declared complete. And ask each engineer individually what they think is left, because the aggregate of five private estimates is usually closer to true than any figure that has been through a group meeting.

Then form a position with a number attached and a confidence you can defend. "About three months behind, and I will know within a fortnight whether it is three or five" is a usable statement. "Significantly behind" is not.

Say it once, early, with options

Bad news degrades with age, and a schedule slip discovered by your stakeholders in fragments is much worse for you than the same slip stated plainly in one conversation. Go early, go once, and bring choices rather than a confession. What your leadership needs is not an explanation of how the project became late; it is the ability to make a decision this week.

"I need to correct the reporting on the migration. My assessment after ten days is that it is roughly three months from a releasable state, not three weeks. That is my number and I own it from here.

What I have found: the four services are individually well built and none of them have been run together, so the integration work — which is where this kind of project usually spends its time — is entirely ahead of us rather than behind us. There is also no migration path for the existing accounts, which was assumed to be part of a later phase and is not.

Three options. We can hold the full scope and land in November, which I would put at seven in ten. We can cut the reporting and bulk-edit features and take the core migration live in September for the new accounts only, with existing accounts following, which I would hold at eight in ten. Or we stop and reassess whether the whole thing is still worth three more months, which I do not recommend but should be on the table given what has already been spent.

My recommendation is the second. Whichever you pick, I will be reporting fortnightly against a baseline I have rebuilt from what is demonstrable, and the first one goes out on Friday."

Note what that message does not contain: any account of who reported what before you arrived. Blaming your predecessor buys you nothing — it reads as excuse-making, it tells your new leadership how you will describe them one day, and everybody in the room can do the arithmetic about the previous reports without your help. Own the number from the day you arrive and let the history be inferred.

What you say to the team

The team has been living inside optimistic reporting, and their situation is more complicated than it looks. Some of them have been saying it was late and were not heard, some have been optimistic because that is what optimistic status reporting selects for, and most are braced for a new manager to arrive and blame them.

Two messages, in this order. First, that the reporting is your problem now and you are not looking for who to hold responsible for the last quarter. That is not softness — an audit of past reports guarantees that nobody tells you anything difficult for the rest of your tenure, which is the exact failure you are trying to end. Second, that from now on the standard for "done" is demonstrable, and that reporting a slip early will never be penalised while a surprise near a deadline will be treated as serious. Then behave consistently with that the first time someone brings you bad news, because the whole team is watching what happens to that person.

Expect one or two people to tell you privately that they raised it before. Take those conversations seriously and be careful with what you do next: those engineers are your best source of information and also the most exposed if you quote them.

Replace the mechanism, not just the number

Re-baselining a late project without fixing how it came to be reported green produces a second false green in two months. The mechanism is nearly always structural rather than dishonest.

What produced false green	Replacement
Status derived from a per-cent-complete figure someone estimated	Status derived from what can be demonstrated running
"Done" meaning the code is written	Done meaning merged, integrated, tested and deployable behind a flag
Integration deferred to a phase at the end	Something integrated end to end within the first fortnight, however thin
Green or red as the only two states, with red carrying blame	A stated confidence and a named risk on every report
A single date months away with no interim checkpoint	Fortnightly checkpoints, each with something observable

The two lines with the most leverage are the definition of done and the early integration. A project where four components are each ninety per cent complete and have never met is not ninety per cent complete; it is a project whose remaining risk has been carefully preserved for the last fortnight. Getting a thin end-to-end path working early is unglamorous and is the single most effective way to stop the same thing recurring.

The other half is cultural and slower. Ask what happened the last time someone reported red in this organisation. If the answer is that the project got a review committee, an extra reporting line and a questioning of the team's competence, then the incentive that produced the green reports is still intact and your team is being sensible rather than dishonest. You cannot fix that unilaterally, but you can absorb it: be the person who reports red upward, take the resulting scrutiny yourself rather than passing it down, and make sure the engineer who told you the unwelcome thing is visibly better off for having done so.

The recommendation nobody wants to make

Keep cancellation genuinely on the table. Work already spent is not a reason to spend more, and a new manager is in the rare position of being able to ask whether this project would be started today, given what is now known about its cost and the value it was justified by. Sometimes the answer is no, and saying so in your first month — with the analysis to support it, and a proposal for what the team does instead — is a stronger opening move than heroically rescuing something that should not exist. It is also the recommendation that requires you to be least attached to being the person who saved the project.