How to Manage Application Enhancements - ' Getting a Handle on '

First, recognize that a lot of these requests are for things that users could do for themselves if they had the right tools, a little training and support and a "clean" information environment. Changes to reports, even changes to web pages and transaction screens can often be handled by the requestor, if the information management environment is robust, the platform architecture is solid and the right tools are deployed. IT departments don't seem to want to take this route very often (at least I have seen a great deal of resistance to it) because the necessary cleanup efforts almost always require medium or large changes to be made, and there's no budget for such efforts (or willingness to admit that they are needed). But the productivity gain from an effective self-service strategy is significant, and the improvement in customer satisfaction equally worthwhile. In addition, doing some things themselves soon teaches users to assess the real value of everything they ask for.

Secondly, many small changes cluster around specific sections of application code, so an investment in improving these code sections to aid understanding pays big dividends. Application understanding is the largest single engineering task associated with making a small change to an installed application. Over time, the engineering effort can be reduced by up to half.

Thirdly, extensive automation to the testing, code management and build processes that support small changes can trim the total effort needed to deliver a small change by over two-thirds.

Fourth, implementing many of the techniques of "extreme programming"—especially pair programming, test-driven development and refactoring—helps the staff assigned to the small enhancements process to be both productive and quality focused. It might seem foolish to assign two engineers to an effort that's only expected to take a few hours, but because code understanding is such a critical part of the process, using two people actually speeds things up. It also gives you the opportunity to pair an experienced engineer with a novice, broadening the pool of engineers who understand the code.

We implemented all of these strategies (to the extent possible in different client situations) within the applications management practice and for a number of clients and although the mix varies somewhat from place to place, the overall effect is to support a continuous stream of small enhancements that can be delivered quickly at high levels of quality. And a lot of happy users.

Of course there are some unanticipated consequences as well. Because we effectively reduced the effort required to implement a small change, many of the smaller "medium" changes got scoped into the "small" category, shifting the proportion of changes from 10 points to closer to 20. We also had to invest in additional support desk resources and user training to allow the "self service" model to work, and to collaborate with HR departments to assess which end-users simply couldn't learn to use the new tools safely and effectively.

But overall, the efforts were extremely worthwhile and pushed off into the future the day when 100 percent of engineering resources will be needed to enhance what we already have deployed. We'll get to that problem a little further down the road.

John Parkinson is the former Chief Technologist at Capgemini and has advised hundreds of large companies on their IT strategies.

1 | 2