Alignment with Project Risk Management
Projects are now the key contributors to the performance of the organisation as they support the processes that deliver improved services and products. They are part of a structure that works as follows. Projects are grouped together to form a programme as sometimes it will take several projects to achieve a specific business goal. Building a road is a project, but only in conjunction with other projects that construct bridges and install a traffic management system will an effective transportation network be completed. Programmes in turn make up the project portfolio. The portfolio is the outcome of business/project strategy interaction and seeks to maximise the synergy that is created between the two.
From a risk management perspective, projects protect the organisation's existing values, such as its reputation, and/or create new values in the form of novel products and services. Project risks are identified at all levels but are progressively refined from the portfolio downward to the project level via project programmes. Without the vertical integration of projects, programmes and portfolio, the project manager would struggle to identify the value-protecting and value-creating roles that project risk plays. Figure 2.4 conceptualises the above arrangement.
Example of Aligning Business Objectives with Project Risk Management
Kaplan and Mikes (2012) provided an example of how strategic business objectives are formulated and aligned with project risk management. In the case of 'VW do Brasil' there were nine business objectives against which risks were identified:
1. Achieve market share growth.
2. Satisfy the customer's expectations.
3. Improve company image.
4. Develop dealer organisation.
5. Guarantee customer-oriented innovations management.
6. Achieve launch management efficiency.
7. Create and manage robust production volume strategy.
8. Guarantee reliable and competitive supplier-to-manufacture processes.
9. Develop an attractive and innovative product portfolio.
For each business objective, project risks were identified. For example, in respect of the project to meet the goal 'Satisfy the customer's expectations', eleven risks were found and assessed. Four of these risks were determined to be critical and required immediate attention or mitigation. The researchers did not provide details of their nature.
PROJECT RISK IDENTIFICATION
Literature and practitioner material provide comprehensive guidelines to risk identification. The nature of project risk, however, is complex and often misunderstood (see Chapter 8). As an example, a 'fact' is not a risk since risk is about uncertainty. The fact that there has been a crisis in the past does not necessarily mean that the crisis will occur again, even though some element of uncertainty exists. Furthermore, project risks by nature can be positive or negative. The team needs to be specific when determining what project risk is or is not, and its significance. What is also important is that the sooner risk is identified the better.
Project risks are identified to a large extent from existing documentation. First, the organisation's stated risk appetite and tolerance levels will determine the attitude to risk taking. Second, the project's mission and scope statements will define the sources from which risks may originate. Third, activities in other project management knowledge areas should be reviewed to identify possible risks within them. A superficial approach to project costing, for instance, may leave costs being ignored or wrongly estimated.
Project risk identification techniques are well known in the project management profession and include the following:
• Brainstorming. This technique is most often used when subject experts are involved. Those with the necessary experience and knowledge identify initial risk events and subsequently one idea spawns another. A suitable facilitator may be involved to start the process and guide the group in compiling a list of project risks.
• Checklist. The checklist is based on historical information and project experiences. It is useful for projects of a similar nature. Checklists are developed to a detailed risk level and refined at the completion of each project.
• Interviewing. Interviews are question-and-answer sessions where the team interviews subject experts, stakeholders, users and managers. The questions can be structured (requiring specific answers) or unstructured (more like a discussion). To guide the interview, teams often use the Work Breakdown Structure (WBS) to get interviewees thinking about risks in tasks required to complete the project.
SWOT analysis. This approach is very popular and often practised. It requires the team to examine each of the Strengths, Weaknesses, Opportunities and Threats of the internal and external environments as they may affect project risks.
Delphi technique. This is a sophisticated method in which experts are approached and asked to rate potential project risk via a questionnaire. Responses are organised by the mean rating for each item and sent back for further input, additions and comment. The experts are asked to consider the group's mean rating for each risk item and to modify it if they think it is necessary. After another round a fresh list is compiled with new ratings. After about three rounds consensus is reached among the group on the project risks that exist and their ranking.
Assumptions analysis. Assumptions underlying predicted project risks are examined by exploring their validity for accuracy, consistency and completeness. Each project risk is tested for the strength of its assumption and redefined if an assumption turns out to be false.
Checklist: Aligning Strategy with Project Risk Management
• Does the alignment of business and project strategies give direction to developing project risk strategies?
• Are initial project risk strategies formulated during project portfolio management?
• Are project risk strategies progressively refined during project programme management?
• Are project risk strategies implemented during project management?
• Is the nature of project risk clearly understood?
• Are project documents accessed to establish the sources of project risks?
• Is the project team familiar with the techniques for identifying project risks?
• Are the techniques used to identify project risks adequate?