Specification, Realization, and Service Management

The savage journey into the heart of service management I began decades ago has always been filled with the wisdom of best practices. Process before tool is one of them.

The basic truth of process before tool isn’t some suggestion from a self-help guru; it’s been a cornerstone of best practice since the TQM days of the 1950s, and frankly I find the desire to only prototype directly on the delivery platform a sure road to hell.

Sure, it's fast and cheap, a quick fix, like a shot of bottom-shelf whiskey. You can get real-time feedback, see tangible outcomes quick and dirty. But let's get real: it’s like grabbing a fistful of whatever the vendor’s been peddling; it's "you get what we give ya’", a pre-packaged experience. And before you know it, you're sucked into the vendor's vortex, caught in a vendor lock-in, a technological black hole where your great idea gets twisted and repackaged as their next big thing. You’ll be so busy following their lead, adopting their preferred practices (ITIL, anyone?) you won't evolve, you won't adapt, you'll just be another cog in their profit-making machine.

The principle of "process before tool" is widely regarded as a best practice in IT service management (ITSM) and broader business transformation because it ensures that technology supports business needs, rather than dictating or constraining them.

Specification, Realization, and Service Management

So, you might wanna think about this; specify your needs before you go throwing money at tools. You're not just buying a thing; you're defining a whole ecosystem. That's where separation of duties comes in, like a well-placed stick of dynamite to blow open the doors of perception.

By splitting the work between specifying and realizing, you gain control, like a gunslinger controlling their domain. The guys doing the spec work (functional management) are focused on what the customer actually needs and then the technology guys work independently, as long as they deliver to the agreed spec.

Specification is where you, the architect of your digital domain, figure out what you actually need before you go throwing money at the shiny gadgets. It's about understanding your business requirements and critical processes independent of any platform or tool. This is not about what a vendor can offer you out-of-the-box; it's about what your business demands.

Think of it as crafting a detailed blueprint for your technological needs:

• Focus on Business Needs: Specification forces you to define what you want to achieve, not just what a tool can do. It's about business goals, customer satisfaction, and efficiency.
• Future-Proofing: When you specify first, you're designing for adaptability. You are more easily able to adjust to new technologies without having to tear down your whole system. You keep your options open and aren't tied to one platform.
• Flexibility: It ensures that you choose tools based on how well they meet your needs and not the other way around. This supports the "process before tool" philosophy.
• Avoiding Vendor Lock-in: By focusing on your specific requirements first, you’re not beholden to a particular vendor or tool.

Realization is where the rubber meets the road, where those specifications get turned into tangible solutions. This is the realm of technology management and involves the internal workings of the task domain. Realization is the execution of the plan and should be optimized independently of the customer, as long as the agreed-upon specifications are met.

• Internal Optimization: Realization is about the technical implementation, which is handled as an internal matter for the task domain. The aim is to optimize the technical aspects of service delivery, while always delivering to the specs.
• Meeting Specifications: The primary concern of the realization phase is that the delivered service matches the defined specifications.
• Technical Expertise: Realization is about the actual work, whether it’s done by your own team or an external provider, that transforms specifications into solutions.

How to Walk and Chew Gum

Where does Service Management fit into all of this? It’s about how you manage the entire lifecycle of services, from the moment they're conceived to the moment they’re delivered and beyond. The Unified Service Management (USM) method is an example of a service management method that gets this. USM emphasizes a hybrid approach, recognizing that there is a time for fast, easy platform-based prototyping and a time for more deliberate specification.

• Separation of Duties: A core concept in USM is separating the responsibilities and authorities for tasks by creating a cut between specifying and realizing. This is achieved through domain separation and process-based working.
• Domain separation divides a task domain into two sub-domains: one for specifying what is needed (functional management), and one for realizing the specified solution (technology management)
• Process-based working is where management tasks are separated into process management (specifying the routines) and line management (realizing the routines). The organization does not have to coordinate work in a process-based manner but can choose to have a balance between process and team-based coordination. This provides structure and control.
• Hybrid Approach: USM promotes a blend of both approaches, which allows for flexibility and efficiency. This means starting with high-level specifications, then leveraging the delivery platform for rapid prototyping and iterative refinement.
• Balanced Governance: A key factor here is having a formal review process that ensures alignment between those initial specs and the final platform implementation.
• Workflow-Based Work: USM emphasizes the importance of workflows over individual processes. This allows service management to move from process-based to workflow-based approaches.
• Team Structures: USM doesn’t standardize organizational structures, instead focusing on how those structures contribute to control over supply chains. Teams can be structured in different ways, such as by infrastructure, service quality, or activity.
• Clear Profiles: USM uses roles, functions, and profiles to assign responsibility. These include process managers, line managers, process coordinators, line coordinators, operators, and service managers. This creates a framework for responsibilities and workflows.

In essence, Specification is about defining what you want, Realization is about how you achieve it, and Service Management is about how you control and optimize the entire process. This is not an either/or proposition, but rather a dynamic balance to achieve the optimal results. USM is a learnable method that seeks to provide control, efficiency, and adaptability to the organization.

Let’s Get Real

The business sharks have seen through the mirage of IT’s utopian single-platform dream—a slickly marketed utopia where everything fits perfectly, as long as you want what they’ve already built.

No, the business is wising up. They’re wielding the cold, hard logic of process-first pragmatism, demanding tools that let them dictate the terms. They want to carve their vision into stone—specific, unflinching, and painfully exact—before IT even lays a finger on their precious platforms.

So, IT’s dream of a seamless, all-in-one playground for development is just more of the same old “you get what we give ya” nonsense, and the business isn’t buying it this time.

Process Before Tool and the USM method

The "process before tool" principle remains a cornerstone because it addresses a universal challenge: technology evolves rapidly, but business needs and operational principles are more stable. By focusing on processes first, organizations ensure their technology investments remain relevant and impactful over time.

This principle has proven resilient because it delivers consistent results across industries, frameworks, and technological shifts, making it a timeless best practice.

Enterprises that adopt the Unified Service Management (USM) method gain a structured yet flexible method that bridges the gap between specification and realization in service management. USM’s process-driven approach ensures that organizations clearly define their needs and desired outcomes before selecting or deploying tools, aligning with the principle of "process before tool."

At the same time, its emphasis on standardization and modularity allows for seamless realization of these specifications on delivery platforms without compromising on innovation or adaptability. This balanced approach reduces inefficiencies, avoids vendor lock-in, and empowers organizations to implement solutions that are both technically feasible and aligned with strategic business goals, creating a sustainable foundation for continuous improvement.

Ready to join the USM Revolution?

Contact me today for:

• USM Workshops
• Self-Paced USM Foundation Training (coming soon!)
• The USM Public Forum

Start learning an using the USM method!