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.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).