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 O. Rookwood, Jr., MBA, PMPFounder 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.
Nobody was confused about which file was current. Everybody was just
working from a different one.
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.
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.
01
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.
02
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.
03
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.
04
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.
01
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.
02
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.
03
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.
04
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.
05
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.
06
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.
07
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
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.
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 RookwoodFounder, 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.