The Plan-Do-Check-Act cycle is a well-understood, time-tested way of introducing and maintaining a continuous quality improvement program into an organization. It involves four key steps:
This is where you decide what’s important. What commitments you’ve made. What results you want to achieve. Where you want to go. And then how you’re going to get there.
In this step, you execute the Plan. If that means a process change, this is where you put that new process to work. If that means some kind of change in the organization, environment, infrastructure, etc., the Do phase is where that happens. Along the way, you’re capturing information so that you can take the next step.
PDCA is, in large part, a recognition of the fact that we mere mortals aren’t really all that good at predicting how well our plans are going to turn out. So after we Plan and then Do, we Check, analyzing the information we collected during the Do step, drawing the best conclusions we can about how well the Plan worked.
Act (or Adjust)
Once we understand what worked and what didn’t, we’re in a better position to understand what needs to change. The Act step is where we discover and document those changes.
PDCA is intended to be a continuous process. With each iteration, ideally, you get better and better at what you do.
There are a number of factors in PDCA that may vary greatly from one organization to the next. How often do you cycle? Who plays what role in the process? What is the organizational scope (team, department, division, etc.) of a given cycle, and how does it fit in with the PDCA of either parallel or greater scopes?
Another factor that is easy to overlook is where technology fits in the process. Obviously, technology can be a useful tool in support of PDCA. The question is: do you talk about technology as part of your PDCA?
Why Tech May Be Out of Scope
There are a number of reasons why this might not happen.
- Those involved in PDCA may not feel qualified to analyze the role of technology in their day-to-day work
- IT investments are viewed (rightly in most cases) as a strategic decision, and the PDCA participants may not have a clear channel to influence those decisions
- The IT organization itself may be unwilling or unable to engage
In many cases, however, it may simply be that the thought never crosses anyone’s mind. Sometimes our technology feels like an immovable object, like a mountain that has always been there, something we can learn to manage but dare not aspire to try to budge. And in many cases, that’s exactly what it is. But to the extent that we can exert some control over the tools we use, the benefits can be well worth the effort.
Why Tech Should Be a Focus
I can remember a time (and I’m actually not all that old) when it was common for a supervisor to begin their day by grabbing a stack of greenbar reports that had been printed by a third-shift computer operator, picked up by a mail clerk, and delivered to a mail tray near the work area. The supervisor would then visually scan the greenbar for items requiring attention from their department, highlight or mark those items, and then distribute the marked piece of paper to a staff person in a cubicle.
The staff person would then use some kind of greenscreen terminal to make changes to the database on the mainframe. If the staff person needed more information, they might pick up their desk phone and dial a number to call somebody. If they weren’t sure of the process, they might consult a thoughtfully tabbed 4" binder on their bookshelf for instructions, or search in their file drawer for a recent policy memorandum from their manager. Or they might get up and walk to somebody’s desk and ask in person.
Today, we don’t do any of those things. We use email and instant messaging for communications. Policies and procedures are on the corporate intranet. Work items are fed through some kind of enterprise resource planning (ERP) or customer relationship management (CRM) system. What paper does come into the office is scanned, often using optical character recognition (OCR), and loaded into some kind of imaging system. Binders (and bookshelves) are disappearing. When’s the last time you saw a memo? Telephone and in-person communication still exist, but now they’re often considered a last resort for urgent needs, not the default means of communication they once were.
We rely on our technology now more than ever. And while the ERPs and CRMs and imaging systems and communication systems and intranets and all those things can be huge time-savers, they also can be sources of process friction.
Maybe the systems don’t work together as well as they could, requiring double-entry or introducing discrepancies. Maybe it takes too long for new hire to gain the access they need. Maybe there’s one particularly common and critical function that takes 10 seconds to do, but could be done in 3.5 seconds with a minor tweak to the system, saving thousands of work hours per year. If we’re not looking at these things in our PDCA, we could be missing many important sources of improvement.
The Consequences of Our Technology Decisions
It’s an unfortunate fact of life in modern business that even the best strategic technology decisions will have unintended and often far-reaching and long-term consequences. Even if a company has a full-blown software development operation, it’s regrettably common for applications to be architected and implemented in a way that makes them hard to adapt — or, in PDCA terms, hard to Act on.
If you find that to be the case in your organization, you should view that as a strategic risk. Hard-to-change IT limits growth. It stifles innovation. And it can put severe constraints on your process improvement efforts. If your IT is an immovable object, effectively outside the scope of your PDCA, then whatever stakeholders are interested in PDCA should also be interested in how to move your IT forward, because the two are inextricably linked.
On the other hand, if you’re considering a strategic IT investment, give careful consideration to how the product or solution will evolve as your business evolves. There are well-established techniques for building software in a modular, flexible way. Good solution architects and designers will employ those techniques. Whether you are working with internal resources or an external partner, make sure they share your priorities and understand your goals.
If you can, budget for ongoing changes to your technology as part of your PDCA efforts. And make sure technology changes are always “on the table” for PDCA. If you don’t (or currently can’t), your continuous improvement will be missing a critical element. It will never be as successful as it could be.