When Good Programs Fail, Who Gets to Define Success?

Complex programs don't usually fall apart because someone wasn't doing their job. More often, the work is moving, milestones are being met, and the people closest to the program believe things are on track. Then a problem surfaces that, in hindsight, someone could see coming.

Usually, someone knew.

They understood a regional constraint, a dependency between disciplines, or simply how the work actually operated in a particular place. That knowledge wasn't intentionally ignored. It just wasn't part of the conversation when the program's definition of success was established.

That's what makes these situations difficult. The problem isn't necessarily communication, it's representation. The instinct is to call this a failure. It's more accurate to call it incomplete - not wrong, just missing a perspective that was never structurally invited in.

"Done" means different things to different people

On a distributed program, there can be several legitimate definitions of what it means for something to be finished.

Consider physical security. The locksmith may look at a lock and say the work is complete. The person responsible for the electronic security system may have a different definition. The low-voltage technician responsible for the wiring between them has another.

A useful way to describe this gap is: "the lock works, the security system doesn't."

None of those people necessarily did anything wrong. The locksmith did their job. The low-voltage technician did theirs. The security system may work as designed. The problem exists in the space between those definitions of done. Each person can be right about their own piece and the system can still fail to deliver what it was supposed to deliver.

The same thing happens across regions and disciplines. A central team may be focused on consistency and reporting. A regional team may be focused on operational reliability or local requirements. A delivery team may be focused on technical completion.

Those priorities aren't noise. They're a reflection of what each group is responsible for.

The trouble starts when one definition becomes the definition for everyone.

A good relationship can still create a blind spot

A common way this happens is through a strong central relationship.

Someone asks the person they trust what the program needs. They get a clear answer, and the work moves forward. Nothing about that interaction is unreasonable. In fact, it's probably exactly how the relationship should work.

The problem is that a relationship that works well can become the entire channel.

A single point of contact gives a program a real definition of success. Just only one.

That definition is shaped by the person's role, region, seniority, incentives, and understanding of the program. It can be completely accurate from where they're standing and still miss what another group needs to operate, accept, or maintain the result.

The risk isn't that the person is wrong. It's that one microphone gets mistaken for the whole room. The relationship isn't the problem. Treating it as the whole picture is. The real question isn't whether the relationship is good. It's whether it's broad enough to carry the right perspectives, and whether there's a structure for those perspectives to actually reach the decision.

This isn't a character problem. Nobody has to deliberately exclude someone for this to happen. There just isn't always a structural reason to bring another perspective into the conversation.

Someone outside the room may know what matters most

In one global program, the central relationship was genuinely strong. Milestones were moving, reporting looked healthy, and the core team was confident in the model.

The disconnect came from a regional group whose operating reality hadn't made it into the room where priorities were being defined.

A regional stakeholder understood how the work progressed in the region, who needed to be involved, and what timelines were realistic versus what looked realistic on a project schedule. That knowledge changed how readiness was defined. The central team had been measuring readiness by whether the infrastructure was in place, while the region understood that readiness also depended on local staffing and training timelines that the original plan had not accounted for.

It wasn't that this person was particularly clever or had some secret information. They were close to the thing that would ultimately determine whether the plan worked. They just weren't part of the relationship where the plan was being made.

This kind of knowledge can also disappear during a handoff. Documents move from one person to another, but the judgment behind those documents doesn't always make the transition.

Nobody writes down, "Here's the thing I'd worry about at 2 a.m." But sometimes that's the most important part of the handoff.

More meetings aren't the answer

The natural response to a representation problem is often to add people to the meeting.

That doesn't work, at least not by itself.

Five conversations inside the same reporting line can produce five confident versions of the same blind spot. The number of conversations isn't the important part. What's important is whether someone brings a genuinely different vantage point to the discussion.

The goal is independence of perspective, not conversation volume.

Someone should be able to identify a constraint the group didn't already know it had. They need a real route into the decision, and they should be able to see what happened to their input.

And somebody has to own that relationship after the first conversation.

Representation isn't something a program can check off once.

Don't assume silence means agreement

Silence is one of the easiest things to misread on a distributed program.

A quiet team may agree. It may also have decided that raising concerns doesn't change anything, so there's no reason to keep raising them.

Those situations look very different from the inside, but both can look like agreement from the center.

When a group that used to push back suddenly goes quiet, that's a good time to ask a direct question rather than assume the lack of objections means everything is fine.

The goal isn't to create disagreement. It's to find out whether the people responsible for different parts of the program still see their reality reflected in the plan.

Define "done" before the work starts

For distributed programs, "done" should be defined by region and discipline before the work begins, with the overlaps between those definitions made explicit.

There can still be a shared outcome at the top. Underneath it, each group can have its own acceptance conditions, dependencies, owner, and evidence of completion.

That doesn't mean every region needs to follow the same process.

On one global program, reporting milestones were changed to match how different regions actually operated rather than forcing everyone onto headquarters' schedule. The program still maintained consistent visibility into the work. The process just wasn't identical everywhere.

That distinction matters. Consistency of visibility isn't the same thing as identical processes.

The same goes for cadence and ownership. Two groups can be doing good work and still miss each other because their meeting rhythms don't overlap. Over time, one group can quietly become an observer instead of a participant.

Being heard once isn't the same as being represented continuously.

Getting the right perspectives into the room is representation. What happens once they're there - who decides, what counts as evidence, how disagreement gets resolved - is governance. A program needs both. A useful test is to ask four questions:

• Who owns the decision?
• What evidence counts as done?
• When and how do the relevant groups connect?
• What happens when they disagree?

If those questions don't have clear answers, what you have is a meeting invite, not a representation model.

Broaden the definition before you accelerate the delivery

A better starting point for a distributed program is to test representation before testing progress.

Which disciplines, regions, operators, and acceptance authorities are going to live with this definition of success? Which of them aren't in the room yet?

That doesn't mean agreeing with everyone's preferences. It means understanding what risk another group is responsible for before judging how they respond.

A lot of what looks like resistance is someone protecting something they own that others don't.

The most valuable person on a distributed program isn't necessarily the person who understands every discipline. It may be the person who notices that two groups are quietly operating from two different definitions of success and gets into that gap before it becomes a surprise on someone's desk.

This is where a lot of TEECOM's own work lives - at the interfaces between disciplines, regions, and the different definitions of success each group is quietly carrying. That's usually where a program actually breaks, long before it shows up as a missed deadline.

The practical version is simple: broaden the definition before you accelerate the delivery.

The question isn't whether a program listened enough.

It's whether the people who knew were in the room.

TEECOM Can Help

Complex technology programs depend on more than getting each individual system right. They require coordination across disciplines, regions, stakeholders, and project phases so that different definitions of success come together in the final result. TEECOM helps clients bridge the gaps between design, delivery, and operations by bringing the right perspectives into the process early, identifying dependencies across technology systems, and creating alignment around what success looks like. By connecting technical requirements with operational realities, TEECOM helps clients deliver integrated technology solutions that work not only on paper, but in the environments and organizations they are designed to serve. Contact us to learn how TEECOM can support your next project.

About the Author

Tony Asman is a Technical Project Manager with 14 years in program development, delivery, and leadership for enterprise clients, managing complex, multi-site, multi-region technology deployments across access control, video surveillance, and intrusion detection. His work has consistently centered on the space between disciplines and geographies - where a system that's technically correct in one region's operating reality still needs to be re-translated for another's. Tony believes the strongest design doesn't just meet specification; it accounts for who else has to live with the result.