CSQA Exam Dumps - Software Certifications Software Certification Questions and Answers

Risk management is the process used to identify, analyze, and respond to a risk. Identifying, analyzing, and prioritizing risks require knowledge of the business functions, and user involvement. The Project Management Institute's Project Management Body of Knowledge(PMBOK) defines the following four processes to address risk management. The PMBOK also notes that different application areas may use different names for these four processes.

Risk Identification

Risk Quantification

Risk Response Development

Risk Response Control

This discussion of risk management addresses six processes, which have the following mapping to the PMBOK processes.

Risk Identification

Risk Identification – this process answers the question "What are the risks?"

Risk Quantification

Risk Analysis - this process answers the question "Which risks do we care about?"

Risk Prioritization - this process answers the question "How are the risks prioritized?"

Risk Response Development

Planning - this process answers the question "What should be done about the risk?"

Risk Response Control

Risk Resolution – this process executes the plan that was developed in the prior step.

Risk Monitoring – this process evaluates the action taken, documents the risk results and repeats the cycle of identification, quantification and response.

Organizations choose to adopt a model for any or all of the following reasons:

Satisfy business goals and objectives

If the current infrastructure and processes are not meeting business goals and directives, adopting a model can refocus the IT organization to meet those goals and objectives.

Requirements are imposed by customer(s)

In an effort to improve efficiency and effectiveness, key customers may direct the IT organization to adopt a model.

For competitive reasons

External customers may only do business with an IT organization that is in compliance with a model.

As a guide (roadmap) for continuous improvement

A model usually represents the combined learning of leading organizations, and, as such, provides a roadmap for improvement. This is particularly true of continuous models.

The workbench transforms to the input to produce the output. The workbench is comprised of two procedures: Do and Check, which correspond to the Do and Check phases of the PDCA cycle. If the Check procedure determines that the standards for the output product are not met, the process engages in rework until the output products meet the standards, or management makes a decision to release a nonstandard product. People, skills, and tools support the Do and Check procedures. A process is defined by workbench and deliverable definitions. A process is written with the assumption that the process owners and other involved parties possess certain skill and knowledge levels (subject matter expertise).

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-13 at 2.13.25 AM.png

To map processes, executive management (Quality Council) must have identified the organization's mission, long and short-term goals, organizational structure, and deliverables. If formal strategic planning is not regularly performed, identifying an organization's mission and goals is difficult.

Processes should be mapped to mission and goals, to functional units (people), and to deliverables in separate matrices. The following generic process can be used for each mapping:

1. Create a matrix.

2. List processes across the top of the matrix.

3. On the left side of the matrix, list the goals, functional units or roles or deliverables.

4. Identify the linkages between the rows and columns, as follows:

A process may support multiple goals. Put an X in the intersection to acknowledge a linkage only if the stability or quality of the process could influence meeting goals. If all processes contribute to all goals, decompose the mission and goals further. The resulting Manage-by-Process matrix is a process map.

Processes have primary owners, suppliers and customers. Identify a linkage in this matrix by using “O”, “S” or “C” in the intersection to distinguish between the roles.

Deliverables can be internal such as design specifications, or external such as user manuals. In this matrix indicate the usage of the deliverable by placing a “C”, “R”, “U” and/or “D” in the intersection. “C” is used when the deliverable is created, or the service is provided through the process. “R” indicates the deliverable is referenced or used as input to the process. “U” indicates the deliverable is updated or revised in the process. “D” means the deliverable is deleted, or retired, etc.

5. For mission and goal mapping, look for gaps where goals are not supported by processes. Consider removing any processes that do not support goals, as they do not add value. For functional unit mapping, look for gaps where units do not have processes. For deliverable mapping, look for gaps where deliverables do not have processes or vice versa.

6. If the mapping identified any new processes, add them to the inventory.