- An Operations Concept is more detailed than a Concept of Operations
- It is a systems engineering artifact that describes how system use cases are realized
- It is versatile and serves many uses across the project
- There is no set format, though there are some best practices to consider
Concept of Operations (ConOps)
Let start by talking about the OpsCon’s better-known big brother, the ConOps.
A ConOps is a high-level view of the system from the user’s perspective that describes key concepts, capabilities, context, and characteristics for the operation of the system. Its purpose is to communicate the vision of the system to help guide the acquisition and development effort. AcqNotes has a good informational page for ConOps development in military systems, including templates and references.
For military systems, the ConOps is commonly accompanied by an OV-1 High Level Operational Concept Graphic. This provides a visual depiction that serves as a discussion tool. Though the “OV” is an architectural modeling viewpoint, a program does not have to be using an architectural modeling framework to create an OV-1. The DoD CIO DoDAF 2.02 website has a good description of the OV-1.
I searched the Internet to find a good example ConOps to share and found one for the Geospatial Information Interoperability Exploitation – Portable (GIIEP). This is an airborne imagery system previously operated by the Civil Air Patrol (CAP) to support support search and rescue, disaster relief, and homeland defense missions. This particular document describes an existing system rather than a system under development, but the general goal of documenting high-level concepts is the same. It also includes the below OV-1.
There is another, similar document called the Operational Concepts Description (OCD). This is a document that a military customer can request from a contractor using Data Item Description (DID) DI-IPSC-81430A. The OCD can be thought of as the contractor counterpart to the ConOps with details such a support concept, development impact, and summary of advantages. This type of data is developed by the contractor early in the engineering process based on the ConOps, other customer-provided data, and early system architectures. The OCD gives the customer confidence that the contractor understands the acquisition needs and has put thought into concepts beyond operations, such as safety and maintainability.
Operations Concept (OpsCon)
An OpsCon takes the high-level ideas from the ConOps and/or OCD and starts to flesh them out with specifics. This is valuable in several different ways:
- It helps development teams understand how the components they’re developing, interfacing with, or supporting fit in the larger system
- It ensures the contractor and customer are aligned on the interpretation of requirements and provides a useful tool for discussing the capabilities being developed
- It identifies gaps in the architecture or requirements, often due to implied requirements or interfaces
- It helps the user community understand the system functionality and create operations and maintenance plans around it
As an example, the GIIEP ConOps states that there will be software updates, but it has no details on how those updates are published or transferred into the system. An OpsCon would likely provide that type of information. Say that the developer publishes updates via a CD mailed to each CAP unit annually. That implies that the hardware has to include a CD drive, the operating system has to be configured with an account with appropriate privileges, the manual needs instructions for performing this task, and the CAP unit has to have a sustainment plan that includes at least annual scheduled maintenance activity.
This is a single straightforward example. Now consider the several types of users and functions described in the GIIEP ConOps and all of the details that are not defined in the ConOps about how they execute those functions. Then, add in the other lifecycle concepts (training, sustainment, disposal, etc.) that aren’t part of the operational aspects but do need to be defined during system development. You can see that the OpsCon can get very large, very quickly.
For many systems, especially larger ones, the OpsCon is broken up into multiple documents, usually by use case or system function. It is tempting to separate by user role, but this is usually not advised because many functions cross user roles and it is most important to capture the entire flow of activity that accomplishes a given use case. Understanding which user roles are involved in which use case is also important, and this can be captured with a table (you can do the same for any other discrete item that may be involved in multiple flows, such as tools or communication interfaces).
The emphasis of an OpsCon is on interactions among system components, especially the human component. Continuing with the GIIEP software update example, we want to capture the process by which the user will conduct the update, not the technical details about the update function (leave that to the software documentation). We also want to capture non-human interactions, for example if the update function pushes data to multiple sub-components, to capture potential interface impacts, alternative flows, or opportunities for exception/failure.
There is no set format for an OpsCon and you can use whatever format works best, including mixing and matching. Text narratives, step-by-step flows, architecture diagrams, flow charts, and graphics are all commonly used. Supporting data is commonly included as well, such as related requirements or test plans that provide useful context for the functionality being described.
The ultimate goal is to illustrate system use cases, considering all stakeholders and the entire lifecycle of the system. The systems engineering team is typically responsible for developing the OpsCon as part of the left side of the Systems Engineering Vee. In the particular version of the Vee below, the OpsCon is developed after requirements and roughly concurrent with the architecture. It is kept updated as the baseline matures so that it remains useful throughout the project.
In the context of the Vee, you can see how the OpsCon helps to flesh out some of the high-level concepts to support detailed design, implementation, integration, verification, and validation activities. The OpsCon is an extremely versatile document that supports a wide range of systems engineering and development needs. Especially on larger programs, the key value of the OpsCon is to align all of the internal stakeholders on the expected functionality to reduce confusion over what is being built and how it contributes to the larger system whole.
Conclusion
Not all projects have or require an OpsCon, but they are a valuable tool that you should keep in your toolbox. More detailed than a ConOps, this systems engineering artifact describes how system use cases are realized, helping to align understanding across the effort. This supports customer conversations, architecture, detailed design, test planning, training design, sustainment planning, and more. With this introduction, keep an eye out for opportunities to develop and apply OpsCons on your efforts.
Finally, a note about style. There’s no set way to capitalize the words ConOps or OpsCon. I chose the format that looks best to me, but you can style the word many different ways: Opscon, OPSCON, opscon, OpsCon, OpScOn1.
How do you style the word? Have you created or used an OpsCon before? What are some pitfalls to be aware of, tips to keep in mind, or additional ways this artifact can add value? Share your thoughts in the comments!
Footnotes: