Configuration Management / Change Control

[Mark]

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. ;D

[Kitten]

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

[volospian]

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]

^^ 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!

[Mark]

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! ;D

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.

[Kitten]

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 ;D

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]

^^ 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.

[volospian]

you'll never have a fully ITIL-compliant process



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


;)

[Kitten]

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 ;D

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]

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

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. :(

[Kitten]

out of interest, who took you over (PM if you'd rather not say here). It all sounds horribly familiar.... ;)

[Mark]

Wrote the document to set the ball rolling this evening, and I've already got agreement from the 'owner' of the system to give it a try. Will see what my line manager thinks on Monday.

Given that I'm being rushed off my feet and don't have time to study ITIL right now, I've kept it very simple - the goal being more documenting the changes that are being made than controlling them - though that in itself will bring with it some control. If it brings some demonstrable benefit then we can take it from there.

Would like to pick up the basics of ITIL at some not-too-distant future point though, and still intend to read this thread properly when I'm awake. :)

[Garp]

They still monitor our service performance on "server uptime" ffs!

*blink* Service uptime != server uptime. Why is that such a hard thing for people to grasp? DRIVES ME CRAZY. It most especially irritates me when I see sysadmins boasting about server uptimes. "Yeah, my server has a 2 year uptime!", "Yeah, I'm guessing it hasn't been patched in that time. It certainly hasn't been rebooted to make sure its running a patched kernel".

It's about as dumb as measuring support performance by average call time (*fond memories of Piggy's views on that*)

[volospian]

*blink* Service uptime != server uptime.

lol, well they got caught out the other day when they had a service down for about half a day and they tried to report to the client 100% availability, because the server was still responding. The client raised an eyebrow and said "Really? 100%?"

I then had my manager coming in to me and giving a load of verbal about the performance stats, to which I replied "I warned you something like this would happen months ago... but you still insisted we only measure server uptime...".

He wasn't amused when he realised it was his mistake...;D

[Mark]

I have to concur - given that both my servers are also up but I just shut down all the services. They're going to be off for a week. :eek:

[Joe 90]

not seen it mentioned, but when you say change control I just think of version control.

at work we use Tortoise SVN - http://tortoisesvn.net/

Don't know if it'll help, but it basically keeps a log of all versions of a file on a central repo, lets people work on things and keep track of changes etc.

[Kitten]

I'm stuck with tatty old Version Manager :/ Subversion is our developers tool of choice though.