By: Anton Avila, Process Manager for R-Group International Pty Ltd

Often the discussion topic with Management Stakeholders comes up – “So when will our new toolset be ready?” Well that depends... comes the answer. What do we want to use it for?

If you’ve ever given that response, and been met with blank looks or vague business-speak for your trouble, you’re certainly not alone. In fact, most Best Practice adherents out there will tell you it’s a common fault in many organisations; trying to align the way you operate to the toolset after you’ve chosen it, rather than the infinitely more sensible approach of choosing (and then configuring) your toolset to support your existing operations and processes (and the processes you think you’ll be adopting in future as your organisation matures).

Taking this “Toolset supports the Process” approach gave us at R-Group a challenge recently in regards to ITIL Change Management. One of the few ITIL process areas to really gain traction in Western Australia to date (and indeed a primary process driver in the rest of the IT industry in Australia), Change Management really does represent the elephant in the room. But why does it represent such a challenge if everyone acknowledges just how important it is?

The key to any Process implementation is that the Process needs to be Effective, Efficient, and Responsive. This isn’t just for the sake of service delivery; it’s also just as important for the sanity of your own personnel. After all, if the way your organisation implements Change Management (and thus builds the tool to support the implementation) isn’t these three things, will your people use the process? If they don’t use it properly because it’s unwieldy (responsiveness), time consuming (efficiency), and just doesn’t deliver the results it’s supposed to (effectiveness), how can you expect your service delivery to your customers to be what you want it to be?

We took the perspective that we wanted Change Management to be as easy to use as possible. This means documenting as many types of minor, low-risk/impact Changes that we otherwise make every day as pre-set procedures; this allows our team to use the QoS-IT customised ‘Outage’ entity for a lot of general maintenance work... For the technician it means no mess, no fuss; a minute or two to log their ‘Outage’ ticket and they’re done with their administrative requirements.

At the same time it means our Management gets the visibility, control and reporting capability they need out of our everyday change activities. From an ITIL perspective this allows us to cover off our “Standard” Changes while maintaining those three core process attributes and it gets the toolset working for us, rather than the other way around.

Obviously for those larger types of upgrades, patches, or fixes which those of us in ‘ITIL land’ refer to as “Scheduled” Changes where there’s a greater risk and potential impact to the customer’s services, a lot more work needs to be done by all involved. Since we need to capture more detail in such Changes, we took the view that using the ‘Outage’ entity for these kinds of Changes wasn’t appropriate. Instead we set about creating a customised entity ‘Request for Change’ or ‘RFC’. Functionally, having a separate entity allows for relationships to be linked to Cases, and even the QoS-IT customised Problem Management entity (As, from an ITIL perspective, both Incidents and Problems can cause Changes, just as Changes can resolve Incidents and Problems).

The key focus with our new entity (click here to download RFC Entity) was to capture what’s important with managing an RFC;
 

• What’s the Risk to the customer from making the Change?
• What’s the potential impact of making the Change?
• What’s the justification of making the Change (or leaving the status quo)?
• What’s the feasibility of the Change?
• How is the Change Build to be documented?
• What Roll-back plan is to be used?
• What testing needs to be done?
• What Communications Plan is to be used?
• What is the deployment plan for the Change?
• Conduct of a Post Implementation Review.

Obviously these elements need to be presented as neatly as possible, as simply as possible and as compactly as possible while still allowing for completeness and visibility into the Change activity. By combining some of these elements (e.g. Communications Plan and Deployment), and omitting other considerations (such as Testing, which theoretically could cover enough content in enough potential scenarios to be an entity its own right anyway), we adopted most of the considerations as Tabs within the primary ‘RFC’ Form. This allowed us to pack all that information into:

• A ‘Summary’ tab (containing general, administrative and overall information on the RFC)

• A ‘Risk and Impact Assessment’ tab to capture the appropriate Justification information

• A ‘Build Notes’ tab to allow free form data entry by the technicians building the change.

• A ‘Roll-Back Plan’ tab to allow a Roll back plan to be outlined

• A ‘Communications and Deployment’ tab to cover off on Communication measures (backed by Workflows to ensure scheduling and action on required notifications)

• A ‘PIR’ tab to allow information on the usual questions asked during a Post Implementation Review to be asked and answered.

Importantly, we also recognised that such an entity would also need relationships with a “Test Log” (or similarly named) entity, and that we’d need a unique ID number generated by QoS-IT for each RFC saved into the toolset. Emergency Changes have also been built into the ‘RFC’ entity, although their very nature dictates that there’s inevitably less control prior to the Change being made.

Our endeavours in this space are by no means complete, and will probably go through a facelift (or three) as time goes on. But this is far less important than the consideration given to ensuring our chosen QoS-IT tool supports the operation of our Processes; it is the understanding of the Processes, and the specific value they provide our organisation (otherwise, why have the process?) that must drive our implementation of QoS-IT and any customisations we make to it.

Anton Avila is the Process Manager for Perth-based IT contractor R-Group International Pty Ltd, a growing and respected provider of Communication and Data Management Project Services and full Managed Services. He is an experienced ITIL Problem Manager and process implementation SME, certified in multiple ITIL v3 Capability certifications. When not working with the QoS-IT team on R-Group’s QoS-IT implementation, he continues to cut his teeth in process development and self-funded training in order to satisfy a stubborn aspiration to achieve ITIL v3 Expert Certification “via the scenic route”.