3.3.5       Concept of Operations

OBJECTIVES	The Concept of Operations includes ·        High-level identification of user needs and system capabilities in terms that all project stakeholders can understand. ·        Shared understanding by system owners, operators, maintainers, and developers on the who, what, why, where, and how of the system ·        Agreement on key performance measures and a basic plan for how the system will be validated at the end of project development.
Description	The Concept of Operations (ConOps) is a stakeholder-oriented description of the system being developed.  This ConOps will present each of the multiple views of the system corresponding to the various stakeholders. These stakeholders include operators,  owners, developers, maintenance, management, and in some cases end users. The documentation of the ConOps can be easily reviewed by the stakeholders to get their agreement on the system description, operations, and maintenance. It also provides the basis for validating the system being built.
Context
INPUT Sources of Information	·        Regional ITS Architecture ·        TSMO Plan or other planning documents ·        Recommended concept and feasibility study from previous step
PROCESS Key Activities	·        Identify stakeholders ·        Define/ refine project vision, goals, and objectives ·        Develop user needs ·        Develop operational scenarios ·        Develop and document concept of operations ·        Develop validation plan
OUTPUT Step Results	·        Concept of Operations describing who, what, why, where, and how of the project/system, including stakeholder needs. ·        Validation Plan defining the approach that will be used to validate the project delivery

 

Overview

The Concept of Operations is a stakeholder-oriented description of the system that is being developed by the project.  The purpose of the Concept of Operations is to clearly convey a high-level view of the system to be developed that each stakeholder who has a stake in the system (e.g. owner, operator, maintainer, developer, management, and in some cases the end user) can understand, as shown in Figure 12.

Figure 12: Concept of Operations

(Source: Adapted from ANSI/AIAA-G-043-1992)

A good Concept of Operations answers who, what, where, when, why, and how questions about the project from the viewpoint of each stakeholder.

·        Who – Who are the stakeholders involved with the system?

·        What – What are the elements and the high-level capabilities of the system?

·        Where – What is the geographic and physical extent of the system?

·        When – What is the sequence of high-level activities that will be performed?

·        Why – What does your organization lack that the system will provide?

·        How – What resources are needed to develop, operate, and maintain the system?

Risks to be Managed

Risk of not building the right system. Avoid the outcome that at the end of the project one or more stakeholders say: “that’s not what we needed!”  This is primarily a technical risk.

Activities

Some of the key activities relating to the development of the Concept of Operations are:

Identify the stakeholders associated with the system/project – SE in general, and this process step in particular, requires participation from the stakeholders who have a stake in the project. One of the first steps in developing a ConOps is to make sure all the relevant stakeholders – owners, operators, maintainers, users, etc. – are identified and involved. You can start with the stakeholder list from the regional ITS architecture (the “operational planning process” discussed earlier) and then expand it to identify the more specific organizations – divisions and departments that should be involved. One of the most effective ways to involve the stakeholders is to create an integrated product team (IPT) of stakeholder representatives (or alternatively called a “project working group”) that brings together the necessary expertise and provides a forum for all project stakeholders.

If you hire a consultant, don’t assume that this is the end of your responsibilities for ConOps development. The stakeholders remain the foremost experts on their needs and must be materially involved in the development. The consultant can provide technical expertise on how to create an effective ConOps output (see discussion below), facilitate the meetings and outreach activities, prepare the documentation, and coordinate the review, but it’s the stakeholders’ concept that should be documented in the end. The stakeholders should consider the documentation of User Needs to be THEIR document, not the consultant’s document.

The best person to write the documentation may not be the foremost technical expert on the proposed system. Stakeholder outreach, consensus building, and the ability to understand and clearly document the larger picture are key. It’s often said that “you can outsource the work (to a consultant), but you can’t outsource the responsibility.”

 

Define/ Refine project vision, goals, and objectives

If not already developed, the vision, goals, and objectives of the project should be discussed and documented.  A vision statement, usually only associated with large projects, is a simple paragraph length statement describing in non-technical terms the end result the project is expected to achieve.
Goals and objectives describe what the potential project should accomplish from the point of view of the operating agencies and their operators, and other stakeholders (e.g system users).  If already developed the vision, goals, and objectives should be revisited and expanded or elaborated as necessary to capture multiple viewpoints.

Develop user needs

Getting agreement on a project’s needs is essential to the successful completion of every project. The effort to define the needs will be performed by those who have a stake in the system.  The needs are most commonly referred to as user needs, but could be more precisely defined as the needs of those groups that will operate, develop, maintain, and manage the system.  For certain systems this list may also include the end user, but for many of the common traffic management related projects the end user will not be a key stakeholder.  For example, for a project deploying additional dynamic message signs, drivers are the ultimate end users, but they will not be a part of the group that develops the user needs. 

For some projects, the needs may be well known. For example, a municipality has five Closed Circuit Television (CCTV) cameras deployed and would like to add three additional (and functionally identical) cameras at key congestion points within their network. In this case the needs have been previously considered and agreed to (whether explicitly or implicitly), and the needs of the additional cameras are the same as for the original cameras. In other cases, the needs might be known only at a very high level (e.g. “the region would like to improve data sharing between agencies”), but a careful documentation of the needs will improve the likelihood of a successful outcome.

Sometimes a needs statement such as in the prior example (“the region would like to improve data sharing between agencies”) might be interpreted differently by different stakeholders, and that ambiguity may lead to the risk of not building the right system (at least in the minds of some stakeholders). Needs should be validated right after the project goes operational. Validation of needs means testing whether the needs are satisfied by the now operational project. Documenting (and getting stakeholder agreement) at the beginning of the project how the needs will be validated can clarify in the minds of the stakeholders exactly what the needs mean. For example, the need might be tested by “1). The CCTV camera images shall be visible to the County Fire Department dispatcher in real-time. And 2). The camera PTZ (pan-tilt-zoom) controls shall be operable by the County Fire Department dispatcher during an incident.”  If there are stakeholders who think that this test is not the data sharing, they had in mind, it’s best to find out early in the project when the needs are being discussed and agreed to.

 Incrementally create the user need(s), review relevant portions with stakeholders, and adjust the needs as necessary to get buy-in. All stakeholders do not have to agree on every aspect of the project, but all stakeholders must feel like they are achieving their major needs for the project.

The user needs provide an expression of the end users’ operational needs that can be met by the system that will be developed or upgraded. User needs have a well-defined set of criteria that have been used for systems engineering development for decades. Well written user needs all share the following criteria:

1.       Uniquely Identifiable. Each need must be uniquely identified (i.e., each need assigned a unique number and title). This criterion is necessary for traceability that occurs in other processes.

2.       Major Desired Capability (MDC). Each need should express a major desired capability in the system, regardless of whether the capability exists in the current system or situation or is a gap.

3.       Solution Free. Each need should be solution free, thus giving designers flexibility and latitude to produce the best feasible solution. This means the needs should be neutral to technology (even though some stakeholders might have an idea of the one or more solutions/technologies they believe are needed).

4.       Capture Rationale. Each need should capture the rationale or intent as to why the capability is needed in the system. This can be as brief as a single sentence (or a reference to the need in a prior project), or a few paragraphs, or a trade-off study between competing alternative needs.

User needs can address a variety of need areas including:

·        Operations (e.g. reduction of staff to collect tolls, reduction or elimination of dwell time to collect tolls),

·        Maintenance (e.g. reduce the frequency of hardware faults), or

·        Strategic (e.g. extend transportation services to new geographic areas).

Because there may be competing needs for limited resources, needs can be ranked (e.g. in a trade study) by the value of the satisfaction of the need vs competing needs. A trade study can use objective criteria for comparing needs, including:

·        Safety improvement e.g. travel crash/death/injury rate reduction.

·        Travel cost reduction

·        Air quality improvement

·        Travel time reduction

·        Travel time reliability improvement

·        Security incident reduction

·        Incident response time reduction

·        Traveler satisfaction improvement

Including how each user need will be validated after the new ITS project becomes operational will clarify the user need in the minds of the stakeholders.

Develop operational scenarios

Operational scenarios are an excellent way to work with the stakeholders to define a key aspect of a ConOps. Scenarios associated with a major incident, a work zone, or another project specific situation provide a vivid context for a discussion of the system’s operation. It is common practice to define several scenarios that cover normal system operation (the “sunny day” scenario) as well as various fault-and-failure scenarios.

Develop and document concept of operations

The ConOps should be an approachable document that is relevant and understandable to all project’s stakeholders. It should be relevant to system operators, system maintainers, system developers, system owners/decision makers, other transportation professionals, and in some cases the end user. The art of creating a good Concept of Operations lies in using natural language and supporting graphics so that it is accessible to all while being technically precise enough to provide a traceable foundation for the system requirements document and system validation.

Graphics should be used to highlight key points in the Concept of Operations. At a minimum, a system diagram that identifies the key elements and interfaces and clearly defines the scope of the project should be included. Tables and graphics can also be a very effective way to show key goals and objectives, help illustrate operational scenarios, etc. 

Portions of the concept of operations can often be created from existing documents. For example, the regional ITS architecture should include stakeholder roles and responsibilities and high-level information flows that stakeholders have agreed can be used. An operations planning system study report, if prepared, or other preliminary study documentation, may provide even more relevant and refined information. Even a project application form used to support project programming will normally include high-level goals and objectives and other information, when relevant, that should be included (or referenced) in the Concept of Operations for continuity with the existing planning investments. An MPO Long Range Planning document or the original project business case documentation for the project can often be used to trace backwards from the project needs.

Last but not least, the ConOps development phase is when concerns related to security, including cybersecurity and physical security are first considered. Security definition should occur in parallel with systems engineering steps, incrementally achieving greater levels of detail based on the SE content created at each step, until the security design is completed in the design step. Note that cybersecurity is a particularly specialized field, so for systems with significant security concerns specialized personnel with expertise in cybersecurity may be required as part of the project team.

Develop validation plan

In addition to setting expectations for the stakeholders about what the system will achieve, the user needs can serve a more formal role once the system has been developed and tested; they can help to validate the system. Defining the method of validating a need in advance of developing the system will clarify for all the stakeholders the precise definition and intent of the need. Creating a validation plan reduces the risk of stakeholders misunderstanding the definition and intent of the need, and can be used to manage the stakeholders’ expectations from the beginning of the project. This plan is usually (but not always) created separately from the Concept of Operations documents described below.

Tailoring this Step

The level of each activity should be scaled to the size of the project. For example, a small project may have a Concept of Operations that is only a couple of pages long. The emphasis on concept exploration depends more on the newness of the project than on its size. For example, if the system will be automating activities that were formerly manual, or integrating formerly independent activities, it is a good idea to look at alternative ways for structuring the system. This will be useful for allowing the stakeholders to envision using the new system. Whenever formerly independent activities are merged, it is essential to carefully spell out the new operational responsibilities of each agency.

Policy or standard for Process Step

The FHWA Regulation/ FTA Policy requires participating agency roles and responsibilities to be identified in the systems engineering analysis for ITS projects funded from the Highway Trust Fund, including the Mass Transit Account. It also requires procedures and resources necessary for operations and management of the system to be defined. The roles and responsibilities, operations procedures and resources are initially defined and documented for the project as part of the Concept of Operations.

Two different industry standards provide suggested outlines for Concepts of Operations: ANSI/AIAA-G-043-1992 and ISO/IEC/IEEE 29148 as shown in Figure 13.  Both outlines include similar content, although the structure of the 29148 outline lends itself more to incremental projects that are upgrading an existing system or capability. The ANSI/AIAA outline is focused on the system to be developed, so it may lend itself more to new system developments where there is no predecessor system. Successful Concepts of Operation have been developed using both outlines.

Figure 13:  Alternative Concept of Operations Document Outlines

(Source: ANSI/AIAA-G-043 and ISO/IEC/IEEE 29148)

 

Note that this guide uses the term Concept of Operations (ConOps) where other sites like the International Council of Systems Engineering (INCOSE) use the term Operational Concept when discussing a project level document that captures the needs the stakeholders have and how those needs will be met in the system.  In the ITS industry, an Operational Concept is defined in 940.9 (c) (3) as “An operational concept that identifies the roles and responsibilities of participating agencies and stakeholders in the operation and implementation of the systems included in the regional ITS architecture;”.  Thus, an Operational Concept tends to be associated with a broader regional view of ITS within the ITS industry, while the Concept of Operations is a more specific project or system-level document.  When you consult references outside the ITS industry, these terms may be used in precisely the opposite way.

 

Traceable Content

The key artifacts determined by the Concept of Operations development process are the definition of Stakeholder Needs, identified in Table 4, with their backward and forward traceability to other process artifacts or external documents. Traceability from needs to requirements will be discussed in the next section.

Table 4: Concept of Operations Traceability

Traceable Artifacts	Backward Traceability To:	Forward Traceability To:
Concept of Operations	Needs in the Long Range Plan or Original Project Business Case documentation	Requirements
Validation Plan	Concept of Operations	Validation Tests

 

Checklist

The following checklist can help answer the question “Are all the bases covered?” once the activities above have been planned or performed.  The checklist is not sufficient by itself.

 

R  Are goals, objectives, and vision (if included) evident?

R  Has an identification of stakeholders and their responsibilities been made?

R  Are the operations described from the viewpoints of all key stakeholders?

R  Have the operational user needs been defined?

R  Does the system description include external interfaces?

R  Are both operational and support environment included?

R  Does evidence exist for alternative concepts and rationale for the selection process?

R  Have operational scenarios been documented?

R  Are both normal and failure operational scenarios included?

R  Is the Concept of Operations documented in an easily understood manner?

R  Has the Concept of Operations been reviewed and accepted by the key stakeholders?