Nobody Told Me the Project Was Losing Money Until Month Five

I found out my project was underwater in a meeting I wasn't supposed to be in. Someone put a slide up, my project's name was on a red row, and the number next to it was negative. I had been running that delivery for five months and it was genuinely news to me.

The worst part wasn't the embarrassment. It was realising afterwards that I could have known in week six, and that the information had been sitting in plain sight the whole time in a form I had never bothered to learn to read.

Start here, because this is the mechanism and almost nobody explains it.

Your engineer books time in week one. That timesheet gets approved in week two, sometimes week three if she's busy. It lands in the finance system at the end of the month. It gets reconciled against the project code, and against a purchase order, and against a supplier invoice that arrived late. Then it appears in a report. Then that report goes into a monthly pack. Then the pack gets reviewed.

By the time a cost shows up on a slide with your project's name on it, the decision that caused it happened a month and a half ago, and quite possibly two months ago. You cannot manage a delivery on a signal with that much lag. You'd never accept it from your monitoring stack. You accept it from your commercials because nobody told you it was a monitoring problem.

So the first move is to stop treating the finance report as your source of truth about the money and start treating it as the confirmation of something you already knew.

Here's the substitute, and it is much cruder than a finance system and much more useful because it exists on Friday rather than in six weeks.

Take your total budget in days. Not money, days, because days are the thing you actually observe. Say the project sold two hundred and forty engineer days.

Every Friday, write down two numbers. How many days the team has burned so far. And what percentage of the delivery you honestly believe is complete.

That's it. Two numbers, one line in a text file, ninety seconds.

If you're at ninety days burned and you believe you're forty per cent done, the maths says the whole thing lands at two hundred and twenty five days and you're fine. If you're at ninety days burned and you're honestly at twenty five per cent, you're heading for three hundred and sixty days, and you are a hundred and twenty days over a two hundred and forty day budget. In week seven. With a hundred and thirty three days of ammunition left to do something about it.

The whole trick is in the word "honestly". Everyone's instinct at twenty five per cent complete is to say forty, because the hard parts are still ahead and optimism is the default setting of an engineering team in month two. Force the estimate against something observable. Sites live out of total sites. Integrations signed off, not integrations written. If your completion figure can't be checked by someone who isn't you, it isn't a figure, it's a mood.

A worked example of why the lag matters so much.

A 14-person storage team is delivering an archive migration for a television broadcaster, sold at two hundred and forty days. At week seven the lead notices the burn rate implies an overrun of roughly a hundred days. He raises it. Here's what is still available to him at that point:

He can change the staffing mix on a build phase that hasn't started yet. He can put the two additional integrations that appeared in month two through a change request, because the client hasn't yet had them delivered for free and got used to the idea. He can ask the client to fix the environment access problem that is costing his team two days a week, and the ask carries weight because he can quantify it. He can re-sequence so the work with commercial risk sits before, not after, the point at which the budget runs out.

Now run the same project where he finds out in month five, from a slide. The build phase is staffed and half done. The two extra integrations are delivered, in production and referred to by the client as "the agreed scope". The environment access problem has been normalised into everyone's plans. And the conversation he now has with his leadership is not about options, because there aren't any left. It's about explanation.

Same overrun. Same team. Eight weeks of notice is a management problem. Five months is an incident.

This is where technical leads get stuck, and I understand why. Telling your leadership that the money is going the wrong way feels like confessing failure, so the temptation is to wait one more sprint to see if it recovers. It will not recover. Overruns are not self healing and I have never once seen a burn rate quietly fix itself.

The thing that makes this conversation survivable is bringing the shape of a decision rather than the shape of a worry.

A bad flag sounds like: "I'm a bit concerned we might be over budget." That gives the person you're talking to nothing to do except be concerned back at you, and it makes you look like someone who noticed a problem and handed it upwards.

A useful flag has four parts and takes about forty seconds to say. Where you are: ninety days burned, twenty five per cent complete by sites. Where that lands you: roughly a hundred days over, which is a meaningful chunk of the margin. What is causing it: two thirds of it is the environment access delays, one third is the two integrations that were added in March and never priced. What you propose: raise a change request for the integrations, and I need someone senior to have the access conversation with their infrastructure director this week, because it's above my level.

Notice the last clause. Own what's yours, be clear about the part that isn't, and name what you need from the person you're talking to. That's the difference between escalating and complaining, and senior people can feel the difference immediately even if they couldn't define it.

Also worth saying plainly: if your organisation punishes the person who brings the early warning, the problem is not your reporting technique. But do not assume that's your organisation until you've actually tested it with a well built flag. Most of the time the punishment people fear is imagined, and the real reaction to an early, quantified, option bearing warning is relief.

Open a text file. Put today's date, days burned, and your honest completion percentage, checked against something countable. Do the division. Write the projected total at the bottom.

Then put a recurring fifteen minutes in your calendar for every Friday at four, called "burn", and do it again. If the projection ever crosses your budget, you send the flag that week. Not the week after, when you're more certain. The week you see it.