Real World ITIL Blog - Change Management

Does Change Management Become a Witch Hunt?

info.nospam@nospam.evergreensys.com (JoeLong) — Mon, 24 Aug 2009 11:38:00 -1000

How many times have you been on-site and the people who currently have the responsibility for perfomring the task that you are to help automate or streamline resent your presence? Do they look at you like your the newest gunslinger in town? Are your cries of "I am not an animal!" go unheeded? Did you know that this attitude (when pronounced) can have an effect on the way you function? It can make you shy away from recommending a modification to current procedures or processes when you know it is the best thing to do. Many of the tools that are installed now contain a log that captures every move made. This is very true of the old Opsware products, so the end-users feel that "Big Brother" has arrived and it is 1994 all over again. Take the time to explain. Take the time to really listen to the person doing the job. Make sure you explain this is not intended to be the traffic cop who is cathing those who make a mistake and hang them out to dry. I find the best explanation is that it is used to quickly determine how to find and fix the problem. Remember, don't spend time thinking about the problem, think about the solution.

Change Management - Are You Fighting Fires or Preventing Them?

info.nospam@nospam.evergreensys.com (DonCasson) — Mon, 15 Oct 2007 22:05:00 -1000

We’ve been talking lots lately about Change management, so I have a question for all of you out there who feel like all you do is fight fires.

How many Changes does your organization make per month? Now think of the impact on the business. Are you pushing more than 500 changes per month? Do you feel like you’re fighting fires instead of preventing them?

If this is a topic on your mind, then I hope you’ll join me tomorrow, October 16 at 10AM (PDT) 11AM (MDT) 12PM (CDT) and 1PM(EDT) for our HP and Evergreen sponsored webinar on Change Management – taking it from firefighting to fire prevention.

The agenda includes:

• Best practices on Change control lifecycle management.
• Change acceleration with reduced complexity, cost and increased ROI.
• Real-world success stories on managing Change.
• Optimization of CAB efficiency and effectiveness.
• A fast tour demo of HP’s integrated ServiceCenter, Change Control Management and uCMDB bundle.

Change will also be address in the context of workflow analysis, CI (configuration item) collision and the importance of a universal CMDB.

Hope you’ll be able to join us!

Don

Managing Change - It’s All About the Lifecycle

info.nospam@nospam.evergreensys.com (DonCasson) — Fri, 28 Sep 2007 22:06:00 -1000

We’ve been talking about change lifecycle management lately, so I thought it might be interesting to dissect the components of Change.

Key improvements in Change Management can be found in four phases – planning, approval, execution and review. Most organizations tend to spend all their time in execution but there are valuable opportunities for improvement in other areas that are often overlooked.

In the area of Change Management planning, typical improvements come from:

raising the bar for change approval (saying no to changes that are not justified).
empowering those requesting the change to plan it.
matching level of effort in change planning with the materiality of the proposed change.
clarifying and communicating expectations related to change submission completion and lead times.

Most potential for gain in the Change Management Approval area will be uncovered by discussing the Change Approval process with those handling the IT Change Approval process. Typical improvements come from:

streamlining and routing approval processes based on risk and materiality.
reducing approval activities by screening out unqualified requests.
reducing time required by standardizing and improving the quality of the requests.
planning work more efficiently by raising compliance with submission lead time standards.

Execution changes most often involve improving efficiencies by breaking down organization, process and communication barriers around ‘silos’ in IT. Typical improvements come from streamlining and reducing complexity by grouping similar workflows and reducing them to a manageable number. For example, all server upgrades are ‘essentially’ the same, yet many organizations have completely different workflows for each type of server platform.

Executing via common workflows makes the work of IT less customized and more replicable. Gains in efficiency, simplicity, accuracy and service quality are common, along with reductions in cost and risk. These improvements come from

filtering approval processes based on the risk and materiality of the proposed change.
reducing approval activities by screening out unqualified change requests.
reducing work time required by standardizing and improving the quality of the requests.
planning work more efficiently by getting staff to comply with change submission lead time standards.

The most potential for gain in the area of Change Management Review is usually uncovered by discussing the Change Review process with those performing the review work. For most organizations, effective change review is the most neglected change activity.

Changes that do not fail, but don’t perform well for some reason or other are rarely reviewed. Changes that fail during execution or illustrate themselves as software failures are obvious and should be considered separately. More subtle changes need to be examined separately and root causes examined. Changes that cause serious failures, often evidenced by unplanned downtime or worse, usually do receive in-depth analysis. These often result in major systematic course corrections, but only after the fact, when high costs have been incurred. Red flags should go up for changes that fail during initial execution, but more subtle changes should be investigated thoroughly as well. Many IT organizations operate reactively and thus ignore these more subtle changes, spending the majority of their time on reactive analysis.

Typical improvements come from better change review activities that reduce the number of failures and also reduce the number of changes that fail in execution, thereby reducing the number of ‘near’ failures.

Analysis of the findings in Change Management from the perspectives of basic re-engineering of key, high-volume workflows and key improvement points in each of the four phases of the Change Management lifecycle should point out clear opportunities for business value improvement. These include improvements in service quality, efficiency, accuracy and agility, and reductions in risks and costs.

- Don

Calculating the Business Gains of Change Process Re-engineering

info.nospam@nospam.evergreensys.com (JoeKoester) — Mon, 24 Sep 2007 22:07:00 -1000

One of the best places to start ‘changing change management’ is through classic business process re-engineering. These efforts show the greatest gains when looking at workflows that are more complex (have a greater number of steps and approvals) and cross three or more areas (silos) in going from start to finish. Organizations that have not base-lined and re-engineered the top five to six high-volume workflows in IT can see efficiency gains of up to 25-40%.

To calculate the value of re-engineering, select three high-volume workflows crossing three or more areas. Examples may include IT security approval processes, medium-level software programming changes (such as 20 to 40 hours of code development), IT procurement actions and server operating systems or database upgrades:

Using a spreadsheet, interview those involved from end to end to create the ‘as-is’ process state. Review the workflow for unnecessary steps, duplicative activities, excessive manual activities, excessive delays and rework caused by inaccuracies and errors due to poor end-to-end understanding and communication.
Build the desired state by devising the most simple, streamlined approach to meet the business requirements and assume the use of basic Change Management technology to automate communications and workflow.
Measure the expected change in efficiency and elapsed time.

This kind of measurable gain can go a long way in convincing executive management to invest in re-engineering change management in your IT organization.

I’d love to hear how you calculate business gains from re-engineered change processes in your organization.

Also, Don’t forget to register for Evergreen’s change management webinar: Take Change Management from Firefighting to Fire Prevention

Joe

Role of Virtualization in Change Management

info.nospam@nospam.evergreensys.com (TonyIanetta) — Tue, 20 Mar 2007 22:09:00 -1000

The emphasis today around Change Management is establishing a good workflow to speed up the request and approval process. All well and good, but let’s fast forward and declare that part of journey over and pretend we’re so efficient that we can submit and approve 50 change requests a day. While we’re at it, let’s also assume you are also proficient at detecting and resolving collisions among a batch of RFCs.

The next challenge might be how do I really increase my level of confidence for critical and n-tier changes. Why? Because you can’t totally rely on analysis, sometimes you have to insert and evaluate the change in an actual environment. Obviously you can’t do this in a real production environment but you can in a replicated virtualized environment.

Virtualization allows you to create multiple and different types of abstract or logical servers on real physical machines without dedicating the machine to a particular operating system or application function. I’d be surprised if any IT shop today hasn’t already deployed products like VMware, Virtuozzo, Xen etc. This technology is a great opportunity for change management (and functional testing too) since you can build a replica of your product environment, roll in the change and evaluate the results. These virtual machines can be destroyed if you are simply using it as a lab or it can be migrated directly if you have a virtualized data center. Additionally you can create and restore snapshots for ongoing problem analysis. Ok I admit it’s a fairly advanced topic for the process world of ITIL but if you?re organization is already investing in VMware or similar products then take a look at how this technology can be leveraged to further mitigate change risk.

Download Evergreen’s free Change Management Policies and Procedures Guide

Also, Don’t forget to register for Evergreen’s change management webinar: Take Change Management from Firefighting to Fire Prevention

Change Management Process Design Good Practice — Feedback

info.nospam@nospam.evergreensys.com (TonyIanetta) — Wed, 14 Mar 2007 22:10:00 -1000

Every well designed process or system relies on a feedback mechanism to ensure stability and to achieve a desired goal (that’s right, a process is a small system and not a Visio diagram). That?s simply a text book definition from school, but I?ve certainly come to respect the need for feedback in life as well as managing business processes.

So if you want your ITIL Change Management process to be more than pumping paperwork faster, then consider what feedback controls need to be designed into the workflow.

Here are some control points to design in:

Unplanned (aka unauthorized) changes - your CMDB should have capability to kick out daily alerts for CIs with change events that are under configuration control and not have a recently scheduled production change.

Business Verification - your workflow should allow the business representative to verify that certain types of changes are working as planned from the end user?s perspective.

Operational Monitoring - the changed CI is being monitored (or not if that was the type of change). If monitoring isn?t the appropriate mechanism for verifying a particular change then a test script or inspection should be run upon rolling it into production.

Production Operations Check-off - indicating that the RFC was promoted to production Operations successfully or rolled back

In addition to feedback for individual changes, the overall process should be periodically checked using management metrics.

Management KPI (Key Performance Metrics) trend the process results. Some examples are decreasing (hopefully) preventable errors, reduction or steady state number of emergency changes, or a reduction in untested changes. Now an undesirable trend is not always due to a poor process. People may simply be making errors in judgment. However, KPIs trending out of the desired limits may be telling you the process itself needs to be reevaluated.

Download Evergreen’s free Change Management Policies and Procedures Guide

Also, Don’t forget to register for Evergreen’s change management webinar: Take Change Management from Firefighting to Fire Prevention

Developing the Business Case for Change, Configuration and/or Release Management, part 2

info.nospam@nospam.evergreensys.com (ScottBraden) — Tue, 06 Mar 2007 22:02:00 -1000

Last time I shamelessly teased you by stating that speed, quality and cost can all be improved at the same time. Now I’ll tell you how I’ve seen it done in real-world IT shops.

Here’s the secret: they implemented strong, mature ITIL-based Configuration, Change and Release Management.

Here’s why it works: as I said, these three processes are tightly linked at almost every step.

For example, your planned changes (RfCs or Requests for Change) are assessed for impact and risk and which Configuration Items (CIs) are involved by using the relational data about your infrastructure that?s stored in your CMDB (Configuration Management Database).

Then, the Change Management process hands off the actual implementation of many (but not all) changes to the Release Management process, which is responsible for building, testing and implementing the actual changes to the infrastructure.

And of course, the CMDB gets updated with the new information about the CIs that have changed.

Because of this tight linking, smart companies are able to build in a high degree of control and quality checkpoints. For example, if a planned rollout fails, you want to be able to trace the cause of the failure back to its origin. When you build mature processes and tight controls, then review and act on the data and metrics you capture, you have specific, clear, measured information that you can use to make improvements in your policies and processes and procedures. It?s a continuous feedback loop.

Result: your operations become more efficient. Your shop can deliver more changes, with higher quality and reliability, at lower cost. CIOs love that stuff.

Till next time, keep up the good work, and ask yourself: ‘in our shop today, when a change causes problems, do we rigorously go back and find out not only the technical cause of the issue but the process or procedure gap that allowed the tech problem to sneak in?’

Scott Braden

Download Evergreen’s free Change Management Policies and Procedures Guide

Also, Don’t forget to register for Evergreen’s change management webinar: Take Change Management from Firefighting to Fire Prevention

Developing the Business Case for Change, Configuration and/or Release Management

info.nospam@nospam.evergreensys.com (ScottBraden) — Mon, 05 Mar 2007 22:03:00 -1000

When we’re working with clients to help them map out a long-term plan for ITSM (IT Service Management) using ITIL best practices as a guide and benchmark, one of the most important questions is “Which ITIL process should we work on first? Second?”

Well if you read my blogs, you’ll know my answer is going to depend on the results of the assessment, which makes heavy use of ITIL KPIs and metrics that IT and the business would like to see improve.

What’s not always so clear for clients is how to translate a business requirement or SLR (Service Level Requirement) into specific process changes that are needed to meet the goals.

For example, most businesses I’ve worked with in the past few years are looking for some combination of improved speed for IT to deliver changes, without hurting service quality and while keeping costs under control. Some of you are laughing already, as you recognize the old joke about ’speed, quality, price – pick any two.’

But, it is in fact possible to improve all three, at the same time. One of the most common examples I see is in the areas of Change, Configuration and Release Management. These three ITIL processes are very tightly linked, so that we frequently recommend that clients begin their SIP (Service Improvement Program) by focusing on these together, or at least in a very compressed time frame.

Next time, I’ll tell you why – till then, keep up the good work, and ask yourself “of the Changes our shop puts into production, how many are on time, on budget and produce no unknown errors?”

Scott Braden

Download Evergreen’s free Change Management manual

Also, Don’t forget to register for Evergreen’s change management webinar: Take Change Management from Firefighting to Fire Prevention

Which Comes First: The Change and Configuration Egg or the Service Catalog/Service Level Management Chicken?

info.nospam@nospam.evergreensys.com (ScottBraden) — Fri, 12 Jan 2007 22:10:00 -1000

Which comes first, Change and Configuration, or Service Catalog and Service Level Management?

This is a trick question. I’ll give you the answer later. And it’s also the actual decision we’re facing right now as Phase 1 of this client’s ITSM initiative wraps up and Phase 2 planning is in full gear. Based on the current state assessment, I personally think the most business value “bang for the buck” is in improvements to Change and Configuration Management.

But there are some important reasons why SLM and Service Catalog are important too. Those reasons are key Directors in the organization, who have a vote in the budgeting decision for Phase 2. And they also have specific objectives of their own that they want to get completed as soon as possible.

Our project sponsor understands all of this, and agrees that from the ITIL perspective, and more importantly from the business value point of view, Change and Configuration should be tackled next. But he also understands that “The other Directors understand why Change and Configuration Management are important, but they don’t see why they need to be addressed first. However, what they do understand is why their Service Level Management and Service Catalog goals are immediately important.”

So, the answer to the trick question is this. The one that comes first is the one that the customer wants and is willing and able to fund. Ultimately, business value is in the eye of the beholder.

As a consultant, it’s my duty to help the client understand their options clearly, as well as the costs, trade-offs and expected benefits associated with each option. But it’s up to the customer to say “Ok, I understand, we’re starting with plan B.”

Also, check out our new White Paper on “How To Develop a Service Catalog”.

Don’t forget to register for Evergreen’s change management webinar: Take Change Management from Firefighting to Fire Prevention

Keep up the good work,

Scott Braden

Technorati Tags: help desk itil service it service itil desk software

Business Value of ITIL’s Release Management

info.nospam@nospam.evergreensys.com (DonCasson) — Tue, 26 Sep 2006 01:08:00 -1000

Hi Guys-

Here is a discussion that transpired recently with some of us at Evergreen related to advanced practices in Release Management. Note–this is not complete or polished--just some interesting musings.

David: Client A and Client B use Change Management to plan for the production ready releases of (applications). All other release activities from conception, design, test, QA, etc… are handled by individual groups outside of a singular control process. Based on my experience with both clients this is the case because the Operations team owns the change process and the Development team doesn’t believe Operations should be involved with the management of applications, other than installing, modifying, or removing production ready apps.

Don: David - a good discussion! I believe the approach you described is very common industry wide, and is not necessarily inappropriate. Most development teams have processes and software (Serena, Merant, Mercury, etc) supporting the development of an application or app modification.

Per ITIL, Release Management coordinates the many service providers and suppliers involved with a significant release of hardware, software, and associated documentation across a distributed environment.

Some thoughts from a business practical view - not an exhaustive list.

Some Good Release Management Practices

Have a defined set of change execution models for the 4-5 common types of releases - agreed upon with development (improves their alignment activities).

Set clear expectations with development on timing, lead times, risk, end user training, and infrastructure readiness state, ensuring smooth, planned launches.

Have agreed upon (and followed) development best practices - with the correct amount of emphasis on testing for quality, end user testing, and end user training.

Some Great Release Management Practices (add these)

Use one enterprise change management process for change planning and approval, which begins at the front end of the demand funnel - so all of IT works with one change planning system - Plan, Approve, Build, and Implement. This allows apps and infrastructure to weigh in on risk, impact, and cost?thereby getting a true picture of the value of a proposed activity. This can be the portfolio management tool or the IT change management tool, it doesn’t matter - but use one for IT.

This also allows infrastructure to understand the demand load they are facing in time to affect their strategic planning. So better decisions / tradeoffs can be made on infrastructure investments with longer range planning horizons.

Gear development lifecycle effort by type, according to the risk and materiality. Low risk, low impact projects can follow a lighter development set of activities end to end, using production as more of a litmus test.

Release Management is a really good 2 way bridge (just happens to be ITIL codified) between apps and infrastructure to begin working more as one IT organization.

Don’t forget to register for Evergreen’s change management webinar and learn how to Take Change Management from Firefighting to Fire Prevention

Also, check out our new White Paper on “Developing the Business Case for ITIL”.

—–