A Concept of Operations (CONOPS) is a verbal or graphic statement of a commander’s assumptions or intent in regard to an operation or series of operations as defined by Joint Publication 1-02 “DoD Dictionary of Military and Associated Terms”.  The CONOPS is developed by the user community to communicate the vision for the operational system to the acquisition and developer community.  A CONOPS can also be written by the buyer, developer, or acquirer to communicate their understanding of the user needs and how a system will fulfill them. The main purpose of the CONOPS is to facilitate a common understanding of a future system to help in the development of requirements. It’s designed to give an overall picture of an operation.

 

Template: Concept of Operations (CONOPS)

 

In Acquisitions, a CONOPS is used to examine current and new and/or proposed capabilities required to solve a current or emerging problem.  It describes how a system will be used from the viewpoints of its various stakeholders. It should contain a conceptual view of the system (i.e., a preliminary functional flow block diagram or operational architecture) that illustrates the top-level functional threads in the proposed system or situation. This provides a bridge between the often vague capabilities that a project begins with and the specific technical requirements needed to make it successful.  

 

A CONOPS should define any critical, top-level, performance requirements or objectives stated either qualitatively or quantitatively (including system rationale for these objectives).  It is a useful tool that helps the user community write/refine their Initial Capabilities Documents (ICD), System Requirements Document (SRD), and Capabilities Development Documents (CDD).

 

REGULATORY:  Component approved acquisition document that is derived from and consistent with the validated/approved capability requirements document. Will be provided to the Milestone Decision Authority (MDA) at the specified decision events and normally provided to industry as part of the Request for Proposal (RFP). [2]

 

There are several reasons for developing a Concept of Operations:

  • Get stakeholder agreement identifying how the system is to be operated, who is responsible for what, what the lines of communication;
  • Define the high-level system concept and justify that it is superior to the other alternatives;
  • Define the environment in which the system will operate;
  • Derive high-level requirements in the ICD and CDD;
  • Provide the criteria to be used for validation of the completed system

 

A CONOPS should include all the factors needed to define the objectives of the system utilizing DOTLMPF-P Analysis (doctrine, organization, training, leadership, materiel, personnel, facilities, and resources).  It is critical that the CONOPS provide enough information to help with future activities such as sustainment, training, fielding, support, and even disposal. 

 

Main CONOPS Components [3]
According to IEEE Standard 1362-1998, the main components should always include:  

  • The existing system (manual or automated) the user wants to replace.
  • Justification for a new or modified system (including restrictions on that system).
  • A description of the proposed system.
  • Scenarios highlighting the use of the system in the user’s environment including internal and external factor

 

A CONOPS can be developed in many different ways but usually share the same properties. In general, it will include the following:

  • Statement of the goals and objectives of the system
  • Strategies, tactics, policies, and constraints affecting the system
  • Organizations, activities, and interactions among participants and stakeholders
  • A clear statement of responsibilities and authorities delegated
  • Specific operational processes for fielding the system
  • Processes for initiating, developing, maintaining, and retiring the system

Checklist: Critical Information

  • Is the reason for developing the system clearly stated?
  • Are all the stakeholders identified and their anticipated roles described?
  • Are alternative operational approaches described and the selected approach justified?
  • Is the external environment described?
    • Does it include required interfaces to existing systems?
  • Is the support environment described?
    • Does it include maintenance?
  • Is the operational environment described?

 

CONOPS Development Best Practices

  • Use tools and/or techniques that best describe the proposed system from the user’s perspective and how it should operate.
  • Describe the system simply and clearly so that all intended readers can fully understand it.
  • Write the CONOPS in the user’s language. Avoid technical jargon. If user jargon is employed, provide a glossary that translates it for non-users.
  • Use graphics and pictorial tools as much as possible, since a CONOPS should be understandable to different types of stakeholders. (Useful graphical tools include, but are not limited to, node-to-node charts, use cases, sequence or activity charts, functional flow block diagrams, structure charts, allocation charts, data flow diagrams, object diagrams, storyboards, and entity-relationship diagrams.)
  • Describe the operational environment in detail to give the readers an understanding of the assumptions, constraints, numbers, versions, capacity, etc., of the operational capability to be used.
  • Describe those aspects of the physical environment, safety, security, and privacy that exert influence on the operation or operational environment of the proposed system.
  • Include voluminous descriptions, such as a data dictionary, in an appendix, or incorporate them by reference.

 

AcqTips:

  • The CONOPS is also called a commander’s concept

AcqLinks and Resources:

Updated: 4/19/2021

Print Friendly, PDF & Email
Ezoicreport this ad