Good Intentions Don’t Translate to Good Outcomes

Most programs don’t fail because of bad people. They fail because of good people with unchecked ideas.

The requirements were written with care. The reviews happened. The working groups met. Everyone was trying to do the right thing. And somewhere between the original need and the final delivery, the thing stopped being about the person who needed it and started being about the process surrounding it.

That’s not a cynical observation. It’s a structural one. And until you see the structure clearly, you can’t fix it.

The Good Idea Fairy

There is a character that shows up in nearly every program that goes sideways. They don’t have a formal role in the org chart necessarily, but they are the chief cause of the drift – The Good Idea Fairies... They’re not malicious. In fact, they almost always actually want to help. They’re usually senior enough to be heard and removed enough from the front line to have stopped feeling the problem directly.

They arrive with a suggestion.

“What if it were multi-purpose?”

“Could we make it more flexible?”

“Shouldn’t it be adaptive?”

Those are not requirements. They are aspirations wearing the clothes of requirements. And in a regulated environment — government, defense, healthcare — each one of those words is a like a trigger.

The moment “multi-purpose” enters the requirements document, the program is no longer solving the original problem. It is now also anticipating every other problem it might conceivably be asked to solve. Safety has to assess the new contexts. Security has to expand the threat surface. Testing has to cover the additional use cases. Documentation has to cover the testing. Training has to cover the documentation. Governance has to oversee all of it.

None of those functions/disciplines are wrong to respond the way they do. Every regulated discipline is doing exactly what it is supposed to do. The cascade is feature, not a flaw. It is working as designed.

The actual failure occurred one step earlier… when nobody stopped to think. When no one asked the Good Idea Fairy a simple question: what problem on the front line are you actually solving with ‘multi-purpose’?

More often than not, the answer is none. But the suggestion sounds better. It feels more defensible. It gives the impression of forward thinking. One word. In one meeting with the wrong audience and without a single follow-up question. Now the program just got six months longer and end product becomes considerably harder to use.

The Person Who Needed It

Before the beginning of every single program in existence, if you look back far enough, there is a person… This person has an actual problem. The problem they have is usually specific and observable. (It is also inevitably far less complicated than what eventually gets built to address it.) This also is the person who gets stuck with that complicated and barely useful ‘multi-functional’ product that falls out of the other end.

That person, usually called an end-user, is consulted at the start. Their input goes into a document. The document gets approved. And then, almost without exception, the program stops talking to them. The end user is an afterthought until the program wants to roll out their shiny, flexible solution.

In between the initial ask and final reveal, a lot of things happen. Decisions get made about what they probably need. For them, not with them. Constraints get applied based on what is assumed about their environment. Assumed because once again, no one thinks to ask… We have to go fast, right? Features get added because someone, somewhere, decided they would be useful and make it more ‘multi-functional’ that the first ‘multi-function’ that was added. None of those people involved are the person with the problem.

They are interpreting, translating, and augmenting — through their own lens, with their own priorities, at increasing distance from the original need.

By the time delivery happens, the gap between what was needed and what was built can be enormous. Not because anyone failed at their job. Because the job everyone was doing had quietly shifted from solving the problem to managing the program.

The person with the problem is still there!! The one who needed a solution. They’ve been there the whole time. They adapted. They found a workaround. They got on with things. They didn’t file a change request because the system made that part hard and their need didn’t wait!

When the delivery finally arrives, they look at it and they recognize almost nothing of what they originally asked for. And they are not wrong. They take the ‘multi-function’ turd and throw it on a shelf or in a trashcan, and use their improvised solution.

Good Intentions Are Not Enough

The instinct to make something more ‘capable’, more ‘flexible’, more ‘future-proof’ is not a bad instinct. In isolation, almost every addition that gets made to a program is defensible. The additional functions mean it can handle more situations. The compliance requirement protects everyone involved.  But ‘defensible’ good intentions are not the same as actual requirements. Those solve actual problems held by real people.

The problem is not any individual decision. It is the accumulation of decisions made without returning to the original question: does this still serve the person we built it for?

That question stops being asked early in most programs. Not because people are negligent. Because the process doesn’t require it. Requirements are locked. Scope is defined. The program moves into execution and the feedback loop between what is being built and what is actually needed gets longer and longer until it effectively doesn’t exist.

By the final delivery, the program has answered a hundred questions that nobody asked and has not answered the one that started the whole thing.

What the Structure Has to Require

The fix is not a better requirements template. It is not another review gate or a more detailed approval process. Those are the mechanisms that got us here.

The fix is a standing obligation to return to the original person, with the original question, at every point where the program changes direction. Not a user representative appointed by management. The actual person who will use the thing, on the day it matters, under the conditions it was built for.

Before any new features get added, someone needs to be able to answer: who asked for this, and have we confirmed with the end user that it serves them?

Before any constraint gets applied, someone needs to ask: have we told the user what this means for them, and do they still get what they needed?

Those conversations are uncomfortable because people assume they surface disagreement or slow certain decisions down. And those do happen. But what they actually do is prevent the much larger cost of discovering at delivery that the thing you built is not the thing that was needed.

The most expensive outcome in any program is a faithfully executed wrong requirement. Everything that follows building the wrong thing expertly costs more than the conversation that could have prevented it. Thing like the rework, the delay, the loss of confidence, the capability gap that persisted while the program ran, and so on.

Good intentions matter. They are necessary. They are not sufficient.

What has to be asked, at every stage, is not just “are we doing this right?” It’s “Are we doing this right?” AND “Is this still the right thing to do for the person who needed it in the first place?”

If you can’t answer both of those questions, the program is running for itself (not the person you think).

At Leitwolf, keeping the original need in frame — and the original user in the room — is foundational to how we work. If your program has drifted or you want to make sure it won’t, let’s talk! Contact us: info@leitwolf.net