We Did Everything Right

And That Was the Problem

About seven years ago, I was part of a consulting engagement with a billion-dollar insurance company preparing to replace its IT Service Management platform. Before implementing the technology, the company wanted to get its processes in order. Our job was to assess the environment, design a set of ITIL-aligned service management processes, help implement them, and eventually translate those processes into the new platform.

At the beginning of the engagement, I asked the CIO a question I ask almost every client: What does success look like to you? His answer was remarkably candid. This was a publicly traded company. He had governance responsibilities, and compliance and auditability were not abstract concerns. As he put it, “ITIL keeps me out of jail.”

Fair enough. That was not cynicism; it was an honest description of something he needed from the engagement. By that definition, we succeeded. The client was happy. The engagement was extended. The deliverables were accepted, the new platform moved forward, and we did exactly what we had been asked to do.

I walked away deeply dissatisfied with what we had accomplished.

That dissatisfaction was difficult to explain at the time because there was no obvious failure to point to. We had not missed the deadline or exceeded the budget. The client had not rejected our recommendations. Nobody had accused us of misunderstanding ITIL or producing poor work. By nearly every conventional measure, the engagement was successful. It took me years to understand why success felt so much like failure.

We Knew How to Do This

This was not the client’s first attempt at improving IT Service Management. Another consultancy had been there before us, and early in the engagement I was given some of the documentation they had produced. It was good. That matters, because this story would be much easier if their work had been obviously bad. I could point to somebody else’s terrible process diagrams, shake my head knowingly, and explain how we arrived to fix everything.

But that is not what happened. Their documentation looked much like the documentation I would expect to produce on an engagement of this kind. Then we proceeded to do many of the same things.

We started where these engagements often start: the Service Catalog. For roughly two weeks, we sat onsite with essentially the same group of knowledgeable decision-makers and talked through the services IT provided. What should the Service Desk offer? How should requests enter the organization? Who should own them? Where should approvals occur? How should incidents be handled? What should onboarding look like? What would a mature, ITIL-aligned service management organization do?

There were interviews, workshops, whiteboards, and Visio workflows—so many Visio workflows. We were good at this work. We could take complicated conversations and turn them into orderly diagrams. We could establish ownership, clarify responsibilities, define handoffs, align processes with accepted practice, and produce a future state that made sense on paper.

The client loved it. Our initial assessment-and-design engagement went so well that we were extended for nearly six months to help implement the new processes and support their translation into the replacement service management platform. We had expertise, a respected industry framework, stakeholder participation, professional deliverables, and a clear methodology.

There was just one small problem: we had barely watched anybody work.

The Organization We Were Told About

We had spent two weeks talking with knowledgeable people about how the organization worked. More precisely, we had talked about how it was supposed to work, and that is not the same thing.

The people in those rooms were not lying to us. They were not incompetent or disconnected from the organization. They understood their responsibilities, their policies, their organizational structure, and their intentions. They knew the system—but they knew it from where they sat. Their view was real, informed, and incomplete, just as every view of a complicated organization is incomplete.

We took that perspective, combined it with our own expertise and an established industry framework, and constructed a future state. Then we treated that future state as ready to implement. We had skipped something so basic that, looking back, it seems almost absurd: we had never established the current state by observing it. We asked the organization to describe itself to us, and then we treated the description as evidence.

This is a subtle methodological error because every individual activity looks legitimate. Leadership interviews are useful. Policies matter. Process owners know things other people do not. Frameworks give us valuable language and tested practices. Workshops can expose disagreement and create alignment. None of those things is the problem. The problem emerges when descriptions of the system become substitutes for contact with the system itself.

When we began introducing the new processes, the people expected to use them reacted about the way people usually react when consultants arrive with polished process diagrams: they nodded politely, attended the training, and then returned to doing what they actually did every day. There was no rebellion. Nobody stormed out of a meeting or marched into the CIO’s office demanding that the consultants be removed. The processes simply failed to alter the operating system in any meaningful way.

Remarkably, that did not make the engagement unsuccessful. The client remained happy. The work continued. The invoices were paid and the deliverables accepted. We were accomplishing what we had been hired to accomplish; we simply were not moving the needle nearly as far as everyone believed.

When Reality Finally Entered the Room

Several months into implementation, we finally sat down with people on the Service Desk and watched them work. We did not do this because we had experienced a sudden methodological awakening. We did it because we were trying to determine how our shiny new processes would fit into the new tool. As far as we were concerned, the processes themselves had largely been designed.

Then I started walking through those processes with the Service Desk, and they looked at me as though I had three heads. So I asked a more useful question: What do you actually do?

Show me how a request arrives. Show me where you go next, who you speak to, what happens when the expected path does not work, and what you do instead. Show me where you leave the system. Show me the spreadsheet, the Post-it note, the side conversation, and the thing everyone knows is required even though no procedure mentions it.

Suddenly we were learning about the system we had supposedly assessed months earlier—not the documented system, the intended system, or the ITIL-aligned system, but the operating system. The real one.

That system was full of adaptations. Some were efficient and some were clumsy. Some compensated for limitations in the tool; others compensated for limitations in the process or the organization around it. Some were products of history. A few probably should not have existed at all. But almost none were arbitrary. People had reasons for working the way they did. They were solving for constraints we had never taken the time to understand.

We had approached those adaptations as deviations from the process we were designing. In reality, they were evidence about the environment into which that process would have to survive. We had encountered the organization after reality had shaped it—and only then realized we had designed for the organization before reality had its say.

The Constraint We Never Named

There is a version of this story I could tell that would make me look considerably better. In that version, I recognize the problem immediately, stop the engagement, gather the stakeholders, and explain that our assumptions were incomplete. We return to the beginning, observe the environment properly, reconsider the design, and rebuild our recommendations around what we have learned.

That is not what I did.

We were already months into the work. The client had invested money, and we had invested time. Processes had been approved. The technology project was moving. This was also, candidly, a very profitable engagement, and I wanted another extension. The incentives all pointed in the same direction: preserve the work already completed and absorb the new information without disturbing the engagement’s underlying story.

So I adapted—not the engagement, but myself. I re-interviewed decision-makers, this time armed with a much better understanding of what people actually did. We called it “tuning.” We tuned the processes for the tool, refined workflows, and incorporated implementation details. Technically, none of that was untrue. The processes improved. They became more representative of the operating environment and more honest about how work moved through the organization.

It worked, but it was never quite right, because all of that new information entered the engagement under an unstated constraint: the work we had already done had to remain fundamentally correct. Reality was permitted to modify the design, but it was not permitted to challenge it.

That felt like a lie. Not because the resulting processes were dishonest; they were better than the ones we had started with. The lie was subtler. We described what we were learning as refinement when it was also evidence that we had begun in the wrong place. “Tuning” allowed us to preserve the appearance of methodological continuity while quietly repairing the consequences of a weak current-state assessment.

Two Definitions of Success

I keep returning to the fact that the client was happy because I think it matters. It would be convenient to reinterpret the engagement as a straightforward failure, but that would be as misleading as calling it an unqualified success. The CIO had told me what success looked like to him. Governance mattered. Compliance mattered. Auditability mattered. Replacing the service management platform mattered. Those were legitimate business outcomes, and we helped deliver them.

I did good work on that engagement. I am still proud of parts of it. The problem was that somewhere along the way I had developed another definition of success: I wanted the system to be better because we had been there. Not merely prettier, better documented, or more closely aligned with a respected framework on paper. I wanted the organization to be measurably more capable of doing its work.

I was not convinced it was. If I walked into that organization today, I would be surprised if our engagement had fundamentally advanced its service management maturity. We assessed, recommended, designed, implemented, and delivered. We had a methodology, expertise, stakeholder participation, and professional artifacts. What we lacked was a disciplined way to make operational reality the starting point—and, later, a willingness to let evidence challenge the work already done.

That distinction changed the way I think about consulting. A project can meet its contractual obligations and still fail as an intervention. A deliverable can be accurate within its assumptions while those assumptions remain dangerously incomplete. A client can be satisfied because the work solved the problem leadership commissioned, even while the people doing the work continue to inhabit a different problem entirely.

Observation Before Intervention

After that engagement, I developed a habit. Whenever I could, I wanted to sit with the Service Desk first—before executive workshops, before redesigning the Service Catalog, before deciding what Incident Management should look like, and certainly before telling anyone what needed to change. I wanted to watch work enter the system and follow it wherever it actually went.

At the time, this was more instinct than methodology, and instinct is surprisingly difficult to sell. “I am going to spend time sitting beside your people and watching them work” does not sound particularly sophisticated in a consulting proposal. Where is the assessment, the maturity model, the gap analysis, or the slide deck? I knew observation mattered. What I did not yet have was language for why it mattered or what should happen after it.

Over time, I found that language in what I now call the Foundry Framework: Observe. Understand. Design. Implement. Measure. Adapt. None of those words is revolutionary, and that is intentional. The ideas appear across service management, governance, quality management, systems thinking, human-centered design, continuous improvement, and plenty of other disciplines. The Framework is not an attempt to rename familiar work. It is the language I use to describe how I believe that work fits together.

The order matters, especially at the beginning. Seven years ago, we jumped ahead. We started designing before we had really observed, and we confused asking people about the system with observing the system itself. Interviews produced perspective. Documents produced intent. Workshops produced consensus. None of them, alone or together, produced direct evidence of how the work actually moved.

Observation, as I mean it here, is not evaluation. It is not an audit, a maturity assessment, or an expert entering an environment and immediately cataloging everything being done incorrectly. It is deliberately more boring than that. We are gathering evidence: What actually happens? Where does work go? Where does it stop? Where do people leave the documented process? What have they built for themselves? Where has the formal system diverged from the operating system?

At that stage, I do not particularly care whether an adaptation is good or bad. There will be time for that judgment. Some adaptations are clever, necessary, or safer than the official method. Others are inefficient, risky, or genuinely terrible ideas. But judgment changes the question too early. If I begin by asking, “Are you following the process?” I am already comparing reality against an expectation. If I begin with, “Show me what you do,” I have a chance to learn something the expectation cannot tell me.

The moment we encounter something unexpected, the temptation is to correct it. The Foundry Framework asks us to understand it first. Why does this happen? What constraint produced it? What problem does it solve? What would happen if we removed it? That is where the conversation between reality and intention begins. Only then are we ready to design toward an intentional state, implement change into a living system, measure what actually changed, and adapt when reality tells us our beautiful design was wrong.

Start Here

That insurance company did not teach me that ITIL was wrong, that consultants were bad, that executives do not understand their organizations, or that the people doing the work are always right. Those would all be easy lessons, and all of them would be wrong. It taught me something more useful: you can do good work, satisfy the client, deliver exactly what was requested, and still leave enormous value on the table.

We did what we were asked to do. The client was happy. The engagement was profitable. And the result could have been galaxies better. I did not need another framework telling me what good practice looked like. I needed a way to begin before deciding what good should look like here. I needed an approach that treated the organization’s operating reality not as noise to be corrected, but as evidence to be understood.

Today, I have language for that approach: Observe. Understand. Design. Implement. Measure. Adapt. But if I walked into that engagement again tomorrow, I would not begin by explaining the Framework. I would not start with ITIL, the Service Catalog, a maturity model, or a blank Visio canvas. I would pull up a chair beside the people doing the work and ask the question we should have asked at the beginning:

So, what do you actually do?