Concepts of operations - an extract from my forthcoming book

If you're lucky, you may already have heard of documents such as a concept of operation (CONOPS for short) or operational concept. If you're exceptionally lucky you may also have heard of a concept of use (CONUSE) or concept of employment (CONEMP), although these terms are less well-known.

These artefacts can be partitioned and titled in several ways, which can be confusing, but they all serve one purpose: to provide background information that informs the requirements that are set for a particular system of interest.

Confusingly, many authorities disagree on the scope and naming of documents or artefacts in this subject area.

There are three main themes to consider and, depending on your source, these can be included in a concept of operations or in another document with a different name. The sketch at the top of the page illustrates some common naming conventions. The magenta outlines are my own preferred conventions. What's important is to figure out what your organisation does and doesn't include in its documentation.

If you take nothing else away from this section, at least remember this:

It is almost always worth making the effort to understand why your customer is asking you to deliver a solution to them, because it can help you define a solution that better meets their needs.

This theme is one of the hardest to analyse in a pure sense, because it is often very difficult to elicit pure needs from stakeholders without them being in some way influenced by their ideas of what kind of system would be a good or familiar solution.

One of the reasons for the confusion is that a concept of operations or CONOPS is rarely created without a particular system in mind; that is, we usually write a CONOPS after we have decided that we need to procure a system. 

Strictly speaking, though, the decision to procure a particular system should be made based on the needs identified in the CONOPS, which therefore needs to be considered first!

However, in organisations with well-documented processes for how they operate, the core of a true CONOPS may already be available: the description of the organisation's structure and processes independent of technology, often referred to as business processes even if the organisation is not strictly a business. I describe needs in this area as operational needs, where I really mean "how the organisation operates'' as opposed to "how users operate the system''.

The reason for trying so hard to separate business-level needs from technical requirements on the system is very simple: for any given set of business needs, multiple system scopes may be possible - and the optimal system scope needs to be selected before proceeding to decide what that system must do.

Extracting the underlying needs

As a solid example, let's imagine we write a CONOPS for a toaster. That is to say, we are doing things the way industry usually does: we already have some kind of solution in mind, but want to identify the true needs that underly why we are trying to procure that solution.

Of course, that might mean that something other than a toaster is the best solution - we'll come to that in the section on CONUSE. Let's work with the toaster as a basis for now.

So, what do the users of a toaster need to accomplish? Of course, it depends on the individual, but let's list some likely candidates:

• Toast sliced bread
• Heat toaster pockets
• Toast sandwiches
• Warm croissants or rolls

Of course, it's not enough to just know what the users need to do. We also need to know the answers to many questions beginning with "how'', such as:

• How large are the items to be toasted?
• How many items are to be toasted at once?
• How often are items to be toasted?

Note that these needs can be met in several different ways. To describe the needs precisely, it is not necessary to dictate a particular solution. The level of quality required will often exclude certain solutions. 

There is no single uniform way to ensure that you have asked enough of these questions. You have to use your judgement to determine if your set of needs is sufficiently complete for you to begin basing your system design on it.

Placing the needs in their context

The fundamental needs we have identified now need to be placed in some kind of environmental context in order to complete the picture that we present in our CONOPS.

Where in the world are the intended activities going to take place? A commercial kitchen is going to need a very different toasting solution from a private kitchen or a campsite.

The physical environment is only one aspect of the context; there are many other possible sources of constraints that should also consider.

There are several different mnemonics for prompting the consideration of different contextual themes. I prefer the PESTEL mnemonic:

Political - constraints arising from strategy, policy and doctrine of the user organisation and/or applicable governments

Economic - constraints on costs, financing and benefits

Social - constraints arising from the interaction of people, including fairness and anti-discrimination considerations

Technical/technological - constraints arising from the technology in the environment, for example limitations on local construction capability

Environmental - constraints arising from the natural environment, that is the geography - climate, terrain, wildlife and so on

Legal - constraints arising from applicable legislation and/or regulation

PESTEL is intended to take a very high-level view but it is reasonably applicable to our family home example. Constraints such as local regulations, availability of materials and labour for construction, the location where the solution is to be used and the available budget all fit into these categories. It's not as important to categorise them precisely as it is to use PESTEL as a prompt to help us identify the different issues that are in play.

Summary

However we package our documents, we need to attempt to understand and describe the operational needs of our stakeholders: the things they need, and the context in which those needs are to be addressed. 

If we understand enough about why the stakeholders need the system, it helps us make more informed design choices as engineers, and reduces the risk that our solution fails to meet the needs of the stakeholders.

The operational needs should be used as a basis for validation of the solution. Validation is about giving evidence that a solution is fit for purpose. The operational needs we have discussed in this section are a way to understand and document that purpose.

To be continued in parts 2 (concepts of use) and 3 (concepts of employment) - where we look at the needs that emerge once we've decided on the system boundary.