e never worked with so many process improvement teams in such a short period of time.  It’s been a regular “office process mapping and improvement boot camp”.

Here are some things I’ve learned over the years and that have been reinforced in my recent experience:

Start with a Project Charter

It’s important that the team start with an energetic discussion of “What are we doing here and what’s expected of us?”  That’s what a project charter is for.  It’s not “getting the form filled out” that’s important, it’s the discussion that takes place that serves to get the team members on the same page.  There are lots of Project Charter formats out there.  Choose one that’s available or design one to match your own needs and circumstances.  There are lots of generic forms on the interweb.  Some are simple, others are pretty complicated.  Whatever works for you.  But, again, it’s the conversation that important, not filling in lots of fields on a form.

Map the Process As Simply as You Can

Choosing the “level” at which the team will map the process can be a challenge.  At too high a level, there can be too little detail, at too low a level, too much detail.  I usually talk about the “2000 foot level”; high enough so that the team doesn’t get into the weeds of describing, in detail, each and every task associated with the process but low enough so that the basic steps are identified.  I’ve found that even fairly complicated processes can generally be captured in ten to twenty steps.

It’s important to map the Current State with the assumption that each step is carried out without anything going wrong.  Teams can get way down into the weeds with respect to all the steps that they undertake when things don’t go right.  So, you present the question:  “How does the process work now assuming everything goes the way it’s supposed to?”  You’ll get to all the bad things and problems later on.  Right now, you just want to get the process mapped, not identify everything that can go wrong.

I use three symbols for mapping processes: a circle for the first and last process steps, squares for all the steps in between, and arrows.  That’s it.  No decision diamonds, nothing.  My experience has been that most of the other symbols are used to account for sub-processes and steps that are made necessary by variances and problems.  That’s not what we want to capture at this point.  That said, I admit that I’ve had to occasionally use decision diamonds in a process map to identify legitimate choice points.  But it’s been very occasionally.  The large majority of the time, two circles and a bunch of boxes and arrows works just fine.

Brainstorm Process Step Variances

A variance is something/anything that goes wrong or might go wrong at a particular step of the process.  For example, variances for the process step, “Ship the product”,  might be:

• Product doesn’t get shipped
• Wrong product gets shipped
• Wrong quantity gets shipped
• Product is shipped to the wrong address
• Product is shipped via wrong carrier
• And so on.

The team brainstorms these variances and the usual guidelines to brainstorming apply.  In other words, don’t get wrapped up in long discussions of each possible variance; just write it down and move on.m  You’ll sort through them later.

One useful parameter on the brainstorming of variances to keep in mind:  The variances should occur at the step being focused on at the moment.  If a variance occurred at an earlier step but is caught or observed at the focus step, it goes under that earlier step.  For example, if the step under focus is “Budget requests are reviewed and approved”, a variance like “Manager submits wrong budget format” isn’t a variance at that step.  The manager submitted the wrong budget format at an earlier step, not at the inspection step.  Variances that occur at the “review and approve” step might include:

• Review and approval is delayed
• Incorrect format gets approved

By the same token, be careful of brainstorming variances that are actually desired outcomes of the step.  Let’s imagine that you’re mapping the process for hiring and you’re focusing on the step “Review resumes”.  In that case, “No suitable resumes are identified” wouldn’t be a variance.  Weeding out undesirable resumes is exactly what the step is designed to accomplish.  Sure, “no suitable resumes”  might be a hassle for the organization but it’s not because mistakes or errors took place at that process step.

You’ll find that this step of brainstorming variances creates a lot of team energy.  The members will engage in lots of discussion of the variances, even when you remind them of the brainstorming guidelines.  That’s OK…mostly.  You don’t want to squelch energy.  Let them talk about variances a bit and keep them moving.  So long as the team doesn’t get engaged in “debates” as to whether a variance is a big deal or not or discussions of solutions, you’ll be OK.

Prioritize the Variances

The most useful tool to use initially in prioritizing any brainstormed list is polling. I usually give the team members more than three tallies when polling process variances, maybe five to seven, depending on how many variances were brainstormed.  At this point, you’ll have a good visual as to which process problems are front and center for the team.

Develop Improvement Actions for Important Variances

You’re on the home stretch here.  I put up a good, old-fashioned four column action planning page on the flip chart (Action/Assigned To:/Target Date/Status) and go to the variances with the most tallies.  I ask, “What actions or steps do we need to take to reduce or eliminate this variance?”  There is generally a good bit of discussion at this stage.  Some of the “action ideas” will be pretty broad (“A training program for new hires”) and will need to be broken down into specific tasks (“Work instructions documented for all tasks”).  Others will be more specific (“Purchase new copier”) but might need some preliminary work carried out (“Develop business case for a copier and get three quotes.”)

But, hey, you know how to put together an action plan, right?

Follow Up Meetings

Now, we get to, what might be, the toughest stage of the whole enterprise…following up on all that initial work to actually get something done.  Brainstorming and coming up with new ideas is lots of fun.  Developing standard procedures and getting quotes for a new copy machine…not so much.

The team will need to meet no less often than bi-weekly to make sure that improvement efforts move forward.  In most cases, management will need to actively encourage these meetings.  It gets very easy to cancel meetings or for individual team members to miss meetings because of the regular workload.  Managers need to make certain that meetings are being held, attendance is good, and time frames are being met.

Even after the improvement actions are implemented, the team needs to meet to evaluate their effectiveness.  Six to twelve months of bi-weekly meetings can be difficult to sustain but it’s necessary if you’re to have any hope of creating real, lasting change in your business processes.