Sample Project Plans, Project Charter

Sample Project Management Plan (PMP)

Introduction to Project Management Plan

Project Management Approach

Importance of Project Scope

Milestone List

Schedule Baseline and Work Breakdown Structure

Sample Project Management Plans

Change Management Plan

Communications Management Plan

Communications Conduct:

Cost Management Plan

Procurement Management Plan

Project Scope Management Plan

Schedule Management Plan

Quality Management Plan

Risk Management Plan

Risk Register

Staffing Management Plan

Resource Calendar

Cost Baseline

Quality Baseline

Sample Cost Management Plan

Introduction

Cost Management Approach

Project Costs Measurement

Format for Reporting

Cost Variance Response Process

Project Budget

Sample Project Charter

Executive Summary

Project Purpose/Justification

Project Description

Project Deliverables

Summary Milestone Schedule

Summary Budget

Project Approval Requirements

Project Manager

Authorization

Sample Scope Management Plan

Introduction

Scope Management Approach

Roles and Responsibilities

Scope Definition

Project Scope Statement

Work Breakdown Structure

Verify Scope

Control Scope

Sample Risk Management Plan

Introduction

Top Three Risks

Risk Management Approach

Risk Identification

Risk Qualification and Prioritization

Risk Monitoring

Risk Mitigation and Avoidance

Sample Human Resource Plan

Introduction

Roles and Responsibilities

Project Organizational Charts

Staffing Management

Sample Product Scope Description

Sample Requirements Management Plan

Introduction

Requirements Management Approach

Configuration Management

Requirements Prioritization Process

Product Metrics

Requirements Traceability Matrix

Schedule Management Plan

Introduction

Schedule Management Approach

Schedule Control

Schedule Changes and Thresholds

Scope Change

Sample Quality Management Plan

Introduction

Quality Management Approach

Quality Requirements/Standards

Quality Assurance

Quality Control

Quality Control Measurements

This introduction provides a high level overview of the project and what is included in this Project Management Plan. This should include a high level description of the project and describe the projects deliverable and benefits. Excessive detail is not necessary in this section as the other sections of the project plan will include this information. This section of the project plan template should provide a summarized framework of the project and its purpose. Look back at the Project Charter for information to include in this section.

Total Software Incorporated (TSI) has recently approved the SmartVoice project to move forward for project initiation within the research and development (R&D) group. This project will result in the development of new voice recognition software and supports TSI's corporate strategy of providing progressive solutions to clients which improve productivity in both the workplace and home environment. While voice recognition software is currently available, TSI believes that new technological developments will enable our team to develop a solution far superior to what is currently available.

TSI has been successful in gaining market share because of its aggressive pursuit of product quality, ease of use, flexibility, and customer service. Additionally, customers understand that our products may be applied to a wide range of uses for business and personal functions. By leveraging our reputation for superior quality and user-friendly products, and capitalizing on new technology, TSI can position itself as the premier provider of effective and easy to use voice recognitions software in today's marketplace.

This section of the Project Plan is where you outline the overall management approach for the project. This section should describe, in general terms, the roles and authority of project team members. It should also include which organizations will provide resources for the project and any resource constraints or limitations. If there are any decisions which must be made by specific individuals—for example authorizing additional funding by the project sponsor—this should also be stated here. It should be written as an Executive Summary for the Project Management Plan.

The Project Manager, Joe Green, has the overall authority and responsibility for managing and executing this project according to this Project Plan and its Subsidiary Management Plans. The project team will consist of personnel from the coding group, quality control/assurance group, technical writing group, and testing group. The project manager will work with all resources to perform project planning. All project and subsidiary management plans will be reviewed and approved by the project sponsor. All funding decisions will also be made by the project sponsor. Any delegation of approval authority to the project manager should be done in writing and be signed by both the project sponsor and project manager.

The project team will be a matrix in that team members from each organization continue to report to their organizational management throughout the duration of the project. The project manager is responsible for communicating with organizational managers on the progress and performance of each project resource.

State the scope of the project in this section of the Project Management Plan. The scope statement from the project charter should be used as a starting point; however, the project plan needs to include a much more detailed scope than the charter. This detail should include what the project does and does not include. The more detail included in this section, the better the product. This will help to clarify what is included in the project and help to avoid any confusion from project team members and stakeholders.

The scope of TSI's SmartVoice project includes the planning, design, development, testing, and transition of the SmartVoice voice recognition software package. This software will meet or exceed organizational software standards and additional requirements established in the project charter. The scope of this project also includes completion of all documentation, manuals, and training aids to be used in conjunction with the software. Project completion will occur when the software and documentation package has been successfully executed and transitioned to TSI's manufacturing group for production.

All SmartVoice project work will be performed internally and no portion of this project will be outsourced. The scope of this project does not include any changes in requirements to standard operating systems to run the software, software updates or revisions.

Provide a summary list of milestones including dates for each milestone. Include an introductory paragraph in this section which provides some insight to the major milestones. This section of the project plan template should also mention or discuss actions taken if any changes to the milestones or delivery dates are required.

The below chart lists the major milestones for the SmartVoice Project. This chart is comprised only of major project milestones such as completion of a project phase or gate review. There may be smaller milestones which are not included on this chart but are included in the project schedule and WBS. If there are any scheduling delays which may impact a milestone or delivery date, the project manager must be notified immediately so proactive measures may be taken to mitigate slips in dates. Any approved changes to these milestones or dates will be communicated to the project team by the project manager.

Milestone	Description	Date
Complete Requirements Gathering	All requirements for SmartVoice must be determined to base design upon	2/28/xx
Complete SmartVoice Design	This is the theoretical design for the software and its functionality	5/31/xx
Complete SmartVoice Coding	All coding completed resulting in software prototype	7/31/xx
Complete SmartVoice Testing and Debugging	All functionality tested and all identified errors corrected	8/31/xx
Complete Transition of SmartVoice to TSI Production	Completed software and documentation transitioned to operations group to begin production	11/30/xx

This section of the Project Management Plan should discuss the WBS, WBS Dictionary, and Schedule baseline and how they will be used in managing the project's scope. The WBS provides the work packages to be performed for the completion of the project. The WBS Dictionary defines the work packages. The schedule baseline provides a reference point for managing project progress as it pertains to schedule and timeline. The schedule baseline and work breakdown structure (WBS) should be created in Microsoft Project. The WBS can be exported from the MS Project file. Be sure to consult our Work Breakdown Structure Template.

The WBS for the SmartVoice Project is comprised of work packages which do not exceed 40 hours of work but are at least 4 hours of work. Work packages were developed through close collaboration among project team members and stakeholders with input from functional managers and research from past projects.

The WBS Dictionary defines all work packages for the SmartVoice Project. These definitions include all tasks, resources, and deliverables. Every work package in the WBS is defined in the WBS Dictionary and will aid in resource planning, task completion, and ensuring deliverables meet project requirements.

The SmartVoice Project schedule was derived from the WBS and Project Charter with input from all project team members. The schedule was completed, reviewed by the Project Sponsor, and approved and base-lined. The schedule will be maintained as a MS Project Gantt Chart by the SmartVoice Project Manager. Any proposed changes to the schedule will follow TSI's change control process. If established boundary controls may be exceeded, a change request will be submitted to the Project Manager. The Project Manager and team will determine the impact of the change on the schedule, cost, resources, scope, and risks. If it is determined that the impacts will exceed the boundary conditions then the change will be forwarded to the Project Sponsor for review and approval. The SmartVoice boundary conditions are:

CPI less than 0.8 or greater than 1.2
SPI less than 0.8 or greater than 1.2

If the change is approved by the Project Sponsor then it will be implemented by the Project Manager who will update the schedule and all documentation and communicate the change to all stakeholders in accordance with the Change Control Process.

The Project Schedule Baseline and Work Breakdown Structure are provided in Appendix A, Project Schedule and Appendix B, Work Breakdown Structure.

This part of the Project Plan should describe your change control process. Ideally, this process will be some type of organizational standard which is repeatable and done on most or all projects when a change is necessary. Changes to any project must be carefully considered and the impact of the change must be clear in order to make any type of approval decisions. Many organizations have change control boards (CCBs) which review proposed changes and either approve or deny them. This is an effective way to provide oversight and ensure adequate feedback and review of the change is obtained. This section of the project plan template gives you an place where you should also identify who has approval authority for changes to the project, who submits the changes, how they are tracked and monitored.

For complex or large projects the Change Management Plan may be included as an appendix to the Project Management Plan or as a separate, stand-alone document. We have a detailed Change Management Plan Template available on our website.

The following steps comprise TSI's organization change control process for all projects and will be utilized on the SmartVoice project:

Step #1: Identify the need for a change (Any Stakeholder)
Requestor will submit a completed TSI change request form to the project manager
Step #2: Log change in the change request register (Project Manager)
The project manager will maintain a log of all change requests for the duration of the project
Step #3: Conduct an evaluation of the change (Project Manager, Project Team, Requestor)
The project manager will conduct an evaluation of the impact of the change to cost, risk, schedule, and scope
Step #4: Submit change request to Change Control Board (CCB) (Project Manager)
The project manager will submit the change request and analysis to the CCB for review
Step #5: Change Control Board decision (CCB)
The CCB will discuss the proposed change and decide whether or not it will be approved based on all submitted information
Step #6: Implement change (Project Manager)
If a change is approved by the CCB, the project manager will update and re-baseline project documentation as necessary as well as ensure any changes are communicated to the team and stakeholders

Any team member or stakeholder may submit a change request for the SmartVoice Project. The SmartVoice Project Sponsor will chair the CCB and any changes to project scope, cost, or schedule must meet his approval. All change requests will be logged in the change control register by the Project Manager and tracked through to completion whether approved or not.

The purpose of the Communications Management Plan is to define the communication requirements for the project and how information will be distributed to ensure project success. You should give considerable thought to how you want to manage communications on every project. By having a solid communications management approach you'll find that many project management problems can be avoided. In this section you should provide an overview of your communications management approach. Generally, the Communications Management Plan defines the following:

Communication requirements based on roles
What information will be communicated
How the information will be communicated
When will information be distributed
Who does the communication
Who receives the communication
Communications conduct

For larger and more complex projects, the Communications Management Plan may be included as an appendix or separate document apart from the Project Management Plan. We have a detailed Communications Management Plan Template available on our website.

This Communications Management Plan sets the communications framework for this project. It will serve as a guide for communications throughout the life of the project and will be updated as communication requirements change. This plan identifies and defines the roles of SmartVoice project team members as they pertain to communications. It also includes a communications matrix which maps the communication requirements of this project, and communication conduct for meetings and other forms of communication. A project team directory is also included to provide contact information for all stakeholders directly involved in the project.

The Project Manager will take the lead role in ensuring effective communications on this project. The communications requirements are documented in the Communications Matrix below. The Communications Matrix will be used as the guide for what information to communicate, who is to do the communicating, when to communicate it, and to whom to communicate.

Communication Type

Description

Frequency

Format

Participants/ Distribution

Deliverable

Owner

Weekly Status Report

Email summary of project status

Weekly

Project Sponsor, Team and Stakeholders

Status Report

Project Manager

Weekly Project Team Meeting

Meeting to review action register and status

Weekly

In Person

Project Team

Updated Action Register

Project Manager

Project Monthly Review (PMR)

Present metrics and status to team and sponsor

Monthly

In Person

Project Sponsor, Team, and Stakeholders

Status and Metric Presentation

Project Manager

Project Gate Reviews

Present closeout of project phases and kickoff next phase

As Needed

In Person

Project Sponsor, Team and Stakeholders

Phase completion report and phase kickoff

Project Manager

Technical Design Review

Review of any technical designs or work associated with the project

As Needed

In Person

Project Team

Technical Design Package

Project Manager

Project team directory for all communications is:

Name	Title	Email	Office Phone	Cell Phone
John Davis	Project Sponsor	This e-mail address is being protected from spambots. You need JavaScript enabled to view it	xxx-xxx-xxxx	xxx-xxx-xxxx
Joe Green	Project Manager	This e-mail address is being protected from spambots. You need JavaScript enabled to view it	xxx-xxx-xxxx	xxx-xxx-xxxx
Herb Walker	Senior Programmer	This e-mail address is being protected from spambots. You need JavaScript enabled to view it	xxx-xxx-xxxx	xxx-xxx-xxxx
Jason Black	Programmer	This e-mail address is being protected from spambots. You need JavaScript enabled to view it	xxx-xxx-xxxx	xxx-xxx-xxxx
Mary White	Sr. Quality Specialist	This e-mail address is being protected from spambots. You need JavaScript enabled to view it	xxx-xxx-xxxx	xxx-xxx-xxxx
Ron Smith	Quality Specialist	This e-mail address is being protected from spambots. You need JavaScript enabled to view it	xxx-xxx-xxxx	xxx-xxx-xxxx
Tom Sunday	Technical Writer	This e-mail address is being protected from spambots. You need JavaScript enabled to view it	xxx-xxx-xxxx	xxx-xxx-xxxx
Karen Brown	Testing Specialist	This e-mail address is being protected from spambots. You need JavaScript enabled to view it	xxx-xxx-xxxx	xxx-xxx-xxxx

Meetings:
The Project Manager will distribute a meeting agenda at least 2 days prior to any scheduled meeting and all participants are expected to review the agenda prior to the meeting. During all project meetings the timekeeper will ensure that the group adheres to the times stated in the agenda and the recorder will take all notes for distribution to the team upon completion of the meeting. It is imperative that all participants arrive to each meeting on time and all cell phones and blackberries should be turned off or set to vibrate mode to minimize distractions. Meeting minutes will be distributed no later than 24 hours after each meeting is completed.

Email:
All email pertaining to the SmartVoice Project should be professional, free of errors, and provide brief communication. Email should be distributed to the correct project participants in accordance with the communication matrix above based on its content. All attachments should be in one of the organization's standard software suite programs and adhere to established company formats. If the email is to bring an issue forward then it should discuss what the issue is, provide a brief background on the issue, and provide a recommendation to correct the issue. The Project Manager should be included on any email pertaining to the SmartVoice Project.

Informal Communications:
While informal communication is a part of every project and is necessary for successful project completion, any issues, concerns, or updates that arise from informal discussion between team members must be communicated to the Project Manager so the appropriate action may be taken.

The Cost Management Plan clearly defines how the costs on a project will be managed throughout the project's lifecycle. It sets the format and standards by which the project costs are measured, reported, and controlled. Working within the cost management guidelines is imperative for all project team members to ensure successful completion of the project. These guidelines may include which level of the WBS cost accounts will be created in and the establishment of acceptable variances. The Cost Management Plan:

Identifies who is responsible for managing costs
Identifies who has the authority to approve changes to the project or its budget
How cost performance is quantitatively measured and reported upon
Report formats, frequency and to whom they are presented

For complex or large projects the Cost Management Plan may be included as an appendix to the Project Plan or as a separate, stand-alone document. In addition to this project plan template we have a detailed Cost Management Plan Template available on our website.

The Project Manager will be responsible for managing and reporting on the project's cost throughout the duration of the project. The Project Manager will present and review the project's cost performance during the monthly project status meeting. Using earned value calculations, the Project Manager is responsible for accounting for cost deviations and presenting the Project Sponsor with options for getting the project back on budget. All budget authority and decisions, to include budget changes, reside with the SmartVoice Project Sponsor.

For the SmartVoice Project, control accounts will be created at the fourth level of the WBS which is where all costs and performance will be managed and tracked. Financial performance of the SmartVoice Project will be measured through earned value calculations pertaining to the project's cost accounts. Work started on work packages will grant that work package with 50% credit; whereas, the remaining 50% is credited upon completion of all work defined in that work package. Costs may be rounded to the nearest dollar and work hours rounded to the nearest whole hour.

Cost and Schedule Performance Index ( CPI and SPI respectively) will be reported on a monthly basis by the Project Manager to the Project Sponsor. Variances of 10% or +/- 0.1 in the cost and schedule performance indexes will change the status of the cost to yellow or cautionary. These will be reported and if it's determined that there is no or minimal impact on the project's cost or schedule baseline then there may be no action required. Cost variances of 20%, or +/- 0.2 in the cost and schedule performance indexes will change the status of the cost to red or critical. These will be reported and require corrective action from the Project Manager in order to bring the cost and/or schedule performance indexes back in line with the allowable variance. Any corrective actions will require a project change request and be must approved by the CCB before it can be implemented.

Earned value calculations will be compiled by the Project Manager and reported at the monthly project status meeting. If there are indications that these values will approach or reach the critical stage before a subsequent meeting, the Project Manager will communicate this to the Project Sponsor immediately.

The Procurement Management Plan should be defined enough to clearly identify the necessary steps and responsibilities for procurement from the beginning to the end of a project. The project manager must ensure that the plan facilitates the successful completion of the project and does not become an overwhelming task in itself to manage. The project manager will work with the project team, contracts/purchasing department, and other key players to manage the procurement activities.

For larger projects or projects with more complicated procurement management requirements, you can include the Procurement Management Plan as a separate document apart from the Project Management Plan. In addition to this Project Plan Template we have a detailed Procurement Management Plan Template available on our website.

The Project Manager will provide oversight and management for all procurement activities under this project. The Project Manager is authorized to approve all procurement actions up to $50,000. Any procurement actions exceeding this amount must be approved by the Project Sponsor.

While this project requires minimal or no procurement, in the event procurement is required, the Project Manager will work with the project team to identify all items or services to be procured for the successful completion of the project. The Project Manager will then ensure these procurements are reviewed by the Program Management Office (PMO) and presented to the contracts and purchasing groups. The contracts and purchasing groups will review the procurement actions, determine whether it is advantageous to make or buy the items or resource required services internally, and begin the vendor selection, purchasing and the contracting process.

In the event a procurement becomes necessary, the Project Manager will be responsible for management any selected vendor or external resource. The Project Manager will also measure performance as it relates to the vendor providing necessary goods and/or services and communicate this to the purchasing and contracts groups.

It is important that the approach to managing the projects' scope be clearly defined and documented in detail. Failure to clearly establish and communicate project scope can result in delays, unnecessary work, failure to achieve deliverables, cost overruns, or other unintended consequences. This section provides a summary of the Scope Management Plan in which it addresses the following:

Who has authority and responsibility for scope management
How the scope is defined (i.e. Scope Statement, WBS, WBS Dictionary, Statement of Work)
How the scope is measured and verified (i.e. Quality Checklists, Scope Baseline, Work Performance Measurements, etc.)
The scope change process (who initiates, who authorizes, etc.)
Who is responsible for accepting the final project deliverable and approves acceptance of project scope

We have a detailed Scope Management Plan Template available on our website which can be included as an appendix to the Project Management Plan for larger or more complex projects. Be sure to review it and determine if it's necessary for managing your project.

Scope management for the SmartVoice Project will be the sole responsibility of the Project Manager. The scope for this project is defined by the Scope Statement, Work Breakdown Structure (WBS) and WBS Dictionary. The Project Manager, Sponsor, and Stakeholders will establish and approve documentation for measuring project scope which includes deliverable quality checklists and work performance measurements.

Proposed scope changes may be initiated by the Project Manager, Stakeholders or any member of the project team. All change requests will be submitted to the Project Manager who will then evaluate the requested scope change. Upon acceptance of the scope change request the Project Manager will submit the scope change request to the Change Control Board and Project Sponsor for acceptance. Upon approval of scope changes by the Change Control Board and Project Sponsor the Project Manager will update all project documents and communicate the scope change to all stakeholders. Based on feedback and input from the Project Manager and Stakeholders, the Project Sponsor is responsible for the acceptance of the final project deliverables and project scope.

The Project Sponsor is responsible for formally accepting the project's final deliverable. This acceptance will be based on a review of all project documentation, testing results, beta trial results, and completion of all tasks/work packages and product functionality.

This section of the Project Plan provides a general framework for the approach which will be taken to create the project schedule. Effective schedule management is necessary for ensuring tasks are completed on time, resources are allocated appropriately, and to help measure project performance. This section of the Project Plan should include discussion of the scheduling tool/format, schedule milestones, and schedule development roles and responsibilities.

Be sure to check out the detailed Schedule Management Plan Template available on our website. The separate Schedule Management Plan is suitable for larger projects or projects where the schedule management is more formalized. The Schedule Management Plan can be broken out as an appendix to the Project Plan.

Project schedules for the SmartVoice Project will be created using MS Project 2007 starting with the deliverables identified in the project's Work Breakdown Structure (WBS). Activity definition will identify the specific work packages which must be performed to complete each deliverable. Activity sequencing will be used to determine the order of work packages and assign relationships between project activities. Activity duration estimating will be used to calculate the number of work periods required to complete work packages. Resource estimating will be used to assign resources to work packages in order to complete schedule development.

Once a preliminary schedule has been developed, it will be reviewed by the project team and any resources tentatively assigned to project tasks. The project team and resources must agree to the proposed work package assignments, durations, and schedule. Once this is achieved the project sponsor will review and approve the schedule and it will then be base lined.

In accordance with TSI's organizational standard, the following will be designated as milestones for all project schedules:

Completion of scope statement and WBS/WBS Dictionary
Baselined project schedule
Approval of final project budget
Project kick-off
Approval of roles and responsibilities
Requirements definition approval
Completion of data mapping/inventory
Project implementation
Acceptance of final deliverables

Roles and responsibilities for schedule development are as follows:

The project manager will be responsible for facilitating work package definition, sequencing, and estimating duration and resources with the project team. The project manager will also create the project schedule using MS Project 2007 and validate the schedule with the project team, stakeholders, and the project sponsor. The project manager will obtain schedule approval from the project sponsor and baseline the schedule.

The project team is responsible for participating in work package definition, sequencing, duration, and resource estimating. The project team will also review and validate the proposed schedule and perform assigned activities once the schedule is approved.

The project sponsor will participate in reviews of the proposed schedule and approve the final schedule before it is base lined.

The project stakeholders will participate in reviews of the proposed schedule and assist in its validation.

This portion of the Project Plan Template discusses how quality management will be used to ensure that the deliverables for the project meet a formally established standard of acceptance. All project deliverables should be defined in order to provide a foundation and understanding of the tasks at hand and what work must be planned. Quality management is the process by which the organization not only completes the work, but completes the work to an acceptable standard. Without a thorough Quality Management Plan, work may be completed in a substandard or unacceptable manner. This section should include quality roles and responsibilities, quality control, quality assurance, and quality monitoring.

For larger or more complex projects, the Quality Management Plan may be included as an appendix or separate document from the Project Management Plan. A detailed Quality Management Plan Template is available for use on our website.

All members of the SmartVoice project team will play a role in quality management. It is imperative that the team ensures that work is completed at an adequate level of quality from individual work packages to the final project deliverable. The following are the quality roles and responsibilities for the SmartVoice Project:

The Project Sponsor is responsible for approving all quality standards for the SmartVoice Project. The Project Sponsor will review all project tasks and deliverables to ensure compliance with established and approved quality standards. Additionally, the Project Sponsor will sign off on the final acceptance of the project deliverable.

The Project Manager is responsible for quality management throughout the duration of the project. The Project Manager is responsible for implementing the Quality Management Plan and ensuring all tasks, processes, and documentation are compliant with the plan. The Project Manager will work with the project's quality specialists to establish acceptable quality standards. The Project Manager is also responsible for communicating and tracking all quality standards to the project team and stakeholders.

The Quality Specialists are responsible for working with the Project Manager to develop and implement the Quality Management Plan. Quality Specialists will recommend tools and methodologies for tracking quality and standards to establish acceptable quality levels. The Quality Specialists will create and maintain Quality Control and Assurance Logs throughout the project.

The remaining member of the project team, as well as the stakeholders will be responsible for assisting the Project Manager and Quality Specialists in the establishment of acceptable quality standards. They will also work to ensure that all quality standards are met and communicate any concerns regarding quality to the Project Manager.

Quality control for the SmartVoice Project will utilize tools and methodologies for ensuring that all project deliverables comply with approved quality standards. To meet deliverable requirements and expectations, we must implement a formal process in which quality standards are measured and accepted. The Project Manager will ensure all quality standards and quality control activities are met throughout the project. The Quality Specialists will assist the Project Manager in verifying that all quality standards are met for each deliverable. If any changes are proposed and approved by the Project Sponsor and CCB, the Project Manager is responsible for communicating the changes to the project team and updating all project plans and documentation.

Quality assurance for the SmartVoice Project will ensure that all processes used in the completion of the project meet acceptable quality standards. These process standards are in place to maximize project efficiency and minimize waste. For each process used throughout the project, the Project Manager will track and measure quality against the approved standards with the assistance of the Quality Specialists and ensure all quality standards are met. If any changes are proposed and approved by the Project Sponsor and CCB, the Project Manager is responsible for communicating the changes to the project team and updating all project plans and documentation.

This part of the Project Plan provides a general description for the approach taken to identify and manage the risks associated with the project. It should be a short paragraph or two summarizing the approach to risk management on this project.

Since risk management is a science in itself, we have many risk management templates available on our website. Look for the detailed Risk Management Plan Template, Risk Register Template along with our article on how to perform a risk assessment meeting.

The approach for managing risks for the SmartVoice Project includes a methodical process by which the project team identifies, scores, and ranks the various risks. Every effort will be made to proactively identify risks ahead of time in order to implement a mitigation strategy from the project's onset. The most likely and highest impact risks were added to the project schedule to ensure that the assigned risk managers take the necessary steps to implement the mitigation response at the appropriate time during the schedule. Risk managers will provide status updates on their assigned risks in the bi-weekly project team meetings, but only when the meetings include their risk's planned timeframe.

Upon the completion of the project, during the closing process, the project manager will analyze each risk as well as the risk management process. Based on this analysis, the project manager will identify any improvements that can be made to the risk management process for future projects. These improvements will be captured as part of the lessons learned knowledge base.

The Risk Register for this project is provided here

Here the Project Plan Template discusses how you plan to staff the project. This section should include discussion on matrixed or projectized organizational structure depending on which is being used for this project. This section of the project plan should also include how resources will be procured and managed as well as the key resources needed for the project.

The SmartVoice Project will consist of a matrix structure with support from various internal organizations. All work will be performed internally. Staffing requirements for the SmartVoice Project include the following:

Project Manager (1 position) – responsible for all management for the SmartVoice Project. The Project Manager is responsible for planning, creating, and/or managing all work activities, variances, tracking, reporting, communication, performance evaluations, staffing, and internal coordination with functional managers.

Senior Programmer (1 position) – responsible for oversight of all coding and programming tasks for the SmartVoice Project as well as ensuring functionality is compliant with quality standards. Responsible for working with the Project Manager to create work packages, manage risk, manage schedule, identify requirements, and create reports. The Senior Programmer will be managed by the Project Manager who will provide performance feedback to the functional manager.

Programmer (1 position) – responsible for coding and programming for the SmartVoice Project. All coding and programming tasks will be reviewed by the Senior Programmer prior to implementation. Responsibilities also include assisting with risk identification, determining impacts of change requests, and status reporting. The Programmer will be managed by the Project Manager and feedback will be provided to the functional manager for performance evaluations by the Project Manager and Senior Programmer.

Senior Quality Specialist (1 position) – responsible for assisting the Project Manager in creating quality control and assurance standards. The Senior Quality Specialist is also responsible for maintaining quality control and assurance logs throughout the project. The Senior Quality Specialist will be managed by the Project Manager who will also provide feedback to the functional manager for performance evaluations.

Quality Specialist (1 position) – responsible for assisting the Project Manager and Senior Quality Specialist in creating and tracking quality control and assurance standards. The Quality Specialist will have primary responsibility for compiling quality reporting and metrics for the Project Manager to communicate. The Quality Specialist will be managed by the Project Manager who will provide feedback, along with the Senior Quality Specialist to the functional manager for performance evaluations.

Technical Writer (1 position) – responsible for compiling all project documentation and reporting into organizational formats. Responsible for assisting the Project Manager in Configuration Management and revision control for all project documentation. Responsible for scribing duties during all project meetings and maintaining all project communication distribution lists. The Technical Writer will be managed by the Project Manager who will also provide feedback to the functional manager for performance evaluations.

Testing Specialist (1 position) – responsible for helping establish testing specifications for the SmartVoice Project with the assistance of the Project Manager and Programmers. Responsible for ensuring all testing is complete and documented in accordance with TSI standards. Responsible for ensuring all testing resources are coordinated. The Testing Specialist will be managed by the Project Manager who will also provide feedback to the functional manager for performance evaluations.

The Project Manager will negotiate with all necessary TSI functional managers in order to identify and assign resources for the SmartVoice Project. All resources must be approved by the appropriate functional manager before the resource may begin any project work. The project team will not be co-located for this project and all resources will remain in their current workspace.

Include a Resource Calendar as part of your project plan. The resource calendar identifies key resources needed for the project and the times/durations they'll be needed. Some resources may be needed for the entire length of the project while others may only be required for a portion of the project. This information must be agreed to by the Project Sponsor and Functional Managers prior to beginning the project.

The SmartVoice Project will require all project team members for the entire duration of the project although levels of effort will vary as the project progresses. The Project is scheduled to last one year with standard 40 hour work weeks. If a project team member is not required for a full 40 hour work week at any point during the project, their efforts outside of the SmartVoice Project will be at the discretion of their Functional Manager.

resource calendar

This section of the Project Plan Template contains the cost baseline for the project upon which cost management will be based. The project will use earned value metrics to track and manage costs and the cost baseline provides the basis for the tracking, reporting, and management of costs.

The cost baseline for the SmartVoice project includes all budgeted costs for the successful completion of the project.

Project Phase	Budgeted Total	Comments
Planning	$350,000	Includes work hours for all project team members for gathering requirements and planning project
Design	$250,000	Includes work hours for all project team members for work on SmartVoice conceptual design
Coding	$200,000	Includes all work hours for coding of SmartVoice
Testing	$175,000	Includes all work hours for testing (including beta testing) of SmartVoice software
Transition and Closeout	$150,000	Includes all work hours for transition to operations and project closeout

This section of the Project Management Plan should include the quality baseline for the project. The purpose of this baseline is to provide a basis for ensuring that quality can be measured to determine if acceptable quality levels have been achieved. It is important for all projects to clearly define and communicate quality standards and the quality baseline serves this purpose. This is why the quality baseline is included in the Project Management Plan Template.

The SmartVoice Project must meet the quality standards established in the quality baseline. The quality baseline is the baseline which provides the acceptable quality levels of the SmartVoice Project. The software must meet or exceed the quality baseline values in order to achieve success.

Item	Acceptable Level	Comments
Voice Recognition	At least 98% recognition level with 2% or less errors in text	Using standard TSI English language databases
Compatibility	No errors associated with running software with compatible applications	Using the _______ suite of applications
Supporting Documentation	Less than 1% failure rate in beta testing new users to run setup and execute software functionality

Source: projectmanagementdocs.com

Also see more sample project plans:

Project Plans - Sample Plans

The Cost Management Plan clearly describes specifically the methodology for monitoring and control of project costs during the project lifecycle. It includes the system and baseline for measurement of the project costs, their reporting, and controlling mechanism. It also includes the following:

Identification of the authority for cost management
Nomination of the authority for approval of changes in costs
Procedure for quantitative measurement of cost performance, and its reporting
Formats for reports, their frequency, and to whom delivered

The Project Manager has been assigned the responsibility for the management and control of the project cost during the project life cycle. During the project fortnightly status meeting, the Project Manager will explain the project cost performance, with measures adopted for its control. Earned value management will be used for measuring cost performance. The Project Manager is accountable for all cost variance, and recommending alternatives for completing the project back on planned budget. The Project Sponsor will use discretionary measures for authorizing cost changes to exceed budget, if necessary.

Approach to be maintained for the management of cost is documented in this part of the Cost Management Plan. Cost Accounts will be created at the third level of the Work Breakdown Structure. If a suitable Project Management Information System is being used, then it is recommended that the costs should be managed till the level of work package. If a detailed Project Management Information System is not available, then the level of cost control in the Work Breakdown Structure should be such till the cost can be efficiently reported and managed. The lower the cost is managed in the Work Breakdown Structure, the greater will be the effort required. Thus, the level should be balanced with the effort that can be utilized for this purpose.

Project costs will be controlled at the third level of the WBS, by creation of Control Accounts at this level for the cost tracking. Project financial cost performance will be measured and controlled by using the methodology of Earned Value Management, to be applied for the Control Accounts. Although cost estimates of the activities will be detailed in work packages of the Work Breakdown Structure, the accuracy level will be determined at the third level of the WBS. Work will be monitored at the level of Work Package. 50% credit to work will be granted on its initiation, while remaining 50% will be assigned on its completion. Work hours will be determined to the level of hours, while the level of accuracy for the costs will be nearest dollar.

Variance of +/- 0.2 in the Schedule Performance Index ( SPI ) and Cost Performance Index ( CPI ) will indicate a caution to the Project Manager, and will be reflected in the status reports of the project. If these variances exceed +/- 0.3, an alert stage will be created, where appropriate remedial measures will be necessary by the Project Manager, to ensure reduction of the variances below the alert level. Corrective actions to be undertaken will be recommended to the Project Sponsor, by the initiation of a Change Request.

This part of the Cost Management Plan describes the procedure for measuring the project cost. Earned Value Management is a useful tool that is used globally for the measurement and control of the costs in a project. It is recommended that Project Managers should be conversant in this methodology by undertaking formal training in this discipline.

Detailed procedure should be mentioned in this section, including the measurements that will be captured and analyzed. If any software is to be used, like Primavera P6, then it should be mentioned, including its installing and training to the users of this application. This section will also describe if the cost performance will be reviewed with reference to work packages, time, or schedule of activities. In this section of the Cost Management Plan, four measurements have been specified, namely Cost Variance (CV), Cost Performance Index ( CPI ), Schedule Variance (SV), and Schedule Performance Index ( SPI ). These measurements will provide adequate status of the project cost performance for efficient control and management.

Cost Variance (CV) : It is a measurement that determines the project budget performance, and can be measured at any stage of the project. CV is the difference of Earned Value (EV) and the Actual Costs (AC). EV represents the budgeted cost of an activity, and is the real value achieved for the project. AC is the amount actually spent for the completion of that activity. CV will indicate if the cost performance is below, equal, or above the planned budget at any stage of the project.

If value of CV is zero, then it implies that the project coast performance is the same as was planned, and project is on budget. If value of CV is greater than zero, then it is a good indicator, representing that more is being earned by the project than was planned, and the project is under budget. If CV is less than zero, then cost performance is not good, and needs to be analyzed for remedial action. The project in this situation is earning less than what was planned, and the project is over budget.

Cost Performance Index ( CPI ) : It measures the value of the completed work, comparing the actual cost incurred for the completion of that work. CPI is determined by dividing EV by AC, EV/AC. If the value of CPI is 1, then the project is precisely on budget. If the value of CPI is greater than 1, then it is a good indicator for the project cost performance, and the project is under budget. If CV is less than 1, then the project is being completed over budget, and corrective actions are necessary.

Schedule Variance (SV) : It is a measurement that indicates the project schedule performance. It is calculated by subtracting the Planned Value (PV) from the Earned Value (EV), and formula is SV = EV – PV. Since EV is the real value earned at any stage of the project, and PV is the value that was planned at that stage, then SV will indicate the variance, whether the project is behind or ahead of the schedule baseline, or on schedule. If SV is greater than zero, then the project performance is good, and it is earning more value than that was planned, and project is ahead of schedule. If value of SV is less than zero, then the project schedule performance is not satisfactory, and needs to be analyzed for necessary remedial actions.

Schedule Performance Index ( SPI ) : It signifies the project progress attained till any stage, against the value that was planned. SPI is the ratio of EV and PV, and calculated as EV/PV. If EV is same as PV, then SPI will be 1, implying that the project schedule status is exactly the same as that was planned. If the value of SPI is greater than 1, then the project schedule performance is good, and the project is ahead of schedule. A good planned and controlled project should have the value of SPI close to 1, and value less than 1 indicates that the schedule performance needs to be reviewed.

Project performance will be measured by the use of Earned Value Management. Following metrics concerning Earned Value Management will be utilized for the measurement of project cost performance:

Cost Variance (CV)
Cost Performance Index ( CPI )
Schedule Variance (SV)
Schedule Performance Index ( SPI )

If the variance of Cost Performance Index ( CPI ) or Schedule Performance Index ( SPI ) is between 0.2 and 0.3 the Project Manager will report the reasons for this status, including recommendations for improvement.

Performance Measurement

Yellow

Red

Cost Performance Index ( CPI )

Between 0.8 and 0.9 or Between 1.2 and 1.3

Less than 0.8 or Greater than 1.3

Schedule Performance Index (SPI)

Between 0.8 and 0.9 or Between 1.2 and 1.3

Less than 0.8 or Greater than 1.3

Reports regarding the project cost performance will be included in the project monthly status reports. The Project Monthly Status Report will comprise a part called “Cost Performance Management”. This portion will include the Earned Value Metrics, which were established in the previous part. All cost variances, which exceed the limits defined, will be communicated to all concerned, including any remedial actions planned. Change Requests which are necessitated due to project cost overruns, will be tracked in this report.

This section of the Cost Management Plan defines the control thresholds for the project and what actions will be taken if the project triggers a control threshold. As a part of the response process the Project Manager typically presents options for corrective action to the Project Sponsor who will then approve an appropriate action in order to bring the project back on budget. The Project Manager may propose to increase the budget for the project, reduce scope or quality, or some other corrective action.

The thresholds for the financial control of this project are a SPI less than 0.8, and CPI of less than 0.9. If the project attains any one of the threshold, a corrective action will be necessary. Project Manager will analyze and recommend options to the Project Sponsor for remedial actions, within four business days of the occurrence of the variance. After approval by the Sponsor, the Project Manager will implement the desired course of action within three business days.

The budget assigned for this project is mentioned below.

Fixed Costs: $xxx,xxx.xx
Contractor Costs: $xxx,xxx.xx
Material Costs: $xxx,xxx.xx
Contingency Reserve: $xxx,xxx.xx
Total Project Cost: $xxx,xxx.xx
Management Reserve: $x,xxx.xx

You can download free cost management plan template here

Project Plans - Sample Plans

The executive summary should be a high-level summary of what issues or problems the project was created to correct. Typically, the executive summary also provides the background information and general statements regarding the project's purpose or justification which will be covered in more detail in the appropriate section(s) of the charter.

For the past several years our company intranet has been subject to numerous external breaches because of poor information technology (IT) security measures. These incidents have resulted in approximately $10 million in damages to the company. The Intranet Security Assurance ( ISA ) project has been created to address and correct these security issues and prevent further loss due to external IT security breaches. The project will integrate improved technology solutions with our current platform in order to establish a more robust security infrastructure.

This section of the project charter describes the purpose and justification of the project in the form of business case and objectives. The business case should provide the reasoning behind the need for this project as it relates to a function of the business.

Business Need/Case

Discuss the logic for the Business Need/Case (market demand, organizational need, customer request, technological advance, legal requirement, ecological impacts, social need, etc). This section should also include the intended effects of the business case (i.e. cost savings, process improvement, new product development, etc).

The ISA project has been created to increase organizational IT security in order to prevent further financial damages resulting from external security breaches. The costs associated with the successful design and implementation of these security measures will be recovered as a result of the anticipated reduction in financial damages.

Business Objectives

Here the project charter should list the Business Objectives for the project which should support the organizational strategic plan.

The business objectives for this project are in direct support of our corporate strategic plan to improve IT security and reduce costs associated with loss and waste.

Design and test a new IT security infrastructure within the next 90 days
Complete implementation the new IT infrastructure within the next 120 days
Reduce the amount of damages by 50% in the first year

This section of the project charter provides a high-level description of the project. This description should not contain too much detail but should provide general information about what the project is, how it will be done, and what it is intended to accomplish. As the project moves forward the details will be developed, but for the project charter, high-level information is what should be provided.

The ISA project will provide increased security to the company's IT infrastructure and, more specifically, to the company intranet. The ISA project will utilize improved technology in the form of security hardware and software in order to prevent external breaches of the company intranet. All hardware and software will be integrated into the company's current IT platforms in order to establish increased security while allowing all systems and processes to continue without interruption.

Project Objectives and Success Criteria

Objectives should be SMART: Specific, Measurable, Attainable, Realistic, and Time-bound. The project manager must be able to track these objectives in order to determine if the project is on the path to success. Vague, confusing, and unrealistic objectives make it difficult to measure progress and success.

The objectives which mutually support the milestones and deliverables for this project have been identified. In order to achieve success on the ISA project, the following objectives must be met within the designated time and budget allocations:

Develop security solution methodology to present to the VP of Technology within the next 20 days
Complete list of required hardware/software which meets budget allocation within the next 25 days
Create a simulated solution in the IT lab using all purchased hardware and software to test the solution within the next 60 days
Achieve a simulated solution which allows no security breaches and complete testing within the next 90 days
Implement the solution across the organization within the next 120 days

Requirements

The project team should develop a list of all high-level project requirements. These requirements are clear guidelines within which the project must conform and may be a result of input from the project sponsor, customer, stakeholders, or the project team.

This project must meet the following list of requirements in order to achieve success.

The solution must be tested in the IT lab prior to deployment
Solution must be implemented without disruption to operations

Additional requirements may be added as necessary, with project sponsor approval, as the project moves forward.

Constraints

Constraints are restrictions or limitations that the project manager must deal with pertaining to people, money, time, or equipment. It is the project manager's role to balance these constraints with available resources in order to ensure project success.

The following constraints pertain to the ISA project:

All security hardware and software must be compatible with our current IT platforms
All hardware and software must be purchased in accordance with the allocated budget and timeline
Two IT specialists and one security specialist will be provided as resources for this project

Assumptions

The project team must identify the assumptions they will be working under as the project goes forward and document them in the project charter. These assumptions are what the project manager/team expect to have or be made available without anyone specifically stating so.

The following are a list of assumptions. Upon agreement and signature of this document, all parties acknowledge that these assumptions are true and correct:

This project has the full support of the project sponsor, stakeholders, and all departments
The purpose of this project will be communicated throughout the company prior to deployment
The IT manager will provide additional resources if necessary

Risks

All projects have some form of risk attached. This section of the project charter should provide a list of high-level risks that the project team has determined apply to this project.

The following risks for the ISA project have been identified. The project manager will determine and employ the necessary risk mitigation/avoidance strategies as appropriate to minimize the likelihood of these risks:

Potential disruption to operations during solution deployment
External threats breaching intranet security via new methods

This section should list all of the deliverables that the customer, project sponsor, or stakeholders require upon the successful completion of the project. Every effort must be made to ensure this list includes all deliverables and project sponsor approval must be required for adding additional deliverables in order to avoid scope creep.

The following deliverables must be met upon the successful completion of the ISA project. Any changes to these deliverables must be approved by the project sponsor.

Fully deployed intranet security solution
Technical documentation for intranet security solution
Recommendation list for future security considerations

This section of the project charter provides an estimated schedule of all high-level project milestones. It is understood that this is an estimate and will surely change as the project moves forward and the tasks and milestones and their associated requirements are more clearly defined.

The project Summary Milestone Schedule is presented below. As requirements are more clearly defined this schedule may be modified. Any changes will be communicated through project status meetings by the project manager.

Summary Milestone Schedule
Project Milestone	Target Date (mm/dd/yyyy)
Project Start	01/01/20 xx
Complete Solution Design	01/21/20 xx
Acquire Hardware and Software	01/26/20 xx
Complete Solution Simulation with New Hardware/Software	03/01/20 xx
Complete Solution Simulation and Testing	04/01/20 xx
Deploy Solution	05/01/20 xx
Project Complete	05/15/20 xx

The summary budget should contain general cost components and their planned costs. As the project moves forward these costs may change as all tasks and requirements become clearer. Any changes must be communicated by the project manager.

The following table contains a summary budget based on the planned cost components and estimated costs required for successful completion of the project.

Summary Budget – List component project costs
Project Component	Component Cost
Personnel Resources	$110,000
Hardware	$45,000
Software and Licensing	$75,000
IT Lab Preparation	$15,000
Total	$245,000

The organization must understand when the project has reached a successful completion. These criteria must be clear and should be accepted by whoever will sign-off on the project's closeout. Once the project charter is signed-off by the authorized person, the project is deemed approved and is successful as long as it has met all of the agreed upon requirements.

Success for the ISA project will be achieved when a fully tested intranet security solution, and all technical documentation, is fully deployed throughout the company within the time and cost constraints indicated in this charter. Additionally, this measure of success must include a recommendation list for future security considerations as we fully anticipate the necessity of this solution to evolve in order to prevent future threats. Success will be determined by the Project Sponsor, Mr. Jim Thomas, who will also authorize completion of the project.

This section of the project charter explicitly states who is assigned as the PM, their responsibility, and authority level. Depending on the organization and scope of the project, the project manager may have varying levels of responsibility and authority for personnel, project expenditures, and scheduling.

John Doe is named Project Manager for the duration of the ISA Project. Mr. Doe's responsibility is to manage all project tasks, scheduling, and communication regarding the ISA project. His team, consisting of two IT specialists and one security specialist will be matrix support from the IT department. Mr. Doe will coordinate all resource requirements through the IT department manager, Jane Snow. Mr. Doe is authorized to approve all budget expenditures up to, and including, the allocated budget amounts. Any additional funding must be requested through the Project Sponsor, Jim Thomas. Mr. Doe will provide weekly updates to the Project Sponsor.

Approved by the Project Sponsor:

__________________________________________ Date:____________________
<Project Sponsor Name>
<Project Sponsor Title>

Source: http://www.projectmanagementdocs.com/

Project Plans - Sample Plans

Scope Management involves the management of techniques that make sure that the project comprises all the tasks necessary to achieve the objectives, and exclusive of all the effort which is not essential. It includes the definition, development, and verification of work, including the assignment of responsibilities for these tasks.

Processes included in Scope Management are:

Collect Requirements – In this process, project requirements are collected from the stakeholders, so that the project scope can be precisely defined. Project charter is the basic document used during this process, and stakeholder register assists to identify the stakeholders from whom the requirements are to be collected. Requirements are collected by conduct of interviews, workshops, seminars, etc. In formation collected during this process is the major input for defining the project scope.
Define Scope – this process is crucial for the success of project since it involves the formulation of a comprehensive elucidation of the project and product, and comprises description of deliverables, assumptions, exclusions, constraints, and acceptance criteria. It includes background within which project tasks should be executed.
Create WBS – during this process, deliverables are sub-divided into small and manageable work, and tasks at the lowest level are known as work packages. This hierarchy of work permits for ease in costing, scheduling, monitoring, and controlling the project.
Verify Scope – project deliverables are reviewed with the client during this process, and either the deliverables are accepted, if according to scope, or referred to execution, for removal of deficiencies.
Control Scope – during this process, project is monitored and controlled to ensure that the scope is in accordance with the scope that was defined during the process of Define Scope. Changes occurring in the scope baseline are managed, to avoid scope creep.

The Scope Management Plan presents structure for the project scope. This plan includes the approach for management of scope, roles and responsibilities for this discipline, definition of scope, verification and control actions, and creation of work breakdown structure. All communication regarding the project scope will remain within this Scope Management Plan.

The objectives of this project are design, program, and analysis of a new software, which will be applied to track the finances of the company, and enhance the financial procedures. This consists of software design, programming, coding, and validation. Outsourcing is not expected.

It is essential that the project scope is managed efficiently by precise scope definition, with a detailed documentation. This part of the Scope Management Plan includes a synopsis, which focuses on the following:

Who is responsible for scope management
How project scope will be defined, including the creation of Project Scope Statement, Statement of Work, WBS, WBS Dictionary, etc.
How the project scope will be evaluated and confirmed, including the creation of Quality Checklists, Work Performance Information, Scope Baseline, etc
The process involved for changes to scope
Who is authorized for the acceptance of deliverables, and acceptance of project scope

Project Manager will be entirely responsible for the project scope management. The project scope will defined by the Project Scope Statement, Work Breakdown Structure, and WBS Dictionary. Sponsor, Project Manager, and stakeholders will formulate the documents for measuring project scope, including quality checklists, and measurements to identify the work performance. Changes in scope may be recommended by Project Manager, project stakeholders, or members project team. Change requests will be forwarded to the Project Manager, who will analyze change in scope, and its impacts on cost, schedule, quality, and other aspects. Project Manager will forward the change request to the Change Control Board for decision. After approval by the Change Control Board, the project documents will be updated by the Project Sponsor, and changes in scope will be communicated to the stakeholders.

To ensure efficient management of project scope, it is crucial that roles and responsibilities for the management of scope are defined explicitly in the Scope Management Plan. This portion identifies the role of Project Manager, Project Management Team, and Stakeholders, who are responsible for the project scope management. It should mention who is accountable for scope management, and responsibility for the acceptance of project deliverables.

Project Manager, Sponsor and project management team will have key roles for the management of project scope. Therefore, all these persons should be conscious of their responsibilities to ensure that all project work is in accordance with the scope defined. The table below describes the roles and responsibilities for project scope management:

Name	Role	Responsibilities
Matthew	Sponsor	Review the change requests regarding scope Endorse or reject the change request Acceptance of deliverables
Jacob	Project Manager	Evaluate and validate project scope Assist in the management of scope change requests Analyze the impact of scope change requests Conduct meetings for evaluation of the change requests Communicate decision of scope change requests Update the project documents
Daniel	Team Lead	Measure and verify project scope Validate scope change requests Evaluate impact of scope change requests Communicate results of scope change requests to the team Facilitate the process of change review
Joseph	Team Member	Contribute in describing changes Assess the requirement for scope changes and convey to the project manager
Ethan	Team Member	Contribute in describing changes Assess the requirement for scope changes and convey to the project manager

Table 2.1, Roles and Responsibilities Regarding Scope Management

This part involves the development of comprehensive project goals, and the project deliverables. Scope can only be defined after the project requirements have been precisely appreciated during the previous process of Collect Requirements. During this process, documents which are created are Requirements Documentation, Requirements Management Plan, and Requirements Traceability Matrix. The Scope Management Plan will describe the procedure to be implemented to create the comprehensive project description and the deliverables. The documents to be used for this purpose are the Project Charter, Requirements Documentation, and other project documents. Tools and techniques to be for defining the project scope are product analysis, identification of alternatives, and conduct of workshops.

The project scope was defined by means of a methodical process of collection of project and product requirements from the stakeholders. Initially, an analysis was conducted regarding the existing software applications of the company, based on client and team feedback. Subsequently, the project requirements were documented, and the requirements management plan, and requirements traceability matrix were developed to trace the requirements to the original.

Project description was completed and the deliverables were identified, based on the user requirements and contribution by the subject matter experts in the disciplines of software design, programming, and testing. Expert judgment was extremely useful in providing valuable information, to accomplish the user requirements of delivering software, which will enhance financial tracking and performance of other financial processes.

The project scope statement explains the project deliverables, and the necessary work involved for their creation. The Project Scope Statement includes the following elements:

Product Scope Description – explains what the project should achieve
Acceptance Criteria – illustrates what objectives should be accomplished for the acceptance of the project
Deliverables – comprehensive detail of project deliverables
Exclusions – details of tasks that are not included, and not within the project scope
Constraints – restrictions on resources, like money, time, manpower, or machinery
Assumptions – assumptions under which the project will be completed

The project scope statement includes a project description, acceptance criteria, list of deliverables, exclusions, constraints, and assumptions. It also includes work that is not to be executed, and not within the project scope.

This project comprises designing, programming, and testing of a software application that will be used for tracking the company finances. The project deliverables are complete software for financial tracking, with flexibility for modification and expansion, as required. The project acceptance will occur after the successful software testing in all sections, and is confirmed to be compatible with the existing information technology of the company. Ongoing operations and software maintenance is not included in this project. Only company staff and resources can be utilized for this project. Furthermore, the project duration will not exceed 120 days, and budget will be maximum $600,000. It is assumed that the project sponsor will provide all necessary support, and the branch supervisors, with internal resources, will be available for the project.

Work Breakdown Structure and Work Breakdown Structure Dictionary are significant components for efficient scope management. This part of the Scope Management Plan explains how the scope of the project will be decomposed into smaller components in the WBS, and how these small elements will be monitored and controlled during the project life cycle.

To ensure efficient management of the project work, it will be sub-divided into discrete work packages that should not be in excess of 40 hours work. This will permit effective scope management during the project execution. The first level of project decomposition consists of Design, Programming, and Testing. The first level components are further subdivided into work packages, duration of which will not need 40 hours, and not less than 4 hours (refer WBS below).

Figure 1.1, Work Breakdown Structure

To ensure clear definition of project work, WBS Dictionary is created, which incorporates detail of all WBS elements, including a comprehensive description of work, deliverables, budget, and resources required.

WBS Dictionary

Table 1.2, WBS Dictionary

This section includes the procedure for verification of deliverables, with reference to the scope defined, and the guidelines for project acceptance. The project deliverables should be accepted by the client by scope verification either throughout the project life cycle, or by inspection at the end.

As the project is executed, deliverables will be verified by the Project Manager, keeping in view the scope baseline and the project scope statement that was defined during the project planning. After verification by the Project Manager, review will be carried out with the project sponsor for formal acceptance of the project. The deliverables will be accepted by the sponsor by signing the acceptance certificate. This document will ensure that the sponsor has accepted the project after verification of the project scope, which was agreed during the project planning, and documented in the project scope statement.

Control scope is the process during which project scope is monitored and controlled during project life cycle. This part of the Scope Management Plan also includes procedure for incorporating changes in the scope baseline.

Project Manager and the project management team will be responsible for the scope control. The project management team will use the WBS Dictionary for obtaining details of the work to be completed. The project management team will ensure that only that works are performed, which is defined in the WBS, and no other work is executed since it will be out of scope. If any change is required in the project scope, impact of changes on cost, schedule, and other features will be analyzed by the Project Manager, and then forward the change to the Change Control Board for decision. Change can be recommended by any member of the project management team. All change requests will be forwarded to the Project Manager, using proper Change Request Form, duly filled with all details.

Project Plans - Sample Plans

As organizations begin new projects they begin operating in an area of uncertainty that comes along with developing new and unique products or services. By doing so, these organizations take chances which results in risk playing a significant part in any project. The purpose of the risk management plan is to establish framework in which the project team will identify risks and develop strategies to mitigate or avoid those risks. However, before risks can be identified and managed, there are preliminary project elements which must be completed. These elements are outlined in risk management approach.

This project is considered a medium risk project as it has an overall risk score of 24 on a scale from 0 to 100. The project risk score is the average of the risk scores of the most significant risks to this project. A risk score below 16 is low risk project, a score between 16 and 45 is a medium risk project and a score above 45 is a high risk project.

Before risk management begins it is imperative that a foundation is established for providing structured project information, thus, the following project elements were completed and defined prior to developing this Risk Management Plan:

Define work scope, schedule, resources, and cost elements

Develop project WBS/WBS dictionary
Develop master schedule and detailed schedules
Estimate project cost and finalize budget
Identify required and available resources
Establish performance measurement metrics

Define minimum and maximum baseline thresholds

Schedule
Resources
Cost

Baseline reporting requirements

Format
Frequency of distribution
Distribution list

Define Risk Management Roles and Responsibilities

Project Manager chairs the risk assessment meetings
Project team participates in risk assessment meetings and members serve as meeting recorder and timekeeper
Key stakeholders participate in risk assessment meetings
Project Sponsor may participate in risk assessment meetings

It is important to explicitly state the top three risks to the project in the Risk Management Plan. This will make management aware of the top risks for the project and the nature of the risks.

The top three high probability and high impact risks to this project are:

Delay in Server Equipment
Due to a manufacturer's production backlog, the servers are not available for large scale application testing causing a delay in the project schedule. The project manager will mitigate this risk by using servers from the backup data center if needed.

Fiber Optics Connection Not Completed
Due to construction delays in installing the fiber optic cable between the data center and the headquarters facilities users will not have a high speed connection between their site and the datacenter resulting in slow responses from the application making it unusable. The Project Manager will implement a site to site broadband Ethernet radio network between the data center and headquarters facility.

Network Operations Center ( NOC ) Not Appropriately Staffed
Due to lead times associated with hiring and training additional staff, the NOC does not have the necessary staff to monitor the additional bandwidth associated with the project resulting in a delay to the project schedule. The project manager will mitigate this risk by working with the NOC to create an alternate work schedule to compensate for the staffing shortage until additional staff hiring and training is complete.

This section of the Risk Management Plan provides a general description for the approach taken to identify and manage the risks associated with the project. It should be a short paragraph or two summarizing the approach to risk management on this project.

The approach we have taken to manage risks for this project included a methodical process by which the project team identified, scored, and ranked the various risks. The most likely and highest impact risks were added to the project schedule to ensure that the assigned risk managers take the necessary steps to implement the mitigation response at the appropriate time during the schedule. Risk managers will provide status updates on their assigned risks in the bi-weekly project team meetings, but only when the meetings include their risk's planned timeframe. Upon the completion of the project, during the closing process, the project manager will analyze each risk as well as the risk management process. Based on this analysis, the project manager will identify any improvements that can be made to the risk management process for future projects. These improvements will be captured as part of the lessons learned knowledge base.

Here the Risk Management Plan explains the process by which the risks associated with this project were identified. It should describe the method(s) for how the project team identified risks, the format in which risks are recorded, and the forum in which this process was conducted. Typical methods of identifying risks are expert interview, review historical information from similar projects and conducting a risk assessment meeting with the project team and key stakeholders.

For this project, risk identification was conducted in the initial project risk assessment meeting. The method used by the project team to identify risks was the Crawford Slip method. The project manager chaired the risk assessment meeting and distributed notepads to each member of the team and allowed 10 minutes for all team members to record as many risks as possible.

Expert Interview
Two Expert Interviews were held for this project. The interviews revealed several risks which were then mitigated by making changes to the project plan. The remaining risks are included in the Risk Register.

Risk Assessment Meeting
A risk assessment meeting was held with key team members and stakeholders. The risks identified during this meeting were added to the project plan and Risk Register.

Historical Review of Similar Projects
The project team reviewed the history of similar projects in order to determine the most common risks and the strategies used to mitigate those risks.

Once risks are identified it is important to determine the probability and impact of each risk in order to allow the project manager to prioritize the risk avoidance and mitigation strategy. Risks which are more likely to occur and have a significant impact on the project will be the highest priority risks while those which are more unlikely or have a low impact will be a much lower priority. This is usually done with a probability – impact matrix. This section explains risks were qualified and prioritized for this project. For more information on how to qualify and prioritize risks refer to our Risk Assessment Meeting Guide.

In order to determine the severity of the risks identified by the team, a probability and impact factor was assigned to each risk. This process allowed the project manager to prioritize risks based upon the effect they may have on the project. The project manager utilized a probability-impact matrix to facilitate the team in moving each risk to the appropriate place on the chart.

Once the risks were assigned a probability and impact and placed in the appropriate position on the chart, the recorder captured the finished product and the project manager moved the process on to the next step: risk mitigation/avoidance planning.

This section of the Risk Management Plan should discuss how the risks in the project will be actively monitored. One effective way to monitor project risks is to add those risks with the highest scores to the project schedule with an assigned risk manager. This allows the project manager to see when these risks need to be monitored more closely and when to expect the risk manager to provide status updates at the bi-weekly project team meetings. The key to risk monitoring is to ensure that it is continuous throughout the life of the project and includes the identification of trigger conditions for each risk and thorough documentation of the process.

The most likely and greatest impact risks have been added to the project plan to ensure that they are monitored during the time the project is exposed to each risk. At the appropriate time in the project schedule a Risk Manager is assigned to each risk. During the bi-weekly project team meeting the Risk Manager for each risk will discuss the status of that risk; however, only risks which fall in the current time period will be discussed. Risk monitoring will be a continuous process throughout the life of this project. As risks approach on the project schedule the project manager will ensure that the appropriate risk manager provides the necessary status updates which include the risk status, identification of trigger conditions, and the documentation of the results of the risk response.

Once risks have been qualified, the team must determine how to address those risks which have the greatest potential probability and impact on the project. This section of the Risk Management Plan explains the considerations which must be made and the options available to the project manager in managing these risks.

The project manager has led the project team in developing responses to each identified risk. As more risks are identified, they will be qualified and the team will develop avoidance and mitigation strategies. These risks will also be added to the Risk Register and the Project Plan to ensure they are monitored at the appropriate times and are responded to accordingly. If necessary, the Risk Management Plan will be updated.

The risks for this project will be managed and controlled within the constraints of time, scope, and cost. All identified risks will be evaluated in order to determine how they affect this triple constraint. Project manager, with the assistance of project team, will determine best way to respond to each risk to ensure compliance with these constraints.

In extreme cases it may be necessary to allow flexibility to one of the project's constraints. Only one of the constraints for this project allows for flexibility as a last resort. If necessary, funding may be added to the project to allow for more resources in order to meet the time (schedule) and scope constraints. Time and scope are firm constraints and allow for no flexibility. Again, the cost constraint is flexible only in extreme cases where no other risk avoidance or mitigation strategy will work.

Risk Register Every project must maintain a risk register in order to track risks and associated mitigation strategies. This section describes the risk register criteria as well as where the risk register is maintained and how these risks are tracked in the project schedule.

The Risk Register for this project is a log of all identified risks, their probability and impact to the project, the category they belong to, mitigation strategy, and when the risk will occur. The register was created through the initial project risk management meeting led by the project manager. During this meeting, the project team identified and categorized each risk. Additionally, the team assigned each risk a score based on the probability of it occurring and the impact it could potentially have. Risk Register also contains the mitigation strategy for each risk as well as when the risk is likely to occur.

Based on the identified risks and timeframes in the risk register, each risk has been added to the project plan. At the appropriate time in the plan—prior to when the risk is most likely to occur—the project manager will assign a risk manager to ensure adherence to the agreed upon mitigation strategy. The each risk manager will provide the status of their assigned risk at the bi-weekly project team meeting for their risk's planned timeframe. Risk Register will be maintained as an appendix to this Risk Management Plan.

Source: projectmanagementdocs.com

Project Plans - Sample Plans

This section of the Human Resource Plan explains the purpose and importance of having a human resources management plan. It should provide a general description of what the plan includes and explain how the project manager and project team can use the plan to help them manage the project effectively.

Human resources management is an important part of the Software Upgrade Project. The human resources management plan is a tool which will aid in the management of this project's human resource activities throughout the project until closure. The human resources management plan includes:

Roles and Responsibilities of Team Members Throughout the Project
Project Organization Charts
Staffing Management Plan to Include:

How resources will be acquired
Timeline for resources/skill sets
Training required to develop skills
How performance reviews will be conducted
Recognition and rewards system

The purpose of the human resources management plan is to achieve project success by ensuring the appropriate human resources are acquired with the necessary skills, resources are trained if any gaps in skills are identified, team building strategies are clearly defines, and team activities are effectively managed.

Roles and responsibilities of team members and stakeholders must be clearly defined in any project. Depending on the organizational structure, project team members may represent many different groups/departments and act in the interest of different functional managers. Additionally, team members may have varying degrees of authority and responsibility. When listing roles and responsibilities the following should be included:

Role – description of the portion of the project for which the member is accountable
Authority – the level at which the member may make decisions, apply project resources, or make approvals
Responsibility – the work a team member must perform to complete assigned work activities
Competency – the skill(s) required to complete assigned project activities

The roles and responsibilities for the Software Upgrade Project are essential to project success. All team members must clearly understand their roles and responsibilities in order to successfully perform their portion of the project. For the Software Upgrade Project the following project team roles and responsibilities have been established:

Project Manager (PM), (1 position): responsible for the overall success of the Software Upgrade Project. The PM must authorize and approve all project expenditures. The PM is also responsible for approving that work activities meet established acceptability criteria and fall within acceptable variances. The PM will be responsible for reporting project status in accordance with the communications management plan. The PM will evaluate the performance of all project team members and communicate their performance to functional managers. The PM is also responsible for acquiring human resources for the project through coordination with functional managers. The PM must possess the following skills: leadership/management, budgeting, scheduling, and effective communication.

Design Engineer (DE), (2 positions): responsible for gathering coding requirements for the Software Upgrade Project. The DEs are responsible for all upgrade design, coding, and testing of the upgraded software. The DEs will assist the implementation lead in the distribution and monitoring of the software upgrades throughout the network infrastructure. The DEs will be responsible for timely status reporting to the PM as required by the communications management plan. The DEs may not authorize any project expenditures nor allocate any resources without PM approval. DE's performance will be managed by the PM and communicated to the Design Technology Group Manager (DE's Functional Manager). DEs must be proficient in programming html, C++, and Java programming languages.

Implementation Manager (IM,) (1 position): The IM is responsible for the distribution, implementation, and monitoring of the new software upgrade. The IM is responsible for working with the DEs to ensure all coding on new software conforms with organizational security regulations. The IM is responsible for coordination outage windows with each department to facilitate the rollout of the software upgrades with minimal/no disturbance to operations. The IM will report status to the PM in accordance with the project's communications management plan. The IM's performance will be evaluated by the PM and communicated to the IM's functional manager (Network Manager). The IM must be proficient in managing network architecture.

Training Lead (TL), (1 position): The TL is responsible for training all network users on the features provided by the upgrades to the existing software. The TL will coordinate training times/locations with each department's training advocate. The TL will provide training status to the PM in accordance with the project communications management plan.

Functional Managers (FM), (2 positions): While not part of the project team, functional managers are responsible for providing resources for the project in accordance with the project staffing plan. Functional managers are responsible for working with the PM to determine skill sets required and approving resource assignments. Functional managers are also responsible for conducting performance appraisals of assigned resources based, in part, on the PM's feedback regarding project performance.

In this section the Human Resource Plan provides a graphic display of the project tasks and team members. The purpose of this is to illustrate the responsibilities of team members as they relate to the project tasks. Tools such as responsible, accountable, consult, inform (RACI) or responsibility assignment matrix ( RAM ) may be used to aid in communicating roles and responsibilities for the project team. Additionally, organizational or resource breakdown structures may be used to show how responsibilities are assigned by department or by type of resource respectively. It should be noted that the level of detail may vary depending on project complexity.

The following RACI chart shows the relationship between project tasks and team members. Any proposed changes to project responsibilities must be reviewed and approved by the project manager. Changes will be proposed in accordance with the project's change control process. As changes are made all project documents will be updated and redistributed accordingly.

	Project Manager	Design Engineers	Implementation Manager	Training Leads	Functional Managers	Department Managers
Requirements Gathering	A	R	R	C	C	I
Coding Design	A	R	C		C	I
Coding Input	A	R
Software Testing	A	R	C		I	I
Network Preparation	A	C	R		I	I
Implementation	A	C	R	C	C	C
Conduct Training	A			R	C	C

Key:
R – Responsible for completing the work
A – Accountable for ensuring task completion/sign off
C – Consulted before any decisions are made
I – Informed of when an action/decision has been made

This part of the Human Resource Plan contains information on several areas including: when and how human resource requirements will be acquired, the timeline for when resources are needed and may be released, training for any resources with identified gaps in skills required, how performance reviews will be performed, and the rewards and recognition system to be used. It is important to note that depending on the scope of the project there may be other items included in staffing management (government and/or regulatory compliance, organizational health and safety, etc).

Staff Acquisition:

For the Software Upgrade Project the project staff will consist entirely of internal resources. There will be no outsourcing/contracting performed within the scope of this project. The Project Manager will negotiate with functional and department managers in order to identify and assign resources in accordance with the project organizational structure. All resources must be approved by the appropriate functional/department manager before the resource may begin any project work. The project team will not be co-located for this project and all resources will remain in their current workspace.

Resource Calendars:

The Software Upgrade Project will last for five weeks. All resources are required before the project can begin. The resource histogram below illustrates that design engineers are required to perform 40 hours per week per engineer for the first three weeks of the project. Their requirements are then scaled back to 5 hours per engineer in the fourth week. After the fourth week the design engineers will be released from the project. The implementation manager will also be released from the project after week 4. The training lead will be required to perform 15 hours of work in the first week and a full 40 hours of training during week 5.

Training:

There is currently no training scheduled with regards to the Software Upgrade Project since the organization has adequate staff with required skill sets. However, if training requirements are identified, funding will be provided from the project reserve.

Performance Reviews:

The project manager will review each team member's assigned work activities at the onset of the project and communicate all expectations of work to be performed. The project manager will then evaluate each team member throughout the project to evaluate their performance and how effectively they are completing their assigned work. Prior to releasing project resources, the project manager will meet with the appropriate functional manager and provide feedback on employee project performance. The functional managers will then perform a formal performance review on each team member.

Recognition and Rewards:

Although the scope of this project does not allow for ample time to provide cross-training or potential for monetary rewards there are several planned recognition and reward items for project team members.

Upon successful completion of the Software Upgrade Project, a party will be held to celebrate the success of each team member with the team members' families present.
Upon successful completion of the project, any team member who satisfactorily completed all assigned work packages on time will receive a certificate of thanks from the CEO.
Team members who successfully complete all of their assigned tasks will have their photo taken for inclusion in the company newsletter.
The company will provide free family movie tickets for the top two performers on each project.

Source: projectmanagementdocs.com

Project Plans - Sample Plans

{aridoc engine="google" width="650" height="550"}documents/Sample_Product_Scope_Description.ppt{/aridoc}

Project Plans - Sample Plans

The Requirements Management Plan is a necessary tool for establishing how requirements will be analyzed, prioritized and managed throughout the lifecycle of a project. Depending on the type of project there may be both project and product requirements. It is easy to unintentionally omit requirements, fail to document them, or leave requirements incomplete without a tool to properly manage them.

The purpose of the BrightStar Requirements Management Plan is to establish a common understanding of how requirements will be identified, analyzed, documented, and managed for the BrightStar fiber optic cable project.

Requirements will be divided into two categories: project requirements and product requirements. Project requirements are the requirements identified to meet the needs of the project and ensure its completion and readiness to hand over to operations. These consist mostly of non-technical requirements. Product requirements are the requirements identified to meet the technical specifications of the product being produced as a result of the project: the BrightStar fiber optic cable. These will consist of requirements to ensure that performance specifications are met, cable properties are properly documented, and manufacturing thresholds are identified and documented.

The inputs for the requirements management plan include the BrightStar Project Charter and Stakeholder Register.

The requirements management approach is the methodology the project team will use to identify, analyze, document, and manage the project's requirements. Many organizations use a standard approach for all projects, but based on the characteristics of each project, this approach may require some changes. The PMBOK defines this approach as "How requirements activities will be planned, tracked, and reported." Complete this section of the Requirements Management Plan with the approach you will take to managing requirements.

The approach we will use for requirements management for the BrightStar project will be broken down into four areas: requirements identification, requirements analysis, requirements documentation, and ongoing requirements management.

Requirements Identification: The BrightStar project team will facilitate various methods to collect requirements which may include: interviews, focus groups, facilitated workshops, group creativity techniques, questionnaires and surveys, or product prototypes. These will be conducted among the project stakeholders to ensure all requirements are captured.

Requirements Analysis: The BrightStar project team will analyze requirements to determine if they fall into project or product categories. Additionally, this analysis will determine where in the WBS the requirements will fall or what work activities correspond to particular requirements. Accountability and priority for each requirement will also be determined as part of the analysis. Finally, metrics and acceptance criteria must be determined for all requirements in order to provide a baseline for understanding when a requirement has been fulfilled to an acceptable level.

Requirements Documentation: Once requirements have been identified and analyzed, they will be documented and assigned to accountable personnel. These requirements will be added to the BrightStar project plan and the project team will determine what methodology the accountable personnel will use to track and report on the status of each requirement. All requirements will also be added to the project requirements checklist which must be completed before formal project closure is accepted by the project sponsor.

Ongoing Requirements Management: Throughout the project lifecycle, the project manager will ensure all team members are reporting requirement status and raising any issues or concerns with their assigned requirements as appropriate. As the project matures there may be situations in which requirements must change or be altered in some way. The project team must follow the established change control process in order to propose any changes to requirements and receive approval from the change control board. Ongoing requirements management also includes receiving approval of all requirements by all vested parties as part of project closure.

In order to effectively manage a project, communication must be managed and controlled. Additionally, every effort must be taken to identify requirements thoroughly during project initiation and planning. However, there are often situations which require changes to a project or its requirements. In these situations it is important to utilize configuration management to consider proposed changes, establish a process to review and approve any proposed changes, and to implement and communicate these changes to the stakeholders. As stated in the PMBOK: "Configuration management activities such as how changes to the product, service or result requirements will be initiated, how impacts will be analyzed, how they will be traced, tracked, and reported, as well as the authorization levels required to approve these changes." Use this section of the Requirements Management Plan template to outline your configuration management process.

For the BrightStar Project, the Requirements Management Plan will utilize the configuration management activities outlined in the Configuration Management Plan. Key items include documentation/version control and change control:

Documentation and Version Control: All project documentation will be loaded into the Configuration Management Database (CMDB) as the central repository for the BrightStar Project. Appropriate permissions will be granted to the project team for editing and revising documentation. Any proposed changes to project requirements must be reviewed by the Configuration Control Board (CCB) and have written approval by the project sponsor before any documentation changes are made. Once these proposed changes are approved and the documentation is edited, the project manager will be responsible for communicating the change to all project stakeholders.

Change Control: Any proposed changes in project requirements must be carefully considered before approval and implementation. Such changes are likely to impact project scope, time, and/or cost, perhaps significantly. Any proposed changes to project requirements will be reviewed by the CCB. The role of the CCB is to determine the impact of the proposed change on the project, seek clarification on proposed change, and ensure any approved changes are added to the CMDB. The project sponsor, who also sits on the CCB, is responsible for approving any changes in project scope, time, or cost and is an integral part of the change review and approval process.

Prioritizing requirements is an important part of requirements management. Developers or service providers do not always know what requirements are most important to a customer. Conversely, customers do not always understand the scope, time, and cost impacts of their requirements on a project. Collaboration among all stakeholders is a necessary part of establishing project requirement priorities. If cuts need to be made to scope, time, or cost, this list of priorities will provide a better understanding of where a project can or cannot focus to deal with the constraints placed upon it. One way to do this is to group requirements into priority categories such as high, medium, and low priority based upon the importance of the requirement. There may be hundreds of requirements in a large project so this type of categorically-based method would be helpful. NOTE: there are many methods by which priorities are determined and these should be explored based on the size and complexity of the project.

The BrightStar project manager will facilitate stakeholder meetings in order to establish priorities for all project requirements. This project will use a three-level scale in order to prioritize requirements. The chart below illustrates these levels and defines how requirements will be grouped:

Priority Level	Definition
High	These requirements are mission critical. They are required for project/product success or for progression to the next project phase.
Medium	These requirements support product/process operations but can be completed under the next product release.
Low	These requirements are quality and/or functional process enhancements and are disirable if time and resources permit.

Product metrics are an important part of determining a project's success. There must be some quantitative characteristics to measure against in order to gauge the progress and success of the project. Product metrics are usually technical in nature though not always. Such metrics may consist of performance, quality, or cost specifications. Metrics may also be based on the product requirements identified for a given project.

Product metrics for the BrightStar project will be based on cost, quality, and performance requirements as outlined in the project charter. In order to achieve project success, the BrightStar product must meet or exceed all established metrics.

Cost:

BrightStar cable product must cost less then $6,000 per linear kilometer for fiber counts of 12-72 fibers; less than $8,000 per linear kilometer for fiber counts of 84-180 fibers; less than $10,000 per linear kilometer for fiber counts of 192-288 fibers.

Quality:

BrightStar cable product must achieve less than 10% attenuation in temperature cycle testing
BrightStar cable product must achieve a minimum bending radius of less than 10 feet
BrightStar cable product must weigh less than 1.0 lb per linear foot for fiber counts of 12-180 fibers and less than 2.0 lbs for fiber counts greater than 180

Performance:

BrightStar cable must achieve an average attenuation of less than 0.1% per linear kilometer at 1550nm
BrightStar cable must achieve an average attenuation of less than 0.5% per linear kilometer at 1610nm
BrightStar cable must have a diameter of less than 1.0” for 12-72 fiber cables; less than 1.5” for 84-180 fiber cables; and less than 2.0” for 192-288 fiber cables

The Requirements Management Plan should include a requirements traceability matrix. The requirements traceability matrix is a tool to ensure that deliverables meet the requirements of the project. The matrix provides a thread from the established and agreed upon project requirements, through the project's various phases, and through to completion/implementation. This ensures that the product specifications and features satisfy the requirements on which they were based. Any interim project tasks associated with the requirements should be included. An example of this are test cases which will utilize metrics, based on the product requirements, which are linked to the project charter and design document. This allows a team member or stakeholder to follow a requirement through all tasks required for its completion.

Below is the requirements traceability matrix for the BrightStar project. The purpose of the requirements traceability matrix is to ensure all product requirements are completed in accordance with the project charter. This matrix provides a thread from all product requirements through design, testing, and user acceptance. Design document and charter references are contained in the BrightStar Project Configuration Management Plan. Any approved changes in project scope or requirements will result in changes to the traceability matrix below. Based on impacts of the approved changes, the Project Manager will make the necessary changes to the matrix and communicate those changes to all project stakeholders.

Project Name	Bright Star Fiber Optic Cable	Business Area	Research and Development
Project Manager	J. Doe	Business Analyst Lead	B. White
QA Lead	F. Black	Target Implementation Date	06/01/20 xx
Req. #	Requirement Description	Design Docu Reference	Charter Ref	Test Case Reference	User Acceptance Validation	Comments
1	Reduce cable building cost per linear foot by 15%	DD001	3.2.4	TS001
2	Improve attenuation in temperature testing by 10%	DD002	2.1.1	TS002
3	Improve fiber cable bending radius by 10%	DD003	1.4.3	TS003
4	Reduce fiber cable weight by 10%	DD004	2.5.4	TS004
5	Improve performance (attenuation) by 10%	DD005	1.6.5	TS005
6	Reduce cable diameter by 5%	DD006	1.3.2	TS006

Source: projectmanagementdocs.com

Project Plans - Sample Plans

This section highlights the purpose and importance of the schedule management plan. It provides a general description of what should be included in the schedule management plan. These items will be described in more detail later in the plan under each corresponding section.

The project schedule is the roadmap for how the project will be executed. Schedules are an important part of any project as they provide the project team, sponsor, and stakeholders a picture of the project's status at any given time. The purpose of the schedule management plan is to define the approach the project team will use in creating the project schedule. This plan also includes how the team will monitor the project schedule and manage changes after the baseline schedule has been approved. This includes identifying, analyzing, documenting, prioritizing, approving or rejecting, and publishing all schedule-related changes.

This section provides a general framework for the approach which will be taken to create the project schedule. This includes the scheduling tool/format, schedule milestones, and schedule development roles and responsibilities.

Project schedules will be created using MS Project 2007 starting with the deliverables identified in the project's Work Breakdown Structure (WBS). Activity definition will identify the specific work packages which must be performed to complete each deliverable. Activity sequencing will be used to determine the order of work packages and assign relationships between project activities. Activity duration estimating will be used to calculate the number of work periods required to complete work packages. Resource estimating will be used to assign resources to work packages in order to complete schedule development.

The following will be designates as milestones for the project schedule:

Completion of scope statement and WBS/WBS Dictionary
Baselined project schedule
Approval of final project budget
Project kick-off
Approval of roles and responsibilities
Requirements definition approval
Completion of data mapping/inventory
Project implementation
Acceptance of final deliverables

Roles and responsibilities for schedule development are as follows:

The project team is responsible for participating in work package definition, sequencing, and duration and resource estimating. The project team will also review and validate the proposed schedule and perform assigned activities once the schedule is approved.

The project sponsor will participate in reviews of the proposed schedule and approve the final schedule before it is baselined.

The project stakeholders will participate in reviews of the proposed schedule and assist in its validation.

This section defines how the project's schedule will be controlled throughout the life of the project. This includes the frequency of updates and schedule reviews as well as communicating the schedule and progress. This section also defines roles and responsibilities as they relate specifically to project schedule control.

The project schedule will be reviewed and updated as necessary on a bi-weekly basis with actual start, actual finish, and completion percentages which will be provided by task owners.

The project manager is responsible for holding bi-weekly schedule updates/reviews; determining impacts of schedule variances; submitting schedule change requests; and reporting schedule status in accordance with the project's communications plan.

The project team is responsible for participating in bi-weekly schedule updates/reviews; communicating any changes to actual start/finish dates to the project manager; and participating in schedule variance resolution activities as needed.

The project sponsor will maintain awareness of the project schedule status and review/approve any schedule change requests submitted by the project manager.

As the project schedule is created it is important that boundary conditions are set by the project sponsor to establish the schedule parameters within which the project is expected to operate. Any event which may potentially cause a schedule change which exceeds these boundary conditions must have a schedule change request submitted and approved by the sponsor before the schedule change is made. For the example in this schedule management plan template we will use a change threshold of 10%.

If any member of the project team determines that a change to the schedule is necessary, the project manager and team will meet to review and evaluate the change. The project manager and project team must determine which tasks will be impacted, variance as a result of the potential change, and any alternatives or variance resolution activities they may employ to see how they would affect the scope, schedule, and resources. If, after this evaluation is complete, the project manager determines that any change will exceed the established boundary conditions, then a schedule change request must be submitted.

Submittal of a schedule change request to the project sponsor for approval is required if either of the two following conditions is true:

The proposed change is estimated to reduce the duration of an individual work package by 10% or more, or increase the duration of an individual work package by 10% or more.
The change is estimated to reduce the duration of the overall baseline schedule by 10% or more, or increase the duration of the overall baseline schedule by 10% or more.

Any change requests that do not meet these thresholds may be submitted to the project manager for approval.

Once the change request has been reviewed and approved the project manager is responsible for adjusting the schedule and communicating all changes and impacts to the project team, project sponsor, and stakeholders. The project manager must also ensure that all change requests are archived in the project records repository.

Occasionally, approved changes to the project's scope may result in the schedule needing to be re-baselined. These scope changes may include new deliverables or requirements that were not previously considered as part of the original schedule's development. In these situations the project manager and team must consider the current status of the project schedule and how the scope change will affect the schedule and its resources as the project moves forward. How you handle scope change must be clearly documented in the Schedule Management Plan.

Any changes in the project scope, which have been approved by the project sponsor, will require the project team to evaluate the effect of the scope change on the current schedule. If the project manager determines that the scope change will significantly affect the current project schedule, he/she may request that the schedule be re-baselined in consideration of any changes which need to be made as part of the new project scope. The project sponsor must review and approve this request before the schedule can be re-baselined.

source: projectmanagementdocs.com

Project Plans - Sample Plans

The Quality Management Plan is an integral part of any project management plan. The purpose of the Quality Management Plan is to describe how quality will be managed throughout the life cycle of the project. It also includes the processes and procedures for ensuring quality planning, assurance, and control are all conducted. All stakeholders should be familiar with how quality will be planned, assured, and controlled.

The Quality Management Plan for the Loose Tube Fiber Cable (LTFC) project will establish the activities, processes, and procedures for ensuring a quality product upon the conclusion of the project. The purpose of this plan is to:

Ensure quality is planned
Define how quality will be managed
Define quality assurance activities
Define quality control activities
Define acceptable quality standards

This section of the Quality Management Plan describes the approach the organization will use for managing quality throughout the project's life cycle. Quality must always be planned into a project in order to prevent unnecessary rework, waste, cost, and time. Quality should also be considered from both a product and process perspective. The organization may already have a standardized approach to quality, however, whether it is standard or not, the approach must be defined and communicated to all project stakeholders.

The quality management approach for the LTFC project will ensure quality is planned for both the product and processes. In order to be successful, this project will meet its quality objectives by utilizing an integrated quality approach to define quality standards, measure quality and continuously improve quality.

Product quality for the LTFC project will be defined by the company's current standards and criteria for its fiber optic cable family. The focus is on the project's deliverable and the standards and criteria being used will ensure the product meets established quality standards and customer satisfaction.

Process quality for the LTFC project will focus on the processes by which the project deliverable will be manufactured. Establishing process quality standards will ensure that all activities conform to an organizational standard which results in the successful delivery of the product.

The project team will work with the Quality Group to define and document all organizational and project specific quality standards for both product and processes. All quality documentation will become part of the LTFC Project Plan and will be transitioned to operations upon the successful completion of the project.

Metrics will be established and used to measure quality throughout the project life cycle for the product and processes. The Quality Group Manager will be responsible for working with the project team to define these metrics, conduct measurements, and analyze results. These product and process measurements will be used as one criterion in determining the success of the project and must be reviewed by the project sponsor. Metrics will include:

Schedule
Resources
Cost
Process performance
- Manufacturing line utilization
- Material waste
Product performance
- Attenuation
- Tensile strength
Customer Satisfaction (as a result of field trials)

Quality improvements will be identified by any member of the project team or quality group. Each recommendation will be reviewed to determine the cost versus benefit of implementing the improvement and how the improvement will impact the product or processes. If an improvement is implemented the project manager will update all project documentation to include the improvement and the quality manager will update the organizational documentation the improvement affects.

This part of the Quality Management Plan should describe how the project team and/or quality group will identify and document the quality requirements and standards. Additionally, there should also be an explanation of how the project will demonstrate compliance with those identified quality standards. The quality standards and requirements should include both the product and processes.

Product Quality:
The product quality standards and requirements will be determined by the project team and quality group. These standards will primarily be based on the company's documented standards for all fiber optic cables. There may be product-specific quality standards identified that are not currently part of the documented organizational standards. In this case, the quality group will review these newly identified standards and incorporate them into organizational documentation if approved. The project team will also document any newly identified quality standards into the LTFC project plan and ensure communication with all stakeholders.

As trial products are measured at pre-determined intervals, we will know that the product is compliant with quality standards once we achieve ten consecutive trial runs resulting of cable which is 100% within acceptable quality control margins.

Process Quality:
The process quality standards and requirements will be determined by the project team and quality group. Many of these standards will be based on existing company process standards. However, it is anticipated that there will be several unique steps in the manufacturing of the LTFC product which will require new quality standards. The LTFC project team will work with the quality group to establish acceptable standards and document these standards for incorporation into both organizational process documents as well as the LTFC project plan. These standards will be communicated to all project stakeholders.

As trial products are created, the process metrics will be measured and analyzed to determine the quality of the process. Once the LTFC product meets quality compliance and all process metrics fall within acceptable quality assurance margins, we will achieve process compliance for the LTFC project.

Here the Quality Management Plan should explain how you will define and document the process for auditing the quality requirements and results from quality control measurements in order to ensure that quality standards and operational definitions are used. This section should also document the actual quality assurance metrics used for this project.

The quality assurance of the LTFC Project focuses on the processes used in the manufacturing of the LTFC product. In order to ensure quality, an iterative quality process will be used throughout the project life cycle. This iterative process includes measuring process metrics, analyzing process data, and continuously improving the processes.

The LTFC Project Manager and the project team will perform assessments at planned intervals throughout the project to ensure all processes are being correctly implemented and executed. Key performance metrics for the manufacturing of the LTFC product include polyethylene (PE) waste, fiber waste, and time per cable run for each phase of cable creation (buffering, stranding, and jacketing). The established project tolerances for these metrics are the organizational standards for all other cable products. The table below provides the key quality assurance metrics for the LTFC Project.

Process Action	Acceptable Process Standards	Process Phase	Assessment Interval
Filter Tube Buffering	- < 20 feet fiber waste per tube - < 0.5 lbs PR waste per tube - < 8 minutes per linear km of buffer tube	Buffering	Daily or per run
Filter Tube Stranding	- < 10 feet of waste per stranded core - < 12 minutes per linear km of stranded core	Stranding	Daily or per run
Core Jacketing	- < 15 feet of waste per jacketed cable - < 3 lbs PE waste per cable - < 12 minutes per linear km of jacketed cable	Jacketing	Daily or per run

The quality manager will provide day to day quality management and conduct process audits on a weekly basis, monitor process performance metrics, and assure all processes comply with project and organizational standards. If discrepancies are found, the quality manager will meet with the Project Manager and review the identified discrepancies.

The Project Manager will schedule regularly occurring project, management, and document reviews. In these reviews, an agenda item will include a review of project processes, any discrepancies and/or audit findings from the quality manager, and a discussion on process improvement initiatives.

Process improvement is another aspect of quality assurance. Quality assurance reviews, findings, and assessments should always result in some form of process improvement and, as a result, product improvement. All process improvement efforts must be documented, implemented, and communicated to all stakeholders as changes are made.

In this section the Quality Management Plan describes how you will define and document the process for monitoring and recording the results of executing the quality activities to assess performance and recommend necessary changes. Quality control applies to the project's product as opposed to its processes. It should include what the acceptable standards and/or performance are for the product and how these measurements will be conducted.

The quality control of the LTFC project focuses primarily on the LTFC product and the acceptable standards and performance. The quality performance standards for the LTFC Project are in accordance with the organizational standards of performance of all fiber optic cable products. However, there are several project-specific quality standards which were established specifically for the LTFC Product. All trial cables which are produced will be submitted to the characterization group for standard loose tube cable performance testing. Additionally, all physical measurements will conducted on each produced cable to ensure compliance with established quality standards. The table below illustrates all performance and physical quality standards for the LTFC Product:

Product	Physical/Performance Standards	Quality Assessment Activities	Assessment Intervals
6-36 fiber loose tube cable	0.75” +/- 0.01” diameter > 300 N/m2 Tensile Strength < 5% attenuation at 625nm wavelength	Lab and field testing	Per produced cable length
42-188 fiber loose tube cable	1.5” +/- 0.01” diameter > 450 N/m2 Tensile strength < 5% attenuation at 625nm wavelength	Lab and field testing	Per produced cable length
194-288 fiber loose tube cable	2.25” +/- 0.001” diameter > 600 N/m2 Tensile strength < 5% attenuation at 625nm wavelength	Lab and field testing	Per produced cable length

The project team will perform all physical measurements on their trial cables. The characterization group will perform attenuation testing and will provide the results back to the project team within 3 business days after the test sample is submitted. The quality group will ensure all physical and performance standards are met for each trial cable, perform audits, and assist the project team with creating or updating all documentation related to product quality.

The Project Manager will schedule regularly occurring project, management, and document reviews. In these reviews, an agenda item will include a review of products, any discrepancies and/or audit findings from the quality manager, and a discussion on product improvement initiatives.

It is imperative to the success of the project that all of the established physical and performance standards are met. By doing so, the LTFC Project Team will ensure that the product achieves the high level of customer satisfaction anticipated and that future operational cable production will be in line with budget and resource allocations.

Code of WBS

Name of Component

Work Description

Deliverable

Resources

Budget

This section of the Quality Management Plan should contain a sample or useable table/log to be used in taking quality measurements and comparing them against standards/requirements. These forms may be found in many different styles or formats. The most important aspect of this log is to provide documentation of the findings in the Quality Management Plan. If actual measurements do not meet the standards or requirements then some action must be taken. This may be done in regularly scheduled project status meetings or as necessary throughout the project lifecycle.

All LTFC Project products and processes must be measured and fall within the established standards and tolerances. The below logs will be used by the project and quality teams in conducting these measurements and will be maintained for use as supporting documentation for the project's acceptance.

Quality Assurance Log

Trial #	Date	Process Measured	Required Value	Actual Measured	Acceptable? (Y/N)	Recommendation	Date Resolved

Quality Control Log

Trial #	Date	Process Measured	Required Value	Actual Measured	Acceptable? (Y/N)	Recommendation	Date Resolved

Source: projectmanagementdocs.com

More Articles...

«
Start
Prev
1
2
Next
End
»

Page 1 of 2