Process Improvement Starts With the Boring Stuff

Alex Carter October 20, 2026 20 min read

A few years ago, the managing partner of a mid sized accounting practice called me in to “fix” their month end close. She already had a process improvement plan, and it was an expensive one. She wanted automation, a new workflow platform, and dashboards on the wall. The software demos were booked before I arrived.

On my first morning, I asked three senior staff members to show me the checklist they used for the close. They each pulled one up. All three were different. One was a spreadsheet last edited two years earlier, another lived in a personal notebook, and the third was a sticky note on the side of a monitor that simply said “DON’T FORGET ACCRUALS” in red ink.

That was the real problem. Not the lack of software. The firm had no shared understanding of how its own work was done, so any tool they bought would have automated three different versions of confusion.

The Process Improvement Lesson That Keeps Coming Back

I have been doing continuous improvement work for a long time now, across law offices, consulting shops, staffing agencies, IT service teams, and a few warehouses before that. And the lesson keeps coming back, almost annoyingly: process improvement starts with the boring stuff. The dull, unglamorous basics that nobody puts on a conference slide. Writing down how the work actually happens. Agreeing on one way to do it. Cleaning up the shared drive. Fixing the handoff between two teams that don’t talk to each other.

This article is about those basics, why they matter more than the exciting parts, and how to start on them without turning your office into a bureaucracy.

The Unglamorous Truth About Process Improvement

Most leaders I work with have been sold a version of process improvement that looks like a transformation. Big kickoff, consultants, a branded program name, a new system. Some of that has its place. But in my experience, the companies that actually get better year after year tend to look a little dull from the outside, built on steady business habits rather than big launches.

They have checklists that people use. Those checklists get reviewed regularly. Everyone knows who owns what. When a problem shows up, they can point to the step where it happened, because the steps are written down.

That last part matters more than people realize. Taiichi Ohno, the engineer most associated with the Toyota Production System, is famously quoted as saying “Where there is no standard there can be no improvement.” I have that line printed on a card above my desk, and I think about it every time a client wants to skip ahead to the fun part.

Here is why it holds up. If everyone does a task their own way, you cannot tell whether a change made things better. You only know that things are different. One person speeds up, another slows down, and the average hides everything. A piece on standard work from Fabrico puts it in a way I like: without a fixed method to compare against, you have change without a baseline, not improvement.

So before anything else, you need a baseline. And baselines are boring to build.

Process Improvement Begins by Writing Down the Real Work

The first boring thing is documenting the work. Not the work as it appears in the policy manual, and not the work as the department head imagines it. I mean the work as it actually happens on a Tuesday afternoon when someone is out sick and a client is calling.

In lean circles this is called standard work. The phrase sounds rigid, and that puts people off. I understand. Nobody in a professional services firm wants to feel like a cog. But standard work isn’t about turning people into robots. It is about agreeing on the current best known way to do something, so everyone starts from the same place and anyone can suggest a better one.

KaiNexus, a company that has written about improvement culture for years, describes standard work as a detailed description of the current best practices for completing an activity or process, built so that work is done consistently regardless of who does it. Notice the word “current.” The standard is supposed to change. More on that later.

Let the People Who Do the Work Write It

The most important rule I follow is that the people who do the work write the standard. Managers can facilitate. They can ask good questions and keep the meeting on track. But the person who processes 40 invoices a day knows things about invoice processing that no supervisor knows. KaiNexus makes the same point, noting that the people who perform the tasks in a process should produce the standard work documents, and that involving them builds a sense of ownership.

There is also a diagnostic benefit here that I didn’t appreciate early in my career. When you bring three people into a room and ask them to agree on the steps, and they can’t, you have just learned something enormous. The same KaiNexus article observes that if the people doing the work can’t agree on the current process, that tells you something significant. In my accounting firm example, the disagreement over the close checklist explained almost every late close in the prior year. We didn’t need a dashboard to find that. We needed a whiteboard and two hours.

Documentation Habits That Support Process Improvement

A few practical habits help when you write things down, and they’re the same ones behind SOPs people actually follow:

Keep each document to what fits on one or two screens. If it scrolls forever, nobody reads it.
Use screenshots, short videos, or photos wherever words get clumsy.
Write the “why” next to any step that people tend to skip. A step without a reason is the first one to disappear.
Put a date and an owner at the top of every document.

That fourth habit sounds trivial. It is the single thing that keeps documentation alive.

Map the Process You Have Before Any Process Improvement

Once people have written down their steps, I like to put them on a wall. Literally. Sticky notes, butcher paper, and a long hallway if we can find one. In remote teams, a shared whiteboard tool works fine.

Process mapping is one of the oldest tools in quality work, and it is still one of the best. A columnist in Quality Magazine described the process map as a personal favorite tool, explaining that a reviewer should be able to spot waste, bottlenecks, delays, redundancies, illogical sequences, and gaps from the completed map. The same writer noted something I see constantly: once the map exists, process owners often return to work and make quick adjustments right away.

That is my favorite moment in any engagement. Somebody looks at the wall, goes quiet, and says, “Wait, why do we print that and then scan it back in?” Nobody had to tell them. The map told them.

Walk the Real Process First

The trap here is mapping the ideal process instead of the real one. People want to look good. They will describe the version that happens when everything goes right, not the version with the workarounds, the side spreadsheets, and the email that goes to Brenda because Brenda is the only one who knows the password.

So I walk the process. In lean language this is going to the gemba, the place where work happens. In an office, that might mean sitting next to someone while they onboard a new client, or watching a ticket move through a help desk queue. GoSkills makes a point in its Lean Six Sigma training that I repeat to every team: when you discover the actual process is different from what is mapped, change the map, not the process, at least not yet.

That patience is hard. The minute people see waste, they want to fix it. But if you fix the first thing you see, you often fix a symptom and miss the cause sitting three steps upstream. Map the whole thing honestly first. Then decide.

Use Swim Lanes to Expose Handoffs

One more thing about mapping in professional services. Use swim lanes. Draw a horizontal band for each role or team, and let the process move between them. Every time a line crosses from one lane to another, you have a handoff. Count them. I promise the number will surprise you.

Clean Up the Workspace, Including the Digital One

When people hear “5S,” they picture a factory floor with tape outlines around every tool. That is where it came from. The five steps, usually translated as sort, set in order, shine, standardize, and sustain, were built to organize physical workspaces.

But I have used 5S in law firms, recruiting agencies, and marketing teams, and it works there too. The workspace just looks different. Picture a shared drive with 14 folders called “Final.” Add a CRM with three duplicate records for the same client, plus a project tool where half the tasks were abandoned in 2023.

Why 5S Is a Process Improvement Tool, Not a Tidiness Drill

What I like about 5S is that it isn’t really about tidiness. Lean Enterprise Institute’s Tom Ehrenfeld, rounding up writing on the topic, notes that the true purpose of 5S goes deeper than a one time housecleaning. The same roundup frames it as a method to teach people to take ownership of their own work environment so they can perfect their standardized work.

That connection to standard work is the part most people miss. A clean shared drive is nice. A clean shared drive where everyone knows exactly where the current contract template lives, and the old ones are archived, is a process improvement. It removes a decision from every person’s day. Multiply that by forty people and fifty decisions a week, and you have bought back real time.

Art Smalley, writing for the Lean Enterprise Institute, describes how his own view of 5S broadened over the years, and how in office work teams often built a process map to “see” the work before organizing it. That order of operations is worth copying. Map first, then clean. Otherwise you organize things around a process nobody follows.

A Half Day Digital 5S

Here is a quick version I run with teams:

Sort. Archive anything nobody has opened in a year. Don’t delete. Just move it out of the way.
Set in order. Agree on one folder structure and one naming convention. Write it down.
Shine. Fix broken links, duplicate records, and dead templates.
Standardize. Make the folder structure the default for every new client or project.
Sustain. Put a 30 minute review on the calendar every quarter. Assign an owner.

Step five is where almost everyone fails. Which brings me to the uncomfortable part.

Handoffs Are Where Process Improvement Pays Off Most

If I could fix only one thing in most professional services firms, it would be handoffs. Sales to delivery. Intake to case team. Recruiter to account manager. Developer to QA. Every one of these transitions leaks information.

Velaction, a lean training company, explains this well. On a factory floor, a handoff is physical, like moving a cart from one station to the next. But in the office, handoffs require mental reshuffling of work. The person receiving the work has to rebuild the context in their own head. What did the client actually agree to? Which requirement was a nice to have? Who promised what by when?

Velaction also points out something I have seen many times: administrative processes often get less attention around handoffs than the shop floor does, and offices tend to lean toward specialists even when the work doesn’t require it. Every specialist you add creates another handoff, and every handoff is a chance for something to fall through.

Making Handoffs Boringly Reliable

You won’t always be able to eliminate handoffs. Some work truly needs specialists. But you can make the remaining ones boringly reliable. Here is what has worked for me:

Write a handoff checklist. List exactly what the sending team must provide before the work moves. Contract scope, key contacts, deadlines, open risks.
Give the receiving team the right to reject. If the package is incomplete, it goes back. This sounds harsh. It saves weeks.
Hold a short live conversation for complex handoffs. Fifteen minutes on a call catches what a form never will.
Track how often handoffs bounce. If one team’s handoffs get returned constantly, that is your next improvement project.

None of this is exciting. All of it works.

Measure Process Improvement With Fewer, Honest Numbers

Measurement is where process improvement efforts often go sideways in a different direction. Instead of skipping the basics, teams drown in metrics. I once audited a consulting firm with a 37 tab reporting workbook. Nobody could tell me which three numbers mattered.

My rule is simple. Pick no more than three measures for any process you are improving, and make sure the people doing the work can see them every week. For most service processes, the useful ones fall into a few buckets: how long the work takes from start to finish, how often it has to be redone, and how often the customer or the next team is unhappy with what they received.

Rework Tells the Truth

That second measure, rework, is the most revealing in my experience. Professional services firms rarely track it because rework hides inside billable hours or “client revisions.” But when you start counting how many times a proposal, a contract, or a report goes back for correction, the picture of where your process breaks becomes very clear.

ASQ, the American Society for Quality, lists a set of basic quality tools that have stood the test of time. Quality Magazine summarizes them as data collection sheets, histograms, Pareto charts, scatter diagrams, cause and effect diagrams, flow charts or process maps, and control charts. You don’t need all of them. A simple tally sheet and a Pareto chart will get most teams surprisingly far. Count the reasons work gets sent back for a month, sort them from most to least common, and fix the top one. Then do it again.

Honestly, that is most of what process improvement looks like when it is working. Count, sort, fix, repeat.

Make the Standard Easy to Find and Easy to Change

Here is the part where most documentation efforts quietly die. A team writes beautiful procedures, saves them somewhere sensible, and then never looks at them again. Six months later, the real process has drifted, the documents are wrong, and everyone has learned to ignore them.

KaiNexus is blunt about this. In their advice on standard work documentation, they write that the biggest mistake they see companies make with standard work is pure neglect. Their fix is equally direct: every suggested process change should trigger a review of the standard work.

Keep It Where the Work Happens

Two things keep a standard alive in my experience. First, it has to live where the work happens. KaiNexus makes the point that standard work documentation must be available to employees in the place where they do the work. In a modern office, that usually means linking the procedure directly inside the tools people already use. If the client onboarding checklist lives in the CRM record itself, it gets used. If it lives in a folder three clicks away, it doesn’t.

Treat Every Standard as a Draft for Process Improvement

Second, people have to believe the standard can change. This is the opposite of what many people expect. They assume standardizing means freezing things. In practice, a living standard invites more improvement, not less, because now there is something concrete to improve. KaiNexus explains that standard work should never be treated as final work, and that once a tested change proves better than the current standard, the documentation should be updated and employees retrained.

The University of Strathclyde’s continuous improvement team says it plainly as well: as the process changes, so too should the standard work.

I like to tell teams that a standard which never changes is a warning sign. Either nobody is improving anything, or nobody is reading the document. Neither is good.

Why Teams Skip the Boring Side of Process Improvement

If all of this is so effective, why do so many organizations skip it? I have thought about this a lot, and I think there are three honest reasons.

First, the basics don’t photograph well. A leadership team can announce a new platform. It is much harder to announce “we agreed on a folder naming convention.” Nobody gets promoted for a tidy shared drive, even when that tidy shared drive saves the firm hundreds of hours a year.

Second, the basics expose things. When you write down how work is really done, you find the workarounds, the single points of failure, and the person who has been quietly holding a process together for years. That can be uncomfortable. Sometimes it reveals that a senior person’s favorite way of doing things is the source of the problem. It takes some courage from leadership to sit with that.

Third, there is impatience. Results from the basics take weeks to show, and they are often invisible until something goes wrong and doesn’t. A good handoff checklist doesn’t produce a headline. It produces a quarter where no client was surprised by a missed deadline. That is easy to overlook.

Lean Enterprise Institute’s roundup of writing on standard work highlights a point from Michael Ballé that I find useful here: standards only work if people own them, believe in them, and trust them. Trust is slow to build. It comes from doing the boring thing consistently, week after week, until people see that it actually helps them.

A Simple Process Improvement Plan for the Next 30 Days

If you are reading this and thinking about your own team, here is a plan I give to clients who want to start without a big program.

Days 1 to 7: Choose and Gather

Pick one process that happens often, frustrates people, and touches more than one team. Client onboarding, monthly reporting, and new hire setup are common choices. Then gather the people who do it. Ask each of them to describe the steps on their own first, compare the versions, and note every disagreement.

Days 8 to 14: Map and Document

Put the steps on a wall or a shared board using swim lanes. Walk the process with at least one person doing the real work, and mark every handoff and every wait. From there, write the current standard on one page if possible: steps, owner, date, and a short reason next to any step that tends to get skipped.

Days 15 to 21: Fix One Thing

Not five. One. Usually the worst handoff or the most common reason for rework. Test the change for two weeks. While that runs, clean the related digital space by archiving old templates, settling on one folder structure, and removing duplicates.

Days 22 to 30: Measure and Keep It Going

Check whether the change helped. If it did, update the standard and tell everyone. If not, roll it back and try the next idea. Finally, put a 30 minute monthly review on the calendar with the process owner. That meeting is the thing that keeps all your work from evaporating.

You will notice there is no software purchase in this plan. That is deliberate. Once you understand the process and have a stable standard, software decisions get much easier and much cheaper, because you know exactly what you need the tool to do.

Final Thoughts on Process Improvement

Back to that accounting practice. We never bought the workflow platform they had been demoing. After six weeks of writing down the close, mapping it, fixing two handoffs, and cleaning up a shared drive that hadn’t been organized since the firm moved offices, their close went from eleven working days to seven. Later, once the process was stable, they did adopt a modest tool. It took two weeks to configure instead of three months, because they finally knew what they were configuring it for.

That is what I mean when I say process improvement starts with the boring stuff. The exciting parts are real, and they have their place. But they work best when they stand on a foundation that is dull, well understood, and maintained by the people who do the work every day. That foundation is the core of good operations management.

If you remember one thing, make it this. Before you change a process, make sure you can describe it. Ahead of any automation, make sure everyone does it the same way. And before you celebrate a process improvement, make sure someone owns keeping it alive.

The boring stuff is where the results are hiding.

Frequently Asked Questions About Process Improvement

What is process improvement in simple terms?

Process improvement is the ongoing work of finding where a process wastes time, effort, or quality, and changing it so it performs better. It works best when there is a clear, documented baseline to compare against, which is why standard work matters so much. The University of Strathclyde’s guide to standard work gives a clear introduction.

Why is standard work important for process improvement?

Without an agreed method, you can’t prove whether a change made things better or just different. Standard work gives you that baseline and makes deviations visible. The KaiNexus overview of standard work explains how it supports ongoing improvement.

Who should write process documentation?

The people who actually perform the work. Managers can guide the conversation, but frontline staff know the real steps and workarounds. See KaiNexus on best practices for standard work documentation.

Does 5S apply to office and professional services work?

Yes. In an office, 5S often focuses on shared drives, templates, CRM data, and project tools. Its real purpose is ownership of the work environment, not just tidiness. The Lean Enterprise Institute’s roundup on 5S covers this well.

What is the most common mistake in process mapping?

Mapping the ideal process instead of the real one. Walk the process and record what truly happens before redesigning anything. The GoSkills Lean Six Sigma Green Belt course explains this approach.

How do I make handoffs between teams more reliable?

Use a handoff checklist, allow the receiving team to return incomplete work, and track how often handoffs bounce. Reducing unnecessary handoffs also helps. Velaction’s explanation of handoffs outlines why they create waste in office work.

References

Tags:Operations