Quick Guide to a Concept of Operations (CONOPS)

Government agencies and IT companies have to keep up with the ever-evolving world of technology.  Therefore, they have to think about technical systems for present and future issues.  This is where the Concept of Operations (ConOps) document comes in.

What is a ConOps Document?

ConOps is a useful technical document that can aid you in envisioning the perfect system to tackle a current issue that you are trying to solve. It is also a good prerequisite before thinking about requirements, writing a request for proposal (RFP), or proposing a solution. Here are the main sections that a basic ConOps usually has:

Introduction, Including System Overview

As with anything, a ConOps has an introduction. This is where you state your objective, scope, and document organization. Another key area is the system overview. You can think of this as the executive summary of a document where you highlight what the envisioned system will do. In another section, you will go into more detail (of course) on the system and its components.

Current System (and/or Issue)

Before you can discuss the proposed system, you have to give stakeholders a bit of history of the issue you are trying to solve. The background and history of the current issue is very important because you want to show stakeholders that you fully understand how the issue evolved.  It will also help you in designing a better system.

If there is already a current system in place, then you want to discuss that as well. You want to detail everything about the current system and/or issue.  This includes system architecture, policies, constraints, and users.  I will discuss a little bit more about the users because it’s very important that you get it right.

Users are always the most important part of a system because they are the ones who will be using it on a daily basis. Therefore, you have to characterize the user groups that are currently using the system.  If you don’t know this, then you have to do more research.

When you are writing about the current system, you want to ensure that you get everything down from your interviews with Subject-Matter Experts (SMEs), users, and stakeholders. If you don’t fully understand what is currently going on, how can you find the proper solution? Therefore, take your time in gathering everything you can about the current system.

Justification for Changes

This section is the bridge between the current system (or issue) and the future one.  Think of it as a mini proposal section where you justify why a change has to occur. It should only be a few paragraphs where you kind of sell the future system to stakeholders and yourself.

Future System

You have done your research, and now it’s time to discuss how to solve the issue. You want to really take a week or longer to really come up with a solution that will be better than what is currently in place. This section is like a mini-document in itself. You want to start off by giving a high-level overview of what future system. Please make sure that you use “will” and not “shall.” The latter is requirements talk.

You also want to discuss the policies and constraints that the future system will have. You want to ensure stakeholders that it will adhere to any current and near-future policies that are in place. Also, that it is interoperable with other systems. Government agencies have realized the importance of systems to talk to one another, so if you can show that your future system can do that, then stakeholders will be almost sold. Other areas to cover are the future system’s components, data flow, support, training, and user groups.

The impact that the future system will have to the users, everyday operations, and other systems is the best way to conclude the ConOps. You want to reassure stakeholders that you have thought about this, and you will ensure that everything is smooth sailing, or as near to that as possible.

Conclusion

ConOps can really prepare your team in developing a sound and innovative system. If you have the time to write one, or find someone who can make the time, then I suggest you have this document as a must-have in your system development life cycle.