Communicating concepts of operations

If you don’t capture and validate key concepts meaningfully, you’ll end up managing chaos instead of operations as a logical consequence

Concepts are powerful symbols of meaning we use in communications. They allow us to organize our knowledge and understanding within a particular context and provide a framework for us to structure the actors and objects which are involved in delivering value through a set of interactions over time. Concepts help us to integrate individual observations and phenomena into viable hypotheses and theories about the world. As we use them to communicate these theories, readers can then validate aspects of a system with their own beliefs and understandings and assess the potential value of changes which are proposed, under consideration, or available for their usage.

Purpose

A Concepts of Operations artifact (aka "ConOps") should provide a useful overall depiction of needed capabilities using compelling visual representations. The information should provide a user-centric bridge from the operational goals and objectives of the system of interest to an operational view of how the system will be used within the environments targeted for deployment.

The narrative developed in the ConOps should limit the problem space for defined audiences over distinct time periods. It should document the sponsor and customer assumptions and intentions with respect to each operation or series of operations, especially when a series of connected operations must be carried out simultaneously or in succession. The resulting narrative perspective weaves the associated concepts for a system into a story about how the anticipated physical and technical capabilities of the system will be used to provide selected capabilities, such as resource or information aggregation, computation, synthesis, navigation, production, distribution, or monitoring over time.

A ConOps should provide powerful graphics that reinforce a written narrative that describes a 'big picture' perspective to the designers of the system. Its depiction should amplify and clarify the purpose of the endeavor. This perspective (often composed of multiple viewpoints) should help explain how a proposed solution is expected to work 'holistically' once it enters service. The interactions between solution elements should be collectively introduced in a way that captures the voice of the customers and emphasizes how the delivered capability will enable the harvesting of value by its stakeholders. Use case diagrams can supplement a ConOps further and frame the problem at a lower level but should not be necessary to characterize the essential attributes of the proposed solutions.

Expected Outcomes

A ConOps puts these interactions into a meaningful framework by describing:

• What outcomes are intended from using the system?

• What novel concepts are crucial to understanding how the system will be used to realize these outcomes?

• How will these concepts be utilized throughout the system's lifecycle?

What resources will users need to operate and maintain the system?

Content description

The following outline provides a suggested template for effectively communicating such information. Content described will vary depending upon whether for a new system of interest that is being developed from scratch, when a major upgrade to an existing system is to be performed, or whether the system is intended to replace an existing system.

• Current System or Situation

• Background, Objectives, and Scope

• Assumptions and constraints

• Operational policies and constraints

• Description of the current system or situation

• Stakeholders and personnel affected by change

• Justification for and nature of changes

  • Reason changes are necessary

  • Description of needed changes

  • Priorities of changes

  • Changes considered but not included

• Description new and changed system elements

  • Block diagram

  • Description of critical functions

  • Description of primary interfaces

  • Key timeline and interactions

  • Measures of effectiveness

  • Operational scenarios & modes

    • Initialization

    • Operations

    • Support

    • Modification

    • Service restoration after failures

• Summary of capabilities provided

  • System execution

  • Data management

  • Operations management

  • Systems management

• Analysis of the proposed system

  • Summary of benefits

  • Summary of limitations

  • Summary of alternatives and tradeoffs considered

Planned capabilities need to be oriented within the missions of each affected organization, with particular focus on:

• A delineation of the areas of responsibility, especially at the boundaries

• A timeline which details time budgets for activities

• A description of how progress will be tracked with respect to performance targets

• the resources allocated to perform each aspect of this mission

• how these resources scale under different scenarios, especially:

  • Innovation: the ability to introduce new materials, technologies, and methods, as well as to enhance traditional work in new ways

  • Robustness: the ability to maintain effectiveness across a range of tasks, situations, and conditions, including pivots in the face of unusual (and potentially unanticipated) states. These should include:

    • Resiliency: the ability to recover from or adjust to misfortune, damage, or a destabilizing perturbation in the environment

    • Responsiveness: the ability to react to changes to the environment in a timely manner

Flexibility should be provided to enable actors to employ multiple pathways to success and the capacity to move seamlessly between them. This contingent flexibility should include the following:

• The ability to make sense of the situation in which their role is to be performed

• The means for coordination with other actors, to enable them to work to together efficiently within the operational environment

• Knowledge, skills, and experience sufficient to recognize and respond to each situation

• The ability to select and execute a sequence of steps that will achieve the intended outcomes

While this information does not all need to be covered within the CONOPs artifact itself, it will enable the organizations involved to evaluate the clarity of the CONOPS, and its readiness to guide the subsequent efforts transforming the CONOPS information into a working system.

Summary

This ConOps information will be useful regardless of the domain or disciplines which will be involved in its implementation. If more projects used a ConOps approach, their probability of success will be increased, since the follow-on requirements elicitation process will have a better focus, allow clear delineation of responsibilities, and will be reinforced by a description of what “done” looks like. It is also particularly useful in onboarding new personnel to the endeavor.

For more information about using a CONOPS, see MITRE's guidance on this subject.