Docstoc

Project Plan Baseline Template

Document Sample
Project Plan Baseline Template Powered By Docstoc
					<<PROJECT NAMEINSTITUTION NAME>>
Project Management Plan
Document Change History
Version Number V1.0 Date Contributor Description What changes (additions and deletions) were made for this version?

** Note to Document Author – Red and blue text (with the exception of the title and document name above) in this document is directed at the template user to describe processes, build standards and help build the document from the template. All such red and blue text should be removed before submitting any formal documentation, including both draft and/or final, deliverables. ****

Updated August 12, 2008

Project Management Plan

1. PROJECT SUMMARY
Project Name: Cancer Center: <<Name Here>> <<Center Name Here>> Start Date: Date Awarded: <<Date>> <<Date>>

Current Stage of Project:

<< Insert Development Life Cycle (Design, Development, Integration or Testing or Implementation)>> Ex: Implementation

Points of Contact: <Complete the following table.>> Position Project PI Project Manager Procurement Contact Data Manager Customers: Name/Organization Phone E-mail

Other Stakeholders (Top 3):

2

Project Management Plan

Project Objectives:
<< Provide a brief, concise list of what the project is to accomplish. For example, see below:>> The objectives are to a) Implement C3D and Oracle Clinical 4.5 as an ASP service hosted by NCICB b) Implement a melanoma registry, “Family Study of Skin Cancer in Utah”, utilizing C3D c) Set up and implement a clinical trial, “Optimizing Diet for Weight Loss Success in the Individual Breast Cancer Survivor”, utilizing C3D

Success Factors:
<< List factors that will be used to determine the success of the project. For example, see below:>> 1. Development and initiation of two data management products. 2. Timely completion of deliverables. 3. Acceptance of and comfort with C3D implementation by customers and stakeholders.

Project Dependencies/Constraints:
<< List factors that will be used to determine the success of the project. For example, see below:>> 1. Start date for second clinical study must be identified early. 2. The Developer must have the code ready on time, or our project‟s timeline is at risk. 3. Training for adopter staff must be thorough and completed on time.

2. ACTIVITY LIST/SCHEDULE
<<Provide an activity list (work breakdown structure) that describes work required by the project to complete each deliverable, in the statement of work. For an example, see below. Please note that an MS Project Plan may be substituted for the chart below.

3

Project Management Plan

*Note* A well developed MS Project (or similar Project Management Application Software) plan that includes activities, deliverables, dependencies, start dates, durations, review times, etc. should be substituted for sections 2 and 3 of this document when possible and/or appropriate. In that case both the task list and the gnant chart would be included.>> *Note to developer, a Unified Process based project plan sample is available upon request and/or for download.

Task # 1.1

Activity Name

Activity Name Description

1.2 1.3

Project management (PM) PM – Staffing plan PM – Monthly status reports PM – Training Study selection 1st study activities (1st) – Identify CRFs

Adopter will manage Center level project activities and use caMP to track deliverables. Center lead will assign adopter team members to activities. Document progress, meetings and action items. Review and provide feedback to NCICB on documentation. Attend BP and SOP monthly teleconferences. Arrange appropriate, ongoing training for adopter staff. Finalize study selection. Assess CRF reusability. Identify and prioritize CRFs.

# of Day s 5

Start Date 3/15/06

Dependenc y None

Milestone

Project management plan Staffing plan March status report

5 2

3/25/06 4/1/06

1.1 None

1.4 2.1 3.1.1

1 3 5

4/1/06 3/25/06 3/28/06

None None 2.1

March training report Study selection report Provisional implementation plan

4

Project Management Plan

3. WORK PRODUCT IDENTIFICATION
<<Provide a list of all deliverables required by the project, the date due and the person responsible for the deliverable. This is an extract of the Deliverables from the MS Project Plan. For an example, please see below:>> Deliverable Name Task 1.1 Project management Task 1.2 Staffing plan Task 1.3 Monthly status report Task 1.4 Monthly training report Task 2.1 Study selection report Task 3.1.1 Provisional implementation plan Task 3.1.2 Catalog of CRFs Task 3.2.1 C3D user list Task 3.2.2 Training list Task 3.3.1 eCRF modification requests Task 3.3.2 New eCRF requests Task 3.4.1 Existing CDEs used Task 3.4.2 New CDE requests Due Date 3/29/06 4/12/06 4/5/06 + 5th of each month 4/5/06 + 5th of each month 3/22/06 3/29/06 4/5/06 4/19/06 4/19/06 4/26/06 4/26/06 4/26/06 4/26/06 Date Delivered Point of Contact Rob Smitt Rob Smitt Brad Stone Brad Stone Rob Smitt Rob Smitt Rob Smitt Brad Stone Brad Stone Rob Smitt Rob Smitt Rob Smitt Rob Smitt

5

Project Management Plan

4. RESOURCE PROFILES – STAFFING
<<Provide a staffing plan that shows the number of personnel, by type, that will be required on the project on a monthly basis. For an example see below. Information for MS Project may be inserted if you are utilizing the Resource Tracking function of the MS Project Plan. For an example, please see below.>> Project lead February March April May June July August September October November December 0.6 0.6 0.6 0.6 0.6 0.6 0.6 0.6 0.6 0.6 0.6 Program coordinator 0.15 0.15 0.15 0.15 0.15 0.15 0.15 0.15 0.15 0.15 0.15 Data manager 0.10 0.10 0.10 0.4 0.4 0.4 0.10 0.10 0.10 0.4 0.4 Adopter PI 0.05 0.05 0.05 0.05 0.05 0.05 0.05 0.05 0.05 0.05 0.05 1st Study PI 0.05 0.05 0.05 0.05 0.05 0.05 0 0 0 0 0 2nd Study PI 0.05 0 0 0 0 0 0.05 0.05 0.05 0.05 0.05 Data entry 0 0 0 0 0.5 0.5 0 0 0 0.5 0.5 Total FTE 1 0.95 0.95 1.25 1.75 1.75 0.95 0.95 0.95 1.75 1.75

6

Project Management Plan

5. CONFIGURATION/CHANGE MANAGEMENT PLAN
<<Briefly describe and reference the configuration management plan and identify the person(s)/team responsible for project configuration management. Specify the flow of your change management process. The CM Plan provides instruction for incorporating Configuration Management (CM) practices and procedures. The plan demonstrates the application of CM and provides guidelines for implementing procedures supporting this function.The CM Plan documents the project's CM activities to be performed, the schedule of activities, assigned responsibilities; and resources required, including staff, tools, and computer facilities. For an example, please see below:>> CM Responsibility: Rob Smitt Manager: Rob Smitt Additional Staff for CM: Brad Stone, John Hill Change Control Repository: “CMrecords” folder in the caBIG directory, which is in the Common Files directory

Describe the Change control process and workflow:
Change requests will be directed to the CM manager. They will be documented in a single Excel file sorted by date and coded/annotated for the type of change requested, the reason for the request, impact of the change requested to current phase of project, original and estimated new timeline, resources and cost and the requester‟s name. The outcome of the review of the request will also be documented, including from whom input was sought, if necessary, and the decision to grant the request or make a compromise.

Sample CM management Log shown below. Change Management Log Sheet Owner: Rob Smitt
Date Requested By Change request type Reason Impact Estimated LOE - 2w. Populating data from multiple tables. Will need reindexing. Timeline: 2 wk of overall delay Final Status

2/2/2006 John Smith

NEW REQUIREMENT: Add new Req. 'X' to add export feature

The results display is long and take's long to scroll and compare records

Approved as of 3/2/06

7

Project Management Plan

Sample Workflow diagram shown below: Change Management Process Flow
Approved

Change/ Modification

Review with stakeholders for approval

Criticality and Impact Analysis

Submit CR form

Record to Change Mgmt log

Implement if Approved

NOT Approved

Final Signoff

Describe the release management process for each technical environment:
Prior to a release, the CM manager will review the deliverables leading to the release and ensure that issues identified in the testing phase have been addressed. This review will be presented to the project PI and the additional CM staff members, who will suggest potential problem areas to be tested.

8

Project Management Plan

6. QUALITY ASSURANCE PLAN
<<Briefly describe your plan to assure project and deliverables meet acceptable quality standards. W here applicable as a deliverable, please reference the Quality Assurance Plan. Identify the person(s) responsible for project quality assurance. For an example, please see below:>> QA Responsibility: Rob Smitt Manager: Rob Smitt Additional Staff for QA: Brad Stone, John Hill Repository: “QA” folder in the caBIG directory, which is in the Common Files directory

This QA plan is intended to ensure that the project deliverables accurately reflect the C3D Adoption work. The QA management position is assigned to Rob Smitt, and the QA analyst is John Hill. The QA manager will initiate reviews of the deliverables, and the QA analyst and study staff will provide additional reviews, as appropriate. These reviews will be documented regarding what deficiencies are identified, what actions should be taken and by whom, deadlines for corrections, and when corrections are actually made. Discrepancies among the QA team will be brought to the attention of the PI, Marcy Harris, who will provide final approval of actions to be taken. Results of the reviews of deliverables and ultimate outcomes of identified deficiencies will be circulated to all staff members so that lessons may be learned from the QA process.

9

Project Management Plan

7. INITIAL RISK IDENTIFICATION - SEE CAMP FOR DETAILS
<<**It is highly recommended to use caMP for identifying and tracking Risk. However, the table below has the same fields as caMP and can be used as either a guide or a substitute if you prefer not to use caMP. ** See Appendix B for the process used to manage Risks. A Risk is a speculation of a problem that may likely occur in the future. This is different from an Issue in that Issues are problems that are currently being experienced by the project team which demand action. Risk should be monitored throughout the project. Once realized, they are then transferred to the issues list and managed as issued.>>

Structured Risk Management Matrix (SRMM)
Risk Type Date Identified/ # of wks in SRMM Date of Likelihood Mitigation (this week OR vs Occurrence last week) (indicate which) <Refer to <Refer to appendix appendix A> A> Impact (this week vs last week) <Refer to appendi x A> Conseq uence Structured Mitigation Plan Contingency Plan Comments

<Refer to appendi x A>

<Refe r to appen dix A>

<Refer to appendix A>

<Refer to appendix A>

<Refer to appendix A>

<Refer to appendix A>

<Refer to appendix A>

8. TOP ISSUES
<<Complete this table for all Issues. Issues are problems that are currently being experienced by the project team which demand action. This is different from a Risk in that a Risk is a speculation of a problem that may likely occur in the future. Issues should be tracked to closure. This list should be leveraged to populate the Monthly status report. For an example, please see below: >> ID # Issue Owner Actions Priority Status

10

Project Management Plan

0

<<Name/describe the issue>>

<<Insert Name of the person who is assigned to take immediate action to resolve this issue.>> Developer John Doe

<<Comments about what has taken place so far in trying to resolve.>>

<<See Appendix B>>

<<Open or Closed – plus any other pertinent status details>>

1

Current connection not working

Test configuration

Open – meeting next week

2

11

Project Management Plan

APPENDIX A
Superscript Key: 1 required field for all Risks 2 required field for any Risk with Likelihood >= 50% (2) and Impact >= Moderate 3 required field for any Risk with Impact >= Operational regardless of Likelihood 4 field required when a Risk has either occurred or been successfully mitigated 5 optional field Risk1 – Brief name by which the Risk can be identified in the context of the Project, e.g. “inadequate technical expertise for schema generator too.‟ A more lengthy description of the Risk may be included if deemed helpful to the understanding of the tool by project stakeholders or team members, e.g. „the application must invoke an external schema generator to produce the desired files for export and no one in the development organization currently understands or has experience with the schema generator. The project budget needs to be expanded to either hire the appropriate resource or train an internal resource. Time delays can be expect ed for either solution.” (NOTE: Each Risk should be granular enough to be mitigated by a single, structured Risk Mitigation Plan (see description below).) Type1 – each Risk is assigned a single Type as follows: (Q) Requirements – unknown, incomplete, and/or shifting requirement(s) (R) Resource – limitation in obtaining sufficient, appropriate and/or timely persons, machines, funding for the Project Team to accomplish its stated/assigned goals (S) Social/political/cultural – Vulnerability of the Project‟s schedule, budget, functionality, quality, coherence, or other critical success factors to forces within or external to the team that represent a risk not categorized as risks of type Resource, Technical, or Requirements. (T) Technical – Dependency of the Project on a technology which is new or unproven in the Project‟s context, not well understood by the appropriate members of the Project Team, still under development, poorly documented, supplied by a 3rd-party that is in some way deemed to be at risk (schedule, funding, etc.) etc. Date identified/# of weeks in SRMM1 – The calendar date that the Risk was identified by one or more team members followed by the number of calendar weeks that the risk has been in the project‟s SRMM Date of Mitigation/Occurrence4 – Date that Risk either actually occurred or was successfully mitigated. (NOTE: Date of Occurrence  Likelihood this week = 5 (100%))

12

Project Management Plan

Likelihood (this week / last week)1 – A semi-quantitative assessment by appropriate members of the Project Team as to Likelihood of the occurrence of the named Risk in the next 30 days. 0 = 0% (risk has been successfully mitigated) (NOTE: Risks may be removed from Matrix in this case) 1 = approximately 25% („possible but not likely that Risk will occur in next 30 days‟) 2 = approximately 50% („chances are even that risk will occur in next 30 days‟) 3 = approximately 75% („a good or better than average chance risk will occur in next 30 days‟) 4 = approximately >75% but <100% („risk will almost certainly occur within next 30 days unless immediate mitigated steps are taken‟) 5 = 100% („risk has occurred‟‟) Impact (this week / last week)1 – A semi-quantitative assessment by appropriate members of the Project Team as to Impact of the Risk on the projects schedule, budget, functionality, and/or quality. (N) Negligible – if the Risk occurs, the project‟s schedule, budget, functionality, and/or quality will not be substantively affected because a suitable workaround is available. (M) Moderate – if the Risk occurs, the project‟s functionality and/or quality will ultimately not be substantively affected because a suitable workaround – already identified – can be implemented. Implementation of this workaround will, however, affect the schedule and/or the budget of the project a degree that is fairly well understood by the Project Team. (O) Operational – if the Risk occurs, the project‟s schedule, budget, functionality, and/or quality will be substantively affected. However, the Project Team believes that a suitable workaround is available, but does not have sufficient knowledge of the impact of implementing the workaround to be able to quantitatively assess its overall impact on the project. (NOTE: this is a mid-ground classification between „Moderate,‟ where both the impact of the Risk‟s occurrence and the existence (and impact) of a suitable workaround are fairly well understood – and „Profound‟, where the impact of the Risk‟s occurrence is known to be so severe as to threaten (or signal) the demise of the project.) (P) Profound – if the Risk occurs, the project‟s schedule, budget, functionality, and/or quality will be substantively affected to such a degree that the project will either not be able to continue without a substantive analysis of the affected areas of the project, a significant refocusing or redefinition of the project (as outlined in the Risk‟s Contingency Plan, or, in some cases, cancellation of the Project. Consequence5 – an optional text description of the expected consequence of a given Risk should it occur.

13

Project Management Plan

Mitigation Plan3 – A defined set of tasks agreed upon by appropriate members of the Project Team, that will be executed in the current week‟s Project Plan, with the express purpose of reducing a given Risk‟s Likelihood and/or Impact. All Risks with a Likelihood of 3 or more and/or an Impact of Operational or Profound must have a defined Mitigation Plan. (NOTE: a given Project Team may choose to define Risk Mitigation Plans for Risks with lower Likelihood and/or Impact rankings). All tasks in the Mitigation Plan should be assignable to a single accountable resource associated to the Project. Each Task must be granular enough to be accomplished with one week‟s time by the assigned resource, i.e. the tasks listed in a given Risk’s Mitigation Plan are expected to flow from the Risk Matrix onto the team’s Project Plan. (NOTE: For Mitigation Plans whose complete Task Set requires more than one week to complete, the Project Team may find it helpful to indicate in this Risk Matrix column from week-to-week which of the specific tasks in the Mitigation Strategy have been completed to better help in the visual tracking of the progress of the Mi tigation Strategy.) Contingency Plan4 -- A defined set of tasks agreed upon by appropriate members of the Project Team that will be undertaken to manage the Project Team in the event the Risk occurs, roughly equivalent to an organization‟s various Disaster Plans. Tasks should be assignable to a single accountable resource. Given the substantive effect that the Risk is judged to have on the Project, the Contingency Plan may be relatively short with the realization that if it is invoked, it will ultimately give rise to a larger Project Plan detailed elsewhere. Otherwise, the guidelines for granularity etc. of individual tasks are identical to those described for the Mitigation Strategy. All risks with an Impact rating of Profound must have an associated Contingency Plan. If the decision has already been made to cancel the project if the Risk occurs, the Contingency Plan should state this fact, i.e. “NONE – project will be terminated” Comments5 – Any additional comments that the Project Team would like to add to the documentation of the Risk that will help nonteam project stakeholders better understand the Risk and its management.

14

Project Management Plan

APPENDIX B
The following details guidelines for Priority rankings of project Issues.

Priority Status High Medium Low

Guideline Descriptions
Immediate, or near immediate, Block of project progress. If left unresolved, will prevent success. Issue will block of project progress within 2 weeks. Without resolution, the end goal will not be fully achieved. Does not block project timelines or success. If left unresolved, will NOT prevent project success.

15


				
DOCUMENT INFO
Shared By:
Stats:
views:9438
posted:1/28/2008
language:English
pages:16
ocak ocak
About