Your Project Needs Its Purpose Back.

In every distressed safety-critical program I have walked into over the decades, there is a moment of genuine insight. I sit down with the senior engineers and project leads—the people who actually know how the system works—and within twenty minutes, they tell me exactly what is wrong with the project and exactly what would fix it.

They are usually right.

Then I ask: why isn’t this happening? Why are we not just executing what everyone in the room knows needs to be done?

And the answer is: nobody is letting us. The policy won’t let us. The customer is unhappy and unreasonable. Management is panicked and focuses on corporate standards. Process people are demanding compliance. Everyone is drowning in meetings and committees. Decisions take weeks—sometimes forever. Trust between the team and key suppliers has collapsed. The team has been running overtime for months, and nobody is sure anymore what they are running toward.

The truth is that senior engineers know what to do, but they simply have no permission to do it. And after enough months of that, they begin to lose faith.

This is the moment when consultants get called in. And this is also where many consultants get the diagnosis wrong.

The Misdiagnosis

The default assumption—among process consultants, interim project managers, process compliance specialists—is that distressed projects are engineering or process failures. In such cases, “gaps” are being closed, one by one. The defect curve was incorrect, so we meticulously installed a better ticket-tracking system. The release scope keeps slipping, so we define a 10-page scope governance work instruction. The traceability is flawed, so we mandate that the matrix be filled in. Process gaps in, process gaps out.

Those measures sound rational and correct, but they are just “process patches.” Almost every distressed safety-critical project I have seen is a purpose failure first, and an engineering failure second. The symptoms are real, but they are symptoms, not the disease.

When a team has lost its sense of purpose—why it is worth doing well, why it is worth doing at all—the metrics, while often useful, are not the solution. That is not because those measures are wrong, but because processes do not motivate anyone except for the compliance guardians. As a result, defects get logged casually, specifications drift, reviews become rituals, and the traceability measures become nebulous. The team becomes even more frustrated. The senior engineers, who could see all of this clearly, either check out or shift into self-protection mode. They stop bringing their best to a project that—as everyone feels—no longer deserves it.

You can install all the processes you like into that situation, and nothing will improve. Process without purpose is just a checkbox ritual, and senior engineers see through it faster than anyone.

Russell Ackoff Saw This Coming

The systems-thinking pioneer Russell Ackoff distinguished between purposeful and purposive systems. A purposive system is goal-oriented in a mechanical sense—it simply moves toward a target in terms of schedule and milestones. A purposeful system, on the other hand, has a goal that its members understand, share, and choose. In such projects, team members can explain why the goal matters and why it should be pursued.

A distressed project almost always starts as a purposeful system. At its inception, someone, somewhere, articulated a real reason this product needed to exist—a car that would actually be safer, a medical device that would actually save lives, a rail signaling system that would actually let trains run on time. That is why engineers joined the project. The team felt they were part of something that mattered not just to management but to the organization and even to society as a whole. The senior engineers signed up because they wanted to build the thing, not just collect the paycheck.

But over time, the purpose slowly and quietly erodes. Customer politics, self-serving siloes, scope creep, leadership churn, restructuring initiatives, sustained pressure—these are the factors that wear down the connection between the daily work and the original reason why this project exists. The system becomes purposive without being purposeful. People hit milestones without knowing what those milestones really mean. They produce deliverables that nobody is sure anyone reads.

When that happens, process or method improvements won’t help because the product has lost its intrinsic meaning.

Not Every Project Deserves to Be Saved

Although it might sound a bit dramatic, I want to emphasize one important point. No one can save some projects, because they were never worth saving in the first place.

Let me use a real example to make this point clear.

I once consulted briefly on Fiscus, the German federal-state effort to build unified tax-office software. The entire endeavor was truly a project Odyssey. Thirteen years, nine hundred million euros, sixteen Länder with conflicting interests—that was the frame. There was no coherent ownership and no shared purpose at any level of the organization. Bavaria and the eastern Länder eventually quit and built their own systems. The central project died. By the time I arrived, the question of “how to recover this” was the wrong question. The right question was: should this project have existed at all, in this form, with this structure, with these politics? The honest answer was no.

Projects like Fiscus are purpose-dead from the start. They were never built with a real purpose in mind. They were built around a political compromise, or a budget line item, or a vague aspiration that nobody could believe in.

This anecdote matters because genuine purpose defines whether a project can be turned around and saved. A recovery is only possible if the project was once actually really worth doing. That holds when there is a genuine product underneath, a real problem to solve, a real customer who needs it, and a team that originally signed up to build it for all the right reasons. In that case, the purpose is still in there somewhere, dormant, recoverable. Bring it back, and the team comes back with it.

However, if the project was rotten at the root—wrong structure, wrong politics, wrong premise—no turnaround magician can save it, and trying only postpones the inevitable end.

In other words, a project worth saving is the project that was originally worth doing. Get the purpose right, and the project can heal.

Bring the Purpose Back

When the project is genuinely worth saving, the first job is not to install better metrics or tighter governance. It is to reconnect the team with a credible reason for delivering this project.

That sounds “soft”—but it is not. It is a concrete, genuine insight.

It often takes the form of a direct conversation with the senior engineers, in which I ask them to name, in plain language, what this project, properly executed, would actually mean to the world. I mean, not the marketing version or the numb steering committee version, but their version. What does it mean, for them, that this product ships well? What does it mean if it ships badly? What would they want to be able to say about it three years from now?

The answer is usually straightforward and plain. I want this car’s lane-keeping to actually save someone’s life on a wet road at night. I want this medical device to be the one clinicians trust. I want the next generation of engineers at this company to learn from a project that worked rather than one that failed. I want to look at this product, ten years from now, and be proud of what we did.

When senior engineers articulate purpose to themselves, in front of someone who takes it seriously, something shifts. They remember why they signed up. They remember that they are still allowed to care. The defensive posture dissolves, and the unholy spell is broken.

In such decisive moments, I am not trying to play the role of a motivational speaker or simply try to make them feel better. I am trying to think with them more clearly about what this project is actually about. What follows is often an insight that they are not alone in this. That is already healing. What follows, when done right, is the miracle of a project turnaround.

What Senior Engineers Need

The conventional view of distressed projects assumes the team is the problem and outside expertise is the solution. But that’s very rarely the case. The senior engineers are not the problem. They are the most capable, committed, and knowledgeable people in the organization. They are also the most beaten down.

These are people who spent years at university studying complex technical and scientific matters. Then they spend years getting genuinely good at their jobs. They went into this work because they wanted to build things—real, complex, challenging products—things that mattered. Many of them are still, underneath the exhaustion, the same people they were when they started.

What they need is not more abstract instruction or more methodical or “standards” preaching. They need three things they have been missing for months (or sometimes even years):

Permission to do their actual job. Most senior engineers in distressed projects have been pulled into endless coordination, escalation, and political work. They often cannot remember the last time they had a clear week to think technically. The first thing a recovery does is give them that week back.

Cover from the organizational chaos. Senior engineers cannot do their best work while also fielding panicked questions from a steering committee. The recovery installs someone—a Project Lead with real authority, or a coach in the room, or both—who absorbs the noise and lets them work.

Belief that recovery is possible. By the time a project is in real trouble, the senior engineers have usually privately concluded that it cannot be saved anyway. They have mentally “checked out.” You can literally see that in their eyes. Sometimes they are right, and the project is Fiscus. But more often, they are wrong, and what they are missing is someone in the room who has seen worse and pulled it through, and who is honest about what is and isn’t possible. Pretending things are fine destroys credibility. There are usually clean, simple measures to restructure the project. They need to be spelled out with confidence. Done that way, it works.

A Note on Senior Engineers

Senior engineers—such as chief engineers, principal engineers, technical fellows, the people who have spent many years getting genuinely good at building complex products—are the most underutilized asset in modern safety-critical development. They are also, in my experience, the most starved for honest advice that resonates with their way of thinking.

The corporate world has spent decades promoting its best technical minds into managers—and then wondering why projects keep failing. It has filled its leadership ranks with people who are good at compliance but have forgotten how actually to build things. It has surrounded its remaining senior engineers with process apparatus that was supposed to scale their judgment but instead replaces it with checklists.

The senior engineers know all of this. They feel it daily. They are not naive about their own situation. What they need is not motivation. What they need is recognition—from someone with technical credibility—that they are right about what is wrong, and that this person is willing to fight alongside them to fix it.

That is, I think, the actual job. Everything else—the frameworks, the dashboards, the process design, the coaching—must be the core service to senior engineers, restored to their craft, building things they can be proud of, on projects that remember what they are for.

That is what I mean by bringing purpose back. And that, in the end, is what every distressed project that is worth saving actually needs.

---

The framework I use for this kind of work—including the recovery dashboard discussed in earlier articles—is available here.