To err is human, to really screw up you need a computer. An old
adage, but still relevant, which is why change management might be
useful.
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.
"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