A phantom process is not documented, measured, or managed, but somehow it gets done through tribal knowledge, heroic efforts, and at a substantial cost to the organization.
As an ITSM consultant, I conducted numerous ITSM maturity assessments. During these assessments, we looked closely at the service management organization, ITSM processes, and the tools used to manage IT services.
I learned through this experience that even the most dysfunctional or immature organization had some form of ITSM processes in place. The problem is that these processes were not formalized, documented, owned, or managed.
These organizations spend far too much time and money getting things done. This waste results from the amount of inconsistency and substantial rework in their processes.
Some examples of this waste include:
- Outages resulting from poor IT Change Management practices
- Fixing the same issue over and over due to poor Incident and Problem Management
- Dissatisfied users due to a flawed Service Request Management process, for example, confusion between incidents and service requests.
However, many immature organizations believe that the lack of defined processes makes them agile and less bureaucratic. Without defined processes and good measurements, they don't have the data to show them just how poorly they are doing.
What separates an immature organization from a high-performing one? Here are some of the basics:
- Processes have an owner responsible for ensuring the process is executed and managed.
- Process documentation exists, keeping everyone on the same page.
- Processes are measured to ensure they are delivering results.
- Processes are automated wherever possible to improve execution.
- Process training is available to the staff.
- Processes are evaluated and continually improved.
So, where does one start their journey to eliminate Phantom Processes? One place to start is to define your processes. The good news is you don't have to start from scratch. Adopting ITIL-based approaches can give you a head start.
ITIL Process Documentation
To begin documenting your processes, you need to appoint an owner for each one. The process owner is typically a senior manager authorized to enforce the processes.
The process owner can bring together a representative group of process stakeholders. These are people with subject-matter knowledge of how the processes work today. This team should include people involved in executing the process, users, and folks involved with the automation of the process.
Start with a straw model process based on industry best practices. There are many sources, including the ITIL books, ITSM consultants, or tools like the Navvia Process Designer.
A well-defined process should include:
- Description
- Goals and objectives
- Roles and responsibilities
- Activities and Tasks
- Procedures
- Workflow Diagrams
- Metrics, controls, and policies
- Glossary of terms
Another essential part is the process automation requirements, including:
- User Stories
- Technical and functional requirements
- States and triggers (for workflow automation)
- Metrics (for reporting requirements)
- User notifications
Check out these resources for additional information.
While process documentation is only one part of a well-managed process, it is a critical and great place to start.
Originally published Feb 01, 2018 17:51, updated May 27, 2022
