Nobody decided the project would be six weeks late. There was no meeting where someone proposed it and no email in which anyone agreed.
What there was instead was forty small things. A code review moved to tomorrow, because today something more urgent came up. Documentation put off until the end of the sprint. A test skipped, because the change was minor. A question to the client sent on Friday instead of Wednesday. Each of those decisions cost half a day or less, and each was reasonable.
Six weeks is a sum nobody added up, because no single item looked worth writing down.
Why small decisions reach nobody
A big decision has its route. A change of scope goes to the sponsor, a moved date to the steering committee, a change of supplier to the board. Someone weighs it, someone signs off on it.
A small decision is made where it arose. The developer judges for themselves that the test can be skipped. The analyst decides the question can wait until Friday. That is fine and that is how it should be, because a project in which every detail needs approval stands still.
The trouble starts when small decisions line up in one direction. Each one on its own sits within someone’s authority. Together they change the project more than many a committee decision, and nobody who could say “stop” can see them. It is a different mechanism from scope creep, which arrives as a sentence from outside. This drift comes from the team’s small concessions to itself.
Three kinds of small concession
In my experience most of them fall into one of three bags.
“We’ll do it later.” Documentation, tests, tidying up. Things whose absence doesn’t hurt today. Put off bit by bit, they all come back at once in the last month.
“Just this once.” A deployment without review, a change without a record, an arrangement without confirmation. An exception made three times becomes a habit nobody decided on.
“I won’t bother anyone with this.” A question that wasn’t put to the client. A doubt that wasn’t raised at the daily. These are the hardest decisions to notice, because they consist in something not happening.
How to see them without turning the project into bureaucracy
The first temptation is a register of everything. That is a bad idea. A team that has to record every concession will stop talking about them.
Three light habits work better.
One question at the end of the week. What did we put off or cut short this week? No judging and no looking for someone to blame. Five minutes and a list on one sheet are enough.
Counting exceptions rather than banning them. If “just this once” has been said for the third time about the same thing, it is no longer an exception. Then it is worth deciding deliberately whether we change the rule or go back to the old one.
A threshold above which a small decision stops being small. Simple and known to everyone. For example: anything that moves something by more than two days, or touches something promised to the client, goes to the PM. The rest stays where it arose.
These habits don’t stop small decisions. All they do is make sure someone sees their sum before it shows up in the schedule.
The PM’s role: watch the direction, not every decision
A PM who tries to control every detail becomes a bottleneck and stops getting information. A PM who doesn’t look at them at all learns about the drift from the client.
In between there is a role that consists in reading the pattern. One skipped test is a developer’s decision. Five skipped tests in two weeks is a message that the team is under pressure it isn’t reporting. The PM doesn’t have to react to the first. To the second they should, and with a conversation about workload, not about tests.
One question for this week
What has your team put off or cut short in the last two weeks? If you added those things up, how many days would it come to?
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.
