Risk management in business analysis the great differentiator
•Download as PPTX, PDF•
2 likes•4,304 views
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Viewers also liked (20)
Similar to Risk management in business analysis the great differentiator
Similar to Risk management in business analysis the great differentiator (20)
Risk management in business analysis the great differentiator
- 1. 1 By Christian D. Kobsa Project Risk Management in Business Analysis The Great Differentiator
- 2. TOC PART I Definition Why Important Risk Impact Why Difficult General Risk Analysis Questions Risk Analysis Focus Areas Focus Area Breakdown Analysis Related Risk PART II Risk Assessment – How? Risk Taxonomy & Taxonomy Model Risk versus Uncertainty Risk Breakdown Structure …TBD… 2By Christian D. Kobsa
- 3. Definition “Project risk analysis and management is a process which enables the analysis and management of the risks associated with a project. If performed properly it will increase the likelihood of successful project completion to cost, time, and deliverable objectives.” 3By Christian D. Kobsa
- 4. Strategy, Tactics, and Risk 4By Christian D. Kobsa Why? What / How?
- 5. Why Perform Risk Analysis and Management? “Any project will face exposure to the possibility of stated and unstated uncertain events and circumstances that can have negative impacts on the outcome of the project.” 5By Christian D. Kobsa
- 6. Risk Occurrence Impact 6By Christian D. Kobsa Project deliverables can not be completed within the promised timeframe. Project deliverables can not be completed within the defined cost parameters. Project deliverables do not meet agreed upon client expectations. Possible loss of profits. Possible decline in reputation. Possible decline or complete loss of trust.
- 7. Risk Analysis / Management – Why Difficult? 7By Christian D. Kobsa Lack of communication about project risk. Lack of analysis of possible risks. Stakeholder reluctance to accept that risk neither good / bad but always present. Stakeholder reluctance to recognize that identified risk can be successfully managed. Cultural bias to bring up risk, as it carries a negative connotation.
- 8. General Risk Analysis Questions 8By Christian D. Kobsa What could possible go wrong? How would that influence the project deliverables? What is the likelihood of it happening? How will it affect the project? How will the effect on the project influence project deliverables? What can be done about it? How will this risk mitigation influence project deliverables?
- 9. Risk Focus Areas 9By Christian D. Kobsa Staff Organization Technological Environmental Cultural Legal …Others…
- 10. Focus Area Questions - Staff 10By Christian D. Kobsa What happens if staff is not available soon enough? What happens if the project staff does not have the right skill set? What happens if key project team members leave? What happens if key project team member conflicts create stalemate?
- 11. Focus Area Questions - Organization 11By Christian D. Kobsa What happens if organizational buy-in is not available? What happens if the sponsors and/or other key stakeholders do not provide the support promised? Is the organizational management structure unstable / changing? Will there be a new project sponsor in case the current one leaves? If there is a new sponsor, how will the project be affected? What if another business or business unit withdraws from the project initiative? What if the deliveries from a vendor do not meet expectations?
- 12. Focus Area Questions - Technological 12By Christian D. Kobsa What if the technological expectations for project deliverables can not be met? What if technology cost is higher than anticipated? What if technology requirements limit project delivery implementation? What if technology requirements expand project delivery expectations? What if technology requirements don’t allow for proper interfacing with existing systems?
- 13. Focus Area Questions - Environmental 13By Christian D. Kobsa Are there environmental demands that contradict business needs? Are the environmental requirements clearly defined and understood? Can the environmental requirements be implemented without negatively influencing business-value? What are the consequences if the environmental requirements are not met?
- 14. Focus Area Questions - Cultural 14By Christian D. Kobsa Is the project’s deliverable being used primarily in a multi-cultural environment? Are the motives and interests in the project’s deliverable of culturally divergent stakeholders clearly understood? Is the project team multi-cultural? How comfortable are multi-cultural team members with each other? How do multi-cultural team members communicate with each other? Are team members aware of typical cultural behaviors of each other? Are multi-cultural team members respectful of, and interested in, the cultural background of other team members?
- 15. Focus Area Questions - Legal 15By Christian D. Kobsa Is there any question as to whether the project’s deliverable is legal? Is there any particular area of the law that influences how the deliverable must be produced? Is there any particular area of the law that restrains what can be produced under this project? Does the project’s deliverable fall under the jurisdiction of international law? Does the law dictate that the project team consists of individuals with certain backgrounds?
- 16. Risk Focus Areas - Summary 16By Christian D. Kobsa Human: individuals, stakeholder groups, departments, illness, death, etc… Operational: disruption to supplies and operations, loss of access to essential assets, failure in distribution, etc… Reputational: loss of business partner or employee confidence, damage to reputation in the market. Procedural: from failures of accountability, internal systems and controls, organization, fraud, etc… Project: risk of cost over-runs, jobs taking too long, insufficient product or service quality, etc… Financial: from business failure, stock market, interest rates, unemployment, etc… Technical: from advances in technology, technical failure, etc… Natural: threats from weather, natural disaster, accident, disease, etc… Political: from changes in tax regimes, public opinion, government policies, foreign influence, etc.
- 17. Analysis Related Risks 17By Christian D. Kobsa Business Situations: 1. The contract is not finalized, hence the scope is undefined. 2. The project charter is not shared with the consulting BA team. 3. Requirements planning cannot be conducted prior to a formal kick- off. 4. The organization does not have a requirements management plan. 5. Current state documentation or business workflows are not always made available. 6. Business requirements have received sign-off, but continue to change during implementation. 7. Stakeholders are not prepared for analysis elicitation workshops. 8. All product enhancement requests are ranked as “high”. 9. Buy-in to conduct formal stakeholder analysis can not be obtained. 10. Resources responsible for elicitation are not communication requirements.
- 18. Risk Assessment – How? 18By Christian D. Kobsa Risk Assessment Identify Uncertainties Analyze Risk Prioritize Risk
- 19. Identify Uncertainty – Risk Taxonomy 19By Christian D. Kobsa IT Engineering Risk Taxonomy Product Engineering Engineering Environment Program Constraints Requirements Engineering Specialties…. Engineering Process Work Environment …. Resources Program Interfaces …. Stability Scale… Formality Product Control … Schedule Facilities… ClassElementAttribute
- 20. Risk Identification Using a Taxonomy Model 20By Christian D. Kobsa Select a Base Taxonomy Select a Project Type Classification Adjust Risk Taxonomy Develop Risk Identification Rules Customization Execution Tracking Specification of Project Characteristics Execute Risk Identification Rules Respond to Risk Related Questions Execute Risk Identification Rules Undefined RiskYes Present All Identified Risks No Track Identified Risks Improve Risk Detection as Possible
- 21. Risk Versus Uncertainty 21By Christian D. Kobsa A definite fact about the project and/or its environment.CAUSE RISK Uncertainty that could affect the project if it occurs. EFFECT Contingent result of risk on project objectives. Structured Risk Statement: “As a result of <definite cause>, <uncertain event> may occur, which would lead to <effect on objectives>”.
- 22. Risk Breakdown Structure (RBS) 22By Christian D. Kobsa Project Name Technical Risk External Risk Organizational Risk Project Mgmt. Risk Requirements Technology Complexity Interfaces Performance Reliability Quality ??? Sub-Contractors Suppliers Regulatory Market Customer ??? Project Dependencies Resources Funding Prioritization ??? Estimating Planning Controlling Communication ???
- 23. References 23By Christian D. Kobsa Books: Managing Risk – Methods for Software Systems Development (Elaine M. Hall) Crisis Management – Planning for The Inevitable (Steven Fink) Practice Standard for Project Risk Management (Project Management Institute) White Papers: Overcoming Cultural Obstacles to Managing Risk (Daniel Galorath) Managing Risk in Multi-Cultural Projects (Kirsi Aaltonen, Mervi Murtonen, Sampo Tukiainen) What is the Likelihood and Impact of a BA Communicating Risk? (Maureen McVey) When is a Risk not a Risk? (Dr. David Hilson) A Taxonomy Based Model for Identifying Risks (Sebastian Maniasi, Paola Britos, Ramon Garcia-Martinez) Integrated Risk Management As A Framework For Organizational Success (Dr. David Hillson) Web Sites: http://whatis.techtarget.com http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=11847; (“Taxonomy Based Risk Identification” by Carnegie Mellon University, SEI) http://www.mindtools.com (
Editor's Notes
- This is one of many definitions one can find about what project risk is. This particular definition highlights the points that: Project risk analysis and the management of identified risks is a process. I.e., it is not something that can successfully be done in a haphazard manner, or just once during the initiation of planning phase. There are two aspects associated with project risks. One is the analysis effort, which primarily refers to identifying the risks for a particular project. Second, once risks are identified, they have to be managed. Well performed and managed, the dividends are significant. From a business analysis perspective, it is the words “deliverable objectives” in the definition that makes risk analysis so important.
- Defining an organizations vision and business benefits falls under the realm of strategy. Projects, programs and portfolios describe the tactics by which the strategy is achieved. Project, program, and portfolio objectives exist between the strategic and tactical areas. Objectives are defined in relation to the strategic vision. In turn project requirements are defined in relation to project objectives. It is a fact, that many projects fail because of a gap or disconnect between the strategic vision and the tactical project deliverables. Why does that happen? Often this is the case because of poorly defined project objectives. Hence, for projects to be successful, this “space” between strategy and tactics requires careful and proactive analysis and management. It is in this “space” that projects are most at risk! All business activity takes place in an environment of uncertainty. That uncertainty comes from technical issues, commercial constraints, management issues and external dependencies. Risk is NOT the same as uncertainty. Risk arises, when uncertainty has the potential to affect objectives. Project objectives provide the link between the overall vision and the projects that are undertaken to implement that vision. Project objectives also define the acceptance criteria for the deliverables of the project. Because project objectives are affected by the uncertain environment within which the project is being executed. That fact, results in a level of risk exposure.
- This is why risk analysis and management is an important aspect of executing a project. Note, that the explanation is NOT saying that the list of stated or unstated uncertain events and circumstances WILL occur, but that the possibility of one or more of them occurring does exist. The results of such occurrences are negative impacts on the project in at least the following areas; (next slide). What this statement DOES say then, is, that a project WILL experience the possibility of one of the stated or unstated uncertain events to occur. It is because of that possibility, that managing risk and it’s impact on the scope or a project becomes important. And when project scope is affected, requirements of the project’s deliverable – whether a product or service – are impacted as well. It is for this very reason, that risk analysis is not just the purview of the PM, but of the BA as well.
- All of these impacts are bad enough, with the worse one likely being the last one. Why? Because the client of the project did put their trust in the project team that they could deliver on the defined and agreed upon objectives. That trust has now evaporated…! To build trust takes a long time, and much effort. To rebuild trust takes an even longer time and more effort. For these reasons, project risk analysis should begin early, during the project planning phase. Because project risk occurrences have a direct impact on time, cost, deliverables, profits, reputation, and trust, the business analyst and project manager should work closely together to identify what the risks to the project are, and how to address them should they occur.
- Everybody knows that in any project undertaking, there are risks that may affect the project, and there are risks that will surface and do affect the project. Hardly anyone will argue that this is a fact. So why is risk analysis and risk management so elusive? There are a number of reasons as seen on this slide. It is my opinion, that the last bullet point is the truly main reasons why project risk analysis and risk management is so difficult. It is that cultural bias, be that nationality related culture, or organizational culture, that hinders stakeholders to communicate about the possible risks a project faces. And without good communication, there is obviously no analysis. Why is there this lack of communication about risk? To a large degree, because what risk actually is, isn’t properly understood.
- From these questions you can already see that there is a direct correlation between various types of risk occurrences and how they affect project deliverables. If project deliverables are impacted, that means that project requirements must be impacted as well. In turn that directly influences the projects scope and vision.
- This is a sampling of areas where project related risks may lurk. The list is by no means comprehensive. Much of the risk focus areas depend on the type of project the BA and PM are engaged in. Each of these project spaces can carry with them factors that can expose a project to influences that may inhibit the success of a project. To identify these factors, the business analyst and project manager must ask appropriate questions that expose the risk factors and reveal what in particular the impact on project deliverables can be potentially.
- Obviously, depending on the answer to each of these questions, project deliverables and hence project deliverable analysis, can be impacted positively or negatively.
- The first question is important because if the answer to it is “yes”, it adds additional risks to the management of the project, as well as to the delivery of the correct product…. …to minimize the added risk due to culturally divergent stakeholders the project team must ensure that it clearly understands what motivates stakeholders about this project. Why are they interested in what it delivers? Without an understanding of these aspects, risk to the project increases. All these questions are important because their answers reveal how likely certain risks are to materialize or not.
- Based on the last seven slides we can identify threats to a project and it’s deliverable to be:
- The ten items stated on this slide all relate to risks that are very specific to the work of a business analyst. Let’s briefly discuss them one by one: There is no point in starting detailed requirements analysis if the scope of the deliverable isn’t clear yet. First, you must understand and document the product scope and get agreement on it from the project stakeholders. The project charter is a milestone document, and the BA must know what the charter contains, because it specifies requirements of the deliverable at a high level. It also specifies constraints, that affect the analysis effort and the scope of the project. … That is a major red flag! It indicates that requirements analysis has not in the past, and likely is still not high on the priority list when it comes to executing a project. If that is the case, the BA has an uphill battle throughout the project, and often will not be able to get the support necessary to provide the value needed. When that happens, it becomes more difficult to understand what the current state is, where the problems are, how the new solution will fit into the existing systems, etc. These things must be understood however. W/o As-Is documentation, it must be created. If the project budget and timeline does not allow for that, it means that the analysis effort for the project deliverable has to happen w/o a clear understanding how it fits into the existing system infrastructure, business processes, data structures and management, etc. It should be pretty obvious that this scenario spells major risk to deliverable quality and stakeholder satisfaction. If business requirements change during the analysis effort that is OK, to a degree, as long as scope is not significantly affected. However, if business requirements change during the engineering effort, it poses risks to the estimated budget, timeline, agreed upon deliverables, and other systems, as the impact on these has not been investigated. Knowledgeable stakeholder input is crucial. They are the ones that know what is needed, what works, doesn’t work, works sometimes, and how it could work better. The know where the hurdles are, who to talk to, and who not to talk to, etc…. They can’t all be ranked high. Either somebody is not wanting to take the time to figure it out – which makes you wonder if you want that person on the team – or maybe they don’t know how to go about creating a meaningful ranking structure. Either way, this is a good opportunity to get with stakeholders and have a workshop to determine which requirements of highest importance and which are not. You may be surprised how much more you will likely learn about the projects deliverable during such a discussion. By proactively engaging stakeholders in this manner, risk of incorrect requirements implementation is reduced. If this is the case, it reveals a much larger underlying problem. It is a significant risk to the project as a whole. It demonstrates a lack of commitment to project. With little of no commitment the project is doomed to fail. If there are several BA’s working on a project and they are not doing their job in communicating requirements to various stakeholders, either at all, or not using techniques easily understood depending on requirements type and/or circumstances, it can significantly add risk of creating an incorrect solution.
- There really is nothing inherently complicated about the process of performing risk analysis. Naturally, the first step is to detect what the potential risk factors are, by identifying the uncertainties that exist on the project. Once the analyst has a list of these factors, analysis of each one can begin in greater detail. Finally, as the understanding of each risk factor grows, prioritization of them can be performed. Now the question is: How is this done? What are the best approaches to identify uncertainties on a project? Read and understand the entire project plan. The BA must first understand the project objectives and scope, before being able to identify the scope of project risk. Use or establish a IT project risk taxonomy. Next, the analyst must ensure to identify actual real risks or uncertainties, not causes, effects, or problems!
- An IT risk taxonomy is an excellent tool in identifying product and project risks. It provides a framework for organizing, identifying, and studying the breadth and depth of IT engineering issues and uncertainties, hence risks. As can be seen on the slide, the taxonomy is arranged into three major categories: Product Engineering: this covers the technical aspects of the work that the project must perform to meet the clients business needs and complete the project. Engineering Environment: this addresses methods, procedures, and tools used during project execution to create the final product according to the clients needs. Program Constraints: contractual, organizational, and operational factors within which the IT engineering effort is undertaken. This generally lies outside the direct control of the projects management These three major categories are further divided into elements, each characterized by a set of attributes. Having a risk taxonomy is a great tool to identify risks in the three major areas, or classes, of a project: risks exist in the area of engineering the product as well as in the environment in which the engineering effort takes place. Risks to the success of the project also comes from aspects that constrain the project; things that are outside the immediate control of the project, but still can have a significant impact on its outcome. Obviously, risk identification is crucial. You can’t analyze risks, that you have not first identified as risks. There is one important aspect in identifying risks. That is, the analyst most ensure that what is being categorized as a risk is not in reality an effect, or consequence of the risk having materialized. Consider these examples: “Because our organization has never done a project like this before (fact = cause), we might misunderstand the customer's requirement (uncertainty = risk), and our solution would not meet the performance criteria (contingent possibility = effect on objective).” “We have to outsource production (cause); we may be able to learn new practices from our selected partner (risk), leading to increased productivity and profitability (effect).”
- This is the basic process for identifying risks using a taxonomy model. Note, that the distinction between risk identification, risk analysis, and prioritization is not crisp and clear. Because obviously, as one identifies risks, analysis of this risk is taking place. The point is, to focus on identifying risks relevant to the project at hand. A taxonomy based approach as shown in this model, is an excellent way to perform this task.
- Risks must be identified if they are to be successfully managed. But risk is not the same as uncertainty, and risks must be separated from their causes and their effects. We must be clear about what we are trying to identify. Why is this important? Because if due to incorrect risk identification, contingency plans are put in place that address the effects of risks, instead of the actual risk, or the cause of the risk, the underlying problem that creates the unintended results has not been addressed. That means, it will occur again! Not only that. Time and resources have been squandered. And depending on the gravity of the risk, significant negative outcomes may be the consequence. So how does one ensure one identifies truly risks and causes, instead of effects? That is, how does one clearly separate risk from cause and effect? One proven method is by using a risk meta-language; i.e.: a formal description with required elements. It is a three-part structured risk statement as shown on this slide. Notice, that if one formulates the sentence as shown here, it becomes clear what causes the risk and the effect it has.
- The RBS is conceptually similar to a work breakdown structure, in that it identifies the big areas where risks can occur, and breaks it down into manageable size pieces. It is an excellent way to organize the work that must be performed in identifying areas of risk towards the completion of a project’s deliverable. As a visual aid, it can also be used by the BA in communicating with the PM and with other project stakeholders. Here is a typical RBS structure. Of course, this should be modified to fit the particular project scope and environment at hand.