The Recovery Nobody Wrote Down

David Nichols – Co-Founder and Executive Director of the DVMS Institute

The Recovery Nobody Wrote Down

What a career-ending project taught me about managing by assurance, long before that was the name for it

I came back from a business trip and walked into my boss’s office. He told me he had a suicide mission for me, or in the common vernacular, a “career-ending opportunity.”

The Field Engineering Division had spent years trying to replace the tangled collection of disparate applications that ran its operations. The project was eighteen months behind schedule. There was no clear path to recovery. The consulting firm running it had delivered one delay after another, and no one above me could confidently say the system would ever ship. With no viable alternative, I took the assignment.

Two decisions

The first decision was the easiest. I fired the consulting firm. I kept their lead consultant, the one person who actually understood how the pieces were supposed to fit together, and built from there.

The second decision was harder. I brought every user lead into a single room and validated the design requirements from the ground up. Departments had spent months, in some cases years, asking for things that directly contradicted what another department needed. Nobody had forced that conflict into the open. I did, and we rationalized every mutually exclusive requirement until only a design the whole division could stand behind remained.

What we built

Then we built it. The system spanned four hardware platforms and three operating systems. We had a working prototype in two months. We went live nine months later.

We called it the Integrated Service Information System, ISIS, before the acronym came to mean something else entirely.

In the first thirty days of operation, we had zero priority-one bugs. ISIS replaced more than fifteen thousand COBOL programs with a single integrated system. In its first month, the division used the new system to identify and recover more than $800,000 in overpayments to distributors, money the old patchwork of applications had never uncovered. The logistics portion of ISIS remained in production for seventeen years before an ERP system upgrade finally replaced it.

The standard nobody named

That was not the first suicide mission I returned from, and it would not be the last. I have often wondered why some of those missions succeeded when the assignment itself all but guaranteed failure. Some of it came down to specific decisions: firing a vendor who could not deliver, forcing hidden conflicts into the open before writing a single line of code, and building a team that could work across four platforms at once.

But beneath those decisions was a standard I held myself to every time, whether or not anyone was checking. Not did you follow the process. Instead: does the system actually work, and can you prove it under conditions designed to make you fail? That standard does not leave you once you learn it. It changes how you manage everything afterward.

I did not have a name for that standard when I was working on the ISIS project. I had a deadline, a fired vendor, and a room full of department heads who needed to stop arguing past each other. What I did not have, and what nobody around me had either, was a way to document what actually worked so the next manager facing a career-ending assignment could start where I left off instead of starting from nothing.

The evidence that ISIS worked existed. Zero priority-one bugs in the first month were evidence. Eight hundred thousand dollars recovered was evidence. Seventeen years in production is about as strong a piece of evidence as a system can produce. None of it was captured as evidence at the time. It became a story I told, not a practice another manager could pick up and run with.

I have watched the same pattern repeat with other managers on other projects since. Someone inherits an assignment nobody expects to succeed. They make the hard calls nobody else was willing to make. The project ships, the numbers come in, and the organization moves on to the next crisis without ever asking how it happened. The manager who pulled it off usually cannot fully explain it either, because the standard they applied was instinct sharpened by pressure, not a practice they could hand to whoever runs the next crisis. Every time that happens, the organization pays for the same lesson twice, once in the crisis itself and again when a different manager has to relearn it from nothing.

Managing by Assurance

That gap between doing the work well and being able to prove it was done well is what Managing by Assurance is built to close. The book takes the standard I was applying on instinct during ISIS and on every difficult assignment before and after, and turns it into four practices any manager can run deliberately rather than discover by accident under pressure.

Setting boundaries was what forcing every contradictory requirement across departments into the open actually was, done as a repeatable practice rather than a one-time act of will. Designing for resilience was what building a team that could operate across four hardware platforms and three operating systems actually was, done on purpose rather than assembled out of necessity. Treating evidence as a byproduct of the work itself would have let the ISIS results speak for themselves at the time, rather than becoming a story that only exists now because I am the one telling it. And decision rights, made clear in advance rather than sorted out during the crisis, let a fired vendor and a rationalized design turn into a working prototype in two months instead of another eighteen months of drift.

None of this required a platform, a new framework, or executive permission to change how the whole organization operated. It required a manager willing to ask whether the system actually works and whether you can prove it, and then to build the habits that make the answer to that question available on demand instead of reconstructed after the fact from memory.

What this looks like starting Monday

A manager does not need a career-ending assignment to start applying this. The same four practices work at ordinary scale, even on ordinary weeks. Setting a boundary can be as simple as writing down, before the next dependency fails, what a degraded but acceptable state looks like, rather than discovering the acceptable threshold during the outage itself. Designing for resilience can be as simple as adding one fallback path to a process that currently has none. Treating evidence as a byproduct of work can be as simple as keeping the decision, the action, and the result of a single hard call, rather than letting them evaporate into a story told secondhand at the next staff meeting. And clarifying decision rights can be as simple as naming, in advance, who is actually authorized to make the call when the usual chain of command is unavailable.

None of these require a career-ending assignment to practice. They only require the decision to practice them before the crisis arrives, rather than during it.

Why this matters more now than it did then

The ISIS project spanned four hardware platforms and three operating systems, considered an unusually tangled environment for its time. A manager facing a comparable assignment today inherits interdependent cloud services, third-party vendors, and AI-enabled processes that no single person on the team fully understands end to end. The complexity has not gone away since ISIS went live. It has compounded. What has not kept pace is the number of managers who have a deliberate practice for proving their system works under pressure, rather than an instinct discovered only once the assignment already looks like a career-ending one. That gap is exactly where Managing by Assurance is aimed.

The book

Governing by Assurance, the first book in this series, made the case to boards and executives that governance needs to change. This book goes straight to the manager who does not have the authority to redesign the whole organization. They only have the authority to redesign how their own team works. Exercised deliberately, that authority is enough.

Managing by Assurance: Turning Intent into Reality is Book Two in the Assurance Now series, co-authored with Rick Lemieux and published by the DVMS Institute. It is written for the manager who runs a team, a service, or a value stream within a larger enterprise, the reader who inherits imperfect governance, lives with dependencies they cannot control, and faces pressure to demonstrate resilience without ever being given a clear model for doing so.

The standard I held myself to on ISIS, whether or not anyone was checking, is the same standard this book asks every manager to hold. This is the standard applied to the work of managing, made into something a reader can practice on purpose rather than discover only once the assignment already looks unsurvivable.

It gives the reader the model. Available now.

Get your copy on Amazon: Amazon.com: Managing by Assurance: Turning Intent into Reality (Assurance Now) eBook : Nichols, David, Lemieux, Rick: Kindle Store

About the Author

Dave is the Executive Director of the DVMS Institute.

Dave spent his “formative years” on US Navy submarines. There, he learned complex systems, functioning in high-performance teams, and what it takes to be an exceptional leader. He took those skills into civilian life and built a successful career leading high-performance teams in software development and information service delivery.

Digital Value Management System® is a registered trademark of the DVMS Institute LLC.

® DVMS Institute 2026 All Rights Reserved