How to make a CONOPS
CONOPS = Concept of Operations
In the systems design world a Concept of Operations (CONOPS or ConOps) is a tool for taking a big ambiguous challenge and uncovering just the next layer of the story. We’re peeling back just one more layer for more information.
It is intended to provide readers with better context, some clarity as to how it is imagined, and the operational flow the system will go through. It is not supposed to describe all Requirements and Use Cases, but a jumping point for uncovering those.
In the Aerospace and Defense world a CONOPS is a familiar term and process, but in other industries; consumer goods, software services, and Medical Devices, it is usually unfamiliar territory.
Some available definitions;
“A document describing the characteristics of a system from the viewpoint of an individual who will use the system.” - Wikipedia
“A document that describes a series of actions taken in pursuit of mission accomplishment.” - Department of Homeland Security
“A CONOPs describes the mission of the system and its operational support environments” - IEEE Guide for Information Technology
Each of these definitions give of the impression this is a very Aerospace-y, Militant, Government vibe. Which rightfully so, those are the organizations that have developed and pioneered this practice. That said, I think it is a valuable tool and process that can be brought down and broaden to be more applicable on a variety of programs.
My definition;
“A document that provides high level context of a system, it’s expected use, and environments throughout each of its life cycles.”
I like to think of a CONOPS like a comic book story; it provides a reader with key snapshot images of the product as it move throughout its life. It will show who, when, what, and where without trying to depict every single detail.
Example System
I’ll outline with an example system we will reference back to throughout.
Augmented and Virtual Reality are hot topics these days, so let’s imagine your team is responsible for developing a pair of glasses that support Augment Reality applications. The product is intended to have the following capabilities;
Overlay visual graphics onto the lens of the glasses at a 60Hz frame rate and high resolution
Have a battery life of at least 10 hours
Support wired charging
Wirelessly pair and connect to a personal smart phone, OS agnostic
To add to that the business needs a few things from the product as well;
The product needs to support a subscription service model for reoccurring revenue
The product needs to be lightweight and visually appealing to users
The product needs to be provisioned for future product integrations (i.e. integrate with future products like headphones or a laptop)
The company has decided to name this product ecosystem: Projected. We’ll reference back to this name throughout.
Where to Start
Get all the elements out there. Think through the product and try to imagine all of the different distinct parts of the system.
It’s okay if you are missing a few pieces at this level, as you begin to construct the CONOPS you’ll start to uncover the unknown quantities.
Using little icons or images is usually not a bad idea at this level. Personally, I think it provides a nice visual for readers and begins to bring reality to the story of the product, but its definitely not necessary.
Interfaces
In a previous post, What is a System?, I describe what makes a System a System, and the most essential piece to that definition is Interfaces. Without interactions, without different elements interfacing together, our system isn’t very interesting.
This type of diagram is sometimes referred to as a System Context diagram. As the name implies, it quickly provides context of a particular system. This isn’t intended to be the CONOPS, but rather to provide a starting point for how the CONOPS will flow. When constructing the CONOPS document, a diagram like this is great to provide early on in the front matter to give readers context. When verbally describing your system this visual can go a long way.
Notice I’ve begun to layout interfaces but at this point I am not able to be prescriptive in what type of interface will be supported. This may or may not be the case on your program. Perhaps it is known we will leverage BLE for interfacing with the Cellphone because we use that technology on other programs, great we can put that in, but we don’t have to. Unless there are absolutes, like the BLE example, then I would recommend keeping a looser framework until the team is able to lock down design decisions. The intent is to provide a rough idea, not create requirements for a design.
Product Life-cycles
I think a super helpful framework for thinking about a product is creating distinct life-cycles for the product. Stages of the products life that it will move through. For our example product that might be Development, Distribution, Operation, Maintenance, etc. For a space program it might depict the sequence of operations for a satellite launch.
But this might be one of several depictions that describe the life of this satellite. For a program like this with thousands of pieces and interfaces, this is the level of detail that is appropriate for the audience.
The key is that it’s up to you to create that complete story. For simpler systems, products like our example, the same idea applies just with a different perspective. I generally gravitate towards life-cycles like the ones outlined below.
A very large image with small font is a perfect way to look like you doing something valuable without actually doing something. Let’s double-click on a few of the life-cycles here.
You might not immediately assume it, but we have way more interfaces in the Production and Distribution phases when compared to the Operational phase. Interfaces like connecting to a manufacturing network and product packaging are not immediately obvious, but by constructing something like this it enables the team to see the bigger picture. To understand the more nuanced pieces of the product and to zoom out beyond just the thinking about the everyday user.
Hopefully you can begin to see how this tool can feed into System Architecture development and Use Case definition, bringing to light the not so obvious needs.
These two life-cycles are typically where our attention goes and lives. Rightfully so, these are very critical to being able to have a successful product. There is something beautiful and satisfying about having such simple interfaces for the Operational, not to imply that this always the case or that it will stay that way. But ideally it’s supposed to be easy for users, right?
The Service life-cycles becomes an interesting one depending on what scope your business will support. For example here, we’ve decided that we will take on some kind of product refurbishment, maybe in the form of replacing lens or batteries. In addition, it becomes clear just how essential have a cellphone as a connected device for the product to continue to operate.
For each of these elements (boxes) we can provide more specific definition as we know more. Power Supply may include power supply requirements for US, Australia, EU, and Japan. Each of which will have some of their own uniqueness. This can be especially useful when thinking about the environment element. A lovely example of this is the Samsung Galaxy 7 and Note 7 catching fire on planes, effectively leading to a ban by TSA. Samsung did a great job designing the product, but by not considering all of the potential Operational environment conditions, they failed to design a product that can withstand what the user needs.
Last but not least, the Retirement cycle. A life-cycle that is many times forgotten, but has become much more essential for consideration over the recent years. More and more governing bodies are requiring electronic devices to support some form recycling as a push to improve the waste conditions around the globe. California just enacted SB 1215, which will required electronic devices to have a removable battery.
Taking a Step Back
We’ve identified who will be interfacing with the product as it moves through it life-cycles. This can give you insight into a particular stakeholder needs that may not be so obvious. It may also uncover some unknown constraints of different stakeholders. For example, service personnel may be limited in what information they can access during troubleshooting.
Where the product exist; different environments, their conditions, and constraints the product might encounter. This is such an important piece of developing a functional product. Understanding what environmental elements the product will be exposed to will drive Requirements, design decisions, and constraints.
Something I omitted, but can be seen in the NASA example, is highlighting a few key pieces of functionality for each life-cycle. For example in Production, maybe we need to perform a functional RF test every 50 units. This is really important to know sooner rather than later. This will draw out you’re most essential functions so review know what the product needs to support.
Critical interfaces have been clearly laid out. This should lay the framework for teams in building out more detailed system architectures and interface definition. You can also highlight the most critical interfaces and which pose the highest risk if they were to be wrong or go down. I didn’t include it here, but you could identify future interfaces, such as a desktop app or headphones like in our example.
Ultimately we have started to uncover requirements for the product and intend to lead to a better design in the end. We’ve brought to light life-cycles, stakeholders, and interfaces that are not as obvious, but essential to success.
Risky Business
Discussions on Risk Management are long, and will not be included here, but I will touch on one thing quickly in regards to Risk as it relates to a CONOPS. As we are developing this story we are going to begin to uncover unknowns.
In my mind, in the Product Development world Risks come in two different flavors, Project Risk and Product Risk.
Project Risk - A risk to the success of the program. This could be to resource constraints, technical unknowns or readiness, long lead times, or external forces such as suppliers.
Product Risk - A risk of harm or hazard to a user, a patient, or any other stakeholder that would be interfacing with the system.
A CONOPS is likely going to focus on discovering Project Risk. It should uncover questions about the product as it moves through life-cycles, and point to areas where the team lacks complete understanding. It doesn’t mean the exercise can’t discover Product Risk, but chances are since the description is high level it won’t uncover lots of meaningful information in regards to Product Risk.
Take the questions, the unknowns, and the TBD’s and push those into your project risk management tool to track, plan, and mitigate.
ASS (out of) U (and) ME
After you have gone through the process of painstakingly constructing and reviewing the depiction with your team, you’ve now created a super helpful tool to review with stakeholders not so close to the problem. Upper management, other product teams, external customers, business partners, and so on. The CONOPS can serve as a one stop shop to quickly understand the product, its story, and how it fits into the bigger picture of the world.
When reviewing with key stakeholders like management and other product teams, it will be a great time to get buy-in on key assumptions. You will likely uncover some points in the product where expectations aren’t completely aligned. This is a perfect time and tool to begin to set the story straight, ask questions, and to make plans to resolve unknowns.
For example on Projected, perhaps there is another team responsible for developing a Desktop app that will allow our product to integrate into PC’s. That team will be making some assumptions about communication interfaces and user interfaces that need to be agreed upon in order for the project to have success.
The Highlights
You’re laying out a story from beginning to end of the product.
This is a tool to review internally and externally, gaining alignment on interfaces, functions, environments, and questions.
You’ve identified key stakeholders who will be required to interface with the product; more than just the user and engineers.
Requirements have been identified, or at the very least areas where requirements are needed, and ideally ones that were not so obvious at the outset of the effort.
Ideally you’ve captured additional programmatic risks that can be tracked and mitigated, leading to a higher probability of success.
This can act as a jumping off point for use case development as the team further explores a new product.