| İlhan Kesken, PMP – Project Office Manager |
Risk Management in Business Process Management (BPM) Projects
When we hear project management, most of us think of things like a timeline, tasks, resources, target dates and so on. If you have no background in the project management discipline, risks either never make it onto your list or end up at the very bottom.
Yet surveys reveal a striking fact: of every 10 Business Process Management (BPM) projects, 7 end in failure.
This high rate alone proves that in these projects, we need to think about what not to do just as much as we focus on what to do.
Risks and Risk Management (BPM)
By the classic definition, risk expresses the variety of possible outcomes, their probability of occurring and their subjective impact. The mathematical formula behind this theory:
Risk = Probability of a gain or loss occurring (%) X Magnitude of its impact
The Project Management Institute (PMI) defines risk as
an uncertain event or condition that, if it occurs, has a positive or negative effect on a project objective.
Because risks are usually associated with negative outcomes, they are often confused with project problems. Risks are not actually problems, but it is not wrong to see them as potential problems.
Risk Management
The purpose of risk management is to reduce or neutralize potential problems and to develop and seize opportunities. Risk management structures consist of 3 main phases: identification, analysis and control.
The identification phase is carried out through brainstorming sessions by a group of experts.
Risks arise from uncertainty. That makes it hard to frame risks and characterize them fully. One way to do this is to categorize them by identifying attributes such as impact, probability, time of occurrence and overlap with other risks. The literature describes four risk response strategies:
1. Mitigation
2. Avoidance
3. Transfer
4. Acceptance
| Strategy | Definition | Examples |
| Mitigation | Reducing the probability and/or impact of a risk. Even if risk limitation cannot prevent a risk from occurring, it aims to soften its effects by buffering them. | · Process routing standards · Formalized exception handling (exception handling) |
| Avoidance | Taking precautions before a risk occurs and preventing it from happening. This is usually done by accepting other risks that have less impact or are easier to resolve. | · Process redesign |
| Transfer | Shifting the impact of a risk to another party if it occurs, or reducing the impact by sharing it. This may include activities such as outsourcing or insurance. | · Outsourcing process · Insurance policies |
| Acceptance | Adapting to the risk when it emerges as a problem. This strategy requires a contingency plan. | · Complying with legal regulations |
Common Risk Classifications in Enterprise Projects
Risk in enterprise projects is a topic that has attracted the attention of academic literature. The most popular classification is based on the nature of the risk. Typically, a business situation is threatened by natural disasters or events, people-related risks and risks arising from environmental factors. Similarly, 3 main groups can be considered in projects targeting Business Process Management (BPM)
1. People-Related Risks
2. Management-Related Risks
3. Technical Risks
In addition, (Davenport, 1993) positions organizational human resources and information technology (IT) [1] as the two main drivers of process innovation. In other words, if we do not manage these two well, our business can be negatively affected.
(Scott, 2000) also included changes in the external environment in the risk factor model developed for enterprise system implementations. According to them, risks affect our business positively when they are managed well within the organization and when the organization can react to changes dictated by the external environment. In the research of (Summer, 2000), the risk context is divided into smaller groups.
1. Distribution of Skills
2. Management Structure and Strategy
3. Software System Design
4. User Involvement and Training
5. Technology Planning
6. Project Management
7. Social Commitment
The table below was prepared based on the sources and research mentioned above (zue Muehlen & Rosemann, 2005).
Risks may stem from factors within the organization or be created by external factors.
Examples in Business Process Management (BPM) projects include the lack of a Business Process Management culture in the project team, or the lack of suitable technology at the selected third-party contractors. The probability of occurrence can be anywhere between ‘certain’ and ‘impossible’.
For risks that are certain to occur, error detection and remediation procedures must be planned. The critical level of the resulting impact can be very minor (errors in documentation, small glitches in the governance structure, etc.) or severe enough to require stopping the entire project.
The areas in which risks have consequences are also among the attributes used in classification. Risks do not just appear out of nowhere for no reason; in most cases they materialize as the result of an intentional or unintentional mistake. Sometimes policies and procedures can also cause risks, and sometimes internal working rules or cultural background can prevent the measures that would eliminate a risk from being taken.
Risks Specific to Business Process Management (BPM) Projects
In Business Process Management projects, risks can occur within the phases of the lifecycle as well as during transitions between phases. The table below lists the risks that are common in these areas.
Most of the identified risks come to life due to reasons such as
. The methods used in different phases of the process lifecycle being incompatible with each other
. It being unclear who is responsible for the phases and their outcomes
. Process goals not being defined correctly
Managers of Business Process Management projects need to pay attention to these.
This classification matters from a management perspective because the same types of risks can occur in different phases. Identifying them may require a more detailed risk analysis and the definition of more functional classes. These functional classes make management easier by grouping risks with common root causes (lack of training, lack of project management skills, incompatibility of the selected technology, etc.) into shared clusters. By intervening in the identified root causes, problems that could occur in several phases are prevented with a single intervention.
Lifecycle-Specific Risks
| Lifecycle Phases | Risks Specific to Business Process Management (BPM) |
| Analysis | · Performing analysis without a process strategy · Failing to define process goals and values· Focusing too much on technical issues· The language of the analysis being insufficient to express the observed process semantics |
| Analysis -> Design | · Analysis outputs not being reflected one-to-one in the design · Loss of information or focus when translating into design |
| Design | · The implementation modeling language not supporting the desired process semantics · Use of incompatible modeling technologies· Lack of communication between process designers and process stakeholders· Designers ignoring or failing to grasp the organizational perspective on the process design· No risk (problem) detection and handling measures built into the design· Modelers working at different levels of abstraction. The model being too abstract or too detailed… |
| Design -> Implementation | · Misinterpretations in the transition from the process model to the implementation plan · The modeling method (or approach) and the implementation method (or approach) being incompatible |
| Implementation | · Failure to create a top-down (senior executive level) view of the implementation · Managers lacking process management knowledge/culture· Focusing too much on technical issues· The resulting model not fitting the infrastructure· The resulting model not fitting the organization (culturally, structurally, regionally, etc.)· Failure to plan the transformation of resources· Failure to achieve the desired change in behavior, roles and responsibilities among process stakeholders· Process stakeholders assuming they already know the process without reviewing the new design |
| Operation | · No common language, or no communication at all, between process stakeholders · Process stakeholders resisting carrying out process activities· Process stakeholders taking a long time to adapt to the new structure· Process stakeholders being unable to communicate effectively beyond organizational boundaries· Process stakeholders not feeling comfortable in a process-oriented leadership environment· Process stakeholders having to work with many different people while running the process· The system not running stably· Service providers abandoning the work· New legal regulations making the process fully or partially non-compliant |
| Monitoring | · No monitoring strategy in place · Reduced or lost process transparency due to stakeholders' special requests or laws· Incorrect, faulty feedback from stakeholders· Failure to simplify the monitoring data with suitable filters· Monitoring without a quality approach· Differences between the objects specified in the design and those monitored |
| Monitoring -> Audit | · Monitoring staff receiving more information than they can evaluate · Failure to turn raw audit data into understandable, useful reports· Failure to combine information from different channels meaningfully· Failure to prevent people from manipulating the generated information· Failure to detect critical situations and respond to them in time |
| Audit | · Audit standards not yet established · Audit goals and design goals not aligned· Misinterpretation of audit data· Failure to turn audit data into useful business data· Failure to relate the assessment to strategic and external variables |
| Audit -> Design | · No feedback mechanisms in place · Lack of competence to identify problems during audit and assessment· Lack of competence to create contingency plans from assessment results |
The table below shows a Risk Classification made for risk factors:
Risk Classification
| Risk Factor | Definition |
| Method | The methods defined in the planning, design, implementation, operation and assessment stages not being understood or being applied incorrectly. |
| Communication | Failure to establish communication between BPM stakeholders and process users. Applies to communication in every form (conversations, meetings, reports, training, etc.). |
| Information | Not enough information being generated about situations within stages or about situations that arise in transitions between stages. |
| Change Management | Lack of competence in recording and carrying out changes |
| System / Technology | Technology not being suitable, or people being unable to use the technology |
| Leadership / Management | Failure to show strong leadership and to apply project management practices correctly |
| Resources/Skills | Not having the relevant skill sets |
| Strategy | Failure to create a vision, goals and set of functions that include all BPM stakeholders, functions and components |
Mapping Risks to Risk Classes
| Risk Factor | Lifecycle Risks |
| Method | · Unsuitable process analysis and design methods [1], [2] · Unsuitable mapping methods in the transfer from Problem to Solution and from Solution to Implementation [1,2], [2,3]· Unsuitable process modeling methods [2,3]· Unsuitable process implementation methods [3]· Unsuitable assessment methods [5]· Inconsistency between assessment and measurement methods [5],[6]· Unsuitable feedback mechanism [5,2] |
| Communication | · Goals communicated incorrectly [1,2] · No communication between stakeholders [All]· Assumptions in design and implementation that nobody knows about [1,2,3] |
| Information | · Misuse of information [1,2], [4,6], [5] · Insufficient information [All]· Invalid information [1,2], [2,3], [5,2]· Invalid translation of information [6,5] |
| Change Management | · Failure to change job descriptions and functions [1,2] · Failure to make changes [2]· Failure to detect problems [5,2]· Failure to react to changes made [All] |
| System / Technology | · Technology not being accepted [All] · Technology not being used properly [All]· Technology not being flexible [All]· Technology not being compatible [All]· Technology not being scalable [All] |
| Leadership / Management | · Ineffective leadership and managerial power [All] · Inconsistent management [All]· No leadership or managerial power at all [All] |
| Resources/Skills | · Lack of resources and skills [All] · Resources and skills not being used correctly [All]· Failure to deploy resources and skills [All] |
| Strategy | · Incomplete strategy definition [All] · Vague strategy definition [All]· No strategy defined [All] |
Now that we have built a classification, we can relate these categories to the lifecycle stages. In the table above, the numbers at the end of the lifecycle risk examples refer to the lifecycle stages.
1.Organizational Analysis
2.Design
3.Implementation
4.Operation
5.Monitoring
6.Audit
Looking at the table, risks in the Strategy, Resources/Skills, Leadership/Management and System/Technology categories have an effect across all lifecycle stages. This means these risks are orthogonal to the direction in which the BPM lifecycle project progresses.
As a result, it makes sense for a BPM Project Manager to focus on these risks before the project starts. Even if mitigation of risks in the other categories is postponed somewhat, their effect on the project's progress will be relatively milder.
References
Davenport, T. (1993). Process Innovation. Boston: Business School Press.
Scott, J. V. (2000). Managing Risks in Enterprise Systems Implementations. Communications of the ACM.
Summer, M. (2000). Risk Factors in Enterprise-wide/ERP projects. Journal of Information Technology.
zue Muehlen, M., & Rosemann, M. (2005). Integrating Risks in Business Process Models. Sydney, Australia: Proceedings of the 2005 Australian Conference on Information Systems (ACIS 2005).
Sources
https://www.ibm.com/think/topics/business-process-management
https://www.ibm.com/think/topics/business-process-analysis
https://www.ibm.com/think/topics/process-optimization
Would you like to see PaperWork in your organization?
Request a Demo
