4

Planning an Implementation Program for Success

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:

• Defining the scope of the project
• Planning the release and release activities
• Structuring the implementation team
• Governance
• Value management

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 scope of the project

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).

Important components of the project scope

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.

The project vision

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.”

The project’s guiding principles

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:

• Always reduce the number of unique process steps across teams rather than configuring technology to accommodate these differences.
• Never increase the time that a service takes or the number of actions taken by a customer before they can receive service.
• Reduce the required agent decisions and agent actions required to fulfill service requests for a customer.
• Don’t put off making changes that impact the organization – deliver the needed organizational change along with the systems.
• All proposed changes must respect the project scope, timeline, and resource constraints.

Current state processes in the scope

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.

The project’s desired value and KPIs

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:

• Establish a set of KPIs to be improved as part of the project
• Define how the KPIs will be measured both in the current state and in the target state
• Take a baseline measurement of the KPI in the current state, possibly requiring previously uncaptured data to be captured

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.

A functional requirements list

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.

A technical requirements and integrations list

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:

• Performance requirements, large data volumes, or near-real-time response requirements for large data volumes
• Integration requirements – in particular, integrations that have to go through Enterprise Service Bus (ESB) systems or have to conform to enterprise integration standards
• Encryption requirements that specify exactly what kind of data is to be encrypted and the type of encryption required (at rest, in transit, or end-to-end)
• Accessibility requirements, such as accommodating visual impairments (while ServiceNow has some accessibility capabilities, out-of-the-box requirements in this area should be evaluated specifically)

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.

Adding details to the scope

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:

• Detail risks and uncertainties: If the solution to a particular objective is uncertain or unknown, it is better to include information on where the uncertainties are instead of hypothesizing about the possible solution. This is doubly important when the implementation will be carried out by a third party (e.g., a consulting company), as it allows that third party to provide better estimates taking into account the risks and allows project managers to better mitigate risks upfront and plan for contingencies. A good example of this approach is when the system will rely on a dataset of unknown quality. Effort may be required to cleanse the data and this work can be difficult to forecast. Documenting this uncertainty prevents it from being forgotten and ensures that the project continues to track it as a risk to successfully realize value.
• Detail KPIs and measures of value: A repeated theme in this book is the focus on value and measures of value. A project is far more likely to demonstrate value if there are clearly understood, quantifiable objectives that can be baselined before the project and measured again after the project. Whenever possible, a substantial portion of resources and time during the initial preparation of the project scope should be focused on what quantifiable measurements will be used to determine project success and to guide project priorities.

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:

• Detail the stakeholders, groups, and decision-makers: The act of defining the stakeholders, decision-makers, and groups impacted by a project can help clarify the scale of the scope of work, particularly in large transformations. For example, an IT CMDB project that involves the data center or infrastructure maintenance groups will differ significantly in its size and the possible outcomes it achieves compared to one in which they are not involved. In the latter case, the transformational outcomes should be more limited to enabling the automatic detection of application-level faults and dependencies, as, without change or commitment from the infrastructure team, any desired hardware-level dependency management in the CMDB will likely not be operationally sustainable.

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.

Planning the release and release activities

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.

Releasing often (minimizing impacts)

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.

Considering external dependencies

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:

• The external vendors involved in managing or delivering services: The availability of vendors providing managed services for technologies or infrastructures that the project will need to change or provision, or vendors who are involved in a current state process that will be changing in the target state, should be considered. Dependent vendors should be contacted early on in the planning process and incorporated as key stakeholders in the project and project timelines. This dependency can have significant impacts on the release schedule, as vendors are often bound by contracts that may prevent them from changing quickly at the discretion of the project.
• The teams involved in external systems that the platform will be integrating with: For ServiceNow implementations, integrations with external systems are frequently encountered and utilized for automation, obtaining business data, and other business purposes. Integrations with these external systems will require coordination with the teams supporting them in activities such as design, development, unit testing, QA testing, end-to-end integration testing, deployment, and verification. The project must consider the lead time required to engage the services of these external teams as well as their existing availability when planning releases.
• The impacted business and operational teams and their blackout dates: There is nothing worse than having a well-planned project timeline disrupted because other business-critical parts of the organization have a scheduled blackout or brownout date on the deployment or go-live date. After impacted stakeholders and teams are identified, relevant individuals within the stakeholder teams should be contacted to determine whether there are major release schedule conflicts or blackout dates that could prove disruptive to the release process.

Planning for data migration and validation

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.

Should you even migrate the data in the first place?

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.

What parts of the data should be migrated and what strategies should be employed?

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:

• For compliance purposes: Some operational data should be archived for several years. In these cases, strongly consider a migration plan that involves simply archiving the existing system’s database for access in the future. Archiving tends to be much simpler from a release standpoint than migration, as no transformational logic needs to be defined and the archiving process can be done outside of any other deployment activities and so does not need to be on the critical path of the deployment activity.

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.

• For active operational needs: Often, there is operational data that is still being actively worked on when the deployment to the new environment occurs. For example, what happens to open incidents or open cases when the existing system is transitioned to the new system? Even in this case, there are still options to explore before deciding that the data definitely has to be migrated. One option is to employ a sunsetting strategy where at the time of deployment, the existing system is not entirely shut down. For a certain sunsetting period, your teams will work in both the existing system and the new ServiceNow deployment, but with a very clear set of procedures to determine when to work in one over the other. For any operational data that remains open at the prescribed cutoff time (usually when deployment begins), these tickets will continue to be managed in the legacy system. After the cutoff time, new data will not be allowed to be generated in the legacy system (this is usually accomplished by disabling all the capabilities in the old system to create new operational records to prevent human error). In this way, the legacy system will have a finite number of existing tickets that still have to be worked on and closed. At the end of this period, the interim state in which both the current and target state systems are used can end, as the organization fully transitions to the target state.

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.

Considering testing and training

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.

Budgeting time to create automated tests to aid future regression testing needs

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.

Budgeting 20 to 30% of additional project implementation time for testing and training

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:

• QA testing is the most basic form of testing. The purpose of QA testing is to simply have testers run through the platform and check that all the functional capabilities in the target state design are working as described. QA testing should come with structured, detailed test scripts with clearly articulated expected outcomes. QA testing should be performed based on exercising the target state processes designed as part of the implementation. If a solution enables the execution of the target state processes as described, then it passes QA testing. However, if a described capability is missing, does not work as described, or does not fully enable the execution of the process as described in the target state design, then it is a defect. Even for the simplest projects, QA testing should be planned to take no less than 20% as long as the time spent on process design and technical implementation.
• System integration testing is the technical testing of technical integrations between systems. This term is sometimes used synonymously with QA testing but should be differentiated. System integration testing should be focused on making sure the APIs or interfaces between systems are working as described, responding as described, and sending and receiving data correctly. System integration testing should also test any performance requirements between integration interfaces if that is a part of the design specifications. System integration testing can be particularly complex because it requires coordination between teams and systems. Additionally, because each integration may perform a variety of tasks and have a variety of legal and illegal inputs, testing may not only require significant manual work but also work on building testing automation tools to help fully exercise the integration. Integration testing, therefore, is a more complex type of testing, and we recommend allocating 30% as much time as you spent designing and implementing integrations.
• User acceptance testing is the process of having the real business users of the system test the solution to identify whether there are any glaring issues with the design that could prevent the effective operation of the system. One common mistake made in large-scale ServiceNow transformation is for user acceptance testing to be the only time that actual business users see the system. As user acceptance testing is planned at the end of a build cycle and very shortly before training and deployment, identifying a critical defect or change in requirement at this time can be extremely disruptive to the project. Therefore, the previous testing cycles should have already involved business stakeholders, who were the primary drivers of the design of the product. Instead, user acceptance testing should be the opportunity to identify areas where the design may be confusing, identify incorrect usage, or discover edge cases in the design. The amount of user acceptance testing can vary greatly based on how many customer-facing components are in the target state design. Transformations with significant customer portal components should be subject to much more comprehensive user acceptance testing phases.

Environments for testing

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.

Beginning training after substantial testing has been completed

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.

Structuring the implementation team

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.

Examining major project functions

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:

• The project steering function: The project steering function is responsible for setting the goals, guiding principles, and vision of the transformation itself. They are ultimately responsible for providing the entire implementation team with what is required to achieve these goals. In situations where project constraints clash with the stated goals, guiding principles, and vision, the project steering function is also responsible for either removing the constraint or adjusting the goals to be more in line with the constraints available to the project. This function generally comprises senior business representatives, as decisions made at this level of the project can impact not only the project itself but also other parts of the organization and organizational resources as a whole. The project steering function is led by the project executive sponsor and supported by the project manager.
• The business transformation function: This function is responsible for designing the target state business processes and implementing the business changes required to reach the target state. Business change can range from something as simple as procedural simplifications on a team-by-team basis to something as drastic as creating new roles, and responsibilities and adjusting the overall business operating model to better serve the needs of the target state. The business transformation function is also responsible for establishing the standards of organizational business data to support the technology transformation function. The business transformation function is comprised of multiple teams and team leads including process owners, product owners, functional lead(s), solution architects, and organizational change management lead(s).
• Technology transformation function: This function is responsible for implementing the technologies, such as ServiceNow, that will enable the business transformation of the target state. While there is an interplay between the choice of technologies and the direction and design of the business transformation, most successful transformation initiatives with high-value realization are always led by the business transformation and not the technology. Nevertheless, the technology transformation function is important in helping the business transformational function achieve its goals. Additionally, for a prescriptive platform such as ServiceNow, the technology transformation function must help inform the business transformation function of the capabilities and limitations of the platform to better align the business transformation design to maximize these capabilities. The technology transformation function is comprised of multiple teams and team leads including the platform owner, technical lead, and solution architect.

Examining team leads and their skill sets

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: Often the executive sponsor of the transformation pick themselves by creating the vision and plan and convincing the organization to transform. With that said, the executive sponsor can still augment their abilities: by including the right individuals to support them as part of the steering committee or advisory panel. For large transformations, the executive sponsor should also be communicating and building relationships with leaders in parts of the business that may be impacted by the transformation initiative itself. It is important to keep in mind as the executive sponsor that the transformation initiative envisioned may not only impact other leaders indirectly but may also require the commitment of other leaders to change their way of working in service of the broader objective to be truly 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: There is plenty written about what makes a great project manager beyond the scope of this book, but from a ServiceNow transformation standpoint, a great project manager should take on the following:
  • Be detail-oriented and interested in the work being done
  • Have a level of functional understanding of the ServiceNow platform
  • Have experience in running large system integration and business transformation projects
  • Be able to build strong relationships and be well connected within the organization

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: These are leaders who are made accountable for the health of a process or practice within the organization. An important distinction between a process owner and the leader of a department or team in an organizational hierarchy is that the process owner has accountability for the entire process across the organization. For example, IT incident management is a practice that may involve infrastructure management teams, service desk teams across multiple countries, and network monitoring teams. Each team likely has a distinct leadership, way of working, operating model, and reporting structure, some or all of which may need to change as part of the transformation to improve the IT incident management process and achieve broader organizational outcomes.

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.

• Product owners or functional leads: Should be experienced resources with a deep understanding of the ServiceNow platform and the leading practices and frameworks in the industry. Depending on the specific scope and objectives of the transformation, functional leads may need specialized experience in product management and product development, or user experience design. Certification in the relevant ServiceNow processes may also be helpful for the product owners and functional leads.

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: These are individuals with substantial experience of designing and creating solutions on the ServiceNow platform (and integrations to other platforms) to solve highly complex solutions. Solution architects bridge the gap between the technologies available to the organization and their inherent strengths and limitations, and the designs of the product owners intended to solve a particular business problem.

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).

• Organizational change managers: Identifies the impact on the people, process, and procedures of the organization based on the target state design that will be delivered as part of the transformation. Organizational change improves the adoption of a transformation and therefore its value realization, and the organizational change manager is responsible for determining the right approach and executing the right activities to improve that adoption.

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.

• Platform owners: A leader responsible for delivering value to the organization using the ServiceNow platform. The platform owner must not only add or enhance platform capabilities to support the organization’s transformation needs but also balance these changes to the platform against the resources available to them to support long-term platform operations. These long-term operational activities include resolving platform support issues, fixing defects, upgrading the platform, managing demands for enhancements and projects on the platform, and managing and maintaining platform data.

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.

• Technical leads: A platform owner should be supported by a technical lead who is in charge of the configuration and technical maintenance and management of the platform. The technical lead of a platform should be deeply familiar with the technology of the platform and run a team that can effectively deliver changes to the platform to meet the business requirements and demands approved for it. The technical lead is responsible for setting configuration standards and for assessing the risk of change to the platform. The technical lead is also responsible for leading their team into implementing changes on the platform in a way that best balances maintainability, scalability, performance, and the alignment of the platform’s foundational abilities with other dimensions.

Can’t I just hire a consultant for all this?

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

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.

Accelerating decision-making with a good governance model

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.

Decisions that conflict with the constraints or desired outcomes of the transformation

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:

• Expediting customer orders on a new service portal requires the supply chain team to begin viewing orders from ServiceNow, violating a scope assumption that only IT teams would be impacted by the transformation. A guiding principle of improving customer experience is now in conflict with a project scope constraint of not impacting a particular line of business during the transformation.
• The IT asset management team would like a custom UI widget with complex requirements to mass update asset contract data. Having the widget could reduce the time spent on managing IT asset data by over 5,000 hours a year, but the change is high-risk from a maintenance standpoint. The constraint related to avoiding complex changes on the platform now clashes with a change to improve the agent experience and reduce the operational costs of IT asset management.
• As part of an HR service management implementation, it was determined that an automated integration to two other HCM systems could result in the full automation of several high-volume HR service requests, bringing substantial savings to the organization. However, the integration itself could push the project timeline out by 8 months and increase project costs by 20%. In this case, the guiding principle of bringing automation and improved employee experience is directly in conflict with the project constraints of budget and time.

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.

Reducing the overhead of governance

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.

Escalating decisions

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:

1. Establish objective guiding principles and list out the objective project constraints to be incorporated into any decision.
2. A formal decision needs to be recorded whenever it involves conflicting constraints or guiding principles (e.g., a decision breaks one constraint but better follows a guiding principle).
3. A formal decision must be recorded to finalize the target state design of a process, procedure, or configuration. This decision can be a single sign-off against a suite of design choices to be more efficient.
4. All decisions must respect project constraints or explicitly authorize the violation of a constraint as part of the decision. This reduces the possibility of decision-makers making toothless decisions that are incompatible with the project or organizational constraints.
5. There should be at least one decision-maker designated for decisions involving the technical design of the platform. When in doubt, this should be the platform owner.
6. There should be at least one decision-maker designated for decisions involving the design of the target state processes. When in doubt, the process owner of the organization can usually fill this role.
7. When a decision by one decision-maker negatively impacts the interests of another stakeholder who is a decision-maker in their own right, the impacted stakeholder must be consulted.
8. If the impacted stakeholder does not agree with the decision and can show a violation of constraints or principles, the decision must then be escalated to a higher-level authority.
9. The operating committee is a higher-level authority involving all decision-makers at the process and platform levels and is led by the executive sponsor. Escalated decisions that only impact the stakeholders within the scope of the project should be discussed and made here. The executive sponsor makes these decisions based on a prioritization of the project’s vision, guiding principles, and constraints.
10. If the decision impacts parties outside of the immediate project scope, the steering committee is a construct involving senior-level decision-makers, selected depending on the impact of the decision to resolve conflicts and impacts that expand beyond the scope of the project. The steering committee can make final decisions by voting or by engaging an individual of organizational authority a level higher than the impacted stakeholders and the executive sponsor.

Value management

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:

• Establish quantitative measure whenever possible, each with a baseline and a relationship to a clearly defined business outcome:

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.

• Subjective measurements can still be made quantitative through the application of frameworks and systems:

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.

• When making target state design decisions, have decision-makers always ask the question, “How does this change contribute to improving our KPIs?”:

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.

Summary

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.