Quality Assurance Plan

Project Name

Project Code:

Internal Advisor:

External Advisor:

Project Manager:

Project Team:

Submission Date:

_____________________
Project Manager’s Signature
Employee Management System Error: Reference source not found Version x

Revision History
Date Version Description Author
<dd/mmm/yy> <x.x> <details> <name>

Comsats Lahore Page 2 of 23

Employee Management System Error: Reference source not found Version x

Table of Contents
1. Introduction 4
1.1 Purpose 4
1.2 Scope 4
1.3 Definitions, Acronyms, and Abbreviations 4
1.4 References 4
1.5 Overview 4

2. Reference Document 4

3. Management 4
3.1 Organization 4
3.2 Tasks 5
3.3 Responsibilities 5

4. Documentation 5

5. Standards and Guidelines 5

6. Review and Audit Plan 6

7. Evaluation and Test 7

8. Problem Resolution and Corrective Action 7

9. Tools, Techniques, and Methodologies 7

10. Code control 7

11. Media control 7

12. Supplier control 7

13. Records collection, maintenance, and retention 7

14. Training 7

15. Risk Management 7

Comsats Lahore Page 3 of 23

Employee Management System Error: Reference source not found Version x

Error: Reference source not found

1. Introduction
This Software Quality Assurance Plan (SQAP) defines the process, methods, standards, and procedures that
will be used to perform the Software Quality Assurance function for the Employee’s Management System
project. The SQAP follows the Software Engineering Methodology (SEM), modified to accommodate the
project model adapted for the EMS (Employee’s Management System) project.
1.1 Purpose
The purpose of this Software Quality Assurance (SQA) Plan is to establish the goals, processes, and
responsibilities required to implement effective quality assurance functions for the Employee
Management System project.

The Employee Management System Software Quality Assurance Plan provides the framework necessary to
ensure a consistent approach to software quality assurance throughout the project life cycle. It defines the
approach that will be used by the SAM and Software Quality (SQ) personnel to monitor and assess
software development processes and products to provide objective insight into the maturity and quality of
the software. The systematic monitoring of Employee Management System products, processes, and
services will be evaluated to ensure they meet requirements and comply with Institute of Electrical and
Electronic Engineers (IEEE) standards.
.
1.2 Scope
This SQAP provides a foundation for managing the EMS software quality assurance activities,
and is based on project activities and work products as documented in the EMS Project Plan.
This plan:
• Identifies the SQA responsibilities of the project team and the SQA consultant
• Defines EMS reviews and audits and how they will be conducted
• Lists the activities, processes, and work products that the SQA consultant will review and
audit
• Identifies the SQA work products.

1.3 Definitions, Acronyms, and Abbreviations

Quality assurance (QA) is any systematic process of determining whether a product or service meets
specified requirements.
The ISO: International Organization for Standardization
IEEE: Institute of Electrical and Electronics Engineers
1.4 References
DOE Software Engineering Methodology, March 1996
• ANSI/IEEE Standard for Software Verification and Validation Plans
• Software Engineering Institute, SQA Key Process Area

1.5 Overview
The processes described in this plan are used during the requirements, design, implementation,

Comsats Lahore Page 4 of 23

Employee Management System Error: Reference source not found Version x

test, verification and acceptance of the EMS. The next chapter and its subsections will turn the attention to
the method for resolving
the problem, the programming environments used for developing the system and the
implementation of the operations performed upon the database.
2. Reference Document
1Q Manual, Quality Assurance, Procedure 20-1, Rev. 11, Software Quality Assurance. Savannah
River Site, November 2007.
7Q Manual, Security.
10Q Manual, Computer Security.
B-SWCD-C-00026. Software Classification Document for H-Area Tank Farm (HTF)
Performance Assessment (PA) Probabilistic Model. Savannah River Site, July, 2010.
G-SQA-A-00011. Software Quality Assurance Plan for GoldSim©, Rev 0. Savannah River Site,
August 30, 2006.
GTG-2009. GoldSim© Technology Group, LLC., GoldSim© User’s Guide, Version 10,
Volumes 1 and 2. Issaquah, WA, 2009.
SRR-CWDA-2009-00053, Dyer, C., et al., Closure & Waste Disposal Authority (C&WDA)
Desktop Guidelines for General Office Practices. Savannah River Site, Aiken, SC, May 2010.
SRR-CWDA-2010-00058, Hommel, S., Software Acceptance Testing for GoldSim© Version
10.11 (SP3), Rev. 0. Savannah River Site, Aiken, SC, August 2010.

3. Management
3.1 Organization

Employee Management System efforts are supported by numerous entities, organizations and personnel. Relevant
entities/roles that are of interest and applicable to this SQA Plan and the software assurance effort are described at a
high level below.

3.2 Tasks
All software development tasks for EMS, within the scope of this document, will be performed
by personnel in the SQA. SQA will assure that the SIS in the DPA is validated and that internal as well as
external deliverables are produced in accordance with the SDP, SMP, STP and this document. SQA will
certify that the Science Instrument Software (SIS) acceptance process used in the delivery of the
DPA and will verify the acceptability for use of specific Electronic Ground Support Equipment
(EGSE) used to validate the delivered ACIS Instrument. The PAM will assure that the SQA function is
being performed according to this plan.

3.3 Responsibilities
Role Name Org. SQA Stage Exit

Comsats Lahore Page 5 of 23

Employee Management System Error: Reference source not found Version x

Responsibility Function
QA V. Domenico DOE Manages the Approve
Software Quality (delegated
Manager
Mgmt. Assurance to QA
function. consultant)
System M. Raffaello HR-XXX Helps define Approve
Owner product quality
expectations.
Represents
procurement
users.
Determines final
acceptance of
EMS.
QA G. Garibaldi DOE Audits and Approve
Consultant Software approves project
Mgmt. deliverables
from QA
perspective.
Reviews plans
and deliverables
for compliance
with applicable
standards.
Provides
guidance and
assistance on
process matters.
Project A. Software Ensures Conduct
Manager Michelangelo Develop_ implementation
ment of quality
activities.
Coordinates
resolution of
issues. Provides
regular and
timely
communications.
Project A. Dante Software Monitors Approve
Manager's Develop_ implementation
manager ment of quality
activites.
Receives reports
on SJ-RT quality

Comsats Lahore Page 6 of 23

Employee Management System Error: Reference source not found Version x

efforts. Resolves
conflict across
organizations.

4. Documentation
1. Project Manager Plan
16326:2019(E) - ISO/IEC/IEEE International Standard - Systems and software
engineering - Life cycle processes - Project management. 2019.

The PM plan controls the QA engineer’s department for getting

the report of employee. It includes three strategies of planning:
Quality plan, Quality Assurance & Quality control.

The PM should check the program requirement of EMS from QA Engineer’s. the PM
could meet the contractor of that project who can describe in detail to make the changes
and update the program requirement in EMS like: user module, database module, admin
module, finance module etc.

In Employee Management System, the activity by PM is to handle different aspects of

programs that can assign to QA engineer team where to get reports of program
requirements which are stated as,

Program Requirement Strategies:

 Insufficient end-user involvement
 Poor communication among customers, developers, users and project
managers
 Unrealistic or unarticulated project goals
 Inaccurate estimates of needed resources
 Badly defined or incomplete system requirements and specifications
 Poor reporting of the project's status
 Poorly managed risks
 Use of immature technology
 Inability to handle the project's complexity
 Sloppy development practices
 Stakeholder politics
 Commercial pressures

2. Software Requirement Specification

 IEEE Guide to Software Requirements Specifications. 1984. 

The SRS of Employee Management System are given level of statement

& description on Business requirement. We take requirements one by one to check on

Comsats Lahore Page 7 of 23

Employee Management System Error: Reference source not found Version x

system whether this requirement make issue or any fault creation in future. We research
on documentation of SRS to check which modules and section be perfect to contract
manager requirement (Business requirement).

Overall Descriptions:
 Product perspective
 System interface
 Interfaces
 Hardware interface
 Software interface
 Communication interface
 Memory constraints
 Operations
 Site adaption requirements
 Product functions
 User characteristics
 Constraints
 Assumptions and dependencies
 Apportioning of requirements

Requirement Specifications:
 External interfaces
 Functions
 Performance requirements
 Logical database requirements
 Design constraints
 Standards Compliance
 Software system attribute
 Reliability
 Availability
 Security
 Maintainability
 Portability
 Organizing the Specific Requirements
 System mode
 User class
 Objects
 Features
 Stimulus
 Response
 Functional hierarchy
 Additional comments

3. Design Specifications
IEEE Standard for Information Technology — Systems Design — Software Design
Descriptions. IEEE. 2009-07-20.

Comsats Lahore Page 8 of 23

Employee Management System Error: Reference source not found Version x

EMS Design can be specified in three levels of description. Where we

check the design requirement that can fulfil the program requirements and SRS.
 Context viewpoint
 Composition viewpoint
 Logical viewpoint
 Dependency viewpoint
 Information viewpoint
 Patterns use viewpoint
 Interface viewpoint
 Structure viewpoint
 Interaction viewpoint
 State dynamics viewpoint
 Algorithm viewpoint
 Resource viewpoint
 Data design
 Architectural design
 GUI design
 Procedural design

EMS Quality Assurance

 Verification & validation methodology
 Verification activities
 Technical Reviews of Documentation
 Design Walkthroughs 
 Code Reviews
 Training
 Standards and Conventions
 Validation Activities
 Unit Test Phase
 Module Test Phase
 Integration Test Phase
 System Test Phase
 Beta Test Phase
 Test Organization

EMS Quality Control

 Configuration Management
 EMS Build & Release
 Build Identification
 Build Instructions
 Release Notes
 Issue Tracking

4. Test Plan
IEEE-829 Standard for Software Test Documentation

Comsats Lahore Page 9 of 23

Employee Management System Error: Reference source not found Version x

In Testing Phase, we check design specs by use case testing, for coding by unit
testing, integration testing & system testing.
Here we implement different test plans on EMS to get better performance on
documentation and coding phase:
Test contains detailed information about the testing area and business objectives of the
product. It helps determine the time and effort required to test the product. It clearly
defines the roles and responsibilities of each team member. It provides a testing schedule.
Hence, it provides you with a basic timeline to monitor and track your team's progress. It
specifies the resource requirements and hardware requirements to conduct the testing
process successfully.
This test plans also included when making any software project in detailed parts
section:

Document identifier
Introduction part
Approaches to testing
Resources
List of task and goals
Features of test
The team
Work schedule
Module pass/fail criteria
Risk assessment with ways to avoid them

Quality test plan

 Analyze the product

 Developing a Testing strategies
 Define the scope
 The development schedules
 Define Role & Responsibilities
 Anticipate Risk

5. Risk Management Plan

RMP validates the outcomes of the project deliverables and project milestones against its
plans and methodologies. Monitors the risks and notifies the Project manager in case of
serious deviation from plans. It has the authority to reject a deliverable, internal product
or milestone achievement statement if it concludes that the artifact is not meeting the
settled quality standards. It introduces and manages the list of deliverables’ reviewers,
which has to be confirmed by the PM and manages the entire process of deliverables
preparation up to the step of submission

Comsats Lahore Page 10 of 23

Employee Management System Error: Reference source not found Version x

 Risk Analysis involves the identification of a risk, the assessment of its

importance and the evaluation of whether the risk level is higher than the risk that
could be accepted for the project. In case a risk exceeds the acceptable levels, a
risk analysis activity is instantiated that defines the required actions in order to set
the risk within acceptable levels.
 Risk Management involves the planning of the required activities to handle the
risk, the redistribution of resources, the evaluation of the results, as well as
ensuring the stability of the new status
 Avoid
 Control / mitigate / modify / reduce
 Accept / retain
 Transfer / share 

6. Software Configuration Management Plan

828-2012 IEEE Standard for Configuration Management in Systems and Software
Engineering. 2012
In SCM plan, the development team can assign task to each other
to manage the work. If one can take a job to authorize changes in requirement and other
can take a job for system report, the third one can take the job for testing section. Here
the matter where SCM plan can confirmed for deliverable the task to the developers.

 Identification 
 Status accounting 
 Control
 Auditing
 Build management
 Process management
 Environment management
 Teamwork
 Defect tracking

7. User- Deliverable Documents

IEEE 24748
It is also called End-User Document where we can plan how to deliver the
document in time and in better pattern including followings:

This following step can be made in plans document when one organization deliver the
software to their clients this statement can helpful for clients to understand:

 Tutorial
 Thematic
 List of references

1. User analysis
2. Planning

Comsats Lahore Page 11 of 23

Employee Management System Error: Reference source not found Version x

3. Draft review
4. Usability, testing
5. Editing

Standard, Practices, Conventions & Metrics

1. Product-Specific Quality Measures
 Management by Objectives:
Management by objectives is a management model
aimed at improving the performance of an organization by translating organizational
goals into specific individual goals.
The employee works towards these goals and reports back to the manager on their
progress. These goals can even be given a certain weight (a number of points).
 Product defects
 Number of errors
 Net promoter score
 Forced ranking
 Number of sales
 the number of client contacts
 the number of phone calls 
 the number of company visits
 the number of active leads
 Number of units produced
 Handling time, first-call resolution, contact quality
 Work efficiency
 Revenue per employee
 Profit per Full Time Equivalent
 Overtime per Employee

2. Web Page Standard

IEEE Web page Standard by zenefits.com

3. Documentation Standard
Agile Model

Comsats Lahore Page 12 of 23

Employee Management System Error: Reference source not found Version x

4. Logic Structure Standard

Class diagram
Use case
Network diagram
Database notations
Gantt chart
Block diagram
Architecture diagram
Data flow diagram

5. Coding Standards:

Front-End development: HTML5, CSS3, JavaScript, jQuery,

BootStrap4, Express JS.
Back-End development: MongoDB, React JS, Node JS
App development: React Native

6. Naming Standards

Identifier type Rules for naming Examples

Packages Packages for all over com.sun.eng
com.apple.quicktime.v2
programming language is to edu.cmu.cs.bovik.cheese
run that statement which is
declare in library event
Tags The tags can make DOM on <h1>
web pages they write content <div>
on GUI <span>
Style Gives style to web page as h1{border: 2px;

Comsats Lahore Page 13 of 23

Employee Management System Error: Reference source not found Version x

html make content in web Padding: 0px;

page Top;80%;
}
Classes The classes can be called <h1 class = “now”>…</h1>
varies in different operation .now{color:green;}
like javascript & jquery etc
Id Id = classes just changes is <h1 id = “now”>…</h1>
that we use both as retrieve #now{color:red;}
data or update data
Script It reads javascript & jquery <script src =
files and many more files in “text/javascript”>
external html Var p = lkdjkhs;
</script>
Link Link css file to main html <link rel = “stylesheet”
href=”hg.cs”/>
href Link any url or any object <a href = “#”></a>
Src Links jQuery files <script src =
“text/javascript”>
Var p = lkdjkhs;
</script>
Components Make own tags <school/>
Event Handler On event play the function Onclick = “function()”
call the class
database Retrieve data from localhost SELECT * FROM Customers;

7. Commentary standards
IFRS Practice Statement Management Commentary published by the IASBIFRS Practice Statement Management Commentary published by the IASBIFRS Practice Statement Management Commentary publ

IFRS Practice Statement Management Commentary published by the IASB

Element User Needs
The entity's most significant resources, risks Whether the requirement can be created fault
and relationships and other problem the resource for EMS can
check test document to sort the problem
The results of operations and prospects Operation can fulfil the requirement

8. Testing standards & practices

• Create Separate Teams for Testing Security and Performance
• Talk to End-Users and Simulate Their Environment
• Mimic the Developer Environment
• Focus on Significant Code Changes
• Use a Two-Tier Test Automation Approach
• Run a Regression Cycle

9. Products & process metrics

The Products Metrics can describe characteristics of EMS function like:

Comsats Lahore Page 14 of 23

Employee Management System Error: Reference source not found Version x

Size, complexity, design features, performance & quality level

It can measure predefined attributes in class & Objects
The process metrics used for improvement of project/ maintain process like:
Effectiveness of defect removal, pattern of defecting arrival & response time of fixes.
Measure efficiency of process the system what to do.
The Project metrics describe EMS characteristics and execution like:
Number of developers, costs, schedule & productivity etc.
Access the status of project track risk identify problem statements

10. Acceptance criteria

• Pre-established standards must meet.
• Product or software must be satisfied to be accepted by user
• Criteria should be testable
• Criteria should be concise and clear
• Everyone can easily understand the criteria
• Criteria should provide user perspective

5. Review and Audit Plan

The SQA auditor will review and audit

Management Work Path Permission Grant to Walkthrough Inspection

Phases Product Person
Risk Risk Server Read Muhammad No No
Analysis Management Side Update Afzal
Document Cancel
Estimation Estimation Client Read Muhammad Yes Yes
& Metric side Change Al Fahad
Report Test
Planning Test Client Discussion Muhammad Yes Yes
Planning side Read Al Fahad
Document
Organization Training Client Read Muhammad No Yes
Document, side Changeability Fahad
HR Plan Cancel
Monitoring Collected Server Update Muhammad No Yes
& control Metrics of side Read Adeel
project effort Change
Issue Issue Server Control Muhammad Yes Yes
Management management side Read Fahad
report Test
Test Report Test report Client Read Muhammad Yes Yes
document side Analyze Afzal

Comsats Lahore Page 15 of 23

Employee Management System Error: Reference source not found Version x

5.1.1 The SQA will review task

Date Task Personal Description Output walkthrough Inspection
In
Charge

12 Evaluate Fahad -Software Planning Yes Yes

Nov project specification review report
2021 planning, Review
organization -Estimation, Master minute
review Schedule and project
plan review
20 Requirement Al Review requirement Process Yes Yes
Dec analysis Fahad development audit
2021 review report
1 Evaluate Adeel Review test design EMSQA No Yes
Mar and review document report
2022 test design Review
minute
2 Review Adeel Process audit: final Process No Yes
Mar release release audit
2022 report
5 Review Afzal External review after Process No Yes
Apr project final delivery to audit
2022 closing customer/stakeholders report

6. Evaluation and Test

1. Introduction
 Scope
In Scope

Out Scope

 Quality Objective
 Role & Responsibilities
2. Test Methodology
 Overview
 Test Level
 Bug Triage
 Suspension criteria & Resumption Requirement
 Test completeness

Comsats Lahore Page 16 of 23

Employee Management System Error: Reference source not found Version x

Project Task, Estimation & Schedule

3. Test Deliverables
 Before Test Case
 During Test Phase
 After Test Phase
4. Recourse & Environment need
 Testing tool
 Testing Environment
5. Terms/Acronyms

7. Problem Resolution and Corrective Action

When a problem in an approved CI is detected, it has to be solved. There are several kinds

of problems:

Document problems:
• Non compliance with other project documents.

• Non compliance with the house style.

• Incompleteness.

• Errors.

Code problems:
• Lack of functionality.

• Wrong functionality.

• Non compliance with coding or commentary standards.

These are the procedures to be followed when a problem is detected: Problem reporting

procedure:

• When a problem is detected, the person who discovered the error is responsible for

reporting it to the PM and QAM. When a problem is discovered during a review, the

member of the SQA team present is responsible.

8. Tools, Techniques, and Methodologies

The SQA team has to make sure that appropriate tools, techniques and methods are used.

Comsats Lahore Page 17 of 23

Employee Management System Error: Reference source not found Version x

The SQA team checks their use by means of random checks. With respect to the tool used during this
project special

interest is paid to:

• Availability of the tools.

• Knowledge. The group members working with the tools must have the necessary skills

to work with the tools.

• The tools must work properly. (Are there errors or malfunctions in tools? Enough

capacity?).

Every used tool will be checked at least once before use and once during use. When problems

appear the SQA decides together with the PM and CM if the problem can be solved, or if

the tool must be replaced by an alternative.

9. Code control
It is the CMs responsibility to assure the correct handling of the code. The following has to be valid:

• Documents are available to all people who are authorized to access them and to no one

else.

• All versions of a document are available.

• No file is unnecessarily locked.

• Name conventions are consequentially used.

This is done by reviews and random checks. Problems are reported to the CM and

PM.

10. Media control

The QAM checks if the procedures and standards as described in the SCMP are handled

properly. Problems are reported to the librarian and PM.

Comsats Lahore Page 18 of 23

Employee Management System Error: Reference source not found Version x

11. Supplier control

All external software components in the program code, that have an unreliable source, will be tested
according to the IEEE standard Software components that have reliable sources will undergo some quick
tests. These tests will be focused on the parts of this software that are of importance to the project. Whether
an external software component is reliable or not is to be decided by the PM.

12. Records collection, maintenance, and retention

1)Purpose
2)The purpose of this Policy is to ensure that necessary records and documents of are adequately protected
and maintained and to ensure that records that are no longer needed by EMS or are of no value are
discarded at the proper time. This Policy is also for the purpose of aiding employees of EMS in
understanding their obligations in retaining electronic documents - including e-mail, Web files, text files,
sound and movie files, PDF documents, and all Microsoft Office or other formatted files.
3)Policy
This Policy represents the EMS’s policy regarding the retention and disposal of records and the retention
and disposal of electronic documents.
4)Administration
Attached as Appendix A is a Record Retention Schedule that is approved as the initial maintenance,
retention and disposal schedule for physical records of EMS and the retention and disposal of electronic
documents. The {Insert Title of Policy Administrator} (the “Administrator”) is the officer in charge of the
administration of this Policy and the implementation of processes and procedures to ensure that the Record
Retention Schedule is followed. The Administrator is also authorized to: make modifications to the Record
Retention Schedule from time to time to ensure that it is in compliance with local, state and federal laws
and includes the appropriate document and record categories for EMS; monitor local, state and federal laws
affecting record retention; annually review the record retention and disposal program; and monitor
compliance with this Policy.
5)Suspension of Record Disposal In Event of Litigation or Claims
In the event EMS is served with any subpoena or request for documents or any employee becomes aware of
a governmental investigation or audit concerning EMS or the commencement of any litigation against or
concerning EMS such employee shall inform the Administrator and any further disposal of documents shall
be suspended until shall time as the Administrator, with the advice of counsel, determines otherwise. The
Administrator shall take such steps as is necessary to promptly inform all staff of any suspension in the
further disposal of documents.
Applicability
This Policy applies to all physical records generated in the course of EMS’s operation, including both
original documents and reproductions. It also applies to the electronic documents described above.
This Policy was approved by the Board of Directors of EMS on
RECORD RETENTION SCHEDULE
The Record Retention Schedule is organized as follows:
Accounting and Finance
Contracts
Corporate Records
Correspondence and Internal Memoranda

Comsats Lahore Page 19 of 23

Employee Management System Error: Reference source not found Version x

Electronic Documents
Grant Records
Insurance Records
Legal Files and Papers
Miscellaneous
Payroll Documents
Pension Documents
Personnel Records
Property Records
Tax Records
Contribution Records
Programs & Services Records
13. Training
During the project there may arise tasks that require special skills. Due to the fact that all group members
reached an acceptable level of knowledge in the area of computer science, special training in this area will
probably be unnecessary. However, should the need arise for people with specialized knowledge into a
certain area for some task, the PM will assess the level of knowledge for the task in the group and then they
decide whether special action needs to be taken. In that case, detailed information can be found in the
appendices of this document.
14. Risk Management
1.1Purpose
This plan documents the processes, tools and procedures that will be used to manage and control those
events that could have a negative impact on the Employee Management System. It’s the controlling
document for managing and controlling all project risks. This plan will address:
• Risk Identification
• Risk Assessment
• Risk Contingency Planning
Risk Identification
A risk is any event that could prevent the project from progressing as planned, or from successful
completion. Risks can be identified from a number of different sources. Some may be quite obvious and
will be identified prior to project kickoff. Others will be identified during the project lifecycle, and a risk
can be identified by anyone associated with the project. Some risk will be inherent to the project itself,
while others will be the result of external influences that are completely outside the control of the project
team.
The EMS system Project Manager has overall responsibility for managing project risk. Project team
members may be assigned specific areas of responsibility for reporting to the project manager.
Throughout all phases of the project, a specific topic of discussion will be risk identification. The intent is
to instruct the project team in the need for risk awareness, identification, documentation and
communication.
Risk awareness requires that every project team member be aware of what constitutes a risk to the project,
and being sensitive to specific events or factors that could potentially impact the project in a positive or
negative way.

Comsats Lahore Page 20 of 23

Employee Management System Error: Reference source not found Version x

Risk identification consists of determining which risks are likely to affect the project and documenting the
characteristics of each.
Risk communication involves bringing risk factors or events to the attention of the project manager and
project team.
The EMS project Here project manager will identify and document known risk factors during creation of
the Risk Register.
It is the EMS project manager’s responsibility to assist the project team and other stakeholders with risk
identification, and to document the known and potential risks in the Risk Register. Updates to the risk
register will occur as risk factors change. Risk management will be a topic of discussion during the
regularly scheduled project meetings.
The EMS project team will discuss any new risk factors or events, and these will be reviewed with the
EMS project manager.
The project manager will determine if any of the newly identified risk factors or events warrant further
evaluation. Those that do will undergo risk quantification and risk response development, as appropriate,
and the action item will be closed.
At any time during the project, any risk factors or events should be brought to the attention of the EMS
project manager using Email or some other form of written communication to document the item. The
project manager is responsible for logging the risk to the Risk Register. Notification of a new risk should
include the following Risk Register elements:
• Description of the risk factor or event, e.g. conflicting project or operational initiatives that place demands
on project resources, unexpected study outcomes, delays, etc.
• Probability that the event will occur. For example, a 50% chance that the vendor will not have an animal
colony that meets the criteria available.
• Schedule Impact. The number of hours, days, week, or months that a risk factor could impact the
schedule. As an example, the animals require an additional 3 months to meet age requirements.
• Scope Impact. The impact the risk will have on the envisioned accomplishments of the project. Delayed
animal delivery may result in a reduction in the number of studies that can be completed within the contract
period of performance.
• Quality Impact. A risk event may result in a reduction in the quality of work or products that are
developed. As an example, lack of funding caused by cost overruns may result in the reduction of the study
size and impact statistical empowerment
• Cost Impact. The impact the risk event, if it occurs is likely to have onthe project budget.
Risk Responsibilities
The responsibility for managing risk is shared amongst all the stakeholders of the project. However,
decision authority for selecting whether to proceed with mitigation strategies and implement contingency
actions, especially those that have an associated cost or resource requirement rest with the Project Manager
who is responsible for informing the funding agency to determine the requirement for a contract
modification. The following tables details specific responsibilities for the different aspects of risk
management.
Risk Identification: All project stakeholders Risk Registry: Project Manager
Risk Assessment: All project stakeholders
Risk Response Options Identification: All project stakeholders
Risk Response Approval: PM with concurrence from CO/PO/COTR
Risk Contingency Planning; Project Manager(s)

Comsats Lahore Page 21 of 23

Employee Management System Error: Reference source not found Version x

Risk Response Management; Project Managers

Risk Reporting Project Manage
Risk Assessment
Risk assessment is the act of determining the probability that a risk will occur and the impact that event
would have, should it occur. This is basically a “cause and effect” analysis. The “cause” is the event that
might occur, while the “effect” is the potential impact to a project, should the event occur.
Assessment of a risk involves two factors. First is the probability which is the measure of certainty that an
event, or risk, will occur. This can be measured in a number of ways, but for the EMS project will be
assigned a probability as defined in the table below.
Probability of Occurrences
Definition MeaningValue
Frequently • Occurs frequently
• Will be continuously experienced unless action is taken to change events 5
Likely • Occur less frequently if process is corrected
• Issues identified with minimal audit activity
• Process performance failures evident to trained auditors or regulators 4
Occasional • Occurs sporadically
• Potential issues discovered during focused review 3
Seldom • Unlikely to occur
• Minimal issue identification during focused review 2
Improbable Highly unlikely to occur 1

The second factor is estimate of the impact on the project. This can be a somewhat subjective assessment,
but should be quantified whenever possible. The estimated cost, the duration of the potential delay, the
changes in scope and the reduction in quality are in most cases factors that can be estimated and
documented in the risk statement and then measured using the standard project management tools (i.e.
project plan, budget, statements of work)
Risk Contingency Planning
Contingency planning is the act of preparing a plan, or a series of activities, should an adverse risk occur.
Having a contingency plan in place forces the project team to think in advance as to a course of action if a
risk event takes place.
• Identify the contingency plan tasks (or steps) that can be performed to implement the mitigation strategy.
• Identify the necessary resources such as money, equipment and labor.
• Develop a contingency plan schedule. Since the date the plan will be implemented is unknown, this
schedule will be in the format of day 1, day 2, day 3, etc., rather than containing specific start and end
dates.
• Define emergency notification and escalation procedures, if appropriate.
• Develop contingency plan training materials, if appropriate. • Review and update contingency plans if
necessary.
• Publish the plan(s) and distribute the plan(s) to management and those directly involved in executing the
plan(s).

Comsats Lahore Page 22 of 23

Employee Management System Error: Reference source not found Version x

Contingency may also be reflected in the project budget, as a line item to cover unexpected expenses. The
amount to budget for contingency may be limited to just the high probability risks. This is normally
determined by estimating the cost if a risk occurs, and multiplying it by the probability. For example,
assume a risk is estimated to result in an additional cost of $50,000, and the probability of occurring is
80%. The amount that should be included in the budget for this one item is $40,000.

Comsats Lahore Page 23 of 23