The agile community likes to suggest that agile development is the solution to many of the problems that are the root cause of IT project failure. I know agile development processes add measurable value to the development of software. Because we use them on actual software intensive projects.
But if the organization requesting that software doesn't know what capabilities they are asking for in the software, no amount of exploring and emergence by discovering the requirements is going to help improve the probability of project success. The project simply doesn't know what DONE looks like in any unit of measure meaningful to the business. Requirements are not the same as Capabilities. Requirements enable Capabilities, but Capabilities come first.
The process to develop the Capabilities doesn't have to be anywhere near as the Joint Capabilities Integrated Development System (JCIDS) but some how, some where, there needs to be a statement of what Done looks like from the users perspective. This statement says how the system will be used to accomplish the business strategy. Technical specifications are no business strategy. Databases, Java code, User Interfaces are not business strategy.
One successful approach is to establish what is needed by the business BEFORE applying agile software development methods is called Capabilities Based Planning.
“Planning, under uncertainty, to provide capabilities suitable for a wide range of modern-day challenges and circumstances while working within an economic framework that necessitates choice.”
By Identifying system capabilities, the elicited technical and operational requirements can be traced from the Measures of Effectiveness to each deliverable in the Integrated Master Plan and Schedule. Capabilities state the “why” of the system.
With these system capabilities in hand, the standard agile processes can then be applied to emerge solutions to enable those capabilities to be delivered.
In order to discover the needed capabilities, we need to:
- Define the operational concepts as Capabilities
- Partition system capabilities into classes of service within operational scenarios
- Connect capabilities to system requirements
- Define Measures of Effectiveness (MoE) from the customer point of view
- Define in the delivery schedule the achievement of each Technical Performance Measure
- Define the capabilities through Scenarios or Use Cases
- Define scenarios for each system capability
- Connect these scenarios to a Value Stream Map of the increasing maturity of the program
- Assess value flow through the map for each needed capability
- Identify capabilities mismatches and make corrections to improve overall value flow
- Asses the needs, costs, and risks of the Capabilities simultaneously
- Assign costs to a system element using a value model process model
- Assure risk, probabilistic cost and benefit performance attributes are defined
- Use cost, schedule and technical performance probabilistic models to forecast potential risks to program performance
- Define explicit, balanced, and feasible alternatives
- Make tradeoffs that connect cost, schedule, and technical performance in a single “trade space” model
- Measures of Effectiveness and Measures of Performance are the raw materials for these tradeoffs
Notice a few things here
- We need to know the cost of a capability before we can make any tradeoffs with other capabilities.
- We need to know the value of the capability to the business or the mission before we can determine of we can afford the cost.
So when someone suggests we don't need to estimate the cost of the capability you'd like to possess, we'll just get started writing software. Or, we're exploring dysfunctions in the organization - without actually ever specifying those dysfunctions or all possible actionable solutions to the unspecific dysfunctions, or any non-trivial projects where this unspecified solution has been applied (beyond a 5 week project with 3 people in the same room)
Run away as fast as you can. You're on a train wreck waiting to happen.
