Please complete the assignment as below

<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.1 Project Description

2.2 Problem Statement

2.3 Goals

2.4 Project Background

2.5 Product Objectives

2.6 ..Business Objectives……………………………………………………………..

2.7 ..Milestones……………………………………………………………………….

2.8 Assumptions, Constraints and Dependencies

2.9 Project Deliverables

2.10.. Project Success Criteria ………………………………………………………..

2.11..Schedule and Budget Summary

2.12..Evolution of the Plan

2.13 ..References

2.14 Definitions 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

8.1.. Procurement Planning

8.2... Solicitation Planning

8.3... Solicitation

8.4... Source Selection

8.5... Contract Administration

8.6... Contract Close-out

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.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 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.

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 Overview

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.

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.

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.

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.

*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.

3.Stakeholder Register

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 complete 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

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.

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.

Legend:

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.

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.

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.

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

Procurement is the part that carries the parts that acquired the services needed on the project, whereas typically they are outsourced. For purposes of simplifying issues, the procured items will be known as the product. This part of the project management will include the following actions. There will be the procurement planning, Solicitation planning, solicitation, Source selection, Contract Administration and Contract Close-out. Procurement planning helps in making the choice of what to procure and at what time. Solicitation planning on the other hand dictates the requirements of the products and come up with specific sources. Solicitation deal with getting the bids, offers and proposals. Source selection on the other hand is getting the source that will work wit the organization in the project. What follows is the contract administration and contract close-out that mainly deals with nurturing the relationship of the service provider and finalizing the requirements of the contract.

8.1 Procurement Planning

This is first step that mainly involves identifying the project needs, that can be met by precuring the service from outside, this is the part that shows how to procure what to procure and when to do it. The issue at this point is that it is already predetermined mainly because it replacing the previous Veeva QMS with a newer version meaning that the same provider will come and sort out issue and provide the service.

One of the most important inputs in this case is the scope statement that mainly deal with describing the needs of the project and strategies during the procurement process.

The next step is describing the service needed by project/ in other words product description, that will help describe what project product expectation.

Procurement resources is what follows at this point, the procurement will need resources and expertise. In the scenario that there is no procurement team then the organization will need to produce one to handle the job. This is the team and resources that used to get Veeva into working with the organization.

Market conditions is important, the team looks into all offers from the market based on who is offering and in what conditions.

Other planning inputs, should be considered during this step to make sure the procurement planning is successful, which include outputs like; schedule estimates, quality management plan, identified risks, cash flow projections and work breakdown structures.

Finally, the most important task at this point is looking at the constraints (funds availability) and assumptions (factors considered to be certain/real) and use these in making the procurement plan.

The tools that were utilised at this point was expert judgment and contract type selection which helps in establishing, what are the best considerations and contract type selection, present to make everything clear. Expert judgement was responsible for identifying Veeva as the best and thus procuring their services.

8.2 Solicitation Planning

This is the step that follows, in the procurement process. As mentioned before this project is a sequel of the initial project, mainly because Veeva QMS had already been installed in our systems. The installation of the new Veeva QMS will not require the full project procurement management process, thus the solicitation planning would really not be necessary.

In the case that it would be required the inputs that would be important in this case are the procurement management plan and statement of work.

Techniques required is mainly expert judgement as discussed from the previous section. In addition to there is the standard forms that is the contract, including standard description of Procurement needs.

8.3 Solicitation

This involves getting information from the prospective service providers, at this point the market has established the need of the organization and people who can individuals/organizations that can provide the information have come forward. These include the proposals and the bids.

The main inputs that are required at this pint include the qualified seller list and the procurement documents. The qualified seller list will help in choosing who to work with. Whereby apparently Veeva was the most appropriate choice from the list.

The tools and techniques utilised at this point include the bidder conferences and advertising, the conferencing helps to make sure that all the prospective service providers understand what is required of them and advertising on the other hand, utilised to bring forth additional service providers if they were needed.

The outputs at this point are mainly the proposal from the prospective service providers. The proposals are documents prepared to describe the willingness and ability of the service provider and in that case Veeva, who in their proposal described that they would also have provided training after the installation process, which is technically the factor that made Veeva standout from the rest.

8.4 Source Selection

Involves receiving the proposals and selecting the service provider, the one with the most appealing proposal tend to pass the test and be selected. Price consideration is the first priority when selecting the source, this is to make sure that the service is within the budget provided by the organization, including the maintenance and after services. The other consideration made in this case is the performance of the service provider; looking at their previous works and other customer recommendation.

The inputs used in making the choice, include the proposals, organizational policies and the evaluation criteria.

What follows is the contract negotiations, after establishing the service provider which was Veeva, what followed was negotiating the contract so that each party will be contented with the stipulations in the contract. Making independent estimates is also crucial at this point as it will help the organization save on the cost of the requirements. In the proposal the cost of products provided by the service provider might be a bit higher thus looking at alternatives is recommended.

8.5 Contract Administration

This is there to make sure that the service provider actually delivers what they describe in the proposal. Contracts are legally binding and a breach has its win consequences. Thus, it is process that ensures maximum understanding between the two parties in addition to making sure that everyone is comfortable before the project begins. This part also includes some activities that will improve the contractual relationship, such as quality control, performance reporting, project plan execution and change control. At this point meetings with Veeva are important to make sure the above activities are in place and are well done.

The inputs here include the contract as mentioned above, the work results; what has Veeva produced on what was to delivered, change requests; which mainly might be change in the terms of the contract, may be additional information or cutting out some details, and finally there is the seller invoice which is mainly shows what has been delivered and what is to be paid to Veeva.

The outputs include correspondence; written agreement between the two parties on the matters in the contract which may be warning or some clauses needed to be addressed, there is also the payment requests; which mostly comes if the payment system is external and then finally there is contract changes; shows if approved or unapproved it done through the appropriate project procurement and planning process.

8.6 Contract Close-out

This is similar to an administrative closure, an it requires both an administrative close-out and product verification, that is to understand if everything that was stipulated in the contract has been achieved accordingly. The terms and condition of the contract might describe how the contract close-out will be. The inputs required is the contract documentation; invoices, payments record and maybe the result of the project. The tool that is mainly utilised here are the procurement audits; which is an overview of the procurement process from the procurement planning through contract administration that is mainly done on the closing week of the project, when both the project managers have established that everything is in order.

9. Cost

9.1 Introduction

This is the most important segment of the paper, mainly because it deals with how the budget allocation will successfully finish the project. From the budget there are estimates of the budget might amount to, thus cost management should be undertaken so that the cost of the project can be estimated, allocated and controlled. The main reason for cost management is to prevent the cost to surpass the budget which might be hectic for the organization. The cost of the project is mainly handled before the project begins and it should be approved so that the actual work can begin. Thus, there will be a development if a cost management plan that will be developed to make sure that the project stays within the project budget. The significance of this exercise in the long run is to provide a benchmarking experience as the actual cost will be compared to the predicted costs.

Cost Management Plan

9.2 Estimate Cost

The top down cost estimation will be the best in estimating the project cost.

9.3 Contingency Reserve Project Purpose or Justification

The contingency reserve for the project is $22,000 as it will go to the phase of migration activities, mainly because at this point the data can be lost and need to recovered. Thus, allocating the contingency reserve to deal with this risk.

9.4 Budget

Cost Control and Monitoring

9.5 Performance Monitoring

Earned Value Analysis will help is coming up with the performance monitoring. The variables below, show the calculations and how it will be approached. The timeline for performance monitoring will be the first 36 weeks, whereby the actual cost for this period is $80,000 and the budgeted cost is $80,000. The overall budget is $150,000.

Planned value (PV) = 80,000

Actual Cost (AC) = 80,000

Earned Value (EV) – (150,000 * 0.5) = 75,000

Schedule Variance (SV) – (EV-PV)- 75,000-80,000= -5,000

Schedule Performance Index (SPI) – (EV/PV) 75,000/80,000= 0.94

Cost Variance (CV) – (EV-AC) – 75,000-80,000= -5,000

Cost Performance Index (CPI) – (EV/AC) = 75,000/80,000 = 0.94

Estimated at Completion (EAC) – (total project budget)/CPI = 150,000/0.94 = $ 154,574.47

As per the calculations, SV is negative and the SV for a project should be greater than 1, an SV lesser than is behind schedule. Considering the fact that these are only the first 36 weeks’ cost, means that there will be some improvement in the second art of the project.

The CV is also negative, the project is halfway at this point means that almost half of the budget is used. The CV that is less than one obviously shows that the project is over the budget. If the project continues with the same pace then the total cost of the project will be $154,574.47 as opposed to the original budget of $150,000.

9.6 Project Reports

The following report will be submitted;

Progress Report; that will describe what has been accomplished since the last report.

9.7 Cost Change Control

This is the procedure through which any change in the cost baseline can be introduced to the report.

The changes in the change in the cost baseline will be measure and immediate corrective will be taken to maintain the minimum cost. All the cost changes are recorded and what follows is the forecasting of the total costs continually.

Microsoft Project Deliverables

9.8 Project Budget Work Breakdown Structure

9.9 Microsoft Performance Report

Status report; this report will give the currents ate of the project at any specified time. Report is based on the performance measurement baseline and shows where the project is at that particular moment. Quality parameters, cost, time and scope are some of the current aspects to show from the report at this time.

9.10 Microsoft Performance Report

Progress Report; that will describe what has been accomplished since the last report.

Project Plan for Implementation of Veeva QMS at IRWD v1.0 Page 24

10. Integrated Change Control

This is the process of looking at all the change requests: that is managing and approving changes to organizational process assets, deliverables, project documents and management plan of the project and communicating their disposition.

The inputs of this process include the change requests, organizational process assets and project management plan. For instance, from the cost control, there is a noticeable budget overrun this eh most logical thing to do is to ask for a change from the project manager.

The tools and techniques utilised here will be mainly the meetings, because it is important to involve all the stakeholders before making any changes that will affect the project.

The outputs of this process include project management plan updates, Approved change requests, and project documents updates, that is from the charter to the project plan.

The change control will follow a flowchart as described below:

Source: My previous design as for course PMGT 510

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.

Change Request Form:

<Implementation of Veeva QMS at Ironwood Pharmaceuticals>

InitiationPhase

Develop Project Charter

Planning Phase

Initiate Valdation Activities

Configuration Phase

Migration Activities

Project Close-out Phase

Others (Hosting, Interface and maintanence)

Execution of Validation

Training of PO

Software IQ

Software OQ

Prepare Migration

Migration Completion