On most IT projects, risk mitigation is a well-managed process. However, many business intelligence (BI) projects fail to deliver on time or within the set budget. The reason for this is likely due to a lack of qualitative risk management. It is relatively easy to identify and mitigate quantitative risks compared to qualitative risks, such as the failure rate of equipment, and to put a contingency plan in place, say, for instance, RAID 5 or 10 in this case, should the risk materialise.
The frog-in-boiling-water effect prevents one from realising that a risk is materialising.
Gerhard Botha is principal consultant at PBT.
In its simplest form, quality can be described as 'conformance to requirements'. Qualitative risk management addresses risks associated with a number of uncertainties in the quality of inputs on a project, which may result in deliverables not being met.
This Industry Insight is not an attempt to show how to mitigate these risks or what contingency plans to put in place, but rather to create awareness among project stakeholders of such factors that should be included in future project risk management strategies.
Risky business
Below, I have outlined a number of qualitative risks and what these include:
* Quality of human resources on projects. One of the biggest performance variables on projects are the people, their cognitive abilities, education and experience, which are all factors that could impact effectiveness.
* Quality of data, including data availability, data integrity and reliability. It is well known that poor input makes for poor output; nevertheless, most BI project managers opt to ignore this as a risk. Simple data verification and profiling will mitigate poor data quality risks.
* Quality of requirements, project scope and exclusions. One of the most problematic aspects of any IT solution is the meeting of expectations. Simply having a list of specifications is no longer sufficient in measuring the success of a project. More important than the list of requirements or specifications are the project goals and objectives. Instead of looking at what a computer system should produce, project managers and all those involved should have the bigger picture in mind, and have an understanding of what the business should accomplish when using the system.
* Quality of organisational processes and structure, eg, an organisation's procurement cycle may be too long, with too much red tape and therefore impact on downstream processes.
* Quality of equipment. Although the failure rate of equipment is well understood and documented, the cost associated with failure is seldom listed as a risk factor.
* Quality of training. The smartest people will make mistakes or be inefficient without proper training.
* Quality of environment. Without sufficient attention to ergonomics, productivity is bound to suffer.
* Quality of logistics. If resources cannot be moved on time or, in the case of people, in comfort, then delays will occur or travel fatigue will set in.
* Quality of IT processes, including robustness and fail-over procedures.
* Quality of software. High-quality software has many quantitative attributes such as high availability, robustness and functional abilities; however, what is often overlooked is the productivity that software solutions permit.
* Quality of architecture. There are two architectural aspects to address. Firstly, enterprise architecture must allow for the effective integration of systems and the support of value chains and workflows within an organisation. Secondly, the quality of the solution architecture will greatly influence the effectiveness of the project and must be mitigated by having an experienced architect participating or consulting on the project.
* Quality of decision-making. If decisions are made on the fly without supporting evidence or research and based purely on political influences, then poor results will follow.
With all this being said, it is not sufficient to list the risks, but to plan for them, and more importantly, be able to spot them. An important question to ask is: “What are the triggers and warning signals that a risk may materialise?” Especially in the case of qualitative risks, the frog-in-boiling-water effect prevents one from realising that a risk is materialising. A continuous review of risks is therefore required.
Qualitative risk assessment should not necessarily be seen in a negative light, but seen as an opportunity in an organisation's continuous improvement programme.
Qualitative risk management not only applies to inputs, but also outputs - the recipients of a company's work should expect the same level of quality that the company must expect from others.
Share