9

Effectively Operating ServiceNow

So far, you have deployed ServiceNow in your organization, and if you have followed the advice of the previous chapters, it went exceptionally well. The scope was well controlled, the stakeholders were supportive and aware of the decisions they needed to make, and the overall direction of the implementation was smoothly steered by a clear overall strategy and guiding principles: congratulations!

At this point, the project is over, the consultants (if any) have left, and the current users of the platform are starting to ask for changes and reporting little issues they are finding here and there as they become increasingly familiar with their new world. In addition, leaders from other departments have heard of the success of the implementation and are clamoring to start using the platform for their own needs. One executive in marketing heard that there’s a Customer Service Management module on the platform and they’re eager to leverage the platform to send targeted marketing campaigns to customers, augmented with case data. With half or more of the team involved in the initial project gone or reassigned to other tasks, the demand is piling up and frustration is building: what do you do?

This chapter will help your organization operationalize the platform for long-term success and value realization far beyond the initial implementation. The following major topics must be considered to make operationalization successful:

• Establishing a platform strategy
• Establishing a platform operating model
• Operating the platform

Before we discuss these important dimensions of operationalization, let’s briefly look at the difference between operating the platform and simply implementing capabilities against it.

The differences between operations and project work

While platform operations and project work can intersect in many areas, there are several key differences between the two that require different models to be managed correctly. The following is a list of the key activities for both project and operational work and highlights their differences:

• Business outcomes: Both project work and operational work delivers specific business outcomes and, in this respect, there is very little difference between the two. Platform operations will more frequently involve “ongoing” business activities (defect remediation, incident management, platform performance, and maintenance management) that occur continuously and are typically not always accounted for during projects.

The biggest difference between delivering the business outcomes of operations and projects is that operations are typically resource-constrained while project work tends to be time-constrained. That is, projects will allocate as many resources (money and people) as necessary to deliver an outcome based on a specific timeline, whereas operational platform work generally has a fixed resource capacity but can work at delivering a business outcome continuously until it is achieved. It does so by increasing timelines and staging value realization across multiple regular releases.

• Timelines: Project work typically has fixed timelines to deliver a specific outcome, whereas operational work must be more flexible with timelines because it is resource-constrained. The advantage of project work is that it can deliver major changes very quickly by concentrating its resources on a specific scope. The advantage of operations is that they can work on a specific business problem for as long as they need to, which can significantly improve adoption and can be more successful for changes with many dependencies.
• Resources: Projects and operations both tend to have fixed budgets. However, projects are generally funded based on a business case meaning that an additional budget is allocated to achieving the targeted Return on Investment. On the other hand, operations typically have a fixed annual budget, a portion of which will be dedicated to ongoing activities such as incident management, platform maintenance, and defect remediation. The remainder is flexibly allocated to enhance the platform.

Because of these differences, platform operations is much more sensitive to how demands are prioritized than projects – they must understand how to allocate its resources across a portfolio of possible demands so that they can still deliver business outcomes regularly, avoiding situations where they spread their resources too thin. Operations must also worry about how the ongoing costs of maintaining the platform can be affected by their activities, as well as those of the projects. Depending on the funding model for platform operations, all these ongoing costs must be absorbed through the operational budget, so platform operations is also far more sensitive to strong rules and standards when it comes to platform governance, without which they may find themselves overwhelmed by projects whose outputs must be maintained in perpetuity.

Operations need a “North Star” to guide the way it prioritizes and allocates its resources; one such North Star is the platform strategy.

Establishing a platform strategy

The first step in determining how your organization’s ServiceNow platform will be effectively operationalized is to determine what your platform strategy will be. ServiceNow, when used at its fullest extent, can be an enterprise platform that acts as the source of truth for several types of operational data in different process areas, a platform that supports multiple applications used by different teams, and a significant (if not the only) point of entry to engage business services and customer services. With so many capabilities, having a platform strategy will help focus your efforts so that the organization’s limited resources can be directed against the platform in focused ways that drive business value.

But what even is a platform strategy? You will often see a platform strategy or technology strategy being summarized in a single statement, such as Automate customer service or Decrease the cost of IT. While these strategic statements can be useful to help simplify and specify the goals of your team or organization, having an effective strategy that can help you determine how to design the operating model of your platform will take a little more work.

Instead of racking your brain to find one magic statement that perfectly describes the objectives of your platform, you should consider and provide answers for various strategic dimensions. Let’s take a look at some of the questions that are typically asked.

Who will be the platform’s customers?

When you launch the ServiceNow platform into the organization, it may seem obvious who the platform’s key customers will be. Typically, it is the team(s) of the executive sponsor of the implementation or their business customer. However, once the platform has transitioned into operations, the line can rapidly blur as groups related to the platform’s implemented capabilities begin requesting enhancements and changes to the platform to improve its organizational value. This influx of demand from various stakeholders is a good thing: it typically means that the implementation of the capability has been successful enough to garner attention and there are now opportunities to improve the return on investment. However, if the platform strategy does not identify its priority customers, the platform operational team’s resources may be stretched thin, and the demand intake process may be overwhelmed.

By identifying an initial list of priority customers and growing that list over time as the platform expands (or not), the platform team can manage expectations and better focus its resources on delivering the right outcomes. Given the capabilities of the ServiceNow platform, there are several immediate customer candidates and use cases the platform can support:

• Chief Information Officer (CIO) and IT service management leader
• Global service desk leader
• Chief Information Security Officer (CISO)
• Head of HR
• Head of customer support and customer service
• Chief Operating Officer (COO)

Each of these leaders and titles is likely to oversee a team(s), departments, or a portfolio of business use cases that can be directly addressed by the implementation or enhancement of the platform. More importantly, the portfolio of business cases that exist within the teams of each leader in the preceding list is likely to be large enough to justify long-term, ongoing investments on the platform. If your immediate interested customers are more operational – for example, the incident management leader or change management leader – you should work with them to build a broader business case for the platform by including their leaders or broader stakeholders. As a platform with broad enterprise capabilities and a fairly substantial operational cost, it is important to help stakeholders at the operational levels to build broader business cases to make both them and the organization successful.

Identifying your customers will not only focus the efforts of the platform team but also make it easy to measure and maximize another important metric in the long-term operational success of an enterprise platform: customer satisfaction. Without a clear customer and long-term sponsor, the platform can quickly run the risk of failing to make anyone happy. When such a situation occurs, leaders and teams can quickly decide to switch to something else, washing away all the time and effort invested in the existing technology.

The platform’s customer base can be added to over time, so it is always good to start with a smaller customer base before expanding it. A good rule to follow here is to treat the operations of the platform as a product business within the business. Like most successful businesses, focusing on doing one or two things well at the beginning is typically better than tackling an array of different and distinct issues. Also, like most businesses, there is still an element of opportunism that must be considered. When a major customer with a large and high-value use case approaches, there may be a strong incentive to consider that customer, even if it means a pivot in the direction and focus of the platform team.

When considering this question, the answer will usually come down to the following:

• First, who are the current customers that are utilizing the platform? In most cases, these customers must be directly supported and therefore are likely to be your platform’s core customer base for the reasonable future.
• Second, is there a broader strategic initiative that the platform can play a key role in supporting? For example, if a large customer service transformation initiative with ambitious goals is currently being planned, the ultimate stakeholders of that transformation could easily be considered potential customers for the platform.
• Third, who are the prospective near and medium-term customers who may need to be engaged early and whose relationships should be managed for long-term platform success? To identify who these customers are (and what level of involvement they should have in the ongoing operations of the platform before being a customer), the second aspect of platform strategy should be considered: how ServiceNow fits within the business.

Even if you have understood your customer base, it may not be clear where ServiceNow fits within the broader technology landscape of the organization. In the next section, we will see how positioning ServiceNow in the broader technology landscape is important to successfully plan the platform’s growth.

How will the platform fit within the broader technology landscape?

Whether it is IT or HR or the customer support and marketing parts of the business, you are likely to find a broad array of technologies and platforms available to solve a large and broad portfolio of business problems. Some of these technologies will be fit-for-purpose solutions built to be exceptionally good at solving a particular business problem, while others, such as ServiceNow, can act as an enterprise rapid application development platform capable of being configured to address multiple business cases. To make this situation even more complex, ServiceNow also has out-of-the-box applications and capabilities that are fit for purpose, so even if the rapid application development aspect of the platform is not leveraged, ServiceNow can still be considered when solving business problems in the HR, customer service, IT service management, and other spaces.

The question to answer via your platform strategy is how the enterprise should treat ServiceNow. Is it simply another tool in the toolbox, or will it be treated as a more strategic asset, taking advantage of the fact that, as a platform, return on investment can often be greater as more use cases – in particular, interconnected use cases – are addressed on that single platform?

When treated like a toolbox, for any business scenario that could benefit from supporting technologies, ServiceNow will be evaluated against the rest of the technology portfolio of the organization and potentially against off-the-shelf and non-off-the-shelf solutions not yet within the technology landscape of the organization. This is a good choice if the organizational technology strategy is to emphasize fit-for-purpose solutions for each business outcome. The disadvantage of this strategy is that the cost of integration typically increases, and the approach may introduce a multitude of point solutions that can increase the overall technology costs. The resiliency of the technology landscape may also begin to erode, especially if introducing many different solutions overwhelms the capability of the organization to retain the specialized skill sets that may be necessary to keep those technologies working effectively.

When treated as a strategic platform, when a business use case is identified, ServiceNow is treated as a priority solution option (along with a small selection of other strategic platforms). In this way, the question that’s asked when a new business case is identified is why couldn’t this be solved with ServiceNow? as opposed to investing heavily in identifying the potential best fit-for-purpose solution that may be out there. The advantage of this strategy is that it maximizes the potential of the platform to share costs and to deliver integrated value more efficiently. When supported with the right platform solution architecture, leveraging ServiceNow in this way can significantly reduce the cost of integrations and decrease time-to-value, enabling the organization to launch applications that can take advantage of an enormous amount of enterprise data with less effort. In addition, leveraging a small set of powerful enterprise platforms allows the organization to maintain a smaller core of skilled talent that can be flexibly moved across different applications and technology solutions built on the same platforms The disadvantage of this approach includes potentially losing out on some functionality that is more readily available on fit-for-purpose platforms and, in some cases, a reduction in flexibility for business stakeholders looking for quick solutions for business problems that may be more readily available and more readily deployable when choosing an off-the-shelf point solution.

While both strategies are valid, ServiceNow’s capabilities, costs, and long-term roadmap strongly encourage organizations to treat it as a strategic platform. While ServiceNow may be competitive from a value standpoint against point solutions, a far more compelling value case is made by treating it as a strategic platform.

With that said, there may be internal limitations within the organization that prevent the platform from realizing its potential, even if there are pockets of sponsorship. These limitations should be considered when a strategy is being established so that the strategy is realistic for the organization. In the next section, we will discuss one of the most impactful determinants of how successful a particular platform strategy will be: the platform operating model.

Establishing a platform operating model

The best and most ambitious strategies will still fail miserably if the enterprise is not organized or resourced enough to successfully execute that strategy. Decisions on how the ServiceNow platform is governed can often affect the ultimate direction it takes during operations, regardless of the strategy it is attempting to follow. Therefore, it is important to consider the operating model when the platform strategy is being developed. Leaders must recognize cases where the ideal operating model is not supported and adapt accordingly. Given existing organizational realities, it may be prudent to shift the strategy accordingly to achieve more realistic goals. On the other hand, it may be that success in achieving a particular strategic goal is imperative for the organization, so leaders will need to put in the work to build support and governance to execute on that strategy.

While there is no one-size-fits-all approach, like strategy, there are a few key aspects of the operating model that should be decided on to create a coherent approach:

• Who will manage the direction of the platform and how?
• Who will manage the intake of platform demands and how?
• Who will manage how the changes on the platform are implemented and how?
• Who will manage the funding for changes to the platform and how?

For each dimension, there is usually a centralized versus distributed option with pros and cons for each.

Before we look at each of these models and how they differ, let’s look at the typical roles involved in platform operations, from setting the strategic direction of the platform to executing the changes required to meet business outcomes.

Platform operating model roles

Whether big or small, centralized or distributed, each platform team should fill a set of roles that can help the team operate effectively. A person can have multiple roles in a team, but the team should avoid splitting the responsibilities and accountabilities of a single role across different individuals. This is because the accountabilities and responsibilities separate concerns in such a way that individuals in a role can fully focus their abilities on related areas and create appropriate separation of concerns that drive better decision-making as a whole.

Platform executive sponsor(s)

The platform executive sponsor could be anyone (or several individuals) within the organization. The primary role of the platform executive sponsor is to fund the costs of platform operations and, occasionally, the costs of projects on the platform as needed. Because platform executive sponsor(s) fund the platform operations, they have a considerable influence on the direction of the platform and how operational resources are allocated. However, platform executive sponsors are not omniscient. Since they are leaders within various business areas of the organization, they may have competing priorities and interests. They are also likely to only have a limited understanding of the operational constraints faced by the platform team. These constraints may include resource constraints as well as technological constraints and dependencies on other parts of the organization. Because of this limitation, another role must exist with a greater level of understanding of these constraints to provide insights into these areas and improve the ability of executive sponsors to make decisions. This role typically belongs to the platform owner.

ServiceNow platform owner

The ServiceNow platform owner is an individual that oversees the platform operational team and is accountable for the health and business outcome realization of the ServiceNow platform. The platform owner should be well informed of the operational details of the platform – how much work will it take to maintain the platform and what kind of budget is required? What are the current risks? The platform owner must be able to advise the executive sponsors on how to maximize the value of their investment, providing a level of understanding of the operational realities that the sponsors may lack. There should always be a ServiceNow platform owner, regardless of whether the platform is governed in a more distributed manner or a centralized manner. The only difference in such a case would be the authority provided to the platform owner, as we will discuss in more detail in the following sections of this chapter.

Business analyst/product owner

The names business analyst and product owner are often interchangeable; organizations following agile terminology tend to use product owners more than business analysts. The actual job of the role is the same – ideas and needs from the business that may be unstructured and ad hoc must be collected and refined into a clear and formal request with well-defined business outcomes and requirements. The business analyst or product owner’s role is to understand the business needs of the customers and translate their ideas and unstructured demands into structured demands/requirements that can then be scoped, estimated, and prioritized as work to be done by operations. The best product owners understand the customer’s needs better than the customers themselves, make prioritization decisions that are best for value-realization for the customer, refine their ideas into clearly executable demands, and represent the customer in the demand management process. When a demand is approved and prioritized, the product owners flesh out their requirements into target state designs and user stories, which they then work with alongside the platform developers to estimate and ultimately implement them.

Demand managers

Demands from the business, represented by their respective product owners, must be evaluated and qualified against other demands and operational constraints before they can be officially scheduled as a package of work for the operational team. Demand managers are the first to enforce platform governance – they enforce the standards that the demands on the platform must meet before they can be formally assessed and prioritized. Demand managers will interact with the product owner to determine if the demand is sufficiently thought out so that it can be evaluated against other demands. They can also reject demands that do not align with the strategic priorities of the platform outright. Depending on the volume of demand and the footprint of the platform, there may be many demand managers managing demands against the platform. Demand managers are responsible for the platform owner in a centralized operating model as they help the platform owner determine how best to allocate operational resources to maximize business outcomes.

Platform architect

The platform architect is responsible for protecting the architectural integrity of the platform and provides the platform owner with technical insights that may affect the prioritization of demands against the platform. A common role of the platform architect is to evaluate and reject demands that may not be the right fit for the technical capabilities of the platform (for example, requirements for the platform to be a data archiving solution for enterprise documents or a training video viewing platform). The platform architect also provides demand managers and the platform owner with support in assessing the relative complexity and/or technical risk of implementing a demand and the long-term operational costs and risks associated with maintaining a particular demand going forward. Platform architects also play a role in project work, using the same framework in which they assess the risk of operational demands to projects, as has been detailed in previous chapters of this book.

Platform development and QA teams

ServiceNow developers, QA testers, and their respective leads comprise the platform implementation teams. They are responsible for planning and executing the necessary configurations and changes on the platform to meet the incoming platform demands. They are also responsible for upgrading the platform, responding to platform incidents, and monitoring platform health. The size and number of these implementation teams vary, depending on the platform’s footprint, but at a minimum, there must be a technical lead and a QA lead on each team. One is responsible for implementing the technical configuration necessary to meet the requirements for approved demands, while the other is responsible for testing these changes against the acceptance criteria to ensure the output delivers upon these business outcomes with minimal defects. In large operational teams, each lead may have a team consisting of two to four individuals to distribute their work, and/or there may be multiple such teams each responsible for its stream of work. This is typically divided by the product owner/business line they work with.

In the case of large implementation teams, the role of the technical lead is to provide technical guidance and direction to their team so that every developer implements them according to the right technical standards. The technical lead also works with the architect to ensure that what is implemented follows architectural standards and considers the usage of the shared architecture (for example, CMDB) in a way that is common across multiple streams.

The QA lead is responsible for understanding what configuration is being built and working with their team to construct the right test scenarios to fully exercise the configuration. In large and complex operating environments, the QA lead and their team are also responsible for creating automated tests and other testing technologies to enable the operational team to perform regression testing and automated testing for complex configurations.

Release managers

Release managers help plan when capabilities will be deployed onto the platform. This job is complicated by the fact that there may be external dependencies outside of the platform that provide constraints on when releases can occur (for example, there could be an organizational policy that dictates no changes to the HR module during the year-end payroll processing period). Therefore, release managers work with the broader enterprise release process to determine the best sequencing and timing for releases of capability and help demand managers, product owners, and development and QA teams sequence and schedule accordingly. Release managers are also responsible for helping create the deployment plans for operational activities that are ready to be deployed by working with the development and QA teams and the platform architect.

Regardless of the exact operating model, these roles will always be needed to manage platform operations. But while the existence of these roles is a requirement for healthy platform operations, the exact authority and responsibilities of these roles may be subject to change, depending on the key dimensions of the platform operating model, starting with how the direction of the platform will be managed and by whom.

Who will manage the direction of the platform and how?

Given limited resources but many demands on the platform, who should decide which demand is answered first? The answer to this question impacts the authority that’s granted to the platform owner and may also impact the speed with which platform decisions are made.

In the centralized model, the platform owner has the ultimate authority to decide how resources at their disposal will be allocated against demands.

When the right individual is chosen and provided with the right team, the centralized model tends to make faster decisions A centralized model where the platform owner has the final call on the direction and vision of the platform can also be more effective at solving a large problem if provided with enough space, as the platform owner can focus their resources on realizing a particular vision without being distracted by the changing priorities of many different stakeholders. The drawback of the centralized model is that it is more difficult to find the right platform owner as the skill requirements of the role are increased. The platform owner must balance selling the platform’s vision to stakeholders to receive funding with managing the resources of the operational team and managing and selling the business outcomes. Therefore, the platform owner should be someone senior within the organization who is deft at building consensus as well as building a team that can deliver promised results.

In the distributed model, the direction of the platform is decided by an operating committee that should meet regularly (the cadence of which depends on the anticipated and actual volume of platform demand) and decide, as a collective, which demands should be implemented on the platform first, which demands should be deferred, and which demands should be rejected outright.

Under the distributed model, the platform owner acts as an advisor and steward of the resources and direction of the platform granted by the operating committee of the platform. They are just one vote among many regarding how resources should be allocated, and which demands should be addressed first and which second. When the stakeholder of the operating committee is aligned on following a particular shared vision and acting in unison for the interests of the enterprise, the distributed model has a better chance of finding greater transformational opportunities by pooling resources from multiple leaders for the greater good. The drawback of such a model is that without an organizational culture of working for a common good, or without the ability to measure the outcomes of that common good, it can be prone to paralysis as competing priorities and objectives fragment the decision-makers, which ultimately results in inaction.

The platform owner in a distributed model should still be as senior as possible, as their capacity to act as an advisor to the operating committee is enhanced by their seniority. However, because the platform owner is not ultimately accountable for the direction of the platform and instead acts as a steward or executor of the will of the operating committee, the platform owner could be a less senior resource in the distributed model compared to the centralized model. In such cases, it is recommended that the platform owner brings a stronger execution capability to the table to bolster the more strategic capabilities of the other stakeholders within the operating committee.

In either model, the platform owner is responsible for managing the expectations of the stakeholders and the operating committee.

While there is no wrong choice in terms of whether your platform operating model should be more distributed or centralized under the platform owner, there are factors that should influence the decision. If the organization is highly effective at measuring enterprise metrics and can incentivize leaders to deliver enterprise outcomes, even if it’s outside of their immediate portfolio (for example, incentivizing IT leaders to produce HR business outcomes), a distributed model may work very effectively. On the other hand, if the organization tends toward more of a siloed approach, where sharing resources and funding is not formally recognized, then having centralized accountability of the product owner enables better business outcomes by allowing the platform owner to make the right decisions on behalf of the combined inputs of the stakeholders as a “neutral” third party.

Establishing the operating model to determine the direction of the platform helps establish the framework for which prioritization decisions are made. The next important dimension to manage is how the source of these decisions – demands – is managed.

Who will manage the intake of platform demands and how?

Demands are requests to commit resources to make changes on the platform. Defects on existing capabilities that should be remediated, enhancements on existing capabilities, and net new capabilities to be implemented on the platform all constitute demands upon it.

Demands can come from anyone and anywhere, and as the footprint of the platform grows, demands for change typically increase. Apart from this, stakeholders become invested in how the platform works and is changed. Because resources are finite, only a subset of demands can be accommodated for any fixed period, so managing what demands should be accepted and which should be deferred or rejected becomes a key aspect of the platform operating model. Since we have already discussed establishing how the direction of the platform will be managed, the who for which demands are prioritized or rejected has already been established – the platform owner and the operating committee should ultimately make such decisions based on the direction they have established. However, this still leaves us with the opportunity to determine how to filter demands so that only highly relevant demands are fully evaluated. This demand management activity is required as without it, demands big and small must all be evaluated at the highest authority level, creating a bottleneck, and potentially overwhelming the decision-making authority. This results in less effective and informed decision-making.

It is convenient to look at how demands should be filtered and qualified by separating them into a few buckets – demands that enhance or remediate existing platform capabilities that are already being delivered to the organization, demands that are net-new but still aligned with the platform direction established by the platform authority, and demands that are net-new and add to the scope and mandate of the platform.

Demands that enhance or remediate existing capabilities should almost always be given some greater priority when business outcomes and costs are equal. This is because these demands already have clear customers and clear benefits and are already well aligned with the platform strategy and the broader business strategy (assuming everything leading up to this chapter has been followed!). In the case of these demands, the hardest problem is to size the demands and determine how to prioritize them if the overall number of demands is greater than the ability of operations to deliver them.

Demands that are net-new but still aligned with the direction established by the platform authority typically require an additional consideration – the increased operational commitment to support the capability. These types of demands include “major” enhancements that add substantial new capabilities to something already implemented – for example, adding a call center integration component to an existing customer service management capability or adding a virtual agent to the employee service portal. In the latter case, even though the capability can be added “out-of-the-box,” adding it must still be assessed as it will create a source of additional demand, should employees or the business stakeholders begin noticing gaps in the service experience and begin asking for improved conversational options and other additions through the demand channel. A greater level of scrutiny is required when these new capabilities are added because additional operational strain may be placed upon the platform team, and because such additions may also have dependencies outside of the platform (for example to integrate with new data sources within the organization). A greater level (and duration) of funding commitment may also be required before they can be approved.

Finally, demands that are net-new and are not in the immediate direction or scope of the platform require the greatest amount of scrutiny and may also require one or more projects to be fully implemented. The biggest decision for these types of demands is whether expanding the platform’s footprint into that area is worth it. Leveraging the platform and business strategy as a guide is important in these decisions – supporting a net-new business customer with a brand-new platform capability can create a large change in the operational constraints of the team and should always be carefully considered, even when the initial implementation can be projectized instead of being dealt with operationally.

Once a small subset of demands has been qualified, it must be considered against organizational and operational constraints before it is approved for implementation. During this decision-making process, how the operating model deals with resourcing for implementation can influence the evaluation criteria.

Who will manage how changes are implemented on the platform and how?

While we clearly articulated the roles needed to operate the platform earlier in this chapter, we have not specified the organizational hierarchy in which these roles fit. This was done intentionally because different organizations may benefit from different reporting models, and different decisions regarding whether the platform is managed in a distributed or centralized manner can also affect the reporting structure of the various roles.

Two major patterns are used in the organizational hierarchy of the operational team of the platform when it comes to using resources to implement changes on the platform: distributing the implementation team across the business stakeholders or centralizing the platform implementation team under the platform owner.

In the distributed pattern of implementation, business stakeholders are allowed to resource for their implementation teams. This can often be seen in organizations where business units such as human resources or security or customer support have their own technical teams to maintain systems that underpin the business services in their portfolios separate from IT. This pattern can also sometimes emerge when IT has subunits with technical delivery capabilities. These subgroups can often leverage their technical capabilities to bring enhancements to the platform that may otherwise be prioritized lower by the platform owner, creating parallel streams of value and reducing time to value for those teams. The advantage of the distributed implementation pattern tends to be time-to-value: groups that can find implementation resources can quickly meet their demands on the platform without worrying about broader operational constraints or impacts.

The distributed pattern has several drawbacks. As an enterprise platform, the value realization of ServiceNow improves when various components of the platform are configured to work together or utilize shared data and architecture. While this is possible to achieve when implementations are spread among multiple groups, it is certainly much more difficult. Even when strong governance and standards are established, due to the lack of direct reporting structures, it is extremely easy for that governance to be violated or ignored both intentionally and unintentionally. Therefore, the benefits of the parallelization of platform change work are hindered or mitigated by greater risk to platform integrity or a reduction in efficiency due to the overhead of attempting to coordinate these different teams into a cohesive whole. Related to the previous point, there are also disadvantages and inefficiencies in resource sharing as each group in a distributed model is usually more strongly incentivized to make sure investment and resources are allocated to benefit the group directly. This difference in incentives means that the distributed model tends to be less effective at pooling investments that may only have short-term benefits that are limited to a particular group, but a longer-term benefit for multiple groups. The CMDB is a notable example of this – initial investment in building up a high-quality, well-maintained CMDB may have many phases where only a few groups benefit, but over the long term, that investment can translate into greater value realization for all.

The alternative to the distributed approach is centralizing the implementation capabilities under a single leader, most typically the ServiceNow platform owner (and by extension, the operating committee if the platform direction is managed in a distributed way). In this model, the implementation team reports directly to the platform owner, and it is the responsibility of the platform owner to manage the performance of such a team. The centralized model truly makes the business stakeholders customers and removes them from having a direct impact on the platform, regardless of their ability to bring human resources to the table. The advantage of this model is that the direction of the platform can be much more easily connected to the priorities of the implementation. As the implementation team reports directly to the platform owner, who is a key stakeholder in setting the direction of the platform, there is little room for the implementation team to deviate from the long-term platform vision and plan. Additionally, the fact that the implementation team directly reports to a single authority means that it is much easier to enforce technical and functional standards on the team and hold the team accountable for the quality of their overall delivery. The centralized model is particularly good for efficiently and effectively delivering large-scale transformations against shared business components such as the CMDB. Assuming the directional alignment exists (a difficult step in and of itself), the implementation team can plan across its entire footprint to maximize the usage of the shared data and architecture and coordinate the timing of releases to take advantage of the CMDB’s growth at the right times.

The disadvantage of the centralized approach is that there is a greater demand from the platform owner or the platform operating committee on managing its business customers and stakeholders. Because the business customers will continue to have competing priorities and when these priorities are addressed (or not at all) entirely at the whim of the platform owner and/or operating committee, at least some stakeholders may find their priorities de-emphasized for those of others. This disconnect will place more pressure on the platform owner and the operating committee to do much more in ensuring stakeholder alignment and that everyone understands and buys into the shared vision. It’s also easier for the centralized approach to get lost in its vision and become disconnected from the customers they are trying to serve; this issue can be mitigated by having strong product owners who can act as the voice of the customer and help place the right focus in the right areas.

Concerning how to set the direction of the platform, there is no obvious choice between the distributed and centralized models to manage the implementation of changes on the platform. With the implementation choice, if all other factors are not considered, the centralized model tends to be a better fit for ServiceNow, given its nature as a shared enterprise platform. However, there are other factors to consider, and having a strongly centralized model will require several key ingredients, such as a strong platform owner and a highly aligned and supportive operating committee that can help the platform owner gain alignment with the business customers. This does not mean organizations should give up on the centralized model. Even if some distribution of responsibilities must occur, strong enforcement of architectural and quality standards through the platform owner and operating committee is still necessary for long-term value realization. The bottom line is that when it comes to implementation on the platform, leaders and teams must learn to work together in developing shared visions of both business outcomes as well as architectural approaches and keep each other and their teams aligned to this shared vision. This cohesion and clarity of where the platform must go from all stakeholders becomes invaluable when it comes to the next consideration for operating the platform: funding.

Who will manage the funding of changes on the platform and how?

Who pays for the costs of platform operations and what considerations must be taken to fund the platform? We can break down platform operational funding into three major buckets – the licensing costs of capabilities of the platform, the maintenance and enhancements costs of capabilities already implemented, and the initial implementation costs of the capabilities.

In many organizations, the business approaches IT with a particular problem or requirement, and IT is responsible for obtaining the necessary budget and resources to accomplish this task. IT in this model may also be responsible for all ongoing operational costs and the cost of defect remediation and enhancements going forward for the capabilities that have been implemented. This IT Service Provider model gives IT, which is the part of the organization most well-equipped to implement and operationalize the platform, great flexibility to prioritize and execute the initiatives that it believes can make the greatest business impact, considering all its potential customers and business opportunities. In this model, IT can charge its customers for ongoing operational costs, adjust that cost depending on the level of service required, and request additional funding for large projectized outcomes, provided the customers are willing to pay for it. Any excess earnings through this charge-back model can then be reinvested into IT for long-running, broadly impactful improvement initiatives such as improving automation or adding resiliency.

The disadvantage of the IT Service Provider model is that unless there is an actual mechanism for IT to charge its customers for its services, operationally and otherwise, there may be a level of disconnect between the budget and resources that IT can obtain, the business outcomes desired by the customer, and the actual outcomes that IT can deliver with its budget. This is especially true when it comes to long-term operational costs, which are often neglected and result in decreases in service quality and an inability for IT to reinvest back into itself regularly for continuous improvement.

The alternate model, where businesses must provide funding to IT to accomplish its goals (IT as an implementation team for the business), can make it easier for IT to execute focused initiatives. The model also encourages the issues with the most pressing business priorities (that is, the ones that people are willing to pay for) to be addressed first. When the platform team/operating committee establishes strong standards for what funding dimensions must be considered (for example, not neglecting the cost of maintenance and the cost of ongoing IT service management for the new service), the model may create greater delivery capacity than in the service provider model because every initiative will be backed by both the business and IT.

One of the major drawbacks of this model is similar to the issue with distributing the implementation to the stakeholders – the inability to commit shared resources to build capability on the platform that may provide long-term benefits for multiple areas. While strong governance and standards can reduce the instances of this occurring, it can impact the customer experience – business units with money may not understand (or even care to understand) the reasons why their goals cannot be accomplished without additional investments in shared infrastructure for which their funding is insufficient, creating misunderstandings or a perception that the platform is unable to deliver results.

The reality is that it may be difficult for the ServiceNow platform stakeholders to make any tangible changes to the funding model as this is typically a deeply embedded aspect of business operations. Now that we know the players of the game and what to look for in terms of platform operations, we will focus on the day-to-day actions of the team and where to apply their focus, including how and where to focus the time of the platform team (including the operating committee) to reduce the impacts of the drawbacks of each model and to play to their strengths.

Operating the platform

Now, we are going to highlight some of the key activities and actions members of the platform operations team can and should be doing to contribute to the platform’s success. This will not be a detailed set of operational procedures, but instead a loose list of actions and considerations for each role to be utilized as a guide to drive everyday positive behaviors. Where applicable, we will provide comments on how a particular activity may change in terms of its criticality or character, depending on the operating model or choices established in the previous sections of this chapter.

Executive sponsor and operating committee

The executive sponsor and the steering committee have three major responsibilities that they must fulfill.

Protecting and committing to the platform’s vision and strategy

One of the most important aspects of the executive sponsor and the operating committee is to ensure that the vision of the platform that has been established and agreed upon is protected. As time passes, changes in business priorities, leadership, and other factors can create major headwinds that cause the path to the vision to drift off-course. It is only with leadership commitment and support that the platform overcomes these obstacles and stays focused on its long-term objectives. Too many roadmaps have been created and left by the wayside as the initial excitement of phase one dies down and everyone scatters or becomes tied up in the day-to-day complexities of operations.

It is up to the operating committee to continue to refer to any roadmaps, visions, and guiding principles as the North Star on all decisions, and to raise the alarm when business activities are beginning to stray from that path. Having regular (monthly or quarterly, depending on the footprint and net activities on the platform) business checkpoints to see whether roadmap goals are being achieved and whether the platform is continuing to fulfill the platform vision and effectively supporting the overall business strategy is important when fulfilling this objective. These business review sessions should not focus on the minutiae of individual enhancements, requirements, or defects; instead, they should evaluate whether the platform’s current business footprint is aligned with expectations, whether the platform’s business customers and users are realizing value from the implementation, and whetherany technical, process, or people gaps are affecting value realization, and what resources are needed to close such gaps.

Another important aspect of protecting the platform vision is to reject the next shiny objective that may be placed in front of the operating committee. Stakeholders from various areas of the business may be eager to get on board the platform, and while there are situations where a piece of fruit hangs so low it is highly worthwhile to take a detour to obtain it, it is more likely that deviating from the initial vision may spread resources too thin and reduce time to value across the board. The operating committee must stand ready in such instances to trust and stick to the plan and support the platform team against pressure.

Refreshing the platform’s vision, strategy, and roadmap

No plan will be perfect as they are always created with imperfect information that has implied and explicitly stated assumptions. The executive sponsor and operating committee should, on a semi-regular (bi-annual or annual) basis, evaluate whether the existing vision, strategy, and roadmap established for the platform are still valid for the business and its strategy. An important aspect of this evaluation is to look at what has been implemented and determine how many more resources to allocate to these areas versus how much to focus on net-new capabilities on the platform. Roadmaps often overemphasize the addition of new capabilities and provide less detail on incremental improvements of existing capabilities. However, during operations, the operating committee should pay close attention to what has already been developed as investments in operations to improve these areas may sometimes have the greatest return on investment with the least risk.

Empowering the platform owner and the platform team to make decisions

While the operating committee plays a key role in establishing and agreeing to the vision and standards of the platform, it is the platform owner and their team who enforce these standards day to day. The platform owner and demand managers must be comfortable with rejecting demands that may not fit the platform vision or are simply unachievable given the available resources. In distributed models, the platform owner should also be empowered to help their platform architects enforce platform technical integrity, which may occasionally mean that certain requirements become more resource-intensive to achieve to accomplish it properly.

Empowering the platform owner is not just a matter of granting them authority – it also means communicating that authority, its limits, and its purpose to those who engage with the platform.

Platform owner

The platform owner leads the platform team and is the key individual in delivering value to the organization from ServiceNow. Let’s take a look at their responsibilities.

Communicating and building consensus around the project plan

One of the major jobs of the platform owner is to communicate the vision and plan for the platform to its business customers. This includes socializing the roadmap with the stakeholders, constantly reporting on what is being developed on the platform and why, and how demands and enhancements on the platform are being prioritized. It also includes reporting on whether the platform is encountering any health issues or facing long-term trends (for example, performance issues, a high number of incidents in some part of the platform that may require a more focused problem management effort to address the root cause, or an increase or anticipated increase in HR service requests due to organizational changes such as recent and upcoming mergers).

Communicating the plan clearly and often will help align stakeholder expectations and, in the best case, make business customers partners to the platform and contribute solutions and resources as opposed to being passive consumers of outcomes. When funding, platform direction, and implementation are all centralized under the platform team, this type of communication becomes critical to the platform’s success. Without it, business customers can often feel in the dark about when and what they will receive from the platform.

Platform owners should be communicating the plan for the platform in a variety of ways, both one-on-one discussions with the key customer stakeholders and having repeatable assets (a slide deck, a document, and so on) that can easily be distributed to anyone who may be interested.

Using measurement to guide platform decisions

Business decisions, especially ones that can incur large costs, should always be backed up by measurements that allow the risk of failure to be justified. Platform owners will be asked to make many business decisions as part of platform operations, ranging from large (expanding the capabilities of the platform to service a new area of the organization) to small (deciding whether the additional risk incurred by the desired enhancement is worth the business outcome generated to the customer). Ideally, these decisions will be backed up by some sort of measurement. This can be easier said than done, and entire books exist about organizational KPIs and how to measure and model the risk of decisions properly. While we will not cover this topic in detail, we will provide a few guidelines for success regarding this topic:

• First, it is important to be aware of whether a decision needs to be made. A decision should have more than one viable option and there should be some cost associated with each decision. There will also be an element of uncertainty with each decision; if you are certain about each, then it should be trivial to understand which is better. Similarly, if each option is equivalent to another, there should be absolutely no hesitation in picking an option at random.
• Second, models and measurements should only be created and made if the possible result of that measurement will lead to a different decision. If you cannot establish ahead of collecting and measuring the desired data how the results of that data will cause you to choose between one or more options, it is unlikely that the measurement will be worth it. This rule also means that many of the complex or busy “dashboards” built by various business groups (including those by the ServiceNow platform team!) are irrelevant when it comes to generating business decisions. Instead of focusing on collecting more data that may not be relevant, the platform owner and their team (and any other business leader) should focus on what kind of decision they are looking to make and what kind of data will enable them to decide upon one decision or another.
• Third, never be afraid of treating data collection and measurement as a series of experiments instead of a single long-running initiative. Collect the right data and measure the right information for a given decision and move on after the decision has been made. There will rarely be long-running metrics that will continuously provide answers to inform continuous decisions (though there are some, such as looking at sudden and substantial changes in certain steady-state metrics that can drive decisions on problem investigation).

Advising the operating committee on what is needed to execute the platform’s vision

The platform owner is likely to be the most senior member of the operation team and has direct and deep knowledge of the business capabilities of the platform. When working with the operating committee, it is the platform owner’s responsibility to provide information to the rest of the committee about aspects of the platform that they may not be familiar with. This includes, among other things, the platform’s capabilities, limitations, and costs. While the platform owner may also not be an expert on each of these subjects, they must gather a team of technical leads, product owners, and architects that can provide them with this knowledge.

With this knowledge, the platform owner’s role regarding the operating committee is to ask for the right support to effectively execute the platform vision that has been established. If the direction and implementation capabilities of the platform are all centralized under the platform owner, then there will be an increased demand for the platform’s owner’s ability to create the right plan and obtain the right resources to be able to establish and then execute the vision.

Business analyst/product owner

The business analyst, or product owner, serves as the individual translating the needs of the business into platform requirements and designs. In terms of the platform team, they should take care of various aspects. Let’s take a look.

Understanding the needs of the customers and translating them into requirements

The business analyst/product owner’s role is to translate the needs of the customer into a product that serves those needs. In the case of the platform operations team, that product is the set of changes on the platform that must be made to meet those requirements. The product owner and business analyst aspire to know the business of the customer better than they may even know themselves. With a deep level of insight into the customer and with knowledge of the platform’s capabilities, an exceptional product owner can create requirements on behalf of their customer that address or exceed the customer’s expectations, as well as have requirements that will be well-aligned with the platform’s capabilities and avoid playing into the platform’s limitations.

The knowledge of the customer not only applies to creating great requirements but also enables the platform/product owner to be able to ruthlessly prioritize the backlog of priorities to deliver the right functionality to the customer in the right order and at the right time.

Understanding the customer’s needs also translates into communicating and managing the expectations of the customer so that they are aware of how capabilities will grow to meet their needs, both present and future. Therefore, the product owner acts partly as a relationship manager between the platform team and the customers of the platform and should help the platform owner understand where customer needs are being met and where there are deficiencies (either in perception or reality).

Interfacing with the technical team

The product owner must be able to communicate the functional requirements of the customer to the technical team so that they can be decomposed into a set of technical designs and platform configurations that allow the platform to meet those functional requirements. In a typical agile development environment, this means that the product owner must create artifacts that enable the functional requirements to be easily digested. They must walk through these artifacts with the development team to confirm that they are understood and estimable. Typical artifacts that are used to communicate the functional requirements to the developers include wireframes, mock-ups, user stories, and acceptance criteria. It is important to note that the format of the communication is not as important as being able to communicate the information concisely and clearly. Functional requirements communicated in this way must be somehow functionally verifiable after the configuration has been completed. Requirements not explicitly stated and not explicitly verifiable will be prone to “defects” as differences in interpretation between individuals cause discrepancies in what the product owner expects and what the developer has built. A small but common example of this would be positioning the user interface elements on a form. If no mock-up is provided and no details are specified for where a user interface element is to be positioned on the form, it is highly likely that a requirement such as there should be a button to cancel the request could result in the positioning of the button being different than what is expected by the product owner.

When developing requirements and interfacing with the technical team, the product owner needs to avoid providing technical solutions to the developers as much as possible, even if the product owner has enough technical understanding to know how a particular functional requirement may be addressed. Technical teams (in consultation with the architect) should always have the last say in how a particular functionality should be implemented. This provides the team with the greatest level of flexibility in meeting the functional requirement using the best technical options available. The assumption here is that the functional resource will not be as technically capable as the technical team, and even if they were, the functional resource will know fewer of the details of the platform, so they will be less qualified to make technical judgments.

Demand managers

As the organization stands up the ServiceNow platform, there will be no shortage of demands from stakeholders on how the platform can be made better. The demand manager’s job is to make sure the great ideas that are aligned with the platform’s strategy are surfaced, and frivolous requests are deprioritized. Great demand managers are constantly working on various aspects. Let’s take a look.

Managing the pipeline of incoming demands and improving the overall quality of demands over time

The key role of the demand manager is to manage the queue of demand from the product owner/business customers. Demand managers should recognize low-quality demands and reject them outright. For demands without enough detail but with high potential, demand managers should request the demand submitter to provide the required information to help the demand manager qualify the demand.

Demand managers differ from product owners in that demand managers work with a broader array of stakeholders and are more likely to encounter requests that are not qualified or are not aligned directly with the platform’s strategy and vision.

Beyond qualifying demands, demand managers also help shepherd the demand through the demand management process within the organization. This commonly only applies to demands that require budgets beyond the typical operational budget (you would not normally go through the demand management process for small enhancements that may be passed directly to the product owner).

Platform architect

The platform architect is not just a senior technical resource. At their best, a platform architect is a person deeply connected to the business and the entire footprint of the organization’s technologies who can help guide the technical design of the most crucial parts of the platform. The platform architect should identify and produce the shared data and architecture of the platform to be communicated by all technical teams.

Shared data and architecture are platform configurations that are consumed by specific modules and other configurations to accomplish business outcomes in a specific way. Once again, the CMDB and the Common Service Data Model (CSDM) are notable examples of shared data and architecture components. Regardless of the module, when the CMDB data is created or consumed, developers should follow common conventions in terms of which tables the CI data should go to and what attributes should be used for what purposes.

When the shared architecture is designed by the architect, they must also communicate how this shared architecture should be used to all developers (often via developer leads). This communication does not need to be verbal – in fact, even for small-scale teams, there is a significant value in documenting the architecture design, the reasoning, and examples of how to utilize the shared architecture both in terms of efficiency of communication and in the effectiveness of knowledge transfer for new and external team members.

Sometimes, it will not be obvious to an individual developer or product owner that a particular requirement calls for a shared architecture design. This is where the architect must leverage their experience and visibility across streams to identify these situations and work with the product owner and technical teams to incorporate the development of the shared architecture component as part of the requirement. This step is particularly important as not identifying the right shared architecture opportunities may result in development creating many inefficient point solutions on the platform that could have been simplified and consolidated into a single design. Nevertheless, because this process can never be flawless, an additional task of the architect is to identify situations where multiple point solutions should be merged as a single shared architecture component. They must work with the demand manager and/or product owner accordingly to allocate the correct time and resources to perform this consolidation at the right time.

Summary

In this chapter, we covered the key aspects of operating the platform that the organization should consider to improve the chances of obtaining a positive return on investment.

When your organization selects ServiceNow, make sure that you have considered who the immediate customers are that the platform has been built to serve, how the platform will fit within the broader technology landscape of the organization, what the operating model for the platform is, including demand management, implementation, and ongoing maintenance, and how to create the right team in service of the platform and the business to generate long-term value.

In the next chapter, we will move away from the people and processes side of the equation and highlight a cutting-edge feature of the platform that can be integral to value realization: artificial intelligence.