Page 1 of 1

How to avoid making the process bureaucratic and heavy?

Posted: Wed Mar 02, 2011 10:22 am
by Hena
How do you make sure the change process doesn't get bureaucratic and heavy?
It seems no matter what we do, people will complain that creating RFCs is too much paperwork, but from a change mgmt and CAB perspective, we feel that we need more information to assess risk properly. How do you find the balance? If we have few questions or requirements, we don't get a good picture of the actual change, and if we ask more questions to get a better understanding, then people complain, take shortcuts or simply don't submit RFCs (and don't get caught). The biggest challenge I, as the change manager, see is that people give one line answers just to complete the RFC as quickly as possible. CAB keeps on complaining that the RFC quality is not good enough. I feel that I'm babysitting the users (who are the CAB member's staff).

I want to help people and make the process smoother and creating RFCs easier without introducing any risk. I do monthly training, workshops, I have several user guides, templates for different types of changes, and other documentation but in this org nobody cares about those things. I'm not getting much help from management either so I feel like I'm pushing the elephant up the hill by myself. So again, how to I make the process effective and get people onboard? Btw, according to our stats change management is doing great (avg success rate is 98%), but I know that's not the true picture. I know there are many unauthorized changes because some people can't be bothered to follow the process. How do I find the balance?

Posted: Thu Mar 03, 2011 5:34 am
by Diarmid
Are the right people making the change requests?
Are you asking the right questions?
Is your CAB composition right?

If changes are going ahead unmanaged:
is the CMDB being updated? - does this not point to the culprit?
are you auditing the CMDB? - do discrepancies point to unmanaged changes?

Are people invited to CAB to speak for their change request?
Do the requesters understand that the issues are risk, value, authority, scheduling,resourcing, service disruption, testing, regression, etc.?

Posted: Thu Mar 03, 2011 9:54 am
by Hena
We don't have a CMDB to rely on. We operate on a trust/honor system. The CAB members are managers for various areas within IT who come together and collectively assess risk. It doesn't matter what questions we ask, because people who don't like RFCs will try their best to finish the RFC as quickly as possible (one-liners to all questions). The risk assessment questions are always answered in such a way that the calculated risk level is low. In their eyes, the changes are always 'low risk, no impact, no big deal if it fails' type of changes. Sometimes I wonder if it's pure luck that our success rate is so good compared to how understated our RFCs are.

CAB doesn't actively chase down people who score their RFCs as low risk changes, and I'm not always able to challenge their RFC on a technical level.

Posted: Thu Mar 03, 2011 12:28 pm

In a word, you are screwed.

You dont have a change management process in place. You have a request processing centre instead.

What level of documentation regarding CM do you have

Do you have a CM Policy document defining what changes and what areas are covered in CM
Did senior mgmt sign off ?
Did the document get distributed ?

You are almost due for a major outage due to a failed change

The other thing I see is I dont see what kind fo changes you are bringing to the CAB

If the team for service X is NOT important to the users, then why is there a team supporting that service.

You need to take the action and go to the senior mgmt and ask

What is the impact if this application / service is lost ?
Can you afford hours, days, weeks of down time due to failed changes ?

You need to do this for the mmajor apps / services

Posted: Thu Mar 03, 2011 2:42 pm
by Hena
Well, I wouldn't say we're screwed but it's not perfect either. We have people who follow the well documented process diligently, we have people who have to follow process but don't like it and don't want to like it, and then we have people who follow process if they have to but find ways of not following process if they can.

I'm not concerned about the level of documentation; we have everything from process guide, flow charts, RACI charts, policies, operating procedures, manuals, job aids, training guides etc. There is a semi-annual review of the documentation where the service manager signs off on the documentation (personally, I think her boss who is the process owner should sign it off). All the documentation is easily available on our SharePoint site. Any changes to our policies are also communicated through email and at our meetings.

Major outage due to a failed change? That may very well happen.. even for a change that has gone through the process. We've had change management for 4 years and are continuously improving, but we have had no disaster yet. The types of changes brought to CAB are of course changes that are submitted for approval with risk level medium, high and critical (lows are approved by the change manager on behalf of CAB). I am not concerned with the questions we are asking - I've compared our RFC against ITIL books and other guides and found we're definitively asking the right questions, but as we are maturing we are realizing there's more 'nice to have' type of information that we want to include in the RFC.

The CAB members (IT managers) see the value of the process, the challenge is to get all the IT&S support staff onboard (project teams are following the process). I don't think the issues we are having are unique... most tech guys hate documentation and paperwork and want to do least amount of work on the RFC. Our RFC is constantly evolving to but also growing in number of questions - which is the concern I have - I don't want it to be a reason why people want to avoid the process.

Posted: Fri Mar 04, 2011 3:42 am
Thanks for the more detailed information. This sounds a lot better than the picture I had seen based n what you first posted

I do have a couple of questions

Do you have 1 CAB meeting that deals with everything or several CAbS dealing with specific subjects

The reason I ask is that depending on the tech/service is the need for detailed changes

Network changes are pretty straight forward - open / close port, , add / remove IP range, add / remove DHCP Range, add network kit, remove kit, upgrade IOS,

Most of these should be CAB-less - classified as standard changes - once you have a history of work and successful deployments

Back Office servers are the next complex. Not in the servers itself but the service they provide - which requires planning and foresight becuase of the impact; however, becase normally these are in pairs, farms etc and the server work may not cause service disruptions

Front office equipment is the next complex - these are the desktops and laptops, PDAs etc. These are both simple and complex in changes. I handled these by having regular scheduled maintenance windows - Mid week, mid month - where certain changes are always done

THe most painful, bureaucratic and process anal is applciation change management - especially if you have a run and maintain and a development arm for the applications. These require the higher level of control and more level of detail

While techie do not like paperwork, me included, I usually point out that paperwork is th eproof and protection for the techie if things go wrong

Posted: Tue Mar 08, 2011 10:49 am
by Hena
Yes, we have one CAB meeting per week that deals with change requests by risk level and not by CI/ Service.
Network changes are typically low risk changes that rarely make it to CAB unless there's service disruption to high or critical apps.

Changes to back office servers - that's where the guys may feel that creating RFCs is a pain because in their eyes, there is no outage, we have redundancy, we may or may not have tested it (depends if they have test environment), we are doing it during the maintenance window, and we have the IT service owner's approval. Too much paperwork for what they consider a piece of cake, but can have a negative impact if things go wrong.

Front office equipment changes are always tested and planned properly. The support staff for this area are pro-change management and follow the process properly.

App support team is great to work with because their manager is on top of things.

The bottom line is that I want to help them "love" change management. I want to make RFCs more pleasant than it is perceived (beyond the templates I have created). I want them to stop resisting change management. I want them to embrace change management. Nobody cares about the documentation, training sessions, workshops, templates etc. :(

Posted: Wed Mar 23, 2011 9:55 am
by markhayes
I find that putting out reports showing adherence to process and impact of changes on particular services, maybe highlight which areas are creatring the most process failure chg or Emergencies then extrapolate this out into incidents caused. Make a report pack, management love that, then they (Hopefully) start trying to improve things, especially if there is a bit of competition

Re: How to avoid making the process bureaucratic and heavy?

Posted: Wed Apr 06, 2011 5:52 pm
by TomG
Hena wrote:How do you make sure the change process doesn't get bureaucratic and heavy?
Although I have top down buy-in and support in my current organization and there are some great key folks with the right attitude and willingness to make change management a success, I'm still running into situations where some department heads who are entrenched in the "old" way of doing things; silo'ed approach with no process bridging or integration understanding or willingness, exist.

Using strategies outlined in MOC (Management of Change, not Change Management there's a difference) I've been able to bring them past the stages where they are overwhelmed and resist the changes initially using interpersonal techniques that basically help me deliver the change to them in a way that makes them feel they came up with it in the first place. This is very difficult and takes a while. Key ingredient here is to drop hints during a situation where they are pressured to restore service and learn from the event for the future to avoid having it reoccur. Then place some resistors, organizational roadblocks (can't get the hero to fix it) and process roadblock (can't lean on that process crutch) that prevents them from bypassing your new process. Once the situation is resolved and they've followed your process, have a follow up discussion during the post implementation review with the CAB and find a way to get them to provide feedback on the situation while steering the discussion towards the efficiency and effectiveness of the process they had to follow also mentioning how the oversight and preparedness as a result of following this process has built up the confidence of those looking at IT as a trusted partner (aka the biz).

This is only one example of handling this situation however it's always different and involves a lot more than what I'm typing above. The more times you practice doing this the more walls you break down over time.

A key reminder is to find out what are these people's drivers that push their agendas and "show" how your process aligns with their agenda.

If it doesn't at all or you can't figure it out then you might have to fall back on the compliance and regulation hammer and hit them over the head a few times assuming you've got top down organizational support.

If you don't have support then you probably lost this battle for the time being. The good news is that if this is an issue then the folks who are resistors to the process are usually causing concerning issues elsewhere and eventually, if you're tracking all the right information in the right way (you've got to figure this one out as it's different everywhere), their involvement with the process will be reviewed by an annual audit which should point out who or what the resistors are. Once that occurs and the auditor's report looks unfavourably in the eyes of those that care within your organization there is a good chance you'll see them come around.

Have patience.

Man I type too much, sorry folks.

Posted: Tue Apr 12, 2011 11:39 am
by ChasingSleep
Great answer TomG.

This is a Transformation project. It has nothing to do with ITIL or Change management. It could be Cobit, PMBoK, Lean, Incident Management, Project Management or whatever you decided to implement.

You would fail miserably, as you are doing now.

In order to transform the way an organisation works, it takes time, a well established strategy and top management engagement.

I suggest you google for "management of change" or "organisational change". You should find a lot of interesting ideas. Next, get yourself a specialist in this domain. He will help you to get where you want, or at least he will tell you not to loose your time if you do not have what it takes!

One last comment:

You said: "I want to make RFCs more pleasant than it is perceived (beyond the templates I have created)."

YOU have created? Would you like to be forced to do what others tell you to without even having the chance to contribute?

Think about it...