One way to set strategy is to use your clout.  As the company’s chief executive and majority shareholder, convince everyone else that the direction you want to take is essential to achieving the company’s objective goals – increasing sales, improving customer satisfaction, and complying with government regulations.  Maybe not the best way, but it’s one way.

Realistically, there are better ways to determine company strategy, and no one way is the best way.  Any time you can take more than one route to arrive at a desirable goal, you need to balance the relative value of projects, using financial measures like ROI, or prioritization schemes like Pareto charts.  This post considers the interactions between decisions, projects, and systems – in real life, few good decisions occur in isolation. Decisions must take into account that everyone in your company depends on everyone else for information and work-in-process.

That’s where process maps come in

Implementing strategy without a process map is like navigating a family road trip without a road map. It usually doesn’t work out. Ask my wife about my driving and navigating from St. Louis, Missouri, to Michigan. Fortunately, we had plenty of food and water in the minivan, and the kids were already in Michigan at summer camp.

Today in the article section, we continue our series on process maps by introducing three types of process maps: High-level, Low-Level, and Swim Lane Process Maps.

Consider that before packing the minivan, I might have consulted a map of the United States. Were I to look at the big picture, I would have seen right away that the eastern shore of Lake Michigan is north and somewhat east of Saint Louis and that it’s faster to drive through Illinois and Indiana to get there than say, through Missouri, Iowa, Wisconsin, and the Milwaukee Ferry. In that sense, the national map is a High-Level Process Map. It shows the major systems (states) and how communication (highways) pass through them.

My wife asks the question, "why do they call this a minivan?"

If you were updating your company’s automation supporting order-to-cash software, you might want to review a high-level picture showing how Purchasing moves a quote to Production, and Production sends finished goods to Shipping. A High-Level Process Map would show you right away that Shipping has to receive materials before shipping Finished Goods to customers. Knowledge of sequence and dependencies depicted in a High-Level Process Map helps you determine what happens first.

Back on the road

Once we were in Wisconsin, the big US map showed that Milwaukee was to the right (er, east) of Dodgeville. Easy enough. Once we got to Milwaukee we searched for the ferry. There, the big USA map was not much help, so I pulled out the more detailed (or low-level) Wisconsin state map.  On it, I looked for the Milwaukee area insert.  Furthermore, had I stopped to ask directions, someone might have advised staying in the southbound lanes of Carferry Drive rather than end up back on Lake Parkway heading toward Chicago.

That is the kind of insight you can glean about your business from a Low-Level Process Map. Credit checks and accounts-receivables reviews happen before granting credit to customers, so you might want to work on the estimating and accounting software packages before redoing the invoicing systems.

Now my family and I are all safely home.  I’m contemplating our next road trip, and I have become a big fan of Swim Lane Maps. Like a Low-Level Process Map, Swim Lane Maps show the functions that must occur for a successful journey, like “Drive” and “Navigate” (and maybe “Keep your hands off your sister’s iPod”).  Swim Lane Maps show responsibility for each activity and when various parties need to accept information from (or hand off to) one another.

All this, and they're still happy campers, on the eastern shore of Lake Michigan.

Had I consulted a Swim Lane Map before repacking the family in the minivan, it would have been visually apparent that I was responsible for driving, not navigating, and I was supposed to accept information somewhere north of Chicago.

One can come to appreciate that maps get all the information out in the open. And should things go in the wrong direction, you can point to the map. Interested parties can discuss the map calmly, with no need to comment on anyone’s innate abilities such as hearing or sense of direction.

At this point, you might see how Swim Lane Maps could come in handy in your company, when you consider how systems will support people who provide information and work-in-process to each other, and vice versa.  For example, the sales department is supposed to hand off orders to the credit department which, in turn, performs the credit check based on management criteria.  The IT department should want to know about responsibilities, dependencies, and hand-offs — which a Swim Lane Map can convey easily and concisely – before they begin to plan, develop, debug, and roll out software.

So, check out this week’s installment about High-Level, Low-Level and Swim Lane process maps.  An introduction to the series appeared last week in a blog post of ours and in the article site where we posed the question, ‘What is a Process Map?’

I trust that next week, you will find your way back here for more types of maps.

Process improvement is occurring at many organizations throughout the world.  Yet people constantly ask about how to get started.  How do you get your organization moving in a direction of continuous improvement?

First off, you have to have Management Commitment.  The obvious question, then, is how does top management show commitment to change and improvement? The answer is about inspirational leadership, it is about communication.  To be an inspirational leader, one needs to be a great communicator.  Management commitment takes both leadership and communication.

Second, it takes SMART Objectives.  Planning by management must result in clearly defined objectives that the organization can work towards.

Third, in order to achieve the SMART objectives, the organization will require operational Action Plans with accountability and responsibility for each action.  This means the Who-What-When is spelled out for proper execution.

Fourth, you will need a User Focus.  Defined customer requirements, an understanding of the voice-of-the-customer — your customer, and a method of constantly integrating your customer’s requirements into your processes.

Fifth, there has to be Profound Knowledge, which results in your ability to anticipate results.  Really understanding your customer, your markets, and your processes lead you to anticipating what your customer needs next.  How do you reach this state?

Sixth, you will need to learn and implement Management By Fact, which will lead you to profound knowledge.  Collect the facts from data, use the data to derive information, and obtain knowledge about your customers, markets and processes.

Seventh, in order to manage by fact, you will need the facts in the form of Real-Time Data.  Your processes will require increased visibility and transparency.  Real time data is needed to build a strong competitive advantage.  The longer the delay in getting data, the slower your reaction time is and the less competitive you become.

Eighth, with so much going on you will need a good Change Management System that can document and control all of these changes.  This will build on your system of management by fact and lead you to greater profound knowledge.

Ninth, Execution Audits, internal audits or process audits.  Either way you will require a system of monitoring to ensure that the system is working, that your change management system is effective, and that you are in fact achieving progress towards your SMART objectives.

Tenth, still unsure of where to start?  Then Continuous Learning is needed to build your knowledge management.  No improvement will take place unless knowledge is identified, acquired, shared, and used.  Training, learning and practice are crucial to build competence.

What are these Performance Improvement Drivers?

1. Management Commitment (Leadership & Communication)
2. SMART Objectives (Goals)
3. Action Plans (Accountability, Who-What-When)
4. User Focus (Customer, Employee, Supplier)
5. Profound Knowledge (Anticipates Results)
6. Management By Fact (Data, Information Knowledge))
7. Real-Time Data (Visibility)
8. Change Management System (Documentation & Control)
9. Execution Audits (Monitoring)
10. Continuous Learning (Improvement)

The thing about IT systems is that people have to use them. No matter the on-time, on budget performance of the development, the success of your install will be judged on how you move the needle on the metrics that the system was designed to affect. And to move the needle, users have to use your system effectively.

Getting users to use it takes two things. It takes buy-in, which you no doubt facilitated by involving users early to define their requirements. It was at this stage that you investigated and communicated to users the underlying core process that would be automated by your system. You got on the same page with users at the very beginning that the right work is in fact being automated.

Getting people to use your system requires their buy-in from the start, and bite-sized, context-sensitive training and communications after your system launches. Copyright, Bizmanualz, Inc. © 2009.

The second thing that you need to get users to use the system is communications and training, aka: a roll-out. Roll-out is when you remind users that they defined the requirements in the first place, and at that time you all agreed that by automating the core process, their lives would be easier, and the enterprise would benefit through improved metrics.

Remember, your million-dollar technology investment is at risk if people don’t use it. Your IT development was certainly serious. So your roll-out needs to be serious too, not a Band-Aid slapped on to try and recover.

Deployment: Who needs to know what, and when do they need to know it?

A serious roll-out reflects your understanding of how your system will actually be used. Remember those use-cases? OK, dig those up and consult them when planning your training and communications.

Develop a training plan that is consistent with the use-cases that you captured when you gathered user requirements. Copyright, Bizmanualz, Inc. © 2009.

Develop training from the point of view of your users. Think about the context in which the information will be used. That is, deploy training in formats appropriate for the setting. For example, field-delivery workers will have their hands full, literally. They may not have the time to attend live training for extended periods. Instead, break up the information into bit-size nuggets, and deliver it digitally to their mobile devices in visual or video format.

Deliver training in bit-sized nuggets as it is needed. Use formats that work in the situation. Make it as easy as possible or people to know what they need to know to use your system effectively. Copyright, Bizmanualz, Inc. © 2009.

Close the loop by updating standards, policies and procedures.

Remember how, early on, you and your users got on the same page about the core processes that you would be affecting? Ultimately, you need to close the loop. You need to update company standards, policies and procedures to reflect any changes that you have made in the work flow, compliance or standard practices.

It’s too easy to focus on the project management metrics and forget that ultimately it’s the impact of automation that matters. Do users remember that they set the requirements? Do they know how to use the system to do their job? Are people making the connection of improving metrics back to the technology causing it? Take a good look at your roll-out plans, and make sure that you get payback for your technology investments.

PR: wait… I: wait… L: wait… LD: wait… I: wait… wait… Rank: wait… Traffic: wait… Price: wait… C: wait…

Last time we talked about process as a conceptual representation of work flow. Processes show how business functions work together at a certain rate to achieve a goal. Processes show inputs being transformed into useful outputs at some rate of flow or tempo. A good process leaves out non-flow information, and is simple (Figure 1.).

Figure 1. Processes should communicate the main steps occurring within a business function. Show the inputs and outputs, and the useful transformation taking place. “Useful” is usually determined by the customer. Draw processes as simple as possible. Illustration copyright Bizmanualz, Inc.

Simple processes provide information at the level of a business function. But workers require much more literal information. Most of the time, workers design their own work by determining how they will achieve a goal within their perceived constraints: “Hit the ball by swinging the bat. You get three outs.”

Workers create mental pictures and checklists of what they need to do to get their job done. They translate, in essence, from the conceptual process to the literal steps (Gifure 2.). “Hold the bat hand over hand. Watch the ball. Swing level.”

You can help translate the process into action by showing the literal steps.  ”Showing” may entail demonstrating, training, and coaching. It may include providing pictures or diagrams to remind workers what they need to do.

Use Pictures

Figure 2. Pictures and diagrams help remind us how we want to approach our work. Pictures are especially helpful when we want to change the way we do our work. Picture credit blogs.sun.com/DaveEdstrom

Especially when we want to change or adjust how we do something, we may need to be reminded of what we are supposed to do differently. Pictures and diagrams are particularly useful for that.

Recently I built a cedar fence along my property line. Though I had built fences years ago with my dad, I needed a reminder of how to set and steady the posts (Figure 3.) before pouring the concrete, and how to scribe a level line across the fence row. I found a book with pictures and referred to it while working.

Figure 3. Even for experienced workers, referring to pictures helps plan the job and recall the special know-how that they have acquired. Picture credit: www.ourfixerupper.com

So you can see there is a wide gap between the conceptual process of playing baseball and the literal steps of swinging a bat; or between the process of building a fence and the literal work of setting a row of fence posts. Translating from the process to the literal work in ways that help people do their work is what we call implementation.

And, as they say, implementation is where the rubber meets the road (Figure 4.).

Figure 4. Your process may be fine-tuned. But it takes action-oriented communications and job training to roll out your process effectively. Picture credit: About.com

In future posts, we will look at how to use training, job aids, video and other media to effectively implement processes.

PR: wait… I: wait… L: wait… LD: wait… I: wait… wait… Rank: wait… Traffic: wait… Price: wait… C: wait…

Implementing changes in an organization can generate a range of emotions within your stakeholders (employees, customers, suppliers, etc.) that can create barriers to realizing your original change objectives.  Understanding why people are responding the way they are to your proposed changes will help you to roll-out your improvements more smoothly and allow you to obtain the buy-in from your stakeholders that will actually deliver the performance improvement your changes were designed to realize.

When you start to communicate change and improvement throughout your organization you will take your stakeholders through five phases or states of mind.  Each phase is a normal emotional state that most people go through.  Developing a communication plan to help guide your stakeholders through each phase, with prepared responses for each one, can ensure a successful roll-out for your changes and improvements.

What are these phases of change and how should you respond?

1. Anticipation.

Stakeholders are anxiously waiting for what is about to come. People may not know what to expect; rumors abound, and speculation increases.  Some may even be in denial of what is about to occur.

Introduce your strategy, present your concrete steps, and build awareness to overcome the speculation and reduce the resistance or denial factor.  Identify each stakeholder group and assess what information each group may need.

2. Confrontation.

Your stakeholders begin to see that change is really happening, improvement teams are forming, or new software features are being implemented.  But that does not mean they are happy about it.  In fact, they may be angry, frustrated, or downright resistant in an effort to fight your changes. 

Help stakeholders get through it.  Be firm and have responses to possible objections from each of your stakeholder groups.  Remind stakeholders of your strategy (the one you used to address their anticipation in phase 1).  You will need customized information tailored to each stakeholder group.  There is no “one-size-fits-all” approach here.  Each group has different interests, needs and objections.

3. Realization.

Once the change has been implemented, stakeholders will realize that nothing is ever going to be as it was before.  Some may reminisce, longing for the “old ways” of doing it.  Some groups may start negotiating alternatives to the changes seeking for a way out.  They may try and not use the changes or go back to the “old ways”.  Many will have questions about the changes and will want some answers.

Be prepared with various communication vehicles such as memos, newsletters, town-hall meetings, interviews, team meetings, coaching and training sessions.  Training is very important because changes introduce new concepts.  If you don’t offer enough information to overcome their resistance, you may prolong the next phase.

4. Depression.

Stakeholders may mourn the past. Intellectually, change is here, but emotionally, stakeholders don’t like it.  People see what they believe, which means that even if the changes are working, they may not “see” positive results. 

Address each stakeholder’s beliefs and give them time to work it through.  Develop monthly communications to reinforce the behavior change.  Keep an open door to answer lingering doubts.  Show everyone how well their efforts are working.  Communicate results and recognize successes.

5.  Acceptance.

Stakeholders are now accepting the changes. Although they may have reservations, they are not fighting the changes anymore. They should be seeing some of the benefits on their own, even if they are not completely convinced.  Some will love the changes and may wonder how they ever managed the “old” way.  Overall, they are starting to feel good about the changes and accept them as the new way of doing business.

You are not done.  You will need to reinforce your changes and improvements with some type of follow-up and review.  Use process audits, process reviews, and management reviews or solicit inputs from your stakeholders to obtain feedback and “lessons learned” that can be used to start a new cycle of improvement.  That’s right, at this point we are back to phase one, using feedback to anticipate stakeholders needs and make the next round of changes.

An understanding of these phases is critical for developing your communication plan. Your communication plan objectives should address each phase.

Change Phase Communication Objectives

1. Anticipation – introduce your strategy.
2. Confrontation – respond to objections.
3. Realization – provide training and support.
4. Depression – communicate monthly.
5. Acceptance – Review and obtain feedback.

Understanding why people are responding the way they are to your proposed change will help you to roll-out your improvements more successfully and obtain stakeholder-buy-in that will actually deliver the performance improvement your changes were designed to realize.

We are currently in the midst of surveying our customer base for their opinions on how to improve our policies and procedures manuals, the bread-and-butter of our company.  We’re asking them questions like, ”Have you used the product?”, “What was your primary reason for purchasing it?”, “How satisfied are you?”, and “How do you manage (control) your documentation?”

Organizations usually buy our policy and procedure, or “PnP”, manuals for the content and structure they provide.  Think of policies and procedures as the plans and materials for erecting a modern office building: it’s easier for a builder to work from a set of plans, with the materials identified and laid out for the task, than it is to start “from scratch”.

There are several major differences between PnP manuals and buildings, however.  Thousands of years of accumulated wisdom, as well as enforcement of clear, strict building codes, ensure that adverse outcomes in construction (i.e., spontaneous building collapse) are unlikely to occur.  With policies and procedures, there is no strict code – and no laws of physics – to say the outcome must be “this” or “that”.

Companies are free to do what they wish with the plans and materials, somewhat like a child playing with Lego blocks.  There’s no rule set in stone that says, “You must use all the procedures we provide you.”  There is no governing body to tell you to implement the procedure exactly as it’s written, or to forever keep the document in the same format in which it came (i.e., Microsoft Word).  In fact, we encourage our customers to shape the policies and procedures we provide to their unique circumstances.

What do you do once they have the product?  We solicit your input from the moment we deliver the manual, but few actually take us up on the offer.  That is the main motive for our current research — what are you doing with our Policies and Procedures manuals?  More importantly, what can we do to make them better for you?

Now, I ask our readers who’ve yet to purchase one of our products, “What do you think?”  How do you develop and manage your policies and procedures?  How do you maintain them?  How do you communicate PnP to your workforce?  How do you ensure timeliness and availability?  How do you ensure cooperation?   How do you ensure VALUE?  And…given what you now know…what might you do differently?

PR: wait… I: wait… L: wait… LD: wait… I: wait… wait… Rank: wait… Traffic: wait… Price: wait… C: wait…

When dealing with your knowledge management communications, think about all of your changes and improvements as organizational “news”.  You have to get the word out and communicate the news so others can profit from the changes and improvements you’ve made.  Could you do this like a news show?

All of the communications activity must be planned and coordinated.  You would need a news staff to write, produce, and distribute your news materials.  Your news show could have a schedule with a regular time slot, format, and an editor or anchor for your program.  Perhaps you run feature stories regarding training events, Kaizen of the month, and progress on major changes or improvement objectives.  Be creative — have fun with it — make it engaging!  Produce videos, a newsletter, a change wall, or skits for the changes.

What’s your news program’s budget?  Major software changes in IT get money for new software and software customization, but considerably less time and money is allocated to effectively communicating these changes.  This may be due, in part, to the lack of a formal in-house communications program.  If you don’t have such a program, do you go with “what works for everybody else” (which really doesn’t), or do you try something different…like a news show?

Show Your Commitment to Change and Improvement

Identify a news staff whose job it is to get out the word on change and improvement.  Delivering change and improvement is like producing a show.  You have to budget for the production of the show (change and improvement development activities) and you then have to have the show on a regular basis, just like the news.  Change and improvement, like the news, isn’t a one-time event: it’s ongoing.

Your knowledge management program requires a serious commitment to change and improvement.  You can demonstrate your commitment by the time and money you budget to communication, as well as by the quality of the Change and Improvement Show you produce.  Seeing a high level of commitment from management, the rest of your organization is more likely to effect the changes and improvements your company needs to thrive.

PR: wait… I: wait… L: wait… LD: wait… I: wait… wait… Rank: wait… Traffic: wait… Price: wait… C: wait…

In ‘Top Ten Reasons’, we looked at why policies and procedures don’t work.  In this post, I’ll share a little about what we do when companies ask us to help improve their policies and procedures.

“Too long”, “unclear”, and “complicated” generally top the list of “Reasons Why Procedures Don’t Work”.  We often find that clients have complex flow charts, swim lane diagrams, and subway maps, usually with no clear starting or ending point or communications objective.  When workers look at these diagrams, they don’t know how to read them — they don’t know what the author is trying to tell them.

Get Organized, Then Consider Your Communications Objectives

While capturing everything you learned while studying your process may help you, you don’t need to show that around.  Think of your spaghetti diagram as homework, but think of your procedures as having a job to do. Your procedures are responsible for communicating know-how to someone who may have an alternate view of how a task should be done.

Think of your procedures as stories, with a beginning, middle, and end.  After discerning your intent, we look in our library for something we have composed already that tells a similar story. But our procedure communicates flow, or how raw materials, information and labor come together to create value for customers. By organizing the story around flow, we can simplify your procedures, not to mention the underlying processes. Flow should be a theme in all your procedures.

When we review a client’s procedures, we compare them to stories (e.g. procedures) that we have already written. We simplify client procedures so that they communicate flow. And we add measure and balance information at transition points to keep the underlying processes running smoothly.

Procedures Should Help Work Flow

Think of work flow as the current in your favorite fishing or boating stream.  When the stream moves at a “normal” pace, the water stays within its banks.  However, if a larger-than-normal volume comes downstream, or if the normal volume encounters an obstacle (like a bunch of fallen trees), the stream rises.  Soon, the stream has nowhere to go but out of its banks. What a mess.

To maintain work flow in your company, you need to know the measure and balance that should be maintained at each transition point in your process. For example, how much raw material should Receiving hand off to Production every hour?  Every day?  Such concrete measure and balance information determines the tempo of your processes. Workers need to know the appropriate tempo to prevent production managers from being inundated with material, and prevent inventory from backing up.

Procedures communicate flow.  And other kinds of documents and communications tools have other jobs. Thinking about and achieving all the communications jobs needed to roll out a process and keep it humming along is what we call “implementation”.

After Developing Your Procedures, You Have to Tell the Story

When we review a client’s procedures, we compare them to procedures, or stories, that we’ve already written. We simplify client procedures so they communicate flow.  And we add measure and balance information at transition points to keep the underlying processes running smoothly, at the appropriate tempo.

That may end up being a lot of information — more than you would want to write in text form as a procedure — so we deploy communication tools: maps, job aids, visual work boards, training, videos, etc.  These tools get the right information to the right people at the right time, so they can do their work at the right tempo and stay in sync.  Deploying communications tools in this way is how we achieve implementation.

I’ll cover implementation in a future blog post.

We have been hearing from IT department managers lately. They say that the volume of work standards has mushroomed in their departments, ostensibly to implement accepted IT processes such as Information Technology Infrastructure Library (ITIL), Capability Maturity Model (CMM), and others. Such tools are, of course, supposed to help us gain better alignment with business goals and more efficient project implementation.

But is the volume of documentation really helping? Despite the growth of documentation, managers note persistent symptoms including an ever-increasing project backlog, and little direct feedback from completed projects indicating that they are having the desired impact on the business. These are symptoms of lack of alignment of processes and the business’ goals.

When workers view procedures as irrelevant or hard to use, they tend to rely on tribal knowledge—they just ask each other questions. While that can be effective, formal knowledge management systems become superfluous and they die. This invites other problems, like inconsistent product quality, loss of knowledge as people leave, lack of compliance and no audit trail, hoarding of information. All of this puts customer satisfaction and even the company’s future at risk, managers say.

Figure 1. Knowledge Management Systems

Written standards, policies and procedures need to be aligned with key processes, or users will find workarounds.  We hear from IT managers because they think of us as ‘the policies and procedures guys,’ and they sense that “better” procedures are the answer.

But we’re the first ones to suggest that standards, policies and procedures are only part of the answer. When found in abundance, policies , procedures and standards could be a symptom of lack of alignment around business goals. It’s like trying to patch an ineffective working relationship by writing down every possible scenario. Of course that’s impossible. And it only hamstrings the creativity and initiative of your best professionals.

But playing the role of facilitator, you can help staff and stakeholders collaborate to critique existing processes, modify them as necessary, and agree on a workable process.

As their manager and resource, you can provide communications and training to reinforce buy-in and adoption. Success creates an impetus for further improvement. With the improved focus, It’s easier to weed out unnecessary processes and get better results.