7 steps to a successful itsm tool implementation

7 Steps to a Successful ITSM Tool Implementation

Welcome to the Presentation!

• CEO & Co-founder of Navvia

• 30 plus years of Service Management Experience

• Twitter: @mainville

• [email protected] Mainville

April 2014 Copyright 2014, Navvia - A Division of Consulting-Portal 2

“It’s seldom the tool that’s the problem”


Why do you think ITSM tool projects fail?


The vendor says no need for process, it’s “out of the box”….

…Consensus takes too long & it is hard work

We’ll just do a “lift and shift” from our old tool

...The last project that focused on process failed

Our management says “6 months? Just slam it in”…

…It’s SaaS, just turn it on


7 Steps to a successful ITSM tool implementation

Identify the GAPS – the goal is to improve things

Don’t start from Scratch – great templates exist

Don’t try this on your own – isolation kills adoption

Don’t be a technophobe – capture requirements

Don’t forget to validate – helps with the buy in

Remember to educate – critical for adoption

Govern the process – left in isolation the process will die


Identify the gaps• Why are you implementing

a new tool?

• What are the pain points with the current system?

• What are the capability gaps you are trying to close?

• Do you understand the users point of view?


Identify the gaps

Tool Strategy & Plan

Questionnaires

Interviews Workshops

Observations


Build a roadmap

CurrentState

FutureState

Quick Wins

ProcessEnhancement

TechnologyDeployment

OrganizationalChange


Don’t start from scratch• What are you doing today

from a process perspective?

• Are there templates or standards you can leverage?

• What is being employed in other areas of your organization?

• Can you leverage other programs (ISO, Six Sigma…)


Best practices, by their very nature, are absent of your company's organization, business, cultural and technology requirements

To realize the full benefits, organizations must re-introduce their own reality


Remember This?


Keep the diagrams simple!

Remember your audience…less is more!


Anatomy of a Process

InputsThe objects or data

required to complete the activities

ActivitiesThe specific steps required

to convert inputs to outputs

OutputsThe desired work

products or data. May be input to another process.

ControlsThe policies and guiding principles defining how the process will operate

MeasurementsThe activities and metrics to ensure the process meets requirements


Anatomy of a Process• Overview

– Description, goal, objectives, roles, related documents and glossary of terms

• Workflow– Activities and tasks– Task details

• Inputs, outputs, roles & duties, tool & data specs and procedures

• Controls– Control objectives, metrics,

policies and governance tasks

• Specifications– States & triggers, tool & data

specifications and notifications


Process Design Artifacts


Don’t try this on your own• Processes built in a vacuum, in

isolation, will not get adoption

• People need to understand “why”

• Do you understand your stakeholders requirements?

• Are you actually making things better for people?

• Balance consensus with getting things done


What’s in it for me?

“Why should I embrace your vision or change, what’s in it for me”?


Everyone has their own perspective…

Shouldn’t IT just work? I’ve got a business to run and services to deliver

How do I demonstrate that IT is aligned to the business?

I&O is consuming 60% of my budget, I can’t fund new projects

Those users just don’t understand!

The CEO The CIO

The IT Manager The Technical Staff


Who Needs to be Involved?

Core Team

S.M.E.’s

Stakeholders

Steering Committee

Level of engagement diminishesLevel of accountability increases


Don’t be a technophobe• Out of the box seldom works

• Map business outcomes to tool and data requirements

• Identify the mandatory fields, define pick lists, figure out the triggers

• Make sure you are capturing the right data to produce metrics


Business Outcomes must drive IT

Business Outcomes Requirements Processes Tools and

Technology

Start Here

Not Here


Mapping Process to the Tool


Detailed requirements


Process Design Timeline

Simultaneous Process and Technology Design

Process Path

Technology Path

Process & Technology - You can’t do one without the other!


Don’t forget to validate• Iterative process design

• Use of “show & tell” sessions

• Watch out for scope creep

• Validate often and get sign off against requirements

• Be wary of “I didn’t agree to that…”


Remember to educate• Training fosters adoption of

the processes

• Build an education curriculum and plan that addresses all your stakeholders

• Consider various training formats from CBT to instructor led

• Consider using people involved in the process to do the training


Education

Curriculum Development

Content Development

DeliveryVehicles

Testing and Certification

EducationPlan


Govern the process• Define the controls, policies &

standards then make people accountable

• Define your governance organization and structure

• Define the controls & frameworks you are required to report against

• Governance is key to CSI

• Governance of cloud applications means extending your controls to your vendor

– Remember, you are still accountable


ITSM Governance & Service Delivery

Series1

Actual Service Levels

Desired Service Levels

Ungoverned processes “wear down” over time

The result is service variability versus consistency

More effort to manage / less customer satisfaction


Don’t be one of the statistics!

Understand what’s broke & build a plan

Collaborate with your stakeholders

Save time, don’t start from scratch

Define and capture your requirements

Validate, Keep asking if your on track

Educate to drive adoption

Govern to ensure accountability


We are a Software and Service company dedicated to helping organizations Navigate IT and Business

Process Complexity Via our tools and services

Over 14 years of ITSM success!


The Navvia Process Management Platform

March 2014 Copyright 2014, Navvia - A Division of Consulting-Portal 33

Free trialwww.navvia.com/test-drive

Thank You!David Mainville

[email protected]

Twitter: @mainville


mailto:[email protected]

Appendix


Process Design Project

1.0Initiation

2.0 Discovery

3.0 Process Design

4.0Technical

Design

5.0 Build

6.0 Test

7.0 Rollout

Work Breakdown

April2014 Copyright 2014, Navvia - A Division of Consulting-Portal 36

Approach & DeliverablesActivity Approach Deliverables

InitiationVarious meetings and planning sessions.

Kickoff meeting with senior management in attendance held live, broadcast via WebEx

and recorded

• Approved Statement of Work / Project Charter• Resources identified and scheduled• Project kickoff presentation created & delivered to

all stakeholders• Project reporting and signoff criteria documented• Status meetings and post project review scheduled

Discovery

Combination of online questionnaires, interviews, workshops, along with a

thorough review of background materials including current systems, documentation

and other existing process

• A stakeholder analysis• An inventory of current practices, documentation

and supporting tools• An evaluation of current process with specific

recommendations for improvement (people, process and technology)

• Quick wins

Process DesignA combination of process design workshops (up to 10) and validation workshops (2) to design a process that meets the needs of

your organization.

Process documentation that includes:• Description, goals and objectives• Inputs, outputs, controls, policies and metrics• Activities and tasks• Detailed process flows, RACI diagrams and other

artifacts to effectively communicate the process



Technical Design

A combination of technical design workshops (up to 16) and validation workshops (4) to

design and develop a set of technical specifications in support of tool

implementation and process automation.

Technical design document that includes:• Tool and data specifications down to field types• States, state transitions, triggers and state diagram• Notifications, message content and notification rules• Screen design and layout recommendations• Integrations identified

Build

Design review sessions (4). We will also conduct separate workshops (4) to develop the use cases needed for testing. We also capture ‘screen shots” of the customized

application in order to develop role-based user training.

• Schedule / facilitate the design review sessions• Documented feedback to the developers• Oversight that the tool implementation is on-track

and is in adherence to the documented design• Documented use cases and testing scripts

TestAssemble testing team and assign test cases. Review test results and provide feedback to

design team. Continue with the development of training materials

• Oversight and guidance throughout the testing• Role-based user training including PowerPoint slides

& student guide• Documented training plan and schedule

RolloutConduct train-the-trainer sessions, schedule and conduct training. Collect user feedback

and modify training accordingly. Record training for offline delivery.

• Schedule training sessions• Training delivery• Recorded training content• Training feedback and CSI


Project Plan

Approximately 18 weeks from initiation to an implemented process
