Recently, the Bizmanualz sales team used a “swim lane” map to agree on the use and timing of its new sales tools.  Before that, though, we collected all of our sales presentations, product descriptions, proposals, and contracts and used them to update our sales implementation binder.  We not only created this physical “home” for the information but we duplicated it on our network.  This binder was designed to help us standardize how we talk about our services.

Even with the sales tools collected and standardized in this way, we were getting more variance than we were willing to accept in terms of the length of the sales process, final configuration of the service, and the customer’s expectations.

Looking for root causes, we determined that the sales tools we had created were being deployed at different stages in the sales process by different people.  Though we had information on when was the best time to use each tool — for example, we knew it was counterproductive to send a written proposal before confirming a shared understanding with the prospective customer, and we’d developed one-page illustrations and short slide decks to help with that – the issue of correct timing had not been adequately communicated to everyone.

Bizmanualz’ sales team worked together on this swim lane map to arrive at a consensus on when to deploy proposals and other sales tools (click graphic to enlarge).

Timing is Everything

We had not clarified when to use each tool, so in practice our sales process had not been fully implemented.  Getting the sales team in on creation of a swim lane map helped us hash out the best timing and implementation of each tool. We agreed that implementation would be based on customer behaviors that we could observe and document.

Our swim lane map shows us establishing a shared understanding with the customer using a visual presentation, and also gaining acceptance to configuration and price. Only then do we propose terms and conditions.  Has a shared understanding been established? What have we observed that confirms our perception? Have we received a written correspondence? Yes: issue proposal.

By mapping it out, we could visualize the implications of using the wrong tool at the wrong time. We could see that offering a formal proposal too early could throw us into a loop of confusion, delays, and revisions. By confirming expectations one step at a time, we could literally see on the map that we would be driving up customer satisfaction, one of the key metrics we use to run the company.

The swim lane and document maps that we blogged about recently are useful for describing processes.  The swim lane map showed us who was responsible for what: Dad was driving, Mom was navigating, and in this scenario our kids were the customers.

Information flow was better captured in the document map.  It identified the documents handed off at each step of the process.  It also showed when status or other information was not in document form, but was spoken.

Swim lane maps and document maps are descriptive rather than prescriptive: we use them to communicate what is happening today, not what we’d like to happen or what should be taking place.  To change the existing process, we need to map the activities at each step and critique them for the value they add to the process.  One way we can do this is with an activity map.

When It Comes to Making Changes, Start with the Small Things

Activity maps and “value stream” maps help us capture what is happening in the workplace (or, in my example, the family minivan).  Activity maps are great for identifying areas ripe for streamlining or eliminating — if the activity/process doesn’t add value, it probably doesn’t belong.

Using my family vacation example, I could call a family meeting, tape our swim lane and document maps to the dining room wall, and engage my wife and kids in a conversation about the process of driving to summer camp.  I would ask them for their opinions and insights about each process step, to identify opportunities for improvement.  (How popular this would make me!)  

We dig past generalities down to the tasks that we each perform.  We look at each task and determine what’s not necessary – see if we can skip or eliminate steps.  Would we get there faster?  Would we each let go of “non-value-added” activities?  I don’t know, but I know that an activity map could help us get the issues onto the dining room table. (Selling our analysis, conclusions, and the resulting change might require a rendered map, which I’ll cover in upcoming articles and blog posts.)

Here’s the driving process presented in an activity map:

The first row is the process step as appears in the swim lane and document maps for the “Driving” process. Second row is a tally of activities per step and the number of lean value-added steps. Next row is color-coded by responsible party. Green activities are value-added. Red represents waiting or other waste. All other activities (in white) should be reviewed for their necessity and potential improvement.

Green steps transform the product (travel) that the customer (passenger) is receiving. These steps add real or perceived value to the product, in the customer’s eyes, so they’re called “value-added” steps.  The green steps help transform the end product, whether or not the customer is aware of the transformation. 

The “check/fix car” activity (at the top of the “Drive” column) is an example.  Preventive maintenance in advance of the trip assures my customers a trouble-free trip, though they may not be informed of the oil change, tire rotation, fluid check, etc.  Other green steps – loading/unloading luggage, occasional status reports, driving — are readily apparent to my customers.

Few would argue that waiting doesn’t add value.  Any waiting “activity” (shaded in red) is a non-value-added step.  Today — “Star Trek” notwithstanding — it is impossible to arrive instantly at a destination.  Ideally, we would look to cutting “wait time”, but in our scenario it’s unavoidable.  (Dad could go faster, but the minivan and the law enforcement authorities have their limits.)  We note that some wait time is unavoidable in this case, and we proceed with the analysis.

The remaining activities (in white) will lead to further discussion and analysis.  We acknowledge that these individual activities are not what the customers are buying — they’re buying the whole experience.  But we can’t call all of them waste — some of them are necessary.

Can We Cut Activities?

In hindsight, the activity “Plan alternate route in case of trouble” could be considered waste.  We don’t know that we will run into slowdowns, detours, open drawbridges, or inaccuracies on the roadmap/TripTik.  You could cut that activity.

But we ran into all those problems.  Good thing we didn’t cut the activity. However, the activity is not value-added to my customers.  I could tout my wife’s exceptional planning skills and convert a non-value-added activity to a value-added one, in my customer’s opinion.  If road delays were rare or unlikely, I might argue for cutting that activity.  Either way, the Activity Map is the tool that helps make the conversation meaningful.

I thought a local route near Saugatuck, MI, would save us few miles and some time. I learned that you can’t always get there from here in coastal Michigan. Good thing that my navigator had a backup plan.

Getting a job done requires more than just the work.  Often times, there are inputs provided and paperwork handed over, not only before the project, but also between tasks within the project. Now, paperwork may take the form of electronic documents, or records in a database. But either way, handing off or accepting documents is often how we set the boundaries between tasks and transfer control from one party (or project step) to another.

The map used to show the flow of paperwork is one of the seven most-used process maps that we are describing in our process map series.  The document map displays visually what information you should expect to receive, and from whom. It also shows you what information you are expected to produce for someone else. For an example, let’s go back to my family vacation story. One of my usual stops before any family vacation is AAA for a TripTik. You get a custom-printed series of roadmaps showing the territory that you plan to traverse. Tall skinny pages are comb-bound into a book. The route is highlighted, usually with an orange highlighter that is easy to see in daylight and darkness.

Handing off a simple document like a highlighted road map leaves little doubt about what is intended and that control is being handed off from the navigator to the driver.

In our vacation travel example, a TripTik map page could serve as an output document from the navigator to the driver at the “provide directions” step.  Sure, after several hours on the road my wife might just tell me where to go. But she might better show me where to go. With experience, we have agreed that a highlighted TripTik removes all ambiguity between right turns and left and otherwise clarifies the navigator’s intentions.

In this small area of the swim lane map, the navigator "provide(s) directions" to the driver. The navigator is actually handing off a highlighted roadmap, or TripTik, to the driver. This hand-off shows up on the document map shown here. See the previous blog post for the full swim lane map where this example comes from.

Document Maps Help You Recognize Hand-Offs

A simple document map like this one makes it clear what documents are inputs and outputs at each process step. You can see what documents you get, and which ones you need to hand off to others.

Look at the first row labeled “Navigator.” She obtains a TripTik map and tourist brochures (received from outside the process).  The navigator executes the ‘plan route’ process step and produces a ‘highlighted route’ and ‘turn-by-turn instructions’ for the Driver. All four documents are, literally, physical documents, and thus are shown on the map.

Next, the driver uses the documents obtained from the navigator in his ‘driving’ step and produces a status report showing the current location. Notice that a parallelogram is shown instead of a document symbol, indicating that the status report is not a written document, but a spoken one in this case.

The passengers, who don’t really own any process steps, produce a break stop request as part of a pre-defined process called “break process.” That is, the break process comes from somewhere outside of the Driving process. Here, passengers produce a spoken request for a break. Again, a parallelogram is shown, indicating that no actual written document is produced.

Document maps should show all the important written documents so that you could audit your inventory of reports for compliance purposes. The document map is not a recreation of the swim lane map. Decisions and process detail can be left out. You are showing the main steps in rough order.

Document maps come in handy in quality systems like ISO 9001, which require that certain records (like product requirements) be created and maintained. Since they show the records your process creates, documents maps remind and remind process owners to generate output documents without having to name someone as the “document police.” And if you’re in the middle of the process, document maps can tell you if you have the inputs you need to do your job.

Last week I took you along on a family vacation to the Eastern Shore of Lake Michigan near Muskegon. Yes, we got there. But it was a longer journey than it needed to be. We could have spent less time travelling, and more time vacationing in the cool climes of Lake Michigan. Responsibilities between driver and navigator could have been more clearly delineated. The hand-offs could have been better communicated to cut down on some of the indecision and waiting that occurred.  Sounds good but, So how do you do that?

This swim lane process map shows the passenger (customer) in the first lane. Their role is mostly to ask questions. In the second lane, the driver accepts requests for breaks from passengers, and route adjustments from the navigator, who is shown in the third row.

Asking, ‘how are we going to get from where we are to where we want to be,” is a question of implementation.  What are the concrete steps we have to take to get there?  Who is going to do what, and when are they going to do it?

Using Swim Lane process maps is one way to answer some of these questions.  We like to organize Swim Lane process maps by putting the ‘START’ on the left and the ‘END’ on the right.  It’s easier to read the chart from left to right.  Organizing the Swim Lane map and other process maps in predictable ways, and not over-stuffing your maps with information eases communications, which is mainly why you create process maps: to communicate to others a process that you already know.

What’s In A Swim Lane?

Swim Lane Diagrams, as described in part I of our series on process maps, organize tasks by role.  A role gets a swim lane. You are responsible for every task, document or decision shown in your Swim Lane.  The chart above shows three swim lanes: Passenger, Driver, and Navigator.  In our swim lane maps, we always show the customer on top.  Arguably, my daughters in the back seat are the customers of the ‘drive home from camp’ process.  If it wasn’t for the customer, my wife and I might be in Cape Cod, or Colorado, or France.  But we wouldn’t be in the minivan in Michigan.  To determine who goes in the top lane of your Swim Lane map, use the “but for” test.  ‘But for my daughters, I would not be driving five hundred miles north to a very small town in Michigan.  The process would not be taking place.

How Swim Lane Maps Help

What really stands out in this Swim Lane map is that Driving and Navigation are in fact different roles.  Had we consulted a Swim Lane map before our trip, we would have clearly seen that the driver should not be attempting to navigate,  no more than the navigator should be grabbing the wheel and driving.  The roles are clearly distinct.  Swim Lane Maps visually communicate how the roles relate to and communicate with one another.

Swim Lane Maps keep you within the bounds of your role while defining hand-offs of control and information.

Customer Involvement Shows Up In A Swim Lane Map

Swim Lane Maps visually communicate the involvement of each role, the Customer role for example.  As in the example above from my family road trip, my daughters asks of the process, ‘are we there yet?’ and interrupts the process when it is, ‘time for a break.’ But my daughters are passengers, and not responsible for any process steps (rectangular boxes).  In simple processes, customers may provide information at the beginning of a process in the form of requirements, and at the end when they buy the product.  In more complex products, customer requirements may be injected more frequently. In the case of co-development or co-creation of products, customers may have responsibility for processes and therefore process steps would appear in their swim lanes.

ISO-certified organizations must gather requirements from customers. That could be shown as a requirements document, depicted in a process map as a process step box with a wavy bottom. Customer requirements could also stand alone in a separate requirements definition process.

In a Swim Lane Map, handoffs of control and information appear as vertical lines or arrows originating from an activity in one role and connecting to an activity in another. When my daughter asks, “Are we there yet?”, it shows up as a vertical line leading from a decision point. The answer produces different actions, which is another indicator that this role is a customer.

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.

Recently we have been interviewing our customers to find out how they are using the policy and procedure manuals.  Many are using them as templates for policies and procedures as intended, but some are using them to infer the processes from which the policies and procedures were derived.

Many customers say they are creating process maps as aids to implement and update their processes, and to capture and communicate the information they have found.  Some customers say they are looking to Bizmanualz for the best practices of many organizations.

Like any process map, rendered maps shown above help communicate information to others and are tailored for communication. Rendered maps represent the information in familiar, more realistic graphics and can represent elements of a process in physical proximity or time.

Clearly, our customers are telling us that there is more we can do for them.  We could provide more process maps that can be customized for specific purposes.  We believe that providing a set of coherent process maps would help you get your job done better, faster and cheaper.  If your job is to implement and improve processes, and support processes with training, procedures and other communications, then clearly process maps can help you.

We’re talking to more customers right now to solidify our understanding. So if you had a conversation with us recently, and agreed to a follow-up call, you will probably hear from us again soon.  If you haven’t already heard from us, but would like to weigh in on this issue, please get in touch.  Just comment at the end of this post, or contact us online and let us know what you’re thinking.

Defining Process Maps

The trouble is that “process map” means different things to different people. You will find everything from strange spaghetti diagrams of everything going on in an organization, to abstract block diagrams that tell you little about what’s actually going on in a company.

As a step in creating our library of policies and procedures, we have created many process maps. We have had to, to make sure that everything works together.  In fact, we have standardized on seven types of maps, each type with a specific purpose, its pros and cons, and its role during implementation.

As a step toward providing you with useful, best-practice process maps, we plan to share our mapping methodology with you, our readers, friends, and customers.  We have written a white paper defining seven types of process maps and will publish it in installments (read part I).  The paper provides an example of each type of map, its best uses, and the positives and negatives of each one.

So stay tuned over the next several weeks as we fine-tune an approach to process mapping that will work for the majority of our customers, and share what we learn with you here.

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…

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.