What message are you trying to get across in your procedures? To whom? Is your message getting through? How do you know?

“What message am I supposed to get across, besides ‘This is how you’re supposed to do it’?”, you may ask. To that I reply (in the form of a question), “Are we talking ‘procedures‘? Or ‘work instructions‘?”

If the activity is fairly simple:

• There might be more than one way to do it, but none of them is longer than 6-7 steps;
• It doesn’t require a lot of parts, tools, or prep time; and/or
• It’s not being done by a broad, diverse group of people;

we’re talking about work instructions. An example is “loading a smartphone app”:

• Use a search engine to find an app that does what you want;
• Go to a web site that has the app; and
• Download the app and install it on your smartphone.

Many tasks are simple and straightforward so that an employee can be trained in minutes just by showing them how it’s done and letting them do the task repeatedly until they have it right. You don’t need to write a work instruction (or a procedure) when:

• It would take less time to show someone than to write and test a work instruction; and/or
• The risk of failure is minimal (i.e., the probability of failure is small-to-nonexistent, as is its impact).

If you can’t afford the risk, either don’t do it or reduce your risk by documenting the process.

Which brings us to procedures. Procedures are documented processes. The processes may be so complex that they can’t be reduced to a set of work instructions. A process may also consist of a number of processes. The process may cross departmental and/or hierarchical boundaries.

In all cases, it’s important to communicate certain concepts clearly and effectively in your procedures, such as:

• Purpose;
• Roles and responsibilities;
• Scope; and
• The company’s policy on that subject.

If you’re not communicating these points to your intended audience — if your message is being lost in translation — here are some things you can do to help:

1. Add graphical content. If I tell you, “Enter your user name and password and hit [Login]“, you probably know what that means, regardless of what application I’m talking about. But, what if you don’t?

Procedures are primarily designed to train (and retrain) people to perform complex processes and/or processes they don’t perform often. If you’re unfamiliar with logging in, it’d be helpful to you if I showed you what that looks like, wouldn’t it?

(Don’t you love the warmth of that light bulb that goes “on” in your head as you say, “A-ha!”?)

2. Use active voice. It’s more direct. It leaves less room for interpretation. For example, which of the following makes more sense:

• “An internal audit program shall be prepared annually by the lead Quality Auditor before the end of the current calendar year”?, or
• “The lead Quality Auditor shall prepare next year’s interal audit program before the end of the current calendar year”?

3. Write as if you’re talking to one person. Picture yourself trying to teach a procedure to someone who’s not at all familiar with it or the company, like a new hire.

That’s the procedure’s audience and that’s how you should write all procedures — as if it’s just you and the trainee at the computer, machine, etc.

4. Tell your audience “why”. The new hire in #3, above, should have been through a general company orientation — the company’s lines of business, how long it’s been in business, the vision and mission statements, company objectives, etc. — by now. They need all that background to understand how this procedure fits into the grand scheme (that is, how the process helps the company achieve its objectives, or “why they’re learning the procedure”).

If you don’t tell them why, they’re liable to ask themselves at some point, “Why am I doing this?” You may not agree with — or like — the answers they come up with on their own. This may be counterproductive.

5. Simplify, simplify, and simplify. My favorite example is the Swiss Army knife¹. The more expensive variations have nearly every tool you might possibly need. Capable of doing a hundred things, it does none of them well. I’ll take a tool box with me on a camping trip; you bring your Swiss Army knife.

Champ 28 Swiss army knife, by Wenger

Is my kit heavier? Yes! Is it stowable in the glove box?² No! But will your saw cut anything larger or heavier than string cheese? Will your knife cut nylon rope? Will your hammer…wait…you don’t have one. (I will credit you the beer and wine bottle openers, however.)

My point is you should keep your procedures like your tools — simple, functional, and easy to use.

Remember these five techniques for improving your procedures:

1. Add graphical content;
2. Use active voice;
3. Write like you’re talking to an audience of one;
4. Tell the reader “why”; and
5. Keep it simple

…and your procedures will be simple and easy to use, which will improve your workforce’s productivity and morale. So, who’s with me?

* * * * * * *

Notes:

¹I’m expressing a personal preference; that’s all. (I can’t see “Dexter” using a Swiss army knife, can you?) However, if Wenger wants to give me a Swiss army knife and show me how to use it, I’m open to that.

²I’m curious: How long have you been driving? Have you ever, in that time, put a pair of gloves in the “glove box” of any auto?

I wonder how many of our clients, on receiving our policy-and-procedure manuals, have asked themselves what in heck they got themselves into. (“There’s a lot of stuff here…where do I begin?”) Well, like a lot of things, it’s probably not as difficult as it looks initially. First, you took a step in the right direction by using our templates to develop your company policies and procedures. It’s always easier to start with some of the work already done for you, rather than you having to start from scratch.

Now, how do you proceed?

Understand Why You Need Policies and Procedures

You don’t need policies and procedures merely to comply with regulations or industry standards (like ISO 9001). Sure, there’s nothing quite like the threat of fines, legal action, and the scorn of the business community to motivate you, but that’s far from the best reason. Much better reasons for developing policies and procedures include:

• Communicating your business goals and priorities;
• Standardizing processes, behavior, and results;
• Training your employees consistently; and
• Identifying acceptable and unacceptable behaviors (and encouraging or discouraging them).

Prioritize Your Needs and Set Goals and Timelines

Now that you understand “why”, you need to decide “what”.  Of the policies and procedures you could work on, you have to determine which one(s) are going to provide:

• The biggest bang for the buck;
• A quick return on your investment; and/or
• The greatest good for the greatest number.

Only you know what you need.  I can offer you suggestions (like “start with a fairly simple process”) but only you have the intimate, day-to-day knowledge of your organization. It’s your company: you decide.

So, decide which process you’re going to document first.  If you have absolutely no idea (you have no metrics and no historical basis for evaluation), try any Bizmanualz policy or procedure.  Document your initial design and development process and use it as a baseline for further development.

Give the first procedure a fair evaluation.  Don’t look at your first policy-and-procedure development, point out all the flaws you can find, declare the project an abject failure, and pull the plug.

Introduce discipline into the development process by setting clear and meaningful (aka, “SMART“) goals and timelines.

Analyze Your Existing Procedure

If you already have a de facto¹ procedure in place, don’t throw it out in favor of so-called best practices that may or may not work for your firm.

“If it ain’t broke, don’t fix it.” (Anon.)

Now is as good a time as any to document your process.  Diagram it quickly in any manner and medium with which you’re comfortable. Simple is best (“Don’t make a big production out of it!”, Mom used to say).  Next…

Compare Your Process with Bizmanualz Best Practices

Bizmanualz has already looked at many companies’ procedures, blended them together to describe “best practices”, and reasonably modeled these procedures on the Deming, or “Plan-Do-Check-Act”, cycle. You may find that your procedure already looks very much like the PDCA model:

• You develop a set of objectives and a plan (process) for realizing those objectives;
• You implement the plan and immediately start collecting process data (in-process, end-of-process, etc.);
• You routinely analyze the data, to see if the process is performing in line with expectations; and
• You make changes to the process (procedure) in order to improve it and improve your results.

If that’s the case, you don’t have far to go at all. Next…

Make Our Procedure Your Procedure

Make the obvious and necessary changes to the Bizmanualz policy and/or procedure.  We wrote them generally, like ISO standards, so they’d have the widest possible application.  Any resemblance between our procedure and your process is coincidental; that is, you’ll have to customize our procedures – make them your procedures.  For example:

• Change every instance of “Bizmanualz” or “the company” to your company;
• Where you have an existing form (e.g., purchase order, customer order, invoice), use it – and make sure field names, etc., on the form and in the procedure agree;
• Change job titles in the “Responsibilities” section and in the procedure itself to reflect your circumstances;
• Change diagrams² as needed;
• Add visual aids – they add impact and meaning and they complement verbal descriptions very well (especially when they come from your office, your shop floor, your staff, etc.); and
• Leave out what you don’t need.  An entire procedure or just part of one — if it doesn’t apply to your situation, delete it.  Make your policies and procedures simple and direct.

Verify and Validate the Procedure

The people responsible for implementing the procedure have to put it to the test.  Oh, you could write a procedure and thrust it on an unsuspecting workforce but until it’s subjected to “real world” conditions, the results you see may not be the ones you want or expect.

And there’s more to it than procedure verification and validation. Some people call it “getting buy-in”. Whatever you call it, recognize that your employees are stakeholders in the company. They have a vested interest in the company, too – if it does well, they do well. So, keep them in the loop on matters that directly affect them, to ensure their understanding and cooperation.

Even if they’re not directly impacted by the procedure in question, keep all employees informed of this — and most — company matters.

Implement the Procedure

Now, publish the tested-and-verified procedure.  Distribute the procedure to those responsible for executing it, analyzing it, and training employees.  NOTE: A document management system, or DMS, will help you address publication and distribution, as well as improve document control.

Hold a training session on the procedure – make sure trainees are not only capable of doing the work, but that they understand the process and the objectives, as well.  Finally, execute the process.  Collect the data from measuring devices and routinely analyze it.  Look for anomalies and trends in the data, evaluate the process, and aim for continual improvement.

Yes, ladies and gentlemen, it’s just that simple! Any questions?

NOTES

¹Just because you haven’t documented it doesn’t mean you don’t have an effective process in place.  Example: my wife and I came to a quick understanding some time ago that I would clean tubs, showers, and toilets and balance the checkbook. It’s very effective, plus there’s no point in documenting such processes because (a) they’re easy and (b) she won’t ever do them.

²We’ve been using Microsoft Visio to build diagrams. Unfortunately, Visio is not automatically included with any version of MS-Office, so far as we know. There are many alternatives to Visio, though – any search engine will help you find them – so your organization need not be constrained by a lack of Visio³.

³No, that’s not a typo.

We’ve already discussed writing policies and procedures and reviewing them. Now let’s talk about doing something with them.

Too many companies look at procedure documentation as a necessary evil. They look at business as a number of tasks and events; sometimes those events and tasks are connected, but many times they’re not. In these cases, the process – and the procedure that’s supposed to describe it – are two different things. In other words, there’s “what we say” and there’s “what we do”.

You’ll enjoy greater success if you look at your business procedures like you look at everything else you do — as an opportunity for improvement. To make sure you do, always keep the following concepts in mind:

1. Be sure your process objectives are reasonable. As I’ve often said and will continue to say because it bears repeating — nothing does more harm than having unreasonable expectations.

2. Be sure that as you’re developing your procedures, you have all stakeholders involved from start to finish. Do you know who the stakeholders are? Yes, the customers are, ultimately, but there are others.

3. Be sure that everyone — not just the people who are responsible for executing your policies and procedure, but those at both ends of the process, too — understands the importance of the procedure to the success of the company and have bought into that.

4. Train people on the procedure before you officially implement it. Do as many “dry runs” as are necessary; once is never enough.

5. Execute the procedure faithfully. Don’t do only those parts of the procedure that make sense to you. Don’t take shortcuts.

6. As you’re executing, be sure to monitor & measure the process. You can’t improve a procedure if you don’t have data.

7. Do something with your data — don’t just look at them and say, “Oh, that’s interesting.” What is so interesting about the data? Do you see outliers and trends in the data? Do they make you want to take action? Do you know what’s normal and what isn’t? Continually reevaluate your objectives.

8. Review your procedures periodically. Things are not always what they seem. Different people see things differently. Don’t wait for problems to occur — assume they will and head them off.

9. Revise and retrain. No procedure should be considered “set in stone”. Internal and external forces are continually changing. Either you see change as a normal part of doing business or you don’t see it until it’s too late. If you’re ready for change, it’s much easier to deal with. Revise procedures and retrain continually, in small increments.

10. Always think proactively. What’s better, to be active or passive in the business world? (It’s a rhetorical question — we all know active is better, right?)

Don’t sit on your laurels. Just because you’ve implemented your procedures doesn’t mean it’s time to sit back and take it easy. (Well, maybe you can for a moment, but don’t get too comfortable.) The business world, like time, waits for no one.

We received an inquiry recently on our process implementation page, where we ask: ‘How do you train and communicate with your team?’ A reader from a large school district wrote in using one of our new ‘Talkback‘ links saying that their district is in the midst of many changes. The district faces many communications and training challenges, especially when introducing new information technology for employees. The reader went on to ask, ‘How do large companies communicate and prepare training for organizational change or implementation?’

Will Employees Skip Training When A Customer Calls?

Though a school district may be an extreme example, it shares practical challenges similar to many geographically dispersed organizations where employees work independently. Teachers may work at dozens of locations. Culturally, teachers work independently most of the time and are highly self-directed. Every teacher answers to many customers–classroom parents–to whom they must be responsive. Daily schedules are rigid, driven by the defined length and periods of the school day. Non-class in-service training and meeting time is scheduled long in advance.

Any organization with a distributed workforce that works directly with customers faces similar training challenges. Does your workforce travel? Do your employees manage customer relationships in the field? Would your field employees skip training if a customer calls? Think: field sales, field service, field engineering, route delivery. For many such organizations, in-person group training is probably not practical.

 If training Is Not Practical, What Do You Do?

But training is still essential. For example, your route sales and delivery professionals across the Americas require training on a new ordering system. As in the case of teachers in a school district, their workdays are prescribed by customer’s strict time constraints. Any time available for training needs to be measured in tens of minutes. Further complicating matters, every employee’s availability is different.  And by the nature of their work and work culture, they operate independently.

Clearly, building a training program based on inflexible, one-size-fits all classroom training isn’t going work. But self-paced user-driven independently administered training would work. So video content was developed in three to 10-minute bites that employees could access at any time. The information was organized so that students could approach the training either sequentially, or as needed during the day.  Materials and delivery were customized to work with the limited mobile bandwidth and small screens employees had.

A technology partner configured an on-line “campus” web site, complete with quizzes and completion-tracking built in so that the corporation knew who had been exposed to the material, and had demonstrated proficiency. Compliance metrics helped the company roll-out new features and capabilities at times when metrics indicted likely acceptance by workers.

Do You Have a Distributed Training Challenge?

If your corporation, school district or other organization employs independent workers and you are budgeting for a training solution, contact Bizmanualz for a demonstration. While the content can be custom-developed for your organization, you will benefit by sharing the on-line infrastructure, which today is hosting proprietary video training for several large, distributed organizations.

With an understanding of your needs, your content can be developed and hosted in an on-line campus customized for you. Just as Bizmanualz has the largest library of pre-written policies and procedures, we can provide an existing on-line campus so that you don’t have to re-create the wheel.

Call us at (314) 863-5079 x18, e-mail Sales@bizmanualz.com or use the ‘Talkback’ dialog on our Training and Roll-Out page.

Dateline: Utopia, Somewhere in the Near Future

In Utopia, we define our business processes as we develop them.  We plan for the inevitable by formalizing many of our processes.  Granted, there are some processes that are so simple, it doesn’t make sense to document them.  Where it makes sense, we document our processes – we write procedures – so that, among other things, we (a) have a baseline for improving them and (b) can train people, should the need arise.

However, we don’t adhere to our procedures so rigidly that we’re unprepared for change.  We review our processes routinely – as we’re in the midst of them, and on a periodic basis – so we know if we’re getting the results we want. This way, we also know if we’re making our customers happy, if we’re staying abreast or ahead of the competition, and if we’re taking advantage of every opportunity.

Some time ago, we were fortunate enough to learn from some of our mistakes.  One of those mistakes which almost cost us dearly was writing our procedures without knowing where we were coming from or where we were headed.  Basically, we were told to document key processes in order to be compliant, so we jumped in to document those processes without a plan.

We didn’t take a look at the big picture, at first.  We didn’t understand that we were starting a continuous journey somewhere in the middle of it.  It was like being set down in uncharted territory without a plan, let alone the proper provisions and tools.

After several unsuccessful attempts to make deadlines and meet other ill-defined or undefined requirements, we came to the realization that we were starting our journey in the middle without a clear view of where we came from, where we were headed, or how we would get there.  Without a clearly defined project plan, our process journey was always arriving at the same destination: Failure.

How many times have you had to document a process and wished you had a map showing “You Are Here”?  Or, wished you’d started with a better plan?