Reminder of the 7 Guiding Principles
Focus on value
Start where you are
Optimize and automate
Collaborate and promote visibility
Think and work holisticaly
Keep it simple and practical
Progress iteratively with feedback
Reminder of the 7 Guiding Principles
People generally feel uncomfortable when they have to change their way of working, so when we start a program that aims to harmonize and converge practices, we need to coax them gently to come onboard. The idea is to ensure that Processes, Tools and Organization are all defined as crucial pieces of the same value-driven program. Several methods can be used based on Agile Method, and Rapid is a specific method developed by Devoteam to deploy Practices including Processes and their tool. It has been used in several major transformation projects, in several domains: like banking, retail, and insurance.
Using Agile methodology will allow your stakeholders to ensure, step by step, that the product they want to deploy is fit for use and purpose. This is how we used this method for a strategic transformation program on a bank.
Deploying practices into an organisation can be very complex, as most of the time, several practices exist already, deployed through diverse tools and with a different organization / vision
On legacy system, Several IT Productions had their own practices and their own tool, with some interfaces existing between the different ITSM tools. Several of them were working on ServiceNow and others with BMC ITSM. The aim was to deploy the following practices on a ServiceNow platform in a short timeframe (less than one year for first deployment):
- Incident Management,
- Problem Management,
- Change Control,
- Service Asset Management,
- Service Configuration Management,
- Knowledge Management
- Service Request Management,
- Service Catalog Management,
- And, not a practice of course, a shared portal.
To ensure all topics would be deployed in the right sequence, we used Rapid Method for the project. We divided the project into several sprints; each sprint being part of a practice. Each sprint then had to address the 4 dimensions of the practice:
- Organization and People: who will be the stakeholders within the practice, their activities and their responsibilities?
- Information and Technology: what will be the tool to support the practice and which information will be used to deliver the service? This included discussions about the data to be integrated and in some cases protected.
- Partner and Supplier: identify all partners and suppliers who will be involved in the practice and how they will interact with it.
- Value Streams and Processes: identify and define processes.
To deliver this project, project governance defined some key messages which were communicated to stakeholders and which followed the ITIL 4 guiding principles (in brackets):
- Remain on customer needs and how they bring value to practice and stakeholders (Focus On Value),
- Keep in mind that we should follow as closely as possible the ITIL Best Practices and ServiceNow principles (Keep it simple and Practical),
- The method always builds on the results of the previous workshop, to be able to integrate any feedback prior to deployment (Progress Iteratively with feedback).
As shown on the diagram, Rapid Method is composed of 6 steps:
With several loops for Discover / Prepare / Deploy prior to the Go Live.
Let’s look at these steps in more detail.
The first step was to initiate the project and, in particular, to decide how we would progress, by identifying the major practices to be defined in a first phase. The choice of the most mature practices was made, and those with the highest impact on the current organization: As a result, Change Adoption was considered essential and the following practices were integrated: Incident Management, Change Control, Service Configuration Management, Asset Management, Service Catalog Management, Service Request Management.
Problem Management, Service Level Management and Knowledge Management were dealt with later during the project, but were deselected in the first phase.
At this stage, we describe how deployment would be carried out and how interaction would be managed during transition time.
Another part we had to deal with was the identification of Stakeholders, especially process management members: legacy Process Owner and Process Manager and also operational attendees.
Last but not least, during this planning phase, a specific focus on possible risks associated to the project had to be addressed. We chose to mitigate these risks and defined owners to follow up.
Discover phase, the starting point of the practice definition, aimed to identify the requirements of each stakeholder. To ensure that they all agreed on the solutions to all questions, decisions were made at a workshop and were then developed and presented in terms of process and/or tool at the next workshop. (Collaborate and Promote Visibility)
At each workshop, the agenda included a slot for presenting a different part of the practice, including all four dimensions, to ensure that every participant understood everything.
The diagram below shows for instance the agenda for Incident Workshops.
During the workshop, we began presenting the current processes and tools. This step allowed the stakeholders to share their needs, and how they had been deployed (Process, Tool or Organization answer) in their legacy and to be challenged. This shows also that a same need could have been addressed in different ways (Start where you are).
After the presentation of each production, we consolidated all aspects of the business need in a solution that fit with the different requirements, based on ITIL Best Practice and ServiceNow Standard (as ServiceNow is the target tool in our case). Different options were presented with the target to Keep it simple and practical.
Depending on how the need is articulated, several approaches are possible:
- If the Answer to the business need is about Organization: Point is escalated to correct instance to appoint the resource,
- If the Answer is about Processes: The Process Guide is updated and communication is made with people using the process,
- If the Answer is about the Tool: if the modification is configuration one, it’s added to backlog, if customization, it must be validated by governance.
This answer will be tracked through a User Story that will describe a business need, added value and the different impacts (see more detail in Governance part).
At the beginning of the next workshop, governance decision is shared with stakeholders and the result is presented either in terms of process or in terms of tool.
Based on the results of each workshop, we identify what information to collect, which features to activate on the tool and adjustments to carry out on the Organization, …
As soon as the project governance has validated answers to requirements, User stories are added to Backlog to be developed in accordance to priority and availability within the sprint. As soon as User Stories are added to the backlog and developed, the team ensures that:
- Unit tests are carried out and the result is identified, to be presented at the next workshop.
- Documentation is updated (Process Guide, Operational Manual, …).
This objective of this step is to validate the process and tooling, based on an endto-end test. This will enable stakeholders to confirm the result of their choices. To simplify and limit time-consumption for attendees, we decided to make a single “Operate” phase at the end of the integration.
Prior to Go Live, there is communication with future users of the solution, in front and back office, with regard to opening ITSM service, and resources are mobilized to support the Early Life Support.
Service is delivered in production and Early Life Support is in place with enforced support, to ensure that incident and service requests coming from users (End Users and IT Users) are handled correctly and communicated at the right level.
Governance Committee remains mobilized to react quickly and reinforce the plan if necessary. This early running stage is key to identifying if some points are missing
To ensure this kind of project succeeds, we have to define the right governance, taking into account the four ITIL 4 aspects. Practice owners analyze and present new needs, as soon as they arrive, and prepare for Governance Committee that takes place every two weeks. They will present the result of their analyses to other Practice Owner and the solution owner, based on:
- Functional need,
- Added Value,
- Associated workload (if applicable),
- Risk to do,
- Risk not to do,
- Impact on Other Practices,
- Impact on Deployment,
- Impact on Maintenance (if applicable).
For each item, a description is given and an estimate of the value (Green / Orange / Red) to facilitate decision-making.
During the Governance Committee, User stories are detailed and discussed with the community, including, during the project phase, Project Manager, Process Owner, Platform Owner. This governance approach is established for the transformation project, and must be followed after the project, to ensure a global coherence of practices across the group in the long term.
This committee meets every two weeks during the Project and then needs to stay in run mode to ensure that the platform remains under control.
The project we described is now entering the deployment phase in the different entities. Here are the main conclusions for the 4 first months:
- Manage to converge the following practices: Incident Management, Change Management, Service Configuration Management, Service Asset Management, Service Catalog Management et Service Request Management,
- Define a common CMDB for the whole entities,
- Definition of the roles needed in the target organization,
- Define the consequences in terms of tool
The second step dealt with 2 new practices in two months: Converge Problem Management and Knowledge Management practices. We also defined a common vision for Service Level Management.
So, as you can see, Rapid Method such as any Agile method could be used to deploy practices themselves, with the 4 dimensions of Service Management. It’s undoubtedly the best way to convince stakeholders and get them onboard. The result will be confidence in processes, tools, organisation and relationship with the designated partner.