What is a Concept of Operations Document?

The Concept of Operations document (CONOPs) describes how the system is envisioned to work from different stakeholder viewpoints, such as end-users, operators, maintenance, and customers.

The Concept of Operations document is one of the first documents to be written in the Software Development Lifecycle.

Where is it in the Software Development Lifecycle?

This is written up during the Planning Phase of the Software Development Lifecycle (SDLC).

Once it is written up, it feeds into the Functional Requirements, Software Requirements Specifications and, by extension, the Design Document.

Why write a Concept of Operations document?

Let’s say your company has a problem.

You have 10 departments scattered across the country all using different systems, different email products, different interfaces and other such horrors. It’s a mess.

You need to streamline all of these to make the obvious cost-savings and allow your company to work more productively. Makes sense?

Before you start any kind of coding, you need to do explore what it is that users will actually need and while not down to the interface level but the general high-level requirements they have.

For example, they need access to email from remote locations.

How you do this is another question but the requirement is – remote email access!

This is a very simple example but you get the idea.

What’s next?

The next thing to do is get permission to prepare a Concept of Operations document.

This will do three things:

Current System – describe the current system and why it cannot fulfill the users’ needs, i.e. its limits and constraints

Proposed System – describe the proposed system and how it will implemented and operated etc. in other words, how it will overcome the current and constraints

Justification - describe why your company needs to adopt a new system (urgently!) and the benefits it stands to gain, e.g. better customer service, quality, data quality, process improvement, rationalization etc.

How much detail should I provide?

The level of detail you provide will be determined by the respective project. There is no hard and fast rule.

Provide enough information so that the decision makers can make an informed decision, i.e. to fund the project or re-assess the situation.

What should I focus on?

Describe how/where it will be used, users’ roles and responsibilities, the personnel involved in its implementation and operation and the high-level user needs.

What's the benefit to Project Stakeholders?

Developing the concept of operations document ensures that all stakeholders agree on a common view of the proposed system.

It can also be used as a reference point for new team members, including new employees and contractors brought in to help with the system implementation, operation, or maintenance.

How to capture user’s requirements?

Develop use cases that illustrate the most common scenarios/processes that users will perform.

Use cases can be high-level or dig a little deeper if required.

You can also develop an Excel or Word checklist and capture requirements this way.

Write them in plain English and avoid jargon. Make sure that the stakeholders can read and understand the users’ needs and check that they are reasonable and comprehensive.

What happens next?

These requirements (i.e. needs) are used to define system requirements that will determine how the system is designed.

This information will also be used to work out technical support contracts and Service Level Agreements (SLAs).

Read more:

1. How to write the Concept Operations Document

2. What it a Concept Operations Document?

3. How to Define the Goals, Objectives and Rationale

4. What you need to put into a Concept Operations Document

5. How to Justify the New System to Project Stakeholders

6. How to develop Use Cases to capture Work Scenarios

7. What's the Connection Between the Concept of Operations and Functional Requirements Document