Change management: What could possibly go wrong?
- Posted:
- 00:00 06 Jun 2001
Change is a constant in IT departments, and managing it a recurring headache for many managers. And, as IT analysts Gartner Group puts it: "Change management is fundamentally about understanding how change affects organisational behaviour. Because those behaviours are rooted in emotional and psychological responses, many leaders find them difficult to manage.
"Understanding that there is an underlying consistency to many of these behaviours helps demystify them, so they can be proactively managed. Effective change management strategies incorporate an understanding of these common behaviours in deciding change initiative priorities, scope and scheduling, and they include explicit activities to manage the phases of these cycles as they occur throughout the change execution process.
ADVERTISEMENT
"Change is hard, painful and expensive. Therefore, even positive change is resisted or threatened by a loss of momentum when difficulties start to arise. If the initiative is truly an imperative - that is, if the gains to be achieved substantially outweigh the pain of the transition and/or the costs of not proceeding - then commitment will inevitably follow." Of this, a rough but succinct translation might be "your programmers ain't going to like this; not to start with, anyway".
Modular programming
Frank Carstairs runs 12-year-old Wokingham based consultancy Tecfacs, was previously dp manager at Whitbread, and cut his computing teeth on the Leo III in the late 1960s.
Change management was already seen as a challenge, and he recalls attempts to introduce 'modular programming' which was then perceived as the up-to-the-minute solution. Rounded up for address by the visiting firemen from consultants Urwick Diebold, the troops brightened noticeably when programs were resembled to "plates of spaghetti"; only to revert to sullen torpor as soon as it occurred to them "this was a description of the way it shouldn't be, rather than the other way round".
Preaching to programmers on control, planning, documentation - indeed, even the merest annotation - is, of course, as rewarding a task as trying to explain vegetarianism to a tribe of cannibals. Frank Carstairs is aware of this - "but you don't need to sort out our own code too many times before you start to see the point" - and his company operates rigorous rules on how and by whom changes may be made.
"It is," he says, "like any system - whether it's in a computer or it's on paper - it's as good as the control mechanism, the people using it, and your ability to enforce it."
Has Tecfacs tried control management software? "Yes."
Was it thereby impressed? "No - it was inordinately expensive, it didn't work very well, and we finished up not using it because we found our own system infinitely superior."
Do Tecfacs programmers welcome any sort of control? "Yes; once you've discovered there's a structure which enables you to fix someone else's fixes without the risk of the whole thing falling over, you can get hooked."
Serena Software bills itself as "a global software and services company dedicated to providing its customers with infrastructure software to manage change to e-business applications", and 'the only company focused on managing change to application software and Web content across the multi-tier, multi-platform architecture'. Vice-president of European operations, Ailish Berry, reasonably points out that "almost every outfit with a computer has some sort of control system, even if it's just getting things signed off on bits of paper", but readily concedes that developers and programmers can be resistant to encroachment on their cavalier encampments.
Software change management, says Berry, can be "a bit like insurance - you never know the real value until you've had a problem". British Airways, for example, experienced a problem whereby a software fix meant passengers had to cart their luggage to the plane, rather than entrusting it to the check-ins. BA was unavailable for comment on this, and its ramifications - did less luggage get lost, for instance - but Ailish Berry's point is valid; had BA been able to track the change or, better still, hit a button and revert temporarily to the previous system, its punters would have spent less time trailing around with their luggage. Serena's change management software boasts audit trails and the ability to go back up to 99 versions which, as Bill Gates once memorably remarked of 620K memories, 'should be enough for anyone'.
Ailish Berry's views of change management are straightforward and are not, in principle, unattached to those of Mr Carstairs. "What it does," she says, "is takes away the right to update source code from everyone except the authorised 'Changer' - you may be able to read the code, but there's no way you can change it without going through the defined channels - yes, you could say it's a control on the anoraks, but it's in background. Almost everyone hates it at the start, but it really does automate a lot of tedious tasks, and they tend to love it in the end."
Martin Saunders is enterprise management product manager at Computer Associates and agrees that, while introduction of change management usually meets initial resistance, "it's not long before developers get to like it - they can find out what's really going on, which isn't easy in a conventional environment where you might have 20 or so people having a simultaneous crack at the same problem, and it's much easier to analyse what went wrong. You could say it reduces stress levels quite a bit, and even developers like that.'
Thenon was founded in 1991 by managing director Nigel Wright and specialises in change management systems for the iSeries, in which area it claims market leadership. Wright concedes that software development "can be manually controlled" but points out reasonably that "if you were building a car, it would be commercial idiocy not to automate the process".
The coming of e-business, he emphasises in company with other interviewees, has meant there is "quite simply less time available - the days when you could spend six months designing a system on the back of a fag packet, and then take another year to develop it, are long gone - it's a tight, well controlled methodology that lets you plan future development in ways that save you both time and money."
Automated development tools, he estimates, "are probably in at 20% to 30% of development shops, 10% to 15% rely on third parties, and the rest probably think they don't need it because they haven't got it."
Nigel Wright was not alone in his opinion of IBM's change management offering which he considers, "Not commercially viable - it's really there so buyers who've asked if the kit has change management can tick the 'yes' box." Big Blue would not be drawn, but may well take the sound view that the best box is the one with IBM printed on the side; whereupon punters are doubtless welcome to install any change management systems they see fit.
Case study - Reckitt Benckiser
In 1998 Bart Couvrer arrived at pre Benckiser merger Reckitt and Colman and inherited a pan European system, plus a spread-around accumulation of some 25 programmers and 10 analysts. The system was "mainly Bpics and/or Asset AS/400, documentation was pretty minimal, and there were chunks of source and object code everywhere". Mr C went for Thenon's change management system, which he has never regretted, although he admits the preceding six month manual clean up - "if you're going to put in a change management system there's no point in feeding it a load of junk" - was not an experience he would care to repeat.
Change management, he says, is a simple enough concept, but actually making it work is quite another matter. Changes are controlled by allowing read only access to code, and changes may only be applied after compliance with all requirements: "You set your own standards, but, having done that, the system should protect you". Bart Couvrer estimates that the use of change management systems saves Reckitt Benckiser a "conservative" £50,000 a year.
Down side? "None that I can think of although, if your operation was small enough that you could clean up the mess manually in a month or so, you might be as well off sticking to a conventional system."
Summary
There is nothing new in the notion that those empowered to muck about with one's computer system code should be subjected to some kind of control. This has traditionally been legislated manually, but change management systems are becoming available in every arena - from mainframes to iSeries and networked PCs, from Linux to Windows2K and NT - and are even said to be gaining popularity with programmers.
Mike Hardwidge
