definition of 'change'

colemic

Not sure if this is where to post this or not...

We are standing up a CCB where I work, and we are pretty much at a standstill on the definition of 'change'. (as in, what constitutes needing to go through the CCB, and what does not. Our SAs raised the point that they don't want - or need - a definition that would require them to jump through a lot of hoops to daily tasks such as performing log file grooming, for example.

My proposed definition: A Change is characterized as a modification of any kind of a configurable element of FFIN infrastructure, a service, component and/or its associated elements in a production environment. A Change must be vetted through the Configuration Control Board for approval, and planned accordingly, to include testing all phases of the Change (to the extent possible), a determination of the risk posed to the production environment by the Change, and development of a roll-back if the Change is unsuccessful.


I have a mixed opinion. I certainly understand, but then, I think they are making changes to a production environment. Where's the balance?

Zartanasaurus

I'll tell you how my director defines a change in much less technical terms with the understanding that the CCB is there to communicate your changes to management and CYA if things go wrong.

Are you willing to bet your job on the change without a CCB if you screw something up?
A change is anything that would cause someone heartache or confusion when they notice it.

So it could be as simple as changing the desktop backgrounds on workstations. Of course no one wants to go through CCB to do what we consider the basic level tasks of our job. However we document lots of our processes with the CCB, so if something goes sideways, we can refer back and say that this ongoing operational duty was approved by the CCB.

colemic

I agree with that logic... but we can't agree on a working definition that doesn't bring our production environment to a halt.

There has to be something obvious I am missing here... how do you define what is exempt from the CCB?

Claire Agutter

Hi colemic, this is always a very difficult discussion! Your definition seems like a good start point if people are prepared to sign up to it - what you will probably find is that at first, you are treating things as changes that don't really need to be treated as changes. As your process matures, you'll see what doesn't need to be managed as a change, and you'll also develop a library of standard changes that can be pre-approved and won't need individual authorisation. Your technical teams will need to bear with you as you go through this process, and you will need to bear with your technical teams too! You'll also need management backing of course - if your technical teams aren't following the process, then it doesn't matter how you define a change. Claire

colemic

Thanks Claire, that's great insight... we have discussed the library of changes concept, and it is definitely on the table. What we are running into, however, is not that the we are being too specific, but there is a push to water down the definition, which invariably leads to grey areas. I am not sure if it is better for us to over-manage the change (easy to get lost in the weeds), or to under-manage and let potentially impactful changes be unregulated and unmonitored.

I should add, that we are looking to keep this rather informal, and are not anticpating having a change repository, for example, at this time. Or a dedicated change manager to keep up with all of that. At least not yet.

Zartanasaurus

colemic wrote: »

There has to be something obvious I am missing here... how do you define what is exempt from the CCB?

That's a question for management. Not all CCBs are the same. Generally you're going to have some kind of "keep the lights on" provision, where if something worked and stopped working, you go in and fix it. You might have a process to submit what you did to the CCB after the fact for documentation purposes. Written requests from director level management, may be exempt from the CCB. It's not going to be perfect to start, and it will develop over time. If it's too restrictive where work can't get done, the stakeholders will get it changed.

There's always going to be grey areas, and how big those areas are depend on how management treats unauthorized changes. All it takes is one major outage from an unapproved change for people to get the message though. We can be a little too trusting of our own abilities sometimes. Like Claire alluded to, you can have a library of processes that cover every day operational duties that have been pre-apprpoved to be done outside of maintenance windows. You write up the process outlining all the systems affected as well as the risk of making those changes and show supporting documentation that proves "hey we've done this a million times and here's the process we repeat every time to make that change".

colemic

does anyone have any experience with Change Management software? Any recommendations?

Claire Agutter

Hi colemic, I've only used Change Management software that's integrated into a bigger service management tool - for those I can recommend Axios Assyst, Marval and Remedy. If you're on linkedin there are some groups on there devoted to service management tools so it could be worth posting over there too. Claire