Configuration Management / Change Control

Mark · 17-02-2011, 23:02

Acknowledging the fact that the team (and the company) I work in is (probably like most others in the sector) notoriously bad at internal documentation, and having a scary thought (involving a bus) on the way home, has led me to one thought...

Change Control

I don't want to do anything that's so onerous that it gets dumped after a week, and I don't want to reinvent the wheel.

So is can anyone point me towards anything in any of the standards that might help guide me towards a workable implementation? What I know about things like ITIL would probably fit on a postage stamp.

Kitten · 18-02-2011, 10:01

You need processes and work instructions. I'm assuming this is a single point of failure scary thought?

Mark · 18-02-2011, 10:36

Quote:

Originally Posted by Kitten

You need processes and work instructions. I'm assuming this is a single point of failure scary thought?

You think correctly - right down to the wording I used in an email!

volospian - I'll read that tonight - looks very interesting.

And, you know who you are - thanks for the PM - the same applies.

We'll be keeping it very simple as there are very limited resources involved (i.e. one person full-time). That means I'll be doing most of the roles, which is very 'not ITIL', but worthwhile nonetheless.

My main aims are going to be:

Document what we have now.
Document any changes to it (before the change happens).
Ensure everyone has insight - so, for example, we don't do any destabilizing changes two days before a critical date.
Let those who have already expressed a preference get better insight into what's changing and why.

"Single point of failure" is probably stretching things - there's plenty of people around here skilled enough to pick the system up, but it took me three months to get up to speed on it and I'm still learning a year later.

volospian · 18-02-2011, 10:21

Well, this is how I do it. It's not "true" ITIL as we don't have the resources to seperate out the roles of Change Management itself, from the roles around Release Management, (not to mention half a hundred other roles...) so I have placed some of the release controls into the Config Management process (hardware and software lifecycle) and split the rest of Release Mgmt into seperate "analyst" and "implementor" roles. I have then sort of short circuited the Change Mgr role by having a "Change Authority" instead.

The idea is that the request for change arrives and is passed to the analyst who writes the technical "how to's" (and performs the technical risk assessment) and then passes those plans to a "implementor", who tests them and reports back any errors. The Analyst then updates the plans and risk register and sends them back to the implementor. This loops around until the plans look good to go.

Then the documentation is passed to the Change Authority, who decides whether to roll out the change into the live environment. If the CA gives the go ahead, the implementor rolls out the change.

It's not perfect, and I'm sure people will have a lot of comments, but if works for us. It splits the planning from the implementation, which stops people assuming that, just because they planned the change it's bound to work fine and can therefore go straight into the live environ, and it also allows the "authority" to be a non tech person (in our case we usually just assign the main stakeholder of the service the job of "authority", unless the changes will affect multiple services, and then we have to assign someone higher up the food chain and call a CAB) as they only really have to review the risk register and the results of the test roll outs before deciding if they want to implement the desired changes. If the risk reg still contains high risks that have not been mitigated, they can reject it (either outright, or for amendment) and if the test results show a problematic roll out, again they can obviously chuck it back, or risk it.

In our experience this makes the actual decision making a lot quicker. They basically read the report and OK it, or not. By making the analyst write the plans out first, the implementor can be someone less techy too (they just follow the instructions and report back) which is good for us, as we have more low level IT staff than we do gurus and I don't want to waste our top techs sitting in front of a piece of hardware watching a percent bar slowly creep up to 100%.

It also means that we have a detailed record of what worked, what didn't and so on, for future reference. It also means that once a change has been applied, the process can potentially be adopted into the "pre-authorised" changes that can be implemented without having to perform detailed change management every time (e.g. new software testing. Once it's succesfully been rolled out on one PC, the same process can be adopted as a "standard" for all subsequent users and that piece of software can go into your Definitive Media Library, along with the full documentation of how to install it, then it simply becomes a service request on your service desk).

Release is, as I said, partially shared with Config Mgmt. If there are requirements for hardware or software, the analyst will detail what is required, and request the necessary items from SACM (Service Asset and Config Mgmt) who will then either assign existing kit or licenses, if available, or requisition new stuff.

SACM then becomes a sort of library where you "check out" hardware and software, and they record where it's gone and for how long. This is reviewed on a regular basis and when it's no longer required in the live environ, it is "called back" into the library. Because SACM is responsible for the "loan" of assets, there is a reduction is wastage where old kit, or unused licenses, is hanging around in an office somewhere and the company is buying new stuff for new projects, instead of reusing the existing stuff... if you see what I mean.

In our place SACM also does our document management process. This ensures that documentation is provided for each CI (item in the database). That way we hope to have an authority who is capable of bothering the techies for missing documentation... and then also ensuring that it meets certain standards (versioning, distribution lists, look and feel, naming convention, etc.)

It all sounds pretty complex here, but once people get used to it, it becomes second nature. As I said at the start, it's not necessarily the way ITIL describe the way these things should work, but it works for us.

Other benefits are SACM performing license and contract renewal, so you shouldn't get caught out of warranty and, in our place, I have assigned the responsibility for backups to the SACM role too. That way the backups are more integrated into the day to day "config" of our systems. We can then document in the CMS what data needs to be backed up, how and when, and they can ensure that it happens.

They also ensure all monitoring is happening, and produce our regular and ad hoc reports, so we can request reports when we need to do any planning, for example. Plus a load of other "admin" roles around auditing, producing performance reports, reviewing existing hardware against minimum spec lists, marking kit for renewal, etc. etc.

If you are interested, I can probably send you some of my docs around this...

Kitten · 18-02-2011, 10:28

^^ sounds like a pretty decent system. Certainly for a smaller scale operation, if it works, it's documented and you can pick up if someone drops it, you're doing a lot better than most!

volospian · 18-02-2011, 10:49

Quote:

Originally Posted by Kitten

^^ sounds like a pretty decent system. Certainly for a smaller scale operation, if it works, it's documented and you can pick up if someone drops it, you're doing a lot better than most!

Well, there is a caveat on this working at the moment. We've recently been outsourced to another company. A soon as they came in, they started messing and, as a result, the person who was lined up to do the role left shortly after. This was about 6 months ago. Now our new lords and masters are still fannying around trying to decide if they want someone here to do the role, or someone in another site (as they don't seem to have any SACM for any of their sites) so at the moment, I'm doing SACM here alongside my other roles.

It doesn't really matter much where the person actually sits who does it. I just need them to finally decide whether to appoint a new person here, or give the job to someone else as I don't really have time to do it properly, so I'm only doing the important bits at the moment (backups and release, really).

It's all becoming a serious bone of contention now, with me telling my immediate manager that unless things are sorted out soon I will resign. My wife gets paid enough that we could still get by without my wage so it's not as if I desperately need to work here, and I feel strongly enough about it, that I will resign if I don't feel they are taking the development of our service seriously.

Kitten · 18-02-2011, 10:41

Bear in mind, Mark that ITIL is essentially a best practice framework. You hang what you can off it - you'll never have a fully ITIL-compliant process because sh*t happens and things don't always go to plan, but you can at least have a process that aspires to be as close to best practice as possible. So just doing all the roles isn't perfect, but sometimes it has to do. Having the responsibility in the 'wrong' function or area is better than not having it at all. I did the same in my old job, I was service support & delivery

Best advice I think I was given re: process & procedures (work instructions) was - if you need to tell someone what to do (i.e. raise a call by calling someone else) then it goes into the process. If you need to know how to do it (i.e. raise a call, entering it into the system with all the relevant information) then it's a work instruction/procedure. Helped me loads when trying to identify which document went were.

Also helpful, do a swim lane before you do anything else. Helps you pinpoint who has ownership of each stage and also fill in any gaps before you realise you've written the process & missed big chunks out.

volospian · 18-02-2011, 10:55

Quote:

Originally Posted by Kitten

you'll never have a fully ITIL-compliant process

[Pedant]
You'll never have a fully ITIL Compliant process because ITIL has no compliancy assessment process. However, they can be ISO20000 compliant, for what it's worth
[/Pedant]

Kitten · 18-02-2011, 10:57

I KNEW someone would say that, even as I was writing it!

I hesitated, and left it in anyway - I'm still right, you'll never be fully ITIL-compliant

PS...I passed the ISO200000000000 thing.

Be careful you don't end up lumped with the role; as they can't see any problems, they don't realise or appreciate that it's basically the function that underpins the entire system. It's only when it's too late and something goes wrong, that you end up firefighting ALL the time and that is a serious PITA.

volospian · 18-02-2011, 11:29

lol, Ah well, I'm trained up to ITIL v3 Expert level so I couldn't let it pass

Congrats on ISO20k, I was intending to complete my Expert, then do ISO20k after, just so I know the differences between the two, but things have been scuppered since the takeover. To be honest, I'm amazed how such a large IT organisation (and it is one of the biggest) has so little comprehension of service management, service lifecycle or even a service-centric approach to IT provision. They still monitor our service performance on "server uptime" ffs!

It's still a valid point you made though. People often think of ITIL as a rigid framework, that must be adhered to, when it's really only a collection of best practices. Adopt and Adapt are the keywords. Take the bits that you can make work, and be mindful of the bits that you can't.

Tell me about it... I'm so frustrated. I was moving (slowly) towards a decent structure, while (even more slowly) managing to persuade those on the top floor that Service Management is the only real way forward. Now everything has been put on hold indefinitely. And what that means is that people on the floor are now losing faith in the concept and it's making it more and more difficult for me to push the implementation through when senior management are not supporting me. I don't want to work in an environment where the lack of senior support is restricting my (and my teams) ability to provide a quality service to our customers.

17-02-2011, 23:02	#1
Mark Screaming Orgasm Join Date: Jul 2006 Location: Newbury Posts: 15,194	Configuration Management / Change Control Acknowledging the fact that the team (and the company) I work in is (probably like most others in the sector) notoriously bad at internal documentation, and having a scary thought (involving a bus) on the way home, has led me to one thought... Change Control I don't want to do anything that's so onerous that it gets dumped after a week, and I don't want to reinvent the wheel. So is can anyone point me towards anything in any of the standards that might help guide me towards a workable implementation? What I know about things like ITIL would probably fit on a postage stamp.

18-02-2011, 10:01	#2
Kitten Spinky-Spank Join Date: Jul 2006 Location: 668. The Neighbour of the Beast Posts: 11,226	You need processes and work instructions. I'm assuming this is a single point of failure scary thought? __________________ "You only get one life. There's no God, no rules, except for those you accept or create for yourself. Then once it's over... it's over. Dreamless sleep for ever and ever. So why not be happy while you're here?" Nate Fisher

18-02-2011, 10:28	#5
Kitten Spinky-Spank Join Date: Jul 2006 Location: 668. The Neighbour of the Beast Posts: 11,226	^^ sounds like a pretty decent system. Certainly for a smaller scale operation, if it works, it's documented and you can pick up if someone drops it, you're doing a lot better than most! __________________ "You only get one life. There's no God, no rules, except for those you accept or create for yourself. Then once it's over... it's over. Dreamless sleep for ever and ever. So why not be happy while you're here?" Nate Fisher

18-02-2011, 10:41	#7
Kitten Spinky-Spank Join Date: Jul 2006 Location: 668. The Neighbour of the Beast Posts: 11,226	Bear in mind, Mark that ITIL is essentially a best practice framework. You hang what you can off it - you'll never have a fully ITIL-compliant process because sht happens and things don't always go to plan, but you can at least have a process that aspires to be as close to best practice as possible. So just doing all the roles isn't perfect, but sometimes it has to do. Having the responsibility in the 'wrong' function or area is better than not having it at all. I did the same in my old job, I was service support & delivery Best advice I think I was given re: process & procedures (work instructions) was - if you need to tell someone what to do (i.e. raise a call by calling someone else) then it goes into the process. If you need to know how to do it (i.e. raise a call, entering it into the system with all the relevant information) then it's a work instruction/procedure. Helped me loads when trying to identify which document went were. Also helpful, do a swim lane before you do anything else. Helps you pinpoint who has ownership of each stage and also fill in any gaps before you realise you've written the process & missed big chunks out. __________________ "You only get one life. There's no God, no rules, except for those you accept or create for yourself. Then once it's over... it's over. Dreamless sleep for ever and ever. So why not be happy while you're here?" Nate Fisher* Last edited by Kitten; 18-02-2011 at 10:45.

18-02-2011, 10:57	#9
Kitten Spinky-Spank Join Date: Jul 2006 Location: 668. The Neighbour of the Beast Posts: 11,226	I *KNEW* someone would say that, even as I was writing it! I hesitated, and left it in anyway - I'm still right, you'll never be fully ITIL-compliant PS...I passed the ISO200000000000 thing. Be careful you don't end up lumped with the role; as they can't see any problems, they don't realise or appreciate that it's basically the function that underpins the entire system. It's only when it's too late and something goes wrong, that you end up firefighting ALL the time and that is a serious PITA. __________________ "You only get one life. There's no God, no rules, except for those you accept or create for yourself. Then once it's over... it's over. Dreamless sleep for ever and ever. So why not be happy while you're here?" Nate Fisher Last edited by Kitten; 18-02-2011 at 11:00.

18-02-2011, 10:21	#4
volospian Vodka Martini Join Date: May 2009 Posts: 786	Well, this is how I do it. It's not "true" ITIL as we don't have the resources to seperate out the roles of Change Management itself, from the roles around Release Management, (not to mention half a hundred other roles...) so I have placed some of the release controls into the Config Management process (hardware and software lifecycle) and split the rest of Release Mgmt into seperate "analyst" and "implementor" roles. I have then sort of short circuited the Change Mgr role by having a "Change Authority" instead. The idea is that the request for change arrives and is passed to the analyst who writes the technical "how to's" (and performs the technical risk assessment) and then passes those plans to a "implementor", who tests them and reports back any errors. The Analyst then updates the plans and risk register and sends them back to the implementor. This loops around until the plans look good to go. Then the documentation is passed to the Change Authority, who decides whether to roll out the change into the live environment. If the CA gives the go ahead, the implementor rolls out the change. It's not perfect, and I'm sure people will have a lot of comments, but if works for us. It splits the planning from the implementation, which stops people assuming that, just because they planned the change it's bound to work fine and can therefore go straight into the live environ, and it also allows the "authority" to be a non tech person (in our case we usually just assign the main stakeholder of the service the job of "authority", unless the changes will affect multiple services, and then we have to assign someone higher up the food chain and call a CAB) as they only really have to review the risk register and the results of the test roll outs before deciding if they want to implement the desired changes. If the risk reg still contains high risks that have not been mitigated, they can reject it (either outright, or for amendment) and if the test results show a problematic roll out, again they can obviously chuck it back, or risk it. In our experience this makes the actual decision making a lot quicker. They basically read the report and OK it, or not. By making the analyst write the plans out first, the implementor can be someone less techy too (they just follow the instructions and report back) which is good for us, as we have more low level IT staff than we do gurus and I don't want to waste our top techs sitting in front of a piece of hardware watching a percent bar slowly creep up to 100%. It also means that we have a detailed record of what worked, what didn't and so on, for future reference. It also means that once a change has been applied, the process can potentially be adopted into the "pre-authorised" changes that can be implemented without having to perform detailed change management every time (e.g. new software testing. Once it's succesfully been rolled out on one PC, the same process can be adopted as a "standard" for all subsequent users and that piece of software can go into your Definitive Media Library, along with the full documentation of how to install it, then it simply becomes a service request on your service desk). Release is, as I said, partially shared with Config Mgmt. If there are requirements for hardware or software, the analyst will detail what is required, and request the necessary items from SACM (Service Asset and Config Mgmt) who will then either assign existing kit or licenses, if available, or requisition new stuff. SACM then becomes a sort of library where you "check out" hardware and software, and they record where it's gone and for how long. This is reviewed on a regular basis and when it's no longer required in the live environ, it is "called back" into the library. Because SACM is responsible for the "loan" of assets, there is a reduction is wastage where old kit, or unused licenses, is hanging around in an office somewhere and the company is buying new stuff for new projects, instead of reusing the existing stuff... if you see what I mean. In our place SACM also does our document management process. This ensures that documentation is provided for each CI (item in the database). That way we hope to have an authority who is capable of bothering the techies for missing documentation... and then also ensuring that it meets certain standards (versioning, distribution lists, look and feel, naming convention, etc.) It all sounds pretty complex here, but once people get used to it, it becomes second nature. As I said at the start, it's not necessarily the way ITIL describe the way these things should work, but it works for us. Other benefits are SACM performing license and contract renewal, so you shouldn't get caught out of warranty and, in our place, I have assigned the responsibility for backups to the SACM role too. That way the backups are more integrated into the day to day "config" of our systems. We can then document in the CMS what data needs to be backed up, how and when, and they can ensure that it happens. They also ensure all monitoring is happening, and produce our regular and ad hoc reports, so we can request reports when we need to do any planning, for example. Plus a load of other "admin" roles around auditing, producing performance reports, reviewing existing hardware against minimum spec lists, marking kit for renewal, etc. etc. If you are interested, I can probably send you some of my docs around this...

18-02-2011, 11:29	#10
volospian Vodka Martini Join Date: May 2009 Posts: 786	lol, Ah well, I'm trained up to ITIL v3 Expert level so I couldn't let it pass Congrats on ISO20k, I was intending to complete my Expert, then do ISO20k after, just so I know the differences between the two, but things have been scuppered since the takeover. To be honest, I'm amazed how such a large IT organisation (and it is one of the biggest) has so little comprehension of service management, service lifecycle or even a service-centric approach to IT provision. They still monitor our service performance on "server uptime" ffs! It's still a valid point you made though. People often think of ITIL as a rigid framework, that must be adhered to, when it's really only a collection of best practices. Adopt and Adapt are the keywords. Take the bits that you can make work, and be mindful of the bits that you can't. Tell me about it... I'm so frustrated. I was moving (slowly) towards a decent structure, while (even more slowly) managing to persuade those on the top floor that Service Management is the only real way forward. Now everything has been put on hold indefinitely. And what that means is that people on the floor are now losing faith in the concept and it's making it more and more difficult for me to push the implementation through when senior management are not supporting me. I don't want to work in an environment where the lack of senior support is restricting my (and my teams) ability to provide a quality service to our customers.