ny organizations intimidate their people into developing overly conservative goals, reducing the perceived probability of failure. Try to remove the fear of failure (easier said than done), and encourage employees to shoot for the moon. Then, help them get the resources they need to achieve these goals, encourage controlled, conscious risk-taking, reward success, and console honest failures that occur as a result of trying hard. It's usually better to achieve half of a 50% improvement goal than all of a 10% goal.

32. Project leaders should lead, not make all the decisions

The ideal project leader is one who can formulate and communicate a mission with inspiration, provide tools that team members need, participate with team members, identify and target opportunities and problems for action.

33. Avoid "Paralysis by Analysis." You'll never have all the facts

One of our associates was leading an inventory reduction program for a client. Some of their employees lamented the fact that up to half of the items to be tracked might lack adequate decision data, so that they felt they could not proceed. He said, "then work on the other half!" We'd still be waiting for all of the data to be right before making a decision if we'd hesitated. Instead, improvements are being made daily.

34. Don't use just functional organizations to define processes- they tend to replicate existing paradigms

Don't tolerate having processes designed to fit the current organization structure, or even specific people. Use cross-functional teams, with outsiders, internal and external process customers and suppliers.

35. Phase implementation to reduce risk and optimize rate of benefit gains

Full reengineering of a company may take much time. Most companies can't/won't wait for the pot of gold at the end of the rainbow, so it is necessary to provide payback at regular intervals, preferably starting soon. Create a phased implementation plan allowing the overall effort to self-fund itself before completion, if possible. Individual processes may have early due dates.

36. Use cellular and self-directed work teams

Get away from functional organization. Organize for processes. Cells are usually designed to handle an entire process, product, or even product line. Set up the organization to serve the customer, mission, product, process - in that order.

37. Avoid building a new bureaucracy/theocracy of Reengineering high priests/ priestesses

It seems like it's only a matter of time after a new concept, such as TQM, MIS, etc., comes along, before a corps of arrogant technocrats materializes, spouting acronyms, rules, regulations, forms, and methodologies. Reengineering is proving to be no exception to this. Don't let them gain a foothold. Make sure BPR stays with the people, by holding them accountable, organizing accordingly, and providing needed resources.

38. Use flow diagrams, dictionaries, business rules, to define system—avoid lengthy prose and technical documentation.

Define your system with simple statements, pictorial charts, tables, and where necessary, algorithms. If these can't be used for training purposes, consider tearing them up and starting over, until you can. People should be able to use them to help perform their jobs.

39. Maintain master running issues status lists

Issues really drive a BPR project. Track all suggestions, disputes, problems, guidance from management. Keep them on "issues lists." Categorize, group and prioritize them. Develop/solicit suggested approaches to these. Use these lists to guide the BPR project, and to track resolution and implementation.

40. New process designs will win by default if not contested by a set deadline.

A corporate, bureaucratic approval process moving at a snail's pace swallows up ideas, innovation and enthusiasm. Consider radical changes to yours. Use the "book club trick." Some book clubs will automatically send you books and bill you for them, unless you object or specify different books.

Your company might use this idea too. Publish suggested approaches, maybe as part of the issues list. If nobody objects or comes up with better ideas, the suggestions are automatically assigned to be developed and implemented.

41.Introduction

Business Process Reengineering (BPR) principles have been around for a long time, piecemeal and under other labels. In recent years they started coming together as a discipline, incorporating world class business principles and focusing on quantum improvements- not merely continuous gradual improvement.

BPR is the complete or partial "reinventing" of how business processes are done, to attain major performance improvement. It questions the underlying assumptions and principles, including what, why, by whom, and even, if—things should be done.

This presentation will contribute by stating and helping to clarify a number of important principles, plus some useful insights, techniques and hints – 40 in all!

Basic Concepts

1. Start with clean sheet of paper, mission statement, and vision

It is probably best to initially start with a high level analysis, and then concentrate on a small number of processes initially.

We recommend a five step design approach:

• Make a list of what you like and don't like about the existing system, and what you'd like to see. Feel free to consult others- process owners, users, customers, suppliers, auditors, whatever. Then lay this aside for awhile.
• Look at alternatives; learn about what else is available, benchmark, etc. Read books, take seminars, courses, read reports/success stories, make pilgrimages to hallowed sites of success. Talk to experienced people.
• Brainstorm approaches. Agree on mission, vision, and focus. Set some overall improvement targets. Identify non-value-added activities.
• Then, construct an abbreviated "as-is" process map to determine what is happening now, and where the waste and delays are occurring. Use this to better understand the process, generate issues lists and target more specific improvements than from the previous steps.
• Construct a "to-be" model of the proposed process, including flow diagrams, organization, forms, procedures, etc., before transitioning to implementation.

2. "Reinvent" how the business is run, don't just make incremental changes, don't automate the mess you already have

If you're not careful, the new process becomes merely an incrementally improved old process, or worse yet, an automated version of the old one. If possible, come up with a whole new, much better way to run the business or perform the process.

It's really important to get a critical mass of FRESH thinking, so that the company doesn't merely take the path of least resistance back to the old ways. There is an unseen force that tries to make almost every change effort spring back to the way it was done before. Find the forces of reaction and deal with them early. Put enough people with the right beliefs, experience, and training, in key positions to help effect change.

3. Customer-driven, anticipate customer needs, and. . .

4. Involve customer early in the process

Find out from customers/prospects what they want. Ask them before they tell you what they don't like or worse yet, take their business elsewhere. This is mysterious and frightening to many internal employees who wouldn't know a customer if they were bitten by one. Take employees out to meet customers or customers in to meet employees. Have them talk on the phone, exchange views. It usually improves both sides, and forms valuable bonds. Involve customers early in the process to build "ownership", and to avoid false starts.

Find out what your successful competitors are doing and see if it makes sense. Don't slavishly copy it—leapfrog it. There may now be better ideas or new technologies that you could use. Try looking at how companies in other industries solve analogous problems.

Better yet, think of something nobody has thought of yet. Overnight air delivery of packages, disposable razors, and eyeglasses in one hour, were all breakthrough ideas that made fortunes and thrilled customers.

Do this before you do your expensive BPR program without sufficient improvement criteria.

5. Achieve continuous, rapid improvement—gradual improvements may not suffice

The Japanese Kaizen, or continuous improvement philosophy, is an extremely powerful concept, and it has taken them, and others who practice it effectively, a long way. But, if you're ten years behind, Kaizen won't even maintain the same gap. Stronger medicine is needed. Business Process Reengineering can be such a tonic, to allow huge leaps forward, and can be used in conjunction with Kaizen. Even if you're not ten years behind, maybe BPR can be a way to get ten years ahead.

How could one suddenly leapfrog another company to become more successful? … by making accelerator pedals instead of buggy whips. By doing something not just better, but truly different.

6. Challenge existing approach

Start out with an assumption in the back of your mind that the old way can be improved enormously—the odds are with you. Allow yourself to be proven wrong in some areas, but don't count on it. This forces more critical thinking. Compare the results of the current process to your ideal mission statement and note the differences. Then brainstorm how it can be improved significantly.

It's hard to get people to challenge existing approaches, unless you:

• Remove possible threats to them for doing so. This can best be done by demonstrating that company people can do it and survive. Ensure that people are rewarded, not punished for making improvements. One company encountered was in the habit of laying off team members after improvements were made. A real motivator.
• Expose teams to alternative models for doing business. This can be accomplished through education, site visits, reading, participation in professional societies, and group discussions.
• Assign leadership or lead the charge yourself—set the example by challenging the status quo and soliciting better ideas. Encourage others to do this as well.

7. Use benchmarking, get ideas from other industries

No need to be totally original in your thinking. Find out what "best practices" are in your and other industries with transferable concepts. Possibly even collaborate with other companies in developing better processes (void where prohibited by law).

8. Define product/process relationships, avoid functional "silos"

Try to disregard the existing organization structure when developing the ideal process. Look at the objectives that need to be accomplished, the processes that are needed to support it, and finally, at the resources (including organization) needed to accomplish them.

9. Set a hierarchy of: customer, product, process, function, activity

The chart below depicts some important relationships:

Objectives

10. Compress time

Faster is almost always better, if it's done right. More speed means more cycles, which means more output per unit time, faster turnaround, which usually improves service and reduces costs. Simply trying to speed up the existing process, however, might actually increase costs, and cause quality problems. This is why "old school" people usually tell you that it will cost more, hurt other priorities, or reduce quality if your request to do something faster is granted.

11. Eliminate bottlenecks

Find the slowest activity in a process. Speed it up. This speeds up the entire process and is usually the cheapest way to do it.

12. Reduce number of steps, complexity, levels, people

The more moving parts that anything has – a machine, system, process – the more it costs, the more that can go wrong, and the longer it takes. Reduce number of steps, operations, people, parts, and improve performance.

13. Reduce defects

Most processes take much longer and cost more due to defects and exception handling. Defects are the worst form of waste. They usually force more expensive exception activities to correct them, slow down cycle times, rob capacity, and force increased capital investment (for inventory, space, equipment, working capital). It has been said that defects cause 5 to 10 times their apparent costs.

14. Increase flexibility

Being adaptable to change enables introduction of new products, services, processes, schedules. Try to envision the parameters of possible change when designing the process. Increase flexibility by using adaptable people, training them, and designing processes to accommodate future change.

Philosophies

15. Empower people, but with strong leadership, clear mission & beliefs

Empower doesn't mean to abdicate management leadership, but to provide to employees the direction, skills, authority, and tools they need to accept as much delegated responsibility as possible. However, even in this era of oncoming "self directed work teams", there is still a very great need for leadership. A lot of it needs to come from management, as well as other team members. One cannot overemphasize the value of enthusiastic, strong, informed leadership to energize a reengineering effort. People tend to respond quite positively to this.

16. Make education a way of life

There are just so many new things to learn social, technical, philosophical, specific details, that a significant portion of employee time needs to be dedicated to education and training. This is not just an expense if used wisely, but an excellent investment in the company's future. There needs to be an overall education plan. Employees need to be tasked with education objectives, and tested for improvements. When you send someone to a 3 day seminar on set-up reduction, jointly develop objectives, in advance, for this investment in time and money. This is not a 3 day paid vacation. Debrief the employee afterward- make sure the company gets a return on this investment. If not, learn why. Employees who consistently fail to deliver results here may cease to be candidates for upcoming educational opportunities.

17. A "System" consists of missions, leadership, goals, objectives, metrics, policies, procedures, education, training, organization, personnel, tools—not primarily a computer project

Address all of the system ingredients shown above to reengineer a business system, and its processes.

18. "Ownership" is important

It's better to have even a mediocre approach that has consensus and support than the best idea in the world that no one likes or understands. The first will at least work in a mediocre fashion.

Build ownership by involving people in the new approach so that their intelligence and egos become intertwined with it.

Approaches

19. Focus on eliminating non-value added activities/ assets/costs

Eliminate waste in the company. Cut back on non-productive assets. Use Shingo's "7 Wastes of Production" as a tool to help identify waste. Waste is anything that is not absolutely essential to design, produce, and get the product/service to the customer. Employ some of the various analysis techniques to help identify waste and weigh improvement priorities.

20. Use simple approaches, not complex sophistication

There are already dozens of new, complex methodologies, software packages, etc., purporting to be "magic bullets" to reengineer your company. Most of them are too complicated, and will generate more money for their purveyors than for you. Don't spend more time learning and wrestling with the tools than solving business problems. Be especially wary of complex matrices and mathematical models. Don't get much more complex than a moderate Quality Function Deployment (QFD) matrix.

The key is to understand the requirements of the process, and what is wrong with the existing process, and what tools/resources are available/needed to do the job. Then, design/improve the new/revised process.

21. Decentralize, unless there are compelling reasons to do otherwise

Delegate downward and move resources to forward positions where they might be used to more rapidly and flexibly serve the customer. Move back and consolidate where there are compelling reasons to do so because of economies of scale, critical resources. Make sure this doesn't compromise service, quality, or flexibility.

22. Streamline, Simplify, automate, integrate, in that order

Don't spend big bucks on automation until you know what it is you'll be automating, and there is a simplified approach for running the business. Often, simplification of the existing system can pay for some or all of the subsequent automation. Scope out the entire effort before automating anything. Automation and integration should be a logical culmination of a well thought-out plan.

23. Employ the conference room pilot approach

In spite of everyone's best efforts, processes may still be complex. Therefore, it is extremely important to have tools for testing, refining, and training to ensure best results, with minimum risk. The conference room pilot approach is such a tool, and works by running off-line tests of the system, manually, and with proposed operating computer/software systems, prior to live implementation. Mistakes are made, and education/training occur, in the conference room, not in the heat of battle in the office or on the factory floor. Project leadership uses mission statements, objectives, and issues lists to design test scenarios, and then leads the group through these for training, debugging and problem solving purposes.

Techniques

24. Selectively implement policies, procedures, checkpoints, controls, accountability, metrics

Don't generate any more rules and paperwork than are needed. Well educated people with clear missions need less of this. Where it's not enough, well written and simple policies will often provide adequate guidance. Where that's not sufficient, one may need to add specific procedures. Install checkpoints, logs, controls, only when they are really needed to gain control of a tricky situation.

Have clear lines of accountability. Accountability can only result when there is authority, responsibility, and adequate resources to get the job done.

Utilize a small number of simple metrics, linked to mission, goals, and objectives. Communicate the results, and take corrective actions, if warranted.

25. Use "discontinuous thinking" techniques

Some people would have you believe that inductive, rational thinking is the best way to reengineer a process. It ain't necessarily so. Alfred Nobel invented dynamite, which funded the Nobel Prize, mostly by accident. Federal Express was based on an idea to transfer Federal bank funds overnight. Brainstorming sessions may take half-baked or unrelated ideas and transform them into powerful, creative change concepts.

Use customers, consultants, outsiders, games, your spouse, whatever will help generate ideas that break the confines of the existing approach.

26. Insiders lead, outsiders augment

Use outsiders, such as consultants and educators, to teach your people, provide temporary reinforcement, and skills needed only sporadically. Build the core of leadership and ownership internally when permanent resources are required. Think of outsiders as "jumper cables."

27. Small teams, but with a "guiding hand"

The ideal team size seems to be 3-8. More is unwieldy - a "committee", with fewer, it's harder to attain critical mass. If you need others to help gain consensus, provide technical advice, etc., bring them in on an as needed basis, as "consultants". For example, if you're reengineering the purchase requisitioning process, don't have all 117 people who write, process, and approve these on the design team. Assemble a small team of the best and brightest. Have them consult some of the others, and ultimately either review or provide write-ups of the proposed changes to the others for advice and consent.

Don't assume that the teams will be self managing, especially if they don't have a track record of doing so. At a minimum, even very good teams benefit from help with key parameters, such as mission, objectives, metrics. Less competent teams may need help with their own process of accomplishing things, as well as technical subject matter assistance. Seeding teams with well-trained team players is helpful.

28. Develop common processes, where it makes sense. At a minimum, come up with common data attributes, macro processes, data exchange conventions, etc.

29. Bias towards "vanilla" approaches wherever practical

Don't reinvent the wheel. Use packaged software, and standardized approaches.

30. Leverage investment, people, resources

Leveraging means doing more with less. Don't invest when you can use: consigned inventories, well-planned automation, human resource development, education, virtual corporations, cooperative resources, multi-skilled people, contractors, OPM (Other Peoples' Money), OPI (Other Peoples' Ideas), licensed technology and methodologies.

31. Set ambitious "stretch" goals. Don't worry if they are missed. Worry about how much improvement is made

Many organizations intimidate their people into developing overly conservative goals, reducing the perceived probability of failure. Try to remove the fear of failure (easier said than done), and encourage employees to shoot for the moon. Then, help them get the resources they need to achieve these goals, encourage controlled, conscious risk-taking, reward success, and console honest failures that occur as a result of trying hard. It's usually better to achieve half of a 50% improvement goal than all of a 10% goal.

32. Project leaders should lead, not make all the decisions

The ideal project leader is one who can formulate and communicate a mission with inspiration, provide tools that team members need, participate with team members, identify and target opportunities and problems for action.

33. Avoid "Paralysis by Analysis." You'll never have all the facts

One of our associates was leading an inventory reduction program for a client. Some of their employees lamented the fact that up to half of the items to be tracked might lack adequate decision data, so that they felt they could not proceed. He said, "then work on the other half!" We'd still be waiting for all of the data to be right before making a decision if we'd hesitated. Instead, improvements are being made daily.

34. Don't use just functional organizations to define processes- they tend to replicate existing paradigms

Don't tolerate having processes designed to fit the current organization structure, or even specific people. Use cross-functional teams, with outsiders, internal and external process customers and suppliers.

35. Phase implementation to reduce risk and optimize rate of benefit gains

Full reengineering of a company may take much time. Most companies can't/won't wait for the pot of gold at the end of the rainbow, so it is necessary to provide payback at regular intervals, preferably starting soon. Create a phased implementation plan allowing the overall effort to self-fund itself before completion, if possible. Individual processes may have early due dates.

36. Use cellular and self-directed work teams

Get away from functional organization. Organize for processes. Cells are usually designed to handle an entire process, product, or even product line. Set up the organization to serve the customer, mission, product, process - in that order.

37. Avoid building a new bureaucracy/theocracy of Reengineering high priests/ priestesses

It seems like it's only a matter of time after a new concept, such as TQM, MIS, etc., comes along, before a corps of arrogant technocrats materializes, spouting acronyms, rules, regulations, forms, and methodologies. Reengineering is proving to be no exception to this. Don't let them gain a foothold. Make sure BPR stays with the people, by holding them accountable, organizing accordingly, and providing needed resources.

38. Use flow diagrams, dictionaries, business rules, to define system—avoid lengthy prose and technical documentation.

Define your system with simple statements, pictorial charts, tables, and where necessary, algorithms. If these can't be used for training purposes, consider tearing them up and starting over, until you can. People should be able to use them to help perform their jobs.

39. Maintain master running issues status lists

Issues really drive a BPR project. Track all suggestions, disputes, problems, guidance from management. Keep them on "issues lists." Categorize, group and prioritize them. Develop/solicit suggested approaches to these. Use these lists to guide the BPR project, and to track resolution and implementation.

40. New process designs will win by default if not contested by a set deadline.

A corporate, bureaucratic approval process moving at a snail's pace swallows up ideas, innovation and enthusiasm. Consider radical changes to yours. Use the "book club trick." Some book clubs will automatically send you books and bill you for them, unless you object or specify different books.

Your company might use this idea too. Publish suggested approaches, maybe as part of the issues list. If nobody objects or comes up with better ideas, the suggestions are automatically assigned to be developed and implemented.

41. effectively, a long way. But, if you're ten years behind, Kaizen won't even maintain the same gap. Stronger medicine is needed. Business Process Reengineering can be such a tonic, to allow huge leaps forward, and can be used in conjunction with Kaizen. Even if you're not ten years behind, maybe BPR can be a way to get ten years ahead.

How could one suddenly leapfrog another company to become more successful? … by making accelerator pedals instead of buggy whips. By doing something not just better, but truly different.

6. Challenge existing approach

Start out with an assumption in the back of your mind that the old way can be improved enormously—the odds are with you. Allow yourself to be proven wrong in some areas, but don't count on it. This forces more critical thinking. Compare the results of the current process to your ideal mission statement and note the differences. Then brainstorm how it can be improved significantly.

It's hard to get people to challenge existing approaches, unless you:

• Remove possible threats to them for doing so. This can best be done by demonstrating that company people can do it and survive. Ensure that people are rewarded, not punished for making improvements. One company encountered was in the habit of laying off team members after improvements were made. A real motivator.
• Expose teams to alternative models for doing business. This can be accomplished through education, site visits, reading, participation in professional societies, and group discussions.
• Assign leadership or lead the charge yourself—set the example by challenging the status quo and soliciting better ideas. Encourage others to do this as well.

7. Use benchmarking, get ideas from other industries

No need to be totally original in your thinking. Find out what "best practices" are in your and other industries with transferable concepts. Possibly even collaborate with other companies in developing better processes (void where prohibited by law).

8. Define product/process relationships, avoid functional "silos"

Try to disregard the existing organization structure when developing the ideal process. Look at the objectives that need to be accomplished, the processes that are needed to support it, and finally, at the resources (including organization) needed to accomplish them.

9. Set a hierarchy of: customer, product, process, function, activity

The chart below depicts some important relationships:

Objectives

10. Compress time

Faster is almost always better, if it's done right. More speed means more cycles, which means more output per unit time, faster turnaround, which usually improves service and reduces costs. Simply trying to speed up the existing process, however, might actually increase costs, and cause quality problems. This is why "old school" people usually tell you that it will cost more, hurt other priorities, or reduce quality if your request to do something faster is granted.

11. Eliminate bottlenecks

Find the slowest activity in a process. Speed it up. This speeds up the entire process and is usually the cheapest way to do it.

12. Reduce number of steps, complexity, levels, people

The more moving parts that anything has – a machine, system, process – the more it costs, the more that can go wrong, and the longer it takes. Reduce number of steps, operations, people, parts, and improve performance.

13. Reduce defects

Most processes take much longer and cost more due to defects and exception handling. Defects are the worst form of waste. They usually force more expensive exception activities to correct them, slow down cycle times, rob capacity, and force increased capital investment (for inventory, space, equipment, working capital). It has been said that defects cause 5 to 10 times their apparent costs.

14. Increase flexibility

Being adaptable to change enables introduction of new products, services, processes, schedules. Try to envision the parameters of possible change when designing the process. Increase flexibility by using adaptable people, training them, and designing processes to accommodate future change.

Philosophies

15. Empower people, but with strong leadership, clear mission & beliefs

Empower doesn't mean to abdicate management leadership, but to provide to employees the direction, skills, authority, and tools they need to accept as much delegated responsibility as possible. However, even in this era of oncoming "self directed work teams", there is still a very great need for leadership. A lot of it needs to come from management, as well as other team members. One cannot overemphasize the value of enthusiastic, strong, informed leadership to energize a reengineering effort. People tend to respond quite positively to this.

16. Make education a way of life

There are just so many new things to learn social, technical, philosophical, specific details, that a significant portion of employee time needs to be dedicated to education and training. This is not just an expense if used wisely, but an excellent investment in the company's future. There needs to be an overall education plan. Employees need to be tasked with education objectives, and tested for improvements. When you send someone to a 3 day seminar on set-up reduction, jointly develop objectives, in advance, for this investment in time and money. This is not a 3 day paid vacation. Debrief the employee afterward- make sure the company gets a return on this investment. If not, learn why. Employees who consistently fail to deliver results here may cease to be candidates for upcoming educational opportunities.

17. A "System" consists of missions, leadership, goals, objectives, metrics, policies, procedures, education, training, organization, personnel, tools—not primarily a computer project

Address all of the system ingredients shown above to reengineer a business system, and its processes.

18. "Ownership" is important

It's better to have even a mediocre approach that has consensus and support than the best idea in the world that no one likes or understands. The first will at least work in a mediocre fashion.

Build ownership by involving people in the new approach so that their intelligence and egos become intertwined with it.

Approaches

19. Focus on eliminating non-value added activities/ assets/costs

Eliminate waste in the company. Cut back on non-productive assets. Use Shingo's "7 Wastes of Production" as a tool to help identify waste. Waste is anything that is not absolutely essential to design, produce, and get the product/service to the customer. Employ some of the various analysis techniques to help identify waste and weigh improvement priorities.

20. Use simple approaches, not complex sophistication

There are already dozens of new, complex methodologies, software packages, etc., purporting to be "magic bullets" to reengineer your company. Most of them are too complicated, and will generate more money for their purveyors than for you. Don't spend more time learning and wrestling with the tools than solving business problems. Be especially wary of complex matrices and mathematical models. Don't get much more complex than a moderate Quality Function Deployment (QFD) matrix.

The key is to understand the requirements of the process, and what is wrong with the existing process, and what tools/resources are available/needed to do the job. Then, design/improve the new/revised process.

21. Decentralize, unless there are compelling reasons to do otherwise

Delegate downward and move resources to forward positions where they might be used to more rapidly and flexibly serve the customer. Move back and consolidate where there are compelling reasons to do so because of economies of scale, critical resources. Make sure this doesn't compromise service, quality, or flexibility.

22. Streamline, Simplify, automate, integrate, in that order

Don't spend big bucks on automation until you know what it is you'll be automating, and there is a simplified approach for running the business. Often, simplification of the existing system can pay for some or all of the subsequent automation. Scope out the entire effort before automating anything. Automation and integration should be a logical culmination of a well thought-out plan.

23. Employ the conference room pilot approach

In spite of everyone's best efforts, processes may still be complex. Therefore, it is extremely important to have tools for testing, refining, and training to ensure best results, with minimum risk. The conference room pilot approach is such a tool, and works by running off-line tests of the system, manually, and with proposed operating computer/software systems, prior to live implementation. Mistakes are made, and education/training occur, in the conference room, not in the heat of battle in the office or on the factory floor. Project leadership uses mission statements, objectives, and issues lists to design test scenarios, and then leads the group through these for training, debugging and problem solving purposes.

Techniques

24. Selectively implement policies, procedures, checkpoints, controls, accountability, metrics

Don't generate any more rules and paperwork than are needed. Well educated people with clear missions need less of this. Where it's not enough, well written and simple policies will often provide adequate guidance. Where that's not sufficient, one may need to add specific procedures. Install checkpoints, logs, controls, only when they are really needed to gain control of a tricky situation.

Have clear lines of accountability. Accountability can only result when there is authority, responsibility, and adequate resources to get the job done.

Utilize a small number of simple metrics, linked to mission, goals, and objectives. Communicate the results, and take corrective actions, if warranted.

25. Use "discontinuous thinking" techniques

Some people would have you believe that inductive, rational thinking is the best way to reengineer a process. It ain't necessarily so. Alfred Nobel invented dynamite, which funded the Nobel Prize, mostly by accident. Federal Express was based on an idea to transfer Federal bank funds overnight. Brainstorming sessions may take half-baked or unrelated ideas and transform them into powerful, creative change concepts.

Use customers, consultants, outsiders, games, your spouse, whatever will help generate ideas that break the confines of the existing approach.

26. Insiders lead, outsiders augment

Use outsiders, such as consultants and educators, to teach your people, provide temporary reinforcement, and skills needed only sporadically. Build the core of leadership and ownership internally when permanent resources are required. Think of outsiders as "jumper cables."

27. Small teams, but with a "guiding hand"

The ideal team size seems to be 3-8. More is unwieldy - a "committee", with fewer, it's harder to attain critical mass. If you need others to help gain consensus, provide technical advice, etc., bring them in on an as needed basis, as "consultants". For example, if you're reengineering the purchase requisitioning process, don't have all 117 people who write, process, and approve these on the design team. Assemble a small team of the best and brightest. Have them consult some of the others, and ultimately either review or provide write-ups of the proposed changes to the others for advice and consent.

Don't assume that the teams will be self managing, especially if they don't have a track record of doing so. At a minimum, even very good teams benefit from help with key parameters, such as mission, objectives, metrics. Less competent teams may need help with their own process of accomplishing things, as well as technical subject matter assistance. Seeding teams with well-trained team players is helpful.

28. Develop common processes, where it makes sense. At a minimum, come up with common data attributes, macro processes, data exchange conventions, etc.

29. Bias towards "vanilla" approaches wherever practical

Don't reinvent the wheel. Use packaged software, and standardized approaches.

30. Leverage investment, people, resources

Leveraging means doing more with less. Don't invest when you can use: consigned inventories, well-planned automation, human resource development, education, virtual corporations, cooperative resources, multi-skilled people, contractors, OPM (Other Peoples' Money), OPI (Other Peoples' Ideas), licensed technology and methodologies.

31. Set ambitious "stretch" goals. Don't worry if they are missed. Worry about how much improvement is made

Many organizations intimidate their people into developing overly conservative goals, reducing the perceived probability of failure. Try to remove the fear of failure (easier said than done), and encourage employees to shoot for the moon. Then, help them get the resources they need to achieve these goals, encourage controlled, conscious risk-taking, reward success, and console honest failures that occur as a result of trying hard. It's usually better to achieve half of a 50% improvement goal than all of a 10% goal.

32. Project leaders should lead, not make all the decisions

The ideal project leader is one who can formulate and communicate a mission with inspiration, provide tools that team members need, participate with team members, identify and target opportunities and problems for action.

33. Avoid "Paralysis by Analysis." You'll never have all the facts

One of our associates was leading an inventory reduction program for a client. Some of their employees lamented the fact that up to half of the items to be tracked might lack adequate decision data, so that they felt they could not proceed. He said, "then work on the other half!" We'd still be waiting for all of the data to be right before making a decision if we'd hesitated. Instead, improvements are being made daily.

34. Don't use just functional organizations to define processes- they tend to replicate existing paradigms

Don't tolerate having processes designed to fit the current organization structure, or even specific people. Use cross-functional teams, with outsiders, internal and external process customers and suppliers.

35. Phase implementation to reduce risk and optimize rate of benefit gains

Full reengineering of a company may take much time. Most companies can't/won't wait for the pot of gold at the end of the rainbow, so it is necessary to provide payback at regular intervals, preferably starting soon. Create a phased implementation plan allowing the overall effort to self-fund itself before completion, if possible. Individual processes may have early due dates.

36. Use cellular and self-directed work teams

Get away from functional organization. Organize for processes. Cells are usually designed to handle an entire process, product, or even product line. Set up the organization to serve the customer, mission, product, process - in that order.

37. Avoid building a new bureaucracy/theocracy of Reengineering high priests/ priestesses

It seems like it's only a matter of time after a new concept, such as TQM, MIS, etc., comes along, before a corps of arrogant technocrats materializes, spouting acronyms, rules, regulations, forms, and methodologies. Reengineering is proving to be no exception to this. Don't let them gain a foothold. Make sure BPR stays with the people, by holding them accountable, organizing accordingly, and providing needed resources.

38. Use flow diagrams, dictionaries, business rules, to define system—avoid lengthy prose and technical documentation.

Define your system with simple statements, pictorial charts, tables, and where necessary, algorithms. If these can't be used for training purposes, consider tearing them up and starting over, until you can. People should be able to use them to help perform their jobs.

39. Maintain master running issues status lists

Issues really drive a BPR project. Track all suggestions, disputes, problems, guidance from management. Keep them on "issues lists." Categorize, group and prioritize them. Develop/solicit suggested approaches to these. Use these lists to guide the BPR project, and to track resolution and implementation.

40. New process designs will win by default if not contested by a set deadline.

A corporate, bureaucratic approval process moving at a snail's pace swallows up ideas, innovation and enthusiasm. Consider radical changes to yours. Use the "book club trick." Some book clubs will automatically send you books and bill you for them, unless you object or specify different books.

Your company might use this idea too. Publish suggested approaches, maybe as part of the issues list. If nobody objects or comes up with better ideas, the suggestions are automatically assigned to be developed and implemented.

41. leadership, clear mission & beliefs

Empower doesn't mean to abdicate management leadership, but to provide to employees the direction, skills, authority, and tools they need to accept as much delegated responsibility as possible. However, even in this era of oncoming "self directed work teams", there is still a very great need for leadership. A lot of it needs to come from management, as well as other team members. One cannot overemphasize the value of enthusiastic, strong, informed leadership to energize a reengineering effort. People tend to respond quite positively to this.

16. Make education a way of life

There are just so many new things to learn social, technical, philosophical, specific details, that a significant portion of employee time needs to be dedicated to education and training. This is not just an expense if used wisely, but an excellent investment in the company's future. There needs to be an overall education plan. Employees need to be tasked with education objectives, and tested for improvements. When you send someone to a 3 day seminar on set-up reduction, jointly develop objectives, in advance, for this investment in time and money. This is not a 3 day paid vacation. Debrief the employee afterward- make sure the company gets a return on this investment. If not, learn why. Employees who consistently fail to deliver results here may cease to be candidates for upcoming educational opportunities.

17. A "System" consists of missions, leadership, goals, objectives, metrics, policies, procedures, education, training, organization, personnel, tools—not primarily a computer project

Address all of the system ingredients shown above to reengineer a business system, and its processes.

18. "Ownership" is important

It's better to have even a mediocre approach that has consensus and support than the best idea in the world that no one likes or understands. The first will at least work in a mediocre fashion.

Build ownership by involving people in the new approach so that their intelligence and egos become intertwined with it.

Approaches

19. Focus on eliminating non-value added activities/ assets/costs

Eliminate waste in the company. Cut back on non-productive assets. Use Shingo's "7 Wastes of Production" as a tool to help identify waste. Waste is anything that is not absolutely essential to design, produce, and get the product/service to the customer. Employ some of the various analysis techniques to help identify waste and weigh improvement priorities.

20. Use simple approaches, not complex sophistication

There are already dozens of new, complex methodologies, software packages, etc., purporting to be "magic bullets" to reengineer your company. Most of them are too complicated, and will generate more money for their purveyors than for you. Don't spend more time learning and wrestling with the tools than solving business problems. Be especially wary of complex matrices and mathematical models. Don't get much more complex than a moderate Quality Function Deployment (QFD) matrix.

The key is to understand the requirements of the process, and what is wrong with the existing process, and what tools/resources are available/needed to do the job. Then, design/improve the new/revised process.

21. Decentralize, unless there are compelling reasons to do otherwise

Delegate downward and move resources to forward positions where they might be used to more rapidly and flexibly serve the customer. Move back and consolidate where there are compelling reasons to do so because of economies of scale, critical resources. Make sure this doesn't compromise service, quality, or flexibility.

22. Streamline, Simplify, automate, integrate, in that order

Don't spend big bucks on automation until you know what it is you'll be automating, and there is a simplified approach for running the business. Often, simplification of the existing system can pay for some or all of the subsequent automation. Scope out the entire effort before automating anything. Automation and integration should be a logical culmination of a well thought-out plan.

23. Employ the conference room pilot approach

In spite of everyone's best efforts, processes may still be complex. Therefore, it is extremely important to have tools for testing, refining, and training to ensure best results, with minimum risk. The conference room pilot approach is such a tool, and works by running off-line tests of the system, manually, and with proposed operating computer/software systems, prior to live implementation. Mistakes are made, and education/training occur, in the conference room, not in the heat of battle in the office or on the factory floor. Project leadership uses mission statements, objectives, and issues lists to design test scenarios, and then leads the group through these for training, debugging and problem solving purposes.

Techniques

24. Selectively implement policies, procedures, checkpoints, controls, accountability, metrics

Don't generate any more rules and paperwork than are needed. Well educated people with clear missions need less of this. Where it's not enough, well written and simple policies will often provide adequate guidance. Where that's not sufficient, one may need to add specific procedures. Install checkpoints, logs, controls, only when they are really needed to gain control of a tricky situation.

Have clear lines of accountability. Accountability can only result when there is authority, responsibility, and adequate resources to get the job done.

Utilize a small number of simple metrics, linked to mission, goals, and objectives. Communicate the results, and take corrective actions, if warranted.

25. Use "discontinuous thinking" techniques

Some people would have you believe that inductive, rational thinking is the best way to reengineer a process. It ain't necessarily so. Alfred Nobel invented dynamite, which funded the Nobel Prize, mostly by accident. Federal Express was based on an idea to transfer Federal bank funds overnight. Brainstorming sessions may take half-baked or unrelated ideas and transform them into powerful, creative change concepts.

Use customers, consultants, outsiders, games, your spouse, whatever will help generate ideas that break the confines of the existing approach.

26. Insiders lead, outsiders augment

Use outsiders, such as consultants and educators, to teach your people, provide temporary reinforcement, and skills needed only sporadically. Build the core of leadership and ownership internally when permanent resources are required. Think of outsiders as "jumper cables."

27. Small teams, but with a "guiding hand"

The ideal team size seems to be 3-8. More is unwieldy - a "committee", with fewer, it's harder to attain critical mass. If you need others to help gain consensus, provide technical advice, etc., bring them in on an as needed basis, as "consultants". For example, if you're reengineering the purchase requisitioning process, don't have all 117 people who write, process, and approve these on the design team. Assemble a small team of the best and brightest. Have them consult some of the others, and ultimately either review or provide write-ups of the proposed changes to the others for advice and consent.

Don't assume that the teams will be self managing, especially if they don't have a track record of doing so. At a minimum, even very good teams benefit from help with key parameters, such as mission, objectives, metrics. Less competent teams may need help with their own process of accomplishing things, as well as technical subject matter assistance. Seeding teams with well-trained team players is helpful.

28. Develop common processes, where it makes sense. At a minimum, come up with common data attributes, macro processes, data exchange conventions, etc.

29. Bias towards "vanilla" approaches wherever practical

Don't reinvent the wheel. Use packaged software, and standardized approaches.

30. Leverage investment, people, resources

Leveraging means doing more with less. Don't invest when you can use: consigned inventories, well-planned automation, human resource development, education, virtual corporations, cooperative resources, multi-skilled people, contractors, OPM (Other Peoples' Money), OPI (Other Peoples' Ideas), licensed technology and methodologies.

31. Set ambitious "stretch" goals. Don't worry if they are missed. Worry about how much improvement is made

Many organizations intimidate their people into developing overly conservative goals, reducing the perceived probability of failure. Try to remove the fear of failure (easier said than done), and encourage employees to shoot for the moon. Then, help them get the resources they need to achieve these goals, encourage controlled, conscious risk-taking, reward success, and console honest failures that occur as a result of trying hard. It's usually better to achieve half of a 50% improvement goal than all of a 10% goal.

32. Project leaders should lead, not make all the decisions

The ideal project leader is one who can formulate and communicate a mission with inspiration, provide tools that team members need, participate with team members, identify and target opportunities and problems for action.

33. Avoid "Paralysis by Analysis." You'll never have all the facts

One of our associates was leading an inventory reduction program for a client. Some of their employees lamented the fact that up to half of the items to be tracked might lack adequate decision data, so that they felt they could not proceed. He said, "then work on the other half!" We'd still be waiting for all of the data to be right before making a decision if we'd hesitated. Instead, improvements are being made daily.

34. Don't use just functional organizations to define processes- they tend to replicate existing paradigms

Don't tolerate having processes designed to fit the current organization structure, or even specific people. Use cross-functional teams, with outsiders, internal and external process customers and suppliers.

35. Phase implementation to reduce risk and optimize rate of benefit gains

Full reengineering of a company may take much time. Most companies can't/won't wait for the pot of gold at the end of the rainbow, so it is necessary to provide payback at regular intervals, preferably starting soon. Create a phased implementation plan allowing the overall effort to self-fund itself before completion, if possible. Individual processes may have early due dates.

36. Use cellular and self-directed work teams

Get away from functional organization. Organize for processes. Cells are usually designed to handle an entire process, product, or even product line. Set up the organization to serve the customer, mission, product, process - in that order.

37. Avoid building a new bureaucracy/theocracy of Reengineering high priests/ priestesses

It seems like it's only a matter of time after a new concept, such as TQM, MIS, etc., comes along, before a corps of arrogant technocrats materializes, spouting acronyms, rules, regulations, forms, and methodologies. Reengineering is proving to be no exception to this. Don't let them gain a foothold. Make sure BPR stays with the people, by holding them accountable, organizing accordingly, and providing needed resources.

38. Use flow diagrams, dictionaries, business rules, to define system—avoid lengthy prose and technical documentation.

Define your system with simple statements, pictorial charts, tables, and where necessary, algorithms. If these can't be used for training purposes, consider tearing them up and starting over, until you can. People should be able to use them to help perform their jobs.

39. Maintain master running issues status lists

Issues really drive a BPR project. Track all suggestions, disputes, problems, guidance from management. Keep them on "issues lists." Categorize, group and prioritize them. Develop/solicit suggested approaches to these. Use these lists to guide the BPR project, and to track resolution and implementation.

40. New process designs will win by default if not contested by a set deadline.

A corporate, bureaucratic approval process moving at a snail's pace swallows up ideas, innovation and enthusiasm. Consider radical changes to yours. Use the "book club trick." Some book clubs will automatically send you books and bill you for them, unless you object or specify different books.

Your company might use this idea too. Publish suggested approaches, maybe as part of the issues list. If nobody objects or comes up with better ideas, the suggestions are automatically assigned to be developed and implemented.

41.ore, it is extremely important to have tools for testing, refining, and training to ensure best results, with minimum risk. The conference room pilot approach is such a tool, and works by running off-line tests of the system, manually, and with proposed operating computer/software systems, prior to live implementation. Mistakes are made, and education/training occur, in the conference room, not in the heat of battle in the office or on the factory floor. Project leadership uses mission statements, objectives, and issues lists to design test scenarios, and then leads the group through these for training, debugging and problem solving purposes.

Techniques

24. Selectively implement policies, procedures, checkpoints, controls, accountability, metrics

Don't generate any more rules and paperwork than are needed. Well educated people with clear missions need less of this. Where it's not enough, well written and simple policies will often provide adequate guidance. Where that's not sufficient, one may need to add specific procedures. Install checkpoints, logs, controls, only when they are really needed to gain control of a tricky situation.

Have clear lines of accountability. Accountability can only result when there is authority, responsibility, and adequate resources to get the job done.

Utilize a small number of simple metrics, linked to mission, goals, and objectives. Communicate the results, and take corrective actions, if warranted.

25. Use "discontinuous thinking" techniques

Some people would have you believe that inductive, rational thinking is the best way to reengineer a process. It ain't necessarily so. Alfred Nobel invented dynamite, which funded the Nobel Prize, mostly by accident. Federal Express was based on an idea to transfer Federal bank funds overnight. Brainstorming sessions may take half-baked or unrelated ideas and transform them into powerful, creative change concepts.

Use customers, consultants, outsiders, games, your spouse, whatever will help generate ideas that break the confines of the existing approach.

26. Insiders lead, outsiders augment

Use outsiders, such as consultants and educators, to teach your people, provide temporary reinforcement, and skills needed only sporadically. Build the core of leadership and ownership internally when permanent resources are required. Think of outsiders as "jumper cables."

27. Small teams, but with a "guiding hand"

The ideal team size seems to be 3-8. More is unwieldy - a "committee", with fewer, it's harder to attain critical mass. If you need others to help gain consensus, provide technical advice, etc., bring them in on an as needed basis, as "consultants". For example, if you're reengineering the purchase requisitioning process, don't have all 117 people who write, process, and approve these on the design team. Assemble a small team of the best and brightest. Have them consult some of the others, and ultimately either review or provide write-ups of the proposed changes to the others for advice and consent.

Don't assume that the teams will be self managing, especially if they don't have a track record of doing so. At a minimum, even very good teams benefit from help with key parameters, such as mission, objectives, metrics. Less competent teams may need help with their own process of accomplishing things, as well as technical subject matter assistance. Seeding teams with well-trained team players is helpful.

28. Develop common processes, where it makes sense. At a minimum, come up with common data attributes, macro processes, data exchange conventions, etc.

29. Bias towards "vanilla" approaches wherever practical

Don't reinvent the wheel. Use packaged software, and standardized approaches.

30. Leverage investment, people, resources

Leveraging means doing more with less. Don't invest when you can use: consigned inventories, well-planned automation, human resource development, education, virtual corporations, cooperative resources, multi-skilled people, contractors, OPM (Other Peoples' Money), OPI (Other Peoples' Ideas), licensed technology and methodologies.

31. Set ambitious "stretch" goals. Don't worry if they are missed. Worry about how much improvement is made

Many organizations intimidate their people into developing overly conservative goals, reducing the perceived probability of failure. Try to remove the fear of failure (easier said than done), and encourage employees to shoot for the moon. Then, help them get the resources they need to achieve these goals, encourage controlled, conscious risk-taking, reward success, and console honest failures that occur as a result of trying hard. It's usually better to achieve half of a 50% improvement goal than all of a 10% goal.

32. Project leaders should lead, not make all the decisions

The ideal project leader is one who can formulate and communicate a mission with inspiration, provide tools that team members need, participate with team members, identify and target opportunities and problems for action.

33. Avoid "Paralysis by Analysis." You'll never have all the facts

One of our associates was leading an inventory reduction program for a client. Some of their employees lamented the fact that up to half of the items to be tracked might lack adequate decision data, so that they felt they could not proceed. He said, "then work on the other half!" We'd still be waiting for all of the data to be right before making a decision if we'd hesitated. Instead, improvements are being made daily.

34. Don't use just functional organizations to define processes- they tend to replicate existing paradigms

Don't tolerate having processes designed to fit the current organization structure, or even specific people. Use cross-functional teams, with outsiders, internal and external process customers and suppliers.

35. Phase implementation to reduce risk and optimize rate of benefit gains

Full reengineering of a company may take much time. Most companies can't/won't wait for the pot of gold at the end of the rainbow, so it is necessary to provide payback at regular intervals, preferably starting soon. Create a phased implementation plan allowing the overall effort to self-fund itself before completion, if possible. Individual processes may have early due dates.

36. Use cellular and self-directed work teams

Get away from functional organization. Organize for processes. Cells are usually designed to handle an entire process, product, or even product line. Set up the organization to serve the customer, mission, product, process - in that order.

37. Avoid building a new bureaucracy/theocracy of Reengineering high priests/ priestesses

It seems like it's only a matter of time after a new concept, such as TQM, MIS, etc., comes along, before a corps of arrogant technocrats materializes, spouting acronyms, rules, regulations, forms, and methodologies. Reengineering is proving to be no exception to this. Don't let them gain a foothold. Make sure BPR stays with the people, by holding them accountable, organizing accordingly, and providing needed resources.

38. Use flow diagrams, dictionaries, business rules, to define system—avoid lengthy prose and technical documentation.

Define your system with simple statements, pictorial charts, tables, and where necessary, algorithms. If these can't be used for training purposes, consider tearing them up and starting over, until you can. People should be able to use them to help perform their jobs.

39. Maintain master running issues status lists

Issues really drive a BPR project. Track all suggestions, disputes, problems, guidance from management. Keep them on "issues lists." Categorize, group and prioritize them. Develop/solicit suggested approaches to these. Use these lists to guide the BPR project, and to track resolution and implementation.

40. New process designs will win by default if not contested by a set deadline.

A corporate, bureaucratic approval process moving at a snail's pace swallows up ideas, innovation and enthusiasm. Consider radical changes to yours. Use the "book club trick." Some book clubs will automatically send you books and bill you for them, unless you object or specify different books.

Your company might use this idea too. Publish suggested approaches, maybe as part of the issues list. If nobody objects or comes up with better ideas, the suggestions are automatically assigned to be developed and implemented.

41.ny organizations intimidate their people into developing overly conservative goals, reducing the perceived probability of failure. Try to remove the fear of failure (easier said than done), and encourage employees to shoot for the moon. Then, help them get the resources they need to achieve these goals, encourage controlled, conscious risk-taking, reward success, and console honest failures that occur as a result of trying hard. It's usually better to achieve half of a 50% improvement goal than all of a 10% goal.

32. Project leaders should lead, not make all the decisions

The ideal project leader is one who can formulate and communicate a mission with inspiration, provide tools that team members need, participate with team members, identify and target opportunities and problems for action.

33. Avoid "Paralysis by Analysis." You'll never have all the facts

One of our associates was leading an inventory reduction program for a client. Some of their employees lamented the fact that up to half of the items to be tracked might lack adequate decision data, so that they felt they could not proceed. He said, "then work on the other half!" We'd still be waiting for all of the data to be right before making a decision if we'd hesitated. Instead, improvements are being made daily.

34. Don't use just functional organizations to define processes- they tend to replicate existing paradigms

Don't tolerate having processes designed to fit the current organization structure, or even specific people. Use cross-functional teams, with outsiders, internal and external process customers and suppliers.

35. Phase implementation to reduce risk and optimize rate of benefit gains

Full reengineering of a company may take much time. Most companies can't/won't wait for the pot of gold at the end of the rainbow, so it is necessary to provide payback at regular intervals, preferably starting soon. Create a phased implementation plan allowing the overall effort to self-fund itself before completion, if possible. Individual processes may have early due dates.

36. Use cellular and self-directed work teams

Get away from functional organization. Organize for processes. Cells are usually designed to handle an entire process, product, or even product line. Set up the organization to serve the customer, mission, product, process - in that order.

37. Avoid building a new bureaucracy/theocracy of Reengineering high priests/ priestesses

It seems like it's only a matter of time after a new concept, such as TQM, MIS, etc., comes along, before a corps of arrogant technocrats materializes, spouting acronyms, rules, regulations, forms, and methodologies. Reengineering is proving to be no exception to this. Don't let them gain a foothold. Make sure BPR stays with the people, by holding them accountable, organizing accordingly, and providing needed resources.

38. Use flow diagrams, dictionaries, business rules, to define system—avoid lengthy prose and technical documentation.

Define your system with simple statements, pictorial charts, tables, and where necessary, algorithms. If these can't be used for training purposes, consider tearing them up and starting over, until you can. People should be able to use them to help perform their jobs.

39. Maintain master running issues status lists

Issues really drive a BPR project. Track all suggestions, disputes, problems, guidance from management. Keep them on "issues lists." Categorize, group and prioritize them. Develop/solicit suggested approaches to these. Use these lists to guide the BPR project, and to track resolution and implementation.

40. New process designs will win by default if not contested by a set deadline.

A corporate, bureaucratic approval process moving at a snail's pace swallows up ideas, innovation and enthusiasm. Consider radical changes to yours. Use the "book club trick." Some book clubs will automatically send you books and bill you for them, unless you object or specify different books.

Your company might use this idea too. Publish suggested approaches, maybe as part of the issues list. If nobody objects or comes up with better ideas, the suggestions are automatically assigned to be developed and implemented.

41. Employ the living flow chart approach to model systems

We have pondered the best approaches for documenting as-is and to-be systems configurations, and developed the following conclusions:

• KIS (Keep It Simple). The more complex methodologies confuse and intimidate the very people you most need to involve. The tools can bog down the effort, and rapidly result in diminishing returns.
• People are inhibited from making changes to the more complex models, because of the sheer amount of work of constructing and maintaining the more complex modeling tools.
• Simple methods are more likely to be utilized and to bear fruit more rapidly.
• People think better in chart or pictorial format. Chart the process using actual documents or likenesses of forms, screens, reports, etc. Record issues, defect occurrences, delays, contradictions, cycle times, responsibilities, procedure/policy references, right on the charts.
• Go down to the level that people understand the process.
• Start with company level and process summary level charts. Do a mission statement for each process and sub-process before you get into the details.
• Use the charts as a diagnostic and design tool. Identify and correct non-value-added activities, bottlenecks, defect and delay producing points, organizational constraints, gaps, overlaps, etc.

42. Deliver more than you promise.

42 out of 40 hints promised ain't bad.

This article is also available on our website: PROACTION – Generating Best Practices. It is an excerpt of a paper originally written by George Miller, Founder of PROACTION. It has been modified and updated by Paul Deis, PROACTION CEO.