I promise you this is not an April Fools Joke, but this process improvement specialist wants you to know that you don’t actually have to finish every improvement project.

One of the most useful professional skills I’ve developed over the years is learning when to stop working on something.

This sounds suspicious at first, especially in operations environments where we’re trained to believe that once a process improvement starts, it has to be carried all the way through. But strong organizations quietly stop work all the time. They stop reports nobody reads, automations nobody trusts, dashboards built for questions leadership no longer asks.

The real challenge isn’t finishing everything.

It’s knowing what must be finished.

Back when I worked in a corporate job, I was a part of the Supply Chain Department and responsible for sending out reports to the rest of the organization. And when I say reports, I mean A LOT of reports. Not quite sure exactly how many, one day I sat down and counted them all in a spreadsheet (of course.)

There were 34 reports! More than the number of days in a month, and some were suspiciously similar to eachother. Updating my trusty spreadsheet, I started to group similar reports together and interview each department to see what information they truly needed. Some departments were surprised they were even still getting reports - they had been marking them as junk 🤦‍♀️

Through communication, iteration and some modification of the few key reports, we were able to cut the number of reports we were sending to about half. This saved us a LOT of time, and led to some other improvement projects - departments who had said, “We don’t need this information, but can you add X,Y or Z?”

Now, I would love to tell you that I was a model employee who checked with absolutely everyone prior to abandoning some of the reports. Ah, well - not quite.

In the true spirit of Did Not Finish, I stopped sending out some of the reports with no warning, no communication, nothing. And then, I waited - to see if anyone noticed, or complained. Not all of them, just the ones I had marked as duplicates, or seemed very out of date. If someone noticed, I would apologize and send it over right away. But if nobody said anything… well, I took that as an answer right there.

What can I say - people get VERY upset about change, especially when you’re taking something away. However, I think we need to get more flexible about this - we can’t do everything, and something, something has to give.

When teams aren’t sure whether something should continue, I often suggest a very simple test:

Will we be happier six months from now if we start this project?

For me, the project was reducing reports, and my department was MUCH happier. Plus, the additional communication we had developed when working through the priorities of what to keep, change or add, helped lead to much smoother interdepartmental operations.

After six months - check. Is the project still progressing as expected? Has it made things easier, or has it uncovered larger issues that need to be dealt with first?

Having the structured check in allows everyone to honestly reflect if the project is benifiting the organization, or if it’s time to put it in the parking lot.