The Final-Term for PRM702, "Project Quality and Risk Management" includes the whole syllabus,

however more focus will be on the Post-Midterm Syllabus. The details of your Final-Term for
PRM702 are as follows;
Lectures Included: 01 to 32.
Total Marks: 50.
Time Required: 3 Hours.
Paper Pattern: 10 Short Questions=20 Marks(2 for each) + 3 Long Question(Out of 4)=30 Marks
At-Least 2 Long-Questions ll be from practical topics, which are given below;
1. W.B.S
2. Responsibility Assignment Matrix
3. Risk Register/Risk Assessment Matrix
4. Change, Request form
5. Project Status Plan,
6. Project Life-cycle
7. Project Network Diagram
8. Project Proposal
9. Cause and Effect Analysis/Fish Bone Diagram
10. Pareto/Control Charts
11. Decision Tree
12. Communication Plan,
13. Flow-charting
14. Risk Management Plan
15. Risk Breakdown Structure.
Important tips for attaining maximum marks: Focus from Lecture # 17-32, Know how to work
on above mentioned practical topics.
Hope you all do well in the exam.
Regards,
Adil Hashmi.

WSB
work breakdown structure of an aircraft system.

A work breakdown structure (WBS), in project management and systems engineering, is a deliverable
oriented decomposition of a project into smaller components.
A work breakdown structure element may be a product, data, service, or any combination thereof. A WBS
also provides the necessary framework for detailed cost estimating and control along with providing
guidance for schedule development and control.[1]
Overview
WBS is a hierarchical and incremental decomposition of the project into phases, deliverables and work
packages. It is a tree structure, which shows a subdivision of effort required to achieve an objective; for
example a program, project, and contract.[2] In a project or contract, the WBS is developed by starting with
the end objective and successively subdividing it into manageable components in terms of size, duration,
and responsibility (e.g., systems, subsystems, components, tasks, subtasks, and work packages) which
include all steps necessary to achieve the objective.
The work breakdown structure provides a common framework for the natural development of the overall
planning and control of a contract and is the basis for dividing work into definable increments from which
the statement of work can be developed and technical, schedule, cost, and labor hour reporting can be
established.[2]
A work breakdown structure permits summing of subordinate costs for tasks, materials, etc., into their
successively higher level parent tasks, materials, etc. For each element of the work breakdown
structure, a description of the task to be performed is generated. [3] This technique (sometimes called
a system breakdown structure [4]) is used to define and organize the total scope of a project.

The WBS is organised around the primary products of the project (or planned outcomes) instead of the
work needed to produce the products (planned actions). Since the planned outcomes are the desired
ends of the project, they form a relatively stable set of categories in which the costs of the planned actions
needed to achieve them can be collected. A well-designed WBS makes it easy to assign each project
activity to one and only one terminal element of the WBS. In addition to its function in cost accounting, the
WBS also helps map requirements from one level of system specification to another, for example a
requirements cross reference matrix mapping functional requirements to high level or low level design
documents.

Responsibility assignment matrix

A responsibility assignment matrix[1] (RAM), also known as RACI matrix[2] /resi/ or ARCI
matrix or linear responsibility chart[3] (LRC), describes the participation by various roles in
completing tasks or deliverables for a project or business process.[4] It is especially useful in clarifying
roles and responsibilities in cross-functional/departmental projects and processes. [5]
RACI and ARCI are acronyms derived from the four key responsibilities most typically
used: Responsible, Accountable, Consulted, and Informed.[6]

Key responsibility roles[edit]

Responsible
Those who do the work to achieve the task.[7] There is at least one role with a participation type
of responsible, although others can be delegated to assist in the work required (see
alsoRASCI below for separately identifying those who participate in a supporting role).
Accountable (also approver or final approving authority)
The one ultimately answerable for the correct and thorough completion of the deliverable or task,
and the one who delegates the work to those responsible.[7] In other words, an accountablemust
sign off (approve) on work that responsible provides. There must be only
one accountable specified for each task or deliverable.[4]
Consulted (sometimes counsel)
Those whose opinions are sought, typically subject matter experts; and with whom there is twoway communication.[7]
Informed
Those who are kept up-to-date on progress, often only on completion of the task or deliverable;
and with whom there is just one-way communication. [7]

Very often the role that is accountable for a task or deliverable may also
be responsible for completing it (indicated on the matrix by the task or deliverable
having a role accountable for it, but no role responsible for its completion, i.e. it is
implied). Outside of this exception, it is generally recommended that each role in the
project or process for each task receive, at most, just one of the participation types.
Where more than one participation type is shown, this generally implies that participation
has not yet been fully resolved, which can impede the value of this technique in
clarifying the participation of each role on each task.

Role distinction[edit]
There is a distinction between a role and individually identified people: a role is a
descriptor of an associated set of tasks; may be performed by many people; and one
person can perform many roles. For example, an organisation may have ten people who
can perform the role of project manager, although traditionally each project only has one
project manager at any one time; and a person who is able to perform the role of project
manager may also be able to perform the role of business analyst and tester.

Matrix format and Examples[edit]

The matrix is typically created with a vertical axis (left-hand column) of tasks (e.g., from
a work breakdown structure WBS) or deliverables (e.g., from a product breakdown
structure PBS), and a horizontal axis (top row) of roles (e.g., from an organizational
chart) as illustrated in the image of an example responsibility assignment (or RACI)
matrix.

Risk register

A Risk Register is a Risk Management tool commonly used in Project Management and organisational risk
assessments. It acts as a central repository for all risks identified by the project or organisation and, for each
risk, includes information such as risk probability, impact, counter-measures, risk owner and so on. It can
sometimes be referred to as a Risk Log (for example inPRINCE2).
A wide range of suggested contents for a risk register exist and recommendations are made by the Project
Management Institute Body of Knowledge (PMBOK) and PRINCE2 among others. In addition many companies
provide software tools that act as risk registers. Typically a risk register contains:

A description of the risk

The impact should this event actually occur

The probability of its occurrence

Risk Score (the multiplication of Probability and Impact)

A summary of the planned response should the event occur

A summary of the mitigation (the actions taken in advance to reduce the probability and/or impact of
the event)

The risks are often ranked by Risk Score so as to highlight the highest priority risks to all involved.

Example Risk Register in table format[edit]

Risk Register for project "birthday party"

Risk
Risk Probability Impact Risk
Risk Name
Category
Number
(1-3)
(1-3) Score

Guests

The guests
find the
party
boring

1.1.

Mitigation

Invite crazy
friends,
provide
sufficient
liquor

Contingency

Bring out
the karaoke

Action
By

Mack

within
2hrs

Jerry

Now

Guests

Drunken
brawl

1.2.

Dont invite
crazy friends,
don't provide Call 911
too much
liquor

Nature

Rain

2.1.

Have the party Move the party

Milind
indoors
indoors

Nature

Earthquake 2.2.
or fire

Start the party

with
instructions
on what to do
in the event of
fire or

Action
When

10mins

Implement the Everyone As per

appropriate
plan
natural disaster
response plan

earthquake

Food

Not enough
3.1.
food

Have a buffet Order pizza

Magua

Food

Food is
spoiled

Store the food

in deep
Order pizza
freezer

Matthew
30mins
Susi

3.2.

30mins

Useful terminology[edit]
In a "qualitative" risk register descriptive terms are used: for example a risk might have a "High" impact and a
"Medium" probability.
In a "quantitative" risk register the descriptions are enumerated: for example a risk might have a "$1m" impact
and a "50%" probability.
Contingent response - the actions to be taken should the risk event actually occur.
Contingency - the budget allocated to the contingent response
Trigger - an event that itself results in the risk event occurring (for example the risk event might be "flooding"
and "heavy rainfall" the trigger)

Risk Matrix
From Wikipedia, the free encyclopedia
(Redirected from Risk Assessment Matrix)

This article needs additional citations for verification. Please help improve this article by adding
citations to reliable sources. Unsourced material may be challenged and removed. (May 2009)
A Risk is the amount of harm that can be expected to occur during a given time period due to specific harm
event (e.g., an accident). Statistically, the level of risk can be calculated as the product of the probability that
harm occurs (e.g., that an accident happens) multiplied by the severity of that harm (i.e., the average amount of
harm or more conservatively the maximum credible amount of harm). In practice, the amount of risk is usually
categorized into a small number of levels because neither the probability nor harm severity can typically be
estimated with accuracy and precision.

A Risk Matrix is a matrix that is used during Risk Assessment to define the various levels of risk as
the product of the harm probability categories and harm severity categories. This is a simple mechanism to
increase visibility of risks and assist management decision making.
Although many standard risk matrices exist in different contexts (US DoD, NASA, ISO), [1][2][3] individual projects
and organizations may need to create their own or tailor an existing risk matrix.
For example, the harm severity can be categorized as:

Catastrophic - Multiple Deaths

Critical - One Death or Multiple Severe Injuries

Marginal - One Severe Injury or Multiple Minor Injuries

Negligible - One Minor Injury

The probability of harm occurring might be categorized as 'Certain', 'Likely', 'Possible', 'Unlikely' and 'Rare'.
However it must be considered that very low probabilities may not be very reliable.
The resulting Risk Matrix could be :

Negligible

Marginal

Critical

Catastrophic

Certain

High

High

Extreme

Extreme

Likely

Moderate

High

High

Extreme

Possible

Low

Moderate

High

Extreme

Unlikely

Low

Low

Moderate

Extreme

Rare

Low

Low

Moderate

High

The company or organization then would calculate what levels of Risk they can take with different events. This
would be done by weighing up the risk of an event occurring against the cost to implement safety and the
benefit gained from it.

Contents
[hide]

1 An Example

2 Problems with Risk Matrix

3 References

4 External links

An Example[edit]
The following is an example risk matrix with certain accidents allocated to appropriate cells within the matrix:

Negligible

Certain

Likely

Marginal

Critical

Catastrophic

Stubbing Toe

Minor Car Accident

Possible

Major Car Accident

Unlikely

Aircraft Crash

Rare

Major Tsunami

Ishikawa diagram
Ishikawa diagrams (also called fishbone diagrams, herringbone diagrams, cause-and-effect diagrams,
or Fishikawa) are causal diagramscreated by Kaoru Ishikawa (1968) that show the causes of a specific event.
[1][2]

Common uses of the Ishikawa diagram are product design and quality defect prevention, to identify

potential factors causing an overall effect. Each cause or reason for imperfection is a source of variation.

Causes are usually grouped into major categories to identify these sources of variation. The categories typically
include:

People: Anyone involved with the process

Methods: How the process is performed and the specific requirements for doing it, such as policies,
procedures, rules, regulations and laws

Machines: Any equipment, computers, tools, etc. required to accomplish the job

Materials: Raw materials, parts, pens, paper, etc. used to produce the final product

Measurements: Data generated from the process that are used to evaluate its quality

Environment: The conditions, such as location, time, temperature, and culture in which the process
operates

Overview[edit]

Ishikawa diagram, in

fishbone shape,

showing factors of

Equipment, Process,

People, Materials,

Environment and

Management, all

affecting the overall

problem. Smaller arrows

connect the sub-

causes to major causes.

10

Ishikawa diagrams were popularized by Kaoru Ishikawa[3] in the 1960s, who pioneered quality management
processes in the Kawasakishipyards, and in the process became one of the founding fathers of modern
management.
The basic concept was first used in the 1920s, and is considered one of the seven basic tools of quality control.
[4]

It is known as a fishbone diagram because of its shape, similar to the side view of a fish skeleton.

Mazda Motors famously used an Ishikawa diagram in the development of the Miata sports car, where the
required result was "Jinba Ittai" (Horse and Rider as One jap. ). The main causes included such
aspects as "touch" and "braking" with the lesser causes including highly granular factors such as "50/50 weight
distribution" and "able to rest elbow on top of driver's door". Every factor identified in the diagram was included
in the final design.

Causes[edit]
Causes in the diagram are often categorized, such as to the 6 M's, described below. Cause-and-effect
diagrams can reveal key relationships among various variables, and the possible causes provide additional
insight into process behavior.
Causes can be derived from brainstorming sessions. These groups can then be labeled as categories of the
fishbone. They will typically be one of the traditional categories mentioned above but may be something unique
to the application in a specific case. Causes can be traced back to root causes with the 5 Whys technique.
Typical categories are:

The 6 Ms (used in manufacturing industry)[edit]

Machine (technology)

Method (process)

Material (Includes Raw Material, Consumables and Information.)

Man Power (physical work)/Mind Power (brain work): Kaizens, Suggestions

Measurement (Inspection)

Milieu/Mother Nature (Environment)

The original 6Ms used by the Toyota Production System have been expanded by some to include the following
and are referred to as the 8Ms. However, this is not globally recognized. It has been suggested to return to the

11

roots of the tools and to keep the teaching simple while recognizing the original intent; most programs do not
address the 8Ms.

Management/Money Power

Maintenance

Flowchart
From Wikipedia, the free encyclopedia

For the music group, see Flowchart (band).

A simple flowchart representing a process for dealing with a non-functioning lamp.

A flowchart is a type of diagram that represents an algorithm or process, showing the steps as boxes of
various kinds, and their order by connecting them with arrows. This diagrammatic representation illustrates a
solution to a given problem. Process operations are represented in these boxes, and arrows; rather, they are
implied by the sequencing of operations. Flowcharts are used in analyzing, designing, documenting or
managing a process or program in various fields. [1]

Overview[edit]
12

Flowcharts are used in designing and documenting complex processes or programs. Like other types of
diagrams, they help visualize what is going on and thereby help the viewer to understand a process, and
perhaps also find flaws, bottlenecks, and other less-obvious features within it. There are many different types of
flowcharts, and each type has its own repertoire of boxes and notational conventions. The two most common
types of boxes in a flowchart are:

a processing step, usually called activity, and denoted as a rectangular box

a decision, usually denoted as a diamond.

A flowchart is described as "cross-functional" when the page is divided into different swimlanes describing the
control of different organizational units. A symbol appearing in a particular "lane" is within the control of that
organizational unit. This technique allows the author to locate the responsibility for performing an action or
making a decision correctly, showing the responsibility of each organizational unit for different parts of a single
process.
Flowcharts depict certain aspects of processes and they are usually complemented by other types of diagram.
For instance, Kaoru Ishikawa defined the flowchart as one of the seven basic tools of quality control, next to
the histogram, Pareto chart, check sheet, control chart, cause-and-effect diagram, and the scatter diagram.
Similarly, in UML, a standard concept-modeling notation used in software development, the activity diagram,
which is a type of flowchart, is just one of many different diagram types.
Nassi-Shneiderman diagrams and Drakon-charts are an alternative notation for process flow.
Common alternate names include: flowchart, process flowchart, functional flowchart, process map, process
chart, functional process chart, business process model, process model, process flow diagram, work flow
diagram, business flow diagram. The terms "flowchart" and "flow chart" are used interchangeably.

13

Risk management plan

From Wikipedia, the free encyclopedia
(Redirected from Risk Management Plan)

A Risk Management Plan is a document that a project manager prepares to foresee risks, estimate impacts,
and define responses to issues. It also contains a risk assessment matrix.
A risk is "an uncertain event or condition that, if it occurs, has a positive or negative effect on a project's
objectives."[1] Risk is inherent with any project, and project managers should assess risks continually and
develop plans to address them. The risk management plan contains an analysis of likely risks with both high
and low impact, as well as mitigation strategies to help the project avoid being derailed should common
problems arise. Risk management plans should be periodically reviewed by the project team to avoid having
the analysis become stale and not reflective of actual potential project risks.

14

Most critically, risk management plans include a risk strategy. Broadly, there are four potential strategies, with
numerous variations. Projects may choose to:

Avoid risk Change plans to circumvent the problem;

Control/Mitigate risk; Reduces impact or likelihood (or both) through intermediate steps;

Accept risk Take the chance of negative impact (or auto-insurance), eventually budget the cost (e.g.
via a contingency budget line);

Transfer risk Outsource risk (or a portion of the risk - Share risk) to third party/ies that can manage
the outcome. This is done e.g. financially through insurance contracts or hedging transactions, or
operationally through outsourcing an activity.

(Mnemonic: SARA for Share Avoid Reduce Accept, or A-CAT for "Avoid, Control, Accept, or Transfer")
Risk management plans often include matrices.
The United States Department of Defense, as part of acquisition, uses risk management planning that may
have a Risk Management Plan document for the specific project. The general intent of the RMP in this context
is to define the scope of risks to be tracked and means of documenting reports. It is also desired that there
would be an integrated relationship to other processes. An example of this would be explaining which
developmental tests verify risks of the design type were minimized are stated as part of the Test and Evaluation
Master Plan. A further example would be instructions from 5000.2D

[2]

that for programs that are part of

a System of systems the risk management strategy shall specifically address integration and interoperability as
a risk area. The RMP specific process and templates shift over time (e.g. the disappearance of 2002
documents Defense Finance and Accounting Service / System Risk Management Plan, and the SPAWAR Risk
Management Process).

15