[Intelink-U mirror]

What the heck is CAIV?

CAIV is an idea that when buying systems, Cost should be treated As an Independent Variable (CAIV). The concept and term were popularized in the 1990s Defense Acquisition Reform efforts, and (I think) comes from the Military Operations Research community.

Traditionally, there is a waterfall-like process for buying things in the military: first, ask the “warfighter” what they need, and they come up with requirements. Then figure out what that costs, ask Congress for the money, and build it.

Wait, what? The users decide what they think they need, before considering how much it will cost? How does that work?

So, that’s where CAIV should come in. As I see it, CAIV is a simple three step process: first develop a vague idea what you want (um… “a high-level requirement”), then you figure out how much you want to budget for that idea, then finally go try to get the best solution you can for the money you set aside –  trading requirements, risk, and schedule – to deliver maximum value for a fixed cost.

For example: this is how we buy cars in my family: (1) My wife decides we need a new mini-van (e.g. pregnant w/ another child). (2) I start saving… and shortly before the baby is born, I figure out how I want to spend based on how much I’ve saved and how much I’m willing to borrow. (3) We go to the dealership and try to get the best deal we can for the dollar figure that’s already in my head. The Cost is decided in step 2 – and is Independent of the actual vehicle chosen in step 3.  If we negotiate well, we can get a new 8-passenger model.  Or we could get a used model but get the leather interior and built-in DVD players.  Maybe we could live with the 7-passenger model with all the extras?  Or could we hold off until the price drops on last year’s model?

I can budget for a new mini-van without a detailed cost model, simply knowing that I need a better mini-van than I currently have, and with only a vague notion of what mini-vans actually cost.  I can do this with confidence, because my plan is to “buy the best mini-van available within my budget.”

To this day, this chestnut which enshrines CAIV in DoD policy, is buried in DoDD 5000.01:

E1.1.4. Cost and Affordability. All participants in the acquisition system shall recognize the reality of fiscal constraints. They shall view cost as an independent variable, and the DoD Components shall plan programs based on realistic projections of the dollars and manpower likely to be available in future years. To the greatest extent possible, the MDAs shall identify the total costs of ownership, and at a minimum, the major drivers of total ownership costs. The user shall address affordability in establishing capability needs.

That passage makes it sound like CAIV is just a hedge against cost-overrun.  But consider the other end of the idea: Given a specific budget, how much capability could you deliver? Remember Moore’s law (and related “laws” such as Kryder’s law, and Butter’s Law, etc.): as the costs of IT basics such as computation, data storage and networking fall exponentially, the amount of “capability” that a given project can deliver for a dollar becomes unpredictable.   The combination of automation and commoditization makes this even more acute.

So CAIV, properly executed, hedges this unpredictability by aggregating requirements at the “vague need” level.  That sounds bad….  The challenge is that CAIV absolutely requires that during execution of the program the PM have the ability to make trades in the requirements space.  The more detailed the requirements, the less well this works.  This is sounds plausible in a blog post, but in the real world of Defense Acquisition, there is a significant disconnect between the requirements and acquisition processes.

Intelink is a beautiful example of doing this sucessfully:  Intelink’s mission is to provide “services of common concern for the Intelligence Community and its mission partners.” (my understanding – not an exact quote)  They have a budget to do this within, and a high degree of flexibility in how to achieve it.   This allows Intelink to deliver exceptional value because they can reduce costs through aggressive automation and commoditization – for example, leveraging existing PKI solutions for user provisioning and fielding Open Source Software solutions – and plow the savings into the next fun project to empower and delight their users.  Hence the tagline: “Driven by Mission, Enabled by Innovation”.

I see Defense Acquisition programs, on the other hand, as the opposite of this model.  In order to control requirements creep, the requirements are specified very rigorously.  Early in the program, program managers are incentivized to make the requirements aggressive(*), in order to increase the budget for the program, (and the prestige of the program manager), which increases the perception of later flexibility.  More money makes things easier, right?   … Except that the money was justified by fiendish requirements which will be difficult to meet during Operational Test.  (* I understand that Program Managers are not supposed to have influence on their own requirements, and they never do, except for always.)

(There’s probably a sweet-spot middle ground, where the requirements are fully specified – but the PMO has the flexibility to discard or augment those requirements as needed, with consultation from the user/customer and oversight processes.)

In the end, I think CAIV is a brilliant idea, because:

1. CAIV mirrors how people actually think about budget allocation.
2. CAIV is fundamentally focused on dealing with fiscal reality and containing cost growth.
3. CAIV addresses the inherent cost uncertainties in the development and operation of IT systems

Alas, I think the Defense Department processes are currently not well aligned to CAIV, because:

1. Budgets are driven by Life Cycle Cost Estimates, rather than the other way around.
2. Requirements definition processes are deliberately isolated from engineering and acquisition processes.
3. Incentives and performance measures for program managers are rarely focused on actual user satisfaction or mission accomplishment.

As a final thought, specifically for software-intensive systems, I’d like to propose a complementary idea of “Schedule as an Independent Variable”, which I will describe in some future post.