Lessons Learned

What happened:I was running a capital raise project for a client working with C-level executives. During due diligence, the C-level executives and the team kept sending projection-based data instead of actuals. Every document came in with different numbers, none of them matching the baseline we'd agreed on. Each time, it triggered another round of rework on the IM deck. There was no change control on the data itself - it just kept shifting without anyone flagging it as an issue. Our weekly status meetings had no real progress to report, just the same open item carried forward. The milestone that was set for May slipped to June, then July, then September, then rolled into the next year.

What I learned:This wasn't a scope problem, it was a data governance problem. I was managing document versions instead of managing the root cause. The moment you see the same inconsistency show up a second time, it belongs in the issue log as a formal risk, not just another edit to the deck.

What I’d do differently:I'd log the first mismatch as an issue immediately and escalate it to the sponsor early, instead of absorbing it as "just another update." I'd also restructure the status meetings around a single source of truth - no deck work until the C-level executives sign off on one dataset we can actually baseline against.

What happened:I was running a training project for a government institution in Qatar, with the sessions set to take place in London. Everything tracked to schedule right up until one day before the start date. That's when a flood disaster hit the SME's home country. Both communication and transportation went down at the same time - I couldn't reach the SME, and there was no way for them to travel even if I could. The start date had to move.

What I learned:A single point of failure on a critical resource is a risk, even when everything else on the plan looks solid. I had no contingency in place for the SME being unreachable or unable to travel - the plan assumed they'd just show up. Force majeure events don't ask for a heads-up, so the risk register should have had a line for this kind of scenario, even if the probability looked low.

What I’d do differently:I'd build a backup plan around the SME earlier - either a co-facilitator who could step in, or a remote delivery contingency that didn't depend on physical travel. I'd also set a clear trigger point for when to notify the sponsor and stakeholders, instead of waiting to see if the situation resolved on its own.

What happened:I was managing a project where the sponsor was happy with progress, but every review call ended with a small extra ask - "can we also add this," "can we also check that." None of these felt big enough to push back on individually, but three months in, the scope had grown well past what we'd baselined, and the schedule hadn't moved at all.

What I learned:Scope creep rarely shows up as one obvious event. It comes in small pieces that each look reasonable on their own. By the time I connected the dots, I'd already absorbed a lot of extra work without a formal change request.

What I’d do differently:I'd log every "small ask" as a change request from day one, even the tiny ones, and let the sponsor see the cumulative impact on a running list. Once people see the pattern in writing, the small asks slow down on their own.

What happened:A big chunk of the project depended on one vendor's integration work. Everything else on the team was moving fine, but this one dependency kept slipping - a week here, a week there - and nobody flagged it as urgent because each delay looked small in isolation.

What I learned:A dependency with only one supplier is a risk even if that supplier has a good track record. I'd treated it as a normal task on the schedule instead of as a single point of failure that needed its own escalation path.

What I’d do differently:I'd have set clear checkpoints with the vendor early on, tied to consequences if missed, and kept a parallel backup option in mind from the start instead of only reacting once the slippage became visible.

What happened:Half the team worked from the office, half remote. Decisions kept getting made in hallway conversations at the office, and the remote half found out about them a day later, secondhand. Meetings felt fine on the surface, but people were working from different versions of the plan.

What I learned:A communications plan on paper doesn't fix this - it only works if it's the actual habit of the team. The real gap wasn't the plan, it was that decisions weren't being written down in one place everyone could see.

What I’d do differently:I'd push every decision, no matter how small it felt in the moment, into a shared log the same day it was made. That one habit would have closed the gap between the two halves of the team.

What happened:We had a clear setup - the product owner owned the backlog, and the team planned each sprint based on what he prioritized. Then the CTO started coming to me directly, asking to squeeze in items that hadn't gone through the product owner at all. Each request came with a good reason and a sense of urgency, so it was tempting to just say yes and sort it out later.

What I learned:Letting requests bypass the product owner, even with good intentions, quietly breaks the whole prioritization model. If I keep saying yes outside the process, the backlog stops meaning anything, and the product owner loses authority over his own plan without anyone deciding that on purpose.

What I’d do differently:I'd redirect every CTO request straight back to the product owner, framed as "let's get this prioritized together" instead of just absorbing it myself. If it was truly urgent, I'd get the CTO and product owner in the same conversation to trade off against what was already committed, rather than negotiating scope changes one-on-one with either side separately.

What happened:We were running on a PHP infrastructure that worked fine, no real complaints from anyone. Then one of the founders decided we needed to move to a different tech stack and got the investor on board with it. We brought in a specialist for the new technology - someone with a rare skill set, working mostly as a freelancer with his own small team. The first stretch went well. But the project direction kept shifting and the timeline slipped, so instead of adjusting the schedule, we kept adding more developers to catch up - a form of crashing, though nobody called it that at the time. Each new developer came in and rewrote or dismissed the previous person's code instead of building on it, so the extra headcount didn't actually buy back the time we'd lost. Then came a scheduled demo for a client, and it simply didn't work. When I reported the failure to the team, the founder treated it as my fault and went cold on me afterward.

What I learned:Crashing only works if the added resources can actually plug into the existing work. Adding people to a codebase with no clear ownership or handover process just adds more rework, not more speed - the cost went up but the schedule didn't improve. I also learned that a tech pivot needs the same rigor as any other major scope change - a transition plan and a shared definition of "done" that survives a change in developer. And when a demo fails, the story that sticks isn't the six months of shifting direction before it, it's the five minutes on stage.

What I’d do differently:Before adding more developers, I'd check whether crashing was even the right call here - fast tracking parts of the work, or simply resetting the schedule with the founder, might have been cheaper and safer than throwing people at a shifting codebase. I'd also push for a code review and ownership handover process the moment a second developer came onboard, and I'd run a full rehearsal of any client-facing demo against the actual current build, not the version from two weeks earlier.

What happened:I was working on a project funded by an investor who was also sponsoring a second startup at the same time. On paper, he was acting as the sponsor for both - the person who should have been holding governance and accountability. In practice, he had a personal friendship with the founders, and that relationship overrode his sponsor role. As PM, I kept my side of the process clean: status reports on schedule, feedback loops closed, milestones tracked against the baseline. None of it changed the outcome. Budget kept getting released for trade fairs and promotional giveaways before the product had even passed its readiness criteria. Spend was being approved against visibility, not against the business case.

What I learned:Reporting only drives decisions when the sponsor is actually using it to make decisions. Here, the reports existed, but they weren't functioning as a governance tool - they were just documentation. The real gap wasn't communication, it was that the sponsor's personal stake in the founders' friendship replaced his stake in the project's business value, and no report format fixes a sponsor who isn't holding the line.

What I’d do differently:I'd tie every spend request to a specific milestone or acceptance criterion in the project charter, so releasing money without meeting readiness gates would need a formal exception, not just a sponsor's nod. I'd also escalate the pattern as a risk the first time I saw it - not the individual purchase, but the recurring gap between spend and product status - and get it logged formally instead of letting it stay an informal observation across status meetings.

What happened:I was working at an e-learning product company. The project scope was clear, the product existed, and management had set a target around producing a certain volume of content. We ran the project against that target and delivered on it. But when the product reached the market, it didn't meet customer expectations. It turned out customers weren't just buying content - they expected an enterprise-ready product, something their organization could roll out and use across every function, not just a growing content library. We had optimized for the wrong success metric the whole time.

What I learned:Hitting your defined scope doesn't mean you've hit product-market fit. The project's acceptance criteria were internal and management-driven, but they were never validated against what the customer actually needed at the enterprise level. I was managing to the plan, not to the market, and by the time the gap showed up, we'd already spent the budget and the timeline on the wrong priority.

What I’d do differently:I'd push to validate the target itself against customer requirements before locking the scope, not just execute against a number handed down from management. I'd also build in a checkpoint partway through - a pilot with real enterprise customers - so any mismatch between what we were building and what they needed would surface early enough to still course-correct, instead of only showing up after launch.

What happened:I was managing a project where a key deliverable needed approval from several stakeholders. Each person had a small comment, so we kept sending the document around for another review. Nobody wanted to be the person holding things up, but nobody wanted to give final approval either. The document went through several versions while the downstream work was waiting.

What I learned:More reviewers don't always mean better control. At some point, review needs to end and someone needs to accept the deliverable. We had a review process, but no clear approval authority.

What I’d do differently:I'd define the approver before the review starts and give everyone else a clear role. Comments can come from many people. Final acceptance cannot. I'd also set a review deadline and make the impact of a missed approval visible on the schedule.

What happened:I was managing a project where one team finished its part and moved on to another priority. A few weeks later, we found out that the next team was still waiting for information and access from them. Everyone thought the handover had happened because the files had been sent. The receiving team thought it was incomplete because nobody had walked them through the process or confirmed what they had received.

What I learned:Sending files is not the same as handing over work. I had tracked the deliverable as complete when the receiving team was not actually ready to use it.

What I’d do differently:I'd define handover as an acceptance point, not just a task completion. The receiving owner needs to confirm that they have the information, access, documentation, and knowledge they need. Only then would I close the handover.

What happened:I was running a project where several workstreams were moving in parallel. One team made a small change to its part of the solution without realising another workstream depended on the old behaviour. Nothing broke immediately. The problem appeared later when the two pieces came together and we had to rework both sides.

What I learned:A change can look local and still affect the whole project. We were tracking tasks well, but we weren't looking closely enough at the dependencies between them.

What I’d do differently:I'd review cross-team dependencies whenever a requirement or design changes, not just update the task itself. If a change touches another workstream, I want the owner in the conversation before the change is implemented.

What happened:I was managing a project with a tight deadline when one of the key people became unavailable (getting fired). The work didn't stop immediately because the rest of the team tried to cover it. Within a few days, though, other tasks started slipping because people were taking on work they hadn't planned for.

What I learned:A resource risk doesn't only affect the person's own tasks. It can spread through the whole plan when other people start covering the gap.

What I’d do differently:I'd identify critical roles and backups during planning. When a key person becomes unavailable, I'd replan the affected work instead of quietly distributing it across the team and hoping the impact stays small.

What happened:I was managing a project where the business wanted to launch on a fixed date. As the date got closer, several lower-priority items were still open. Instead of making a clear decision about what could wait, the team kept trying to finish everything. The final weeks became a long list of small fixes and last-minute requests.

What I learned:A fixed launch date forces prioritisation. If everything remains a must-have, the team has no real way to protect the date.

What I’d do differently:I'd agree on the minimum scope needed for launch earlier and keep a clear list of what can move after go-live. When the date is fixed, scope has to become the variable. Otherwise we're just pretending the plan is still under control.