Capabilities Based Planning

s

One of the root causes of project failure is the apply the First Principle of the Five Principles of project success …

What does Done look like in units of measure meaningful to the decision makers?

With the Five Immutable Principles of Project Success in hand, let’s start applying them through some Practices and Processes that implement those practices. There are 5 Practices needed to implement the Five Principles.

The first Practice is to define the needed Capabilities produced by the project. If we’re looking for the units of measure meaningful to the decision makers, they come from 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).

The ConOps is based on 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 is to:

• 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.
• The place for users to state their desires, visions, and expectations without requiring the provision of quantified, testable specifications.
• The mechanism for users and buyer(s) to express thoughts and concerns on possible solution strategies.
• Uses tools and/or techniques that best describe the proposed system from the user’s perspective and how it should operate.
• Is written in the user’s language.
• Produced with graphics and pictorial tools as much as possible, since a CONOPS should be understandable to different types of stakeholders.
• 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.
• The place where descriptions, such as a data dictionary, in an appendix, or incorporate them by reference.

Glen Allenman is part of the GovLoop Featured Blogger program, where we feature blog posts by government voices from all across the country (and world!). To see more Featured Blogger posts, click here.