“So where do you record decisions here?” That’s the question a developer asks after moving on Monday from one project to another in the same company. In the old project, decisions landed in a note after every meeting. In the new one, nobody can give him an answer, because decisions live in email threads, on the board and in the PM’s head, depending on who remembers what.
Nobody neglected anything here. Both projects are run by good PMs. Each of them simply runs it their own way.
Variety that looks like freedom
In many companies, differences between projects are treated as natural, sometimes even as an advantage. Every PM has their own style, every project is different, a rigid procedure would kill flexibility. All of this is partly true.
The problem is that the cost of this variety doesn’t fall on the PM who creates it. It falls on everyone around them.
Who pays for everyone doing it their own way
People who move between projects. A developer, tester or analyst working on two projects at once has to remember two sets of rules: where the current scope lives, how a change is raised, who signs off. Every switch costs a few days of learning things that have nothing to do with the work itself.
The sponsor who reads several status reports. If amber means “we have a problem, but we’re handling it” in one project and “we need your decision this week” in another, the sponsor is comparing things that can’t be compared. Usually without knowing it, so they react to the colour rather than the situation.
The PM’s successor. When a PM leaves or moves to another project, their way of running it leaves with them. The successor gets a project in which half the knowledge of how things work was never written down, because it didn’t need to be. Everyone knew how the predecessor did it.
It’s not about one methodology for everyone
The reflex response to this problem is a single mandatory methodology and a thick handbook. That usually ends with PMs filling in the handbook for show while carrying on their own way, only now also in secret.
What works better is a short list of things that must be the same in every project, plus a clear statement that everything else stays in the PM’s hands. The list should be short enough to remember.
What has to be shared
In my experience, five things are enough.
- What green, amber and red mean. One definition for the whole company, ideally described by what the status requires from the reader, not by how bad things are. It’s the same idea behind a sponsor update built on status, consequence, options and recommendation.
- Where decisions are recorded. One place per project, in the same format in every project. A new person should know where to look before they have to ask. A meeting can write its own action list, but only if everyone knows where that list lives.
- How risk is escalated. When the PM decides alone, when they go to the sponsor, and how quickly they expect an answer.
- How a scope change is raised. It doesn’t have to be a form. It has to be clear that a change doesn’t enter the project as a sentence dropped in a meeting.
- What “stage complete” means. How we know we can move on, and who confirms it.
Everything else, meaning the meeting rhythm, the tools, the planning approach, the style of working with the team, can differ. That’s where differences genuinely come from the project and the people.
A simple test
Take someone from one project and sit them in another for an hour. After that hour, ask whether they know where the decisions are, what the current status is and who to go to with a problem. If they don’t, the differences between projects have stopped being style and have become a risk.
One question for this week
If someone took over your project tomorrow, what would you have to explain to them because you never wrote it down? The first thing that comes to mind is the best candidate to write down this week.
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.
