Process frameworks and standards are a guiding light in helping you define processes and assess their maturity, but they won’t lead you to the process Promised Land! These frameworks and standards provide little guidance with regard to process definition, and without defined and documented process, it’s hard to make them stick. With more than forty years of combined experience in process analysis and design, we’ve arrived at a tried-and-true formula for process documentation success.
To get started, you need to ask yourself some key questions. What would you do if you had just five minutes to prepare for a comprehensive walkthrough of your ITSM processes with a new employee, manager, or supervisor? What if an IT auditor unexpectedly stopped by your desk to review all of your process documentation? When you can honestly say “No problem. Bring it on!” that’s when you know your documentation is complete.
But we’re not just talking about “good enough to pass an audit” complete. The real value of a defined process lies in its ability to drive the behaviors that will improve the quality of the support your organization provides to its customers. If you keep that goal in mind, you have the potential to unlock enormous business value through improved response times, more effective communication, and fewer disruptions resulting from infrastructure or change failures.
All IT processes, ITIL-based or otherwise, have a recognizable anatomy. The parts that make up the whole include policy, diagrams, narratives, templates, communications, and reference materials. Each is an important component not only in defining your process but also in making sure you can effectively connect with the people expected to follow the process. When you understand the building blocks, it puts you in control and helps everyone achieve the shared goal of exceptional customer service. Let’s start with policy.
Documenting Policies
Policies are concrete expressions of the rules of engagement, the things you must do. Before you start drafting and documenting policies, you need to make sure you have support from your leadership. You can garner early support by drafting a policy and soliciting feedback. When you feel good about a policy’s content and format, get it in front of leaders and key technicians to gain buy-in before sharing it with the IT masses.
What are the ground rules? Good policies are current, relevant, accessible, and short. Don’t try to draft one overarching, all-inclusive ITSM policy; it won’t work. People won’t buy into a monster policy that keeps growing new heads. Instead, break the content into understandable areas; for example, have one policy for change and release management, another for incident and problem management. Keep policy statements focused on desired behaviors, not instructions; remember, a policy isn’t the place for detailed procedures. Above all, be confident. Just hearing the word “policy” can make some people uncomfortable. In some cases, you’ll get pushback. People might ask, “Who asked you to write a policy?” You may even start questioning yourself: “Who am I to write a policy?” Make sure you’re confident in your task and you can articulate how the new policy will improve the quality of the support your organization provides.
An ideal policy should contain the following parts: the effective date; the version number; the compliance criteria (i.e., the technology or people the policy applies to); the rules to be followed (not instructions); the policy owners; and links to reference materials and terms/definitions (this is optional). Also, be sure to identify any relevant activities that will drive desired behaviors and efficiency improvements; for example, be specific when it comes to acceptable timeframes (e.g., “You must acknowledge a Priority 2 incident ticket within fifteen minutes.”), but not oppressively specific (e.g., “Update your workflow tasks in a timely manner.”). And remember, when developing/drafting policies, be sure to use language and terminology that will resonate with the IT crowd. If you start to sound like a lawyer (“the party of the first part”), you’ll lose them fast!
Finally, the best way to drive policy compliance is through internal leaders. You’ll gain more buy-in and support when key technicians and experts understand the reasons for new policies. Also, get new policies physically signed by important people (like the CIO or group director); this demonstrates their engagement and personal support.
Diagramming Processes
While documented policies are a key driver of process compliance, the skeleton or framework of a defined process is best represented by diagrams and narrative. The process diagram is the symbolic representation of your process, broken down by activities, tasks and roles. Although it’s tempting to get extremely detailed, simple is better. One way to keep yourself in check is to look at the process diagrams your organization already uses and adopt that style. If your diagram still ends up looking too busy, break it up into multiple activities (using ITIL as a guide).
The ideal process diagram should be broken down into processes (areas/groups of related activities), activities (groups of related tasks), decisions (yes/no), and tasks (actions assigned to particular individuals/roles), and should include the following parts: the version number; the legend/key for symbols and acronyms; tasks, decisions, flow lines, off-page references, and exits; roles; and symbol labels/numbering, swim lanes, notes and callouts, and time indicators (these are optional). Make sure your diagrams flow from left to right, top to bottom. This eases the burden on the viewer. Also, only include activities that are part of the current process, and make regular updates when things change.
The reality is, not everybody can diagram well, so know the signs. If your diagram is turning into a convoluted nightmare, ask for help. There are always people in IT who are good at diagrams—application developers, trainers, support center—seek them out!
Finally, every diagram needs a description in the form of a narrative. The process narrative should include basic task instructions and identify inputs and outputs. Some tasks consist of several steps, so be sure to cover the pertinent details in detail. Document how each activity should be executed and what information is needed to execute each activity successfully. If you need even more detail, you can always link to additional references and resources.
The ideal process narrative should include the following parts: the version number; entry and exit criteria; inputs and outputs; details for each process activity corresponding to the diagram); and a list of metrics and the benefits to be gained (this is optional; include the list of benefits only if you can articulate them clearly). With the narrative, consistency is more important than design. It doesn’t need to be fancy; it just needs to make sense and be easy to consume.
Creating Templates and Reference Materials
Now that we’ve covered policies and process diagrams/narratives, there are a few additional components to consider, including the consumables or templates. Templates are used to capture information in a specific format. Some examples include change-risk matrix forms, change or CAB readiness checklists, product selection forms, business justifications for software, and asset exception forms. As templates are consumed (used), they’re typically attached or saved as inputs to process tasks. It is important to keep templates current and relevant, just as you would all other process documentation.
All defined processes should also include reference materials: guides, how-tos, cheat sheets, and detailed instructions. Here’s where you provide the details you omitted from the policy, process diagram, and process narrative; for example, detailed instructions for navigating the ticketing system, or specific instructions for participating in the weekly CAB meeting.
With all process assets, currency and relevancy is critically important. Solicit user reviews and take feedback and suggestions to heart. The better your documentation, the easier it will be to hold people accountable for following it.
So now you’ve got all the important components of a well-documented process. But how will people find it? Consider creating a process asset library (PAL). In its simplest form, a PAL is a shared location for storing process documentation; it can be a folder on the LAN, a SharePoint site, a wiki, or any other accessible shared location. Once you have a space for all of your process documentation, establish a file-naming convention. Consistent file naming reduces confusion and saves time, as a file’s area, content, and owner can be readily identified before the file is even opened.
Other features that will make your PAL a success include basic version control, sorting by file type, a designated librarian (if possible), and simple publishing rules/techniques. Some of these rules/techniques include publishing in HTML or another web format, hyperlinking within the process document, consistent navigation, active links (broken links mean broken processes), and reciprocal linking to related content and shortcuts.
Communicating Your Process
The final step of process documentation is training and communication. Compliance issues are often actually training issues. Investigate onboarding activities for new hires and reach out to training groups for their input and guidance—don’t be shy! Visit any team that’s open to having you sit in on its group meetings. Tell them all about new processes and be open to questions and improvement opportunities.
Managing Processes
Thus far, we’ve broken down the individual variables in the formula for a defined, documented process. But if we want to turn this defined, documented process into a managed process, there are a couple of additional components: metrics and a continuous process improvement plan.
Developing process metrics can feel like an overwhelming burden, so consider the following:
- Do your metrics tell a story?
- Are your metrics relevant and outcome-based?
- Do your metrics have a purpose, with realistic targets and baselines?
Effective metrics will help you identify improvement opportunities. Collaborate with your business customers to understand business impacts, and then set realistic targets with acceptable variances. Metrics can also be great conversation-starters, so use hot-button metrics where appropriate. If you have an issue with the responsiveness of certain teams, develop a chart to make these hot-button metrics stand out, and then publish it. It’s guaranteed to get some attention. And be sure to highlight achievements and jobs well done; when we exceed our targets, sometimes we surprise ourselves, but we always delight our customers.
The final variable in our managed process equation is continuous process improvement. Making this an annual activity is one way to ensure you don’t let your processes stagnate. Ask for feedback from auditing and incorporate their suggestions where it makes sense to do so. More importantly, use policy reviews to get your leaders to renew their commitment to existing processes and policies. Finally, as a process matures and becomes part of the organization’s culture, make sure your documentation reflects the new normal while continuing to drive discipline and desired behaviors.
* * * * *
It’s always difficult to keep up with resource changes and ensure effective onboarding of new processes. Collaborating and integrating with other process areas (e.g., SDLC, architecture, security, etc.) can be challenging. Gaining consistent commitment from leaders at all levels while keeping your eye on the ultimate goal of exceptional customer service can be exhausting. But when you have well-documented, well-managed processes, you can increase efficiency and quality, creating tremendous value for your customers. That’s a win, wouldn’t you say?
Julianne Vargo’s process work spans many industries, including energy, transportation, software, and now insurance with Westfield Insurance. She has more than twenty years of experience developing processes and coordinating training for IT. Julianne is an active member of her local itSMF group, and she currently holds both ITILv2 and v3 Foundation certificates as well as the ITIL v2 Configuration and Release Management practitioner certification.
Using his skills as a process manager and ability to network with all levels of the organization, Tony Cascaldo implemented a highly effective metrics scorecard at Westfield Insurance. He was also instrumental in the successful implementation and effective management of Westfield’s incident, change, and release management processes. Tony currently holds his ITILv2 and v3 Foundation certificates and his ITIL v2 Support and Restore certificate.