Every Department Wants a Piece of the Platform. Nobody Agreed on the Rules.
ServiceNow starts as a tool. IT uses it for incident management. Then HR gets in. Then Customer Service. Then someone in Facilities submits a request. Somewhere between "one team's ITSM platform" and "the thing every department is building on," the question of who's actually in charge of strategy, priorities, and technical standards gets quietly set aside. This is how you answer it.
The Platform That Grew Faster Than the Rules Governing It
A large state agency had been running ServiceNow for six years. Over that time it had grown from a single IT service management deployment to a platform supporting IT, HR, Customer Service, Procurement, and a facilities management pilot. Fourteen teams were actively building on it. The platform was widely used, reasonably well-loved, and operationally critical.
It was also, by any honest assessment, a mess.
Development teams had been making their own architectural decisions for years — different integration patterns, different naming conventions, different levels of customization. The upgrade cycle had grown from a two-week project to a four-month ordeal because nobody had enforced standards that would keep customizations upgrade-safe. The roadmap was a negotiation between whoever had the most political capital at a given moment rather than a reflection of any coherent strategy. HR wanted their enhancement next. IT Security said their compliance feature was urgent. The Customer Service team had been waiting eight months for a change that kept getting deprioritized.
Asked who was in charge of the platform's strategic direction, the answer was effectively: everyone, and therefore no one.
The agency had a ServiceNow implementation. What it didn't have was ServiceNow governance. And without governance, a platform that had been a genuine asset was quietly becoming a liability.
✦ ✦ ✦
The Problem
What Happens to a Platform Without a Decision Framework
ServiceNow governance is not, as it's sometimes characterized, bureaucracy applied to a software platform. It's the answer to a set of questions that every organization using ServiceNow at scale needs to answer — and that, absent a deliberate framework, get answered badly through a combination of organizational politics, individual judgment, and accumulated default decisions.
The questions are straightforward. Why are we investing in this platform, and which business outcomes should it be advancing? What work should we prioritize when more demand exists than capacity? How should solutions be built to protect the platform's long-term health? Without governance, each of these questions gets answered differently by different people at different times — and the accumulated inconsistency is what produces the patterns familiar to every organization that has let a ServiceNow platform grow without structure.
The Five Symptoms of Missing Governance
Uncontrolled customization. Teams modify base system behavior to solve immediate problems without considering upgrade impact or architectural consistency. The platform becomes increasingly fragile and increasingly difficult to upgrade.
Competing priorities, no resolution mechanism. Every department believes their request is urgent. Without a structured prioritization process, whoever makes the most noise or has the most political capital wins — which is not the same as the most strategically valuable work getting done first.
Architectural inconsistency. Different teams solve similar problems differently. Integration patterns, naming conventions, data models, and workflow designs vary across the platform. What should be a unified system starts looking like several systems that happen to share infrastructure.
Upgrade failures. Years of ungoverned customization accumulate into upgrade debt. What should be a routine platform update becomes a months-long project to untangle modifications that shouldn't have been made the way they were.
Platform sprawl. New use cases get added to ServiceNow because it's available and familiar, without anyone evaluating whether ServiceNow is the right platform for the use case or whether the platform can absorb the additional scope without degrading existing capabilities.
None of these symptoms are inevitable. All of them are structural — they're the predictable outcome of a platform being used without a decision framework. Governance is that framework.
The Explanation
Three Governance Domains. Three Different Questions. One Coherent Platform.
ServiceNow governance is organized around three distinct decision domains, each responsible for a different layer of platform management. The three domains aren't a hierarchy in the sense that one is more important than the others — they're interdependent layers, each requiring the others to function. Strategic decisions without portfolio governance produce a vision that never gets executed. Portfolio governance without technical governance produces a prioritized roadmap built on a fragile platform.
Domain 1: Strategy Governance — "Why Are We Investing in This?"
Strategy governance is the layer that determines what the platform is for — which business capabilities it should support, which transformation initiatives it should advance, and how investment should be prioritized across competing organizational priorities. It's the domain that turns ServiceNow from a department's tool into an enterprise platform with a coherent direction.
Without strategy governance, ServiceNow evolves by accretion: each new request that gets approved adds a use case, each use case adds scope, and over time the platform's footprint grows without any organizing principle tying it to organizational outcomes. Teams can point to a long list of things ServiceNow does without being able to articulate a clear answer to why those things are on ServiceNow rather than somewhere else, or whether they're collectively advancing anything the organization cares about strategically.
The executive steering board owns this domain. Its membership — CIO, executive sponsor, business unit leaders, enterprise architecture leadership — reflects the organizational level at which platform direction should be set. This is not the group that approves individual features. It's the group that decides which business capabilities the platform should serve and what the platform should look like in three years.
The outputs of strategic governance are the artifacts that give everything below them direction: the platform vision, the long-range roadmap, the investment priorities, the criteria by which new use cases get evaluated as "ServiceNow work" versus "not ServiceNow work."
Domain 2: Portfolio Governance — "What Do We Work on Next?"
Portfolio governance is where strategy meets reality. It's the mechanism that takes organizational demand — enhancement requests, new projects, compliance requirements, department asks — and translates it into a prioritized, sequenced roadmap that the delivery team can actually execute.
This is the domain that the state agency from our opening story was missing most visibly. Without a structured demand board and a clear prioritization process, their roadmap was whatever the last argument had concluded. The HR team's request wasn't evaluated against the IT Security team's request on any objective basis. Whoever made the more compelling political case in a given week got their work scheduled first.
Portfolio governance replaces that chaos with a process: requests come in, get evaluated against business value and strategic alignment, get reviewed against available delivery capacity, and get approved, rejected, or queued. The demand board — typically including the platform owner, platform architect, process owners, and portfolio managers — is the body that runs this process and owns the resulting backlog.
The most important output isn't the backlog itself. It's the decision record behind the backlog — the documented rationale for why certain requests were prioritized and others weren't. That record is what makes portfolio governance defensible to departments whose requests didn't make the cut, and it's what makes the prioritization consistent over time rather than re-litigated from scratch in every planning conversation.
Domain 3: Technical Governance — "How Should This Be Built?"
Technical governance is the domain that protects the platform's long-term health. It's the layer that prevents individual delivery decisions from accumulating into architectural fragmentation, upgrade risk, and the kind of technical debt that turns routine platform maintenance into a four-month project.
The core question this domain answers is: when a team proposes to build something on ServiceNow, how should it be built? Custom or configured? What integration pattern? What data model? What development standards? Left to individual teams, these questions get answered in whatever way seems most expedient at the time. The technical governance board — platform architects, development leads, security and compliance representation, UX and QA — is the design authority that answers them consistently.
The most important technical governance decisions are often the ones that feel minor in the moment. The choice to modify a base system table rather than extend it. The decision to hardcode a value rather than create a configuration parameter. The integration built with a bespoke script rather than the governed Integration Hub connection. Each one is a small technical debt. Compounded across fourteen teams over six years, they become the four-month upgrade cycle.
"Governance isn't what slows the platform down. The absence of governance is what slows it down — in upgrade cycles that drag on for months, in prioritization arguments that never resolve, in architectural fragmentation that compounds with every deployment."
How It Works
The Three Domains Only Work When They Inform Each Other
The most common governance failure isn't the absence of all three domains — it's having two of them without the third, or having all three without the feedback loops between them.
Strategic governance without portfolio governance produces a compelling platform vision that never gets operationalized because there's no mechanism to translate strategic priorities into a sequenced delivery plan. Portfolio governance without technical governance produces a well-prioritized backlog that gets built in whatever architectural pattern each delivery team prefers. Technical governance without portfolio governance produces impeccably designed solutions to the wrong problems.
The healthy version looks like this: the executive steering board sets the platform direction and investment priorities for the year. The demand board uses those priorities as the evaluative criteria for incoming requests, building a roadmap that reflects strategic intent rather than organizational politics. The technical governance board reviews solution designs before development begins, ensuring that what gets built follows the patterns that protect upgrade safety and architectural consistency. When a technical constraint affects delivery timelines, it flows back to the demand board. When market or business changes shift strategic priorities, that flows down to portfolio sequencing. The three domains talk to each other.
What Changes When Governance Is Working
For the state agency in our opening story, the governance program that came out of the maturity assessment changed several things that had seemed intractable.
The upgrade cycle — previously four months — dropped to six weeks once the technical governance board established and enforced upgrade-safe development standards. There was no magic in this; it was simply the result of having a design authority that reviewed customizations before they were built rather than discovering them when the upgrade broke.
The prioritization arguments that had been consuming planning cycles resolved — not because everyone agreed, but because the demand board had objective criteria against which requests could be evaluated. Departments still made their cases. The board made the call. The decision was recorded and explained. Teams didn't always get what they wanted, but they understood why.
The platform roadmap, for the first time, reflected a coherent strategy rather than the accumulated results of six years of individual project decisions. New requests were evaluated against that strategy. Some were approved quickly because they clearly advanced platform objectives. Some were rejected with clear explanations. Some revealed gaps in the strategy that the executive steering board needed to address.
Summary
The Platform Doesn't Need More Features. It Needs a Decision Framework.
The state agency didn't have a ServiceNow problem. It had a governance problem that was expressing itself through the platform. The fragmentation, the upgrade pain, the prioritization gridlock — all of it was downstream of the same root cause: a strategic enterprise platform being managed without a framework for making and enforcing decisions about it.
The three governance domains — strategy, portfolio, technical — aren't bureaucracy. They're the structure that allows a platform used by fourteen teams across multiple departments to remain coherent, upgradeable, and aligned with organizational goals.
- Strategy governance ensures the platform evolves with intent.
- Portfolio governance ensures the right work gets done in the right order.
- Technical governance ensures the work that gets done doesn't compound into future problems.
Implemented together, with the feedback loops between them functioning, they transform ServiceNow from a collection of departmental solutions into a genuine enterprise platform. That transformation doesn't happen through features. It happens through decisions — made deliberately, documented clearly, and enforced consistently by the right people at each level.
Fourteen teams. One platform. Three governance domains. Start there.
