The CIO Code

Projects fail because we don’t manage change well. One of the impacts of change is that new or changed needs have budgetary impact. If we have a restricted budget, we end up without the resources to accommodate change as it arises. One of the classic traps of a fixed cost contract is the difficulty we have managing change. Done right, fixed cost establishes Predictability and manages risk. Thought about incorrectly, fixed cost leads us predictably into the land of the 75% project failure rates. The manage reserve will help us stay in the 25%.

The principle of a management reserve is to allocate funds to accommodate change as it arises. This is different from a buffer, in which we recognize that tasks most likely take longer than we think they will. Instead, it is a margin that we define in advance that has no purpose other than to be allocated to managing change. It allows us to have a fixed cost contract while providing a framework in which to evaluate and accommodate change.

I’m a big fan of fixed cost contracts: figure out how much you want to spend on something and then share the risk and reward with the people building it. The service provider bears the risk of the project costing more and the reward of completing early.

The problem is, by itself, a fixed-cost contract does not provide the tools to manage either risk or reward. While it provides a budgetary number, it does not provide a framework for change management.

The fixed-cost contracts we have worked with have tended towards one of these options:

• Cap with justification: we start with a number and know it won’t change unless we need it to change; or
• Zero-sum: start with a number and as new tasks come up, chop off low-priority items

Neither of these accounts for change in a manner to preserve either Predictability or Productivity.

Cap with Justification attempts to achieve Predictability by setting a cap on effort. The problem with this, is that if you don’t know what your true cost threshold is, you really don’t have a budget. You just have a starting point. The reality of the starting point, is that those who write the checks will see it as a budget. When change arises, you know you will need to go back to the well, and the degree to which you need to fight for new funds depends upon circumstances beyond your control. If justifying the change requires considerable impact analysis and negotiation with sponsors, you can lose significant Productivity. So Cap with Justification fails to be Predictable because you don’t know what your real cost threshold is, and it fails to be Productive because you have to spend a lot of time in change management.

As much as the problems with Cap with Justification have on Predictability and Productivity, the Zero-Sum model is worse. The Zero Sum model proposes that for every new item or change, something needs to be removed. The problem with this model is that under any real circumstances, you will get LESS than you originally decided you needed. Change will not just off-set previously defined functionality. You will also have wasted the time to analyze and specify the original functionality. You will lose additional functionality in the process of performing impact analysis.

The Solution: Management Reserve

With a management reserve, sponsoring organizations are able to be responsive to change. They know they have both an initial budget and a reserve, and they have the means to make decisions for an application to grow into the management reserve. Service providers make use of management reserve to make specific investments in productivity. Combined, the teams can enter into a contractual relationship with the tools to manage change without losing productivity.

As with most tools, the concept of a management reserve is also not a solution in and of itself. Organizations need to have robust change control models, and they need to have a means of allocating the right amount of funds to the reserve.

Look for more thoughts on how much management reserve to allocate and how to make decisions to allocate it to your projects.

How do you manage change?