Concept of Operations and Root Cause of Project Failure

One root cause 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 user's operational needs, desires, visions, and expectations without being overly technical or formal.?The CONOPS facilitates a shared understanding of ideas, challenges, and issues regarding the possible solution strategies to the problem at hand?without addressing the technical solution or implementation. The ConOps is the first step in 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 deciding 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, and 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 are the fundamental 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 the 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 the user can verify 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 quantified, testable specifications. For example, the users could express their need for a "highly reliable" system and their reasons for that need without producing a testable reliability requirement. [In this case, the user's need for "high reliability" might be stated in quantitative terms by the buyer before issuing a request for proposal (RFP), or the developer might quantify it 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 and 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 clearly so all intended readers can fully understand it.
• 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 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 detailed description of the operational environment gives 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 influence the proposed system's operation or operational environment.
• The place where descriptions, such as a data dictionary, are in an appendix or incorporated 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 whatever 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 required budget. The ConOps is the place to start identifying those needed Capabilities.?

Without the identified needed Capabilities, the order of their delivery, and 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

1. "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
2. "Concept of Operations," MITRE Systems Engineering Handbook
3. IEEE Guide for Information Technology - System Definition-Concept of Operations (ConOps) Document, IEEE Standard 1362-1998, IEEE Computer Society, March 19, 1998.
4. Analysis of Alternatives (AoA) Methodologies: Considerations for DHS Acquisition Analysis, Version 3.0, January 2014,?Homeland Security Studies & Analysis Institute.
5. 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.