This blog post looks at the transition of completed configuration into a Production environment and mobilising the teams who will be using ServiceNow. To fully realise the value of the investment, focus needs to be shifted from the tool and towards the overall operationalisation of ServiceNow. This includes training, communications, updating of operational work instructions and measures to be used in assessing benefits realisation from the implementation.
This stage of an implementation also starts to introduce many more stakeholders to the implementation, requiring careful management and co-ordination to ensure that the required deliverables are completed at a similar time so that there can be an informed decision around moving the changes to Production.
These operational readiness requirements are often overlooked in favour of focussing on the technical configuration. As a result, testing can be rushed and change can feel like it is being imposed on teams prior to go-live. This can result in a lack of user engagement and impact benefits realisation due to slow adoption and low interest in changing ways of working.
As part of the implementation the Sponsor and Stakeholders will need to choose between a “big bang” approach – implementing all of the functionality at once – or a “phased” implementation where the solution is delivered in potentially more manageable chunks, usually prioritised based on business needs and benefits.
A big bang rollout is typically a single go-live or “cutover” scenario where everything switches to ServiceNow at a single point in time. This could be a switch off of current tooling or retirement of a set of delivery processes. The benefits are that there is clean move to the new ways of working and system of record, with everything moving at the same time (Training, communications, testing, etc. However, at the same time there is significant risk to ensure that everything is ready at the same time and sufficient Operational Readiness has been achieved and agreed before making the cutover.
A phased approach is where the implementation happens in a series of predetermined steps. This can be achieved in a number of different ways, such as:
The benefits are that the risk may be considered lower, as there is potentially less business change at any one time and the scope can be broken into more manageable components.
However, the risks that that you end up ‘swivel seating’ processes between tools whilst waiting for further functionality to be introduced. Additionally, the business can suffer from change fatigue as processes and data get migrated.
In terms of what’s right, there are various factors to be considered, such as risk appetite, what budget and time available to the project and willingness of the organisation to adapt and change.
A Test Strategy is vital to help everyone align on a ‘definition of done’ with regards to the ServiceNow configuration. By documenting and agreeing what the entry and exit criteria are for each type of testing it is possible to objectively manage when configuration is complete and when everything is ready for Production.
The Test Strategy should be drafted and agreed with the required stakeholders early in the project and align all of the details required for a successful test such as:
If there are any additional regulatory requirements that the ServiceNow implementation must also comply with, such as Display Screen Configuration or Security Compliance, then these should also be built into this plan.
Additionally, if the ServiceNow Automated Test Framework (ATF) has been built into the Project Configuration (recommended) then this should also be considered as part of the Test Strategy. ATF can bring considerable time savings to the process of executing Unit and Regression testing but should not be considered a substitute for User Acceptance Testing.
The extent of these plans will depend on the level and speed of change expected as part of the ServiceNow implementation, as well as the size of the overall ServiceNow implementation. Again, the recommendation is to start looking at these plans early and assign a responsible owner who can work with Users, Managers and Stakeholders to establish what training needs exist and how to communicate with the Users to ensure that they are prepared and ready at Go-Live.
If training has been purchased from ServiceNow (or a Partner) as part of the implementation, then consideration needs to be given on who is best placed to receive that training based on their expected job role and timing the training in relation to Go-Live. Service Desk Agent training will be quite different to User Training and may also need to be completed at different times for different groups based on timing for UAT and Go-Live.
Communications plans will vary but the intent remains the same, ensuring that Users and Stakeholders are kept up to date with project progress and to enable completion of dependent activities in line with the project plan. These communications can be facilitated through project ‘Champions’ aligned to the project and who can facilitate onward contact with teams throughout the business, as well as channelling feedback to the project team. Consideration can also be given to User Forums, Communities of Practice and Town Halls to ensure that there is clear and consistent messaging to all Stakeholders around the project plan, commitments required from the business and readiness actions for Go-Live.
The extent and depth of operational readiness preparations will depend on the scale of the change being implemented and the overall culture of the organisation. If there is considerable change required in operations and ways of working, then more focus and effort will be required to drive that readiness.
The intent is to bring the operational teams into the Project and ensure that everything required for a successful go-live is considered and checked. Again, this goes back to understanding the ‘definition of done’ and to facilitate a smooth handover from Project to Run Teams (and not throwing something over the wall).
Consider an Operational Readiness dashboard indicating the key success criteria, their owners and the status. In the run up to Go-Live, regular sessions should be run to assess readiness and understand where focus needs to be applied to ensure readiness e.g. training of a particular team, missing operational documentation. Only when all of the Stakeholders are in agreement can the project consider moving into Production.
Overall, there are many non-technical aspects to consider as part of transition, as well as ensuring successful completion of the ServiceNow configuration itself. The Project Manager will need to guide and manage the Project Team and Stakeholders to ensure that these elements are planned and executed in parallel to the overall ServiceNow configuration, so that everything comes together at the right time to move into Production (either as a phase or big bang).
If you wish to find out more about how NWT could help you deliver successful ServiceNow Implementation please visit: firstname.lastname@example.org
Together, Anexinet and NWT are uniquely positioned to help clients streamline their journey to the Cloud in the face of the pandemic by designing, building, automating and managing their workloads and applications on Enterprise-Cloud or Cloud-Hyperscalers, including AWS, Alibaba, Google Cloud, and Microsoft Azure. The strategic partnership has already helped one established financial institution unlock significant value by accelerating the development and delivery of effective, integrated Cloud-based solutions. Anexinet’s proven Kickstart process and comprehensive set of tools and services deliver an Agile, scalable Cloud-based environment that embraces traditional IT as well as Private, Public, and Managed Cloud. Migrating applications and business systems to the Cloud is a daunting task for even the most mature organization. As a result, a Cloud-adoption strategy and roadmap often means the difference between successful deployment and failure to launch. Anexinet helps organizations determine their ideal strategic approach.