Here’s another post from Rob England, aka @theITSkeptic
In our Sensible Service Management Series, we’ve considered the “front-office” activities that serve the users in posts on “Responding to Incidents” and “Responding to Requests“, and we’ve explored the “back-office” activity that removes the causes of incidents: “Problem Management.” If an alligator bites someone, you fix the incident with bandages and maybe surgery. To fix the problem, you shoot the alligator before it bites again.
But how about a fence to keep alligators out in the first place? This might be considered Change Management, which is another “back-office” activity and the topic of today’s post.
All changes should be managed together as a portfolio, as part of planning. They should be balanced against each other and against available capacity and capability. At some point, all changes ‒ large or small, organizational or operational ‒ move from designing and building into a live or “production” state. That movement of changes needs to be controlled to minimize risk and protect operations. That is what Change Management (in our narrow sense) deals with: managing the change to the operational environment.
Change need to be managed. That sounds obvious but many organizations balk at spending the money for change and project managers. Managing a change takes time and skills, and the investment of that extra 10% pays off in changes being successful and on time and on budget.
For any change above quite a small threshold, make it into a formal project: plan and control it. That threshold should be based on risk and potential impact, not just size.
On any but the smallest projects, a good professional project manager repays their overhead by ensuring the costs, risks and over-runs are controlled on the project.
Every project should have a steering committee, with a single decision-making executive in charge: they’re the “owner” of the project. The manager running the project should be separate from the steering committee and report to them.
Manage a large or risky project in stages. At the end of every stage, you should reassess the justification and the plan: do you proceed? what should you adjust? At the start of each stage, the owner commits the next portion of resources (funds, people, etc.) and the project manager plans how to use them to deliver the outcomes of that stage.
Every project should include assurance: either the steering committee or auditors they appoint should both challenge and advise those working on the project to assure that policies, rules, plans, specifications and standards are being followed.
Every project should set up what comes after it: ongoing ownership, operation and maintenance of what was built; ongoing improvement; ensuring the benefits are realized; and measuring the actual results over time.
Put a “fence” around everything that provides services to consumers; i.e. define a boundary and call it your “Production” area. Restrict who can change Production. This includes facilities, equipment, stock, software, documentation and spares.
Get some control over all the changes to Production. Define what is considered administration and therefore not covered by change-control. Administration activities should still be access-controlled and audit-trailed.
To start with, make sure all changes get recorded somewhere central.
Later, make sure they are recorded beforehand and that the schedule is planned. Is this a good time? What else is going on? Can we batch these changes up and do them together? Can we have a regular time we do this stuff? Publish the upcoming schedule regularly: usually weekly, sometimes real-time.
Once you plan your changes in advance, set up a way to approve all changes. There is a set of approvals required, depending on the size and complexity of the organization:
- Business owner of the change
- Change coordinator
In addition to the approvals, many organizations will want to set up a group of stakeholders to review changes, an “advisory board,” to make sure all implications have been considered. Make a list of the people they should consult depending on the impact of the change.
Don’t approve a change unless you understand the risks and the operators know how they are going to back the change out or restore things if it goes wrong. Do some policing to make sure folk aren’t sneaking changes in.
Once all changes are approved and nobody is subverting the controls, define (carefully) what types of operational changes are “standard”: they don’t need approval because they are low risk (not all easy or small changes are low risk and not all low risk changes are small or easy). They still need to be written down and often need to be scheduled too.
Require that a change is ready before it gets the OK to go into production.
Has it been tested?
If it is a new system/product, have we worked out how to support it? Trained the staff, procedures to operate it, procedures to fix it, vendor support contract?
Have we got enough information about it? Manuals, documentation, vendor details?
Which brings us to the next point: know what you are changing. A good start is to know about all the things in your environment. Some of these are assets, which crudely are the things that come through procurement – so that is a good source to start with in listing all the things in the production environment.
Some things are not assets in the sense of what you buy (and depreciate), such as documents, people and places. Other things are conceptual or virtual, such as systems or the services themselves.
One way to record things is to capture them as they come into production, like the procurement example, or like all the information about the things in a project that gets rolled out. In theory, if you do Change properly you will know about them all. But in reality this is usually a “leaky” approach: things get into production undetected – e.g. IT devices like laptops and wireless modems. So at intervals you also need to discover or audit or stock-take what is in production to check against what you think is there.
Release and Deployment
Often your services will involve a complex mix of people, processes, plant, logistics and computing. It is not enough just to schedule changes: you may need to manage their impact on the service, by
- Considering how the changes interact
- Bundling changes together into a package or “release” or “version” of the service
- Ensuring the target environment is ready (people trained, infrastructure compatible, operational procedures adapted…)
- Managing the steps in deploying the change(s)
This higher level of management for rolling out complex changes is called Release (and Deployment) Management. We’ll talk about it next time.
Follow up on changes.
- Did they work?
- Did we get the results we expected?
- Did we manage them in the right way with the right level of formality and controls?
- What can be learned for next time?
- Did they get all approvals they needed?
A successful change is one that achieved what it said it would, not a change that didn’t break anything.
Dissect changes that fail. Try to identify the causes of failure and prevent a recurrence. Most accidents have multiple causes acting in conjunction, so look for more than one.
Formal projects should get additional follow-up some time after completion to ensure they delivered the return they said they would in the business case for doing the project. If projects didn’t deliver as expected, then look at how business cases are written, how the decisions are made, how projects are managed and how the value is measured.
Stay tuned for Part 8 of the Sensible Service Management Series next week.