How to Fix a Broken Business Process: A 9-Step Framework

I was an individual contributor in sales. Every day had a clear shape — calls to make, a pipeline to push, a target to hit. I was good at it, mostly because I understood exactly what winning looked like.

Then I moved into project management on the delivery side of an IT-enabled services business. Different job, completely different planet.

Nobody hands you a number to hit anymore. Instead, you've got five workstreams, three of them quietly falling behind, a client who wants a status update you don't actually have, and a team that's looking at you to make a call you're not sure you're qualified to make yet.

I remember the exact week I realized sales had taught me how to chase one outcome — and delivery was demanding I hold ten moving parts at once, none of which I could fully control, all of which I was now accountable for.

I got it wrong more times than I got it right, early on. Missed dependencies. Said yes to timelines I should have pushed back on. Learned the hard way that "managing a project" and "managing the people on the project" are two completely different skills, and nobody teaches you both at the same time.

That jump — from owning your own number to owning everyone else's outcome — is one of the hardest, least talked-about transitions in a career. Most people either sink in it or come out the other side fundamentally different.

I came out different. It just took longer than I expected.

Think about it. Somebody did a task one way under pressure, three years ago. It worked, barely. Then it became "how we do it" — never written down, never questioned, just passed forward like a rumor.

Then you become the manager. Suddenly you're accountable for a process you didn't build, can't fully explain, and definitely didn't choose.

That's not a discipline problem. That's not a "try harder" problem. It's an inheritance problem — and most managers spend years firefighting symptoms of a process that was never actually a process to begin with.

The fix isn't motivation. It's redesign.

1. Identify the need — what's actually broken, specifically, not just "things feel messy"

2. Understand the current state — map how work really flows today, not how the org chart says it should

3. Analyze & brainstorm — find the real bottleneck, then generate more than one way to fix it

4. Design the new workflow — pick one path, make ownership unmistakable at every step

5. Validate & refine — test it on a small scale before rolling it out wide

6. Develop supporting tools — templates, checklists, trackers — whatever makes the new way the easy way

7. Roll out & implement — communicate the why, not just the what, or adoption stalls

8. Provide ongoing support — the first month after rollout is where most redesigns quietly die

9. Monitor & improve — a process you never revisit is already decaying

Most people stop at step 4. They redesign the workflow, announce it in a meeting, and assume it'll hold. It won't — not without steps 6 through 9.

The work that actually changes how a team operates happens after the big idea part, not during it.

A digital marketing agency I worked with ran weekly performance reports for 20 clients. Every single one was a fire drill.

Numbers lived in a Slack channel, scattered across messages from 7 different PPC specialists. One person tried to assemble it all by hand. The account manager spent half their time just chasing people for "what's the latest number on this client?" — not analyzing anything, just hunting for data that already existed somewhere, in someone's head or half-finished spreadsheet.

By the time a report actually reached a client, nobody could say with confidence who owned which number, or why a campaign had moved the way it had. The account manager was constantly frustrated, and honestly, a little lost — improvising answers in client calls instead of having them ready.

We mapped the actual workflow first — who touches the report, in what order, and where it was breaking. Then we redesigned it: a PM owns the tracker, a reporting lead sets up the structure, each specialist owns and signs off on their own numbers, a clear review chain catches errors before a client ever sees them. Later, we moved the whole thing into a project management tool — same workflow, now with deadlines and ownership built in, repeatable every week without anyone having to remember the steps.

The result wasn't just faster reports. Time spent assembling them dropped by more than 90%, once the numbers lived in live dashboards instead of Slack threads. But the bigger shift was who was doing the thinking. Before, the account manager was winging strategy conversations because they didn't trust the data. After, specialists were the ones bringing strategy recommendations to the table — because they owned their numbers and actually understood them.

The report got better too. What used to be an inconsistent wall of numbers became a templated, client-ready deliverable every time. Client satisfaction went up — not because the campaigns suddenly performed better, but because the client could finally trust what they were being told, and why.

None of this needed new ad platforms or a bigger team. It needed someone to sit down and actually design how the work should flow — then build the system that makes that design hold, week after week.

very story above is really the same story, told from a different angle. Someone trusted me with a mess. I didn't have a clean answer on day one. I had to sit with the confusion long enough to actually see the shape of it, before I could fix anything.

I used to think that not knowing the answer immediately meant I wasn't good enough at this yet. Twenty-five years in, I've come around to the opposite view — the people who claim instant clarity on a messy problem usually haven't looked closely enough at it.

I'd rather be slow and right than fast and wrong. Most weeks, that's still the hardest discipline I practice.