Case Studies

The bottleneck had nowhere left to hide

Nonconforming parts were piling up, waiting for disposition, and the process was extraordinarily complex. In an international collaboration, design authority is split part by part, and even within a single part it is split by area: this zone is ours, the next belongs to the partner. Every nonconformance meant finding the right department in whichever company owned that spot and getting its approval. The route ran through more than ten departments inside and outside the company. Nobody could say how many items were stuck at which stage. My predecessor had brought the backlog down once, but it had stopped moving.

I mapped the approval routes and built a database showing how many items were waiting at each step. I shared it at the weekly project meeting, so everyone could see where things were stuck. Then I set a monthly target for dispositions and required any department that missed it to bring countermeasures.

The internal department holding the most items didn’t have the people to process them. The section manager wanted to hire but couldn’t persuade the department head, who controlled headcount. I gave the section manager the backlog data as evidence and, at the same time, asked senior management to lean on the department head. Hiring got moving.

Outside the company the structure was different. The partners had no incentive to speed up dispositions. So I reframed the issue as profit and loss for the joint program as a whole, secured top-level agreement that dispositions would be done for the good of the program, and turned that into a monthly disposition plan with numbers both sides signed up to. Agreement alone doesn’t keep a plan on track. I set up a steering committee, showed the status every time things slipped, had the partners bring countermeasures, and kept following up.

The backlog that wouldn’t budge began to fall. The department that added staff got its dispositions moving, the two external partners started keeping to plan, and the blockages came loose one by one. By the time I moved on, the downward trend had taken hold and needed only watching. Visibility doesn’t mean making graphs. It means putting the blockages where everyone can see them.

Fewer meetings, faster decisions

More than ten people attended the weekly project meeting, and it decided nothing. The people who owned the agenda items were absent while everyone else talked around them. Materials hadn’t been updated since last time, and questions went unanswered. No one in the room could decide on the spot, no one could say who was holding things up, and so the problems sat. Minutes never went out, so last week’s settled discussion was repeated this week. Every meeting that was added wore the team down a little more and slowed decisions a little further.

I rebuilt the agenda around deliverables instead of departments. With every department’s report on a given deliverable lined up back to back, cross-departmental discussion could happen right there in the room. Materials were standardized at one risk per slide and updated every time. Follow-up frequency was set slide by slide: not everything every week, but the more urgent the risk, the more often I looked at it. I kept asking each department to send someone who could represent it and decide on the spot. If the person who came couldn’t decide, I asked for someone who could. Running the meeting, I pulled buried issues to the surface, named the kind of risk each one was, and routed each question to whoever could answer it. The minutes recorded who said what and who took on what, and went out to everyone. If no objections came back, they stood as the organization’s decision.

Attendance rose from 70% to 90%. Not because anyone was ordered to attend, but because people saw the value: come to this meeting, and things get decided. There were fewer meetings and faster decisions. Meeting reform was never the aim. Once decisions had a structure to flow through, the team began to run itself.

Crisis response became a playbook

On an international aero-engine collaboration, a major problem hit two or three times a year. A supplier announced a plant relocation. Our own machining equipment broke down. A certification test failed. Every unit of one part was rejected for defects, taking next month’s shipments to zero. Quality misconduct surfaced at a supplier. These are real examples, and none of them came with a warning.

When a problem hit, I had a one-page risk sheet written the same day. It answered three questions: What happened? Where in the program does it hit, and how hard? What is the first response? My standing orders to the team were blunt: the worse the news, the faster it comes up, and the impact assessment is due within a week.

Alongside the sheet, the team drew up a schedule, however rough, and put interim countermeasures in place. I laid out four or five options side by side, gave each an owner, and ran them all at once. With two options, you’re out of moves the moment they fail. With five, the program keeps moving even if some of them die. Running countermeasures in parallel costs resources. Not running them costs the program.

For high-risk problems, I held a follow-up every day. Each time new information came in, the one-pager was rewritten and countermeasures were swapped in and out. Round by round, the survivors narrowed down. Once the full impact was visible and containment was in sight, the problem went back into routine progress tracking. That is where crisis response ends.

Repeat that cycle with every crisis, and the team learns the playbook. Because everyone knows their next move, the first response gets faster. Problems closed out at least a month sooner, and that month went into the next problem. You can’t prevent crises. You can teach an organization to recover fast.

The crisis came after I left

I handed program management to my successor. At the handover, one risk was already in plain view: within six months, parts supply would run dry. Overall coordination, tracking the risk, carrying out the countermeasures: from here on, all of it belonged to the successor team. If what I had built was a real system, the team would keep it running on its own. If it had only ever run on my personal skill, it would stall here. Honestly, I was worried.

I handed over very little. Keep the system going, and here is why the system exists. That was all. I didn’t tell them to communicate closely or to show leadership. There was no need, because I had built it from the start so that no one would have to. How the PM meetings are run. Related departments raising risks on their own. People with the authority to decide sitting in the meeting. The playbook, crisis response included, had become common ground for the whole team. Personal skill can’t be handed over. A playbook can.

The crisis came. Parts supply nearly ran out, and our parts came within a hair of stopping the engine assembly line. The successor team carried their countermeasures through and brought supply back to a stable footing. My successor’s words have stayed with me: “Having the playbook in place makes it easier.” In calm times a project moves forward no matter who runs it. Whether a system is genuine is proven only by a crisis after the person who built it has gone. I believe consulting should be held to the same standard. Does it keep running after we leave?