# Service Portfolio KPI Studio

Use this worksheet to help students design management-ready KPIs for a campus information system. The aim is to connect service performance with user value, operational evidence, governance accountability, and concrete improvement decisions.

## 1. Scenario brief

Choose one campus service:

- enrollment or registration
- learning management system
- finance or payment portal
- library access
- helpdesk support
- advising or consultation scheduling
- academic reporting dashboard

Describe the service in one sentence:

> This service helps ____________________ to ____________________ by ____________________.

## 2. Stakeholder map

| Stakeholder | What they need from the service | What poor performance costs them |
| --- | --- | --- |
| Primary users |  |  |
| Service owner |  |  |
| Support team |  |  |
| Leadership or governance body |  |  |

## 3. KPI design table

Design one KPI in each category. A KPI is acceptable only when the team can explain what decision should change when the metric changes.

| KPI category | KPI name | Evidence source | Review cadence | Owner | Decision trigger |
| --- | --- | --- | --- | --- | --- |
| User experience |  |  |  |  |  |
| Operational reliability |  |  |  |  |  |
| Governance or compliance |  |  |  |  |  |
| Adoption or learning support |  |  |  |  |  |

## 4. Quality test

For each KPI, answer these checks:

1. **Actionable:** What will the team do if this KPI gets worse?
2. **Evidence-based:** Where does the data come from, and who trusts it?
3. **User-connected:** Which user or stakeholder outcome does the KPI represent?
4. **Balanced:** Does the set avoid focusing only on uptime, tickets, or speed?
5. **Governable:** Who reviews the KPI and has authority to act?

If a KPI cannot pass at least four checks, redesign it.

## 5. Decision rules

Agree on simple thresholds before looking at performance data.

| Signal | Example threshold | Recommended action |
| --- | --- | --- |
| Stable and improving | Target met for three review periods | Continue and document the practice |
| Warning | Target missed once or user complaints increasing | Investigate root cause and assign owner |
| Critical | Target missed twice or compliance risk appears | Pause related changes and escalate |
| Learning gap | Users avoid the service or repeat the same mistake | Improve training, guidance, or interface copy |

## 6. Classroom debrief

Discuss these questions after teams present:

1. Which KPI looked impressive but did not support a clear decision?
2. Which evidence source would be hardest to collect reliably?
3. How did the team balance technical health with institutional value?
4. What would be different for a low-risk information page versus a workflow-critical service?
5. Which KPI could become part of a CI/CD or post-release verification process?

## 7. Extension activity

Ask teams to convert one KPI into a management artifact:

- a dashboard card with plain-language interpretation
- a post-release verification checklist
- a support-team escalation rule
- a monthly service portfolio review note
- a GitHub Actions check or deployment evidence requirement