Design Coordination — The Conductor of Service Design (Yes, You Need a Baton)

"Design without coordination is a garage band trying to play Beethoven. Loud, enthusiastic, and completely out of sync."

If Service Strategy told us what services will make the organization win, and Service Design Overview showed how those services should look, then Design Coordination is the part of the score that makes sure the trumpets don’t drown out the violins. It’s the glue, the calendar, the polite-but-firm project manager who stops everyone from doing their own thing.

This topic builds on Service Strategy’s emphasis on designing services as strategic assets. Now we move from "we should" to "we will, and we’ll do it the same way across the whole organization."

---

What is Design Coordination? (Short, practical definition)

Design Coordination is the ITIL process that ensures consistent and effective design of new or changed services by: coordinating activities across design projects, maintaining the Service Design Package (SDP) baseline, controlling design inputs and outputs, and acting as the central point for governance, standards, and communication.

In one sentence: it’s the air traffic control for all service design work.

---

Why it matters (and why you should care)

• Prevents duplicated effort and contradictory designs
• Ensures designs meet strategic objectives set by Service Strategy
• Smooths handoff to Service Transition (reduces rework)
• Reduces risk, cost overruns, and the “it worked in dev but exploded in production” syndrome

Ask yourself: "Do I want my services designed once, correctly, and sustainably — or do I want firefighting 24/7?" Answering that determines how much respect Design Coordination gets.

---

Core objectives

1. Coordinate all design activities across projects, programs, and portfolios.
2. Maintain design integrity through standards, templates, and governance.
3. Ensure completeness and quality of the Service Design Package (SDP).
4. Manage interfaces between design processes, stakeholders, and other lifecycle phases.
5. Control changes to designs and handle design-level risks and issues.

---

Key activities (the real work — what you’ll actually do)

• Create and maintain a Design Coordination Plan (timeline, roles, milestones)
• Assemble and validate Service Design Packages (SDPs)
• Facilitate design workshops and review boards
• Maintain a Design Register (catalog of ongoing/complete designs)
• Ensure alignment with policies (security, compliance, architectural standards)
• Coordinate supplier and partner inputs
• Manage design-related risks, assumptions, and constraints

---

Inputs and Outputs (cheat-sheet)

Inputs	Outputs
Service Strategy documentation	Approved Service Design Package (SDP)
Business requirements / SLAs	Design Coordination Plan
Existing service catalog & CMS/CMDB data	Design Register entries
Risk assessments, supplier agreements	Design review minutes & action logs

---

Interfaces — who does Design Coordination talk to? (Lots of people.)

• Service Strategy: receives requirements and strategic priorities
• Service Catalog Management: updates when designs become services
• Service Level Management: ensures SLAs are design-feasible
• Supplier Management: coordinates external design contributions
• Availability/Capacity/ITSCM/Security Management: reviews and signs off on technical constraints
• Service Transition: hands off the SDP and supports Deployment Planning

Quick mental model: Design Coordination = central switchboard. Everything rings through it before it goes live.

---

Tools & templates that actually save lives

• SDP template (functional, technical, operational, transition, acceptance criteria)
• Design Register (spreadsheet or CMDB table)
• Review checklists and sign-off forms
• Risk & issues log specific to design
• Version control for design artifacts (Git, SharePoint, etc.)

Code block example: Simple SDP checklist (pseudocode)

- Business requirements: ✔
- SLA/OLA/KPI definitions: ✔
- Technical architecture diagrams: ✔
- Security controls mapping: ✔
- Supplier roles & contracts: ✔
- Operational runbooks & support model: ✔
- Acceptance & testing plan: ✔

---

RACI (because someone always asks who’s responsible)

Design Coordination: R - Accountable
Service Architect: A - Approves technical design
Project Manager: C - Consulted
Service Owner: I - Informed
Supplier: C - Consulted
Service Transition: R/C - Responsible for handover actions

(Adapt this, but keep the central accountability with Design Coordination.)

---

KPIs & metrics you should track

• % of SDPs delivered on schedule
• % of SDPs passing initial quality review
• Number of design-related incidents within 30 days of deployment
• Rework rate (design changes during Transition)
• Stakeholder satisfaction with design process

Measure these monthly or per-project. If your numbers are bad, don’t bury them — fix the process.

---

Common pitfalls & how to avoid them

• Siloed teams doing ad-hoc designs → Enforce one Design Register; mandate SDP completion
• Poor version control → Use a central repository with approvals
• No authority for Design Coordination → Give it governance teeth (chair design review board)
• Late supplier involvement → Bring suppliers into design workshops early
• Overly bureaucratic process → Keep templates pragmatic; timebox reviews

---

Short real-world example (email service rollout)

1. Strategy defines a single global email platform
2. Design Coordination sets up the project SDP template and schedule
3. Architects produce standard architecture; suppliers provide hosting design
4. Design reviews find a compliance gap — updated SDP, minor delay, documented risk
5. SDP handed to Service Transition with clear acceptance criteria and runbooks
6. Deployment meets SLAs; rework minimized because the SDP was complete

Ask: How many of your projects stumble because someone forgot to document acceptance criteria?

---

Closing — what you should remember (and say loudly in meetings)

• Design Coordination is not paperwork — it’s governance, quality control, and communication all in one.
• If you want predictable, low-risk deployments, invest in a strong Design Coordination function.

Final mic-drop: "Good design is inevitable when coordination is non-negotiable."

Key takeaways:

• Centralize design activities and artifacts
• Use templates and checklists, but keep them lean
• Treat Design Coordination as a gatekeeper and a facilitator, not a bottleneck

Now: go look at your last three SDPs. Are they complete? If not, make Design Coordination your new best (and bossy) friend.