Our lead architect resigned mid-project. We kept the program moving.

A few years ago, I was the engagement manager on a Kinaxis implementation for a global semiconductor company. We were moving them off older planning tools in phases. Several workstreams were running at once, and the client was already unhappy because our functional designs kept missing what they expected.

Then our lead onshore architect resigned.

The first instinct on the team was to cover it internally and hope the client would not notice. I understood why. Nobody wants to walk into a tense client meeting with more bad news. But the client was going to find out one way or another, and I would much rather they heard it from me, with a plan, than from someone else a few weeks later.

So I told them early, explained how we would backfill the role, and showed them how the plan would change.

It helped to admit we had two problems, not one. One was capacity: we were short a senior person. The other was quality: the designs were already off before the architect left. Backfilling the role took care of the first. The second took longer. We went back through the functional design specifications with the client several times, until they matched what the business actually needed.

While we did that, I did not want the developers sitting idle. We kept them building on the parts of the design that were stable, and we brought in an extra technical lead so the remaining team was not stretched even thinner.

The part people tend to forget is the team itself. When someone respected leaves, everyone feels it, and the work they leave behind lands on somebody. We rebalanced the workload early and brought in help where we could. It cost a bit of time up front, but a burned-out team would have cost us much more.

The first sprint of system integration testing closed with no delays, with 30 of its 33 user stories complete and the core planning specifications signed off.

Once the designs settled, the real size of the work became clear. We started with about 160 user stories and ended up needing more than 400. That changed the timeline, and there was no point pretending otherwise. Instead of stopping to replan everything, the team kept delivering what was already in progress while we wrote new stories and features in parallel, and we worked through them steadily. The program went live on budget.

Looking back, I do not think we did anything clever. We just treated the resignation as a real risk to the program from the first day, instead of a staffing hiccup to work around.

If your program leans on one or two people more than anyone would like to say out loud, that is worth knowing before they hand in their notice. The Project Health Self-Assessment touches on it, and I am always happy to talk it through on a 30-minute call.