Is Technology Change Management an Oxymoron?

Is there such a thing as technology change management that contrasts with change management in any other area? Yes, I believe there is partly because the risks and opportunities of technology are often misunderstood, undersold or oversold (or both).

Also, the discomfort that managers feel about science, technology, engineering and mathematics (STEM) in general adds to their discomfort in supporting and encouraging technology change. (Psychological projection of the manager with limited technical literacy or currency to their staff that they feel uncomfortable with the mooted change.)

By change I mean positive improvements in the technology space, for example, adoption of web interfaces in place of 3270 terminals, today de rigueur in most organisations but a great leap of faith just a few years ago. Perhaps SOA is in the same position today with some caveats I will return to shortly.

The problem of reinvention in the fields of technology and IT is a continuing cause for concern because we all know that the same story can only be spun so many times. He who cries wolf, in this context, will have trouble funding the same kind of project the n-th time around.

For anyone who has been involved in championing the adoption of new technology you will already appreciate that socialisation and process issues are of far greater importance and impact on the organisation and members of the organisation than the technology itself.

While a smaller or greater proportion of stakeholders might embrace the adoption of new technology it is uncertain that such success will follow unless a concommitant effort is made to update business processes to support the new technology.

To the title of this post, is technology change management an oxymoron? More often than not I have observed managers and technical leaders paying lip-service to change over an extraordinarily long period of time, say 3-5 years, when the experience of those who have been successful informs us that change can and should be on shorter time frames.

For example, we will change the way we build applications, with user stories the foundation of agile development, we may be told. But no unit testing or continuous integration is needed at this stage because we don't want to make too many changes at once. Project management has enough problems coping with the new time-keeping system so they don't have to write requirements any more.

We will write our own user stories (or use cases or functional requirements, take your pick) because the customer or end user is unavailable. Have you seen the Dilbert cartoon where the developer asks the business rep what the software is supposed to do? The developer is told to design the software and then to describe what is does.

There is a lot of common sense in agile development that is matched by almost as much whining about the purported failings of earlier approaches. In another post I will examine how agile approaches match up with the seminal Waterfall method from its original publication in 1970, including iterative development, customer involvement, and early testing.

The big difference is that when we are talking about agile development we are usually referring to toy systems compared to those in defence and space that Royce was working on. Modern project management practice, including software, should have evolved from such successes as the space program, defence missile, telecoms and various other successes.

Dare we be so conceited as to pretend a few rules of thumb are adequate? Parnas gives a solid argument for pretending to have a process game even if real-life pragmatism rules out a perfect score.