Integrated ITSM Project Plans

Successful ITSM Project Plans Integrate 4 Core and Dependent Work streams It culture and method has a pre-disposition to work in silos and this can often be translated to how we tackle IT Service Management projects. What I have often observed is that separately managed projects with their own project plans will be established for process work, tool configuration and the orchestration of a Management of Change strategy. The challenge with this silo approach is that it promotes a dis-connect between dependant work streams that need to be coordinated and scheduled in an integrated manner. Pink's recommended approach is to establish an overall project plan with at least 4 core sections for each ITSM service improvement project. Each of the 4 core sections may have a separate project owner but the initiative is managed as a coordinated whole rather than having for example a separate process versus tool project. I specifically reference 4 core work streams as illustrated in the diagram used for this article however certain ITSM projects will have additional work streams for example: (A Service Asset and Configuration project will have a data work stream, A Service Catalog project will have a Service Definition work stream, A Financial Management Project will have a Service Cost Model work stream) each equally requiring integration with the 4 core work streams discussed in this article. For the purposes of this post we will focus on the 4 core and common work streams for any ITSM Improvement project. At Pink Elephant we leverage Project Management concepts found in both Prince 2 & Agile Project Management. Primarily we believe it is critical to manage ITSM projects in a stage gate (go / no go) approach as well as to ensure iterative prototyping and quick wins identification through out the lifecycle of the project and deployment stages. The following diagram illustrates the 4 core work streams:

• Process: The development of the high level and detailed process deliverables such as Policies, Process Flows, Roles, Procedures, Classification Structures, Approval workflows, metrics and support for post deployment coaching.
• Tools: The development of requirements, selection of new or existing tools, process/workflow configuration, Integration to other tools, report development and lab based deployment support.
• People: The identification of project resources, definition of process roles, RACI development, process skills training development and the execution of process deployment workshops.
• Governance: The identification and establishment of a tiered enterprise and distributed process ownership structure which will participate as key stakeholders during the project phase and own the accountability and responsibility for ongoing Continual Improvement. Adjustment of organizational reward and measurement systems to ensure support for the new process behaviours are realized and embedded after the project closure

Note: It is our experience that organizations often neglect the Governance work stream which results in the initiative's ultimate failure despite the project having been run successfully up to project close. This is a subject I addressed recently in the article “Help No One Is Following My Process”

When setting up your initial project plan we recommend the following general stages. Based on Prince 2 practices each phase should have a key stage gate decision before the project should be approved to move forward. Baseline Assessment: For reasons I have documented in the article “Why Bother With Process Assessments” we highly recommend starting with a baseline gap assessment.

• Stage Gate Decision: What areas of improvement will be handled as targeted service improvement initiatives managed by specific stakeholders and which processes should be improved using a formal improvement project?

Project or Roadmap Planning: Using organizational, process, tool and cultural knowledge gathered in the Assessment Phase you will now define your scope, project charter, steering committee, project plans and high level (Management of Change, Risk Management, Communication Plan, Education Plan) requirements

• Stage Gate Decision: Is there a business case for the project, is it funded to move forward?

High Level Project Deliverables: This stage of the project focuses on answering and documenting the “Who, What, When, Where and How” questions. For example: Who is the owner, what is the process, what are the roles, what are the general tool requirements.

• Stage Gate Decision: Is their political and organizational agreement on the high level deliverables? (It is critical not to move forward with the detailed and more difficult work until these questions have been answered positively otherwise the project continues to spin back to basic assumptions causing the time and cost of the project to expand beyond tolerance.)

Detailed Project Deliverables: This stage of the project focuses building on the agreed definitions of the high level project deliverables and includes activities such as: The development of detailed procedures including tool usage; The definition of complex classification and approval structures to be automated in the tool; The creation of skills based training materials for use during deployment; Targeted advanced education for key process stakeholders and owners; The definition of the process and tool deployment strategy.

• Stage Gate Decision: Following the completion of all detailed project deliverables a decision is required to move the process to production based on the agreed deployment strategy. This is a careful assessment to validate if all the required deliverables, conditions and organizational elements are in place to support a successful deployment and hand off to the ongoing governance structures and roles

Deployment Phase: During this phase deployment workshops and training sessions are run in batches with segments of the in-scope departments and groups. The level and type of deployment training will depend on the role being trained. For example: Is the person part of the process or a customer which interfaces with the new process and tool. Typically workshops are 1-3 hours in length and will comprise part process and part tool type training conducted in a lab or online classroom environment. The period of deployment will vary in length based on which ITIL®️ process is being deployed and how distributed the organizational and geographical scope is. It is good practice to keep the process design teams in place as an after care or coaching team for a period of time following the completion of all process deployment tasks.

• Stage Gate Decision: The final stage gate decision is to close the project. It is a good practice to conduct a project lessons learned review at this time for use in future planning and ITSM ininitatives

At Pink Elephant we have used this gated approach to successfully assist many organizations deploy and adopt ITSM best practices and I trust that these concepts assist the readers of this blog to gain a higher degree of success for what are challenging transformation projects. Troy's Thoughts What are Yours?

• In this world there are four kinds of people:
  • Those who make things happen
  • Those who watch things happen
  • Those who have things happen to them
  • Those who wonder what happened

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

Like this article? 1 likes

View Comments (6)

Post a comment

Your comments:

Your name:

Your email:

Remember my personal information
Notify me when someone replies

Please type this word:

• Previous Post
• Home
• Next Post