Dale Vile, originally published on The Register
We at Freeform Dynamics have been running surveys and interactive workshops with The Register’s readership since 2006 on a wide variety of topics. Looking back, we see the same themes coming up time and time again.
One of these is the perpetual problem of IT staff feeling they are not able to respond quickly enough to change requests from the business.
Many tell us they see an increase in the rate of these requests, so we thought we would look back over relevant studies and pick out some of the common obstacles to effective change management that seem to dog IT departments.
As with all such exercises, you can’t help thinking that the results are all pretty obvious, but since the problems don’t seem to be going away we thought it was worth listing them.
Disjoints within the business
This might sound like it has nothing to do with IT, but many IT departments are on the receiving end of independent and often conflicting change requests from different parts of the business.
What with political shenanigans between business managers, the lack of a coherent view of overall priorities and limited funding and resources for IT, the handling of change requests can become either a lottery or a question of who shouts the loudest.
Sometimes business stakeholders and IT don’t talk to each other enough, and sometimes they talk but fail to communicate.
Take the simple example of a request made for something that is technically impossible. IT proposes an alternative way of dealing with the requirement that can be delivered quickly and economically, albeit with some caveats.
The proposal is approved by busy stakeholders who either don’t look at the detail or fail to understand its significance. When the change is delivered, the response is: “That’s not what we asked for.”
Too little process
If there is no clear definition of how change requests are captured, categorised and prioritised, then things will be missed, dealt with in the wrong order or allocated to the wrong team.
And if there is then no defined way of implementing requests, IT staff end up continually reinventing wheels or making it up as they go along.
All of this translates to increased overhead, cost and risk, as well as to a general lack of responsiveness.
Too much process
At the other extreme, we see IT departments almost paralysed by bureaucracy. Every request, regardless of its magnitude and urgency, is forced through an intensive process of form filling followed by review and approval by every man and his dog.
IT staff are required to document all activities to excruciating levels of detail, and everything is analysed and measured on an hourly or daily basis.
While backs might be covered and evidence generated to support the blame game, the price in terms of efficiency and morale can be high.
Too much demarcation
Specialist knowledge is important in IT, but when developers don’t coordinate with operations teams, and server, networking and storage guys don’t collaborate effectively with each other, demarcation gets in the way of efficient implementation of change.
The “do your bit then chuck it over the wall” approach results in activities happening serially rather than in parallel.
Then tasks go back and forth to deal with things that were overlooked in the first place or done in ways that cause problems for other teams.
It is notoriously hard to justify investment in management tooling as stakeholders often fail to understand its connection to effective service delivery.
Add a fear of automation, natural inertia or simply an unawareness of alternatives, and the consequence is that many IT teams try to do their jobs using a disjointed mix of tools of varying ages, capability and openness.
Poor automation and the time spent keeping systems in sync, often manually, lead to unnecessarily high costs, slow response times and increased risk.
This list is by no means exhaustive, and we are sure you can come up with other examples of impediments to effective change management from your own experience. Sometimes, however, it’s worth taking a step back and checking some of the basics.