No matter how much you know about what value you wish to capture and what objectives you would like to achieve, a program is only successful if you execute it properly.
This chapter takes a thorough look at the various dimensions to consider when planning your program implementation, the common failure scenarios (and how to avoid them), and the roles each member of the implementation team should play (or not play). You will come to see that a successful implementation is never about how spectacularly the project solved a single problem or decisively made a single decision. Instead, successful projects are constructed from a combination of clear vision, clear plans, and checks and balances. In this chapter, we will cover the following:
We will see how these activities contribute to the ultimate success of your implementation. Within each dimension, we will highlight common techniques, patterns, and methods. We will also discuss how the project team, both internal and external to your organization, should contribute to the success of the activity, and common pitfalls to avoid.
Defining the project’s scope is a critical part of the success of your project’s implementation. Without a clearly defined scope, your ability to measure whether the value of the project has been achieved will be made more difficult. In addition, the project team and any governance and decision-making structures created for the project will be significantly less effective at making decisions and taking action. Scoping a project should not just be about defining what should be done. Well-crafted scope includes insights gained from careful planning that can guide the project team in understanding possible risks, better prioritizing areas of uncertainty, simplifying solutions, and avoiding over-stretching their resources on out-of-scope activities (i.e., scope creep).
There are many other places where you can find guidance on how to define a project scope. We will therefore highlight the aspects that are specifically important to ServiceNow implementations to reduce the amount of overlap between perspectives.
For any project, the following components are critical to be defined within the project scope documentation.
When this project is over, what will have changed? A project vision can provide a concise summary of what the project is meant to achieve. The act of creating the project vision is also a useful litmus test for seeing whether the key stakeholders and project sponsors are aligned at a high level.
Project visions should be concise and allow the project team to quickly determine, “Does what we do contribute to achieving the project vision?”
When creating the project vision, it can be extremely helpful to articulate the vision in terms of changes to the current states of particular stakeholders. This technique allows us to create vision statements that starkly highlight the change that the project is expected to deliver. Taking an approach of highlighting anticipated stakeholder changes can also help avoid the common pitfall of having a vision statement so general that it fails to provide any useful guidance in practical terms. For example, “increase the automation of IT support” is of less practical use than “IT customers requesting for services will require fewer steps than before to request for their services.”
Guiding principles are a set of objectively measurable statements that can help determine how to make the right decisions to achieve the project vision.
Project guiding principles should be written in such a way that if every project decision meets the requirements of the guiding principles, then the decision should almost be guaranteed not to negatively impact the realization of the value of the project. Guiding principles can often be even more critical to define than detailed functional requirements from a scope perspective, as they are much more effective at enabling teams to deal with uncertainty, a key factor in delivering a successful implementation.
It is important to use guiding principles that are clear in their application. For example, a guiding principle of “always think of the customer first” sounds great in principle but is practically less useful at helping guide decision-making than a guiding principle that may say “the project should never make decisions that increase the number of steps taken by a customer to obtain a service,” or “the project should never make a decision that increases the average time to service of the customer.”
This is not to say that more generic statements are to be entirely avoided, as they can sometimes be helpful to orient the project team toward the right dimensions to consider. In the previous example, the more generic guiding principle may still be valuable if it is to be used to help an operations-centric team make decisions that are more considerate of the impact on customer experience.
During project execution, additional guiding principles that target workstream level nuances (e.g., having an additional set of guiding principles for a customer portal branding and experience) may be created, but for the purposes of scoping, a single set of concise guiding principles to inform the entire project should serve as a sufficient starting point.
Example guiding principles include the following:
Having a list of current state processes that will be in the scope of the transformation is a great starting point for identifying the stakeholders involved and perhaps finding stakeholders that you may not have been aware of in your initial ideation of the project. When identifying processes, it’s helpful to inventory the organization’s actual operational processes instead of using ServiceNow’s module processes or the Information Technology Infrastructure Library (ITIL) processes. While these standard process lists can serve as a useful starting point, they may be too generic to capture the full scale and scope of the transformation that the organization needs to undergo to achieve value.
For example, in many organizations, incident management in the ITIL sense can be several operationally distinct variants with the same high-level objectives. If a dimension of value is to consolidate these distinct sub-processes (and disparate technologies that may be supporting these distinct processes), then capturing the specific number of distinct incident processes in operation can be an important step toward truly understanding the scale and scope of the transformation.
The preceding example of distinct variants of a standard process such as incident management may sound absurd but is not uncommon, especially if your goal is to use ServiceNow as the single incident platform across multiple parts of the organization.
Typical situations where you may encounter operationally distinct variants of the incident process include any organization with customer-facing teams versus internal teams (e.g., support teams for customer-facing technologies operating distinctly from internal IT support), or organizations with very distinct IT groups due to factors such as historical acquisitions or disparate geographical locations.
Identifying and placing appropriate guard rails around the scope of change in these cases can be critical to the success of the project, as attempting to merge these variants into a unified process (or accommodating these variants in the platform) can be time-consuming and will be made even more difficult if the appropriate stakeholders have not been initially engaged in or brought into the transformation.
As much as possible, it is important to decide upfront how the success and value of the project are to be measured. It takes preparation to do so, just as showing improvement in the target state requires that you first obtain a baseline of the KPIs. To further complicate the process, the way a KPI is measured in the current state may be different from the target state if a significant process change occurs as part of the implementation. It is therefore important when defining the success measures of the project that the scoping team do the following:
Establishing KPIs is a lot of work but is often worth the effort. It not only provides the project with an objective measure of success but also works as a way of focusing the transformation: requirements or proposed changes that do not contribute to the improvement of the target KPIs can be de-prioritized in favor of changes that do.
If possible, it is always good to capture and include the functional requirements for the target state in the scope to provide an upfront level of detail for the implementation that can help better identify potential risks of the project. Functional requirements can also be used as a tangible way of measuring the completeness of project implementation. Well-written functional requirements can easily be verified against the target state implementation to see whether each has been fulfilled.
A common pitfall of creating functional requirements as part of project scoping is taking an approach of collecting requirements by committee. Sending a functional requirement template to various stakeholders with little to no oversight of how the individual requirements fit together into a cohesive, working process can lead to a confusing and conflicting list of requirements that will be difficult to streamline into a working solution during implementation. It is therefore recommended that if requirements are to be built ahead of time, a team comprised of at least one seasoned platform architect and supporting functional designers is leveraged to help organize the functional requirements into high-level working design ideas.
Furthermore, tying functional requirements into the inventory of current state processes can bring even more clarity to the desired outcomes for the implementation team. Diagramming these workflows in a swimlane diagram or another visual format will help to align the processes and can avoid costly technical rework down the road.
As ServiceNow implementations take place within an existing platform with out-of-the-box capabilities, technical requirements at the time of scoping should focus on specific capabilities that require special accommodations not found directly in the out-of-the-box platform capabilities. Some examples of such considerations include the following:
The scoping of technical requirements for a ServiceNow implementation should take an informed approach to avoid over-specifying requirements that are provided for by the platform out-of-the-box or are beyond the capabilities of the platform. For example, ServiceNow transparently recommends that the system ought not to be used for fully real-time applications or applications with complex graphical rendering requirements (e.g., producing 3D images), and any should trigger an evaluation of alternative technology choices.
When scoping the project, a balance should be struck between how much detail to include in the scope of work versus how much should be left open-ended or high-level. There are multiple trade-offs involved and there are no clear answers on exactly what is the right level to provide to the implementation team to deliver. There are, however, a set of guidelines and rules of thumb that, if followed, can provide consistently good results.
Having the internal project team flesh out the details of the project scope can be more effective than bringing in third-party expertise. While external experts can help facilitate the discovery of these details, they are often limited in the advice they can provide for areas that may be highly dependent on the specific goals, objectives, or organizational model of the business.
In other words, third-party consultants may be able to provide the techniques and tools for understanding the project but are less efficient at collecting the actual details themselves because of additional time required to form a complete understanding of organizational nuances. Therefore, an important function of collecting the following details is to help all the parties involved to be more effective by understanding the landscape of the scope of work and its known risks and uncertainties:
When defining KPI measurements, it is not enough to simply list the names of the metrics and then move on. Instead, how the KPI will be measured should be clearly defined, and measurements before the start of the project should be taken to formulate a baseline that can then be improved upon. Determining what and how to measure could often at a glance seem intangible or difficult to do. It is a science on which entire books have been written, and it is highly suggested that project leadership begins with careful planning and prioritizing these measures, either internally or by consulting with external experts:
Mapping this list of stakeholders and decision-makers against the in-scope processes and sub-processes can provide the final layer of insight to guide the project team in designing and implementing the target state changes to meet the project objectives. As we will see in the subsequent sections of this chapter, understanding the decision-making landscape of the project is a critical tool in accelerating and improving the project’s ultimate outcomes.
With the scope appropriately settled, it’s time to think about the second aspect of successful implementation: determining an appropriate timeline for your project that accommodates the various releases and release activities.
The obvious reason why a timeline should be established for the implementation program is to attempt to gain certainty over when the value and returns on investment will be realized (or begin to be realized). A less obvious reason is to use the timeline as a way of establishing constraints that can help the project team and the organization focus more clearly on outcomes and goals.
Due to the inevitable existence of uncertainty and risk with any project, planning the timeline and release strategy can often be an art form. Some level of uncertainty and risk is inevitable, but it is possible to use a series of guidelines and guiding principles to estimate the timelines of a project and determine the appropriate release strategy.
In this section, we will present a list of considerations, strategies, and techniques to be considered as part of your release and release activity planning. It is important to keep in mind that determining how long and how to structure these release activities often comes down to an exercise in risk management. Allotting more time to ascertain that each activity has been completed to a high degree of detail and quality will reduce the risk to the implementation and value realization. Moreover, occasionally taking reasonable risks by reducing time, or parallelizing activities, more often than not, may enable the organization to realize the value more quickly. While the balance of risk versus reward is something that must be weighed against each project differently, the strategies and activities to consider are consistent and therefore summarizable in the following sections.
In the spirit of agile methodologies, projects should release whenever value can be realized by the release. This is frequently summarized as “release early and release often” in product development. In the enterprise transformation and major enterprise platform implementation space, there are additional complexities to consider in the form of negative business impacts caused by the replacement of an older but more complete solution for a newer but more limited solution.
This impact risk can be particularly acute with the first release of a major enterprise platform meant to replace an existing solution – for example, ServiceNow replacing an existing IT Service Management platform, or ServiceNow replacing a customer service management ecosystem. In such cases, there are often significant legacy capabilities and processes with significant dependencies upon each other. A ServiceNow implementation targeting only a small subset of these capabilities may cause either an unintended impact on the out-of-scope processes or be forced to make undesirable concessions in target state design to maintain the operation of those processes.
Therefore, for enterprise deployments, effort should be spent on determining the point in time that brings both net new value to the organization and has a reduced impact on dependent but out-of-scope processes. This does not mean the release timeline should simply wait until all legacy capabilities have been replaced. Instead, it means that for very complex organizations and environments, more time and resources should be invested in creating short to medium-term interim states. This will help bridge any gaps a new deployment may initially cause to dependent but out-of-scope processes to enable earlier releases of value in specific areas of the project.
For example, an HR service management implementation may be able to quickly bring new automated HR service requests with substantial cost savings on a new HR service portal, but it may take significantly longer to replace all the components of the existing HR portal. In such a case, it may still be worthwhile to have an interim state where both portals exist, but strong communications and modifications on the legacy portal will be put in place to direct employees to the new portal and its automated services in the interim. This allows the release of the automated functionality earlier without impacting employees who still need access to the capabilities on the old portal that are not available in the new one yet.
Planning releases to maximize value and minimize impact extends not only to when releases can happen but also to where. For large global deployments, for example, it might make sense to release the target state regionally if the impact of change can be isolated. In HR service management projects specifically, regional release opportunities can often be found. This is because, due to regional legal requirements, even the most unified HR organization can operate independently at the regional level.
Do not neglect dependencies on external groups and teams when planning the release. As part of the release plan, consider the availability and readiness of the following:
Plan sufficient time and resources for data migration and data validation. Whenever possible, minimize the amount of current-state data that must be migrated to the target state. Data migration can be one of the most time-consuming and complex components of a transformation. Complexity is not only caused by the potential volume and quality of data to be migrated but also because of operational impacts that may occur during the migration process. When it comes to migrating data, simple is often better. The following is a list of important factors that should be considered in your migration strategy to de-risk your release.
It may be an easy assumption to make that all data from existing systems will be migrated to the new ServiceNow system as part of a major implementation. However, there are multiple risks involved in legacy data that should be considered before deciding to migrate the data.
First, the quality of the legacy data for providing reporting and other business value insights should be considered. Data quality issues and a lack of good business data are major reasons for a large IT technology transformation and so a blanket migration strategy will often bring data of dubious insight dubious insight or quality into the target state may impact the subsequent value realization of the transformation.
Secondly, and possibly harder to recognize at the outset, is the complexity of transforming legacy data to conform to the target state. Major transformational implementations will typically lead to the adoption of new target state processes, procedures, and ways of working both inside and outside of a system. This change is likely to fundamentally change the definitions of business data between the current and target states. In a very simple example, if in the target state, incidents can automatically close if they have been resolved after 5 business days but in the current state, it takes 10 business days, then all target state metrics will automatically be impacted by the introduction of data from the current state. In more extreme examples, entire process steps or procedures may be altered, eliminated, or added in the target state, which can make the business data in the target state wholly incompatible with the legacy data from the current state. In these situations, data migration of legacy data should be carefully considered. At the very least, migrating the legacy data into an area separate from the target state data may reduce both its complexity and impact on future reports and metrics.
Sometimes, data migration is unavoidable – in these situations, it may still be worth considering what parts of the data should be migrated and where.
For operational data, try migrating to a legacy area or archiving the data. Operational data includes things such as open tickets, historical tickets, and active cases: data that is operated on by humans and viewed by humans as customer requests for services. There are usually two primary reasons why operational data should be migrated in the first place:
If archiving is not sufficient, for example, because the data needs to be more readily available, then consider migrating the data ‘as-is’ into a separate area than the target state data model. In this model, the current state data is essentially migrated into the target system in a ‘like-for-like’ manner and stored independently. Some linkages can be made between the legacy data and the target state data (for example, legacy incidents can be linked to target state users), but no transformation is done to make the legacy data conform to the format of the new data. This strategy reduces the complexity of data transformation logic and eliminates the impact of legacy data on the target state metrics.
When using a sunsetting strategy, there should be an estimate made on how long the interim period will last. One way of estimating this time is by measuring how many new tickets are opened in the current state and how quickly they are closed on average. This will determine the throughput of the teams closing new tickets and this throughput can then be used to anticipate the length of the interim period. For example, consider that 100 new tickets are opened per day and teams close on average 50 tickets per day. Then, the length of time needed for the cutover period will be the existing open ticket count at the time of cut-over, plus 100 tickets per day during the cut-over, divided by 50. In this case, if the cut-over itself takes 2 days – during this time, the legacy system will still be used - and there are 300 other tickets in the system when the cut-over begins, then you will need approximately 10 days to close all legacy tickets by the end of cut-over.
A final optimization with the sun-setting strategy is to preemptively close tickets below a certain priority and beyond a certain opened-by date. This strategy should be employed in situations where your legacy system contains an enormous number of dead tickets: tickets that for one reason or another have not reached closure, but nobody has worked on or looked at for a long period of time. For tickets of lower priority, these historical dead tickets may simply be ignored, as the relevant customers have likely already forgotten about them. This strategy could impact the customer experience, so should be employed only when the number of dead tickets is at a point where it is unreasonable to deal with them any other way. The existence of this situation is also likely a sign of underlying issues concerning team resourcing, lack of clarity about the type of service provided, customer education, and communications in the current state that should be addressed or improved in the target state implementation.
When all else fails, there will be situations where you absolutely must migrate operational data into the target state. In such cases, a release plan should account for a dedicated data migration team and the dedication of time to designing, planning, and executing the data migration itself. A common mistake made when planning for data migration is starting data migration too late or believing that it can simply be solved by the target state process design teams. Because data migration in this context will require a translation between the current to target state data and their respective definitions, the data migration team needs to be embedded within the target state design teams to fully understand how best to translate legacy data elements into the target state. . The complexity of this activity should not be underestimated, and so the data migration stream should be resourced as if designing net-new functionality, as opposed to simply moving data from point A to point B. This will also allow the migration activity to be started in parallel to other project activities, which will provide early visibility into any issues and mitigate the risk of last-minute complications.
The time spent on testing and training is an often neglected part of a typical release schedule. Even worse, when third-party vendors are placed under time pressure, this could be the first set of activities that is replanned, to the detriment of the long-term success of the project.
When considering the release plan of your transformation, anticipate the additional time needed to test the solution being created and to train impacted teams to adopt the changes ahead of time. The following are a few considerations to incorporate into your planning.
When new functionality is developed, creating automated testing using ServiceNow’s Automated Testing Framework (ATF) or any other automated test systems can significantly contribute to the organization’s ability to be agile in later releases. A common misconception concerning automated testing is that it saves time immediately. In reality, however, automated testing adds effort to the implementation upfront, as creating comprehensive automated tests for features can be as complex as writing the features themselves in the most complex cases.
The value of automated testing is gained incrementally with every new net deployment of capabilities onto the platform. Over time, as capabilities increase, the time to fully regression test the platform to mitigate unforeseen impacts becomes untenable for even large teams. In these cases, time-to-value can be significantly impacted without automated testing, and any failures in the already released capabilities caused by changes in the immediate release can cause significant downtime and customer experience impact.
When budgeting the time spent on building automated testing, consider that automated tests tend to add at least 10 to 20% to the effort of implementation. For complex implementations with many changes to the out-of-the-box configuration, this number may be even higher.
Even with automated testing, you will need normal quality assurance processes for the functions that you have implemented as part of the release. To properly exercise the solution that has been created, testing should cover both straightforward and designed cases, as well as error cases and edge cases. Many different types of testing must be prepared, each with different levels of complexity and different degrees of time added to the project:
Each of the test phases in the preceding section should be mapped to a specific ServiceNow environment. If possible, a different environment for each phase of testing will allow for greater structure. If you have fewer ServiceNow environments, consider grouping system integration and user acceptance testing into one test environment and executing other activities in a dev or QA environment. What is critical is that you are clear on what activities should occur in each environment to assist with logging and resolving issues.
A common release planning mistake is to neglect the time spent on training the team or parallelizing the training process with the testing process. The latter situation is a common shortcut taken by third-party implementors when the request for a proposal or service places significant timeline pressure on the third party. Parallelizing testing and training comes down to risk management. The risk is that during testing, significant defects or changes are identified that invalidate any previous training. Multiple options exist to mitigate this risk, but one obvious and direct solution is to simply do training after the testing has been completed. Depending on the acceptable risk level, training may start after the first few rounds of testing have been completed, with the expectation that any further changes will be minor and will not drastically impact the training previously provided.
Training is a very broad term, but in terms of project planning, in particular when third-party vendors are engaged, it generally refers to classroom training, either in person or virtually, unless otherwise specified. In some cases, a train-the-trainer model may be adopted, where a specialized team is tasked with training a set of operational resources within the organization (team leads or managers) to then train the rest of the teams on the changes that they will need to adopt. Classroom training can be reused and repeated by recording the training for future reference or future use with other teams. In some cases, classroom training may be determined to be insufficient for the organization, and in such cases, time and resources should be allocated as part of the project to be able to create and deliver more specialized training options.
Specialized training options include self-directed e-learning courses built using professional e-learning delivery tools. In-system training and hints are built using either ServiceNow’s guided tours functionality or a custom-built functionality for agents. For specialized training that requires development or custom content creation effort, the creation of the content can typically begin before all testing has been completed – however, a reasonable amount of time must be allocated to performing the final validation and editing of the content post-training to incorporate the changes introduced as part of the testing and remediation cycle.
A ServiceNow implementation project is a team effort and making sure you have the right team is a critical part of enabling your project to be successful. While the size of the project and the size of the organization will determine exactly how many members your team has, every successful ServiceNow implementation team should have at least one of the roles that we will detail later in this section.
In this section, we will highlight the various functions that make up the implementation team and then highlight the leads for each function. It is expected that as your project scale grows, each lead will go from an individual to a leader with several team members supporting them in the execution of their roles and responsibilities. Sometimes, your organization may have many functionally similar processes split across geographical boundaries or business boundaries. In such a situation, it is recommended that you also nominate leads-of-leads: someone with a high enough level of authority to make decisions and changes on behalf of the individual leads.
The focus on leads and not individual team members comes down to a single fact: the most time-consuming and complex aspect of a transformational implementation is being able to make business change decisions quickly. Configuring a tool to accommodate the differing needs of various stakeholders is generally far less complex to do but can quickly reduce the long-term value realization of the transformation by driving up the platform maintenance costs. Far too many projects with an initial vision of transforming the business fail to deliver on this promise due to the lack of commitment or support on the part of the team members to make business change decisions that take advantage of the platform’s capabilities better. Having the right empowered leads supported by their team in place to make these decisions is a critical aspect of a successful transformation.
Project functions are a simple way of dividing up the responsibilities of a project team by the general types of decisions and insights that the team leads bring to the project. A typical transformation should be comprised of at least the following functions:
When identifying the leads for the teams in the aforementioned functions, carefully consider both the individual and their contribution to the team. An effective transformational team requires individuals with specific skill sets and experiences to be successful:
Project executive sponsors should be clear on the purpose, priorities, and constraints of their transformation and be focused on helping the team deliver value despite these constraints. A project executive sponsor should also understand, at least broadly, what the transformation has to accomplish to deliver the value and objectives of the transformation.
Project managers keep track of and are aware of the needs and impediments of the team and work diligently to ensure those needs are met and impediments removed. A strong project manager can hold the project to its scope and its constraints and is unafraid to inform the steering committee and executive sponsor when constraints may be clashing with the vision and value objectives of the transformation.
Process owners should therefore either be senior leaders able to affect these changes across these teams or be supported and empowered by a senior executive (e.g., the executive sponsor) to drive these changes. A process owner should be able to identify required changes to the organization’s people, processes, procedures, and tools that can enable the process they own to achieve the value goals of the transformation, and be able to make decisions that appropriately balance the value realized versus the costs for, and impact on, the organization.
Individuals nominated as process owners as part of the transformation should ideally not only be able to understand what it takes to “keep the lights on” but also have a keen understanding of which value metrics truly matter for the organization and what can influence those metrics positively. You will likely have multiple process owners, each with their own scope of processes that they are responsible for.
At a minimum, all product owners should have the ability to translate the unfiltered wants and needs of their customers (whether internal or external to the organization) into working target state process designs enabled by the ServiceNow platform. While product owners must focus on the “what” and not the “how” when it comes to designing solutions that will satisfy the requirements of their customers, exceptional product owners also have substantial experience with the functional capabilities of the ServiceNow platform. This platform experience can help a product owner design solutions that maximize the usage of out-of-the-box platform capabilities to more efficiently deliver the solution to the customer.
Solution architects should have a great amount of technical knowledge and also strong product development experience. Knowledge of the technology ecosystem of the organization is also a strong asset, as it can allow an architect to envision a solution to a particular design requirement that utilizes the organization’s resources better.
Solution architects also set standards in the transformation process: they have to create the designs for the elements of the transformation that are shared across the various process and practices of the transformation. Some elements of this shared architecture include the Configuration Management Database (CMDB), organizational business data design (such as location, user profile, customer profile, and product catalog), and business logic design (such as customer support entitlement design).
To achieve this goal, organizational change managers must be able to understand what the impact on the organization will be based on the ongoing transformation, a task that is made difficult by the fact that preparation is likely to occur while the design and implementation of the transformation are still in progress. The lead should therefore have some experience with transformations of this type (and therefore some functional knowledge of the capabilities of the ServiceNow platform) to most efficiently identify the possible impacts of organizational change.
The organizational change manager and their team is also an expert in determining how people learn new skills and adopt new processes and has an exceptional understanding of the techniques that can change people’s behaviors.
They will be able to identify the individuals most impacted by the transformation to mitigate the cost of that impact through communication, training, and ongoing support, and prioritize these activities based on the anticipated resistance of the stakeholders to change and the importance of the stakeholders to the success of the transformation.
A platform owner need not be someone with a deep technical understanding of the platform but should be an operational leader who understands budgeting, operational processes and procedures, business analysis, production ownership, and functional design capabilities. A platform owner’s greatest challenge is working with their team and the organization’s leadership to create and manage a long-term roadmap for the platform that continuously generates value for the organization and enables value realization at the organization by supporting initiatives that may not directly involve ServiceNow. Doing this job well requires a clear understanding of the available operational resources and constraints on the platform team, understanding the high-level capabilities of the platform, hiring and managing a team with technical and functional capabilities in support of the platform, and managing a pipeline of business demands and delivering on those demands with consideration of the priorities of the organization and the resource constraints of the team.
Many ServiceNow implementations and business transformations involve third-party consultants. In the ideal situation, consultants bring expertise that cannot easily be found or maintained by the organization to enable and accelerate the transformation.
Many of these aforementioned roles can be filled by external consultants who bring experience and best practices not readily available within the organization. Furthermore, external consultants can provide objective advice and insights that internal resources may not feel comfortable providing.
While external consultants can bring hard-to-find expertise to enable your transformation, the one thing they need your support on is being able to create the right constraints for the transformation aligned with the outcomes you are looking for. External consultants can only provide the best advice for your organization based on the constraints you have established. For example, if you ask them to take you across a river and only provide a small amount of wood and stones, they will likely recommend building a raft even if a bridge is ultimately a better long-term solution.
Therefore, if hiring external consultants for one or many of these kinds of roles, you should follow the principles laid out in the Defining the scope of the project section of this chapter to maximize the value that consultants will bring to your transformation.
When engaging consultants you will also want to be clear on whether you are looking for targeted roles to be filled or whether you are looking for the consulting organization to deliver an end-to-end transformation. These services vary drastically in scope, cost and supported outcomes so a clear understanding of what support you need from consultants will help you engage with them more effectively and successfully.
Now that you have the right team for your transformation, we need to add a final ingredient that can turn a good team into a great team: governance.
Governance represents the rules, norms, actions, and standards followed by the transformation team. Governance is important because it creates consistency within the transformation and removes ambiguity from the transformational initiative. Ambiguity can negatively impact value realization, as it can create misalignment between actions and expectations. The word governance can sometimes have a bad reputation in organizations because it may have been implemented in a heavy-handed manner in the past or was not followed well. A common, flawed reaction to a bad governance experience is to try to avoid implementing governance. This misguided attempt to avoid governance is often combined with the misuse of concepts such as agile or lean, interpreting these new practices to mean an avoidance of governance instead of simply another way to structure governance.
The truth is that governance is critically important within a project. It does not need to be convoluted and complex, but it does require clear enforcement for it to succeed.
From a ServiceNow transformation project standpoint, one of the most critical aspects of governance is to enable the transformation to make effective decisions quickly. When establishing the scope, the vision and guiding principles are great at placing the appropriate constraints and directions on the project – however, without governance these constraints are unlikely to be enforced or followed over the course of the project.
A critical aspect of good project governance is to clearly define how decisions are made and what the decisions that should be made are. The latter can often be overlooked, but formalizing the types of decisions that should involve governance can significantly reduce confusion within teams and accelerate the course of the project. During the project, many types of decisions may be encountered, but not all these decisions will require a formal governance model. Let’s take an extreme example to illustrate the point: very few transformations would benefit from having a formal governance procedure to decide whether an individual can be excused from attending a meeting. In this case, leaving the decision to the individual is often more than good enough. Let’s look at two major decision types, often encountered during a project, that should always be tackled using formal governance.
Whenever constraints clash, or when the desired outcomes of the transformation are impacted, there is nearly always a decision to be made that must involve the governance of the transformation. Some examples of constraints clashing during a transformation include the following:
In each of these examples, there is no immediate solution that is correct. Each decision is a trade-off between two or more dimensions that are valuable to the organization. Whenever a situation of this kind occurs, governance should be engaged. Defining situations where project constraints clash as a trigger point for governance also helps eliminate decisions and situations that don’t cause a constraint clash from having to engage a broader governing body. In the previous example, if the constraint of not impacting non-IT teams is removed and no other constraints are affected, the project team is then free to engage the supply chain team to make the appropriate changes.
Decisions that affect the specific outputs of the project
ServiceNow transformations generally have a set of changes on the platform as an output that configures the platform to fulfill the requirements of the transformation. The transformation is also likely to include changes to current state processes and procedures that must be implemented to make the best use of the platform. In each of these cases, the exact target state process or platform configuration must be decided to avoid back tracking later in the project. Multiple target states can achieve the same outcomes, and many aspects of the target state design are therefore subject to preferences and opinions. Given this, the target state process design, platform design, organizational change plan, and execution design should all be recorded as formal decisions and subject to governance.
When target state design decisions are determined to be subject to governance the decision volume must be considered. For even a moderately sized transformation project there are likely to be hundreds of such decisions. If only a single governing body at the highest level of the project is responsible for making all such decisions, it can quickly be overwhelmed and become a bottleneck to the project. It is therefore important to reduce the overhead of governance through tiered governance approaches, as we will detail in the next section.
Even when the scope of governance is clearly defined to eliminate frivolous decisions, there may still be an enormous quantity of decisions that need to be addressed through governance. A tiered governance model based on the impact of the decisions can help further improve the effectiveness of governance and minimize impacts on the agility of the project.
A tiered governance model is based on the fundamental principle of making decisions closest to the impacted area and involving the least number of decision-makers possible.
Whenever possible, the project should designate key decision-makers at the process and platform levels so individual leaders (such as the platform owners or process owners) can be empowered to decide the final target state for themselves. This is true for design decisions that impact a very specific area of the organization or a very specific process. In these cases, it is almost always faster to simply let process owners decide on behalf of the organization how this target state will need to look.
A general rule of thumb for designating decision-makers and the types of decisions they can make unilaterally on behalf of the organization is to elect leaders that will be the closest to the impact of change (both positive and negative). The seniority of the decision-maker within the organization also matters for these types of decisions: junior leads may have a very narrow set of decisions that they are comfortable making, while a too-senior leader may be disconnected from the day-to-day realities.
While making decisions closest to the impacted area and minimizing the number of individuals that are needed to make a decision is generally preferable, transformations will often have at least a few large decisions that impact many individuals and decision-makers in other areas. In such situations, there needs to be a mechanism for governance to escalate decisions to higher decision-making levels.
Governance should create defined ways to escalate decisions and guidelines on when decisions should be escalated. Escalation is the process in which one decision-maker brings a decision they originally were accountable for making to a higher or different decision-making body. When governance is structured properly, the escalation process settles even the most complex decisions quickly by rapidly finding the right decision-maker for the decision. When governance is structured poorly, there could be many more decisions escalated than necessary, resulting in delays to the project as decisions pile up for higher-level committees to get together and sort out. An alternative problem is when important decisions are not escalated but instead stagnate, with a decision-maker both unwilling to make a decision but also not comfortable escalating it.
To prevent these problems, governance should formalize the situations where decisions should be escalated as far as possible so that there is little room for ambiguity or interpretation. Governance should also define the escalation procedure itself, along with where decisions should be escalated based on the type of decision. With all of these points combined, we present 10 rules to live by when establishing your transformational governance model:
With the right scope, considerations for the timeline, a release strategy for the implementation, a skilled team, and a clear governance structure to make them effective, your transformation should be well on its way to success.
Value management is the final aspect of the transformation, something that should be made an integral part of any scope, release strategy, governance model, and any decisions made. The underlying intent of value management is to optimize the transformational activities so that its outputs (business changes, process changes, and technology changes) are well aligned with the value measures that kickstarted the transformation in the first place.
In a simple sense, value management comes down to continuously asking the question, “Is this bringing value to the organization and what the project cares about?” The difficult part of value management is having an answer to that question for each decision made within the project.
If you have followed this book up to this point during the planning of a transformation, you should have already created layers of constraints and guidelines in the form of value statements, a clear scope, guiding principles, a project vision, and KPIs, which help the transformation steer itself in the direction of value realization. The following set of tips injected throughout the previously covered aspects of the project execution should augment every aspect of the project execution with the right value-management principles to deliver a better, more value-aligned result:
Quantitative measures are generally better than subjective measures because improvement can be directly tracked. Customer experience, for example, can be a very ill-defined and subjective term, but “reducing the time spent on the portal before submitting a request” or “improving clicks before submission of a service request” are goals tied to quantitative measures that are both relevant to that particular business outcome. Improving these quantitative measures compared to the baselines can then be directly fed into the scope of the project, as detailed in the earlier sections of this chapter, to accelerate decision-making around target state design.
Some decisions will always be subjective. Which color is better? Are clear skies better than cloudy skies? Ask several people and you’re likely to obtain many different answers. Similarly, in the case of a transformative ServiceNow project, many common transformational objectives such as customer experience can have highly subjective decisions associated with them. One common subjective dimension may be in the styling or layout of the customer service portal: is a top menu better than a side menu? Should an option be hidden in a menu item or be part of the menu header? Purely subjective decisions such as these are difficult to manage during a transformation because they can often result in decision-making stalemates.
But by applying the right framework and using the governance model to come to agreements on what frameworks are used, it is possible to turn many such subjective decisions into more objective ones. In the simplest form, a voting system can turn subjective into objective, but more involved systems include card sorting, using A/B testing, or instrumenting the portal with action tracking, which brings more involved quantitative measures to these normally subjective systems.
The key consideration to note is that there is almost always a way of breaking down a subjective dimension of measure into a more objective one, given the appropriate amount of time spent determining exactly which aspects of that measurement the organization truly cares about and how much investment it is willing to make to find the appropriate quantitative measure. When all else fails, utilizing a voting system and choosing an appropriate panel of stakeholders can be the final fallback strategy for tough decisions that must be made quickly.
With the right quantitative KPIs established, your baselines measured, and these KPIs tied to the desired business outcomes, the final aspect of integrating value management into the project is by tying all decisions to value, as well as considering the constraints mentioned in the previous sections of this chapter. Decisions that consider both value and constraints are the only types of decisions that matter for the transformation, as missing any dimension will likely result in an incomplete decision or a decision that is ultimately not impactful.
In this chapter, we have provided an overview of all the critical aspects of what makes a project successful. In summary, a successful transformation is one with a clearly defined scope that knows what business value it is trying to obtain, how to measure that business value, and has a clear baseline from which to improve. A team with the right skill sets and experience contributes to success, especially when organized using a clearly defined governance model that accelerates the decision-making process of the transformation by reducing ambiguity and subjectivity. Now that you have all the elements to make your transformation successful, it’s time to look at some of the more tactical aspects of the transformation that you absolutely can’t do without.