When Performance Is Measured, Performance Improves

There’s a quote I keep coming back to:

“When we deal in generalities, we shall never succeed. When we deal in specifics, we shall rarely have a failure. When performance is measured, performance improves. When performance is measured and reported, the rate of performance accelerates.” — Thomas S. Monson

At face value, what CIO wouldn’t want to start measuring everything and reap those accelerating improvements? But before you roll out a dashboard for every team, there’s some honest groundwork to do.

First, Ask the Hard Questions

Measurement isn’t a technical problem. It’s a cultural one. Before you instrument anything, walk through these:

• Are the right people and the right things being measured?
• Are lines of accountability linked to specific individuals?
• Are the people responsible for the work comfortable being visible?
• Is your department still merit-based, or has that ship sailed?
• Does your reward model actually reinforce good performance?

There’s always psychology in play. You need a team willing to share ideas, surface mistakes, and treat being measured as a tool for growth rather than a threat. Skip this conversation and your KPIs become wallpaper.

KPIs Have Dependencies

Key Performance Indicators don’t exist in a vacuum. They need to ladder up to organizational goals that ladder up to something meaningful. Service to students, service to staff, service to the broader community.

A few honest checkpoints:

• Has anyone formally defined the KPIs as part of any project?
• Were they actually coded into the system?
• If they were, is the data being collected over time?
• Does that data feed into any analytics?
• Are the insights being used to evolve how the department operates?

It’s a long chain, and very few organizations complete it. So if you’re not there yet, you’re in good company.

The Reactive Trap

Most IT departments run on a reactive reward model. Something breaks, the SWAT team mobilizes, the outage gets resolved, everyone exhales until next time. The heroics get praised. The pattern repeats.

Measuring and reporting performance is what turns each of those incidents into a learning event instead of a war story. That’s where the real KPIs live, and that’s where the acceleration starts.

A Worked Example: Building a Student Registration System

Let’s make this concrete. Imagine you’re rolling out a new Student Registration system. Pick any upcoming project of your own and follow along.

Set the stage. Define the business need. Anchor the team to the underlying principle: measured performance improves, reported performance accelerates.

Let the team own it. Have them build their own project charter. Lay out the KPIs that fit the department. Architect those KPIs into the design from day one. Capture baseline metrics for the current process before anything changes. Identify who is accountable, who is responsible, and who owns long-term support, and put them on the team. This is how you build pride of ownership.

Fund it properly. No one wants to be on a dud project. Quality costs more up front and saves significantly downstream.

Then get out of the way. Apply your own checks on the team, advertise their progress, and let the work speak.

The KPIs Worth Tracking

For a Student Registration project, here’s a starting list:

1. Throughput — students registered over a given timespan
2. Incidents — categorized by type (failed registration, incorrect registration, etc.) with cost-per-ticket
3. System reliability — failures, time to recover, resources required, bug counts, MTBF
4. Cost to register — average time and resourcing per student
5. Change agility — ease of incorporating new scope, time to ship, downstream impact on APIs and data models

Designing the App to Capture the Data

Assume an Azure web service used by parents and staff, sitting on the existing application database. A few design decisions make measurement possible:

• Audit columns on every entity — who created, who updated, source system, timestamps, who logically deleted the record
• Entity metrics built in — transaction counts, MTBC (mean time between change), category, security level
• A transaction table — written every time a user submits a page, capturing timespan, start time, source, entity name and ID
• Aggressive error handling — every exception logged through Azure’s built-in logging
• A stable API schema — designed for backward compatibility so downstream apps don’t break on every change
• Ticketing system configured — clear escalation from Helpdesk to Student Records support to the dev team
• Project tracking — MS Project or equivalent for time, resources, and scope changes, reused for future enhancements

From Data to Insights

Once the KPIs are flowing into the right stores, the work shifts. Compare against baseline. Are improvements showing up? Report them to the team. Collect daily and weekly stats. Look at trends over time, find the friction points, ship a fix, watch the next data cycle to see if it worked.

Then report it again. Weekly IT newsletter. Weekly scrums. Cost-benefit reviews. Apply what you learned to the next project.

The Real Payoff

It’s not just about facts and numbers. It’s about building pride in the work, supporting the team, and developing real gratitude for jobs done well. People want to be on a progressing team. That motivation feeds back into the next cycle, and the next, and the next.

Try it on your next project. Celerity Insight can help you get the first loaf out of the oven.