Achieve IT Excellence With Actionable Research-Backed Steps

By ITPI | October 8, 2026 |

Ask ten IT leaders what "excellence" means and you'll get ten different answers. One says it's uptime. Another says it's shipping features faster. Someone else points at their security posture, and the person in the corner mutters something about budget.

They're all partly right, which is the problem. When the definition floats, so does everything built on top of it.

Here's what I've noticed after years of watching organizations try to improve their IT operations: the ones that actually get better don't start with a tool, a framework, or a reorganization. They start with a question. What do the best-performing organizations do differently, and can we copy it?

That's not a rhetorical question. It has an answer, and the answer has been studied. Top performers don't differ from everyone else by magic, better luck, or a smarter CTO. They differ in specific, observable, repeatable practices — and once you know what those practices are, you can adopt them. You don't have to invent excellence from scratch. You can borrow it.

This post walks through what those research-backed steps look like in practice, where most improvement efforts go off the rails, and how to build a disciplined operating model that holds up under pressure. If you're mid-digital-transformation, prepping for a cloud migration, rebuilding your security program, or trying to figure out how to govern AI, the same principles apply. Let's get into it.

What IT Excellence Actually Looks Like in Practice

Forget the mission statement version. IT excellence, at the operational level, shows up in a handful of measurable ways:

Change success rates. When you push a change into production, how often does it work the first time? Top performers sit north of 95% in most studies. The average organization is closer to 80–85%, which sounds fine until you multiply it across thousands of changes a year.
Mean time to restore. When something breaks — and something always breaks — how long until service comes back? The difference between a 30-minute restore and a 4-hour restore is often not technology. It's whether the team knew what changed, who's on point, and whether anyone documented the fix last time.
Deployment frequency and lead time. How long from "code committed" to "running in production"? This one exposes handoffs, approvals, and manual steps more than it exposes engineering skill.
Security exposure window. How long does a known vulnerability sit unpatched in your environment? How long would it take to detect a compromised credential?
Cost per unit of service. What does it cost you per transaction, per user, per workload? If you can't answer that, you can't defend your budget either.

Notice none of these are "do we have Kubernetes" or "did we buy the right SIEM." Tools matter, but they sit downstream of practice. A great team with mediocre tools will usually beat a mediocre team with great tools, because the team knows what to do when the tools fail. And they will fail.

There's a temptation to treat excellence as a destination — a state you reach and then coast in. It doesn't work like that. The organizations that stay good are the ones that built a system for getting better, not a collection of achievements.

Why Most IT Improvement Efforts Stall Out

I've seen this movie many times. Leadership reads a book, goes to a conference, or gets sold on a new platform. There's an initiative. There's a kickoff. There are slides. Six months later, nothing measurable has changed, and everyone quietly moves on to the next thing.

Why does this keep happening? A few patterns repeat.

The tool-first mistake. Buying a tool feels like progress because it's a decision you can make and a purchase order you can point to. Changing how a team triages incidents does not feel like progress. It feels like friction. So the tool gets bought and the practice stays the same, and the tool gets blamed when results don't materialize.

The Big Bang problem. Organizations love a sweeping, all-at-once transformation. Rewrite everything, migrate everything, retrain everyone. These programs have terrible odds. There's no feedback loop. If something's wrong, you don't find out until you've already spent the money and the political capital.

No baseline. You cannot improve what you have never measured. Plenty of teams can't tell you their change success rate, their average restore time, or how many of last quarter's incidents were self-inflicted. Without numbers, "we're doing better" is a vibe, not a fact. And vibes don't survive budget season.

Fixing symptoms instead of causes. The server went down, so we restart the server. Problem solved — until it goes down next Tuesday. Root cause analysis is uncomfortable because it often points at process design, understaffing, or a decision someone made two years ago. It's much easier to restart the server.

No shared language. Development says "we shipped." Operations says "you broke prod." Security says "you bypassed the review." Everyone is describing the same event from a different chair. Without a shared vocabulary and a shared pipeline, every incident becomes a negotiation.

Culture gets ignored. Here's the thing nobody wants to hear: most process improvements fail because of culture, not capability. If people are punished for surfacing problems, they stop surfacing problems. If a change freeze is how leadership handles risk, teams will batch up enormous, riskier changes to avoid the freeze. The process adapts to the culture, every time.

The good news: all of these are addressable. The bad news: none of them are addressed by buying something.

The Research-Backed Approach: Study Top Performers, Not Averages

Most industry research works like this: survey a thousand organizations, average the responses, publish the average. That's useful for describing what's normal. It's almost useless for telling you what to do, because "normal" includes a lot of organizations that aren't very good at this.

The better approach — and the one the IT Process Institute has used since 2004 — is to identify the organizations that measurably outperform their peers, then study what they do differently. You're not averaging. You're contrasting the top decile against the rest and asking, "what's actually distinct here?"

The difference in output is significant. Averaged research tells you that 60% of companies use a change advisory board. Contrast research tells you that the top performers stopped doing change approval boards the way everyone else does them, moved approvals earlier in the pipeline, and cut their change-related failures anyway. Which of those two findings would you rather act on?

This is why prescriptive beats descriptive. Knowing "top performers have strong leadership support" is a fortune cookie. Knowing "top performers assign a single accountable owner per service, publish a change calendar, and hold a weekly 20-minute review of failed changes" is something you can do Monday morning.

There's a second reason contrast research matters: it protects you from cargo cults. Someone hears that Google does something, tries to copy it, and gets burned because Google has 100,000 employees and you have 40. Contrast research filters for practices that hold up across organization sizes and industries, not just practices that look impressive on a slide.

A quick example: the change failure paradox

Consider two hypothetical organizations.

Company A reviews every change in a weekly committee. Forty people in a room, two hours, for 200 changes a week. Average time spent per change: 24 seconds. Most approvals are rubber stamps, but the process feels rigorous and it's been in place for a decade.

Company B pushes standard, pre-approved changes straight through an automated pipeline. Only genuinely novel or high-risk changes get human review. The review is done by two senior engineers with the full context of the change, not forty people guessing.

Company B ships more, ships faster, and breaks less. Why? Because Company A's committee isn't actually evaluating risk — it's performing it. The people in the room lack the context to judge a specific database migration, so they default to yes, and the real risk lives in whatever nobody bothered to look at.

That's not a hypothetical, either. It's one of the most consistent findings in the IT operations research literature. Standardization plus peer review beats central approval. The trick is having enough categorization and standardization that you can route changes correctly.

Start With What You Can See: The Visible Ops Foundation

The phrase "visible ops" is the whole idea in two words. If you can't see what's happening in your environment, you can't control it, and if you can't control it, you can't improve it. The IT Process Institute's Visible Ops book series — which has sold more than 400,000 copies across its editions — built its methodology on that premise, derived from studying high-performing IT organizations and writing down what they had in common.

The core insight is that there's an order to this work, and most teams get the order wrong. They try to automate before they've stabilized. They try to optimize before they've standardized. The result is a fast, well-engineered mess.

The sequence that top performers tend to follow looks roughly like this:

Stabilize. Stop the bleeding. Get changes under control, get your configuration items documented, get a working change pipeline in place.
Standardize. Turn recurring work into defined, repeatable procedures. Kill the one-off scripts that only one person understands.
Measure. Now that things are stable and standard, you can measure them meaningfully. Baseline your key metrics.
Optimize. Improve the bottlenecks the data points at, one at a time.
Automate. Automate the things you've already made consistent and measured. Automation applied to chaos just produces chaos faster.

If you skip straight to step five — and almost everyone wants to — you automate the wrong things, in inconsistent ways, and then you have to untangle it later.

The two things to get right first

If you're starting from scratch, there are two disciplines that carry the most weight early on:

Change management with a real pipeline. Every change to production goes through one path, visible to everyone. Not a form. A pipeline with stages, owners, and a record. Small changes get light treatment, big ones get more. The point is that nothing is invisible.

Configuration management that reflects reality. You need an accurate picture of what's running where, connected to what, owned by whom. Most organizations think they have this. Most organizations are wrong. The discovery process usually surfaces a lot of surprises — services nobody knew were still running, owners who left two years ago, dependencies that only exist in someone's head.

Neither of these is glamorous. Both of them are load-bearing. Everything else you want to do — cloud migration, DevOps adoption, security hardening, AI governance — sits on top of them.

Actionable Steps You Can Take This Quarter

Enough theory. Here's what a practical, research-backed improvement cycle looks like when you break it down.

Step 1: Pick one service and make it fully visible

Pick a service that matters but isn't your most fragile thing. Map it end to end: what it depends on, who owns it, what changes touch it, where the data flows. Write it down somewhere shared.

Then track every change to that service for thirty days. Not to approve them — just to see them. Count how many there are, how many succeeded, how many caused incidents.

You'll learn two things: how much change volume you actually have, and how much of it is invisible to management. The second number is usually the bigger surprise.

Step 2: Build a change classification scheme

Sort changes into three buckets:

Standard: pre-approved, low risk, done the same way every time. Password resets, standard config pushes, routine deploys. These should flow without human approval.
Normal: planned changes that need review because they're not routine. New service deployments, schema changes, firewall rule additions.
Emergency: fixes to active incidents. These get reviewed after the fact, not before, and the review has a short deadline.

The classification is the hard part, not the process. Spend real time on it. If half your changes land in "normal" because nothing about your environment is routine, that's a signal. Not a failure — a signal. It tells you where standardization would pay off most.

Step 3: Instrument four metrics and nothing else

Start with four. Resist the urge to build a 40-metric dashboard nobody reads.

| Metric | What it tells you | Reasonable early target |

|---|---|---|

| Change success rate | How often changes work the first time | > 90%, climbing |

| Mean time to restore (MTTR) | How fast you recover when things break | Down 20% quarter over quarter |

| Change lead time | How long from request to production | Down 25%, or under 10 days |

| Repeat incident rate | How often the same failure repeats | < 10% of incidents |

Targets are directional, not universal. A hospital IT team and a SaaS company will have different numbers that count as good. The trend matters more than the absolute value at this stage.

Step 4: Run a post-incident review that people don't dread

The two failure modes here are blaming someone and writing a report nobody reads. Both kill the process.

A review that works has a few properties. It happens within a few days of the incident. It's led by someone with no stake in the outcome. It asks what happened and why the system allowed it, not who typed the wrong command. It produces a small number of concrete follow-ups with owners and dates. And here's the critical one: it gets published where everyone can see it, including the parts that make leadership look bad.

If your reviews consistently find that the cause was "human error," your reviews aren't working. Human error is what happens when a system makes it easy to err. Keep asking why.

Step 5: Fix the culture, or the process won't stick

Process changes survive about six weeks in a culture that doesn't support them. Some things that make the difference:

Leaders go first. If the VP of Engineering bypasses the change pipeline "just this once," everyone learns the pipeline is optional.
Surface problems safely. If someone flags a risk and gets punished for slowing things down, nobody flags risks again.
Make the right thing the easy thing. If following the process takes 20 minutes and bypassing it takes 2, people will bypass it. Close that gap.
Celebrate the boring wins. The change that didn't break anything is a success even though it's not a story. Say so out loud.

I know "culture" sounds like the soft stuff you talk about after the real work is done. In practice it's the opposite. It's the thing that decides whether the real work survives contact with reality.

Bringing the Same Discipline to Cybersecurity

Security is where undisciplined operations get expensive fast. And it's a domain where the visible-ops mindset translates almost directly, which is why the IT Process Institute extended the methodology into Visible Ops Security and Visible Ops Cybersecurity.

The core problem in security is that everybody's trying to do everything at once. Patching, endpoint, identity, network, training, compliance, incident response — all at maximum priority, all the time. When everything is priority one, nothing is.

Top-performing security organizations do something different. They sequence.

First, know what you have. You can't protect assets you haven't inventoried. This is the same configuration management problem from earlier, wearing a different hat. Most breach post-mortems trace back to something nobody knew existed.

Second, control who can get in. Identity and access management is where a disproportionate amount of security value lives. Strong authentication, least privilege, regular access reviews. Boring, high leverage.

Third, get patching to a rhythm. Not perfect, not instant, but a predictable cadence with defined windows for different severity classes. An organization that patches reliably every 14 days beats an organization that patches sporadically at 3 days and 90 days depending on who's on vacation.

Fourth, make detection real. Alert fatigue is the norm in most SOCs, which means the alerts everyone ignores are the ones that matter. Tune aggressively. Better 50 meaningful alerts than 5,000 shrugged-at ones.

Fifth, train people in a way that changes behavior. Annual click-through-the-slides training doesn't change much. Short, frequent, targeted simulations with immediate feedback do.

Notice what's absent from that list: buying more tools. Most security budgets are already tool-heavy. The gap is usually in the sequencing, the ownership, and the culture — which is, again, exactly where research-backed methods focus.

Cloud and Private Cloud: Choosing What Actually Fits

Cloud migration is one of those projects that's easy to start and hard to finish. Plenty of organizations end up hybrid by accident rather than design: some workloads moved, some didn't, nobody quite remembers why, and the cost model is now impossible to explain to finance.

Visible Ops Private Cloud, another title in the ITPI series, speaks to this. The research finding underneath it is straightforward: successful cloud adopters don't approach migration as a technology problem. They approach it as a portfolio problem. Each workload gets evaluated on its own merits.

A workable evaluation framework asks:

Is this workload stable and well-understood? If not, migrate it later. Moving a system you don't understand just relocates the chaos.
Does it benefit from elastic scale? If demand is flat and predictable, cloud's main advantage evaporates and its cost model works against you.
What are the compliance constraints? Data residency, industry regulation, and contractual obligations can rule out public cloud for certain workloads entirely.
What's the real total cost over three years? Include egress, storage tiers, licensing, engineering time, and the cost of the migration itself. The first-year number usually looks great. Year three is where surprises live.
Who owns it after the move? Migration without an ownership transition plan produces orphaned workloads running on someone else's credit card.

The organizations that get cloud right tend to be the same ones that got virtualization right a decade earlier: they standardize first, then migrate in waves, then measure against a baseline. Same discipline, different technology.

AI Governance: The Newest Test of Discipline

AI is where the pattern repeats. New technology arrives, everybody wants to move fast, and the organizations that move fast and stay out of trouble turn out to be the ones with existing operational discipline — not the ones who invented a brand-new process from scratch.

The IT Process Institute's recent VisibleOps A.I. book, which debuted at #25 on Amazon's Top 100 New Releases in Computers & Technology, extends the same research methodology to AI adoption and governance. The logic is consistent with everything above: identify what high performers do, write it down in steps, and make it implementable.

What does AI governance look like in practice, at the level of concrete steps?

Inventory your AI use. Every AI system and tool in the organization, including the ones people are using quietly. Shadow AI is the configuration management problem all over again.
Classify by risk. A text summarizer that drafts internal memos is not the same risk class as a model making credit decisions. Treat them differently.
Define accountability per model. One named owner. Not a committee. A person.
Set data boundaries. What data can and can't be used for training, prompts, or fine-tuning. Written down, enforced technically where possible.
Plan for failure. What happens when the model is wrong, drifts, or gets manipulated? Who gets notified? What's the rollback?
Review on a cadence. Quarterly is reasonable to start. AI systems change fast enough that a one-time review is close to worthless.

None of this is exotic. It's the same governance pattern that worked for change management, for security, and for cloud. That's not a coincidence — it's the point of building methodology from research rather than from the hype cycle of the moment.

Common Mistakes That Undermine IT Excellence

A short catalog of ways this goes wrong, because knowing the failure modes is half the work.

Measuring too many things. Dashboards with 60 metrics get ignored. Four well-chosen metrics change behavior.

Treating the framework as the goal. You don't need to be ceremonially compliant with a framework. You need your change success rate to go up.

Skipping the baseline. If you don't measure before you change things, you can't prove anything improved. This is how improvement programs get cancelled.

Delegating without authority. Handing someone the responsibility for improvement without the ability to change processes is setting them up to fail.

Automating broken processes. Faster broken is still broken.

Making exceptions for senior people. The moment the process doesn't apply to leadership, it stops applying to anyone.

Ignoring the second-order effects. A change freeze reduces change risk on paper and increases batch size in practice, which increases risk. Think one step ahead.

Starting too big. A 3-year transformation plan has a lot of failure points. A 90-day improvement on one service has two.

Forgetting to celebrate. Improvement work is mostly invisible until it isn't. Without recognition, people drift back to the old ways.

Assuming tooling will fix culture. It won't. Ever. Not once.

Putting It Together: A 90-Day Starter Plan

If you're wondering where to begin, here's a sequence that fits in a quarter and produces something measurable. It's built on the same order of operations the research points to: stabilize, standardize, measure, then optimize.

Weeks 1–2: Baseline.

Pick one service.
Map dependencies, owners, and change paths.
Pull whatever metrics you can. Even rough numbers beat no numbers.

Weeks 3–5: Build the pipeline.

Stand up a single, visible change record for the chosen service. Even a shared spreadsheet beats nothing.
Classify standard, normal, and emergency changes.
Route standard changes through pre-approval.

Weeks 6–8: Start measuring.

Track the four metrics. Publish weekly, briefly.
Run post-incident reviews for anything that hits the service.
Assign owners to every follow-up action.

Weeks 9–11: Standardize the top offenders.

Identify the highest-volume, least-standardized recurring tasks.
Turn the top three into documented procedures.
Remove one approval step that isn't adding risk reduction.

Week 12: Review and extend.

Compare metrics against the week-1 baseline. Write down what actually changed.
Pick the next service.
Decide what to automate, now that it's stable and measured.

That's a quarter. It doesn't require a purchase order. It does require someone with authority to say "this is how we're doing it now" and the patience to keep saying it for twelve weeks.

Where IT Process Institute Fits In

Everything above is a lot easier if you're not inventing it from scratch. That's what the IT Process Institute does: independent research on top-performing IT organizations, published as practical, step-by-step guidance rather than abstract frameworks.

A few things worth knowing if you decide to go deeper:

The Visible Ops series. Five books — the original handbook, Security, Private Cloud, Cybersecurity, and VisibleOps A.I. — each built on the same contrast-research methodology. The original alone has moved over 400,000 copies, which suggests something in it resonates with people doing the work.
Research studies and benchmarking reports. If you want to know how your metrics compare to top performers in your sector, this is where you find out. Healthcare IT, enterprise, cloud providers, and other verticals get specific treatment.
Executive snapshots and eBooks. Short, focused white papers for leaders who need the summary before the detail.
Training webinars. Useful when you need to get a team aligned on a method, not just an individual.
The ITPI Store. Direct access to the publications and research materials.

The cost model matters too. ITPI runs a shared research model, which means you're not paying enterprise analyst-firm prices for the same category of insight. For organizations that want evidence-based guidance without a seven-figure research subscription, that's a real difference.

Where it's most useful, in my experience: when you're starting from zero and don't want to guess, when you need to convince a skeptical executive with data rather than opinion, or when you've already tried the tool-first approach and want to understand why it didn't stick.

Frequently Asked Questions

How long before we see measurable improvement?

Most organizations can show movement on a single service within a quarter — change success rate up, MTTR down. Organization-wide change takes longer, usually 12–18 months, because the constraint shifts from process to culture and culture moves slowly. Be suspicious of anyone promising transformation in 30 days.

Do we need to buy new tools to do this?

Usually not at first. Start with what you have and see how far visibility alone gets you. Tools come in when you've identified a specific bottleneck that no amount of process change will clear. Buying first is how budgets get wasted.

Isn't a change review board supposed to reduce risk?

It can, if it's reviewing the right changes with the right people. The problem is most boards review everything with everyone, which means each change gets seconds of attention from people who lack context. Move standard changes to pre-approval and let the board focus on genuinely novel or high-risk work.

Our environment is too complex to standardize. What then?

Complexity is usually a symptom, not a cause. Start with one service. You'll likely find that what looks like complexity is really inconsistency — the same task done six different ways by six teams. Standardizing one recurring task is a foothold. Take it.

How does this work in a regulated industry?

Well, actually. Much of what we're describing here — documented changes, audit trails, defined approval paths, evidence of testing — is what regulators ask for anyway. Organizations that build good operational discipline often find compliance evidence falls out of the process instead of being a separate scramble.

What about DevOps? Doesn't this contradict it?

Not at all. DevOps is about removing handoffs between development and operations, and it works best when the underlying processes are stable and visible. The research findings on change management and DevOps align more than they conflict. Continuous delivery with weak change discipline just means you break production faster.

Where should we start if we're a small team?

Same place as everyone else, at a smaller scale. One service. Four metrics. A visible change pipeline. You'll hit the same lessons with fewer people and less politics, which honestly makes them easier to learn.

How do we get leadership buy-in?

Bring numbers, not frameworks. "Our change success rate is 78%, top performers are above 95%, and here's the three-step plan to close the gap" lands better than a slide about maturity models. Executives respond to evidence. That's the whole reason ITPI's research methodology is built on contrast rather than theory.

Next Steps

If you take nothing else from this, take the sequence: stabilize, standardize, measure, optimize, automate. In that order. Most of the pain in IT improvement programs comes from running those steps out of order, and most of the wins come from running them in order with enough patience to see it through.

Start small this week. Pick one service. Write down everything that touches it. Count how many changes hit it in the next thirty days. You'll have your baseline before the month ends, and you'll have a much clearer picture of what to fix first.

If you want the research-backed version of what to do next — the same methodology that's been distilled across the Visible Ops series and validated across thousands of organizations — the IT Process Institute publishes exactly that. Browse the research studies, pick up the handbook for your domain, or start with a benchmarking report to see how your numbers stack up. It beats guessing, and it beats reinventing a discipline that already has a documented answer.

Posted in Uncategorized