“PRINCE2,” they say, and produce a folder. “Agile,” and produce a different folder, thinner, with better fonts.

What is being described is not a way of working. It is a shopping list.

Nobody has ever been fed by a list of ingredients.

The Tick

Somewhere on every shared drive there is a spreadsheet called Stage Gate Deliverables, and beside each line, a box.

Business Case: tick.

Project Initiation Document: tick.

RAID Log: tick.

Communications Plan: tick.

Lessons Learned Register, created on day one, still empty on day four hundred, ticked throughout.

The gate opens. The project proceeds. Somebody’s name goes on something. And at no point in any of it has anyone been required to decide anything.

What a Recipe Leaves Out

A recipe is what is left over after somebody else has done the thinking. Two hundred grams of flour. Fold, do not stir. Rest for an hour, covered.

That works, up to a point, and the point arrives quickly. The card does not say why the butter has to be cold, so it cannot help when the kitchen is warm. It says nothing about your oven, which runs hot. It assumes eggs of a size you do not have.

Every one of those corrections lives in the cook. None of them lives on the card.

Escoffier did not leave behind a list of dishes. He left a system. The brigade, the mother sauces, a structure from which thousands of dishes follow for anybody who understands the principle. The recipes were the output of the method, not the method itself.

Confuse the two and you end up with a kitchen full of index cards and nobody in it who can cook.

The One Checklist that Works

There is a checklist that saves lives every day, and it lives in a cockpit. The concession is worth making, because the difference between that checklist and the one on the shared drive is the entire argument.

At Wright Field in October 1935, the Boeing Model 299 took off, stalled and came down in flames. The pilot was killed. The aircraft was not defective. The gust lock had been left engaged. Too much airplane for one man to fly, the newspapers concluded. The design survived to become the B-17, and so did the short document its pilots wrote in response.

Every line on that card commands an action. Gust lock, released.

It was written after a specific accident, by the people who would have to use it, and it assumes a trained pilot who knows what a gust lock is and exactly why the other man died. Hand the same card to somebody who has never flown and it documents their death rather than preventing it.

A stage gate list assumes nothing and commands nothing. It does not say risk, priced. It says Risk Register, attached.

It is not a checklist of actions. It is a checklist of stationery, written by nobody anyone can name, after no accident anyone remembers, for a project that was not this one.

Ingredients are Not a Meal

Look at what the tick can actually certify.

It can establish that a Risk Register exists. It cannot establish that anybody has thought about risk for eleven consecutive seconds.

Two different claims, and only one of them is auditable, which is exactly why it is the one audited.

So the register gets filled. Twelve risks, because twelve looks conscientious where four looks idle and forty looks alarming. Each one scored on a five-by-five matrix nobody at the table can justify. The file is dated. The file is signed.

The file is a bowl of raw flour.

Decisions, not Documents

The remedy is not abolishing the checklist. Keep it. Just have it drive decisions instead of documents.

Who decides scope against cost, and on whose authority.

At what point a risk stops being watched and starts being funded.

Which changes can be absorbed, and which ones mean stopping and saying out loud that the plan is no longer true.

What gets said to the Steering Committee when the news is genuinely bad, and who is allowed to say it.

Every one of those can end in a document, and a document is a perfectly good place to keep a decision. What is not good is producing the container and announcing that the contents can be assumed.

Answering those questions means somebody making a judgment in public and carrying it long afterward. Ticking a box takes a mouse and nobody watching.

Mise en place is not the food. It is everything the cook does before service, so that when the orders start arriving, the thinking has already been done.

A row of labeled containers with nothing prepared in them is not mise en place.

It is shopping.

Not from the vendor who underbid, and not from the supplier who missed a date. Those are ordinary problems, and there are ordinary ways to handle them.

The expensive damage comes from a department head who agrees a change directly with a developer because it seemed small. From a sponsor who promises the business a date that was never in the plan. From a committee member who approves a deliverable without reading it, because nobody else around the table looked worried. From an architect who settles a scope question in a corridor and tells no one.

Not one of those people is obstructing anything. Every one of them is trying to help.

Confusion in the Field

In the field, friendly fire is almost never about hostility. It is about people holding different pictures of the same situation.

The plan changed, and one unit was not told. Two groups were on different channels. A position was reported against the wrong reference. Nobody in that sequence wanted the outcome, and the outcome happened anyway.

The fix is not braver soldiers or better equipment. It is the same briefing, the same map, and the same signals, issued to everybody in the area, including the people who will never fire a shot.

That last part is the whole point, and it is the part organizations skip.

The One Person Who Gets Trained

Companies do buy methodologies. They pay for the licenses, the templates, the tooling, and the course.

And the course is attended by project managers.

That is the implementation. That is all of it.

The people with by far the greatest influence over whether a project succeeds attend nothing. The sponsor, the budget holder, the Steering Committee members, the department heads whose staff sit in the team. They are informed by email that the company now works according to PRINCE2, or a scaled Agile framework, or an internal method with a name and a logo, and that is where their involvement with it ends.

So the method now lives in one head in the room.

When the project manager says a change has to be assessed and priced before anyone starts building it, that sounds like process for its own sake. To everybody else at the table, it is exactly that, because nobody ever explained what it is for or what it prevents. They are not being obstructive when they push past it. They are doing what seems obviously sensible, which is getting on with the work.

And the project manager slowly becomes the person who says no.

What Half a Day Would Fix

The remedy is not a bigger training budget, and the Steering Committee does not need the five-day course.

It needs about half a day, covering four things.

What the committee actually decides, and what it only advises on. Those are different, and most committees have never been told which is which.

What tolerance means, and the point at which a decision stops belonging to the project manager and arrives at the committee. A board that does not know its own tolerances cannot tell the difference between being informed and being asked.

What happens to a change between being requested and being approved, and why that order is not bureaucracy. Assessed, priced, decided, then built. Any other sequence means the organization is paying for something it never agreed to buy.

And what it means to accept a known defect into production. Who decides, what the workaround is, and who explains it to the user who finds it on a Monday morning.

None of that requires a binder. It requires somebody senior enough to insist that the people making the decisions understand the system they are making them inside.

What is Actually Being Asked

Look at what gets asked of a project manager in an organization that has trained nobody else.

Lead a team that has never been trained in the company’s own method.

Report to a board that is not fluent in it.

Inside an organization that has not mastered it either.

Then carry the accountability for the outcome.

That is not a difficult assignment. It is an impossible one, and it is usually described as a good opportunity to step up.

Nobody sets out to hit their own side.

It happens when half the people in the area are working from a briefing the other half never received.

The project manager is not the one holding the map. The project manager is the one standing out in the open, waving.

It seems like almost any industry has a little magic wand. That one thing that helps against almost all possible problems, regardless of the size of the problem. No matter what is going on at the time, just apply the magic wand, and the problem will disappear as fast as an unlocked bike in Amsterdam.

Remember when you were little? Your mother also had that magic wand. Whenever you fell and hurt yourself, all you really required was a little kiss from her on that spot, and the pain, no matter how strong, would magically disappear.

The same applies to grown-ups. If you have ever watched football (”soccer” for the Americans among you), you will have witnessed their version of the magic wand. The water sponge. Players can be rolling on the floor, crying out as if breathing out their last bits of air, but as soon as the team doctor applies the water-soaked sponge.... it’s game on!

Projects are no exception. These also have a magic wand, that one thing that takes care of every possible eventuality. Sometimes it is called the contingency budget and sometimes the applied tolerance, depending on the company’s approach and naming conventions.

And. It. Is. Always. Ten. Percent.

That’s the magical part!

What the Number is Supposed to Depend on

Usually, your margin of error during planning depends on a lot of things. Familiarity with the subject matter. Quality of the tools you are working with. Price stability of the supplies you need. Whether the team has done this before, or anything like it. Whether the technology has ever been put into production anywhere. And then some…

But no matter how risky your project, no matter how uncertain the circumstances, no matter how untrained the resources, no matter how unknown the applied technology and no matter how unreliable the supplier..... 10% should cover it!

Ten Percent of the Wrong Thing

Here is the part that is worth sitting with for a minute, because it is arithmetic rather than opinion.

Ten percent is a percentage of the budget. So the contingency is calculated from the cost of the project, which means it is a function of how big the project is, and not a function of what might go wrong.

Those are two completely different questions, and only one of them has anything to do with risk.

Take two projects with the same budget. One is the fourth release of a system the team has maintained for six years, with a supplier they know, on technology that is boring in the best sense of the word. The other is a first implementation, new vendor, new platform, a data migration nobody has scoped properly, and a go-live date driven by a regulatory deadline.

Same budget. Same ten percent. One of those numbers is far too generous, and the other is a rounding error against what is coming.

And notice which way the arithmetic runs. Because contingency is a percentage of cost, the cheapest projects get the least of it. Yet a small project with an unfamiliar supplier and a technology nobody in the building has used before can quite easily be the riskiest thing in the entire portfolio. The formula gives it the smallest cushion precisely because it is small.

Why Nobody Argues with it

There is a reason this survives, and it is not that anybody believes in it.

Ten percent is unarguable. It requires no explanation, no analysis, and no uncomfortable conversation. Nobody in a Steering Committee has ever been asked to justify ten percent.

Any other number has to be defended. Seventeen percent means somebody has to stand up and explain what the extra seven is for, name the risks behind it, and accept that they will be asked about it again every month until the project closes.

So the round number wins. Not because it is right, but because it is the only one that never has to be explained.

The alternative is not complicated, and it does not require a model. Take the risks that have actually been identified, price what each one costs if it happens, weight it by how likely it is, and add the results together. That is your contingency. Some projects will land at three percent. Some will land at twenty-five, and the conversation about whether to proceed at twenty-five is the single most useful conversation anybody will have about that project all year.

Why always ten percent? We really do not know, and neither does anybody we have asked about this mythical number. Maybe somewhere in the past, somebody decided that for one specific project ten percent was a reasonable margin of error. Or perhaps it was never one project at all, but a company-wide standard written by somebody who has long since retired.

And did it start with one company and spread across the entire project world? Or did all companies independently arrive at the same conclusion at about the same time, the conclusion that ten percent covers all?

As with all things magical, we will never really know…

“Where do I find the project method. Templates, stage gates, that sort of thing.”

The answer arrives with a small proud smile.

“We do not really work like that here. We like to keep it flexible.”

By the end of the month, the new project manager has worked out how it actually works. Business cases go to Marion, but only after Dave has seen them, and nobody will tell you why. The Steering Committee does not take decisions in the meeting, it takes them afterwards, by email, in a thread you may or may not be on. You never put a risk in writing before you have raised it verbally with the sponsor. And the real deadline is two weeks before the stated deadline, because of the board pack.

None of that is written anywhere. All of it is enforced.

There is a method. There is always a method. It is simply undocumented, and there is no way to learn it except by getting it wrong in front of people who already know.

The Under-Elevens

Go and watch children play football on a Saturday morning. Soccer, for the Americans reading this.

Twenty children on the pitch and all twenty of them are within about five meters of the ball. Wherever it goes, they go, in one dense cluster, at speed. There is no defense, because defending means standing somewhere the ball is not, and there is no seven-year-old on earth who can be persuaded to do that.

It is not a lack of effort. Every child out there is running flat out, and every one of them is trying to win.

An organization without a documented method does exactly the same thing. Everybody converges on whatever is loudest that week. The escalated defect, the angry customer, the demo on Thursday.

And the work that means standing where the ball is not gets left. Nobody is forecasting next quarter’s cost. Nobody is keeping the risk log honest. Nobody is checking whether the thing being built is still the thing that was asked for, because none of that is where the noise is, and all of it looks like standing still.

Then there is the child who does hold position.

That child gets shouted at by the other children.

In an organization, that child is the project manager who insists on a change being priced before it is agreed, or who will not close a stage without acceptance criteria. Within about two months, that person has a reputation. Bureaucratic. Rigid. Not a team player.

Where This Actually Comes From

Almost nobody arrives at this after careful thought.

It usually comes from a real memory. A methodology was implemented once, and the implementation was theatre. A consultant, a thick binder, a slide deck explaining why everything would be better from now on. The project managers were trained. Nobody else was. The Steering Committee members, who have more influence over the outcome than anyone, never attended a single session and carried on exactly as before.

So it failed, visibly, and the conclusion drawn was that methodology does not work here.

The conclusion available was that the implementation was poor.

The fix is smaller than people fear. You do not need the thick binder. Pick something coherent, use a fraction of it, and write that fraction down. PRINCE2, an Agile framework, or a stripped-back version of either. Which one matters far less than two other things: that it is written down, and that the people who make the decisions are inside it rather than watching it.

At a minimum, four things need to exist on paper.

• Who decides what, and at what value a decision moves up

• What is baselined, and what happens when it has to change

• Where risks go, who owns them, and what triggers an escalation

• What done means, agreed before the work starts rather than after

That is a few pages. It is not a methodology implementation, it is a Tuesday.

What the Absence Costs

Somebody always carries the undocumented method. It lives in the heads of the three or four people who have been there longest, and they absorb the gap by working late and knowing who to call.

When they leave, it leaves with them.

And ambiguity is never neutral. It always favours somebody, and it is rarely the person doing the most careful work.

Children grow out of the clump. Somewhere around ten or eleven a coach finally explains that football is mostly about where you stand when you do not have the ball, and the cluster breaks apart, and the game starts.

Nobody grows out of it by being told to keep it flexible.

“Delivered on time and on budget.”

There is a small round of applause. The sponsor thanks the team, the project is formally closed, and somebody mentions drinks on Friday.

Nobody asks the two questions that would take about ninety seconds.

What did we actually deliver.

And does it work.

Pyrite

Fool’s gold is a real mineral. Iron pyrite. It turns up in the same rock as the real thing, it has the same brassy yellow shine, and in a stream bed in decent light it is convincing enough that people have filled carts with it and gone home happy.

The test is embarrassingly simple. Gold is soft and extremely heavy. Pyrite is hard and comparatively light. Scratch it across a rough surface, and gold leaves a yellow streak while pyrite leaves a greenish black one. Hit it with a hammer, and gold flattens while pyrite shatters.

Two minutes, and no equipment worth mentioning.

The men who went broke on pyrite were not stupid, and most of them were not swindled either. They simply never ran the test, because the thing in their hand already looked like what they had come for.

On time and on budget is the shine.

It is not nothing. Gold is shiny too, and a project that lands its date and its number has done something real. The trouble is that shine is the one property the counterfeit shares completely.

The Two that Nobody Audits

A project has four things that can move. Time, cost, scope, and quality.

Two of them are measured in public. The date is in the plan, and everybody can see it. The cost is in the ledger, and Finance reconciles it monthly. Miss either one and you will be explaining yourself at the next meeting.

The other two are not measured in public at all.

Scope moves quietly. Three requirements go to phase two in April. Two more become enhancements in June. The interface nobody had time for is now a manual process that somebody will automate later. Every one of those was a sensible local decision, and not one of them required an announcement.

Quality moves even more quietly. The test window gets compressed because the build was late. Twenty medium defects go live as known issues with workarounds. The performance work is deferred until after go-live, which is a sentence that means it will not happen.

So when the date and the number are under pressure, everybody already knows which two will absorb it. Not because anybody is dishonest. Because two of the four are audited and two are not, and pressure runs downhill towards whatever nobody has to report.

Which is why the closure slide should carry four numbers rather than two.

Baseline date against actual date. Baseline cost against actual cost. Scope promised against scope delivered, with the deferred items listed by name rather than summarised as a percentage. And defects open at go-live, by severity, with the workarounds stated.

Add one line underneath saying who decided each trade-off and when. That single line is the difference between a managed decision and a quiet cut, and it costs nothing to produce because the decisions were all made by somebody, at some point, in a meeting.

The Wrong Lesson

Here is what the slogan really costs, and it is not the project on the slide.

A project that overruns its first date by two months, gets re-baselined openly with a decision behind it, delivers everything that was promised, and works on the Monday morning, goes into the corporate memory as a troubled project. The project manager gets asked what went wrong.

A project that hit both numbers by quietly removing a third of the scope and shipping forty known defects goes into the corporate memory as a success. The project manager gets the next one.

The organization has just learned something, and it has learned the wrong thing. It will apply that lesson for years.

Nobody sold the prospector his pyrite. He dug it out himself, carried it home, and was delighted with it the whole way.

Two minutes with a scratch plate would have told him.

Two questions would tell you.

An intermediary runs through the assignment, the client, the duration, the rate. Then comes the question that actually decides it.

“Do you have any experience with system XYZ?”

“No.”

“Too bad. The client is looking specifically for someone with detailed knowledge of system XYZ.”

And there you are, left behind, thinking that they were looking for a good project manager.

The track record never comes up again. Twenty years of delivering complicated things in a controlled manner, and the conversation ended on a product name.

The festival

Run the same process somewhere else and watch how it sounds.

You are hiring somebody to organize a rock festival. Three days, a field, fifty thousand people who need to be fed, watered and got home again. The criterion that decides the appointment is whether the candidate knows rock music, and ideally plays a decent guitar.

That the candidate has already organized a jazz festival, a film festival and a food truck festival counts for very little.

If the candidate does not know the entire catalogue of Metallica, then surely managing a multidisciplinary team to successfully host a rock festival is a bridge too far.

Right?

Appointing a project manager on content knowledge rather than project management skill is appointing the right person for the wrong job.

You selected for expertise. You will get expertise.

You have hired a music fan and put him in charge of security.

Two things follow

The first is a conflict of interest.

A project manager spends most of the day weighing things against each other. Scope against time against money, and then explaining the choice. That requires somebody who is impartial about the content, because the entire job is deciding between things that other people care about a great deal.

An expert is not impartial about the content. That is what makes them an expert.

So the rock purist ends up choosing between budget for crowd safety and a first aid team... or one more band, the one he has wanted on that stage since March.

The second consequence is harder to see and does more damage.

Experts cannot leave the detail alone. They know too much about it. They cannot help themselves.

So they spend their time second-guessing the specialists they appointed, which undermines the specialists, and which keeps the project manager too low to the ground to oversee the whole field.

How to spot one

This type of project manager is easy to recognise in a Steering Committee.

They will explain, in great detail, why a particular change request for new functionality needs to be approved, including all of the technical implications. It is a genuinely impressive briefing, and everybody leaves it better informed.

However, that same Steering Committee will not be given an up-to-date forecast on costs, or an updated risk profile including adjusted mitigation actions and contingency measures.

Not because the project manager is lazy. Because the project manager has spent the month doing somebody else’s job, rather well.

The fix is not complicated, and it is not a compromise either.

Hire project managers for the things project managers do. Impose structure, price risk, arbitrate between competing objectives, report honestly and keep promises.

Then let the experts be experts, and hold them accountable for their own output, which is what they are good at and what they were hired for.

But if you must, carry on appointing whoever knows the most about the system. Just do not act surprised at what you get.

That expert is so busy tuning guitars and running through playlists with the band that there is no time left to make sure the ticket counters, the concession stands and the toilets are being correctly set up.

Far out!

Literally...

You have barely come to terms with the fact that your little princess is leaving the fort, and now you meet the other tradition attached to the role, which is financial. She chose the dress at thirteen. The color of the napkins was settled before her sweet sixteen.

The piggy bank comes off the shelf, and you hire a wedding planner, who is your project manager for the day.

She gathers the requirements, builds the plan, and puts a budget against it.

So. Do you now sleep soundly, knowing that a fairytale wedding cannot possibly run into trouble?

What about the risk of a wedding shower. The wet kind.

What about a power failure, in a marquee, at nine in the evening, with two hundred people in it. The band not turning up. Somebody falling ill. The venue writing to you in April to say it regrets to inform you.

Do you sit down with your planner and work through all of that?

Definitely.

What you would actually do

You watch the forecast, and you keep enough cash aside to put up two large party tents if it turns against you.

You hire a generator. Not enough to run the whole thing, but enough for cold champagne and music, which between them are most of a wedding.

You put a penalty clause in the band’s contract, because that lowers the chance of them letting you down, and your planner keeps a list of disc jockeys by the phone anyway, because it does not remove the chance entirely.

You arrange for a first aid team to be there.

Then there is the venue canceling at the last minute, which is the one with the highest impact and the lowest likelihood. You can spend real money holding a backup location. You can negotiate a cancellation penalty heavy enough to keep them honest. Or you can look at the number, decide it is unlikely enough to live with, and accept it.

All three are fine. What they have in common is that somebody decided, in advance, with the cost in front of them.

On the day, there is one shower. Nobody minds, because the tents are up. Good for you.

The band arrives. Uncle Peter passes out after a glass or two of champagne too many and is looked after by the first aid team. The generator is never switched on, which in hindsight was money spent for nothing, and you would spend it again, because a power failure with no backup would have finished the evening.

Your wallet is lighter. Your daughter is as happy as anyone can be. Everyone who visits her over the next few years will sit through the album and ninety minutes of video saying how delightful.

You would call that a good outcome.

The same risks, at work

Now compare that to how a project gets treated.

The project manager is expected to identify the risks up front and then keep managing them. That part usually happens. The risks are named, the likelihood and impact are assessed, and mitigation is proposed with a price against it.

And the Steering Committee looks at the number attached to things that have not happened, and frowns.

“What is this money for?”

The objections are always the same, and they are worth writing down properly, because they sound reasonable in the room.

“What is this money for?”

“Why should we approve this now?”

“This will only make the project unnecessarily expensive, when we do not even know whether we will need it.”

Underneath all three is one belief that nobody ever states out loud. That the risks are virtual. That their real probability is somewhere near zero, and that naming them on a log is the same as dealing with them.

They are not virtual. A risk does not become smaller because somebody updated a column, and the weather does not consult the budget before deciding what to do in June.

Then a major issue arrives, and you can guess who is most shocked by it. The same people. Even though the risk had been written down from the first week of the project, in a document they had all seen.

That is the part that never stops being strange. It was identified. It was assessed. It was presented. And it still never registered as something that might actually happen, because nobody was ever asked to pay for it.

The father of the bride did not need a log to tell him it might rain.

He booked the tents.

And the project managers still keep their plans in Excel.

The word for that is adoption. As in, adoption has been disappointing. As in, perhaps we should look again at training.

There is a simpler explanation, and it does not require anybody to be a technophobe. The project managers read the tool correctly.

They are not sentimental about software. They will use anything that makes delivery easier, including a spreadsheet, a whiteboard, or a shared folder with sensible file names. Nobody has ever had to run a training program to get a project manager to adopt a shared folder.

So when a tool gets quietly refused, the refusal is information.

Where these tools come from

Ask around any organization that has one, and the story is nearly always the same. The initiative did not start in the delivery function.

It started with a problem that is completely real. The numbers were late, or inconsistent, or they arrived in fourteen different spreadsheet formats. Month-end took two weeks. Nobody could answer a plain question about committed spend across the portfolio without three people and a phone call. Then Audit made a finding, and somebody said the sentence that begins these programs.

“We need a single source of truth.”

That is a Finance sentence. Not a criticism, just an observation about where it comes from.

So the requirements get written by the people who have the problem. Controlling, Finance, Audit, sometimes Procurement. The evaluation criteria are theirs, the scoring matrix is theirs, and the demonstration that decides the shortlist is a month-end close.

The project managers are consulted. Usually. Somewhere after the shortlist has been agreed, in a session described as a user group, at which two candidates remain and the contract already has a signature date in it.

The input is genuine. It is also an afterthought in the precise sense of the word. It comes after the thought.

And then the thing gets named. Not Portfolio Financial Control System, which is what the requirements describe. It is introduced as a project management tool, and from that moment, everybody in the organization believes that is what was bought, including the people who bought it.

An army you already employ

Here is the arithmetic that makes it attractive, and it is worth admiring before criticizing it.

Correct numbers need somebody to enter them. Finance cannot enter them, because Finance does not know what happened on the project. The only people who know are the project managers.

There are a great many of them. They are already on the payroll. And crucially, they are not in the Finance budget.

So the data collection is distributed across the delivery organization, and it never appears as a cost in anybody’s business case. The larger the project management population, the better the deal looks. An army you already employ is free, as long as nobody counts the hours.

They are not being asked to manage projects with this tool. They are being asked to supply it.

Actuals and forecast

This is the part that costs real money, and it is not about anybody’s feelings.

A finance system records what has happened. Actuals, committed spend, invoices received, hours booked. Backward-looking by design, and it has to be, because that is what an audit is for. Accuracy about the past.

A project is run forwards. What will the remaining work cost. Which risks are still open and what are they worth. What happens to the date if the supplier slips a month. How much contingency is left and what is it held against. Not one of those can be derived from actuals.

So the project manager spends an entire afternoon entering last month into a system that will not help with next month, then opens Excel and builds the forecast there.

The organization now has two plans. One is complete, current, and auditable. The other is the one being used.

The fix is not a better tool, and it is certainly not more training. It is honesty at selection time, and it costs about an hour.

Write down who the tool is for, in order. If Finance is first on that list, say so plainly and let the business case be a finance business case. It will probably be a good one.

If it is genuinely meant for the project managers, put project managers on the selection panel with a veto, rather than in a user group convened after the shortlist.

Test it on the forecast instead of the actuals. Ask the vendor to demonstrate a re-forecast after a risk has materialized. Move the date, reprice the remaining work, show the effect on the total and on the contingency. It is the most informative twenty minutes of the entire procurement.

Then count the data entry. Hours per project manager per week, times the number of project managers, times the rate they are charged out at. Put that figure in the business case beside the license cost. It will not be the smaller of the two.

The gate

None of that happens, so the rest follows on rails. Training and a dashboard showing tool usage by department, which is a small monument to the problem all by itself. And then, every month, the polite instruction.

“Can you make sure it is up to date before the 3rd working day of the month?”

Up to date. Not correct, not useful. Up to date.

The Greeks needed a horse because the walls were high and the gates were shut.

Nothing here was shut. The gate was opened from the inside, by people who had read the specification and believed the name on the outside of it, and what came out has been doing exactly what it was built to do ever since.

It is doing it right now. Day 3 of the month.

“That is the worst case. We are never going to be that unlucky.”

Everybody agrees. The number comes off the slide, and the meeting moves on, feeling that something sensible has just been done.

They are right, by the way. That is the part worth sitting with.

The worst case assumes every identified risk materializes. All of them. The supplier is late, and the integration fails, and two of the three people who understand the legacy system resign in the same month, and the regulator changes the rules in October. That is not a forecast. It is an inventory of everything that could go wrong, added up as though it all will.

So no. It will not be that bad.

Both ends of the same stick

Now look at the other number, the one nobody ever deletes.

The best case assumes no risk materializes at all. Not one. Every supplier delivers on the agreed date, every requirement survives first contact with the business, the integration works the first time it is tried, nobody resigns, nothing turns up in testing that was not already known, and the regulator stays quiet all year.

Read that back. It is exactly as ridiculous as the other one.

Commit the following to memory (tattoo it if you must): the Best Case is as unlikely as the Worst Case.

Think of the United States at the Olympic Games. The worst case is that it goes home without a single medal. The best case is that it wins every medal on offer.

Both are nonsense, and for the same reason. It has never come close to either. It takes a great many, and not all of them, every time, and anybody who follows the Games has a rough idea of the range before the opening ceremony.

Nobody plans the parade around every medal. In a project meeting, every medal is the only scenario anyone writes down.

And then somebody dares to ask the question that finishes the job.

“Is there anything else we can take out of this?”

At this point, one is tempted to inquire: which part of “Best Case” do you not understand? Do you intend to win more medals than exist?

The pretty number does not stay in the room

This matters more than an argument about arithmetic, because of where that number goes next.

The best case does not sit quietly in the minutes as a bookend. It goes into next year’s budget. From the budget into a business case, from the business case into somebody’s target, and by the time the first risk materializes, the figure has been repeated in so many meetings that it has stopped being an estimate and become a commitment.

So when the supplier is late in month four, the project is not merely late. It is over budget against a number that was never a forecast. The team then spends the rest of the year explaining the difference between what happened and what was never going to happen.

Nobody wanted that outcome. Everybody voted for it in March.

What the two numbers are for

The bookends were never forecasts. They are the width of the corridor. They say how far the outcome can move, which is a different and more useful thing than saying where it will land.

The number to plan against is neither of them. It is the Expected Case: each identified risk priced for what it costs if it happens, weighted by how likely it is, and added to the base estimate. That gives a figure higher than the best case and lower than the worst, and unlike either bookend, it can be defended line by line.

Then put the contingency on its own line, with the risks it belongs to named beside it. Not folded into the total, where it looks like padding and gets shaved. On its own line, where taking it out means somebody has to say out loud which risk they have decided not to fund.

Present all three and say what each is for. Best Case is what happens if nothing goes wrong, and nothing has ever gone nothing-wrong. Worst Case is the exposure if everything hits you at once. Expected Case is the number the project will actually be run against.

That last one is the only sentence in the meeting that anybody will be held to.

The United States has never won every medal at the Games.

It has never gone home without one either.

Only one of those two numbers tends to be written into a budget.

A laptop gets turned around. On the screen: bars. Hundreds of small blue bars marching left to right, with one red one somewhere in the middle that everybody has quietly agreed not to mention. Dependencies. Resource assignments. Phases broken into sub-phases, activities broken into sub-activities, all of it built with real care by somebody who is very good at building it.

That is a schedule.

It is not a plan.

Right?

The Choreography

Say you are planning to rob a bank. Not recommended, but it works.

You decide who digs the tunnel and who cuts the alarm. You pick the drill that goes through the safe door, and you time it. You work out how many minutes you have before the car has to pull away from the corner. All of it on one page, in order, with a name next to every task.

That is a fine piece of work. It is also nothing more than choreography.

Because none of it tells you what to do when there are forty people in the lobby instead of twelve. Or when the man with the drill gets picked up by a patrol car two streets away and never arrives. Or when a security guard decides that today is the day he becomes a hero. Who takes over? Who is allowed to speak to the police, and what exactly are they allowed to say? At what point do you walk out with nothing rather than stay another ten minutes?

No answers to those questions means no plan. It means a timetable and some optimism.

Plan to Control

The PMBOK is not a thrilling read, but it gets the definition right. A project plan is “a formal, approved document used to guide both project execution and project control.”

Read those last two words again.

Control is the part that gets skipped, because control is the part that cannot be drawn as a bar. Where is the governance model? Who decides, who only gets to advise, and at what point does a decision stop belonging to the project manager and travel up to the steering committee? What is the tolerance before that happens?

What happens to a risk when it stops being hypothetical? Is there money reserved against it, with a named owner and a mitigation action somebody has actually agreed to carry out... or is there a row in a spreadsheet with the word “monitor” in it?

Which changes are admissible, and which one forces a re-baseline? Where does an issue go when the team cannot solve it, and how long is it allowed to sit there? Who needs to know what, and when, and who is going to deliver the half of the report nobody wants to hear?

Answer those, and the dates start to mean something. Skip them, and the dates are decoration.

The Professor

Money Heist did not become a global hit because the Professor could read a clock and hand out tasks.

He is interesting because he spent months imagining the thing going wrong. Every way it could go wrong. The hostage who runs. The negotiator who does not behave the way the profile said she would. The team member who breaks the one rule that holds the rest together. For each of those, he has a response ready, and a rule for who decides when he cannot be reached.

He planned for the plan failing.

That is the difference, and it costs nothing except the willingness to sit in a room and say out loud what could go wrong. Which is, apparently, the most expensive hour in project management.

By all means, keep the Gantt chart. A timetable is useful, right up to the moment the timetable stops being true.

But when the alarm goes early, and the tunnel is flooding, and the man with the drill is sitting in the back of a patrol car, nobody in that building turns around to look at the bars.

They look at you.

And you will have a beautiful chart.

What follows is not a transcript of any particular meeting. It is a transcript of most of them.

Watch who stands up first, and watch who stands up second.

Business Manager: Before we go through the list, I want to be clear about the standard. The target should be software without defects. My users cannot be the ones who find these.

Vendor Delivery Manager: We agreed exit criteria in March. Zero high, up to twelve medium with documented workarounds, low deferred to the first patch.

Business Manager: I am not comfortable accepting something we already know is broken.

Program Director: I do not think anyone in this room is going to argue against quality.

Quality Lead: Quality has to come first.

Vendor Delivery Manager: We are fully committed to delivering quality.

Test Manager: There is no build without known defects. Not this one, not the one it replaces.

Program Director: Let us not get lost in the detail. Can we look at the six?

Test Manager: Three are configuration and can be closed this week. One needs a design decision from architecture. Two are in the vendor’s core product.

Vendor Delivery Manager: Those two are working as designed.

Test Manager: They are on the defect list.

Vendor Delivery Manager: They are on the defect list as raised. They are working as designed.

Business Manager: And while we are here. Why should we pay to test your software?

Vendor Delivery Manager: Testing is in the statement of work as a joint activity.

Business Manager: It still feels like we are paying twice.

Business Manager: So, can we get to zero?

Test Manager: Not on this date.

Program Director: Then let us go away and see what is achievable.

Eleven weeks later

Same room. Same agenda item.

Test Manager: Sixty-three open. Nine high.

Business Manager: It was forty-one.

Test Manager: We closed fifty-two. Regression opened thirty-eight. Four of the nine high are in code the vendor touched to fix the original six.

Vendor Delivery Manager: We would point out that thirty of the sixty-three are enhancements raised as defects.

Business Manager: They are things that do not work.

Vendor Delivery Manager: They are things that were not specified.

Business Manager: Some of these my team could live with. There is a workaround for the invoicing one. We used it for years on the old system.

Program Director: We set a standard in March.

Business Manager: I set that standard in March. I did not know then what I know now.

Program Director: The team has worked to it for eight months. I am not going to tell them today that it no longer applies.

Vendor Delivery Manager: The fourth revision puts us in November. That assumes no further regression.

Test Manager: There will be further regression.

Business Manager: Support on the old system ends in December.

Quality Lead: I think the standard has served us well. It has kept quality front of mind all year.

Programme Director: Agreed.

The Business Manager did not know. That is allowed. Nobody outside software development has any reason to know that fixing fifty-two defects can produce thirty-eight more, and “the target should be software without defects” sounds, to someone accountable for the users, like simple diligence.

The Programme Director knew. Third go-live, at least. Has seen a defect list on every single one of them. And what he said, in March, when it was still free to say anything, was that nobody in the room was going to argue against quality.

That is the entire mistake. Not the demand, but the endorsement, from the one person in the room qualified to say the word impossible, at the only moment when saying it would have cost nothing more than an uncomfortable minute.

In the film, every man who stands up knows exactly what it is going to cost him.

That is the difference. In the meeting it costs him nothing at all.

It costs the project a year.