Assess+Risk

=17.0 Assess Risktoc= Risk assessment is how we discover risks. Risk assessment gives us a chance to assess what the consequence from the risk is. Assessing risk is very important when you are doing a project; you don’t want to get a surprise after your project starts. This section will help with the activities that it takes to assess a risk, and how to ass risk as a team

17.1 Conduct a Risk Assessment
The first to discovering risk is to conduct a risk assessment. A risk assessment provides the baseline of assessed risks for the project. Your risk baseline should be done early in a project so that each work is associated with its risk. The main objectives of risk assessment: You don’t have to conduct a special meeting to assess risk, you can do risk assessment whenever the project team members are together. You can do risk assessment during:
 * 1) Identify and assess risk- is the methods used to assess risk. This object is important because it helps to find the risks in your project.
 * 2) Train methods- are using what you find in the risk assessment throughout your project.
 * 3) Provide a baseline- You have to continually manage risk. The baseline provides a way to continually manage risk throughout the project.
 * Phase readiness review- you can hand out the risk assessment form and have people list the top 5 risks.
 * Team-building session- you can have the team list the top three risks to their success. This exercise goes right along with the team-building idea.
 * Technical proposal- This proposal has to respond to the technical risk design.
 * Project start-up- This part of the project, you can do peer interviews to achieve formal risk assessment. The tool used to achieve this goal is the risk taxonomy checklist.

17.1.1 Activities of a Formal Risk Assessment
A formal risk assessment is when you do peer-interviews to assess risk as we have seen in section 17.0. There are activities associated with conducting a successful formal risk assessment:
 * 1) Train team: you have to build an assessment team and train them, review the project, and select the peers that are going to be interviewed, prepare the risk assessment schedule, and coordinate meeting logistics.
 * 2) Identify Risk: is where you hold the interviews, and record all the perceived risks with the project, write an understandable risk statement, and observe and record the results.
 * 3) Analyze Risk: is to evaluate identified risks and categorize the risks.
 * 4) Abstract risk: sort the risk in a database, than prepare the findings.
 * 5) Report results: debrief project manager, and brief project team, and evaluate the risk assessment.

17.1.2 Cost of a Formal Risk Assessment
The cost of doing a formal risk assessment depends on how many people are on the risk assessment team and also how many peer interviews take place. The book suggests that you keep the number of people on the risk assessment team to three and hold a minimum of 3 peer reviews. The bigger the project team is the more interview sessions that will have to take place. The formal risk assessment method is expansive compared to the other methods since it is more time consuming.

17.2 Develop a Candidate Risk List
You can develop a risk candidate list from the top ten risks list from the project team, the work breakdown structure, and the risk checklist. A candidate risk list is about identifying risk from known areas and identifying the source of the risk in both managerial and technical areas.

17.2.1 List Known Risks
Known risks are the risk that you know about. Communication is what helps to discover known risks. Sometimes individuals might know of a risk but is afraid to bring it up. You have to separate the issue from the individual; do not play the blame game that will make people uncomfortable about speaking out about known risks. You have to report risks and report problems. Reporting problems in the organization is a way to improve the risk assessment process.

17.2.2 Discover Unknown Risks
Unknown risks are those that you do not know about, this risk can cause potential issues if they are not discovered; communicating is a way to fight unknown risk. You have to:
 * Share Knowledge -If everyone shares what they know and experience, you can discover risk by forming a clearer picture based on the experience of the team.
 * Recognize importance- we have to know the significance of that risk, you don’t want to undermine the effect of that risk. Knowing the importance of a risk help to prioritize it.
 * Accumulate indicators- A status indicator that is 10 percent off target is generally a low risk, but if you have bunch of indicators that are off they can add up to a critical risk. You have to know what the effect of numerous indicators exceeding their threshold is.

17.3 Define Risk Attributes
After having a candidate risk list you have to qualify the issue as a risk and also asses the possibility of the risk happening. If there’s no chance of the issue taking place, then you can take it out of the risk candidate list.

17.3.1 Bound the Primary Attributes
Bounding the primary risk attribute is using words or number to figure out what’s the probability of risk occurrence. The table below shows an example of bounding the primary risk attributes. It assigns points with the likeliness of the risk occurring. Highly Unlikely Almost no chance || Less than 20 percent || Probably not Unlikely || Less than 40 percent || Probably Better than ever || Less than 60 percent || Probably Likely || Less than 80 percent || Highly likely Almost certainty || Less than 100 percent ||
 * **Five-Point Score** || **Perceived Likelihood** || **Numerical Percentage** ||
 * 1 || Chances are slight
 * 2 || Little chance
 * 3 || We believe
 * 4 || We believe
 * 5 || Very good chance

17.3.2 Categorize the Risk
After assigning values to the risk, you have to categorize the risk so that people can know the nature of the risk. There are five steps to achieve this goal:
 * 1) Clarify- write the risk statement according to the standard notation.
 * 2) Consense- Agree on the meaning of the risk statement. Everyone should be one page so when it comes to the intent of the issue.
 * 3) Classify- you have to group the risks by categories. Put all the risks in categories so that you can get another way to look at the issues.
 * 4) Combine- Group all the risk statements by the above categories from step 3, then review them to get a better understanding of the categories.
 * 5) Condense- Clean up the list by removing duplicate issues and also summarizing similar risks.

17.3.3 Specify the Risk Drivers
Risk drivers are the variables that can increase the probability of a risk occurrence. After assigning the attributes, you don’t want those numbers to get skewed because of risk drivers; you have to pay attention to risk drivers because they can change the risk over a period of time. You have to identify potential risk drivers and keep monitoring them to make sure that they are not skewing your risk attribute numbers.

17.4 Document Identified Risk
Use the risk management form to document the identified risk. The risk management form is a mechanism to document risk that was covered in the first section of this project.

17.5 Communicate Identified Risk
You have to get in touch with the right personnel to discuss the identified risk. The right personnel could be a project manager, or your immediate manager, it should be someone that can actually take action against the identified risk. The organization should have a risk database, use it to document the risk, and turn in your risk management form to the person that’s in charge of it.

17.6 Estimate and Evaluate Risk
After getting everyone aware of the risk, you need to find out what is the probability of occurrence and the consequence from an occurrence. You need to figure out what is the amount of time for action. You don’t want to address it in a time amount to where it’s too late to do anything about it, which would just undermine your previous work.

17.7 Prioritize Risk
Prioritizing is doing what’s important first. The same way you would prioritize your class work, you also need to prioritize risk by the level of importance. The government and the industry have a prioritize risk list that differs but are also interrelated. Just like in the previous section the customer and the contractor have different ways of saying the same thing.

17.7.1 Government Top Ten

 * 1) Funding- Where our funding is coming from is always an issue before you can start a project in the government. I’ve experienced years where funding was above what we actually needed, and some years where we had to cut back. It affects how we plan for the fiscal year.
 * 2) Roles and Responsibilities – As a government employee, I can say that not everyone know their roles in a project, sometimes you have Project management making engineering decisions without consulting the engineer, which most of the time leads to disaster.
 * 3) Staff Expertise- in the Government, you have a lot of people that are moving around, especially on the program management. I’ve been there for 3 years, and already had 2 program managers. By the time you get a program manager that knows the program, a new one takes its place and the whole process starts again.
 * 4) Development Process- There’s a lack of communication in the development process. I am currently working on a repair contract for hardware unit and program manager and I had different part numbers in our documents. The other problem with development process is getting something through the chain of command or contracting, everyone have their own personal way they want things to get done, there’s no consistency.
 * 5) Project Planning- The planning process is not well defined. We do have a planning process, but no one follows the plan, things change, meetings get canceled.
 * 6) Project Interfaces- Usually people are working on multiple projects which can sometimes be a daunting task. I am currently working on a buy and a repair contract, sometimes I got to meetings not knowing which on is it for.
 * 7) System Engineering- System engineering are informally distributed throughout the project.
 * 8) Requirements- Every head quarters have their own requirements and sometimes it’s hard to bring all of it together, especially if they are conflicting requirements. We sometimes have to field different versions of everything, which makes it hard to manage.
 * 9) Schedule- It’s hard to get things on schedule not only because of requirement changes, but also the process of getting anything done itself, it goes through so many hands, that you have to wait till it goes up the chain before you can go ahead.
 * 10) Testing- Inadequate testing is an issue faced by the government, sometimes testing is cut short because of other factors that have delayed the schedule.

17.7.2 Industry Top Ten
The issues facing the industry are:
 * 1) Resources- how much resource they have available towards the project. The industry is about making a profit, and resources have to be managed well to meet the bottom line.
 * 2) Requirements- if the user requirements are poorly defined, you will end up with an unhappy customer who might lose confidence in the way you run your business. You need to have an understanding of what the user need.
 * 3) Development process- having a not well defined process can cause development issues, and can cause delay in the schedule.
 * 4) Project Interfaces- We work with a contractor that waited on software from our team that was late, and that caused a significant delay on their schedule.
 * 5) Management Process- Management sometimes gets in the way of accomplishing goals because they don’t have the engineering knowledge, its mostly knowing what your role is.
 * 6) Development System- building a new system is always risky; it might work in your lab, but fails when you install it in the customer’s lab.
 * 7) Design- Design constraints are a big issue for contractors. Where the hardware is being installed makes a big difference on how you can design it.
 * 8) Management Methods- is a lack of management control over the project. No proper risk management.
 * 9) Work environment- sometimes project members are in remote locations and are not familiar with their work environment, which can cause delay in production schedule.
 * 10) Integration and Testing- Everything can look good on paper by don’t work when it’s time to test it or integrate it with existing software or hardware, which delays delivery time and increase cost.

17.7.3 Top Ten Progress and Challenges
Back in the 1980’s, projects faced risk that today have been dealt with due to the infusion of the risk process in project planning. The table below shows the list or risk from the 1980’s and where they stand currently. Priority** || **1980's Software Risk** || **Risk Category** || **Current Priority** || functions || Risk.Technical.Project || 2 ||
 * **Previous
 * 1 || personnel shortfalls || Risk.Management.Project || 1 ||
 * 2 || Unrealistic schedules and budgets || Risk.Management.Project || 1 ||
 * 3 || Developing the wrong software
 * 4 || Developing the wrong user interface || Risk.Technical.Product || 2 ||
 * 5 || Gold plating || Risk.Technical.Product || 2 ||
 * 6 || Continuing stream of requirements changes || Risk.Technical.Product || 2 ||
 * 7 || Shortfalls in externally furnished components || Risk.Management.Project || 4 ||
 * 8 || Shortfalls in externally performed tasks || Risk.Management.Project || 4 ||
 * 9 || Real-time performance shortfalls || Risk.Technical.Product || 7 ||
 * 10 || Straining computer science capabilities || Risk.Technical.Product || 7 ||