Lessons Learned

What happened:The date, budget, and team size were already set. A few weeks later the sponsor came back from an industry event with a list of competitor features they wanted before go-live. Everything else was supposed to stay exactly as it was.

What I learned:I used to think protecting the plan meant saying no. What actually helps is making the trade-off visible: if this comes in, something else has to move, shrink, or leave. People can live with bad news; they struggle with invisible cost.

What I’d do differently:In the same meeting I would ask, out loud, what we are taking off the list if we add this — and write that answer down before anyone leaves.

Read the related article →

What happened:In a steering meeting everyone nodded along. After the call, three people described three different decisions. Two weeks later the work had already started in all three directions.

What I learned:Nodding is polite. It is not a decision. When nothing is written, everyone fills the gap with their own version — and they all feel honest about it.

What I’d do differently:Before we leave I write what we will do, what we will not do, who owns it, and when we look again. If someone disagrees, I want that in the room, not in Slack two weeks later.

What happened:We spent weeks with a sponsor who genuinely liked the idea. When we needed a real yes, the budget sat with someone who had never been in the room.

What I learned:Liking the work and signing for it are different jobs. Org charts rarely show who can actually move money, scope, or dates — you only find out when you ask.

What I’d do differently:Early on I ask who can approve budget, scope, and timeline. If that person is not in the conversation yet, I stop treating the friendly sponsor as the decision.

Read the related article →

What happened:We needed to leave a vendor. On paper it looked like signing with someone new. In practice the people, the processes, and most of the know-how were still sitting with the old one.

What I learned:A lower price does not replace a handover. If you treat the switch as paperwork, service dips in the middle — usually right when everyone is watching.

What I’d do differently:I would plan the transition like any other delivery: owners, dates, the real cost of leaving, and what we do if quality drops while both sides are still involved.

Read the related article →

What happened:The contract ended on a Friday. Monday the new supplier asked where the runbooks were. They lived in the heads of people who no longer picked up the phone.

What I learned:Whatever is only in someone’s head leaves with them. “We’ll document it later” usually means never.

What I’d do differently:Knowledge transfer gets dates and named people on the plan. I also check that someone who was not in the original setup can run the work without a rescue call.

What happened:Week one the team was polite and fast. By week four they were arguing about owners, quality, and who spoke to the sponsor. Leadership wanted to know what had gone wrong.

What I learned:That friction is often the team becoming a team — figuring out how they work when the easy tasks are gone. Hiding it does not make the work go away.

What I’d do differently:I name the stage out loud. Pretending everything is fine usually makes the next argument louder.

Read the related article →

What happened:One person just knew how the process worked. When they were out, the rest of us were guessing. Status still looked green because they kept answering Slack from wherever they were.

What I learned:Green can hide a single point of failure. The person being good at the job is exactly why nobody notices until they are gone.

What I’d do differently:I make the path visible, name a backup, and write down the exception the first time it happens — not after the third outage.

What happened:We had a weekly meeting everyone attended. Notes went out. A month later the same items were still on the list because nobody owned a date.

What I learned:Tools and templates help a little. Unowned actions do not move, no matter how tidy the agenda looks.

What I’d do differently:I end with one owner and one date, or I take the item off the list. “We’ll pick this up next time” is how it lives forever.

Read the related article →

What happened:We waited until two teams were already angry to talk about how we decide, who speaks for whom, and what “done” means. By then every sentence was about the last fight, not the work.

What I learned:If you leave the working agreements late, you negotiate them under pressure — when nobody has patience left for nuance.

What I’d do differently:While people still get along, I agree how we raise risk, who decides, and how we disagree in the room. It feels slightly awkward. It is cheaper than repairing trust later.

Read the related article →

What happened:The slide was green. The team was working nights. The date had already slipped in private. Nobody wanted to be the person who turned the box amber.

What I learned:A colour you hope for is less useful than a choice you need. The light protects the meeting; it does not protect the delivery.

What I’d do differently:I report the trade-off I am asking for — scope, date, or quality — instead of the colour that looks safest on the screen.

What happened:We were running training programmes that depended on travel. Then travel stopped. The programmes still had to happen, and nobody had agreed how a normal week looked without flights.

What I learned:You need a clear way of delivering the week before you polish slides, brands, or content. Without that rhythm, every other improvement floats.

What I’d do differently:I would lock the new delivery rhythm first — who meets when, what “done this week” means — then rebuild the rest around it.

What happened:A project stopped. The file was closed. People acted as if those months had not happened, so the next similar idea started from zero and hit the same wall.

What I learned:The waste is not only the money spent. It is repeating the same mistakes because nobody kept notes when it was still fresh.

What I’d do differently:I write down what we learned even when there is no launch. An abandoned project still has a story worth keeping.

Read the related article →

What happened:The date could not move. People offered extra hours as if that were a plan. Quality, scope, and how tired everyone would be in week six never made it onto the slide.

What I learned:Extra hours are not a schedule. They are a quiet decision to burn people and quality so the date can stay on the slide.

What I’d do differently:I name what comes off, what gets thinner, and what we will not pretend we can do. If none of that is acceptable, the date is not either.

Read the related article →

What happened:We started building because everyone was keen. Three months in, two departments had different pictures of success — and neither had signed anything that would have shown the gap early.

What I learned:A short charter is not bureaucracy for its own sake. It is the place you write why this exists, what done looks like, and who can change it when pressure arrives.

What I’d do differently:I would get that written before the build gathers speed. Enthusiasm is a poor substitute for a shared definition of done.

Read the related article →

What happened:UAT became the week people finally looked at the thing. New wants arrived dressed as bugs. The date stayed where it was.

What I learned:If you invent the product in UAT, you are planning to be late. Feedback is useful; treating every new idea as a defect is how scope hides.

What I’d do differently:Upfront I agree that UAT checks whether it works as specified. New wants go through change — not the defect list.

What happened:Go-live was treated as the end. Handover, owners in operations, and who to call in six months were left for later. Later never had a slot on the calendar.

What I learned:Close is work. If it is not on the plan, the project team keeps answering tickets forever — usually without anyone calling it that.

What I’d do differently:I put handover on the schedule: what we hand over, to whom, and how we know it can run without the project team standing nearby.

Read the related article →

What happened:A piece of work had no end date, no definition of done, and the same people every month. We still called it a project, so nobody owned it as a service and nobody was allowed to stop it.

What I learned:Calling BAU a project is how neither gets managed. One needs a close; the other needs an operational owner.

What I’d do differently:If it should keep going, I give it an operational owner. If it should end, I give it a close date. The label has to match the reality.

Read the related article →

What happened:Someone asked whether we were Agile or Waterfall before anyone could say what done meant, who the users were, or whether the date was real. The method debate used up the first three meetings.

What I learned:The framework is not the plan. Choosing a label before you understand the uncertainty just gives you a vocabulary for arguing.

What I’d do differently:I choose a way of working after I know the uncertainty, the stakeholders, and the real constraint — date, quality, or learning. Then the method has something to serve.

Read the related article →