How I like to do operationalization documentation

What is a CONOPS (Concept of Operations)?

TLDR: Back of a napkin system plan.

A document, that proposes the characteristics and attributes of a system required to solve a current or emerging problem. It describes in carefully abstract terms the qualities or high level logical mechanisms, attributes, of a system. And it also describes at a high level the distinguishing features and capabilities, characteristics, of a system. Together these details when laid out at a high level provide an overall view of a system in a way that can be understood as how a system is supposed to look and behave. The high level reference framing of the document is important and it should avoid adding specific details of existing systems even if such existing systems perfectly demonstrate the characteristics and attributes desired. This is important to maintaining the flexibility of the CONOPS to be adapted to any components or systems of components to achieve the end goals of solving the existing or emerging problem.

The document is a living document, meant to help guide in the decision making of solving problems systematically. Since problems are rarely static for long the document should be updated regularly as needed to encompass a changing problem landscape.

What is a SOP (standard operating procedure)?

TLDR: Actual business implementation plan, derived from the napkins.

A business process and procedure document for the operation of a system in a standardized way (differentiating from the textbook definition of SOP is important for this document framework). The SOP is intended to provide consistent execution so that performance can be predictable and knowledge of how to use a system can be shared and avoid the problems associated with personnel and tribalknowledge silos in an organization. The SOP should be derived from the CONOPS, where the system described receives complete and practical implementation details.

To align with existing documentation and distinguishing from common SOPs we place a limit on what SOPs cover at the step by step technical instructions common in many SOPs. The SOP can and should have a reasonable quantity of such step by step instructions, but as a higher level set of templates that guide the creation of the detailed run books. This allows us to focus on a middle ground of refinement from the CONOPS to SOPs, where we will cover details of human, monetary, time, data, and physical components of a system.

The SOP describes the team required to run and manage a system, what they need to do so and how they generally run the day to day operations of a system. The human operators and managers of a system are outlined with their required skill levels and estimated involvement in the operations of a system. The specifications of the systems physical or virtual components are detailed to a level fine grained enough to drive purchasing decisions. Even generic system metrics are described in a way that can be used to measure the effectiveness of implementation.

Run Books

TLDR: Step by step guides, written by actual engineers and operators.

These documents are step by step guides to using specific systems to solve problems. They are identical to "play books" as a document concept. In general the run books should be regularly tested and refreshed to match changing or aging systems. Run books should cover day to day operations of the system, common problems and break fixes for the system, and disaster recovery/incident response for the system. One requirement of the creation of run books is the skills necessary to perform each run book should be tied back to the skill requirements of the SOP which the run book falls under, if there are gaps the SOP should be updated to cover the existing run books. Likewise when the operation of a system finds flaws with the abstract reasoning of the CONOPS the CONOPS is what must be updated to accommodate the run books.

Sounds like a lot of work. Why?

It shouldn't be much more work than you do today to document a system, just a bit more organization around how you document so that strategy flows cleanly into tactics.

Good business execution and good engineering is built on solid ideas that need to be communicated across an organization to succeed repeatedly. This is just a framework to capture those ideas in different reference frames to achieve your goals. The system is designed to be flexible with strong feedback loops to bake in adaptability. It most importantly is not a system for creating hard rules to follow, but a system for sharing knowledge and building consistent execution.