How can you implement change management without annoying everyone?

[JoJoGabor]

Read up on CHange Management under ITIL. THis is overly waffley and over-engineered but it gives some good ideas. The best system I have used is:

Use a matrix to determine the risk of the change. Matrix should factor Low Med and HIgh for the two aspects:

Impact of change going wrong
Likelihood of change going wrong

These two factored together give the process for change, ie simple change manager approval or go to full Change control board.

Use dev/staging and prod environments. Developers control their own dev environments, but server team control staging and prod. Stagin is a pure maintained copy of production. There are some tools such as VMware Lab Manager which will help maintain this.

[original PM]

Ha Lol

I get about 5 change requests per day to authorise.

of which 4 have nothing to do with me or my area of the business.

in addition to this the changes get down whether anyone authorises them or not - unless someone spots a major issues and jumps up and down

oh and we got one through this morning retrospectively - change done Friday!!!

so all in all change management is needed but needs not be difficult as has been said clear communication to key stakeholders and it also helps if the people making the change have half a clue of what they are doing and what it will affect.

[krytonsheep]

beaurocracy - it is so often the thing that causes the downfall of companies

Totally agree. That's usually one of the benefits of a recession, the middle managers and their procedures get laid off, leaving the workers (the people with the knowledge) to actually make deciscions and get stuff out the door to make some money.

[vetran]

Make it simple and people use it, make it difficult and people circumvent it.

Seems a bit much to request access to the test system, But access to live seems fine.

Of course you could just do it live and live with the fallout as I saw one big company do. Great fun.

[OwlHoot]

It may also be worth mentioning that risk assessments should be scaled by the number and kind (internal v customers) of users who will be affected if things go pear shaped.

So for example an inherently "low risk" change becomes high risk if it will be made to a web app being used by thousands of customers.

[cojak]

Change Control is unavoidably bureaucratic by its very nature.

The core principles of Change Management are that any change is properly communicated to the relevant stakeholders, the risks and backout plans are managed and the changes have the appropriate level of signed off agreement and authorisation.

Where Change Management becomes a total pain is if the process is poorly thought out and implemented and if there's too much rigour at the wrong levels. A major change to a production system should require more sign off than a simple temporary change to a dev box.

Oh damnit I sound like a process bunny, but I couldn't be much less of one if I tried, but for Change there's no alternative to a decent slim rational process or you get chaos.

WHS..

Why have CM at all? A valid question that you really need to be able to answer for your company. Once you have the answer you can build your change management around your company.

Once you lose your internal map to your infrastructure ("I know that cable plugs into that server that runs that application"), that's the time when you need to implement CM.

But don't simply jump into full change management - you need to educate people as to why it's needed. So work it like this:

• Change awareness
• Change control
• Change management

Nick is also right about risk management, CM can get very bureaucratic - it's important to use a light touch to stop it from getting bogged down by job-worths.

(Oh, and to answer your question - No you can't. There will always be anarchists who'll be ticked because they can't run amok in the computer room the way they used to...)

[OrangeHopper]

I think the most important aspect of change management is the communication of information regarding the change to those ultimately responsible for the system. These people may not understand the code changes made but should have some idea whether your test coverage is good enough or not. If you don't have a formal change control process, you are not being forced to provide this information. There have been many times when I have made the code change and document the testing to have someone, quite rightly, point out that I have missed something in the testing.

Similarly, proposed changes to a live system should be documented in advance and, most importantly, reviewed.

Doing all of this means the responsibility for the change is shared by all concerned.

[sweetandsour]

You have to request a call number, then request permission to install onto the test system (with evidence), then request permission to install onto the live system (with more evidence + user acceptance of test results).
All for things like a single field datatype change.

It is for precisely this reason that change control procedures are are required.

It may well be an obviously low risk change to you, 999 times out of 1,000 you may well be right, but if you make a bad call and take a production system out then that will cost your client money.

I do agree however that the potential impact of any change should be assessed and the level of testing prior to implementation should depend on that assessment. There is no value in jumping through several hoops in order to make changes to unimportant things.

Other than that I can't help but wanted to make a point.

[NickFitz]

In answer to the question "How can you implement change management without annoying everyone?" (which isn't quite the same as the situation you describe) I would say that you can do so by adopting a sensible approach to change.

It sounds like the strategy being put in place is based on adopting a totally risk-averse attitude to change. However, if one is totally risk-averse, then ultimately nothing will ever get done, for there is always some level of risk.

If you can shift the focus from change management to risk management, it might make it easier for simple changes to get done: if it's pretty damn obvious that a datatype change, to take your example, won't cause any problems then the risk is minimal. Alternatively, migrating everything over to a fundamentally different schema is obviously a huge risk. The point is that it's no good having a change management strategy that treats all changes equally; to do so is clearly incorrect, and will obviously create impediments to the smooth running of the organisation, given that things must change from time to time.

Of course, those who exist solely to manage, rather than to produce, will soon find a way to bog down the risk assessment stage of things in "clearly documented procedures". It's best to get out and go somewhere new before things enter that wretched downwards spiral.

The real problem is that management think they are important, when in fact they're just a bunch of jumped-up secretaries whose job is to make sure that the people who actually do the work aren't distracted by irrelevancies. The fact that they are seen as having higher status, and get paid more, is an accident of history, primarily rooted in the way the self-made men of the Industrial Revolution created jobs for their sons where they couldn't do too much damage to the business but would still be called "Sir" by the foremen.

Incidentally, that's why managers always used to have secretaries who actually did all the work. Now they have Excel spreadsheets to do all the work, which they can easily cut'n'paste into PowerPoint presentations that they then show to other managers in order to give the impression that they did the work themselves.

[TykeMerc]

Change Control is unavoidably bureaucratic by its very nature.

The core principles of Change Management are that any change is properly communicated to the relevant stakeholders, the risks and backout plans are managed and the changes have the appropriate level of signed off agreement and authorisation.

Where Change Management becomes a total pain is if the process is poorly thought out and implemented and if there's too much rigour at the wrong levels. A major change to a production system should require more sign off than a simple temporary change to a dev box.

Oh damnit I sound like a process bunny, but I couldn't be much less of one if I tried, but for Change there's no alternative to a decent slim rational process or you get chaos.

[KentPhilip]

Beaurocracy in companies.
While there is obviously a need to track and record software and configuration changes made to live systems, there has to be a trade-off point where the extent of tests gets too high, so causing users to be annoyed by the extra work, and an apparent deviation from principles of "common sense" with the change process.

I am working in a company, and, of her own volition, one of my fellow contractors is busy formalising the company change procedures into a procedure document. Which she got me to write (which I did - only to appease her)

I have to say I am skeptical, and can see the situation where for a period the complicated rules will be implemented fully, wasting a lot of time and causing delay for everyone especially end users, and then the processes will gradually be forgotton about, and the situation return to normal as it was before.

You have to request a call number, then request permission to install onto the test system (with evidence), then request permission to install onto the live system (with more evidence + user acceptance of test results).
All for things like a single field datatype change.

What with the credit crunch I wonder whether her motives are partly to cause me to be slow in getting changes done myself, so making her look better, but more likely that she wants to appear more useful to the company for designing a "change process" that is (apparently) useful to the company, and so make her appear more useful to the company (and more likely to be renewed - I don't have a problem with this).

Trouble is, I hate beaurocracy - it is so often the thing that causes the downfall of companies, and makes the working environment much less fun and spontaneous and effective. A bit like being forced to walk through treacle.

This lady is very good - an asset to the company for sure, so at one level I want to support her. But she also can be stubborn as hell, and rather irritating as a result when there are things I don't agree with.

Anyway, getting round to the question: Can anyone recommend any websites that offer an enlightened approach to the management of the change management process. I want to see whether I can grasp the things she wants included as part of the change process, and convert them into something that is least painful and most useful to those of us (users, managers, tekkies) who have to live with them, but at the same time abiding by the company rules.