Posted: Mon Sep 20, 2010 3:09 pm Post subject: Is this considered Change Management, or ... ?
First post here. Sorry for the length but I wanted to give a bit of background to demonstrate why I'm thinking this way. If you don't read I understand.
I'm looking to implement some best practices and am coming up short on what to implement and how. Any help appreciated.
Background: I work for the government. I will soon manage/coordinate IT solutions for a small (personnel-wise) but geographically distributed organization. We do not have any control over our infrastructure but do some application administration and small web app development as needed. All solutions developed or purchased are hosted on the IT agency's servers, and they also manage our desktops and network. Mostly we are program managers and coordinators with external agencies/vendors as needed. "We" is a five person shop being established by consolidating individual IT people like me into one place.
Since we are starting from near zero, I want fast and light, back-of-the-napkin processes that we can use just to stay sane internally. I have done a very large amount of research over the past few weeks, and have decided to take the ITIL approach (waaaay scaled down) because it standardizes terms and concepts. I've chosen to implement Incident, Problem and Change Management. Incident and Problem are straightforward (I typically just escalate and coordinate with the owning agencies or vendors until resolved) and I'm developing a form to manage tracking and closing these, with possible automation later. Change is my issue. Since I don't manage the infrastructure I am thinking at a different level, almost Configuration Management maybe?
From this forum Change Management appears at a high enough level to almost be an audit function: Did the request go through the specified checkpoints in the process with appropriate signoffs etc... Is this a correct view? If so then this is just a paper exercise -- client requests new service/feature via RFC, we toss it around during a meeting, make a decision and reject or implement and monitor, and get customer acceptance at the end. "Implementation" could be either me making a code change to an internal web app, or a handoff to an external process if the change must be made by a vendor, etc. Does this sound right?
Basically I want a way to formally identify a request, track it, implement it, get customer signoff, and have it available when the customer complains later. Because it happens fairly often actually.
Or is there a better area in ITIL to look to for this type of solution? I know this can be seen as crossing into Demand (maybe?) if it encapsulates requirements, and it starts to get fuzzy. I don't need "dogmatic ITIL", like I said I need "fast and light", but ITIL terminology was very helpful in thinking through this. Or is there a process framework other than ITIL that is a better fit?
Thanks for reading and assisting. This forum is a great resource and I've learned a lot already.
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Mon Sep 20, 2010 6:37 pm Post subject:
welcome to the forum and glad you have already found it helpful. Now about change management.
Back to basics. as the name implies it is about managing the change.
I tend to think in terms of four phases all of which must be managed. below is a brief and incomplete description of what I mean:
- Incoming request
a request needs to be authenticated and recorded and put forward for consideration
- Approval and agreement to proceed
approval implies that the change is technically feasible, has a business benefit, does not have overriding adverse implications, and has no unacceptable risk attached to it, agreement to proceed implies that the resources (money people and equipment) will be made available for it. Obviously all this is only achieved by the appropriate technical, business and resource authorities.
- Plan and Implement
planning takes into account the activities of implementation (including all communicating, testing and verifying, and regression) and determines timing and sequencing to fit as unobtrusively as possible within other work activities and service provisions. Implementing is executing the plan following formal procedures as appropriate.
review is not something apart. It is integral to change management. You consider how far the change achieved its intended outcome (was it worth doing?), how well it was executed (did it cause any unexpected pain?), and ,from time to time you also review the process as a whole.
So change management is not about tracking the change, but about steering it through the phases. You may find it useful to read the ISO20000 standard to give some perspective on what the quality requirements might be.
By the by, "dogmatic ITIL" is an oxymoron of the highest order and you will not get it from any of the more active posters on this site. and the others will be dealt with in "dog fights" _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Thank you for the response. Sorry for the "dogmatic ITIL" bit -- yes, I understand that ITIL is a best-practice framework and not a straitjacket, and it was after midnight I believe when I wrote it...
Your description breaks it down to basic fundamentals, and while I was thinking along the same lines this clarifies it and gives me something concrete to work with. Oddly enough I described the software development lifecycle at a similar level for another individual today, and the two are very similar at a high enough level.
What I've done for now is create a basic RFC-type form (Word 2007) that captures who is making the request, what the request is, CAB analysis, whether or not the CAB approves, implementation plan, date when the solution is purchased, date when implemented, and a statement of acceptance or rejection by the customer with a digital signature required. I think this will work for our needs, at least for now.
I've also canvassed my organization to collect information on all of the small applications (Access databases, small web apps) that each department uses. I put each into a spreadsheet with a description, owner, platform, hosted location, maintenance costs, known risks, etc. This is what I will call our "App Portfolio" and will kind of double as a CMDB for managing RFCs. Any RFC that wants to modify an existing app will be vetted against what we know of that app and its impact to existing operations.
Implementing this stuff is a lot harder than it looked when I read VisibleOps and a few blogs! But worth it.
Yes, I included those in my draft document. I also put in spots for the change manager to digitally sign if he rejects the change, and also for the customer to digitally sign that he accepts the final implementation. Seems like a good idea to me anyway.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum