What Is a ConOps Document and When Do IT Projects Need One?

In this article:

Share the раgе:

A ConOps, or concept of operations, is a document that describes how a system will be used by the people who operate it, in their language, before the requirements are written. It comes from systems engineering, where it is standard, and most IT projects have never produced one. A few of them badly need to. The signals are specific: the people who will operate the system are not the people sponsoring it, more than one organization has to operate it together, it has to run when things go wrong, or it replaces a way of working nobody has written down. This guide explains what a ConOps contains, how it differs from a business requirements document and a use case, when an IT project needs one, and how to write one that stays under thirty pages.

Introduction

The dispatch system went live on a Monday. By Wednesday the night shift had printed the old paper log sheets and was running both, because the new screens assumed a dispatcher handled one incident at a time and the night shift handled six. Nobody on the project had asked what a night shift looked like. The requirements were complete. They described a system. They did not describe an operation.

That gap has a document designed to fill it. It is fifty years old, it is standard in aerospace, defence, and utilities, and almost nobody building enterprise IT has heard of it.

What is a ConOps document?

A ConOps, short for concept of operations, is a document that describes a proposed system from the point of view of the people who will operate it: what they do today, what will change, how the new system fits into their working day, and what happens when it does not work. It is written before the requirements, in the operators' vocabulary rather than the engineers', and it exists so that everyone involved agrees on what the operation is before anyone specifies what the system does.

The term comes from systems engineering. The international requirements engineering standard, ISO/IEC/IEEE 29148, treats the concept of operations as one of the foundational documents of a system life cycle, and an earlier IEEE guide, IEEE 1362, was written specifically about how to prepare one. The practice is routine on programmes where the system will be operated by trained people under conditions that matter: air traffic, power distribution, emergency response, military logistics, transit control.

Three properties define it and distinguish it from every other requirements artifact:

It is written from the operator's chair. Not the sponsor's, not the architect's. The question it answers is "what will my shift look like," not "what will the system do."
It covers the whole operation, including the parts the system does not touch. The paper log, the phone call to the other agency, the handover at shift change, the thing the supervisor does when the screen goes blank. The system is one element in an operation, and the ConOps describes the operation.
It includes what goes wrong. Degraded modes, failover, manual fallback, the night with six incidents. Requirements documents describe the system working. The ConOps describes the operation continuing when the system is not.

Key Takeaway: A ConOps describes an operation, in the operators' words, including the parts where the system is not working. Requirements describe a system.

Building a system for people who were not in the room when it was scoped? Our Discovery & Strategy practice writes the concept of operations before the requirements. Book a free consultation.

What does a ConOps document contain?

Eight parts, described here in our own words rather than the standard's. The order matters, because each part is written from the one before it.

Part	What it answers	Who supplies it
Current operation	How the work is done today, by whom, with what, including the workarounds	Operators and supervisors, observed rather than interviewed
Reason for change	What is wrong with the current operation, stated as consequences, not as missing features	Operators for the symptoms, sponsor for the cost
Proposed operation	How the work will be done after the change, in the same terms as the current operation	Business analyst with operators, validated by the sponsor
Roles and responsibilities	Who does what in the proposed operation, including who decides when the system cannot	Operations management
Operational scenarios	A normal day, a busy day, a bad day, a shift change, and a system outage, each walked end to end	Operators, in narrative form
Operational environment	Where and under what conditions the work happens: locations, hours, connectivity, equipment, noise, gloves	Observed on site
Impacts	What changes for each role, for other organizations, and during the transition itself	Business analyst, reviewed by each affected group
Constraints and assumptions	What cannot change, what is being assumed, and what is unknown	Everyone, recorded as they surface

The scenarios row is where the document earns its cost. A requirements document might have a hundred requirements and satisfy every one while failing the night shift, because no requirement said "six incidents at once." A scenario that walks the busy night, minute by minute, from the dispatcher's chair, produces that requirement before anyone builds the single-incident screen.

The environment row is the one most often skipped, and the one that produces the most expensive surprises. Gloves, glare, a warehouse with no signal, a control room where two people share one screen. None of it is in the CRM the sponsor demoed.

Most IT teams write the proposed operation as a list of features and skip the current operation entirely, because the current operation is assumed to be known. It is not known; it is done, by people who have stopped noticing what they do. ID Business Analysis Canada writes the concept of operations as the first deliverable of a Discovery Sprint on any system with a distinct operator group, with a business analyst observing two or three shifts before writing the current operation, drafting the scenarios with the operators who will live them, and delivering a document the sponsor, the operators, and the build team have all signed as the shared description of what is being built.

Key Takeaway: Eight parts, written in order, with scenarios carrying the weight. Observe the current operation; do not interview it.

How is a ConOps different from a BRD, a use case, or a user story?

It sits above all three and describes what they describe pieces of.

Four-layer diagram showing the ConOps above the business requirements document, use cases, and user stories it is derived into.

A business requirements document states what the organization needs from a solution and why: the objectives, the scope, the high-level capabilities, the business rules. It is written from the sponsor's chair. It rarely says what a shift looks like.
A use case describes one actor achieving one goal through the system, including the paths that fail. It is precise about the system's behaviour for that interaction. It does not say what the actor was doing before or after, or what else was happening at the time.
A user story is a use case in smaller units, prioritized for delivery. It is the right size for a sprint and the wrong size for understanding an operation.

The ConOps is the document those three are derived from on a project that has one. The scenarios in the ConOps become the use cases. The roles become the actors. The reason for change becomes the objectives in the BRD. The environment and constraints become the non-functional requirements that nobody otherwise thinks to write until the tablet does not work in the rain.

On a project without a ConOps, those derivations happen anyway, from the sponsor's understanding of the operation, which is usually five years and two reorganizations out of date. The technical business analyst post on this site described the specification gap between business intent and build. The ConOps is the document that closes the gap one level up, between the operation and the business intent.

Key Takeaway: The ConOps is the source the BRD, the use cases, and the stories are derived from. Without it, they are derived from the sponsor's memory of the operation.

When does an IT project need a ConOps?

When any of four conditions holds. When none does, the ConOps is overhead, and a BRD with good use cases is enough.

The operators are not the sponsors. The system is being commissioned by people who will not use it, for people who were not consulted. Dispatch, field service, warehouse, contact centre, clinical, frontline anything. The larger the distance between the sponsor's office and the operator's chair, the more the ConOps is worth.
More than one organization operates it. Shared services, inter-agency systems, anything where a handoff crosses an organizational boundary. Each organization has its own current operation and its own assumptions about the other's. The ConOps is the only document that describes the joint operation from both sides.
It has to work when things go wrong. Round-the-clock operations, safety-relevant systems, anything with a degraded mode. If the honest answer to "what happens when it goes down at 3 a.m." is a shrug, the ConOps is where the answer gets written.
It replaces a way of working that nobody has written down. Long-running manual or legacy operations where the knowledge is in people's heads and the workarounds are the process. The current operation section of the ConOps is often the first time that process has been documented.

Government IT programmes frequently hit all four at once: a central sponsor, frontline operators in another department, partner agencies, statutory continuity obligations, and a legacy process that predates everyone in the room. That is why the practice is more common in the public sector and in engineering-led industries, and why it is worth importing into any enterprise project that looks like one.

Key Takeaway: Operators who are not sponsors, multi-organization operation, degraded modes, or an undocumented way of working. One is enough. None means skip it.

How do you write a ConOps that stays short?

Scenarios first, observation before interviews, and a hard page limit.

Start with the scenarios. Write the normal day, the busy day, the bad day, the shift change, and the outage, as narratives, with the operators. Most of the other seven sections fall out of the scenarios once they exist. Starting with the current-operation section produces a process manual; starting with scenarios produces a ConOps.
Observe before you interview. Two or three shifts on site, taking notes, before asking anyone how the work is done. People describe the process as it was designed. They perform the process as it is. The difference is the content of the document.
Write in the operators' vocabulary and read it back to them. If a dispatcher would not say it, it does not go in. The validation step is a dispatcher reading the busy-day scenario and saying "that is not what happens," which is the most valuable sentence the project will hear.
Cap it. Fifteen to thirty pages for most IT systems. A ConOps that runs to ninety pages has become a requirements document with narrative padding, and nobody who operates the system will read it. The point is a shared picture, not a complete specification.
Version it once and then stop. The ConOps is signed before requirements begin. After that, changes to the operation go through the requirements process. A ConOps that keeps changing is a sign that the operation was never agreed.

Key Takeaway: Scenarios first, observation before interviews, operators' words, under thirty pages, signed once.

Frequently Asked Questions

What is the difference between a ConOps and a standard operating procedure?A standard operating procedure tells an operator how to perform a task, step by step, in a system that already exists. A ConOps describes how an operation will work with a system that does not exist yet, so that the system can be specified to fit it. The SOP is written after the system is built, from the ConOps and the final design. The ConOps is written before, from observation of the current operation and the intended change. Projects that skip the ConOps typically find the SOP has to describe workarounds for a system that was built without one.

How do we start writing a ConOps on a project that has already begun requirements?Stop the requirements work for two weeks, put a business analyst on site with the operators, and write the five scenarios first: a normal day, a busy day, a bad day, a shift change, and an outage. Read them back to the operators, then compare each scenario to the requirements already written and mark every requirement that no scenario exercises and every scenario moment that no requirement covers. ID Business Analysis Canada does this as a scoped intervention inside a Discovery Sprint, with a business analyst producing the scenario set, the gap list against the existing requirements, and a short ConOps built around the scenarios, so the requirements work resumes against an operation everyone has agreed on. Two weeks at this stage is usually cheaper than the parallel paper process after go-live.

Does a ConOps make sense on an agile project?Yes, and it is more useful there than on a waterfall one, because agile teams derive stories from a backlog that has no natural place for the operation as a whole. A short ConOps written before the first sprint gives the product owner a source for the stories and a test for whether the backlog covers the busy night. It does not need to be maintained sprint by sprint. It is the fixed picture the backlog is checked against.

Who owns the ConOps?The operations lead who will run the system after go-live, with the business analyst as author. Not the sponsor, whose interest is in the outcome rather than the operation, and not the project manager, whose interest is in the schedule. The owner's job is to sign it as a true description of how the operation will run and to be the person who says "that is not what happens" when a scenario is wrong. If no operations lead exists yet, that absence is the first finding.

Conclusion

The requirements were complete and the night shift printed the log sheets, because a hundred requirements described a system and none of them described six incidents at once from a dispatcher's chair. The document that would have caught it has been standard in systems engineering for decades and is almost never written for enterprise IT.

If you are building a system for operators who were not in the room when it was scoped, ID Business Analysis Canada's Discovery & Strategy practice writes the concept of operations first, from observed shifts, in the operators' words, under thirty pages, as the opening deliverable of a Discovery Sprint. Book a free consultation and bring the shift schedule.

Get in touch

Operations First: What Is a ConOps Document and When Do IT Projects Need One?