The Assessment Is the Deliverable

You are handed a scope on the first day, and the scope is wrong. Not by a little. Systems nobody mentioned. Dependencies nobody drew. A process that runs on one person’s memory and has for eleven years. I have walked into this more times than I can count, and I want to say the important part immediately, because it is the part that usually goes unsaid: nobody lied to you. They told you what they knew. The problem is that what an organization knows about its own systems and what its systems are actually doing are two different documents, and only one of them is being maintained.

This is not negligence. It is entropy, and it is universal. A map is written once; the territory changes every day. An architecture diagram is accurate the afternoon it is drawn. Then someone makes an urgent fix on a Friday, and a vendor changes an integration, and a person who understood one critical thing takes a job somewhere else, and none of it gets written down — because writing it down was never the emergency. Multiply that by a decade and the result is not an organization that did something wrong. It is an ordinary organization that can no longer see itself.

Which is why the first deliverable is never the rebuild.

The assessment is the deliverable. Before a roadmap, before a budget ask, before a single migration — an honest inventory of what is actually there, what depends on what, where the knowledge lives, and what it will genuinely cost to bring it to enterprise grade. Not the flattering version. Not the version that fits the number someone already put in the plan. The real one. Every hour spent building that picture is bought back several times over during execution, because it is the only thing that lets you sequence work in an order that does not collapse under you.

It also asks something of leadership that is easy to underestimate. An honest assessment makes visible what was previously convenient to leave unmeasured, and it will occasionally embarrass a decision someone still owns. The organizations that come out of this well are the ones whose leaders can hear the number without hearing an accusation — and my job, done properly, is to make that as easy as possible: no blame, no theater, just the environment as it is, and what happens next. The point of looking is not to determine who is at fault. It is to make it possible to move.

Then the discipline takes over, in order. Document it, so the knowledge lives in the system rather than in a person. Plan it, so the sequence survives contact with reality. Execute it, and keep the documentation current as you go rather than promising to write it afterward, which no one has ever done. This is unglamorous and it is the whole job. When I established the CIO function at a North American multi-plant food manufacturer and rebuilt the enterprise systems environment in forty-six days following an international cyberattack, the compression did not change the method. It only removed the option of skipping any part of it.

What makes this work rare is not technical. Plenty of people can architect a modern environment. Far fewer are willing to spend the first weeks producing a document that makes everyone uncomfortable and impresses no one — when the incentive is to look decisive, name a plan, and start moving. But a plan built on the map instead of the territory is not a plan. It is a forecast of a rebuild you will have to do twice.

So when I say design it right, secure it, and sign your name to it, there is a step that comes before all three, and it is the one that earns them: see it right. Look at what is actually running. Write it down. Only then are you designing anything at all — and only then is there something worth putting your name on.

— Keith Formell