I was chatting in a crazed and maniacal manner with my coworker, Hobi, about my vision for change management for our team. Hobi is a helpful guy to me, because he’s very good at forcing me to face the reality of my ignorance when necessary. He threw me a few basic questions, to which I had to admit ignorance, and then, as I continued pontificating on my glorious plan I watched him slowly check out of the discussion. He then stopped me in mid sentence and said, “Maybe you need to draw yourself a picture of what you’re trying to do. See ya.”
Ok, so this is my cue to start with the basics. The picture will come soon enough. As my father (and little league baseball coach) always says, “Focus on the fundamentals and everything else will fall into place.” Alright, so what is the hitting, throwing, catching, and base-running of change management?
In reading about Change Management, I quickly came across some other important related terms.
- Service Request Management (Service Desk)
- Incident Management
- Problem Management
- Release Management
- Configuration Management
Holy Crap!!! I hear these terms every day, and often hear them used interchangeably! Oh no! The only thing that is clear to me is that starting with the basics begins with understanding how to even title this blog! I don’t know whether I’m trying to learn about Software CHANGE Management or Software CONFIGURATION Management. Of course, as is so often the case in questions involving a choice, we can defer to the old slippery political side-step: It’s really both, David. It’s really both.
Fortunately, where there’s complexity in IT, there’s a standard. The standard is ITIL: Information Technology Infrastructure Library. So, to help us understand how all of these processes work together, I defer to wikipedia .
Here’s your RAJP summary:
Service Request Management (Service Desk)
No brainer. This is the user’s single point of contact for service regarding your software. It covers everything, so I won’t bother listing everything.
Something screws up. You fix it.
Something screws up. You fix it. It screws up again. It’s a problem. You investigate and fix the root problem that is causing the screw ups.
The process you use to make changes to the system. In the case of software, it’s called Software Change Management. Commonly, SCM.
Ok, so you’ve fixed some problems and you’ve added some new features. At some point, your users are going to want to actually see these changes. Release Management is the process of planning, communicating, building, QA, and deployment of a new release of your software.
Your IT infrastructure is made up of a lot of components. From the perspective of Configuration Management, every component is a Configuration Item (CI). Configuration Management is all about tracking changes on or between these items. For SCM, your primary CI is your source code files. So, we’re talking about baselines and source control.
Ok. If you really want to talk the talk in SCM you have to use the word “baseline” about 250 times a day. It’s such a simple sounding word that it can be used to intimidate the hell out the non-CM studs in your organization. It sounds simple, so people are afraid to ask what it is (like me). Well dammit! I finally asked. A baseline is the approved state of your software for starting changes for your next release. This is probably going to be the state of your source code at the point of your last release. So, an important goal of SCM is tracking the changes on every CI for a particular release from a specific BASELINE. So if 3.1 was your last release, the source from 3.1 will serve as the baseline for your 3.2 release…simple.
Think this is all there is to ITIL? Well, you’re wrong, buddy. Dead wrong. But this a good place to start. So I’ll leave it at that.