One of the endless challenges for a large corporate software engineering organization is to develop an effective process for handling the steady stream of small changes, fixes and enhancements that seem to accumulate around installed software, both custom developed and Commercial of the Shelf (COTS)—no matter how good it is initially. Typically, these changes can be handled by a single engineer, don’t require much resource or elapsed time and are generally pretty well defined. Users know that they are not asking for much, and don’t, therefore, expect to have to wait very long to get their change request implemented.
The problem for the engineering managers, however, is that each change generally requires considerable impact analysis before it is made (to see what, if anything, the change could adversely affect) and considerable testing after it has been implemented but before the new “version” of the software goes into production (to prove that nothing actually broke). This “engineering process” effort can easily dwarf the core engineering resource requirements as each small change includes all the aforementioned associated “overhead.” From a release manager’s point of view, it’s better and much more efficient to accumulate all of these small changes into the release cycle for large changes—which may well include many of the small changes anyway—and simplify regression testing and verification. But that makes users wait for their “small” changes to get implemented, and that makes them less than happy.
Try to deal with each change individually, however and you can easily create a version control, configuration management and testing morass.
So what to do?
Back when I was helping put together plans for an “application management” practice—basically an outsourcing business focused on supporting installed applications for clients—I looked in detail at what kinds and levels of effort would be involved in doing this kind of work, and how do design and deploy an efficient process for it. Here’s what we found.
There are basically four kinds of “changes” that need to be managed:
Over the range of companies I looked at between roughly 1998 and 2004, there was quite a lot of individual variation in the effort devoted to each of these aspects of application management. But on average the breakdown went something like this:
One interesting statistic that was universal was the growth trend in the aggregate application management effort—it was positive everywhere. This was a major concern (and hence drove the idea of a service to supplement internal resources) because it was clear that the demand for application management was growing faster than the improvements in productivity that were being achieved. Every new application deployment brought with it a “long tail” of application management needs and sooner or later, the demand would exceed the resources available. In many cases, the better an IT department was at satisfying demand for new capabilities, the worse the application management problem became. Even if you never add new functionality, however, the “entropy effect” that requires long term support for installed software will still eat up a lot of resources.
Let’s look inside the 65 percent application enhancement number. We were interested in the best way to manage the stream of change requests and started by looking at how much engineering and associated effort went into satisfying requests on a historic basis (at least where there was reliable data—a far from universal feature of “maintenance” processes). We discovered that there were generally three kinds of enhancements being made:
Remember that the total amount of resources going into these activities is growing steadily (by about 11 percent a year according to the data we collected) but the allocation across types of enhancements remained pretty constant.
Most organizations grouped medium and large enhancement requests into periodic “releases” spaced anywhere from 90 days to a year apart. Users appeared resigned to the consequent delay, and most attention was focused on ensuring that they got into a release far enough ahead of time that their changes would be available by the time they were needed. But the small enhancement requests were a problem for everyone. Waiting a year for a change that took only a day or two to implement just didn’t seem reasonable. Back to our dilemma about what to do.
Turns out that there a several things you can and should do in combination to solve this issue.
Next page: Getting a Handle on System Change Management