Our story

Why we built Proxeum.

I spent more than a decade inside healthcare organizations watching capable people work extraordinarily hard, and watching the results vary anyway. Proxeum is what I built once I understood the difference was never talent. It was variability.

Dennis Rookwood, Founder of Proxeum
Dennis O. Rookwood, Jr., MBA, PMP Founder of Proxeum
CHAPTER 01

The variability

There had to be a better way.

In 2012 I was running a project management office, and I spent more of my week managing spreadsheets than managing execution.

That is not a complaint about spreadsheets. The tracker had simply become the job. I rebuilt it every Monday. By Thursday somebody would email me a version of it that no longer matched mine, and I would spend an evening reconciling two documents that were both, in their own way, correct.

If you have worked anywhere that runs on spreadsheets, you already know how the folder looked.

I did what most people do. I got better at the tracker. I color-coded it, locked cells, wrote instructions, and asked people, politely and then less politely, to use the version in the shared folder. It worked for about a month at a time.

Eventually I stopped trying to fix the file and started paying attention to why it kept happening. And what I found was not a spreadsheet problem at all.

A priority would be agreed in one forum, planned in another, tracked in a third, and reported in a fourth. Every handoff cost a little context. By the time work reached the people doing it, the original intent had thinned. By the time status reached leadership, it had been summarized into a confidence the underlying data did not support. That is how you end up with a status report that is green while the whole organization feels behind. Nobody is lying. The information simply degrades on its way up.

For a long time I assumed this was a discipline problem, and that better people or better meetings would fix it. They did not. I would arrive, install structure, and results would improve. I would leave, and within two quarters the organization drifted back. Nobody was failing. The organization simply had no shared way to execute.

Once I stopped looking for the person responsible and started looking at the spread of outcomes, the same picture appeared in every organization I walked into.

  • One leader consistently delivers.Another struggles.
  • One team finishes early.Another misses every date.
  • One initiative creates measurable value.Another quietly fades away.
  • One facility executes the plan.Another rewrites it.

Same organization. Same strategy. Often the same budget and the same calibre of people. What separates those columns is not effort and it is not talent. It is that execution happens differently for every leader, every department, every project, and every facility. That spread has a name in every other discipline that got serious about quality. It is variability, and variability can be engineered out of a system.

The difference is rarely talent. The difference is variability.

And variability can be engineered out of a system. That is the entire reason Proxeum exists.

DENNIS ROOKWOOD · FOUNDER
CHAPTER 02

The method

The first attempt was not software.

Before there was a platform, there was a method. It lived on flip charts, in templates, in a decision log, and in a weekly cadence that refused to move.

By 2013 I was consulting inside hospitals, and the room below is where a lot of it got worked out. No company. No product. No investors. A borrowed conference room, a folding table, and a sheet of paper with the whole engagement written on it in marker.

I built the method because I needed it. Every initiative started from the same charter. Every decision was written down with an owner and a date. Every week, the same review asked the same questions in the same order: what moved, what did not, what decision is waiting, and who owns the next step.

It worked. Initiatives that had been drifting for months started closing. Leaders stopped asking for updates because the updates were already there. The method was not clever. It was consistent, and consistency turned out to be the whole point.

Then I watched it fail for a reason I had not anticipated. It only worked where I was standing. The method lived on paper and in my head, so it travelled exactly as far as my attention did. Hand it to another leader and it degraded. Move to another facility and it had to be rebuilt from scratch. Change the person running it and it quietly stopped.

I had built a methodology. What these organizations needed was a system. A methodology depends on the person carrying it. A system holds without them.

Dennis Rookwood in 2013, seated beside a folding table in a hospital consulting room, gesturing toward a flip chart covered in handwritten notes
2013 · Hospital consulting engagement “One of the consulting workspaces where I first began developing the ideas that would eventually become Proxeum. While helping hospitals execute complex initiatives, I became convinced there had to be a better way than spreadsheets, disconnected meetings, and manual reporting.”
CHAPTER 03

The Four S’s

How you engineer variability out of execution

Variability is not removed by trying harder. It is removed by attacking the four places it enters. I got strict about these years before there was any software to apply them to, and they are still the test: not whether something is impressive, but whether it takes variation out of the system.

Speed

Reduces delays

Execution loses more time between a decision and the first action than it ever loses in the work itself. Every hour spent waiting for an owner, an approval, or a next step is variation nobody planned for.

Simplicity

Reduces friction

A system that needs a specialist to operate gets used differently by everyone else, or not at all. Friction is where people quietly invent their own way of working. If a screen needs explaining, it is not finished.

Standardization

Reduces variation

The same initiative should execute the same way at the third facility and the thirtieth. Standard structure is what makes outcomes comparable, and comparable outcomes are the only ones you can improve.

Stability

Creates predictability

Execution has to survive turnover, reorganization, and a bad quarter. A system that only works while its champion is in the room is not a system, and it will not produce the same result twice.

Speed reduces delays. Simplicity reduces friction. Standardization reduces variation. Stability turns the result into something you can count on. Together they produce predictable execution.

On standardization

Standard work is not bureaucracy. It is variation removed.

This is the one that gets misread. People hear standardization and think paperwork, approvals, and a process that slows good judgment down. That is not what it means here, and it is not what it does.

Unnecessary variation is expensive in a specific way. Different formats mean nobody can compare two initiatives. Different definitions of “on track” mean leadership is reading five different scales as though they were one. Different expectations mean two teams believe they agreed on something they did not. Different starting points mean every project pays again for a lesson the organization already learned.

Standardizing the structure is what frees people to use judgment on the work. The charter, the cadence, the way a decision is recorded, the way status is derived: those stay the same so that everything genuinely specific to the initiative gets the attention. Consistency is not the opposite of expertise. It is what makes expertise transferable.

CHAPTER 04

The idea that kept returning

A vision that never went away.

I did not set out to start a company. I set out to stop watching the same failure repeat.

The idea followed me for years. I would sketch it between engagements, put it down when the work got heavy, and pick it up again the next time an initiative stalled for a reason that was entirely preventable. A decision nobody recorded. An owner nobody named. A risk that was visible to three people and invisible to everyone who could have acted on it.

What kept the idea alive was the cost of not having it. Capital committed to initiatives that quietly stopped. Board questions that could not be answered with confidence. Good clinical and operational leaders spending their evenings assembling slides that would be out of date before the meeting started.

Every engagement added another line to the specification. Not features: structure. Governance had to come before execution. Decisions had to be objects, not minutes. Status had to be read from the work rather than reported about it. Visibility had to be observed, not requested.

By the time I was ready to build, I was not designing a product. I was writing down something I had already run, dozens of times, in real organizations, under real pressure.

CHAPTER 05

The timing

When technology finally caught up.

The reason Proxeum did not exist ten years ago is not that nobody wanted it. It is that building it correctly was out of reach.

Doing this properly has hard requirements. Permissions cannot be cosmetic; in healthcare, who can see what has to be enforced at the data layer, not in the interface. Portfolio views have to be generated from live work, not compiled overnight. Governance, projects, meetings, tasks, and reporting have to stay connected so context survives the handoffs where it is normally lost.

For most of my career, that combination meant an enterprise engineering organization and a multi-year implementation, which put it out of reach of exactly the community and rural hospitals that needed the structure most.

That changed. Modern data platforms made row-level security practical rather than theoretical. Live roll-ups stopped being an infrastructure project. Assistance could finally be constrained to what a specific person is permitted to see, which is the only responsible way to put intelligence near clinical and operational data.

So I built it. Not because software is a good business, but because it had finally become possible to build the thing correctly.

I never wanted to build software.

I wanted to solve execution. Software simply became the vehicle.

DENNIS ROOKWOOD · FOUNDER
CHAPTER 06

What we believe

Our philosophy

These are not marketing positions. They are the conclusions I reached the slow way, and every one of them is a different way of saying the same thing: reduce the variability and the results take care of themselves.

  1. The difference is rarely talent. It is variability.

    When outcomes vary across leaders, teams, and facilities, the instinct is to look for who is responsible. The more useful question is what differed in how the work was run. Variation is a property of the system, and systems can be changed.

  2. Strategy fails in the gap, not on the page.

    Almost no organization fails because the strategy was wrong. It fails in the distance between agreeing a priority and delivering it. That gap is the thing worth managing, and almost nothing manages it.

  3. Green status is not the same as real progress.

    Reporting confidence routinely exceeds execution reality. If status is self-assembled, it will drift toward optimism. Status should be a by-product of the work, not an opinion about it.

  4. Accountability requires structure, not reminders.

    Ownership, decision rights, and escalation paths belong in the design of the system. When accountability depends on someone remembering to chase it, you have not built accountability. You have built a habit.

  5. Execution should be an engineered capability, not a personality trait.

    Strong operators will always outperform. But an organization whose results depend on which individual is assigned has not built a capability. It has built a dependency, and dependencies are where variability lives.

  6. Visibility should be observed, not requested.

    Every hour a leader spends asking for an update is an hour nobody spends improving the outcome. Leadership should be able to look, at any moment, without anyone preparing anything.

  7. Work should be connected to the outcome it promised.

    An initiative that finishes on time and delivers nothing is not a success. Execution is only complete when the value it was approved for can be measured.

CHAPTER 07

The name

Why Proxeum?

The name comes from proximity. It was the one word that kept describing the problem I was trying to solve.

Distance is where variation gets in. Distance between the strategy and the people delivering it. Between a decision and the work it was supposed to change. Between what leadership believes is happening and what is actually happening. Every gap is a place where two teams can drift into two different versions of the same initiative, and nothing dramatic has to go wrong for that to happen.

Close the distance and the variation has nowhere to enter. That is the whole design. Everything in the platform exists to pull five things closer together.

  • Strategy
  • Alignment
  • Execution
  • Accountability
  • Results

We are not trying to build a better place to keep a task list.

Execution should be engineered, not inherited.

Not a personality trait. Not a dependency on heroic leaders or extraordinary project managers. Predictable, repeatable, measurable, and scalable.

PROXEUM · OUR VISION
CHAPTER 08

Where this goes

Our vision

Every generation of organizations inherits a capability the one before it had to improvise. We think execution is next.

Manufacturing worked this out a long time ago. It did not get better by asking people to care more. It got better by treating variation as the enemy, and by engineering it out of the process until the same input reliably produced the same output. Finance, quality, and safety each made the same journey: from something good leaders did instinctively to something an organization could teach, measure, audit, and rely on.

Execution has not made that transition. It is still treated as a personal skill, distributed unevenly, and rebuilt from nothing every time a leader changes. It is the last major function in most organizations that nobody has engineered.

That is the work. Predictable execution as an organizational capability rather than an individual talent, built into the organizations that carry the most consequence when it fails. A rural hospital that keeps its service line because the initiative actually landed. A health system that can answer a board question with evidence instead of an impression. A transformation leader who inherits a portfolio and finds it intact.

Predictable execution is not created by working harder. It is created by reducing variability. That is not a slogan. It is the only method anyone has ever found that works at scale.

We do not believe project management is the future. We believe execution management is. Because organizations do not succeed when projects are managed. They succeed when execution becomes predictable.

Our mission is to reduce the variability of execution.

One organization. One leader. One execution system at a time.

The founder

Dennis Rookwood

Portrait of Dennis Rookwood, Founder of Proxeum
FOUNDER OF PROXEUM

Dennis O. Rookwood, Jr., MBA, PMP, is the Founder of Proxeum. He has spent more than a decade in healthcare working on strategy execution and performance optimization alongside the people accountable for results: executives, transformation leaders, and the operators who carry initiatives day to day.

Most of that work has been done inside community and rural hospitals, standing next to executive teams on the initiatives that decide whether an organization holds its ground or loses it: strategy execution, financial improvement, operational transformation, governance, organizational performance, and performance optimization. These are organizations without a large PMO to absorb a bad quarter, which is a useful place to learn what execution actually requires.

That work produced the execution methodology Proxeum is built on. It began as a set of standards for how initiatives should be chartered, governed, and reviewed, and grew into a full operating discipline covering governance, portfolio management, accountability, and value realization. It was tested the only way methodology can be: in live organizations, under real constraints, with real consequences for getting it wrong.

He approaches organizations the way an engineer approaches a system. Where others see a motivation problem, he looks for the structural reason results vary: the decision nobody recorded, the owner nobody named, the handoff where intent quietly disappeared. Leadership, in that view, is less about exhortation and more about designing conditions in which good people can reliably finish what they start.

Proxeum is that way of thinking, made operational.

Healthcare Strategy Execution Performance Optimization Execution Methodology Leadership Systems Thinking
Dennis Rookwood Founder, Proxeum

A personal note

If you’re reading this, thank you.

Proxeum has never been about building another software company. It is the realization of an idea I have carried with me for more than a decade.

My hope is that one day organizations stop accepting chaotic execution as inevitable. If Proxeum helps make that future possible, then every late night, every prototype, every failed attempt, and every lesson learned along the way will have been worth it.

Dennis Rookwood Founder, Proxeum

Make execution predictable across your organization.

Less variation between leaders, teams, and facilities, and results you can repeat. Request access and we will walk you through the system, and through where execution is varying most in your organization.

Request access