Identify+Risk

4.1 Define the Risk Identification Process toc
Risk Identification is the first step in Risk Management Process and is described as the activities and methods used to discover risk. If the engineer or software team knows the risk that they are or will be dealing with, then they have a better chance of avoiding or lowering the cost due to the identified risk. The Risk Identification Process can be described in two views :
 * 1) The **External View** is the process controls, inputs and mechanism.
 * 2) The **Internal View** is the process that it takes to take all the inputs and get an output.

4.1.1 Process Goals
Process Goals are a set of rules that will suffice the risk identification process and also ensure the process quality. These goals are:
 * Letting the team input perceived risk into the process. Involving the team is a way to come up with risk not seen by management.
 * Identifying the risk before it’s too late. That will save cost or injuries if you are dealing with critical systems.
 * Finding the sources of the risk and the risk. If the team knows what is causing the risk (i.e. power supply, etc…) they have a greater chance of fixing the problem.
 * Taking note of every risk, do not talk about it and not write anything down. People get moved around from projects to projects, you have to write everything down, so that the next team member has current knowledge of the system.
 * Communicating risk to those who can solve it. If it is a power supply, the software lead should talk with the engineer that designed or have the knowledge of the power circuit design, he would be the best one to know how to fix the problem.
 * Preventing project surprises. Surprises are unforeseen events and that will lower the process quality by causing time delay, cost, or assigning manpower to name a few.

4.1.2 Process Definition

 * **Control** – Determines when and how the process is executed. The top right section of the IDEF0 is the control of the process. Project Resources, Project Requirements, and Risk Management Plan regulate the risk identification process.
 * **Process Inputs** – An item required for a process transformation that meets the process entry criteria. The top left of the IDEF0 is the process input of the process. Uncertainty is what we do not know, Knowledge is what we do know, Concerns is what we fear, and issue is a matter that is unresolved with respect to other people.
 * **Process Outputs** - a result of a process transformation that meets the process entry criteria. The bottom right of the IDEF0 is the process output. A risk statement is a concise declaration of risk in a standard notation that includes the issue, probability and consequence.
 * **Process Mechanism** – Determines the methods the process uses. The bottom left of the IDEF0 is the process mechanism. A risk checklist contains typical risk areas that relate to the checklist topic. A risk database is a repository of identified risks, it assigned sequential numbers and maintains the history of all identified risks.



4.1.3 Process Activities
The process activities are the tasks that transform uncertainty into a risk statement.
 * 1) Conduct risk assessment. The risk assessment identifies risk and evaluates risk based on established criteria. This step should take place early in the project; you do not want to wait until it is too late.
 * 2) Identify risk systematically. Identify the risk in a way that is understandable like using a checklist, doing a group interview, hosting a meeting, and etc...
 * 3) Define the risk attributes. After the issue is identified, you can be certain it is a risk by defining the major risk attributes of probability and consequence.
 * 4) Document identified risk by writing a statement of risk containing a brief description of the risk issue, the probability, and the consequence in subjective terms.
 * 5) Communicate identified risk is sharing the information either through written or verbal. Find ways to communicate about the risk to the team.

4.2 Develop Risk Checklists
A risk Checklist is a way to generate and provide a systematic way to identify risk. Unknown risk can be discovered by reviewing the critical success factors, listing all items in the critical path of the schedule, and itemizing the project interfaces, internal and external.

4.2.1 Software Risk Taxonomy
The SEI Risk Taxonomy is a structured checklist that organizes known software development risks from the general classes to specific element attributes. If you look at the chart bellow you can look under the Product Engineering and see what known risk are under each phase, like under requirements a risk would be the feasibility of obtaining the goal. Contractors || Constraints || a. Planning || d. Prime contractor || software || b. Project organization || e. Corporate management || implementation || a. Monitoring ||  || Management ||  || management ||  || Specialties** || b. Cooperation ||  ||
 * **Product Engineering** || **Development Engineering** || **Program Constraints** ||
 * **1. Requirements** || **1. Development Process** || **1. Resources** ||
 * a. Stability || a. Formality || a. Schedule ||
 * b. Completeness || b. Suitability || b. Staff ||
 * c. Clarity || c. Process Control || c. Budget ||
 * d. Validity ||  || d. Facilities ||
 * e. Feasibility || **2. Development System** ||  ||
 * f. Precedent || a. Capacity || **2. Contract** ||
 * g. Scale || b. Suitability || a. Type of contract ||
 * || c. Usability || b. Restrictions ||
 * **2. Design** || d. Familiarity || c. Dependencies ||
 * a. Functionality || e. Reliability ||  ||
 * b. Difficulty || f. System support || **3. Project Interfaces** ||
 * c. Interfaces || g. Deliverability || a. Customer ||
 * d. Performance ||  || b. Associate
 * e. Testability || **3. Management Process** || c. Subcontractors ||
 * f. Hardware
 * g. Non-developmental
 * || c. Management experience || f. Vendors ||
 * **3. Code and Unit Test** || d. project interfaces || g. Politics ||
 * a. Feasibility ||  ||   ||
 * b. Unit test || **4. Management Methods** ||  ||
 * c. Coding/
 * || b. Personnel
 * **4. Integration test** || c. Quality assurance ||  ||
 * a. Environment || d. Configuration
 * b. Product ||  ||   ||
 * c. System || **5. Work Environment** ||  ||
 * || a. Quality attitude ||  ||
 * **5. Engineering
 * a. Maintainability || c. Communication ||  ||
 * b. Reliability || d. Morale ||  ||
 * c. Safety ||  ||   ||
 * d. Security ||  ||   ||
 * e. Human factors ||  ||   ||
 * f. Specifications ||  ||   ||

4.2.2 Work Breakdown Structure(WBS)
The work break down structure provides a framework for identifying specific project risk. I’ve used the WBS as a way to identify risk. The WBS tracks works that are not budgeted or scheduled, which can lead to higher risk. The WBS can be used as a checklist also. Bellow is an example of a WBS. Occurrence** || **Consequences** Exposure** || Interfaces || Moderate || Low || Low ||
 * **1** || **2** || **3** || **4** || **Title** || **Probability of
 * at Occurrence** || **Risk
 * 01- ||  ||   ||   || TEG-32 Project || Moderate || High || High ||
 * 01- || 01- ||  ||   || Prime item || Moderate || High || High ||
 * 01- || 01- || 01- ||  || GPS || High || High || High ||
 * 01- || 01- || 01- || 01 || Recievers || High || Low || Moderate ||
 * 01- || 01- || 02- || 01 || Interference || Low || High || Moderate ||
 * 01- || 01- || 02- || 02 || Antennas || Moderate || Moderate || Moderate ||
 * 01- || 01- || 03- || 01 || Processor || Low || Moderate || Low ||
 * 01- || 01- || 04- || 01 || Comm

4.3 Define the Risk Assessment Method
The Risk assessment method used is an interview style method used to identify and appraise risk. Training to be better able to identify risk is part of the risk assessment objective.

4.3.1 Assessment Preparation
The risk assessments are performed by an assessment team trained in basic risk concepts. The team is responsible for reviewing the project profile, which contains unit aspects of the project that are part of the software risk taxonomy. The assessment preparation consists of:
 * 1) Selecting and training the assessment team.
 * 2) Reviewing the project file.
 * 3) Selecting the interview participants.
 * 4) Preparing the risk assessment schedule.
 * 5) Coordinating the meeting logistics.
 * 6) Briefing the project participants.

4.3.2 Interview Session
The interview is conducted by the assessment team using the SEI taxonomy-based questionnaire. The interview protocol should be non-judgmental and non attributive environment, so that it could be open to more controversial views. The interview process consists of an interviewer, a recorder, and an observer. The task from the interview process is as follow:
 * 1) Interview the peer group.
 * 2) Record the Risks.
 * 3) Clarify the risk statements.
 * 4) Observe and document the process results.

4.3.3 Preliminary Risk Analysis
Preliminary Risk Analysis is where the participants assess the risk statements according to defined evaluation criteria. The preliminary risk analysis is done by the assessment team and takes place after the participants have left the room; they review each risk assessment and classify them according to the SEI risk taxonomy. Their task is to:
 * 1) Evaluate the identified risk.
 * 2) Evaluate the interview session.
 * 3) Categorize the risks.
 * 4) Enter the risk in the risk database.

4.3.4 Results and Retrospective
Results and Retrospective is developing viewgraphs to summarize finding of the interview session. Visualizing the info gathered from the interview sessions, and is also debriefed to the project manager. The following tasks are part of the result and retrospective section:
 * 1) Prepare the result briefing.
 * 2) Debrief the project manager.
 * 3) Brief the project team.
 * 4) Evaluate the risk assessment.
 * 5) Distribute the risk management form.

4.4 Develop the Risk Management Form
A risk management form is used as a risk identification mechanism that anyone may submit to identify risk. The form should identify the originator, the risk information and planning.

4.5 Establish the Risk Database Schema
The risk database design should contain field to describe the risk completely, so that when someone enters a risk into the database, all of the needed information can be inputted. The database schema is the design of the fields for the risk database. An example would be to have a log number, a project, date, risk resolution and many other important fields as part of your risk database schema.