Because of the drastic, large-scale change that they create, business process reengineering (BPR) projects are fraught with risk and often end in failure. To help IS managers control these projects, this column identifies and analyzes common risks of BPR.
BUSINESS PROCESS REENGINEERING (BPR) has general acceptance in the business world. This acceptance is because BPR promises to improve the competitive position of the marketplace, offer service and process breakthroughs, provide customer satisfaction, provide greater understanding of the business, renew the organization, and streamline processes.
At the same time, skepticism about those promises has arisen, and for good reason. According to Michael Hammer, BPR guru and coauthor of several best-selling books on the topic, success and failure rates for BPR projects are low and high, respectively. Hammer estimates that 70 percent of all BPR projects fail.
BPR projects fail for many reasons, including having ill-defined scope and processes defined, inaccurate data and information, lack of executive commitment and sponsor-ship, limited authority to proceed, and rapidly changing technologies.
Not only is the opportunity for failure is high, it can have severe subtle and overt consequences, like augmenting resistance to change, causing political fallout (e.g., instability), disrupting existing businesses, draining resources from ongoing activities and processes, losing customer support, losing monies, losing opportunities to achieve other breakthroughs, and lowering morale.
It is quite clear a need exists to minimize the risks that confront BPR projects. Risk management is the tool for fulfilling that need.
Before discussing the specific types of risks that confront a BPR project, it is useful to have an under-standing of risk in general and risk management in particular.
Risk is the occurrence of an event that has some consequences. A vulnerability or exposure is a weakness that enables a risk to have an impact. Controls are measures that mitigate the impact of an event or stop it from having any effect. The probability of a risk is its likelihood of occurrence (e.g., 60 percent chance of happening). The impact of a risk is its degree of influence (e.g., minor, major) on the execution of a process, project, or system.
The basic idea is to put controls in place to minimize the negative consequences of an event, known as risk management.
Risk management consists of three actions:
Risk identification is identifying risks that confront a project. Risk analysis is analyzing data collected about risks, including impact and probability of occurrence. Risk control is identifying and verifying the existence of measures to lessen or prevent the impact of a risk.
Risk management for BPR projects offers several advantages. It is a proactive, rather than reactive, step for developing and implementing BPR solutions. It addresses the "hard" issues early in the project and not when they become more costly and difficult to deal with later in the life cycle. It reduces the opportunity for BPR projects to later become financial "black holes" under specific circumstances. Finally, it provides the opportunity to identify contingency plans for responding to potential scenarios.
Despite the advantages of risk management, there several reasons why it is not done. One, it is viewed as an administrative burden. Two, the understanding and skills for conducting risk management are not readily available. Finally, the information required to do risk management is not available.
There are several keys for conducting effective risk management for BPR projects. Risk management is best performed as early as possible in the life cycle. It requires relying on facts and data while simultaneously identifying assumptions. It requires isolation from political influences to maintain reliability and objectivity. Finally, it requires having people with the requisite knowledge and skills (e.g., mathematical, analytical) to conduct it.
One final caveat. Risk management is not a one-time occurrence. It must be done continuously. The reason is that risk management involves taking a snapshot in time and using it to anticipate what might happen in the future. The conditions of an environment, however, may be extremely dynamic and may challenge the validity of assumptions incorporated when managing risk. Hence, it is wise to revalidate risk management continuously throughout the life cycle of a BPR project.
For BPR projects, the risks are numerous and complex since they involve processes that transcend any particular function or group within an enterprise. BPR risks can fall into one of four categories: people, management, business, and technical.
People risks involve the people side of BPR, such as:
unproven assumptions and values
high resistance to change, internally and externally
incomplete representation on a team and executive steering committee
lack of courage by team members to question everyone and everything
lack of management commitment
lack of management consensus
people who fear to or cannot think "outside the box"
lack of people with the requisite skills
lack of stakeholder support
lack of time for team members to work on a project
too many people on a project
unclear definition of team roles and responsibilities
Management risks involve operational issues, such as:
failure to monitor and measure results of implementation
ill-defined mission and objectives
inability to define core business processes
inability to define customer's needs and values
incomplete plan for transitioning to a new process lack of customer focus
lack of realistic schedules
lack of strategic goals to guide the team
lack of time to execute the project
not empowering the project team
too narrow of a project charter
unable to perform a meaningful gap analysis
unavailability of data
Business risks involve the financial aspects of a BPR project, from analysis to implementation, such as:
failure to prepare a solid business case for the new design
incorrect or unreliable calculation of return on investment for a chosen design alternative
insufficient funds
lack of consensus over spending priorities
Technical risks involve the tools and techniques applied on a BPR project, such as:
inability to determine interrelationships among core processes
lack of access to technical expertise
lack of agreement over analysis and design tools and techniques
lack of knowledge about analysis and design tools and techniques
lack of knowledge about enabling technology
limitation of existing computing technology
not sufficiently defining and map-ping existing and proposed business processes
not using a standard, common reengineering methodology
selection of the wrong enabling technology
After identifying the risks, the next action is to determine their relative importance to one another and their respective probability of occurrence. The ranking of importance depends largely on the interests of the customer.
Three basic approaches exist for analyzing risks: quantitative, qualitative, and combination of both. Quantitative risk analysis applies mathematical calculations to determine the relative importance of each risk to the others and the respective probability of occurrence. The Monte Carlo simulation technique is an example. Qualitative risk analysis relies less on mathematical calculations and applies more judgment to determine the relative importance of each risk to the others and the respective probability of occurrence.
Heuristics, or rules of thumb, is an example. A combination of the two uses both quantitative and qualitative considerations to determine the relative importance of each risk to the others and the probability of occurrence. The precedence diagramming method, which uses an ordinal approach to determine priorities according to some criterion, is an example.
Whether using quantitative, qualitative, or a combination of approaches, the results of the analysis should look like the table displayed in Exhibit 1.
There are three categories of controls: preventive, detective, and corrective. Preventive controls mitigate or stop a threat from exploiting the vulnerabilities of a project. Detective controls disclose the occurrence of an event and preclude similar exploitation in the future. Corrective controls require addressing the impact of a threat and then establishing controls to preclude any future impacts. There are many preventive, detective, and corrective controls to apply on a BPR project, as shown in Exhibit 2.
Risk control requires understanding the environment of the BPR project to determine what controls should exist. It means looking at factors like customer support, expertise availability, funding, management commitment, market conditions, scheduling, and teaming.
With analysis complete, the next action is to identify controls that should exist to prevent, detect, or correct the impact of risks. This requires conducting interviews, performing tests, reviewing documentation, and analyzing data to determine, in fact, whether the controls do exist, are missing, or need improvement.
After identifying the controls that should exist, the next action is to verify their existence for prevention, detection, or correction.
Having a good idea of the type and nature of the risks confronting a BPR project, the next step is to strengthen or add controls. That means deciding whether to accept, avoid, adopt, or transfer risk. To accept a risk means letting it occur and taking no action. An example is allowing a schedule slide to occur. To avoid a risk is to take action to not confront a risk. An example is to not make a decision to deal with. To adopt means living with a risk and dealing with it by "working around it." An example is not working with the customer to define a process in great detail. To transfer means shifting a risk over to someone or something else. An example is allowing another BPR project to address a controversial issue rather than addressing it.
The "burden" of risk management can lighten with the availability of the right software tool. A good number of tools now operate on the microcomputer and support risk identification, analysis, and reporting or a combination. Choosing the right tool is important and, therefore, the tool should have a number of features. At a minimum, it should be user-friendly, interact with other application packages, and generate meaningful reports. Some of the more popular packages include Opera Trademark, RANK-IT Registered Trademark, and Monte Carlo for Primavera Trademark.
BPR projects need risk management. The track record proves it. Risk management must, however, be done consistently and completely to be useful. That means being willing to identify, analyze, and control risks. Only then can BPR projects have a 70 percent chance of success rather than failure.
By Ralph L. Kliem
Ralph L. Kliem is president of Practical Creative Solutions, Inc., a consulting and training firm in Redmond, Washington. He is the co-editor of the following books by Gower Publishing: The Noah Project: The Secrets of Practical Project Management; The People Side of Project Management; and Reducing Project Risk. He can be reached at 75377.2623@com-puserve.com, or by phone (
