“So how far behind are we?” The PM asks the team on Monday morning. The first answer is “a bit”. The second, “a week, maybe two”. The third, “it depends on the supplier”. The fourth person says we are basically on plan, it’s just that testing has moved.
Every one of those answers is honest. None of them can be repeated at the review in two weeks.
The trouble is not that people are hiding something. Everyone sees their own piece and counts from there. The developer counts from their task, the tester from the day they get a build, the team lead from the date they last heard. Nobody counts to the end.
Why “a bit” is not an answer
The word “a bit” has the flaw that everyone reads it their own way. For the team it is three days. For the sponsor, two weeks. For the client, who has user training booked, any delay above zero.
Until there is a number, each of those people plans according to their own version. The gap surfaces at the worst moment, which is when someone finally gives the number and it turns out bigger than everyone assumed. It is the same gap that keeps a project green on the dashboard and red in the hallway.
Three steps to a number
In my experience one afternoon and three steps are enough to get an honest number. It takes no new tool and no full recalculation of the schedule.
Step one: I count from the end, not from today. I take the date that really matters, the day the client is to get a working thing. Then I ask what has to be ready a day before, a week before and a month before. Working back from the end, you quickly see which task already doesn’t fit in front of its date.
Step two: I ask for dates, not percentages. “Eighty percent done” says nothing. Instead I ask each person one thing: on which day will you hand this to the next person in a state where it won’t come back? An answer with a date can be checked in a week. An answer with a percentage can never be checked.
Step three: I add what we don’t control. Acceptance on the client’s side, sign-off from the security team, a deployment window once a month. These things have their own calendar and usually nobody counts them, because they are not “our work”. In practice they are what most often turns a one-week delay into five.
After the three steps one date is left. The difference between it and the date in the plan is the answer to Monday’s question.
A number with a range is still a number
Often the honest answer is not a single number. It sounds more like: six weeks if the supplier delivers the fix by the fifteenth, and ten if they don’t.
That is a good answer. It tells the sponsor what the outcome depends on and when more will be known. Much worse is a single number given with a confidence the PM doesn’t have, because in a month it will have to be corrected in front of the same people.
A range has one condition: each end must have its reason. “Between four and twelve weeks” with no explanation is just a longer version of “a bit”.
What to do when the number is bad
Sometimes the three steps produce a number nobody wants to hear. The first temptation is to count again, optimistically this time.
Better to take it to the sponsor straight away, with one sentence on what makes it up. A sponsor who knows the number two weeks before the review can still do something with it. A sponsor who learns it in the room can only explain themselves. What to put on that one page is covered in what a PM can hand upward two weeks before a leadership review.
A bad number given early builds more trust than a good number that turns out to be untrue a month later.
One question for this week
Ask three people on the team, separately, how late the project is. Did you hear the same number?
All situations described in this article are based on real events, but contain no company names, no individual names, and no data from any specific project.
