One of the root causes of project failure is the failure to apply the first principle of the five principles of project success
What does done look like in units of measure meaningful to the decision maker?
Those units must include Measures of Effectiveness and Measures of Performance. But where do these live? Where do they come from? The answer to that is the Concept of Operations (ConOps). The ConOps described the operational needs, desires, visions, and expectations of the user without being overly technical or formal. The CONOPS facilitates a shared understanding of ideas, challenges, and issues on the possible solution strategies to the problem at hand, without addressing the technical solution or implementation. The ConOps is the first step for developing system requirements. Without the ConOps, the requirements have no place to live.
The ConOps contains the conceptual view of the system and illustrates the top-level functional threads in the proposed system or situation. The CONOPS defines critical, top-level, performance requirements (MOP) and business or operational objectives (MOE) stated qualitatively or quantitatively (including system rationale for these objectives).
Johns Hopkins University's Whiting School of Engineering provides an approach to making the decision about what's in the ConOps and its format based on some Systems Engineering analysis of criteria:
- Program risks - reducible and irreducible uncertainties that create these risks.
- Customer desires - in the form of business, technical, or operational capabilities
- Funding constraints - how much money do we have, when can we spend it, what's our management reserve?
- Market considerations - who's going to buy this? What's our competition?
- Technology considerations - what limitations do we have?
- Nature of the system to be developed - what's the basic processes of the system?
The objective of the ConOps includes: [3]
- Provide end-to-end traceability between operational needs and captured source requirements.
- Establish a high-level basis for requirements that support the system over its life cycle.
- Establish a high-level basis for test planning and system-level test requirements.
- Support the generation of operational analysis models (use cases) to test the interfaces.
- Provide the basis for computation of system capacity. Validate and discover implicit requirements.
The tangible value of the ConOps is ...
- The means of describing a user's operational needs without becoming bogged down in detailed technical issues that shall be addressed during the systems analysis activity.
- The mechanism for documenting a system's characteristics and the user's operational needs in a manner that can be verified by the user without requiring any technical knowledge beyond that required to perform normal job functions.
- The place for users to state their desires, visions, and expectations without requiring the provision of quantified, testable specifications. For example, the users could express their need for a "highly reliable" system, and their reasons for that need, without having to produce a testable reliability requirement. [In this case, the user's need for "high reliability" might be stated in quantitative terms by the buyer prior to issuing a request for proposal (RFP), or it might be quantified by the developer during requirements analysis. In any case, it is the job of the buyer and/or the developer to quantify users' needs.]
- The mechanism for users and buyer(s) to express thoughts and concerns on possible solution strategies. In some cases, design constraints dictate particular approaches. In other cases, there may be a variety of acceptable solution strategies. The CONOPS document allows users and buyer(s) to record design constraints, the rationale for those constraints, and to indicate the range of acceptable solution strategies [4].
- Uses tools and/or techniques that best describe the proposed system from the user's perspective and how it should operate. Describe the system simply and clearly so that all intended readers can fully understand it.
- Is written in the user's language. Avoid technical jargon. If user jargon is employed, provide a glossary that translates it for non-users.
- Produced with graphics and pictorial tools as much as possible, since a CONOPS should be understandable to different types of stakeholders. (Useful graphical tools include, but are not limited to, node-to-node charts, use cases, sequence or activity charts, functional flow block diagrams, structure charts, allocation charts, data flow diagrams, object diagrams, storyboards, and entity relationship diagrams.)
- A description of the operational environment in detail to give the readers an understanding of the assumptions, constraints, numbers, versions, capacity, etc., of the operational capability to be used. Describe those aspects of the physical environment, safety, security, and privacy that exert influence on the operation or operational environment of the proposed system.
- The place where descriptions, such as a data dictionary, in an appendix, or incorporate them by reference.
Can All This Formality Have Any Use in Modern Software Development?
Yes it can, yes it Does, Yes, it's the basis of the Product Roadmap and Release Plan
The notion that agile development is a free-for-all development of what ever the customer wants to produce next, with the customer identifying the next important thing to develop works just fine for de minimus projects. For any non-trivial project, we have a planned release date for the needed Capabilities, for a needed budget. The ConOps is the place to start identifying those needed Capabilities.
Without the identified needed Capabilities, the order of their delivery, the targeted cost for each Capability, the business viability of the system is in doubt.
The Concept of Operations is one of the description of what Done Looks Like
Resources
- "Developing a Stakeholder-Assisted Agile CONOPS Development Process," Ali Mostashari, Sara A. McComb, Deanna M. Kennedy, Robert Cloutier, and Peter Korfiatis, Systems Engineering, Vol. 15, No. 1, 2012
- "Prototype of a Graphical CONOPS (Concept of Operations) Development Environment for Agile Systems Engineering," Final Technical Report SERC-2013-TR-030-2
August 30, 2013 - "Concept of Operations," MITRE Systems Engineering Handbook
- IEEE Guide for Information Technology - System Definition-Concept of Operations (ConOps) Document, IEEE Standard 1362-1998, IEEE Computer Society, March 19, 1998.
- Analysis of Alternatives (AoA) Methodologies: Considerations for DHS Acquisition Analysis, Version 3.0, January 2014, Homeland Security Studies & Analysis Institute.
- Systems Engineering for Software Intensive Projects Using Agile Methods, Larri Rosser, Phyllis Marbach, Gundars Osvalds, and David Lempia, Systems Engineering Conference, Washington DC (SEDC), 2014.
