Exercise - Draft an adoption and change management plan

  • 40 minutes

In this exercise, you draft an adoption and change management plan for Zava's Power Platform estate. You use admin center analytics to identify adoption gaps, define a change operating model, and outline a community enablement strategy with measurable outcomes.

This exercise should take approximately 40 minutes to complete.

Prerequisites

To complete this exercise, you need:

  • Access to the Power Platform admin center with at least Environment Admin or Global Reader permissions
  • A text editor for creating your adoption plan deliverable (Word, OneNote, or a markdown editor)

Note

You create a single planning document as your deliverable for this exercise. Create a new file called adoption-plan.md (or equivalent in your preferred editor) and add each section as you work through the tasks.

Review current adoption signals

Before you can plan for adoption, you need to understand where the organization stands today. In this section, you review Power Platform admin center analytics to identify usage patterns, active makers, and gaps.

  1. Open the Power Platform admin center at https://admin.powerplatform.microsoft.com.
  2. Go to Analytics > Power Apps and review the Usage tab.
  3. Note the following metrics in your planning document under a heading Current Adoption Signals:
    • Total number of active apps in the last 30 days
    • Number of unique active users (players) in the last 30 days
    • Number of unique makers who published apps in the last 30 days
    • Any environments with zero or very low activity
  4. Select the Power Automate analytics view and record:
    • Total cloud flow runs in the last 30 days
    • Number of active flow makers
    • Error rate percentage for flows across environments
  5. Go to Environments and identify any environments that show no recent activity or have no apps deployed.
  6. In your planning document, write two or three sentences summarizing the adoption gaps you observe. For example: "Only 12 of 85 licensed users built apps, and the Production environment has three flows with error rates above 15%."

Tip

If you're working in a lab environment with limited analytics data, use realistic placeholder values. The goal is to practice the analysis pattern, not to have perfect data.

Define your change operating model

A change operating model clarifies who owns what in the platform governance structure. For Zava, you define three key roles: Platform Owner, Zone Owner, and Solution Owner.

  1. In your planning document, add a heading Change Operating Model.
  2. Create a table with the following columns: Role, Scope, Responsibilities, Decision Rights.
  3. Define the Platform Owner role:
    • Scope: Entire Power Platform tenant
    • Responsibilities: DLP policies, ACP policies, environment strategy, license allocation, compliance oversight
    • Decision rights: Can approve new environment creation, escalation point for cross-zone conflicts
  4. Define the Zone Owner role (one per business area):
    • Scope: A business domain (e.g., Finance, Operations, Customer Service)
    • Responsibilities: Environment hygiene within their zone, maker onboarding, local governance
    • Decision rights: Can approve solutions within their zone's environments, manages local DLP exceptions
  5. Define the Solution Owner role:
    • Scope: Individual app or flow (or group of related solutions)
    • Responsibilities: Solution lifecycle, testing, user support, documentation
    • Decision rights: Can promote solutions through rings within their zone's approval process
  6. Below the table, write a short paragraph explaining how these roles interact for Zava Pay specifically, noting that PCI-DSS compliance requirements mean the Platform Owner must co-approve any changes in the regulated environment.

Note

In a real organization, you would map these roles to specific people or teams. For this exercise, define the roles generically and note where Zava's finance team and IT governance board would fit.

Draft a release ring strategy

Release rings control how changes flow from development to production. They reduce risk by exposing changes to progressively larger audiences. In this section, you map rings to Zava's environment structure.

  1. In your planning document, add a heading Release Ring Strategy.

  2. Define the following rings and map each to an environment:

    Ring Environment Audience Duration Purpose
    Ring 0 Developer Solution Owner only 1–2 days Initial build and unit testing
    Ring 1 Test/UAT Zone Owner + selected testers 3–5 days Functional validation and feedback
    Ring 2 Pre-production Broader pilot group (10–15 users) 5–7 days Performance and integration testing
    Ring 3 Production All users Ongoing Full deployment

  3. Below the table, add ring-specific rules for Zava Pay (PCI-DSS regulated):

    • Ring 2 must include a security review sign-off before progressing to Ring 3
    • Ring 3 promotion requires Platform Owner approval in addition to Zone Owner
    • Rollback procedures must be documented before any Ring 3 promotion

  4. Add a short section on ring exceptions - define when it's acceptable to skip a ring (for example, critical security patches might skip Ring 2 with Platform Owner emergency approval).

Design adoption metrics and a value framework

Adoption metrics connect platform usage to business outcomes. In this section, you define KPIs that measure both technical health and business value.

  1. In your planning document, add a heading Adoption Metrics and Value Framework.

  2. Define leading indicators (predictive metrics) in a table:

    Metric Target Measurement Source
    New makers onboarded per month 5+ Admin center analytics
    Apps published per quarter 10+ Admin center analytics
    Maker-to-user ratio 1:8 or better License and usage data
    Training completion rate 80%+ Learning management system

  3. Define lagging indicators (outcome metrics):

    Metric Target Measurement Source
    Hours saved per quarter (automation) 200+ Flow run data × estimated manual time
    Manual processes digitized 3+ per quarter Solution inventory
    User satisfaction score 4.0/5.0+ Quarterly survey
    Compliance incidents 0 critical Security dashboard

  4. Write a short paragraph explaining how to calculate business value for Zava: connect flow run counts to estimated time savings, then multiply by average hourly cost. For example: "If a flow runs 500 times/month and saves 5 minutes per run, that's 2,500 minutes (41.6 hours) saved monthly."

  5. Add a note about how Zava Pay's compliance requirements mean that "incidents avoided" is also a key value metric - each avoided PCI-DSS violation has significant financial impact.

Tip

When presenting adoption metrics to leadership, lead with business value (hours saved, cost avoided) rather than technical metrics (flow runs, app sessions). Technical metrics matter for governance but don't resonate with executive sponsors.

Outline a 90-day community plan

A community enablement program builds sustainable adoption by creating peer support, recognition, and shared learning. In this section, outline a three-phase plan for Zava.

  1. In your planning document, add a heading 90-Day Community Enablement Plan.
  2. Define Phase 1: Foundation (Days 1–30):
    • Identify 3–5 champion candidates from active makers (use analytics data from the first task).
    • Create a Teams channel or community space for makers.
    • Host a kickoff session introducing the change operating model and release rings.
    • Publish a "Getting Started" guide with links to environment request process and DLP policies.
  3. Define Phase 2: Activation (Days 31–60):
    • Launch weekly "Office Hours" where champions provide drop-in help.
    • Run a first hackathon or app-in-a-day event focused on a real business problem.
    • Publish the first community newsletter highlighting successful solutions and makers.
    • Begin tracking community engagement metrics (attendance, questions asked, solutions shared).
  4. Define Phase 3: Scale (Days 61–90):
    • Introduce a recognition program (for example, "Maker of the Month" tied to business value delivered).
    • Expand champion network based on Phase 2 engagement data.
    • Present first quarterly adoption report to leadership using the value framework metrics.
    • Identify candidates for advanced training (pro-dev integration, AI Builder, Copilot Studio).
  5. For each phase, add a success gate - the criteria that must be met before moving to the next phase. For example: Phase 1 success gate = "Community space active with 20+ members, 3+ champions identified, kickoff session completed."

Success criteria

Review your completed planning document against the following checklist:

  • Adoption signals - Document includes a summary of current analytics with specific numbers and identified gaps
  • Change operating model - Three roles (Platform Owner, Zone Owner, Solution Owner) are defined with scope, responsibilities, and decision rights
  • Release ring strategy - Four rings are mapped to environments with durations, audiences, and Zava Pay-specific compliance rules
  • Adoption metrics - Both leading and lagging indicators are defined with targets and measurement sources
  • Value framework - Business value calculation method is documented with a concrete example
  • 90-day community plan - Three phases are defined with specific activities and success gates for each phase
  • Zava Pay considerations - PCI-DSS compliance implications are addressed in at least the operating model and release ring sections

Note

Your completed planning document should be approximately 2–3 pages. In a real engagement, this document serves as the foundation for an adoption proposal presented to leadership for approval and funding.