Project Management Book

...chapter 2 continued

Let us turn to the other end of the spectrum - making small enhancements to existing IT systems. At the extremes there are two ways of dealing with them. At one extreme is the ad hoc approach: each time someone raises a request to enhance, it goes to IT, a programmer dives into the code, makes the change and it goes live whenever it's ready. The obvious benefit is that it is quick - assuming you have enough IT guys waiting around. Also, it doesn't require much management.

The alternative is to bundle, say, 20 enhancements together into a project - again let's call it a release. During a year perhaps there will be four such releases on February 1st, May 1st, August 1st and November 1st. The rule is that the live production system doesn't get changed between releases except where there is an overriding need. What might be the benefits of this approach? It's certainly predictable: the users know when each release is coming and can plan around them in terms of testing resources, procedural changes and so forth.

IT will probably do more thorough testing. There's an old adage amongst programmers: "it's only a one line change, it doesn't need testing." Into production it goes and crash, the live system comes tumbling down. You can't spend a week doing safety check, regression testing of a one line change. But if it's part of a quarterly release it's much more likely that there will be proper regression testing.

Economies of scale: it can take a programmer days to understand a complicated program before he changes it. If a number of changes are made at the same time the understanding overhead is borne only once. Doing those changes ad hoc would have meant re-understanding the program each time.

The sheer act of promoting updates to the live environment costs money - do it every quarter not every other day!

"If it works don't fix it." Every time a change is made to the live system there's a chance of a mistake. If the system is working acceptably leave it alone.

One of the biggest benefits of the release approach to enhancements is that some enhancements simply don't get done. Doesn't sound like a benefit? Consider this: how often does a user shout loudly "I want this changed, it's really urgent and important!" The change is made but a week later the user can't even remember why he wanted it. With a release approach there is more scrutiny of each potential enhancement and ones that aren't worth doing are weeded out.

Bottom line, it's cheaper to do enhancements as releases: you're trading the speed of ad hoc against the efficiency of releases.

Again, what is right for you will depend upon your environment. In a rapidly moving web-based retail environment updating the web site daily may be worth the cost, though even here grouping changes into a weekly update may be worth considering. If you look after the system that administers your company's pension scheme perhaps an annual release is best with changes between releases only if they are absolutely essential.

How does this release approach to enhancements work, what is the process? Sometimes it works like this:

• User sends enhancement request to IT
• User never hears anything about it ever again

We should be able to do better than that. Most IT groups have a service level agreement (SLA) with their users. One item in the SLA might be: within 3 working days of receiving a request to enhance we'll get back to you with a ballpark estimate. This ballpark estimate enables the user to determine whether the enhancement would be worth doing given the cost. If so it becomes a candidate for a future release. But who decides which release, if any, it gets in to? All too often in the past IT decided and the perception was that IT didn't give the business what the business asked for and needed.

There is another way.

The IT systems that run the business are company assets. Assets need owners. Suppose the Marketing Director becomes System Owner for the company's order processing system. What responsibilities would he have?

• Account to the Board each year for the running cost of the system - this tends to stimulate efforts to reduce running costs

• Be accountable for the system's legal compliance - if the system puts the company in breach of the law somebody has to stand up in court.
• Be accountable for every penny spent enhancing the asset - decide which enhancements get done and which don't get done.

In a small company the System Owner can personally decide which enhancements get done but in a large company he will be too senior to do that so will delegate to his "Owner's Representative" - a less senior business person. The Owner's Representative prioritises the enhancement requests and, for example, recommends if only one could be done which one it would be. It becomes the Owner's Representative's job to recommend which enhancements get done in which release. Of course, genuinely urgent enhancements and fixes will short circuit the process and get done now as an exception to the "no changes between releases" rule.

Where the process works best the Owner's Representative meets informally with his IT counterpart every month or so to discuss what's coming down the track and what the priorities are. IT will suggest which enhancements it makes sense to do together for technical and cost reasons. Their discussion will include consideration of the IT resource plan (see Fig 3).