Process consistency is a challenge for many support organisations. It requires a number of elements to be in place to work effectively, which we will explore shortly. It also requires (to quote my favourite character from Harry Potter, Mad-Eye Moody) constant vigilance!
Before we examine process consistency, we will share some practical tips, for context. Let’s explore the basics of Policy, Process, and Procedure.
Why does process consistency matter?
One of the easiest ways to articulate the value of something is to describe a world without it, so let’s take a look at what the world looks like with inconsistent (or missing!) processes:
❌ End users get different expectations from every support representative they deal with and never know what to expect*
❌ Quality cannot be measured as there is no set baseline
❌ Onboarding relies on osmosis rather than structure, which can lead to an adoption of poor practices (even with the best intentions)
❌ Service Desk Analyst performance cannot be accurately measured, and areas for attention or improvement cannot be correctly identified (how can you say a Service Desk Analyst has managed a ticket the wrong way if there is no documented “right way”?)
❌ Customer escalations and complaints due to the level of service received cannot be adequately addressed or validated, as there is no “model” that a provider is working to.
❌ Risks of non-compliance may be raised, especially regarding regulatory requirements.
❌ Service Desk Analysts may get frustrated by not being able to find the correct guidance when needed. This frustration can often lead to a lack of motivation and impact staff attrition rates and the customer experience.
*I call this Forrest Gump Service Management – “It’s like a box of chocolates, you never know what you’re going to get”.
Advice and guidance for achieving process consistency
So, on to the advice and guidance.
Whether there are processes in place, or you start with a “green field”, my advice is the same.
#1 Identify all the operational processes currently being enacted in IT
#2 Build out a simple tracking spreadsheet to record and track what processes are in place and where they are located. This can include basic elements such as:
- Process Name
- Documented Yes/No
- Document Location
- Owner
- Version Number
- Last Reviewed
#3 It’s worth also recording any processes on the roadmap for design and implementation
This simple tracking initiates a discovery activity, which will often provide surprising results. It also starts to get stakeholders engaged and gives you the opportunity to ascertain the size of the challenge in front of you. It helps prompt you to ask the right questions, shows you the state of play, highlights gaps, and hopefully helps unearth some “good stuff” as well as the “not-so-good stuff.”
The above is just a “state of the nation” step in your road to process maturity. Before we get carried away with creating documents, it’s vital we set the rules by which we want people to play.
So, before process documentation comes process governance; without this, you will find yourself back in the same place you started and have wasted time and effort. This is not about being draconian and inflexible; it’s about setting out a process governance framework that shows what is expected and, in fact, makes IT service management people’s lives much easier. They’ll better understand how to be successful and how their actions contribute to achieving goals and objectives.
So, after discovery, the first document I create is usually a simple governance model for process and procedural documentation. This usually contains the following:
✅ Documentation Governance Control and Policy
✅ Standardised Formats and Templates
✅ Ownership and Accountability
✅ Documentation Management and Approval
✅ Storage and Accessibility
✅ Approval and Review Cycle
✅ Maintenance and Continual Improvement
✅ Version Control
✅ Updating Schedule
✅ Review Teams and Procedures
✅ Templates, Versioning, and Updates Protocols
✅ Document Templates to be used
⚡ To quote another famous movie, “If you build it, they will come”.
Here are a few hot tips for great process documentation:
Use a set template
- This not only aids ease of use and adoption (and thus consistency) but also makes it easier for stakeholders to complete process documentation quickly. Generally, people find it much easier to fill in required (titled) sections rather than start with a blank piece of paper
A process owner is not always the document owner
- For instance, the Service Desk Manger may own Incident Management as a process. However, day-to-day responsibility for the process document itself sits with a team leader; this should be identified for the tracking, review, and referral of issues.
No process (or procedure) should go more than 1 year without review
- Given the potential for changes within the organisation, IT support and the associated working practices should be reviewed at least once a year. Without this cadence, they risk becoming out of date and not fit for purpose.
Having processes and procedures stored as knowledge articles makes them easy to find and quick to access from your ITSM tool.
- Staff are more likely to adhere to processes and procedures if they are easy to find. Modern ITSM tools can easily suggest relevant articles at the incident or request logging (or triaging) stage to aid Service Desk Analysts. Having access to process and procedure documentation that does not slow down the support process will aid conformance.
For a process to be both efficient and effective, it must be able to be measured.
- Key performance indicators (KPI) and metrics should be set for each process so it can be accurately measured and evaluated for success. Try to avoid Service Level Management (SLA) performance as the key measurement in this area; this, at best, will only show effectiveness, not efficiency and is not a true measure of the process itself. For example, let’s take an (albeit extreme) scenario which is a 3-day resolution SLA for Priority 3 incidents; you may fix 100% of these in time, but if everyone took 2 days and 23 hours to resolve within SLA, it does not reflect efficiency, just effectiveness (even this is arguable and additionally is likely a poor reflection on the user experience).
A policy associated with a process does not have to be a separate document; it can be a section within the process document itself.
- If you want people to “follow the rules,” make those rules simple, clear, and easy to absorb. While some policy documents related to ITSM need to exist in their own right, for most (if not all!) processes, they can be a section within the process itself. Easy to understand means easy to comply.
What are the characteristics of a good process document?
Well, this does depend on the nature of your organisation and support model, but in general, I would say a good process document has the following attributes:
✅ Process Owner
✅ Document Owner/Author
✅ Creation Date
✅ Document version (draft version control and final version approval)
✅ Alignment with associated policies and procedures
✅ Clear CSFs and KPIs (for measurement of effectiveness, efficiency, and conformance)
✅ Date of the last update
✅ Date of last/next document review
✅ Document reviewer(s)
When you are ready to design your template, here is a list of sections that you may want to consider to get you started:
⭕ Document Controls
⭕ Process Overview
- Purpose
- Scope
- Policy
- Objectives
- Inputs
- Outputs
⭕ Process Description
- Process Flow
- Process Steps
⭕ Process review, updates, and development
⭕ Roles and Responsibilities
⭕ RACI Matrix
⭕ KPIs and Reporting (efficiency and effectiveness measures)
⭕ Related Process and Documents
⭕ Appendix
⭕ Definitions (glossary of terms)
⭕ Document Version History
Lastly, whilst governance is beneficial, too much rigidity and inflexibility can be the opposite. Make sure you allow your Service Desk Analysts to use their judgement and discretion where needed. This needs to be coupled with a defined feedback loop into the process/procedure owner so they gain an understanding of why any process steps could not be followed as documented.
It’s all about continual improvement and collaboration; the focus on the end-user experience and the Service Desk Analyst experience are both key.
⚡ “I follow 3 rules: Do the right thing, do the best you can and always show people you care” – Lou Holtz.
I recently collaborated with a customer to design, define, and document over 60 policy, process and procedural templates, along with associated resources. The impact of this initiative has been immense, benefiting both their customers and their Service Desk/IT department.
With these templates in place, they now operate with a high level of consistency and enjoy excellent collaboration across teams. This enhanced operational efficiency is reflected in the improved positive user feedback they now receive.
In closing, I sometimes get asked, ‘I get what we need, but where do we start?’ Hopefully, the above guidance will set you on the right path.
I am a big fan of the ITIL® 4 Guiding Principles; when I think about any improvement journey, getting your “thinking” right and being able to make good decisions are vital, so it’s worth applying these principles as an overall approach. In terms of processes and governance, I believe all 7 guiding principles apply.
However, the ones that I always have most at the forefront of my mind are:
- Focus on Value
- Collaborate and promote visibility
- Keep it simple and practical
These will be good companions on your improvement journey.
Oh, and one last thought a colleague once told me “If it’s not documented, it’s a rumour!”
Get expert guidance and support to lead your team to success and achieve tangible results for your service desk and support team!
📞 Get in touch with our team today!
John Noctor
SDI Chief Delivery Officer
