Benefits of Risk Analysis RISK MANAGEMENT is a COMPONENT of PRINCE2 for planning, resourcing, monitoring, controlling risks and is required

d to be applied to every PRINCE2 project. Risk Exposure ( quantification ) Quantifying risks in terms of the product of the likelihood of the risk maturing and the negative impact made by the outcome. RE = likelihood X impact Risks should be surfaced ahead of time. The first time is before the project sta rts. Then risk identification should occur throughout the project on an ongoing basis. There is no reason to hide or shy away from the exercise - the customer d oes not expect the project to be risk free. If team members are familiar with the circumstances of the project, they can tak e an active role in identifying and evaluating project risks. Joint participatio n can help identify project risks, lay out effective actions to manage the risk and provide consensus and buy-in for execution. Note that there is a concept of opportunity risk or positive risk. In these inst ances, the Project Manager or project team may introduce risk, to try to gain mu ch more value later. For instance, the team may spend time to relocate together because they think the close collaboration will result in productivity savings o ver the life of the project. This is an example of intelligent risk taking an issue is a current problem that must be dealt with, a risk is a potential future problem that has not yet occurred. Without getting into fractions, a risk has between a 1% to 99% chance of occurri ng. If an event has a zero percent chance of occurring, then it should be ignore d. If it has a 100% chance of occurring, then it is a fact (and perhaps a constr aint). When practising risk management, be sure to focus on the risks and not on facts and non-events All projects have some degree of uncertainty due to the assumptions associated w ith them and the environment in which they are executed. Although the risks cann ot be eliminated entirely, many can be anticipated and resolved ahead of time Risk Analysis The purpose of risk management is to identify the risk factors for a project and then establishes a risk management plan to minimise the probability that the ri sk will materialise Identification capturing/catalogue potential risks unique allocation numbers an ownership details. Estimation qualitative assessment establish the likelihood of risks occurring an d their impacts measuring the likelihood and impact of each risk category of risk (project or bu siness) Probability impact grids/matrix impact Vs probability can provide a common baseli ne for risk classification tables Decision trees, distribution humps, Monte Carlo S-curves (time and cost impacts) end reports, risk registers Evaluation assessing if any of the risks are acceptable or the actions required for management of the risk Risks mitigation identification of remedial action, segregate those that only re quire monitoring, fallback plans for those risks that actually occur despite mit igation actions. Risks are closely related to the Business Case and are monitored throughout a pr oject. Monitor the risk - In this case, the Project Manager does not proactively mitiga te the risk, but monitors it to see whether it is more or less likely to occur a s time goes on. If it looks more likely to occur, then the team must mitigate it at a later time. This approach can work for serious risks that are not likely t o occur. Rather than put a plan in place immediately, the Project Manager create s a plan only if it looks likely that the risk will occur. The advantage is that scarce resources are expended only on those risks that are likely to occur. The disadvantage is that the delay in mitigating the risk might make it less likely that the risk can be successfully mitigated in the future. Risk Log is created in SU4 (brief along with business case) and referenced in DP

and CP and updated in all other processes, especially before the draft PID (coul d be a workshop with specialist and business assurance..) The Risk Log is kept in the Project File Minimum update to the risk log is made at the ESA (SB3) from CS4/CS5 Impact analysis PL6 from CS4 examine project issues for risks and examine busine ss case Review risk status and bus case as part of stage status CS6 and report via highl ight report Communicate risks at Checkpoint and Hilight reporting times Project Manager is responsible for identification, recording, and review of risk s Project Manager may delegate this role to a Risk Manager Early risk identification Risk Trends are in the Hilight Reports Accountability and ownership / responsibility (commitment and teamwork) Project Board and Project Assurance can help to identify owners of risks Auditable unique records Review by management Learn from experience Agreement in CS1 and confirmation in MP1 Exceptionally high risks can be escalated via an exception report and the projec t may be prematurely closed if there is danger of project going out of scope or tolerance exceeded. Risk Log is continually reviewed and saved in a The Project File (esp. SB3/ESA) a d updated at each stage end Risk Classification Table (from configuration management) Explain high and low risk and the scores for each risk Each risk has an owner Likelihood of risk turning into an issue (probability) Move the activities associated with the risk plans to the Project Workplan Consequence (performance) + scoring (impact reputation?) within the table Probability impact grids (high/medium/low for both probability and impact) Project Risks (could be company policies affecting outcomes, + funding problems) Can this risk prevent the project completing on time, to specification, and with in budget? The threats to the management of the project and hence to the achievement of the projects end results within cost and time Possible premature close triggered by DP4 if benefits thought to have disappeare d or too high risk Project Manager is responsible for Project Risks Business Risks (success criteria damage i.e. outside influences, take-overs etc) Initial bus risks are identified with the business case the Project Brief review risks and bus case in DP1 Authorising initiation the Project Brief review risks and bus case in DP2 Authorising Project the Project Brief review risks and bus case in DP3 Authorising Plan The threats associated with a project not delivering products which can achieve the expected benefits Can this risk prejudice the business case / objectives? Update BC in SB3 Project Board are responsible for Business Risks Actions ( Risk Response ) C = Contingency putting into place a series of actions should the risk materiali se Create a contingency plan, to document the consequences to the project if the ri sk plan fails and the risk actually occurs. In other words, identify what would happen to the project if the future risk turns into a current issue. This helps the Project Manager ensure that the effort associated with the risk plan is prop ortional to the potential consequences. For instance, if the consequences of a p otential risk occurring is that the project will need to be stopped, this should be a strong indication that the risk plan must be aggressive and comprehensive

to ensure that the risk does not occur Contingency is sometimes known as Mitigating A = Acceptance cautious commitment, hoping that the risk may not materialise Look at any low risk items, and see whether they should be listed as assumptions . In this way you recognise that there is a potential for problems, but because the risk is low, you are assuming that the condition will not occur P = Prevention stop the risk from happening Mitigate the risk - In most cases, this is the approach to take. If a risk has b een identified and is a concern to the project, usually proactive steps must be taken to ensure that the risk does not occur. Another of the goals of mitigation is to ensure that the effect (impact) of the risk is minimized if it does occur . R = Reduction reducing the likelihood and/or impact reduce the likelihood before the event occurs T = Transference (penalties for external companies / Insurance taken against the risk) Move the risk - In some instances, the responsibility for managing a risk can be removed from the project by assigning the risk to another entity or third party . For instance, outsourcing this function to a third party might eliminate insta llation risks. The third party might have particular expertise that allows them to do the work without the risk. Or, even if the risk is still present, it now i s up to another party to resolve. The risk is accepted by somebody who is better able to manage the impact Protection Paying ahead against a risk that may or may not mature. Taking out insurance is an example Avoid the risk - (PRINCE2 does not recognise Risk Avoidance ) Avoiding the risk eans that the condition that is causing the problem is eliminated. For instance, if a part of the project has high risk associated with it, then th e whole part of the project is eliminated, or something else is done in its plac e. Risks associated with a vendor might be avoided if another vendor is used instea d. This is a very effective way to eliminate risks, but obviously can be used only in certain unique circumstances De-scoping a project is an option to save money etc There is some industry evidence that a 5% contingency can be added to the projec t for dealing with risks that are unknown when the project starts. (The time to mitigate and manage known risks should be included in the original estimate) Can have a Post Project Risk Review Escalate project issues CS8 where there is an impact on the risks or the busines s case CP3 (evaluate project) any lessons for the future STANDARD RISK ANALYSIS CHECKLIST This should be done as part of the Brief Standard Risks are split into six elements. Project Management Project Staff Nature of the Project Maturity of the Organisation ( development and internal/external suppliers ) The Customer and Contract Third Party Supplier Each risk has its own reference a description of low risk a description of high risk a score representing the true level of risk ( high, low, or in-between ) score ranges between 0.10 and 4.00

 normal score is between 1.00 and 3.00 Scores outside the norm are exceptional and explanations are required. a suggested weight range representing the impact to the project and serves to pr oduce the risk factor a weight representing perceived impact within the range of the suggested weight a total representing the score multiplied by the weight. Totals in excess of 15 should be extracted to a risk log recording the proposed actions The project has a Risk Factor resulting from the totals divided by the weights. Risk factor of 2.00 represents LOW RISK PROJECT between 2.00 to 2.20 indicates MODERATE RISK PROJECT between 2.20 t0 2.60 indicates HIGH RISK PROJECT in excess of 2.60 indicates VERY HIGH RISK Project Management Risks Low High Suggested weight range Project Sponsorship Unknown Do not start the project! Full time, experienced Project Manager Part time, inexperienced Project Manager 5 to 7 Customer Management experienced and likely to be active Inexperienced Customer M anagement little participation expected 4 to 6 Project Staff Risks Low High Suggested weight range High standard of supervision and narrow span of control in the project team Wide span of supervision and control expected to be poor 4 to 6 Customer staff likely to be supportive and fully involved in the project Identified and enthusiastic Customer commitment Little Customer staff involvemen t expected and little contribution 3 to 6 Good quality project team, experienced with the right skills Inexperienced pr oject team lacking the key skills 6 to 8 Staff assigned full time to the project Staff have many other responsibilities 3 to 6 Low turnover of project staff High turnover of project staff 4 to 7 Staff experienced at Quality Reviews No experience of Quality Reviews among s taff 4 to 6 An organisational commitment to Quality exists Staff take little interest in ac hieving a Quality Culture 4 to 6 Location of team is close for collaboration We re still on the same floor as the users, so people just walk down the corrid or to discuss things. The close collaboration with users meant they appreciated the need to keep chang e to the minimum to meet the deadline. Change control was minimal, because few changes were requested Staff are split between departments and physical locatio ns 3 to 5 Nature of the Project Low High Suggested weight range Typical project with a straightforward lifecycle A project lifecycle that has a number of inter technical relationships 4 to 6 The project has no or few novel features Pioneering new approaches are be ing tried out in the project 6 to 8 Equipment being installed by the project is well known, tried and tested Equipment is untried and its use is uncertain 4 to 6 Current main operations will be only minimally affected by the project Signific ant impact on current main operations by the project 3 to 5 The business requirements are, or will be, well established and well documented by the customer Well defined Business benefit Business requirements are ( expected to be ) poo rly understood, documented and presented by the customer

Scope / deliverables Poorly defined 3 to 6 Little or no modification needed to existing technical standards Extensiv e modification needed to existing technical standards will be needed 3 to 6 Little project work is being undertaken currently Other project work is be ing carried out in parallel with this project 3 to 6 Moderate response time is acceptable Response times are critical 3 to 8 There is little dependence on development facilities not under the control of th e project team There is a dependence on development facilities which are outsid e the control of the project team 3 to 7 Project duration is less than 6 months or there is only a small number of workda ys required Project duration is longer than 6 months or there is a high numb er of workdays 2 to 5 There is little or no constraint on the completion date There is a mandatory com pletion date stated by the customer 4 to 7 Plans and estimates are ( will be ) based on reliable data from similar projects Plans and estimates are ( will be ) based on unreliable data essentially green fi eld 4 to 7 Estimates have been prepared using well tried and documented standards Approxim ations have been used based on unreliable standards 4 to 7 This is the first or second attempt at this project i.e. there is no history of consistent failure There have been two or more attempts to complete this pr oject i.e. it has a history of failure 4 to 8 Few customer departments will be affected by the final outcome Many customer de partments will be affected by the final outcome 4 to 6 The project work will affect few customer sites Many customer sites will be impa cted by the project work 3 to 6 Sites which the project team will visit are easily accessible Sites are remote and inaccessible 3 to 6 There will be only minor impact on the customers day to day work during the proje ct cycle There will be significant impact on the customers day to day work during the project 3 to 6 Well developed and understood project management standards will be available to the project team Few project management standards will be available to th e project team 4 to 7 Maturity of the organisation Low High Suggested weight range There is a well developed and understood quality environment i.e. an audited qua lity management system Quality management is ill defined and/or not visible 4 to 7 Clear delegation of authority is practised by management There is strict central management control with little empowerment or delegation 3 to 6 Project staff will wish to make use of the published project management standard s Project staff are not expected to utilise any project management standar ds that exist 3 to 6 The customer and the contract Low High Suggested weight range The customer demonstrates a full understanding of the requirements and its impac t The customer demonstrates a poor understanding of the impact of the requ irement Requirements Very complex, hard for customer to define 4 to 7 There will be little or no modification needed to the customers existing faciliti es Extensive modification to the customers existing facilities is expected 3 to 6 An agreed contract is in existence No formal contract is yet in place 4 to 7 There have been previous dealings with the customer and previous contracts have been brought to a satisfactory conclusion There have been difficulties whe n dealing with this customer on earlier contracts 3 to 7 Third party supplier Low High Suggested weight range

Suppliers are known, approved, and have a satisfactory track record The supp liers are new and little is known about their capabilities 4 to 8 Only one, well established, approved supplier will be used to provide the servic es Multiple suppliers ( with sub-contractor elements ) are anticipated 3 to 6 Suppliers have an established structured project management method based on PRIN CE or similar Supplier project management arrangements are ad-hoc with little visible definition 3 to 6 A supplier contract is in existence Informal arrangements only exist 4 to 7 The main supplier has fully audited quality management system to ISO9001 When we selected our suppliers - or business partners, as they became - we made sure they had standards and structured working but we didn t insist they stuck to our own standards, he says. If we d been over-prescriptive it would all hav e taken too long. We let our partners work to their standards, as long as they r eported in the ways we wanted. The main supplier has no published QMS 4 to 7 The future level of supplier performance is expected to be excellent The futu re level of supplier performance is not assessable because too little is known 3 to 6