ITIL Change Management: where is the line between a change and an admin task?

A reader wrote to ask about the line between a change and an admin task. In my usual simplistic way, the answer seems pretty clear.

The question was:

We are implementing ITIL v2 and the change management module. One area we are having trouble getting everyone's head around is defining what is a considered a change and what is considered a standard admin task that does not require any type of notification. Can someone help me define so that they are easily separated?

Is this based on Impact and Risk assessment or more than a clear definition?

As I say, I'm a simple guy. I try to see ITSM simply. Yes the delineation is based on risk and impact. But it's simpler than that. A Change records that something has changed. If you need to know that something has changed then it needs a Change record. Any admin task that needs to leave an audit trail against the changed object is therefore a Change.

I can hear all the tech cowboys sputtering into their Coke already so let me offer some clarifications:

  • Most admin tasks are well understood and low risk, so they can be designated as a Standard change (based on risk and impact, NOT on complexity or frequency of the change). This means they are pre-approved and just need to be tracked.
  • You say you already record the admin tasks somewhere else? Let's look at why we record changes.
    • We do it so the Service Desk and level 1,2, and 3 Support can all see who has dicked with the components of the service, so when it stops working we can quickly diagnose why.
    • We do it so we can forecast and schedule changes in the future, so that changes don't accidentally clash with each other.
    • We do it so all the wise heads can look at a high-risk change before it happens and maybe flag a potential embarrassing cockup before it happens.

    None of that applies to your admin task? Then by all means record it somewhere else. If any of it DOES apply, then making people look in two places to see all change is clearly laziness, selfishness and arrogance that puts service at risk.

  • ITIL defines Change scope to anything that "could have an effect on IT Services" but I'd widen that to "anything we want to keep an audit trail on" because there may be other reasons besides service impact.

So it's simple. Anything that needs a change audit trail is a Change.


Well articulated

Very well articulated Rob. IMHO change management is one process which if implemented well, can bring down (not eliminate) the number of unplanned incidents. One it is implanted in the techie brains, it at least makes us think twice before clicking that "OK" button. However robust a change management process is, wee admin changes do happen, because it is difficult to implement audit trail for every bit of IT (Core Infrastructure, Applications, End user devices etc.).

I used to work for an organization where it was not allowed (and possible) to connect to $ shares on Windows servers (as one could accidently delete a file on a mapped drive on a server), admins could only connect via PCAnywhere to a Windows NT server because it would record the session of an admin. Security Audit logs were not accessible to Sysadmins and many more. Believe me, unplanned outages due to unintended changes were unheard of. I attribute it to two factors - tight controls and fear factor. ITIL wasn't as widely known then. Every change involved at least two pe

There is a fine line between admin tasks and change, and you have rightly said, that anything that needs a change audit trail is a change.

Changes vs. work orders

I consider an "admin task" (aka a work order) to be equivalent to a service request. They are distinct from changes as they involve the service catalog and the dispatching, routing, and performance questions that may not be well handled in the Change Management system. Some change management systems have a separate capability for work orders. But in general, risk and approval can be decoupled from execution.

One Change may have zero or more Service Requests. Service Requests that pose certain levels of risk may require a governing Change. Sometimes, volume is the determinant - 1 workstation upgrade is a Service Request, 100 must also have an approved Change.

Basically it's this:

Change >0---0< Service Request (aka work order/admin task)

Charles T. Betz

Standard Change Continuum

It seems to me at this time that the idea of the standard change is somewhat more appealing here.

As you say, work can, and should, be managed with dispatching and routing.

Additionally, work can be organized around standardized around service request and fulfillment offerings with work breakdown structures and bills of materials with the different activities assigned to different individuals and actual time captured.

Work breakdown structures are needed so that responsible individuals for each activity is known and performance monitored.

The constituent bills of materials can be driven from an Infrastructure Management Catalog that is closely associated with Asset Management and is the result of IT Governance activities - particularly Enterprise Architecture Infrastructure.

Service Request and Fulfillment activities can be designed around Lean and DMAIC TQM techniques; can be standardized; and, can be designed to look like external competition. One can do Time-Driven Activity-Based Costing to capture actual times. One can do Activity-Based, or Service-Based Budgeting to develop the services breakdown and prices - and let the rest of the business, our customers, tell us what their demand for these services will be.

It seems to me that changes to these standard activities can, and should, be under Change Management control.

Changes to the infrastructure need to be noted so that both Configuration and Asset Management data is kept current. Closed loop confirmation of changes need to be validated.

Manufacturing and field service organizations have followed these fundamental procedures for decades. ITIL, sort of, refers to them, but has these ideas spread out across the rather disjointed guidance.

Consider that each group with your IT organization can be seen as its own entrepreneurial mini-business unit. Each can, and quite likely should, offer its own products and services to be competitive with services offered by external service providers. The IT "service" then can buy the services of these internal business units, or, if they cannot provide similar services at a price competitive to external service providers then a make / buy decision is coming.

At every step IT must consider developing transparent processes and costs. Each one of these mini-services need to be managed as a business within a business. Because, after all, the rest of the business, our customers, while they need to trust us, also have a right to verify that their money is being wisely spent by IT. Standardization and transparency of costs is the first major step to trust. Espeically since every day the rest of the business, our customers, are being directlymarketed to by any number of outsourcers to take their business from us.

Cary King

Syndicate content