The Risk of Change

In my last post, I deviated away from talking about the process to oversee a new software development program and discussed the cost of trying to avoid risk. In this post, I’ll continue this thread by discussing how much of the risk in a software development program comes from the risk of change and how much of the cost of risk avoidance comes from the cost of change management.

Let me add that this is more on-topic than you might think. The purpose of software oversight is nothing more than to manage the risk of failure. The cost of oversight is more of the cost of risk avoidance.

In the last post, we considered how a software development vendor adjusts costs when they have to bear the risk. Let us think about this some more.

Imagine a sizeable fixed-bid project done in waterfall style where every detail is completely specified, where the vendors who are bidding on the project completely understand what is expected. Further, let’s assume that there are no technical risks, that the problem is just about effectively solving a complex business problem. In other words, let’s imagine that no change-management is required. What risks are left?

First, there is the risk that the vendor’s development staff goof it up. They write bad code that does not meet the specifications. I would like to suggest that this is almost never the problem. Bad code can be fixed. It takes time to make fixes, so lousy code affects the schedule. Scheduling is the second real risk. When the vendor management team bids, their cost estimate is an educated guess, and they will adjust their bid upwards to compensate for the risk they guessed wrong. Even when the vendor is guaranteed that there will be no changes, vendors will adjust to ensure they do not take a loss.

In the previous post, I described how I doubled, and then doubled again, the bid to accommodate for risk… and how that still allowed me to outbid, but not defeat, the competition. Let’s assume that the first doubling was to account for the risk that my overnight attempt to size the effort was mistaken. What was the second doubling about? It was about the risk of a change in the specifications.

To consider this, I’d like to use some agile thinking. In the agile approach, the business problem is not rigorously specified. Features are left vague with user stories as placeholders to remind the product owners and the developers to work on this feature in a sprint. User stories are discussed informally with no intervening artifact like a formal requirements document or a specification required. In other words, there is no way to know how much effort is required to build out the feature until the informal discussions are complete. As the developer builds code, they share the results and discuss them and refine the code in a dialog with the product owners. The code is the only artifact that counts.

As the code emerges, there are a standard set of issues that come up:
– the product owner suggests that the developer misunderstood what was said, they re-engage, and the developer goes back to rework the code;
– the product owner realizes that they did not accurately represent the problem to the developer, they re-engage, and the developer goes back to rework the code;
– the product owner sees the result and realizes that there is a better approach than how it was first seen, they re-engage, and the developer goes back to rework the code;
– the product owner sees the result, accepts it, and the user story is marked complete;
– the developer considers the feature and comes up with a creative new approach that the product owner likes and it is accepted;
– either the product owner or the developer suggests a new advanced approach that is composed into a new user story to be addressed later.

Also, note that at any time during the development cycle, new user stories may be added to the queue and prioritized. This capability accommodates new requirements that arise due to legislative changes, technology changes, organizational changes, budget changes and just some good new ideas.

The reader will recognize that each of these bullets represents a change, and any of these issues can emerge even in a waterfall-managed project. You may also recognize that managing these issues is the domain of change management in a waterfall project. In the agile method above, change happens organically. All of the outcomes listed are positive. Consider the waterfall outcomes. First, a debate must occur to determine if the issue is the result of an error that should be corrected free-of-charge by the development vendor (the vendor will have to raise his bid to account for this possibility). Next, changes that are desired by the product owner must be individually costed and a determination of whether the cost in time or money is justified. If the change is included, then the total cost of the project must be adjusted up to account for the effort. Note that anytime a product owner request is denied, the product becomes less delightful. Also, note that after a while the product owner is likely to stop suggesting delightful changes to the detriment of the result. Then, all of the new good ideas are costed and added, or usually postponed, promised into a next release that never comes. Finally, when the vendor builds their bid, they must estimate and adjust the cost to account for the effort to execute this change management procedure.

What am I trying to say here? I am suggesting that when a Silicon Valley product development team engages, they naturally deal with change. There is no onerous change management protocol (there is a protocol, but it is as lightweight as possible with a focus on the minimum viable product in front of them). The development teams are working on a time and materials basis, and there is little, not no, conflict management to resolve change requests. In any case, the conflicts are not contractual.

To be sure, I am suggesting that the main reason that software development costs multiples in the government space is due to an attempt to bureaucratically manage a very dynamic development process that is better managed in an open, iterative and collaborative manner.

Software development cannot be perfectly specified up front. It is just too hard to anticipate every detail, too hard to know where the technical state-of-the-art may be at development time, impossible to anticipate legislative and other changes. It is too hard to account for all of these changes in a fixed-cost bid, and trying to take all of the risks of these changes out up front adds enormous cost to every risk-adverse program.

Rob Klopp is part of the GovLoop Featured Contributor program, where we feature articles by government voices from all across the country (and world!). To see more Featured Contributor posts, click here.