Everyone knows that change exists but some organisations are reluctant to accept it as a standard part of the IT environment. They refuse to accept the need to formalise the way they handle change management.
A change to the IT infrastructure can be anything from upgrading a server to installing new software or adding a new desktop PC or email account for someone who has just joined the company. It can cover the whole spectrum from something relatively trivial through to an alteration which could bring down the entire system.
Changes happen every day in every organisation. Many IT departments just go out and implement them without formal accountability. If it is just a question of adding a new e-mail account, a formal approach may not be necessary but if a new e-mail or web server is being replaced this could turn out to be a huge issue if the project goes wrong.
Change is an important integral part of the IT Service Management toolkit which ultimately ensures good quality service for customers. Change management is closely linked to the Incident, Problem, and Configuration and Release modules.
Success and change go hand in hand. Change management provides a pro-active and integrated approach to change control that minimises business risks and promotes strategic planning.
So, why do so many organisations not bother with formal change management? Why is everyone not doing it? Our experiences reveal a substantial minority of organisations who are not carrying it out in a formal, structured and consistent way.
Small changes that can cost big bucks
Some private and public sector organisations conduct change management informally: a verbal or e-mailed request comes in from a member of staff or is referred by the IT help desk, and time for the change is scheduled. "Right," the decision is announced. "We'll swap over the e-mail server at 7 o'clock this evening." There is nothing wrong with this approach if it works but if staff come in at 9 o'clock the following morning and cannot access their e-mails, that is serious.
The problem may have been caused by human error and not lack of a formal change management system but without a proper structure and documentation the problem can come as a total surprise to everyone because they were not notified in advance. Internal communications are an important part of change management. If you are a big business, where people buy from you on-line this can be catastrophic with losses of substantial sums of money. There could be similar embarrassments if you are an airline whose check-in system goes down. Small changes can cost big bucks.
Change management, however, is much more than effective internal communications.
Change management should include an impact assessment. IT managers should ask themselves; "If we implement this change what kind of effect is it likely to have on the computing infrastructure and the overall business? Is this our main e-mail or Web server? If so, maybe 7 pm isn't the best time to do it. Perhaps we should do it at a weekend? What kind of testing do we need to make sure the procedure goes smoothly? What back-up plans ought we to have in place?" It can be a much more complex process than just sticking more memory in a server.
Releases of new software with bugs can have catastrophic impact - so too can changes which might seem at first glance to be trivial.
IT managers may say they lose sleep over introducing changes but this discipline is more than just about expressing concern. It is about impact assessments, having back up, testing and contingency plans in place, and making sure the right people are aware of what is being done - and the implications.
Formal change management begins with the logging of a â€˜Request for Changeâ€™ from someone who believes an improvement is called for. Ideally what happens afterwards is that the request goes to the change management team which, after considering if the change is really necessary, categorises and prioritises it.
Depending on the scale of the alteration they will move to the next stage to set up the change itself or refer it to a Change Advisory Board (CAB) made up of interested parties such as the operations manager and business managers. The CAB will go through all changes requested that week or month and decide which to accept or reject, or seek more information. Changes authorised by the CAB or change management team are then forwarded to the team which carries out the work, first drawing up testing and back-up plans.
Eliminating the errors
The most common mistake in adopting formal change management is to make procedures too bureaucratic. Some documentation is essential but some organisations make things so complex that people just stop doing it. There does not have to be a plethora of sign-offs and authorisations; there should be a balance between having the right controls in place and getting strangled in red tape.
Another mistake is not appreciating that resources are needed to handle it. Good organisations tend to have a change manager or change management team who retain ownership through the whole cycle although they can have other roles as well. Some organisations operate effectively without a dedicated change manager but need to be more careful because the system is more fragmented and there is no single person or team keeping their eye on the big picture.
Some of the older established teams, like mainframe or server support, tend to be better at change because they have been doing it for a long time. Newer teams, like those dealing with software or web applications, are often less structured since they are working in a particularly fast moving environment. But change management is equally important for everyone.
Some industry sectors, like pharmaceuticals, are forced to adopt change management. Manufacturers have legal reasons to adopt it.
The IT Infrastructure Library (ITIL, internationally accepted guidelines for Best Practice in IT Service Management) gives useful guidelines. A good ITSM software solution can help by supporting the process and automating many of the processes and data flows.
Fighting the fear of change
People are usually fearful of change and reluctant to adopt it, particularly if they are being asked to write more reports, so they need to be persuaded of the benefits. IT managers need buy-in, to get people on their side. "Hearts and minds" must be won.
Change management can embrace a large number of different items but they do not all need to be tackled simultaneously. Take a phased approach; if the desktop team are keen to do it, start with them, then move on to the more reluctant sections who hopefully by then will have seen the benefits.
Do not forget the metrics. You can extract a great deal of useful management information from change management reports - for instance, how long people are taking to carry out changes. One of the disadvantages of not having formal change management is that staff could have been working all day to implement changes but no one knew because it was not documented.
You can also document areas causing the greatest problems. Why are you always swapping out that type of server? Maybe it does not suit the environment or is old. So why not just replace it and save everyone a lot of trouble?
At the end of the day you want change to happen without the end-user or other customer being aware of what has happened but appreciating the benefits. That should be an aim which never changes.
Never Say No To a Client
Change is Bad
It's often said that Salespeople never say No. And it's often true - whatever the customer asks for, they invariably say Yes, we can do that. And Project Managers generally hate that as it paints us into a corner where our projects are not under our control.
o Saying Yes leads to Change
o Change leads to Lack of Control
o Lack of control leads to Suffering (which is a PM technical term for missing deadlines, budgets or quality objectives)
But as a client-facing PM, you soon learn that to say No is just unacceptable to most clients. It's seen as pure stonewalling; that you're not prepared to be cooperative, or (worse) that your team just isn't competent. Either can cause you serious problems in your sponsor relationship, maintaining which is one of your top priorities.
Change is Good
On the other hand, saying Yes to client requests tends to result in more work. In the other Yoda mantra:
o Saying Yes leads to Change
o Change leads to More Work
o More Work leads to Happiness (another PM technical term for Increased Project Revenue and Gross Profit, which you're often responsible for)
Balance - a Neat Trick
Balancing between stonewalling (pretending that nothing can be changed and rejecting all proposed changes) and accepting all proposed changes and causing major project control problems is a tough act. Trying to work it out mid-project is even tougher. Trying to work it out on the hoof is nigh on impossible. Here's the basic magic formula - if you take nothing else away from this article, take the following sentence. Put it in your wallet, stick it to your monitor, brand it on the back of your hand
Use The Sentence even if the client request doesn't make sense. Some requests will, some won't, but The Sentence usually ends up with one of 2 results:
1. Client backs off
2.Client agrees to more time, more money or lower quality
In either case, it's a useful holding action that then lets you wheel out the Change Control Process that you thoughtfully included in your standard statement of work.
Change Control Process
This is a process to consistently handle the inevitable Change Requests that crop up mid-project, ensuring that the good ones get through, with associated adjustments to the cost/time/quality Holy Trinity, but the bad ones don't. You maintain control of your project, you're contractually covered, the client gets what they want, but pays for it if necessary.
What is a Change Request?
This one's easy: A Change Request is any request that changes the
Do We Need a Change Control Process?
Again, easy. Yes. Every project must have a change process. Every change request must use it.
Time and time again, I've heard inexperienced clients, developers and sales people starting to say things like: This project is too small/rapid/ low-budget to have a change process. or This change is too small to go through change control. To which I invariably respond: Only if the project policy is to refuse all change requests - which is of course a change process, just a really simple one to operate - or find yourselves another PM.
Strict? Yes. But here's why: because Project Requirements are a contractual document, any change to Requirements is also a contractual document. If the appropriate project authorities (the Sponsor and you) haven't signed up to a Change to the Requirements, you will fail UAT, your project won't be accepted by the sponsor, and there's a good chance you won't be paid.
Here's an example: a stakeholder has a wizard wheeze. It's a pretty simple change to the requirements and won't take much effort to implement. Realising this, the stakeholder takes it straight to one of the developers, who codes it up and tests it in a couple of hours. Doesn't break anything else, doesn't noticeably impact timescales or budgets. But come UAT, the Sponsor notes that the delivered site doesn't match the requirements, and rightly asks Where did I agree to this? You cannotYou didn't with the enevitable followups of When did you agree to it?Who died and gave you authority over what I want. That's A Bad Place to be. allow your project to get to that point, because the only honest answer is and
You don't need to follow the same process for small CRs as large ones, though. You can use a light weight process for small CRs, as long as the 2 processes are documented and agreed, including - vitally - the definition of a small CR.
Sample Change Control Process
Here's an example of a simple Change Control Process. It's not the only possible process you could use, but it is in line with most PMI- compliant methodologies, so would be generally accepted by most professionally run projects.
1. Someone submits a CR. You need to agree and document who is able to do this.
2. Assess the CR to see if it's worth investigating. Here, you need to work out how long it's going to take to analyse the impact of the CR, and compare that with the projected benefits. This is a quick preflight check to weed out the obvious non-starters. If it's going to take a week just to work out how much change is involved, and the benefit is tiny, or there's not a hope in hell of it being accepted (for example, it changes the objective of the project) then this gets thrown in the bucket of CRs that are a waste of time from the outset.
3. Document and Communicate. Essential for all outcomes of any process.
4. Analyse the impact.If we implement the change, how is it going to hit the Holy Trinity? What's the Risk? Answers the questions:
To do this, you will possibly need to replan a large chunk of the project - schedules, WBS, staffing, budgets and all. You may need time from developers for them to contribute - time they would otherwise spend delivering the project.
You must have allowed for this in your original budget and schedule, and have it explicitly written into your contract. Avoiding doing this unnecessarily is why you had the pre-assessment in step 2.
5. Document and Communicate
6. Approve the CR? This is where you take your assessment and put it in front of your sponsor. It's then the sponsor who decides whether the CR should go ahead, accepting the changes in Schedule, Cost, Quality and Risk. If the sponsor decides against the CR, you've been co-operative and (I hope) objective in putting it forward, and you're not the one saying No.
7.Document and Communicate
8. Document and Communicate
9. Implement Change