Every project carries risks, incredibly complex and large-scale projects such as BI systems. When assessing risks, it's important to remember that while the project involves specifying, developing, and implementing a technological tool, it is essentially a human project rather than just a technological one.
The technology is often given or requires development, but the success or failure of the project depends on correctly specifying work processes and implementation - these are human processes. In the risk assessment process, we consider scenarios that may occur in various project stages and potentially jeopardize the entire project to varying degrees.
It is recommended to evaluate each risk according to two parameters, which will be rated on a predetermined scale:
The likelihood of the risk occurring
The severity of impact on the project if the risk materializes
Additionally, for each risk, it is recommended to weigh the assessments of the two parameters into a summary assessment:
High risk - Critical impact on the project
Medium risk - Significant impact on the project
Low risk - Localized implications that can be overcome through relatively simple actions
When examining all risks, there are three main potential consequences:
The project will be realized but with significant deviations in schedule and budget
The project will not be realized
The project will be realized but will not achieve its goals
What is the "most significant" consequence? The answer depends on the organization, its goals, what it must gain from the project's success, and what it has to lose from its failure.
So far, we've reviewed a method for risk assessment in any project. How does risk assessment in a BI project differ from risk assessment in any other project? While the methodology is identical, the intensity of risks varies between project types, affecting the overall risk assessment.
While IT systems are "operating systems" aimed at easing employees' work and streamlining organizational processes, BI systems are "thinking systems" designed to assist managers in organizational decision-making, which can sometimes involve crucial decisions.
Without underestimating the importance of IT systems and their value to the organization, BI systems are more complex. Therefore, the intensity of risks in a BI project is much greater.
Here are "samples of risks" in a BI project and recommended actions to prevent or partially mitigate their impact if they materialize (the actual risk assessment depends on the organization - its organizational culture and existing resources, so these samples are general examples):
Specification
Scenario - Lack of user segmentation into homogeneous groups
Meaning –
Difficulty in adapting the service and solution to user needs, leading to inaccurate specification
Partial response to processes requiring access to additional data sources
Main consequences- The project will be realized but will not achieve its goals
Mitigation actions –
User involvement in all specification stages (including specification validation before development)
Inclusion of methodology experts in the specification process to bridge the gap between users and IT personnel
Scenario - Complexity and complication: size of applications, multiple dimensions, and complex report structure
Meaning - Unreasonable complexity in users' eyes will cause reluctance to use the system
Main consequences - The project will be realized but not achieve its goals.
Mitigation actions –
Maintaining a guiding principle of simplicity in the specification stage
Validating the specification with users
Inclusion of methodology experts in the specification process to bridge the gap between users and IT personnel
Scenario - Low data quality and update level
Meaning - Damage to user trust in the system leading to non-use and turning to additional information sources
Main consequences - The project will be realized but not achieve its goals.
Mitigation actions - Improving critical data before development
Development
Scenario - Technological difficulty in interfacing between the BI system and existing operational systems in the organization
Meaning –
Inability to import essential organizational data and create an integrative and valuable knowledge base in the BI system
Users turning to additional data sources
Main consequences –
The project will be realized but with significant deviations in schedule and budget.
The project will be realized but will not achieve its goals
Mitigation actions - Learning about existing operational systems and the intended BI system during the specification stage by the specification team, with joint thinking with the IT unit on alternative solutions
Scenario - Mismatch between the specification document and the capabilities and work habits of the implementing company
Meaning –
Correction of the specification document to meet the requirements of the implementing company
Returning to users to complete the required data for writing the specification may damage the project's reputation and create a sense of unprofessionalism in the specifying team.
Main consequences - The project will be realized but with significant deviation in schedule and budget
Mitigation actions –
Conducting preliminary expectation alignment between the specification team and the implementing company regarding the structure and content of the specification document
Maintaining constant contact with the implementing company to "align" throughout the process
Conducting a guided reading of the specification document before implementation, involving the specification team and the implementing company, to provide emphasis, ensure understanding, and address problematic points
Implementation
Scenario - Lack of a training program tailored to users in terms of method and duration of training
Meaning –
Raising objections from employees and managers to cooperate
Partial use of the system
Main consequences - The project will be realized but with significant deviation in schedule and budget
Mitigation actions –
Segmentation of the target audience in building the training program
Use of diverse training tools and methods (preferably with user involvement)
Scenario - Communications not tailored to the target audience
Meaning - Conveying conflicting messages from different sources in the organization or lack of "permeation" of messages to the field
Main consequences - The project will be realized but will not achieve its goals
Mitigation actions –
Segmentation of the target audience and creation of segmented and focused messages
Monitoring and feedback regarding the implementation of messages in the organization and adjusting the communication plan
Cross-Project
Scenario - Lack of change management
Meaning –
Disconnection from users in the specification and implementation stages
Raising objections from employees and managers to cooperate
Partial use of the system due to fear of changes
Main consequences - The project will be realized but not achieve its goals.
Mitigation actions –
Engaging managers and employees in the organization from the initial stage by:
Sharing the needs, goals, and plans of the project
Setting expectations regarding their level of involvement in the project
Coordination between the change management plan and the training and communication plans
In conclusion, risk assessment is critical before "setting out" on a project, as it can save surprises later.
Although it is a relatively intuitive assessment, it is performed by professionals and adequately reflects reality.
To "cover" most risks and conduct joint thinking regarding ways to deal with them, performing risk assessment in a team using the "brainstorming" method is recommended.
Good luck.
Comments