What I Offer

Four ways to work together.

Each engagement is scoped before it starts. No open-ended retainers, no scope creep.

How I Work: The Operator's Model

Not "Discover → Design → Deliver." I stay through measurement. You see results before I leave.

1

Diagnostic

2–4 weeks

I read your current-state process maps, not just interview stakeholders.

I identify the gap between what the system says and what crews actually do.

Deliverable

Friction inventory with quantified impact per bottleneck

2

Design + Prove

4–8 weeks

I build the to-be process with your operators, not for them.

Every step has an owner, a metric, and a fallback.

Deliverable

Verified process design with adoption baseline

3

Embed + Measure

Ongoing

I stay until 90-day adoption metrics are logged.

I don't leave when go-live happens. I leave when numbers move.

Deliverable

Monthly performance scorecard for 6 months post-launch

Engagement Models

Three ways to structure an engagement.

Pick what fits the problem. Mix them when needed.

By The Numbers

The record, grouped by outcome type.

What Operators Say

The feedback that matters.

Downloads

Practical tools. Free.

Templates and frameworks from actual engagements.

My Approach

Four steps. Always in this order.

Each step builds on the previous one. Skip any of them and the outcome doesn't hold.

The go-live celebration ends on a Friday. By the following Wednesday, the first escalation lands in someone's inbox. Nobody is sure whose problem it is. So it goes up.

That escalation pattern — the one where routine operational issues reach directors and VPs because nobody below them has clear authority — is not a people problem. It's a design problem. And it's almost never addressed in the cutover plan.

What "process ownership" actually means in practice

Most organizations assign process owners during implementation. They appear in RACI charts. They sign off on documentation. They attend the go-live readiness review.

Then the system goes live, the consultants roll off, and something quietly breaks: the process owner has a title but no operating authority. They can't change system configuration. They can't resolve exceptions without escalating. They have no metric tied to their name. And nobody calls them when something goes wrong — because nobody knows who that is.

This isn't a failure of intent. It's a failure of design. Real ownership requires three things, and most post-ERP environments deliver one.

How to find the gap in 30 days

Pull the last 60 days of escalations. For each one, ask: at what level was this resolved, and at what level should it have been resolved? The gap between those two answers is your ownership gap.

In most post-ERP environments, 40–60% of director-level escalations are decisions that should have been made two levels down. The director isn't wrong to resolve them — they have to. But every one of those escalations is a signal that ownership is missing somewhere.

Once you have the escalation map, match each gap to a process. Then ask three questions about each process:

• 1.Who has the authority to close an exception in this process without escalating?
• 2.What metric tells us whether this process is performing?
• 3.Who reviews that metric, and how often?

If the answers are "unclear," "nothing formal," and "nobody regularly" — you've found the gap. Name it. Assign it. Build the forum. That's the work.

What this costs when you don't fix it

Exception queues grow. Your best operational leaders spend time resolving things that should never reach their desk. Key-person dependency builds quietly — one person carries institutional knowledge that isn't documented anywhere. Then they leave, or get promoted, and performance doesn't erode gradually. It stops.

The 18-month post-ERP performance plateau isn't inevitable. It's what happens when the governance layer doesn't get built. The platform works. The processes are documented. But nobody actually owns them.

Your executive team reviews average cycle time every month. It's green. Has been for three months. Then an auditor, or a customer, or a regulator surfaces a category of transactions that's been sitting at 45 days. The average was hiding it.

This is the most common performance reporting problem I see in utility operations. The metric isn't wrong — average cycle time is a real number. But it's answering a question nobody should be asking. The question isn't "how long does it take on average?" The question is "where are things breaking, and why?"

The problem with averages

When you average cycle time across all transaction types, a high-volume clean category masks the performance of a low-volume exception category. Your 3-day average looks fine. Your 45-day exception queue is invisible.

In billing operations specifically: a utility billing 800,000 accounts per month might have 96% of bills processing in 2–3 days. The remaining 4% — exceptions from field reads, premise disputes, returned mail — can sit for weeks. The average looks fine. The 4% creates the complaint calls, the regulatory exposure, and the revenue delay.

The split that changes the conversation

Segment your cycle time into at least three buckets: clean-path transactions, exception transactions, and aged exceptions (anything over a defined threshold — 15 days, 30 days, whatever your SLA requires).

Report all three. Trend all three. Assign owners to each bucket.

Now your executive conversation changes. Instead of "cycle time is 4.2 days," it becomes: "Clean-path is 2.1 days — stable. Exception cycle time is 28 days — up from 22 last month. Here's the category driving it and here's the root cause."

That second conversation is one your executives can act on. The first one just generates a nod and moves the agenda forward.

How to build this without a new system

You don't need new software. You need a transaction code that distinguishes exception status, and a weekly pull that segments by that field. In SAP environments, this exists — it's usually already there. What's missing is the habit of reporting it segmented.

Start with one process. Pick the one with the most escalations last quarter. Add the segmentation. Run it for two reporting cycles. The story it tells will be more useful than anything the average has been telling you.

The automation vendor presents a compelling demo. The bot runs the process in 90 seconds. Leadership approves the project. Six months later, the automation is processing exceptions faster than humans ever did — which means the downstream queue is now growing three times as fast.

This is what automating a broken process looks like. The technical execution was fine. The process wasn't ready.

Why automation projects fail before they start

Industry estimates put automation failure rates at 50–70% for initiatives that don't deliver ROI in year one. The failure pattern is consistent: the process being automated was not stable, not documented to the actual current-state, or not owned by anyone accountable for the outcome.

Automating an unstable process doesn't fix it. It locks it in. Whatever workarounds, exceptions, and undocumented steps exist in the manual process get encoded into the automation — and they run at machine speed.

The three-step intake below isn't a gate to slow things down. It's the work that makes automation actually land.

The 3-step intake

If you have three YES answers, scope it. Build the automation with a rollback plan and monitoring layer. Go live.

If you have two or fewer YES answers — stop. The 60–90 days you spend stabilizing and measuring will save six months of remediation on the back end. In any regulated or customer-facing environment, remediation after a bad automation rollout costs significantly more than getting the process right first.

The training is done. Every user completed the modules. Attendance was 94%. The go-live readiness checklist says green.

Sixty days later, half the team is still running manual workarounds alongside the new system. The help desk queue has tripled. And the operations manager is spending three hours a day answering questions the training was supposed to cover.

This is not a training failure. The training did exactly what training does — it told people what changed. The problem is that knowing what changed is not the same as changing how you work.

The gap between awareness and behavior

Training creates awareness. Adoption is a change in behavior that holds under pressure — when the system is slow, when volume spikes, when the supervisor isn't watching. That's a different problem. It requires a different approach.

In utility operations specifically, the pressure points are predictable: billing cycles, outage response, seasonal volume peaks, regulatory reporting windows. Adoption fails when people revert to what's comfortable under those conditions. And they will revert — unless the new way is visibly easier and has visible consequences for not using it.

The supervisor question

Before any go-live, ask this: does every frontline supervisor know what "correct" looks like in the new process, and do they have a way to see when their team isn't doing it?

If the answer is no — the training is complete but the adoption system isn't built yet. That's the work that determines whether the investment in the new system actually holds.

Adoption isn't a program you run once. It's the operational infrastructure that keeps performance from sliding back. It needs to be designed, owned, and measured — the same as any other process.

Month 6 after go-live: the system is stable, the project team is celebrating, and the final engagement report is getting polished. Metrics look solid. The consultants roll off.

Month 12: Exception queues are 20% higher than they were at go-live. The dashboards that the project built are no longer being updated. The process documentation is already out of date because three workarounds have crept back in. The senior manager who owned the new process has moved to a different initiative.

Month 18: Leadership is discussing whether to bring the consultants back.

I've watched this pattern play out across multiple utility implementations. It's not inevitable. But it will happen if you don't design against it specifically.

Why it happens

Three things go wrong simultaneously in the 6–12 months after a major implementation:

How to design against it

This is post-ERP stabilization work, and it needs to start during the implementation — not after. Specifically:

Build the governance layer before you need it. Before the consulting team rolls off, define the internal cadence that replaces their operating rhythm. Who owns each process, what metric they own, what forum they report into, and what their escalation path is. Document it. Activate it 60 days before project close — not on the day the consultants leave.

Assume the key people will move. Document ownership with enough detail that a new person can step into it in 30 days. If the only person who can run a process is the person who was on the implementation team, you have key-person dependency — not a sustainable operation.

Keep the metrics running. The reporting you built for the project needs to survive the project. Assign it to someone internal. Simplify it if needed — but keep it. The moment you stop measuring, you stop knowing. And in regulated utilities, what you don't know finds you eventually.

The team has the data. The dashboards are built. The weekly meeting is on the calendar. And yet the same issues show up every week, decisions get deferred, and the most capable people in the room spend the first 20 minutes figuring out what they're actually there to decide.

The meeting isn't the problem. The absence of a decision system is.

Cadence vs. calendar

Most organizations have calendars. They have recurring meetings, standing calls, monthly reviews. What they don't have is a system that connects the meeting to the decision to the action to the result — at every level of the organization, in the right cadence for that level.

A real cadence has four layers, each operating at a different frequency and serving a different decision type:

The design questions that matter

Before you schedule anything, answer these four questions for each level of the cadence:

• 1.What decision does this meeting exist to make? Not discuss — decide. If the answer is "review," it's a report-out, not a decision forum. Those are different things and shouldn't take the same amount of time.
• 2.Who has the authority to close a decision in the room? If the answer is someone who isn't present, the meeting can't resolve anything. Decisions deferred are decisions compounded.
• 3.What data arrives before the meeting? If people are building their view of performance during the meeting, half the time is gone before the conversation starts.
• 4.What happens to the decisions after the meeting? Actions need an owner and a deadline visible to the group. If the output is meeting notes that nobody reads, the cadence isn't working as infrastructure.

A cadence designed around these questions runs differently from one that got scheduled because "we should probably have a weekly." It takes the same amount of time on the calendar. It produces a different outcome in the business.

Leader routines are infrastructure. They hold performance between the big initiatives, through the transitions, and after the consultants leave. Design them with the same rigor you'd design any other system your operation depends on.

Every SAP go-live I've worked in had a RACI. None of them survived contact with month two.

The accountability gap isn't in the cutover plan — it's in what happens to decisions after the system goes live. Exception queues grow. Escalations pile up at the VP level. The people listed as process owners are doing their old jobs plus the new system plus the escalations nobody else wants to touch. The RACI said they owned it. Nobody defined what owning actually means in the new environment.

Here's what I consistently find: the problem isn't that people don't care. It's that no one has told them what a decision looks like in the new process, what they're authorized to close without escalating, or when to escalate versus absorb. So they default to the safest path — surface everything upward and wait.

Three moves that work in 30 days

1. Map every exception to a named owner — not a team, a person. If an invoice dispute sits in a queue, one person's name should appear next to it. Not "AP Team." Not "Billing Operations." One person who knows they own it and has the standing to close it.

2. Run a one-hour authority calibration. Sit down with each process owner and go through the ten most common decisions in their domain. For each one: can they make it without asking someone above them? If the answer is usually no, you don't have a process owner — you have a relay station. Fix the authority, not the person.

3. Build a weekly 20-minute exception review into the operating rhythm. Not as a status meeting. As a decision session. The question isn't "where do things stand?" It's "what needs a decision this week and who's making it?" That single structural change — a named time to close open items — does more for process ownership than any RACI update.

The system is live. The question is who's running it.

Aggregate cycle time is one of the most misleading numbers in operations.

When you average processing time across everything — routine transactions, disputes, regulatory-flagged items, intercompany corrections — you get a number that satisfies the executive dashboard and tells you nothing about where the problem actually lives. The average looks reasonable. The underlying distribution is hiding a crisis.

In most post-ERP environments I've walked into, 15–20% of transactions are driving 80–90% of cycle time variance. That 15% is your real problem. But the aggregate metric makes it invisible — because the 80% of transactions that process cleanly are pulling the average down toward something that sounds acceptable in a leadership meeting.

The segmentation that changes the conversation

Separate your clean-path transactions from your exception-path transactions. Run each as its own baseline, tracked separately, owned by different people. This one structural change typically surfaces the real problem within the first two weeks of measurement.

Set separate baselines for clean path and exception path. Your clean-path cycle time tells you how well the system works when it works. Your exception-path cycle time tells you how well your team manages complexity. They require different interventions.

Track migration between paths. What's creating new exceptions? Which process steps are generating exceptions at a higher rate after go-live than before? That's your real root cause conversation.

Build the leadership conversation around exception rate, not average cycle time. The question is: what percentage of transactions are falling off the clean path, and is that percentage going up or down? That is an actionable metric. Average cycle time is not.

The fix isn't a better dashboard. It's a better question.

Every automation engagement I've seen fail had one thing in common: they started with the tool, not the process.

The technology isn't the hard part. Scoping a bot, building a workflow, connecting a system — those problems are solvable. The failure mode I see consistently is organizations that automate a process they haven't actually stabilized, documented, or owned. The bot runs perfectly. It's running the wrong process at scale.

Three questions before any automation scoping

1. Can you describe the intended process in five steps or fewer — without workarounds? If the answer is no, you don't have a process to automate. You have a collection of adaptations that people have built around a broken process. Automating that encodes the workaround at scale. Fix it first.

2. Do you have 60 days of stable transaction data with a known error rate? If the error rate is still moving — still being discovered, still being explained — the process isn't stable enough to automate. You need a baseline that holds. Otherwise you're building to a moving target and you won't know it until month three of the deployment.

3. Is there a named human who owns the exception path? Automation will generate exceptions. Every system does. If no one owns those exceptions before you automate, you will have a bot that creates work nobody manages. In regulated environments, that work doesn't disappear — it accumulates until someone gets escalated to, usually at the wrong level.

The order matters

Stabilize the process. Measure it for 60–90 days. Then automate against a known baseline with a documented rollback plan. In that sequence, automation accelerates performance. In reverse, it locks in the dysfunction and makes it faster.

If you can't answer all three questions above with confidence, you're not ready to scope automation. That's not a failure — it's a scoping decision that saves six months of rework.

I've sat in rooms where the go-live plan had 40 hours of training scheduled and zero hours of behavior change designed.

Training tells people what the new system does. Adoption is about changing what people do — by default, under pressure, when the old way is faster or easier. Those are different problems, and treating one as the solution to the other is how you get systems that work and processes that don't.

What the 10% do differently

They design for the moment of friction, not the moment of learning. Training happens before go-live. The adoption challenge happens in week two, when the system is live, the old process is still muscle memory, and the new process has a step that nobody warned them about. The organizations that succeed identify those friction points in advance and build reinforcement exactly there — not in the training room.

They track behavior, not completion rates. Training completion is a vanity metric. It tells you who showed up. It tells you nothing about what they do on Tuesday morning when the system behaves differently than the simulation. The metrics that matter: are exception-path decisions being made at the right level? Are workarounds appearing in the transaction data? Is escalation volume going up or down?

They make the front-line manager accountable for adoption, not the project team. The project team will leave. The manager stays. If the manager isn't invested in the behavior change — if they're still allowing workarounds, still absorbing exceptions that should be resolved at the point of origin — then training was theater. The accountability for adoption belongs with the person who can reinforce it daily.

If your post-go-live adoption plan ends with the training schedule, you're measuring the wrong thing.

The performance plateau isn't a mystery. It's predictable. And most organizations walk straight into it.

I've watched the same pattern play out across multiple post-ERP environments in regulated utilities. It unfolds on a timeline that is remarkably consistent, regardless of utility size, system, or region.

The pattern

Months 1–3 post go-live: Stabilization focus. Everyone is engaged. Issues get surfaced and resolved quickly because the project team is still in the building and escalation paths are clear.

Months 4–6: Performance improves. Key players — the ones who actually knew how decisions were made — start getting pulled onto the next project. The institutional knowledge starts to leave the room.

Months 9–12: The people who knew why certain decisions were made are gone. Workarounds start accumulating. Exception queues grow. Nobody escalates it because there's no clear escalation path anymore — the project team inbox doesn't exist.

Months 15–18: A VP asks why performance is back to where it was before the project. The answer is almost always the same: nobody installed the governance layer that makes transformation stick.

Three things that change this outcome

A KPI system tied to named process owners, not project milestones. When the project closes, the metrics shouldn't close with it. If the performance system lives inside the project plan, it disappears when the project does. Build it into operations from month one.

A leader cadence designed to surface drift — not celebrate go-live. The operating rhythm that sustains performance is not the same as the governance cadence that managed the implementation. Build a post-go-live operating model before the project team leaves, not after performance drops.

A documented exception escalation path that doesn't end at the project team inbox. Exceptions will happen. The question is where they go when they do. If the answer is unclear when the project team leaves, you've guaranteed the plateau.

The 18-month problem is preventable. But you have to design for it in month one, not month fifteen.

I've seen organizations spend $50M on a transformation and $0 on the meeting cadence that would make it hold.

A weekly operating rhythm is not a scheduling preference. It is a decision system. The organizations that sustain performance after major change share one visible pattern: leaders at every level have a cadenced touchpoint where they see the same data, make the same decisions, and close the same loops — week after week. That pattern is not accidental. It was designed.

The right frequency for each level

Weekly huddles for frontline operations. Biweekly team reviews for managers. Monthly multi-process reviews for directors. Quarterly business reviews for executives. Each level surfaces what the level below couldn't resolve. The cadence is a transmission system — issues that belong at a higher level move up, and decisions that should be made below don't get escalated unnecessarily.

The right structure

Not status updates — decision points. The question that opens every meeting isn't "where do things stand?" It's "what needs a decision this week and who's making it?" That reframe changes the entire dynamic. Status updates generate more status updates. Decision points generate closed items.

The right owner

Someone has to be accountable for the meeting running — not just for showing up to it. In every cadence that holds, there is one person who owns the agenda, tracks open items from the prior week, and closes the loop on what was committed. When that accountability is diffuse, the meeting degrades into a status call within 60 days.

Leader routines fail when they're treated as optional. They hold when they're treated as the mechanism by which the organization makes decisions — because that's exactly what they are.