Over the years, the success rate of traditional project management methods applied to software development projects has been underwhelming.
These traditional methods are based on a retrospective approach that measures variance against plan rather than providing a performance–forecast that can be used to guide projects in a chaotic environment. [1] There are several programmatic control issues associated with IT projects that suggest a better approach is needed. [2] Using this linear project planning process – sometimes known as waterfall – but often derived from PMBOK style planning processes; there is little attention given to the forces that negatively impact the project. These project risks have no means of evaluation other than to acknowledge their presence, define mitigations and track the results. The impact on the business value of the capabilities of the system is not part of the project management process.
In this current approach avoiding or controlling change becomes the primary activity of project management. In this traditional model, change is undesirable. In reality of business systems development, change is not only natural it is desirable. It is through change that the system can adapt to the needs of the business, which are themselves driven by external forces. These forces are rarely under the control of the project manager let alone the senior management of the business.
One project failure mode is when the participants and leaders of the project fail to recognize the difference between managing in the presence of change and managing change. It is managing in the presence of change that is a critical success factor of any modern business systems development.
Definition of Capability-Based Planning
“Capabilities-Based Planning… involves a functional analysis of operational requirements. Capabilities are identified based on the tasks required… Once the required capability inventory is defined, the most cost effective and efficient options to satisfy the requirements are sought.” [5]
What Are Capabilities and Why Are They Better at Describing Maturity?
Measuring project and product maturity as a function of effort and time assures project management adds value to the business. Simply controlling and measuring the expenditure of resources – scorekeeping – provides little value in the presence of change.
Capabilities–based planning provides a defined outcome that is not a conclusion but lays the groundwork for the continued delivery of value. Objectives are reached and the operational value delivered when a defined capability is available for use. Features and functions describe the static and dynamic behaviors of a system, but they are not directly connected to the business strategy. Milestones indicate that a position in a timeline has been reached, but do not forecast what value will be delivered to the business or how this value is traceable to the needs of the user community. Capabilities provide the answer to the following question: to achieve our objectives, what capabilities must we possess? [3]
Capabilities–based planning transforms the delivery of features and functions into the delivery of processes and technologies that support the business strategy. Capabilities–based planning is planning, under the conditions of uncertainty, to provide capabilities suitable for a wide range of business challenges and circumstances, while working within an economic framework. This approach emphasizes flexibility, adaptiveness, and robust capabilities, implying a modular building–block approach to the delivery of enterprise applications.
Capabilities are not the same as features and functions; they enable demands to be met without the explicit specification of the solution. A capability is the ability to affect an outcome, react to an input, or change an effect.
A capability provides an outcome or an effect without an a priori specification. Features and functions require an a priori specification to test for their existence or conformance to the specification. Capabilities–based planning can be understood at the execution level, but it needs to be raised to the level of enterprise process analysis:
Identify a needed capability in operational terms, using the set of capability options to assess the effectiveness in an operational paradigm, and make choices about requirements and the ways to achieve the capability using an integrated portfolio framework to produce an output set of options based on these operational paradigms.
Putting capabilities–based planning to work requires a change in our approach to planning — a set of business process improvement activities focused on assessing increasing maturity of the capabilities needed to fulfill the strategic objectives. Emphasis is placed on operational capabilities rather than features and functions. These operational capabilities become the building blocks of change. The emphasis is also placed on evaluating capabilities under conditions of uncertainty, which requires the deployment of robust building blocks capable of adapting to these changes. In both cases, analysis illuminates the feasibility of alternatives.
Using Scenarios to Define Capabilities
Scenario-based planning is one approach to defining the objectives in an enterprise application development environment. While scenarios are a popular decision–making process, we must distinguish between two approaches to scenario-based development:
- Finding alternatives
- Evaluating existing alternatives
The first use (finding alternatives) is the most common but has problems. The second use is equivalent to simulation-based acquisition. An example is an assumption that a business strategy can be discovered by studying individual scenarios. This what-if approach to optimal decision making is flawed when some of the parameters are unknown — as is the case in most IT projects.
Issues found in scenario-based planning can be addressed by a capabilities-based view of the world. Scenarios are related to each other in different contexts; changes made to one operational scenario may impact another. The selection of scenarios must be based on the proper understanding of the relations and impact on other scenarios. Capabilities provide a collection point to consolidate scenarios by systematically defining operational concepts and their relationships, with each capability defining the compelling rationale for decisions found in a portfolio of projects.
Augmenting Our Strategy–Making with Capabilities
Strategy–making is the starting point for project management. It asks and answers the question why are we doing this? Strategy making activities can be augmented through a capabilities-based planning process by mapping strategies to the assessment of maturity evaluation points for each of the emerging capabilities. This approach connects the why of a project with the how. The result is the replacement of the measurement of progress as the passage of time with the measurement of progress as the delivery of capabilities.
Capabilities–based planning focuses on assessing the increasing maturity of functionality defined by the strategy. Planning under uncertainty provides capabilities suitable for a wide range of challenges and circumstances while working within an economic framework that necessitates choice, where the focus is on “possible uses” rather than specified features and functions.
For example:
- What features do we need to achieve the desired capability?
- How much of each capability do we need at a specific point in time to satisfy our strategy?
- If we possessed a capability how would we apply it in pursuit of a strategy?
- With a specific capability, what benefits could be accrued to our organization and how would we measure these benefits?
- How can we test our strategies using these measurable benefits?
The difference between a capability and a feature or function is the difference between the delivery of a pre-specified solution and the creation of a foundation for responding to various uncertain demands. It is this ability to respond in the presence of uncertainty that provides value to the organization. Trying to control this uncertainty through frozen specifications and change control procedures ignores the reality of the business environment – uncertainty is the way of life. Trying to control uncertainty leads to failure; managing in the presence of uncertainty is the basis of success. [4]
A capabilities-based planning process…
- Focuses on the outcomes rather than on the features and functions of an IT system – what can I do with the system when that capability is available?
- Focuses on the delivery of the value of the effort that produces these outcomes rather than the consumption of resources – what have you done for me lately?
- Defines the needed maturity and assess its presence to provide feedback to the business strategy – what capabilities do I need at this point to accomplish my mission?
Capabilities–based planning replaces the specification of features and functions with the definition of the needed business capabilities, traceable to strategy through a portfolio of projects and their program events.
It does so by:
- Planning the delivery of capabilities rather than the delivery of features and functions - it's the Capabilities the Customer Paid for. The Features implement these Capabilities. But the Features have many alternatives and the discovery of these alternative Features is an iterative and evolutionary process
- Identifying the features and functions that are the raw materials of capabilities - only after the Capabilities have been defined, can the Analysis of Alternatives (AoA) for the Features take place.
- Making visible the capabilities that enable the delivery of the strategy - a Capabilities Roadmap shows when the Capabilities are needed to fulfill the needed Strategies for Mission Success or Business Plan implementation.
[1] Wharton Strategic Management, “Three Reasons Why Good Strategies Fail: Execution, Execution, …” 10 August 2005.
[2] “Uncertainty and Project Management: Beyond the Critical Path Mentality,” Arnoud de Meyer, INSEAD Working Paper, 2001.
[3] “Analytical Architecture for Capabilities–Based Planning, Mission–System Analysis, and Transformation,” Paul K. Davis, RAND National Defense Research Institute, MR–1513–OSD, 2002.
[4] This in no way assumes we do not need configuration control, change control, or change management. Just that these processes and the tools they use must support the paradigm of managing in the presence of change rather than trying to manage change by preventing it from happening. Change prevention (or the change prevention department) adds little value to an enterprise IT project.
[5] "Analytic Architecture for Capabilities-Based Planning, Mission-System Analysis, and Transformation," Paul K. Davis, RAND Corporation
