Documenting vs Deploying ITSM Processes

A Tale of Two Very Different Words & Goals As the lead of our Solutions and consulting practice at Pink I have the opportunity to review and respond to a great number of request for proposals (RFPs) related to adopting IT Service Management processes. A frequently observed phenomenon is the stated desire of the prospective client to adopt or implement in their words most if not all of the ITIL®️ processes with a 10 to 12 month period. There seems to be some belief that consultants have a magical ability to accomplish the impractical if not the impossible! The challenge we then face is how to gently explain the difference between designing / documenting a process versus successfully deploying one across an organization's functional silos and various service providers. It is my experience that most organizations are not able to adopt and deploy more than two or three processes in parallel at any one time and that the project will typically take 4 to 6 months depending on the scope, scale and specific process we are talking about. Process Documentation To baseline this discussion I'll define the concept of documenting a process as agreeing on, writing down and creating the following deliverables. Process Documentation including at a minimum the following artifacts:

  • Process Goal
  • Process Inputs and Outputs
  • High Level Process Workflow and Activity Description
  • Global Process Policies
  • Process Roles and Responsibilities including a RACI authority Matrix
  • Process Integration Points
  • Process Critical Success Factors and Key Performance Indicators

Following on from this list of project deliverables more detailed classification structures, priority models and tool-based procedures are developed and documented before and as the automation of the process is developed and deployed. ?Documenting your process should not take more than a couple of weeks especially if you start with a rich template set such as we have within PinkATLAS. We recommend using a process design team made up of both internal and external stakeholders. For more on this subject please read the following article. The Art of Building A Process Design Team - Sometimes the journey is more important than the destination!

Process Deployment If you are actually expecting to deploy and have your organization use the process the set of activities and therefore the resources required increases greatly! Now you are concerned with automating your process workflows and reports in a service management tool set. You need to consider the education and training needs of the people who are expected to follow the new process. To ensure that you manage the real challenge of actually getting people to follow your process once it is deployed you will need to carefully manage your education, communication and people change processes throughout the life of the program. For more on this subject see: Help! No One Is Following Our Processes! The Three Perceptions of Implementation The following graphic represents a typical roadmap we would help an organization define as part of the planning stages of their program and does a good job at showing the major component

pieces of a process deployment strategy. Initially we highly recommend starting with a baseline assessment for a number of reasons other than planning which are critical to your success. More: Why Bother With ITSM Process Assessments? Following the assessment we establish the overall program roadmap, internal process ownership, stakeholder roles and then begin engaging in the process documentation activities which are mostly completed in the initial 4 — 6 weeks of the project timeline. Following this step you will notice the yellow line under the green line represents the tool configuration, integration and workflow automation tasks. From Month 3 in this example the project takes on a tool focus with additional design being given to the tool specific procedures, approval flows or classification structures we mention earlier. It has been my consistent experience that the majority of process project timeline tasks (example: Months 3-5) are focused on tool-based activities as the critical path. Finally once the screens have stopped moving around you can develop your deployment training workshops on your specific “ABC Org” process which are typically held in a lab or classroom type setting and usually last 2-3 hours with 1/3rd process training and 2/3rds tool based / use case based exercises for the organization under the scope of the new process. This deployment training is not to be confused with the ITSM education examples on this graphic which are more about gaining organizational buy in and agreement on concepts, context and terms as part of your people change process. Now consider that the average process deployment project will have the following people requirements:

  • Process design team will include 3-5 people working part time on the design and documentation (not all of them consultants)
  • Tool administration roles (internal and software vendor) working on implementation, integration and configuration tasks (2-4 people)
  • Process Training development and then rollout (3-5 people) in addition to your workshop attendees

So on average I would say the average organization will have 6 to 8 people working on some aspect of the process project timeline while they also try to keep their real jobs going. Now stack 2 or 3 processes on top of each other in parallel design and deployment tasks and the number of resources becomes challenging to say the least! You might ask what about consultants? Please read the article above about the process design teams to consider the best way to leverage external resources and how not to use them. In summary while it is more than possible to design and document 24-26 ITIL processes in a couple of years you will most likely not be able to deploy more than 6 to 8 in that timeframe even going full out. As I mentioned above the average organization is able to deploy 2 or 3 processes at the most in parallel. For more information on setting up an ITSM program and successfully deploying new management processes please refer to the following article: Establishing Or Assessing An ITSM Program Troy's Thoughts What Are Yours? ”To get through the hardest journey we need take only one step at a time, but we must keep on stepping” Chinese Proverb

 

ITIL® is a registered trademark of Axelos Limited. All rights reserved.

Like this article? Like

Comments

Post a comment