Building a Service Management Office

Change has its priorities. Release has another rhythm. Knowledge is working from a different backlog. Incident Management is solving today's problems while Problem Management is trying to prevent tomorrow's. Teams report to different leaders, measure different things, and build different roadmaps.

That was the environment we were trying to change.

Within a large Minnesota government organization, service-management responsibilities had developed across multiple teams and leadership structures. The practices were doing important work, but they were not always operating as one connected system. Different teams had different processes, KPIs, strategic roadmaps, and priorities, and ownership could become unclear.

The question became bigger than: how do we improve individual ITSM practices?

The question was: what would happen if we designed service management to operate as one service?

The challenge

Before the Service Management Office, many of the people responsible for service delivery were already working with the same stakeholders and solving interconnected problems.

But organizationally, the work was distributed.

That created predictable friction: practices could mature at different speeds; teams could establish different standards; reporting and KPIs were not always aligned; strategic priorities competed across leadership structures; cross-training and succession planning were harder; ownership could become unclear; and the same people often attended multiple meetings where pieces of the same service story were discussed separately.

The opportunity was not simply to reorganize staff. It was to create an operating model where the practices could be managed, measured, improved, and prioritized together.

The idea

The concept of a Service Management Office had been developing for some time, but a major ITSM platform transition created the right moment to rethink the broader operating model.

We built a business case around three different staffing scenarios and evaluated which service-management functions were closely connected enough to benefit from shared leadership and governance. The proposal was taken to senior IT leadership for review and ultimately approved.

One of the most important design decisions was recognizing that an SMO did not need to own every capability that touched service management. Some functions belonged inside the Service Management Office. Others made more sense as strong partner teams.

That distinction mattered. An SMO should not become an organizational land grab. The goal is not to collect every service-related function under one leader. The goal is to put the right capabilities together while creating strong operating relationships with the teams that remain elsewhere.

Designing the operating model

The Service Management Office brought closely connected service-management capabilities into a more integrated model while maintaining strong partnerships across the broader IT organization.

The broader model also relied on strong partnerships with the Service Desk, monitoring and availability teams, technical training, organizational change management, communications, IT operations, and other technology teams.

That network became just as important as the org chart.

Standardizing how the practices operated

Creating the organization was only the first step.

One of the first things I wanted to solve was a deceptively simple question: what does a well-operated ITSM practice look like here?

We already had a strong Change Management standard operating procedure, including positive internal audit feedback. I used that as a foundation for a common SOP structure that could be adopted across the Service Management Office.

Each practice documented how it operated, who owned what, and how the process should be governed. The SOPs were then placed on a quarterly review cadence so they would not become static documents sitting in a knowledge base while the actual process changed around them. The current operating model continues to use quarterly SOP reviews, regular practice audits, cross-training, and annual maturity assessments.

We also introduced standardized process documentation so each practice could communicate its purpose, workflow, roles, measures, and key operating components consistently.

The goal was not documentation for documentation's sake. It was to create a shared language.

Creating one operating rhythm

One of the clearest examples of integration became the Daily One Call.

Rather than discussing incidents, problems, changes, releases, and knowledge in completely separate conversations, the organization developed a short daily operating rhythm that brought those perspectives together.

Approximately 150 IT staff participate in this shared operating view.

What matters to me about this model is not the meeting itself. It is what the meeting represents.

Incident is no longer just Incident. A major incident might expose a recurring problem. That problem might create new knowledge. The corrective action might require a change. The change may be delivered through a release. The release needs communication, support readiness, validation, and knowledge.

Those practices were always connected. The operating model simply made the connection visible.

Moving from separate maturity plans to shared improvement

Another significant change came through maturity management.

Individual practices still need their own maturity assessments. Change Management and Knowledge Management do not have identical needs.

But the SMO made it possible to look across those assessments and ask a different question: where do the practices need to mature together?

That created a more coordinated improvement backlog. Instead of every practice independently fighting for attention and capacity, leadership could look across the Service Management Office, connect improvement opportunities to organizational strategy, and make deliberate tradeoffs about what should happen next.

Annual maturity assessments now produce a maturity roadmap for every practice, while continuous-improvement work is tied back to broader IT and organizational priorities.

A maturity assessment should not end with a score. It should change the work.

What changed

The biggest result was not an org chart. It was visibility.

People had a clearer understanding of how service-management practices connected. Leaders had a more integrated view of priorities and risk. Practice owners had common governance structures. Teams had more opportunities for cross-training. Service improvements could be prioritized against a shared strategy rather than existing as isolated wish lists.

The model also made it easier to connect operational readiness across Change, Release, Knowledge, Major Incident, Problem, Service Levels, Continuous Improvement, and the Service Desk.

For example, Release Management now operates as a quality gate before go-live, checking that approved change, knowledge, communications, and validation resources are ready before implementation.

That is what integration looks like in practice. Not every team doing the same job. Every team understanding how its job affects the next one.

What I learned

The bigger lesson

I used to think about service-management maturity primarily at the practice level. How mature is Change Management? How mature is Knowledge? How mature is Problem Management?

I still think those questions matter. But building a Service Management Office taught me to ask another one: how mature are the connections between them?

A highly mature Change Management practice operating independently from Incident, Problem, Release, Knowledge, and the Service Desk can still create a fragmented service experience.

The goal is not to have eight excellent practices. The goal is to create one excellent service system made up of practices that understand how to work together.

That is what I mean when I talk about unboxing ITSM. Take the practices out of their individual boxes. Then start connecting them.