The email is polite, short, and four months late. Change request 47 was quoted in the middle of development. Two weeks of work, a clear price, signed off by the project manager and sent to the client for a decision. The client said they would think about it.

They thought about it until acceptance testing.

The project is still running. The project manager is still there, the status meeting is still on Tuesday, and from the client’s side nothing much seems to have changed. Inside the team, a lot has. Development is finished, so the development team has gone from eight people to three, and those three are busy fixing the defects the client’s testers keep finding. The developer who built that interface has moved to another project. The architect who reviewed the design is booked elsewhere until next quarter.

But the client has a quote, the quote has a price, and as far as the client is concerned, the price still stands.

It was quoted, after all.

The Extra Outlet

Picture a house being built. The walls are up but still open, and the electrician is pulling cables through the frame. Walking around the site, you decide you would like one more power outlet in the kitchen.

You ask the builder. He checks with the electrician and quotes on the spot. Half an hour of work and a small bill. The cable is right there.

You say you will think about it.

Four months later, the house is nearly done. You do the final walk-through with the builder, punch list in hand. A door that sticks, a scratch on a tile, a missing light switch cover. And that extra outlet, please. Half an hour and a small bill, as quoted.

The builder is still on site, and so is his finishing crew. The electrician is not. He finished his part three months ago and is wiring a house across town. The walls have been closed, plastered, and painted, and the kitchen has been tiled. Now somebody has to get the electrician back, open the wall, run the cable, and plaster, paint, and tile it again.

Two days, and five times the price.

“But you quoted half an hour.”

He did. With the walls open.

A Quote is Not a Voucher

A change request quote is a snapshot. It is priced on the conditions of that moment: the people in the team, the knowledge in their heads, and the work that is still open and easy to change. Take those away, and the quote is worth about as much as the outlet price after the plasterer has been.

What makes this mistake so common is that the project is still running. The builder is still on site, so the client assumes the capacity is still there. Nobody sees that the one trade the change depends on has already left.

The client is not being unreasonable either. Nobody told them the quote had a shelf life. Nothing on the paper said so. It said two weeks and a price, and that reads like a voucher that can be handed in whenever it suits.

In projects with an Agile component, the same thing happens through the backlog. The change gets estimated during development and sits there, sprint after sprint, while the team that estimated it gets smaller. When the product owner finally pulls it in, the number on the story was produced by people who are no longer in the room.

Then the arguments start. The client points at the quote. The supplier points at the team list. Both are right, and the project manager is left explaining why two weeks has turned into six, in the middle of a test phase that has no slack for any of it.

Two Dates on Every Quote

The fix costs one sentence per quote. Every change request quote should carry two dates, not one.

The first is the Decision Date. Approve by this date, or the quote lapses. Some quotes already have a validity period somewhere in the small print. Move it out of the small print.

The second is the Delivery Period: the start and end dates between which the change can be built at the quoted time and cost. Not before, and not after.

• Not before, because the change often touches something that is still being built. Doing it too early means doing it twice.

• Not after, because the developers and specialists who would build it will roll off the project once development is finished. Name that moment explicitly, for example, the last development sprint, or the code freeze before acceptance testing starts.

Then state the assumption the price is based on, in plain words: ”This quote assumes the current development team, including the integration specialist, is still on the project.” A client who reads that sentence understands the deal. A client who never sees it cannot be blamed for treating the quote as a voucher.

Once the delivery period has passed, the request does not die. It becomes a new request, quoted again by whoever is on the team at that point, at whatever it costs at that point. That is not a penalty. It is the honest price.

The Steering Committee has a role here too. A change request that sits undecided for months is not neutral. Every week of delay brings the end of development closer, and somebody at that table should be asking why it is still undecided.

The builder learned his lesson. His quotes now come with one extra line at the bottom.

Valid until the walls are closed.

The plasterer starts on Monday.

Said by a line manager, to a member of a project team, about a task on the critical path. The project manager finds out on Friday, at the progress meeting, when the task is still at zero.

Nobody did anything wrong, as far as the org chart is concerned. That is the problem.

Every company has a line organization. Departments, managers, reporting lines, appraisals. It is more or less fixed, at least until the next reorganization. A project organization is something else. It is temporary, it is set up for one specific objective, and it is dissolved again when that objective has been delivered.

Most companies draw a project organization chart. It sits in the project plan, neatly boxed. Very few actually follow it. And some do not see the difference at all. They take the project manager and the project team and shoehorn them into the line organization chart, as if the project were just another department.

The National Team

Think of a national football team before a World Cup.

The players all work somewhere else. They are employed by their clubs, trained by their clubs, and paid by their clubs. For a few weeks, they are released to the national coach. During those weeks, the national coach picks the team, decides who plays where, and answers to the national federation for the result. Nobody else.

Nobody expects the club manager of the left back to phone him at half-time with tactical instructions. Nobody expects the national coach to report to the manager of the club that supplied the goalkeeper. It would be absurd, and every fan in the stadium would see it.

In a project, it is Tuesday.

Most project managers have a line manager, like everybody else in the company. Nothing wrong with that. The trouble starts when the project is drawn into the line organization chart, and the project manager starts reporting on the project to that line manager. For the duration of the project, a project manager reports to the project’s Steering Committee, and only to the Steering Committee, as the governance model in the project plan should state.

The confusion does not stop with the project manager. Team members who are supposed to take direction from the project manager now also take direction from line managers who carry no responsibility for the project at all. It is not unusual for one team member to receive two different instructions about the same piece of work, from two different managers, in the same week.

Picture two coaches on the touchline, both shouting at the same left back. One is the national coach, who wants him to push forward. The other is his club manager, who wants him to take it easy, because there is an important league game on Saturday.

One Coach per Team

So, to be clear. For all project staff and all project activities, the temporary project organization supersedes the line organization, for the duration of the project.

Read that sentence again. If there is one mistake organizations keep making on projects of every size, it is ignoring it.

That does not make the line manager irrelevant. The club still pays the salary, looks after the player’s career, and gets him back after the tournament. The line manager still owns the appraisal, the training plan, and the person’s long-term development. What the line manager does not own is the project work.

A few things make the rule stick:

• Agree up front, in writing, which people are released to the project, for how much of their time, and for how long. Football federations agree release dates long before the tournament starts. Projects can manage the same.

• Put the line managers who supply the people on the Steering Committee, as the voice of the departments that supply the team. If they want a say in how their people are used, that is the table to say it at. Not the corridor.

• Show the project organization chart to the whole team, not just to the people who read the project plan. Everybody should know whose instruction counts on project work.

• When a line manager does need somebody back, the request goes to the project manager, and if it changes time, cost, or scope, it goes to the Steering Committee.

When the tournament is over, the players go back to their clubs, and nobody finds that strange either. The national team is dissolved until the next time it is needed. The project organization should work exactly the same way.

Until then, there is one coach per team.

Otherwise the left back, with two coaches shouting at him, does what most project staff do in that situation.

He listens to the one who pays his salary.

So the project waits as well.

Some committee members treat their seat like visiting hours. They come for the big moments, stay for the photo, and are gone before anything needs to be decided.

The word steering in Steering Committee was not picked at random. The committee is there to steer: set direction, approve the budget, and take the decisions the project team is not allowed to take.

That only works if the people around the table have the time, the authority, and the knowledge to do it.

Yet the composition of a Steering Committee is one of the least considered decisions in setting up a project. It is usually settled by an email from the sponsor and a quick look at the organization chart.

The New Wing

A hospital decides to build a new wing. Three years, a serious budget, and a press release.

At the announcement, everybody wants a seat on the building committee. The chairman of the hospital board. A member of the regional council. The well-known surgeon whose name might end up on the building. There is a photo of the first spade going into the ground, and every one of them is in it. The project is visible, strategic, and nothing has gone wrong yet.

Eighteen months later, the ground turns out to be contaminated and the budget is twenty percent over. The wing is still visible, for an entirely different reason. Suddenly the diaries are full, and the committee members start sending deputies.

Projects work exactly the same way. A visible, strategic project with a low risk of failure attracts candidates from every direction, because a seat on its Steering Committee is good for a career.

A high-risk project struggles to fill its seats from the start. And a project that starts to overrun finds its seats emptying one apology at a time, right when it needs decisions most.

Waiting for the Chairman

The second mistake is not political. It is a belief, and it sounds perfectly reasonable: the higher up the committee member sits, the more he or she will get done for the project.

Up to a point, that is true. A senior member can unblock things a project manager never could. But there is such a thing as too high up the ladder. The chairman looks excellent on the project organization chart. He also has forty other priorities, and yours is not near the top of any of them.

So the chairman does not come to the meetings. The contractor needs a decision on the redesigned foundations, and charges for every day the crew stands idle while it waits. The decision cannot be taken without the chairman. He is expected at the next meeting. And the one after that.

The committee that was meant to unblock the project has become the thing blocking it.

Then there is the question of who is not on the committee at all.

Nobody asked the nurses. So when the committee looks for savings to cover the overrun, it approves smaller lifts. They meet the building code, and they save a nice amount. Anybody who has ever pushed a hospital bed could have told them what the problem was.

On a project, the nurses are the group whose work the outcome depends on. Operations, who will run the thing. The supplier’s delivery lead. The business unit that has to change the way it works. Leave them out and the Steering Committee will take decisions that look fine on paper and cannot be carried out by the people who have to carry them out.

Picking for the Photo

None of this is hard to fix. It just has to be fixed at the start, when the committee is composed, and not halfway through, when nobody wants to be the one asking the chairman to step down.

For every seat, ask:

• Will this person attend, every time, for the full duration of the project?

• Can this person decide on budget, scope, and dates without first checking with somebody else?

• Who does this person speak for, and which group is left without a voice?

Not every stakeholder needs a seat. But every group the project depends on needs somebody at the table who knows that work and can commit to it.

A seat filled for visibility is a seat that cannot be filled for representation.

Note that seniority appears nowhere on that list. A head of department who turns up every month and can decide is worth more than a board member who turns up for the kick-off and the go-live party.

The project manager rarely gets to pick the committee. But the project manager can put those questions in the Project Plan and ask the sponsor to answer them, name by name, in writing. That alone is often enough to make somebody reconsider.

The new wing opened a year late.

The chairman came back to cut the ribbon, and every seat on the committee was filled again, for the photo.

Visiting hours.

The first bed arrived an hour later.

It did not fit in the lift.

The project has been running for two years. It has spent several million, it touches six departments and a vendor, and somewhere inside it are forty people working on it full time. The Steering Committee has one question about all of that, and the answer is a color.

Nobody asks for it that bluntly, of course. What gets asked is that the progress report be kept “as efficient as possible”. Fewer pages. Fewer words. Something a busy Steering Committee member can take in between two other meetings, in about five seconds, no matter what the project means for the organization as a whole.

Five seconds is enough for exactly one thing. The traffic light.

It is a paint-by-numbers kit with the numbers left off. Everybody colors in whatever looks right.

Some organizations have gone one step further and replaced the traffic light with actual smileys. A sad face for red, a happy face for green, and, our personal favorite, the indifferent face for amber.

:-|

Meh….

Everything Else is on Page Two

The methodology has not been abandoned. The project manager still fills in the full template every month: forecast expenditure, risks with their probability and impact, open issues, the quality of the deliverables. It is all there, in exactly the detail needed to steer on.

On page two.

On page one, at the top, sits the light. It is the highest level of abstraction a project report can reach. It does not even contain words anymore. Just a color.

The more thorough reports give every topic a light of its own. Time, cost, quality, scope, resources, each with its own little circle, and the overall status sitting above them all. It looks like six times the information.

Nobody can explain how two greens, two ambers, and a red add up to an overall green. But somehow they do. Every month.

There is nothing wrong with a traffic light as one indicator among others. The trouble is that it becomes the only one anybody reads. A Steering Committee can spend twenty minutes on the color itself, and the conversation is rarely about the project. It is about what the color will do once it leaves the room.

“Maybe it is best to leave it green for now...”

At that point, nobody is managing the project anymore. They are managing the color.

Green Until it Isn’t

A traffic light has no nuance and no context. Worse, it has no time in it.

Every project manager has written some version of this sentence: “At the time of writing, the project is still green, but it could very well be amber in two weeks.”

Read it again. Is that project in good shape, about to go wrong, or already on its way down? The sentence does not say, because the color cannot say. It describes today, and today is the one part of the project nobody can do anything about anymore.

A smiley tells you how the project feels this morning. It does not tell you how it will feel at go-live. And influencing how it will feel at go-live is the entire job of a Steering Committee.

A Color Needs a Number

Keep the traffic light, if the organization insists. Just make it mean something, and make it point forward.

Start by defining the colors before the project starts, in numbers. Green means the forecast lands within the agreed margins on cost and time, what PRINCE2 calls tolerance. Amber means a tolerance is forecast to be exceeded unless something changes. Red means it will be exceeded, and a decision is needed from the people in the room.

That is how a paint-by-numbers kit works. Nobody holding the brush gets to decide that area seven would look nicer in green. The number decides.

The same goes for every light underneath the overall one. Time, cost, quality, resources: each gets its own criteria, in numbers, agreed in advance. Cost turns amber when the forecast at completion exceeds the budget by more than the agreed tolerance, not when the project manager has a bad feeling about it.

Then agree how the lights roll up. The simplest rule is also the most honest one: the overall color is never better than the worst color underneath it.

That is not a new idea. It is PRINCE2’s management by exception, and the word doing all the work in it is forecast. The project manager does not escalate because something has gone wrong. The project manager escalates because something is going to.

Then never let the color appear on its own. Next to it go the forecast at completion against the budget, the forecast end date against the plan, and the risks that could move either of them, with what is being done about each.

That fits on one page. It will not be read in five seconds. It will take five minutes, which is the least a two-year, multi-million project deserves.

Undefined, a traffic light is not management information. It is a mood.

Which is exactly why it turns into a smiley so easily.

A Steering Committee that steers on moods will get a project that stays green right up until the week it turns red, with nobody quite sure what happened in between.

And the most honest face in the room will be the one on page one.

:-|

It was written to get the money, and it got the money. Then it went into a folder called 01_Initiation, and nobody has opened it since.

A wedding works the same way.

The couple at the altar has done their homework. They know exactly what they expect to get out of it, and it is not complicated. More time together. Evenings, weekends, someone to come home to. (Also, no more blind dates arranged by Mom.)

They have weighed the alternatives (other suitors, other lifestyles, staying single and keeping the whole closet). They have a rough idea of the costs, which will be staggering once the first child reaches college. They have agreed on the timescale: until death or forever, whichever comes first. They have even identified the key risks, and both sets of them will be at the reception.

Then they say it out loud, in front of everyone they know. For better or worse, for richer or poorer.

As business cases go, it is a good one. It even has a risk section.

And like every other business case, it is never read again.

Every Change Makes Sense on its Own

A few years in, the apartment in the city starts to feel small, so they buy the house in the suburbs. More space, a garden, better schools, and an hour of commuting each way. The house needs a second car, and the second car is the nice one, so somebody takes on more hours at work to pay for it. The garden is big enough for a dog, and the dog needs walking twice a day. And a man at the marina made them a very reasonable offer on a boat, which needs looking after every weekend.

Every one of those decisions was discussed. Every one of them was sensible. Every one was approved at the kitchen table, on its own merits, in about the time it takes to finish a glass of wine.

Not one of them was held up against the vows. Nobody at that table asked the one question the vows would have asked: does this give us more time together, or less?

Ten years later, they have the house, both cars, the dog, and the boat. They see each other on Sundays, at the marina.

Projects drift the same way, and the formal route is the more dangerous one. Scope creep at least looks like what it is. A change request comes with a form, an impact assessment, a number and a signature, and all that paperwork creates the comfortable impression that somebody has checked whether the project still makes sense.

Nobody has. The change was assessed against the plan: what it costs, what it moves, who has to do the work.

It was never assessed against the reason the plan exists.

One big change assessed that way can wipe out the benefits on its own. Twenty small ones will do it more quietly, because each of them was perfectly reasonable at the time. The project itself carries on, on schedule and on budget, delivering everything on the plan.

It just stops delivering the reason it was started.

Nobody ever signed off on the total. They only signed off on the boat.

Read the Vows Again

The business case has to stay on the table for as long as the project runs, and it has to be the thing every deviation is measured against. Not the plan. The case.

That starts with one question. Every change request answers what it does to the expected benefits first, and only then to the costs, the timescale, and the risks. If the honest answer is “nothing”, somebody writes down why.

Then keep a running total. A change should be measured against the business case as it stands today, with every change already approved counted in, and not against the version that was signed eighteen months ago. Twenty small changes only stay small if nobody adds them up.

And at every phase, the Steering Committee reads the whole thing again and answers one question: is this project still desirable, viable, and achievable?

PRINCE2 calls this continued business justification. It is the first of its seven principles, which has never stopped anybody from skipping it.

When the Reasons are Gone

Sometimes the answer is no.

The benefits have moved, or the costs have, or the market has, and the case that justified the project no longer holds. Every product on the plan can still be delivered.

It just won’t buy anything anybody needs anymore.

Here the analogy has to stop. For a marriage, that is a much harder conversation, and not one this blog is qualified to have.

A project has it easier. It is allowed to end the moment its reasons are gone. The methodology even has a name for it, premature closure, and it is not the worst thing that can happen to a project.

The business case was written to get the money. Its real job was always to tell you when to stop spending it.

The alternative is the project nobody believes in, and nobody will stop, absorbing budget and people for another year, because closing it would mean admitting the case stopped holding somewhere around the boat.

Fairy tales always end at the wedding.

Nobody wants to read about the change requests.

Two of them land within a few thousand of each other. The third comes in thirty percent under both.

You already know which one gets the job.

Here is the part worth looking at. The cheap builder is not incompetent and he is not guessing. He has built forty of these. He knows the ground behind the houses on that street, he knows what happens when you take a wall out of a building of that age, and he knows there is a fair chance of needing to underpin it.

He also knows that if he prices the underpinning, he does not get the work.

So he quotes for the version of the job where none of that happens.

Nothing in the quote is false. Every line of it is accurate, for the extension where the ground behaves, and the wall holds, and the weather cooperates. It is simply not a forecast. It is the lowest number that is still defensible on paper.

The Same Thing, with a Statement of Work

Now put that in a tender.

A software vendor is bidding for a piece of delivery work. The people writing the bid have done this before, many times, and they know exactly where it goes wrong. Interfaces to a system nobody has documented since 2011. A data migration that will turn out to be worse than the client believes. A client team that will not be available in the volume the plan assumes, because it never is.

All of it is known. Some of it is even written down internally.

None of it goes in the price.

Not because anybody is confused about whether these things happen. They are priced out deliberately, because the bid is a competition, and in that competition the honest number loses to the optimistic one every single time. Pricing risk is unilateral disarmament.

So the bid goes in on the best case, and it wins, and everybody shakes hands.

Nobody questions a best case. They never do. It is every bit as unlikely as the worst case, and it is the only one of the two that survives the meeting.

It is not technically a lie. It is purposely ignoring reality, which is a different offense and, in some ways, a worse one, because it requires knowing better.

What that Buys, on Both Sides

Then the risks land, as some of them always will.

The vendor discovers the project is no longer profitable, somewhere around month five, and the tone of the correspondence changes. Every request from the client becomes a change request. Every change request becomes a negotiation. The account manager starts attending meetings he never used to attend.

The client, who has a fixed price in writing, sees a supplier trying to charge extra for work they thought they had bought.

Both are behaving rationally. Both are furious. And the argument that follows is never really about the interface or the migration. It is about a number that was agreed a year earlier by people who knew it was optimistic and signed it anyway.

The negotiation ends in one of two places. Less scope for the same money, or the same scope for more. Neither is what anybody bought, and everybody ducks for cover.

Shift Focus from Quote to Risks

The fix is not a procurement rule. It is a question, and it belongs in the tender, where it changes who wins.

Ask every bidder for their top five delivery risks, with a price against each one and a plain statement of who carries it. Not a page of general assumptions and exclusions. Five named risks, five numbers, five owners.

• The bidder who cannot answer has not thought about it and will find out at your expense.

• The bidder who answers with disclaimers has thought about it carefully and is hoping you will not read them.

• The bidder who shows you five priced risks has just handed you the most useful document in the entire bid pack, and will probably look expensive next to the others.

Then compare the bids on their assumptions rather than on their totals. That is the only comparison that means anything, because that is where the bids actually differ.

The gap between the cheap quote and the other two is not a discount.

It is a list of things somebody has decided not to mention yet.

The wall needed underpinning.

It was always going to need underpinning.

The quote was accurate to the penny, right up until the morning somebody started digging.

“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.

Notice what it is not. It is not the worst case, which assumes every risk lands at once and is an inventory rather than a forecast. It is the weighted middle, and the one a good Project Manager should plan against.

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.