Sheet1Cost Summary RubricTopicMaxYour PointsCommentsPMP Cost Man.docx

Sheet1Cost Summary RubricTopicMaxYour
PointsCommentsPMP Cost Management PlanPMP Cost
Management PlanIntroduction/ Purpose10Purpose10Estimate
Cost 10Performance Measures (Earned value, accuracy levels,
variances thresholds, standards of measurement,
etc.)20Contingency Reserve 10Reporting Protocols20Budget
10Cost Change Control Process 20 Performance Monitoring10
Project Reports 10MS Project FilesMS Project Cost report
(PDF)20MS Project Deliverables WBS with resource, material
and costs (MPP) 10Project Cost -WBS with resource loaded
20100`Cost ReportsMininum of two cost reports (overview,
overruns, EVM, Resources costs20`Total 100
Chapter 4 – Section 3 of PMP Template Plan
3. Change Management (Chapter 4)
3.1 Change Management Process
Change management entails thoughtful planning and sensitive
implementation, and above all, consultation with, and
involvement of, the people affected by the changes. Changes
made to the project at any timeline are raised using a request for
change is requested before change is initiated and the change
request is handled by the implementation team to determine if
the change impacts the project risking the timeline, resource,
structure or any kind of impact. Any change requires a Quality
Assurance decision to approve the change or reject. If the
change request is denied the change request is rejected.
3.2 Change Control Process Flowchart

3.3 Change Request Form
Change Request Form
Change Request Number
01
Initiator
Bosch
Brief Description of Request
Editing Workflow configuration change
Submission Request Date
02/04/2017
Request Approve Date
02/05/2017
Reason for Change
The document check-out option is not open and as per the initial
configuration request the feature is added for employee using a
document at remote locations or exporting to other electronic
document managmenet system
Approval Signature
Signed
Date Signed
02/05/2017
Change Request Form
Change Request Number
02
Initiator
Stephen
Brief Description of Request

Security Access change
02/04/2017
Request Approve Date
02/05/2017
Reason for Change
System access for Business administrator is requested for
creating users in the system and remove access for system
owner
Approval Signature
Signed
Date Signed
02/05/2017
3.4 Change Log
Change No.
Type
Description
Initiator
Status
Submission Approved Date
Comments
01
Configuration
Editing Workflow configuration change
Bosch
02/04/2017
Approved
02/05/2017
None
02
Configuration
Security Access change
Stephen

02/04/2017
Approved
02/05/2017
None
References:
http://www.businessballs.com/changemanagement.htm
<Implementation of Veeva QMS at Ironwood Pharmaceuticals>
<PMGT 699 – Applied Project Management>
Prepared By
<Srinivasa Shiva Theja Yadlapalli>
<07/27/2019>
1. Executive Summary
1.1
..Introduction…………………………………………………………
……………
1.2 ..
Purpose………………………………………………………………
………….
1.3 ..
Scope…………………………………………………………………
…………
2. Project Overview
2.1Project Description
2.2Problem Statement

2.3Goals
2.4Project Background
2.5Product Objectives
2.6 ..Business
Objectives…………………………………………………………….
.
2.7
..Milestones…………………………………………………………
…………….
2.8Assumptions, Constraints and Dependencies
2.9Project Deliverables
2.10.. Project Success Criteria
………………………………………………………..
2.11..Schedule and Budget Summary
2.12..Evolution of the Plan
2.13..References
2.14Definitions and Acronyms
3. Stakeholder Register
4. Schedule
4.1
..Purpose/Overview…………………………………………………
……………..
4.2 ..Schedule
Baseline……………………………………………………………….
4.3 .. Schedule
Control………………………………………………………………
…
5. Resource Plan
5.1 .. Overview/Purpose of the Resource Section
……………………………………
5.2 ..Resourcing Strategy &
Assumptions….………………………………………….
5.3 .. Resourcing
Development………………………………………………………..
6. Risk Management Plan
6.1 ..

Purpose/Overview……………………………………………………
…………
6.2 .. Risk
Identification…………………………………………………………
……
6.3 ..Risk
Analysis………………………………………………………………
……
6.4 Risk Monitoring Plan
…………………………………………………………….
7. Communications Plan
7.1..Overview
7.2..Communication Message and Delivery
7.3..Communications Guidelines
7.4.. Escalation Process
8. Procurement
9. Cost
9.1..Introduction
9.2.. Estimate Cost
9.3..Contingency reserve project purpose or justification
9.4..Budget
9.5..Project and Monitoring
9.6.. Project Reports
9.7..Cost Change Control
9.8..Project Budget
9.9..Microsoft Performance Report #1
9.10..Microsoft Performance Report #2
10. Integrated Change Control
1.Executive Summary

1.1 Introduction
Computer systems play a major role in the development and
manufacturing of medical devices and drugs. The
pharmaceutical industry is one of the highly regulated industries
and thus increasingly relies on computerized systems to ensure
consistency, reliability, accuracy, and ability to detect and
reject invalid records. Computers perform several functions in
pharmaceuticals. According to Bandameedi (2016),
pharmaceutical companies use a computer to manage drug-
related activities such as creating and modifying patient files,
management of clinical trials, discovery and designing of drugs,
and data storage and retrieval. The improvement in computer
software and hardware has also helped pharmaceuticals in
research publications and adverse drug events control
(Bandameedi, 2016). Computer system validation (CSV) is,
therefore, important in the pharmaceutical industry because it
helps companies to maintain the required standard quality and
adhere to pharmaceuticals guidelines.
1.2 Purpose
The purpose of this project is to Implement Veeva QMS in
Ironwood pharmaceuticals. The implementation will focus on
replacing the existing Veeva QMS in Ironwood pharmaceuticals
with. Also, the computer system validation process will replace
the paper system in pharmaceuticals with a new computer
system. Veeva QMS implementation seeks to improve
reliability, accuracy, and performance consistency of handling
quality related methods within Ironwood pharmaceuticals.
Quality Management System is essential for maintaining the
quality of the medical devices and drugs and compliance with
the pharmaceuticals guidelines.
The Implementation shall contain the following modules;
· Change Control (CC)
· OOS/OOT

· Product Complaints
· Deviations
· Audit
The above-mentioned modules help Ironwood Pharmaceuticals
in;
· Managing Deviations within the controlled environment with a
detailed Audit trail report for each step
· Manage Product Complaints in a unique designed process
specific for Ironwood Pharmaceuticals
· Reduce Report handling time by in-built reporting capability
that allows generating reports instantaneously
1.3 Scope
Deployment of Veeva QMS at Ironwood Pharmaceuticals Inc.’s
facility (please, refer to Project Charter, Section 3, Project
Scope Statement for complete details).
The Project Scope will be controlled and verified as defined in
the present section of this document.
Project Scope Control
It is the responsibility of Veeva’ Project Manager to control the
scope of this project.
Scope Control, and all associated change requests, will be
managed according to the following Project Change Control
Procedure.
All change requests must be sent to Veeva’ Project Manager.
The project Manager will evaluate them together with Veeva’
technical team, if necessary. These requests will be evaluated
versus their impact on the project in the following ways:
1. If requests are considered within the current Project Scope
(e.g. minor changes to configuration, additional document
types, and changes in roles within Veeva QMS) and can be
implemented without affecting the project schedule, they will be

directly approved by Veeva’ Project Manager. Decisions will be
communicated to Ironwood Pharmaceuticals Inc.’s Project
Manager and activities will be scheduled in the Project
Management Plan for implementation.
2. If requests are considered within the current Project Scope
but cannot be implemented without affecting the project
schedule, they will be escalated to Veeva Director of
Professional Services.
3. If a change request falls outside the current Project Scope, it
will be escalated to Veeva’ Chief Executive Officer CEO and to
the technical team for evaluation and feasibility analysis.
Decisions will be communicated to Ironwood Pharmaceuticals
Inc.’s Project Manager and, if necessary, activities will be
scheduled in the Project Plan for implementation.
2.Project Overview2.1 Project Description
Veeva QMS Implementation consists in the deployment of the
Veeva QMS software at Ironwood Pharmaceuticals Inc.’s
facility. It comprises the configuration, installation and
validation of the software and its features: Processes,
Document, Train, Task and Setup. It also includes the training
of Ironwood Pharmaceuticals Inc.’s resources in its usage, as
established in the Project Scope statement of the Project’s
Charter.
2.2 Problem Statement
The pharmaceutical industry is increasingly becoming
modernized meaning that companies continuously adopt new
technologies. New technologies are applied in designing and
manufacturing of medical devices and drugs. Due to rapidly
growing technology, new computer hardware and software are
introduced into the market. Therefore, there is a need for
pharmaceuticals to adopt new computer system validations to

ensure that the new information technology systems fulfill the
intended functions. Technology is an important facet in the
pharmaceutical industry because it enhances the competitive
edge of the companies. Also, computer system validation is part
of the Food and Drug Administration (FDA) regulations.
According to the Pharma Mirror (2016), the adoption of new
computer systems in pharmaceuticals must follow FDA
regulations and rules in their validation program. Failure to
follow these regulations invites warning letters and inspection
from the FDA and sometimes fines and legal actions. FDA has
issued warning letters to several companies in the
pharmaceutical industry for failing to adhere to CSV
regulations. For instance, in 2018, FDA issued a warning letter
to a Japanese Bio-Chemical Manufacturing Company for
deviating from the current good manufacturing practice (CGMP)
for active pharmaceutical ingredients (API) (Marcial, 2018).
Therefore, the new computer validation implementation plan
will help in addressing such problems in the pharmaceutical
industry.
2.3 Goals
The QA Document Management group at Ironwood currently
manages the lifecycle of approximately 800 GXP controlled
documents and manages the training profile of approximately
150 employees resulting in approximately 3500 training
records/incidences on an average each year. The current process
is not electronic; therefore, the approval of documentation is
performed manually (on paper). This requires extensive
administrative overhead due to the compilation and distribution
of paper records.
Through this implementation the company looks to:
· Facilitate document approval.
· Reduce document revision and approval time.
· Improve document management practices.
· Streamline, enhance and simplify document revision and
approval of documentation.

· Reduce time spent archiving and retrieving documents and
training records.
· Standardize training records management and recording of
training activities electronically.
· Better control the "daily" monitoring of compliance in order to
be ready for audits at all time.
· Improve communication between participants in the approval
chain.
· Create a participative environment for revision and approval.
2.4 Project Background
The project focuses on the implementation of Veeva QMS at
Ironwood pharmaceutical. Pharmaceutical and other medicine-
related industries are increasingly becoming modernize and
continue to implement new technologies; thus, there is an
increasing need to ensure that these technologies accurate and
safe to be used by companies with complying to Regulatory
agencies. Several computer systems are being implemented by
pharmaceutical companies to ease the process of designing,
manufacturing, and distribution of medical devices and drugs.
Some of the new software in the pharmaceutical industry
includes a Quality management system. The implementation of
the project is scheduled to take six months. Veeva QMS will
replace the existing system, which has become outdated and
inefficient in the current environment.
2.5 Assumptions, Constraints and Dependencies
Constraints:
· Constraint 1: The key users and stakeholders should learn to
use the system before it is fully operational
· Constraint 2: training will cover all aspects of the systems,
including safety and maintenance
· Constraint 3: system may contain unidentified pitfalls;
therefore, the project should be tested before implementation.
Also, the project is expected to be completed within six months

Assumptions
· Assumption 1: The main assumption in this implementation
plan is that there is a challenge in the communication between
different departments. It also assumes that departments would
offer administrative support for the development and
implementation of the project
· Assumption 2: A Project Manager is assigned to the Project on
Ironwood's side
· Assumption 3: Veeva QMS infrastructure requirements are met
· Assumption 4: Installation of Veeva QMS will be performed
remotely.
2.6 Project Deliverables
Deliverables
Available
Acceptance Criteria
Project Charter*
August 2019
Approved by BO, IT and QA
Project Plan*
August 2019
Project Management Plan*
September 2019
Project Status Reports*
Every Week**
Project Change Request*
October 2019
Project Closure*
January 2020
Veeva QMS Software Configuration*
November 2019

Client Environmental Compatibility Assessment*
November 2019
Veeva QMS Installation and Configuration*
December 2019
User Requirements Specification*
December 2019
Testing Protocol*
December 2019
Test Scripts*
December 2019
Requirements Traceability Matrix*
December 2019
Validation Summary Report*
January 2020

*Note – All deliverable dates are currently adjusted to the
month available and refer to Schedule Baseline in Section 4.2
for more accurate details on date availability for individual
document.
**Note – Starting from 1st Week of August.
2.7 Schedule and Budget Summary
Aug 2019- Dec 2019
January 2019
FY Total
FY Total
Initiation Phase
Develop/Initiate Project Charter
5,000
5,000
N/A
N/A
Planning Phase
Initiate Validation Activities
25,000
25,000
Execution of Validation
20,000
20,000
Training PO
10,000

10,000
N/A
N/A
Configuration Phase
Software IQ. Initiate/Execute
10,000
10,000
N/A
N/A
Software OQ. Initiate/Execute
10,000
10,000
N/A
N/A
Migration Activities
Prepare Migration/Execute
15,000
15,000
Migrate Completion
N/A
N/A
25,000
25,000
Project Close-out Phase
5,000
5,000
Other (Hosting, Interface, Maintenance and support)
35,000
35,000
N/A

N/A
Total
105,000
45,000
Total Project Budget $150,000
2.10 Definitions and Acronyms
Term/Abbreviation
Definition
GxP
Good (Lab, Document, Clinical) Practices
QMS
Quality Management System
OOS/OOT
Out-of-Specifications
UAT
User Acceptance Testing
QA
Quality Assurance
3.Stakeholder Register
Stakeholder
Role
Responsibility
Amount of Influence
Impacted by

Notes
Lisa Jazon
Quality and Compliance
Evaluating incoming Change Controls
High
New implementation of the System and change of procedure
Wants to add all possible values that are existing and would like
to review the meta fields before launch
Billy Dunder
Senior Legal Supervisor
Maintaining Legal regards and Processing complaints
Medium
New process-oriented procedure around receiving and
evaluating complaints
Wants to be trained as early as possible and requested to be on
all configuration meetings.
Abhilasha Sharma
Training Supervisor
Assigning training and maintaining training documentation for
all employees
Low
New Module implementation
Requested to be included in the meetings involving
configuration of training.
Marcel
Audit Supervisor
Audit assistance and replies to observations
High
New procedure and templates for Audit responses
Interested in knowing the new process and wants to help in
developing the procedure.
4.Schedule Component

4.1 Purpose/Overview
Communication is effectively done using a certain
documentation that helps track of the items that help complete
the project. Project scheduling is one of the best ways to do
this. In the beginning, the project managers for both Ironwood
Pharmaceuticals and Veeva QMS sit together with all the
appropriate parties to discuss the activities that shall be planned
for all the phases to comeplet the project. The project planning
also involves the risk component which allows to arrange tasks
that are ascertained to risk to move around and plan resources
ahead.
In addition, project plan is scheduled using the longest path
possible which covers all the risks components and help track
the project all the way through and help in successful
completion. Upon completion of listing all the tasks, the next
step shall be to make sure that the sequencing of these tasks are
appropriate. There shall be dependencies between tasks, these
tasks follow these assigned sequences to track the work better
and efficient.
Task Dependencies:
1. Finish to Start (FS): This is the most common dependency.
When tasks A and B have an “FS relationship,” task B cannot
start until task A finishes.
2. Finish to Finish (FF): When tasks A and B have an FF
relationship, task B cannot finish until task A finishes.
3. Start to Start (SS): When tasks A and B have an SS
relationship, task B cannot start until task A starts.
4. Start to Finish (SF): When tasks A and B have an SF
relationship, task B cannot finish until task A starts.
4.2 Schedule Baseline

Tasks
Description
Creation of the Activity List and attributes
Both project managers from Ironwood and Veeva sit together
with all the relevant members who are involved in the project to
discuss the activities in each phase. These phases are divided
based on the work done using waterfall method. All activities
planned in each phase are also discussed along with the
timelines and that all members involved in the project have
agreed to those activities and are aligned with the phases it has
been
Estimation of activity resources
Each activity is subdivided with levels of effort that takes to
complete the task successfully. Level A is for task that take
longer than 2 weeks and requires more hours to complete the
task. Level B is much smaller and can be completed with less
hours and takes less than 2 weeks to complete. Level C is
described to be task which is easier and can be completed less
than a week. Level D are tasks that require only approvals and
do not take more than a day or two to complete.
Activity duration estimates
When the activities are planned, all the members together come
with estimates based on how long will they take to complete
also considering the external factors that depend on those
particular dependencies
Approval of the schedule baseline
The Schedule baseline shall be approved by Both project
managers from Veeva and Ironwood Pharmaceuticals. The
internal approvals of both parties are done prior to approval of
managers.
4.3. Schedule Control
The approved schedule baseline will be changed only through
the formal change control process and only after the impact on

the project constrains has been assessed.
Performance reviews
Weekly meetings are scheduled between teams to discuss the
effort and cost that has been used for the project. End of each
month these meeting minutes are taken into consideration and
projects managers from both Veeva and Ironwood
Pharmaceuticals meet to discuss the overall performance of the
team.
Schedule control thresholds
The planning of the project focusses on measruring the risk
component when the plan is created. Usually, there is a 10%
risk taken into consideration of activities that have some
internal and external dependencies. Such activities are provided
with 10% extra time. However, there is a high chance of
unexpectedness in projects. And any risk that involves time to
be increased by15%, project managers must meet to discuss the
issue and approve it before it makes it to the plan.
Schedule performance reporting
Schedule performance shall be reported to the PMO every 1st
week of the month after the Schedule performance meeting.
This is a high-level meeting and only PMO and the Managers
meet to discuss the performance and resolving any issues.
5.Resource Plan with RACI
5.1Overview/Purpose
The purpose of the resource plan is to provide clarity on the
allocation of resources required to complete the project and
ensuring that stakeholders have been assigned specific tasks
depending on their responsibility, accountability, power, and
interest. All the tasks involved in the implementation of the
Veeva QMS should be assigned to the specific stakeholder who
will ensure that it is implemented as per the project plan. Also,
every activity in the project needs the resources assigned to it.
Resources comprise personnel, money, equipment, and all other
things that ensure successful completion of the project.

5.2 Resourcing Strategy & Assumption
The project manager from Veeva and Ironwood will be
responsible for gathering all the resources required for the
implementation. At the beginning of the project, the
organization the project owner who is mandated the task of
collecting resources and manpower necessary for
implementation of Veeva QMS. The project owner establishes
the project team in consultation with the validation steering
committee. The validation project team, which is drawn mainly
from the quality assurance and IT department is responsible for
carrying out the primary activities outlined in the project plan.
The project team, under the leadership of the project owner,
will facilitate the procurement of the systems and software. The
team will also estimate and assign resources to all the activities
listed in the project list. Some of the techniques that will be
used in estimating the number of resources for each activity
include expert judgment, alternative analysis, published
estimating data, and bottom-up estimation. Expert judgment
implies using the opinion of the experts to estimate the
resources that are needed in the validation of the new computer
system. The experts should be knowledgeable and have prior
experience in a similar project. The alternative analysis means
the project team will have to try different options of resource
allocations while estimating resources using published data
entail using journals, books, articles from other projects and
applying them. On the other hand, bottom-up estimation
involves breaking complex activities into simple tasks and
allocation resources. However, this resource technique is
tedious, expensive, and consumes a lot of time.
5.3 Resourcing Development
All the resources will be provided at the start of the project.
The project owner will present the project budget the project
sponsor who will then facilitate the provision of resources. The
project owner is responsible for managing all the resources and

ensuring that they are properly utilized. The validation project
team is responsible for designing, implementing, and providing
support to the after it has been launched. The input of the
system vendor will also be required to ensure that the system
functions properly without technical errors.
High Level Responsibility Assignment RACI Matrix – Ironwood
Pharmaceuticals Team
RACI
ROLE
PMO
PM
Business Owner
IT Owner
Ironwood QA 1 and 2
Ironwood Training Specialist
Project Planning
A
R
Project Management
A
R
Project Status
A
R
I
I

I
I
Software Installation
A
C
C
C
Software Configuration
A
C
C
C
Data & Document Migrations
A
C
C
C
Validation
A
R
R
R
Training
A
I
C
C

R
High Level Responsibility Assignment RACI Matrix – Veeva
QMS Team
RACI
ROLE
CEO
PM
Veeva Configuration Specialist
Veeva
Solution
s Architect
Veeva QA 1 and 2
Veeva Training Associoate
Project Planning
A
R
C
C
C

C
Project Management
A
R
Project Status
A
R
C
C
C
C
Software Installation
A
C
R
Software Configuration
A

C
R
C
Data & Document Migrations
A
C
R
C
Validation
A
R
R
Training
A
R

Legend:
R
Respsonsible for Task Being Completed
A
Approves Task Deliverables
C
Consulted - Must be consulted before deliverables approved
I
Information - must be informed on status
6.Risk Management Plan
6.1 Review of Risk Management Plan
The risk management plan is a document in project management
that project owners use to predicate risks, evaluate impacts, and
establish appropriate response strategies. Risks refer to
uncertainties that occur during the implementation of the
project. These uncertainties can impact the project both
positively and negatively. Negative risks cause harm to the
project and must be prevented from happening positive risks
create opportunities that enable the project to progress
smoothly. It is important to note risks are unavoidable;
therefore, project managers should devise proactive risk
management strategies to maintain the impacts of risks at an

acceptable level. The implementation of Veeva QMS should
have a risk management plan to correct uncertainties.
Establishing a risk management plan for the validation program
is essential to the project because it reduces the cost of
validation. The plan ensures that resources are dedicated to
high-risk systems in the project. Risks are often categorized as
high, medium, and low risk, and risk management requires
proper planning and risk analysis during the inception of the
project.
The risk management process helps the organization to deal
with risks proactively, effectively, and in a way that will
maintain risk exposure below the risk threshold. The risk
management is vital in ensuring that the project achieves its
objectives. Risks can either be threats as well as opportunities.
Acceptable risk refers to a risk level that is deemed acceptable
to the organization, staff, or community affected. Since risks
cannot be reduced to zero, the project managers set risks levels
that are acceptable to key stakeholders, including project
sponsor and investors during the entire project life cycle.
Therefore, the project manager must conduct both qualitative
and quantitative risk analysis to understand better the risks that
might face the project at different stages of development.
The risk management process also aims to engage all the key

project stakeholders to develop a sense of ownership and
encourage them to input their ideas that would help in reducing
risks and steering the project towards realizing its objectives.
All information regarding risk on the project will be
communicated to the stakeholders promptly to enable the
management to devise an appropriate strategy for alleviating
risk occurrence. Risk management process enables project
managers to focus their attention on the specific phases of the
project where risks are more pronounced. Typically, there are
four phases in a project life cycle; initiation, planning,
implementation/execution, and closing phase.
The scope of the project involves project planning and
organization of various aspects, including features of the
project, timeline, and costs. It is important to document the
scope of the project at the initiation phase to allow the project
stakeholders to anticipate risks, costs, and other important
aspects of the project. The project scope also provides an
insight to the customers and the owner of what the product of
the project will look like upon completion. It is important to
involve the right stakeholders throughout various phases of the
project to avoid confusion, which would jeopardize all project.
6.2 Risk Identification

Risk identification refers to the second step in the risk
management process, whereby the validation project team helps
in identifying and documenting potential risks that may occur
during the implementation of the new computer system. For
instance, the risk may arise due to a lack of communication
between key stakeholders and validation project team. The lack
of proper communication among different stakeholders in the
organization leads to inaccurate requirements; hence derailment
of the project. Different techniques can be used to identify
potential risks in the computer system validation project. First,
the project manager can conduct brainstorming sessions to
identify risks. During brainstorming, stakeholders and project
team members converge in a room where they suggest ideas of
potential risks. Secondly, risks can be identified using the
probability and impact matrix technique. The technique helps in
identifying and ranking risks according to their likelihood of
occurrence. Also, risks can be identified by reviewing the risk
register. The risk register is a document that contains all
potential risks, risk owners, and the status of the risks.
Therefore, reviewing the risk register helps in identifying risks
that were not identified during the inception of the project.
Other risk identification techniques include analysis of the
project’s constraints and assumptions and reviewing checklists.
6.3 Risk Analysis

After identifying potential risks in step two, the project
manager conducts a risk analysis to establish which risks
require immediate attention and which ones are less harmful to
the project progress. According to McDowall (2005), risk
assessment involves risk analysis and risk evaluation and
utilizes available information to estimate the risks. Risk
assessment outcomes are used to evaluate which risks
responding to first and which risks to be accepted as less
threatening. The risks level depends on the severity of the risks
and impact on the project. Identified risks are also assessed for
potential harm and probability of occurrence.
Risks are categorized as high, medium, or low. High risks are
those uncertainties which have a highly harmful impact on the
project and require immediate attention. These are risks that
perceived to occur once per less a thousand transactions.
Medium risks are those which occur once per thousand
transactions while low risks involve uncertainties that occur
once per ten thousand transactions. Low risks imply that they
are unlikely to happen while medium risks have a moderate
probability of occurring. Different techniques can be used to
estimate the frequency of occurrence of risks in computer
system validation project. These include hazard analysis and
critical control points (HACCP), fault tree analysis (FTA),
preliminary hazard analysis (PHA), FMEA, and failure mode,
effect and criticality analysis (FMECA) (McDowall, 2005). In

the case of complex computer systems, GAMP risk assessment
methodology is appropriate. The classification of risk is done
by plotting the probability of occurrence against the severity of
the risk on the project. In the early phases of the validation
process, all risks are allocated medium likelihood of occurrence
but should be changed in the course of the project life cycle.
The table shows a Boston grid for classifying risks according to
FMEA.
The severity of the impact of the risk
Risk Probability
Low
Medium
High
High
Level 2
Level 1
Level 1
Medium
Level 3

Level 2
Level 1
Low
Level 3
Level 3
Level 2
6.4 Risk Monitoring Plan
Risk monitoring is an important process in the risk management
plan. The main purpose of risk monitoring is to ensure that the
organization fully implements risk response strategies. Also,
risk monitoring helps in documenting the progress of the
response strategies and their effectiveness and reports it to
relevant stakeholders. According to Metheny (2013), risk
monitoring verifies compliance with the response decisions and
determines any changes that may affect the progress of the
project.
Risk monitoring process in the new computer validation project
will entail reviewing of various processes including control,
access, and risk identification. The project owner will review
risk management reports every month. The project team will
identify and submit potential risks to project owner will, in

turn, review and assign to the risk owner to act on it. The
project owner will also use the probability matrix of occurrence
to prioritize risks. Risks with a high probability of occurrence
will be given the priority because if they have the highest on the
project progress. The risks identified by the validation project
team members are controlled as per the mitigation strategies
agreed upon by the validation steering committee and the
project owner. Throughout the project lifecycle, the root cause
of the risks will be documented and updated on the risk register.
The table below shows the roles and responsibilities of various
stakeholders in risk monitoring of the validation project.
Role
Responsibilities
Project Manager
The main role of the project manager in risk monitoring is to
review and analyze risks, establish mitigation plans, and initiate
the implementation of the mitigation strategies.
Validation project sponsor
The project sponsor approves any changes in risk strategies in
consultation with the project owner.
Validation project team
The project team monitors and identifies new risks on the
course of the project progress. The project team also documents
the effectiveness of the project team and reports any changes in
the strategies to the project owner.

Data migration expert
Helps in laying down data migration infrastructure from the old
system to the new system.
7.Communications Plan
7.1 Overview/Purpose
The purpose of the communication plan is to ensure the Project
Management Improvement Project provides relevant, accurate,
and consistent project information to project stakeholders and
other appropriate audiences. By effectively communicating the
project can accomplish its work with the support and
cooperation of each stakeholder group.
The communication plan provides a framework to manage and
coordinate the wide variety of communications that take place
during the project. The communication plan covers who will
receive the communications, how the communications will be
delivered, what information will be communicated, who
communicates, and the frequency of the communications.
The following outlines the targeted audiences, the key
communication messages to be delivered, and the method for
delivering the information, the communicator, and the
frequency of the delivery.
7.2 Communication Message and Delivery (Matrix)
Clear, complete, accurate, concise and timely communication
must exist to ensure properly informed stakeholders.

The following table shows the communication activities, person
responsible and frequency.
Activity
Audience
Purpose
Frequency / When / Responsible
Type/Method
Working Sessions
To be determined
Gather information for Project Charter and Project Management
Plan
Before Project Start Date
Veeva Project Manager
Meeting
Distribute Project Charter
Project Sponsor, Project Owner, and Project Super User.
Obtain formal approval of Project and its scope
Before Kick Off Meeting
Before Project Start Date
Veeva Project Manager
Document distributed via hardcopy or electronically.
Distribute Project Management Plan

All stakeholders
Obtain formal approval of Project Management Plan and inform
stakeholders
After Project Charter’s approval
VEEVA Project Manager
Document distributed via hardcopy or electronically.
Project Kick Off Meeting
All stakeholders
Communicate plans and stakeholders’ roles/responsibilities.
Encourage communication among stakeholders.
At or near Project Start Date
Meeting
Project Status Report
All stakeholders
Update stakeholders on progress of the project.
Every 3-4 weeks
Distribute electronically
Team Meetings

Entire Project Team.
Individual meetings for Sub-teams, Technical Team, and
Functional Teams, as needed.
Review detailed plans (tasks, assignments, and action items).
Weekly
VEEVA Project Manager/ IW Project Manager
Meeting
Sponsor Meetings
Sponsor, CEO and Project Manager.
Update Sponsor(s) on status and discuss critical issues. Seek
approval for changes to Project Plan.
As needed
Meeting
Audit/Review
CEO and Project Manager
Review status reports, issues, and risks. To identify and
communicate potential risks and issues that may affect the
schedule, budget, or deliverables.
As Needed

Meeting / Report
Quarterly Project Review
Project Manager and key stakeholders.
Review overall health of the project and highlight areas that
need action.
Quarterly
Meeting / Report
Post Project Review
Project Manager, key stakeholders, and sponsor.
Identify improvement plans, lessons learned, what worked and
what could have gone better. Review accomplishments.
End of Project.
Meeting / Report

7.3 Communications Guidelines
The project communication plan follows standard
communication guidelines and procedures. Communications
guidelines help in ensuring that communication goals and
objectives are met. Usually, communication guidelines are
specific to the method of delivery. For instance, when sharing a
message in a meeting, the agenda of the meeting should be
published before the meeting and pre-meeting requests. The
attendees of the meeting should be notified about the meeting
two weeks earlier and provided with meeting agendas. This will
allow team members to prepare adequately for the meeting.
Also, the meeting facilitator should ensure that the attendees
arrive at the meeting venues at five minutes before the meeting
starts. The facilitator should ensure that the meeting starts and
ends within the schedule and does not deviate from the agenda.
Additionally, all necessary people should be invited to the
meeting. For instance, for a risk identification seminar,
representatives of all groups and departments affected by the
new computer system validation should be invited to the
meeting.
On the other hand, when delivering a communication message
through Emails, the project owner should ensure that the subject

line of the email or memo is precise and clear. The body of the
message should identify the issue in the introduction. Also, the
attachments in the email should be named clearly, and the
project owner must ensure that all email communications are
signed.
7.4 Escalation Process
Any escalation of issues shall be raised to the department
manager, who then escalates to the Project Manager. The
manager is responsible to resolve the issue. If the problem
persists, the project manager must report it to PMO and get all
stakeholders involved to resole the issue.8. Procurement
9. Cost
9.1 Introduction
[The purpose of this document is to provide general content of a
Cost Management Plan and to describe submission required in
Microsoft Project format (.mpp file).]
Cost Management
Plan
[A cost management Plan defines cost baseline, modifies it
whenever necessary, and uses it for monitoring and controlling
cost. A project cost management plan generally includes
descriptions, procedures and responsibilities for items such as
Costs included, activity resource estimating, cost estimating,
cost baseline, budget determination and cost control.]

9.2 Estimate Cost
[Estimate Cost is a process of developing an approximation of
monetary resources needed to complete project activities.]
9.3 Contingency Reserve Project Purpose or Justification
[Contingency reserve is money assigned to the project and
allocated for identified risks for which contingent responses are
developed. Generally, how much money is reserved and its
rationale are included here.]
9.4 Budget
[Once the project costs or cost baseline is determined, a time-
phased project budget is developed. Project budget shows how
the project cost will be incurred by appropriate periods (months,
weeks, quarter, etc.) during project performance period.
Describe how your budget is developed.]
Cost Control and
Monitoring
[The approved project budget with contingency reserves serves

as a baseline for project control. This section usually include
project approach to monitor actual versus planned performance,
approach ( e.g. Earned Value analysis), and how any cost
changes will be managed.]
9.5 Performance Monitoring
[Describe your approach to monitor planned versus actual
performance and matrices that will be used]
9.6 Project Reports
[Include name and description of 2 to 3 reports that you plan to
use for performance monitoring, status reporting or other
reports. These are the reports for which you will be submitting
a Microsoft Project mpp file. See section below. ]
9.7 Cost Change Control
[Describe briefly how any changes to the cost baseline will be
administered and implemented.]
Microsoft Project
Deliverables
9.8 Project Budget
[Include your project WBS (in .mpp format) that represents your
project cost. Ensure that contingency reserves as a separate line

item. The report submission is in Moodle]
9.9 Microsoft Performance Report
[Include report name and describe how the report will be used]
9.10 Microsoft Performance Report
[Include report name and describe how the report will be used]
Project Plan for Implementation of Veeva QMS at IRWD v1.0
Page 2410. Integrated Change Control

Sheet1RubricMax Scale for Individual SubmittalScoreChange
Control RubricPointsYour PointsNotesProject Management Plan
(word document)Change Control Process15Change Control
Digagram 15Change Control FormCompleted Form with
relevant criteria15Evaluation of Change 15Project Management
File (mpp file)Change of schedule reflected10Change in cost
reflected 10Cost Reports Cost overview report including
baseline and reflected changes20Total 100

Sheet1Cost Summary RubricTopicMaxYour PointsCommentsPMP Cost Man.docx

More Related Content

Similar to Sheet1Cost Summary RubricTopicMaxYour PointsCommentsPMP Cost Man.docx

More from edgar6wallace88877

Recently uploaded

Sheet1Cost Summary RubricTopicMaxYour PointsCommentsPMP Cost Man.docx