CMS Hybrid Cloud

From Operational Visibility to Service Stewardship

Helping an evolving cloud service ecosystem understand how customer support, shared services, lifecycle operations, governance, and continuous improvement worked together over time.

A newly established Customer Support Team, an emerging product catalog, and a growing network of shared services were reshaping how customers engaged with the Hybrid Cloud platform.

Individual teams understood their responsibilities, but no shared model existed to explain how customer support, service capabilities, operational processes, and governance activities connected across the customer lifecycle.

The operating model was evolving faster than its collective understanding. Knowledge was distributed across teams, contracts, Confluence documentation, Jira workflows, and institutional memory. Creating shared visibility became the foundation for understanding, improving, and stewarding the ecosystem over time.

Reflection

At CDC, I learned how services become operable, governable, and capable of evolving over time.

At CMS Hybrid Cloud, I learned how stewardship itself becomes an operational capability.

The challenge was no longer understanding a service.

It was designing the structures required for continuous evolution.

Role

Lead Service Designer

Partnered with Customer Support Services, Shared Services, Product, Platform, and Operations stakeholders to establish visibility across customer support, operational ownership, lifecycle delivery, shared service dependencies, and service stewardship.

Focus Areas

Service Ecosystem Mapping

Service Blueprinting

Operational Research

Lifecycle Modeling

Service Analysis & Stewardship

Engagement

2025-Present

Hybrid Cloud Customer Support Services

Federal contract held by LeCor Technologies LLC (employer).

Customer Support Services Operating Model

Making Customer Support Visible

Customer Support Model

Core Question

How do we make an emerging service ecosystem understandable?

Hybrid Cloud’s Customer Support Team had recently been established to support customer onboarding, operational guidance, and ongoing service engagement.

At the same time, the organization was transitioning toward a capability-based service model supported by an emerging product catalog and a growing network of shared service teams.

Operational knowledge existed across organizational structures, customer engagements, documentation, workflows, and institutional memory.

What did not yet exist was a shared model explaining how those pieces connected across the customer lifecycle.

The ecosystem already existed.

The challenge was not documenting a service.

Understanding how its people, services, capabilities, and operational responsibilities connected did not.

Customer Support Services Operating Model: Establish customer-facing support structure and introduce operational ecosystem

Customer Support Services Operating Model

Purpose

Establish customer-facing support structure and introduce the ecosystem

Enabled

Clearer view of the emerging support model

Shared language for customer-facing responsibilities

Foundation for operational ownership discussions

Starting point for lifecycle and ecosystem discovery

The model introduced the core Customer Support Services roles, engagement responsibilities, and supporting operational functions needed to understand how customer support was taking shape.

It created an initial foundation for discussing:

Hosting Coordinator

Technical Advisor

Financial Analyst

Customer engagement responsibilities

Supporting operational functions

Cross-team coordination needs

Blueprint Expansion Framework: Expand visibility beyond onboarding into services, governance, tools, roles, and dependencies

Blueprint Expansion Framework

Purpose

Expand visibility beyond onboarding into services, governance, tools, roles, and dependencies

Enabled

Visibility into operational relationships

Common structure for future discovery

Reduced fragmentation across initiatives

Foundation for ecosystem-level understanding

The initial onboarding model provided a starting point, but additional layers quickly emerged.

As onboarding became clearer, connections appeared between customer support, cost optimization, governance activities, operational support teams, supporting technologies, and shared services.

The blueprint needed to evolve beyond onboarding into a framework capable of supporting ecosystem-level understanding.

The framework helped capture:

Customer lifecycle activities

Operational roles

Service capabilities

Governance interactions

Supporting tools

Operational dependencies

REFLECTION

The challenge was not documenting a service.

It was establishing a structure capable of understanding an ecosystem.

Defining Operational Ownership

Core Question

Who owns the work required to deliver the service?

Artifact

The Customer Support Team model established a customer-facing structure for onboarding, operational guidance, and service engagement.

At the same time, leadership was introducing a CRM platform intended to consolidate customer support activities that had previously been distributed across Confluence, Jira, and institutional knowledge.

Ten operational roles had already been identified, but their responsibilities, information needs, workflow ownership, and decision-making activities were not yet consistently defined.

The platform was evolving alongside the operating model.

The roles existed. The platform existed. The relationships between them had not yet been formally defined.

Operational ownership was distributed across people, decisions, information, workflows, and governance structures.

The next challenge was understanding how those relationships actually worked.

Operational Roles & Ownership Landscape: Understand responsibilities, workflows, collaboration patterns, and ownership boundaries
CRM Role Profiles: Document operational roles and responsibilities

Operational Roles & Ownership Landscape

Purpose

Understand responsibilities, workflows, collaboration patterns, and ownership boundaries

Document operational roles and responsibilities

Enabled

Clearer ownership boundaries

Improved understanding of role responsibilities

Visibility into workflow participation

Foundation for CRM design decisions

Research was conducted across ten operational roles involved in onboarding, customer support, governance, platform administration, content management, auditing, and cost optimization.

Roles included:

Hosting Coordinator

Technical Advisor

Financial Analyst

FinOps Engineer

Data Auditor

Super Admin

Technical Writer

Oversight & Management

General Consumer

QA Tester

The goal was not to document job descriptions.

The goal was to understand how operational work moved through the ecosystem.

Operational Needs & Capability Mapping: Identify recurring operational needs independent of individual roles

Operational Needs & Capability Mapping

Purpose

Identify recurring operational needs independent of individual roles

Enabled

Shared understanding of operational requirements

Ecosystem-level capability visibility

Better alignment between platform and operations

Reduced role-specific solutioning

The role profiles revealed patterns that extended beyond individual responsibilities.

Across roles, common needs emerged around:

Information visibility

Workflow coordination

Decision support

Reporting

Collaboration

Customer context

Operational requirements were becoming visible independent of individual enhancement requests.

Patterns could now be discussed at the ecosystem level rather than one role at a time.

Role-Based CRM Framework: Align permissions, dashboards, workflows, and responsibilities to operational roles

Role-Based CRM Framework

Purpose

Align permissions, dashboards, workflows, and responsibilities to operational roles

Enabled

Improved alignment between responsibilities and access

More tailored operational experiences

Clearer workflow ownership

Foundation for scalable governance

As CRM development progressed, research revealed that operational responsibilities, workflows, information needs, and decision-making activities varied significantly across the ecosystem.

The framework evaluated:

CRUD permissions

Dashboard visibility

Workflow ownership

Decision support

Role-based experiences

The challenge extended beyond feature gaps.

The CRM needed to support distinct operational experiences shaped by role, responsibility, workflow participation, and decision ownership.

REFLECTION

Operational ownership was distributed across people, decisions, information, workflows, and governance structures.

The CRM was not the story.

Operational architecture was.

Understanding Lifecycle Delivery

Core Question

How does the service operate across its lifecycle?

Artifact

The Customer Support Team model established who participated in onboarding, but the onboarding experience itself remained distributed across workflows, guidance documents, role expectations, and institutional knowledge.

At the same time, leadership was introducing cost optimization earlier in onboarding as a strategic business objective.

This required incorporating Financial Analysts and cost management activities directly into customer onboarding.

Separately, responsibilities were being redistributed between Technical Advisors and Hosting Coordinators as the organization refined how onboarding work should be performed.

The goal was to create a unified operational view of onboarding that connected customer engagement, technical enablement, governance, and cost optimization activities.

Customer onboarding was not a single workflow.

It was an orchestration layer connecting multiple operational roles, decisions, and service activities.

Initial ONBI Lifecycle Blueprint: Capture onboarding activities, responsibilities, governance, and dependencies
Unified ONBI Blueprint: Converge onboarding activities into a single operational model

Building a Complete ONBI Model

Core Question

How do independent activities become a customer journey?

Purpose

Create a unified operational model of customer onboarding.

Enabled

Unified onboarding view

Reduced process fragmentation

Improved cross-functional collaboration

Greater lifecycle visibility

The first operational model connecting onboarding activities, customer engagement, governance interactions, and cost optimization efforts emerged.

Understanding onboarding required understanding how work moved between people, processes, governance activities, and service teams.

Validated ONBI Journey: Validate lifecycle model with operational stakeholders

Validating Operational Reality

Core Question

Does the model reflect reality?

Purpose

Validate lifecycle model with operational stakeholders

Enabled

Unified onboarding view

Reduced process fragmentation

Improved cross-functional collaboration

Greater lifecycle visibility

The onboarding blueprint had been assembled from multiple efforts.

Before expanding further, the model needed validation with Customer Support Services stakeholders.

Workshops and collaborative review sessions were conducted to validate:

Onboarding stages

Operational ownership

Process sequencing

Customer interactions

Supporting responsibilities

The onboarding model evolved from a synthesized framework into a validated operational representation.

Visibility only creates value when the people performing the work recognize themselves within the model.

Initial O&M Lifecycle Model: Capture recurring post-go-live operational rhythms

Extending Beyond Onboarding

Core Question

What happens after go-live?

Purpose

Capture recurring post-go-live operational rhythms

Enabled

Visibility into post-launch operations

Recognition of operational rhythms

Foundation for O&M analysis

Expanded lifecycle perspective

Once onboarding was understood, attention shifted toward the customer experience after deployment.

A recurring pattern quickly emerged.

Customer support activities appeared to operate through distinct operational rhythms.

Analysis revealed recurring rhythms aligned around:

Weekly Operational Analysis

Monthly Customer Engagement

Quarterly Optimization

Annual Governance & Funding

End-of-Service / Decommissioning

The customer lifecycle did not end at go-live.

Operational stewardship existed as a lifecycle of its own.

The lifecycle did not end at go-live.

It simply entered a different operating rhythm.

Integrated ONBI + O&M Blueprint: Create end-to-end lifecycle model

Completing the Lifecycle

Core Question

What does the full service lifecycle look like?

Purpose

Create an end-to-end lifecycle model

Enabled

End-to-end lifecycle visibility

Shared operational model

Stronger lifecycle planning

Foundation for stewardship activities

For the first time, onboarding and ongoing operations could be viewed together.

The lifecycle extended across:

Customer Interest

Onboarding

Operational Management

Optimization

Governance

Decommissioning

The service was no longer understood through organizational structures alone.

It could now be understood through the customer lifecycle.

The lifecycle became the organizing principle for understanding how the ecosystem functioned.

REFLECTION

Onboarding, operations, optimization, governance, and decommissioning were no longer separate activities.

They became connected stages within a larger service journey.

Revealing the Shared Service Ecosystem

Core Question

What services actually create customer outcomes?

Initial Shared Services Ecosystem Map: Visualize services, teams, and capabilities contributing to customer outcomes

As onboarding and operations matured, Customer Support Services repeatedly depended on capabilities that existed outside its direct ownership.

Funding, governance, security, product engineering, platform operations, observability, and cost management all influenced the customer experience.

The customer lifecycle was visible. The service ecosystem supporting it was not.

The customer experience was being shaped by capabilities distributed across multiple teams.

Understanding the lifecycle revealed a new reality.

Many of the activities shaping customer outcomes existed outside Customer Support Services itself.

The next challenge was understanding how those capabilities interacted and where dependencies existed.

Shared Services Dependency Model: Understand lifecycle dependencies across operational partners

Mapping Operational Dependencies

Core Question

What capabilities does the service depend on?

Purpose

Understand lifecycle dependencies across operational partners

Enabled

Clearer dependency visibility

Stronger cross-team coordination

Better operational planning

Reduced ownership ambiguity

Analysis revealed recurring dependencies between Customer Support Services and operational partners.

Recurring dependencies included:

Product Engineering

Operations

Security

Cost Management

Platform Administration

Governance Functions

Observability

Funding

Services were not delivered independently.

They were delivered through interconnected operational relationships.

Cost Management Service Model: Understand optimization as a lifecycle capability

Understanding Cost Management as a Service Capability

Core Question

Where does optimization begin?

Purpose

Understand optimization as a lifecycle capability

Enabled

Earlier optimization planning

Greater cost visibility

Alignment between onboarding and operations

Lifecycle-oriented decision making

Leadership was intentionally moving cost optimization earlier into onboarding to improve financial outcomes for both customers and the platform.

Cost management activities touched:

Onboarding

Operations

Optimization

Governance

Cost management evolved from a supporting activity into a lifecycle capability.

Optimization begins long before operational issues emerge.

Governance Interaction Model: Reveal governance participation throughout the lifecycle

Revealing Governance Interactions

Core Question

Where does governance actually occur?

Purpose

Reveal governance participation throughout the lifecycle

Enabled

Governance visibility

Improved compliance awareness

Better lifecycle planning

Stronger operational alignment

Customer lifecycle activities repeatedly intersected with governance requirements.

Examples included:

Approvals

Security activities

Compliance checkpoints

Annual funding cycles

Governance became visible as an operational participant rather than a downstream review process.

Governance was not occurring outside the lifecycle.

It was occurring throughout the lifecycle.

Ecosystem-Wide Blueprint: Connect customer support, governance, lifecycle, shared services, and stewardship into a single model

Understanding the Ecosystem as a System

Core Question

What is really producing customer outcomes?

Purpose

Connect customer support, governance, lifecycle, shared services, and stewardship into a single model

Enabled

Ecosystem-wide visibility

Shared understanding of customer outcomes

Recognition of shared services as active participants

Foundation for service stewardship

The operational model expanded beyond:

Customer Support

Onboarding

Operations

and began incorporating:

Shared Services

Governance

Optimization

Lifecycle Stewardship

Customer outcomes were being produced by an interconnected ecosystem of services rather than individual teams.

Governance, funding, security, observability, engineering, and cost management were no longer invisible dependencies.

They became visible participants in the creation of customer outcomes.

REFLECTION

The customer experience was being shaped by capabilities distributed across the organization.

Services were not delivered independently.

They were delivered through interconnected operational relationships.

From Visibility To Service Analysis

Core Question

Where is the ecosystem struggling?

Operational Findings Repository: Capture recurring friction points, findings, and recommendations

As operational visibility increased, recurring friction points began appearing across onboarding, operations, governance, readiness, and shared services.

Teams were no longer asking: How does the ecosystem work?

They were asking: Where is the ecosystem struggling?

The ecosystem was now understandable.

It was not yet optimized.

Visibility created the conditions for analysis.

The next challenge was moving beyond understanding and toward improvement.

ONBI Findings Analysis: Analyze onboarding challenges and readiness gaps

Analyzing Customer Onboarding

Core Question

Why do onboarding challenges occur?

Purpose

Analyze onboarding challenges and readiness gaps

Enabled

Readiness visibility

Better onboarding planning

Earlier risk identification

Stronger customer preparedness

Recurring themes emerged around:

Readiness

Customer education

Service awareness

Governance alignment

Operational handoffs

Customer responsibilities

Many onboarding challenges were caused by readiness gaps rather than process gaps.

The onboarding blueprint evolved from a visibility artifact into a continuous improvement framework.

O&M Analysis Framework: Analyze recurring operational support activities

Analyzing Operations & Maintenance

Core Question

What does healthy operational stewardship require?

Purpose

Analyze recurring operational support activities

Enabled

Visibility into operational rhythms

Improved stewardship planning

Stronger customer engagement strategy

Recognition of lifecycle-based support

Recurring themes emerged around:

Customer engagement rhythms

Optimization activities

Operational planning

Incident response

Governance participation

Lifecycle stewardship

Operational support was not a collection of support activities.

It functioned as a service lifecycle.

Customer Readiness Framework: Evaluate customer preparedness across lifecycle stages

Recognizing Readiness as a Lifecycle Capability

Core Question

Are customers actually prepared for success?

Purpose

Evaluate customer preparedness across lifecycle stages

Enabled

Shared readiness model

Earlier intervention opportunities

Improved customer outcomes

Foundation for readiness governance

Recurring onboarding challenges frequently appeared later during implementation, operations, and governance activities.

Customers often entered lifecycle stages before the necessary prerequisites were in place.

Stage-based readiness emerged as a strategic framework for evaluating customer preparedness across the lifecycle.

Readiness was not a checkpoint.

It was a capability requiring continuous development.

Cloud Optimization Workshop & Action Planning: Transform findings into improvement opportunities
Service Playbook / Findings Portfolio / Enhancement Roadmap: Organize improvements into a structured portfolio

Converting Findings Into Action

Core Question

How do findings become improvements?

Purpose

Transform findings into a structured portfolio of prioritized improvement opportunities.

Enabled

Prioritized enhancement portfolio

Structured improvement pathways

Better strategic decision making

Continuous improvement planning

Recurring themes included:

Readiness

Governance

Feedback Collection

Observability

Infrastructure planning

Operational rhythms

Incident response

Optimization

The ecosystem could now be improved intentionally rather than reactively.

REFLECTION

Understanding alone no longer created value.

The challenge was turning visibility into decisions.

The ecosystem was now understandable.

The next challenge was deciding how it should evolve.

Designing Service Stewardship

Service Playbook MVP: Centralize service enhancements, operational frictions, and future opportunities

Establishing the Service Playbook

Core Question

What structures allow a service ecosystem to continuously evolve?

Purpose

Centralize service enhancements, operational frictions, and future opportunities

Enabled

Centralized improvement portfolio

Structured enhancement management

Operational memory

Foundation for stewardship

As visibility increased across onboarding, operations, governance, and shared services, recurring opportunities for improvement continued to emerge.

Findings, recommendations, enhancement initiatives, and operational insights existed across workshops, blueprints, stakeholder discussions, Jira tickets, and operational reviews.

The ecosystem was visible.

The mechanisms required to continuously improve it were not.

The Service Playbook became the operational memory of the engagement.

It provided a mechanism for managing service evolution rather than simply documenting it.

Service Evolution Maturity Model: Define long-term maturity progression

Building a Service Maturity Model

Core Question

How do we know the service is becoming more mature?

Purpose

Define long-term maturity progression

Enabled

Shared understanding of maturity

Long-term planning framework

Improved prioritization

Visibility into future capabilities

As improvement opportunities accumulated, a recurring question emerged: How do we know whether the service itself is improving?

Initial

Ad hoc execution, siloed knowledge, reactive problem solving.

Defined

Lifecycle blueprints established, operational understanding documented.

Managed

Lifecycle, readiness, guidance, and governance integrated.

Optimized

Continuous measurement, automation, and contextual enablement.

Improvement required understanding not only where the service was today, but what capabilities needed to exist to support its future state.

Stage-Based Readiness Framework: Treat readiness as a lifecycle capability

Reframing Readiness as a Lifecycle Capability

Core Question

Can readiness itself be designed?

Purpose

Treat readiness as a lifecycle capability

Enabled

Lifecycle readiness planning

Improved customer preparedness

Earlier issue detection

Stronger onboarding outcomes

Many onboarding challenges resurfaced later during implementation, operations, and governance activities.

The issue was often not process execution.

It was customer preparedness.

Readiness evolved from:

Production Readiness Checklist ↓

Lifecycle Readiness ↓

Customer Prepardness ↓

Service Capability

Readiness was not a checkpoint.

It was a capability that developed throughout the customer lifecycle.

Process & Task Guidance Architecture: Align guidance to lifecycle, process, task, and operational context

Establishing the Foundation for Contextual Guidance

Core Question

How should knowledge support the work?

Purpose

Align guidance to lifecycle, process, task, and operational context

Enabled

Lifecycle-aligned knowledge architecture

Improved guidance discoverability

Better operational support

Foundation for contextual enablement

Feedback from Customer Support Services consistently revealed that existing guidance was difficult to navigate and disconnected from how work actually occurred.

The goal was not to improve documentation.

The goal was to deliver knowledge within the context of work.

The initiative focused on:

Lifecycle alignment

Process-level guidance

Task-level guidance

Operational context

Future CRM enablement

CRM Guidance Vision: Transform CRM into operational enablement platform

Enabling Contextual Guidance Through CRM

Core Question

What happens when guidance becomes contextual?

Purpose

Transform CRM into an operational enablement platform

Future Capabilities

Lifecycle-aware workflows

Contextual guidance delivery

Integrated knowledge repository

Process-based navigation

Operational decision support

As lifecycle models, readiness frameworks, guidance structures, and process definitions matured, a future opportunity became increasingly clear.

Future-state CRM experiences would connect:

Customer

Lifecycle Stage

Process

Task

Guidance

Readiness

Operational Context

Knowledge becomes significantly more valuable when delivered within the context of work.

Historical Service Repository: Preserve findings, decisions, enhancements, and evolution history

Building a Continuous Improvement System

Core Question

How does the service continue learning?

Purpose

Preserve findings, decisions, enhancements, and evolution history

Enabled

Structured governance

Historical traceability

Service evolution visibility

Continuous improvement capability

As service models matured, findings, decisions, enhancements, and future opportunities continued to accumulate.

Without operational memory, improvements become disconnected, priorities shift, and institutional knowledge fragments.

The organization needed a way to manage both present priorities and future evolution.

Service Stewardship Framework: Connect all stewardship capabilities into a single system

Preserving Service Intelligence

Core Question

What does stewardship actually require?

Purpose

Connect all stewardship capabilities into a single system

Enabled

Structured governance

Lifecycle readiness planning

Contextual guidance foundations

Historical service intelligence

Continuous improvement capability

The ecosystem was no longer lacking visibility.

It was lacking mechanisms for continuous evolution.

The organization now possessed:

Lifecycle visibility

Shared service visibility

Dependency visibility

Improvement pathways

Readiness frameworks

Guidance architecture

Historical service intelligence

Stewardship became more than a concept.

It became a connected operational system.

REFLECTION

Understanding a service was only the beginning.

Visibility made improvement possible.

Stewardship made improvement sustainable.

The challenge was designing the structures required to help the service continuously learn, improve, and evolve.

Readiness, guidance, governance, operational memory, and continuous improvement became components of a larger stewardship system.

The engagement where I learned how stewardship becomes an operational capability.

View All Case Studies