Project Plan Baseline Template

Tags

project management, document

You must be logged in to download this document

be first to review

<> Project Management Plan Document Change History Version Number Date Contributor Description V1.0 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 1. PROJECT SUMMARY Project Name: <> Start Date: <> Cancer Center: <> Date Awarded: <> Current Stage of Project: << Insert Development Life Cycle (Design, Development, Integration or Testing or Implementation)>> Ex: Implementation Points of Contact: > Position Name/Organization Phone E-mail Project PI Project Manager Procurement Contact Data Manager Customers: Other Stakeholders (Top 3): 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 <> *Note to developer, a Unified Process based project plan sample is available upon request and/or for download. Task # Activity Name Activity Name Description # of Days Start Date Dependenc y Milestone 1.1 Project management (PM) Adopter will manage Center level project activities and use caMP to track deliverables. 5 3/15/06 None Project management plan 1.2 PM – Staffing plan Center lead will assign adopter team members to activities. 5 3/25/06 1.1 Staffing plan 1.3 PM – Monthly status reports Document progress, meetings and action items. Review and provide feedback to NCICB on documentation. Attend BP and SOP monthly teleconferences. 2 4/1/06 None March status report 1.4 PM – Training Arrange appropriate, ongoing training for adopter staff. 1 4/1/06 None March training report 2.1 Study selection Finalize study selection. Assess CRF reusability. 3 3/25/06 None Study selection report 3.1.1 1st study activities (1st) – Identify CRFs Identify and prioritize CRFs. 5 3/28/06 2.1 Provisional implementation plan3. WORK PRODUCT IDENTIFICATION <> Deliverable Name Due Date Date Delivered Point of Contact Task 1.1 Project management 3/29/06 Rob Smitt Task 1.2 Staffing plan 4/12/06 Rob Smitt Task 1.3 Monthly status report 4/5/06 + 5th of each month Brad Stone Task 1.4 Monthly training report 4/5/06 + 5th of each month Brad Stone Task 2.1 Study selection report 3/22/06 Rob Smitt Task 3.1.1 Provisional implementation plan 3/29/06 Rob Smitt Task 3.1.2 Catalog of CRFs 4/5/06 Rob Smitt Task 3.2.1 C3D user list 4/19/06 Brad Stone Task 3.2.2 Training list 4/19/06 Brad Stone Task 3.3.1 eCRF modification requests 4/26/06 Rob Smitt Task 3.3.2 New eCRF requests 4/26/06 Rob Smitt Task 3.4.1 Existing CDEs used 4/26/06 Rob Smitt Task 3.4.2 New CDE requests 4/26/06 Rob Smitt4. RESOURCE PROFILES – STAFFING <> Project lead Program coordinator Data manager Adopter PI 1st Study PI 2nd Study PI Data entry Total FTE February 0.6 0.15 0.10 0.05 0.05 0.05 0 1 March 0.6 0.15 0.10 0.05 0.05 0 0 0.95 April 0.6 0.15 0.10 0.05 0.05 0 0 0.95 May 0.6 0.15 0.4 0.05 0.05 0 0 1.25 June 0.6 0.15 0.4 0.05 0.05 0 0.5 1.75 July 0.6 0.15 0.4 0.05 0.05 0 0.5 1.75 August 0.6 0.15 0.10 0.05 0 0.05 0 0.95 September 0.6 0.15 0.10 0.05 0 0.05 0 0.95 October 0.6 0.15 0.10 0.05 0 0.05 0 0.95 November 0.6 0.15 0.4 0.05 0 0.05 0.5 1.75 December 0.6 0.15 0.4 0.05 0 0.05 0.5 1.755. CONFIGURATION/CHANGE MANAGEMENT PLAN <> 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 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 Estimated LOE -2w. Populating data from multiple tables. Will need reindexing. Timeline: 2 wk of overall delay Approved as of 3/2/06 Sample Workflow diagram shown below: Change Management Process Flow Change/Modification Review with stakeholders for approval Submit CR form Record to Change Mgmt log Criticality and Impact Analysis Implement if Approved 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. 6. QUALITY ASSURANCE PLAN <> 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.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 Mitigation OR Occurrence (indicate which) Likelihood (this week vs last week) Impact (this week vs last week) Conseq uence Structured Mitigation Plan Contingency Plan Comments 8. TOP ISSUES <> ID # Issue Owner Actions Priority Status0 <> <> <> <> <> 1 Current connection not working Developer John Doe Test configuration Open – meeting next week 2 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 expected 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%)) 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.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 Mitigation 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 non-team project stakeholders better understand the Risk and its management.APPENDIX B The following details guidelines for Priority rankings of project Issues. Priority Status Guideline Descriptions High Immediate, or near immediate, Block of project progress. If left unresolved, will prevent success. Medium Issue will block of project progress within 2 weeks. Without resolution, the end goal will not be fully achieved. Low Does not block project timelines or success. If left unresolved, will NOT prevent project success.