<Your Project Name Here>

Project Management Plan

<Course, Semester, Year>

 

Modification history:

Version

Date

Who

Comment

v0.0

08/15/00

G. H. Walton

Template

v1.0

<date here>

<who>

<put comment to summarize the changes made in this version>

...

 

 

 

Team Name: <your team name here>

Team Members:


Contents of this Document

Project 0verview

Reference Documents

Applicable Standards

Project Team Organization

Deliverables

Software Life Cycle Process

Tools and Computing Environment

Configuration Management

Quality Assurance

Risk Management

Table of Work Packages, Time Estimates, and Assignments

PERT Chart

Technical Progress Metrics

Plan for tracking, control, and reporting of progress


Project 0verview

<include a 1-paragraph description of what the project is all about>


Reference Documents


Applicable Standards

<NOTE: your team is expected to follow to the letter any standard you list in this section>


Project Team Organization

<include a short description of your organization and any organizational issues (a paragraph or two will usually suffice). See your text for background information. Things to includes are:


Deliverables <fill in the table>

Artifact

Due Dates <some will have multiple deliveries>

Meeting Minutes

Individual Logs

Group Project Management Reports

ConOps

Project Plan

SRS

High-Level Design

Detailed Design

Test Plan

User's Manual

Final Test Results

Source, Executable, Build Instructions

Project Legacy


Software Life Cycle Process

<What process will your group follow? Give a sentence or two description of the process and the rationale for selecting this process. Give a diagram of the process that includes the major phases and the sequencing of the phases. See your text for background information. You may decide to implement a "hybrid" model that is not exactly as shown in your text.>


Tools and Computing Environment

<What Operating System, programming languages, compilers, libraries, ...>


Configuration Management

<How will your group handle version control and change control? Who is responsible? What procedures will be followed? ... See your text for background information>


Quality Assurance

<What QA activities will your group do and when will each activity occur? ... Who is responsible for making sure this occurs? How will the results be reported?>


Risk Management

<Identify potential risks for this project. For each risk, how will you manage the risk? . Note: it is expected that this information will be at a high-level at the beginning of the project and will be updated monthly to provide more detail.>


Table of Work Packages, Time Estimates, and Assignments

<Break down your project into a hierarchy of work packages. For each work package, estimate how much work time it will take to complete. For each work package, state who is responsible for its completion. Note: it is expected that this information will be at a high-level at the beginning of the project and will be updated monthly to provide more detail.>


PERT Chart

<This should be detailed enough so that important activities and dependencies are evident. Estimated durations of activities and the critical path should be included. See your text for discussion and example PERT charts.>

 


Technical Progress Metrics

<You must estimate and track your technical progress using appropriate metrics for each phase of your project. What is a useful metric for each phase of your project? For example, for requirements phase, the total number of requirements, the number of requirements changes, the number of TBDs, ... For OO analysis and design, you might want to count UML diagrams completed. For detailed design and code, you might want to count packages, classes, methods. You will also want to think about other technical metrics such as: memory usage, execution speed, size of various documents, complexity of code (using any of the complexity metrics), ... These can help in planning and in tracking your project work.>

<Choose your metrics carefully -- select metrics that will be easy to collect, easy to report, and easy to interpret. The goal is to give management insight into the progress and risks of your project.>


Plan for tracking, control, and reporting of progress

<What data to collect; when to collect it; how and when to interpret it; how and when to report it. For example, the following would suffice:

"At a minimum, each team member will post the following information weekly: individual time and activity log, individual status information, individual issues and problems, and individual defect log.

Each week, the project manager will: read and analyze the logs; examine the technical content of the work done to date; examine the technical progress metrics; consider the QA results; reassess the potential project risks; and take corrective action if necessary.

The project manager will issue a Project Management Report on the schedule as indicated in the deliverables section above. At a minimum, the Project Management Report will be generated every two weeks and will include the following information: 1 sentence description of overall status, 1 or 2 sentence of any planned changes to the project plan, graph of planned vs actual time, graph of planned vs actual for each technical progress metric, updated PERT chart."


Template created by G. Walton (GWalton@mail.ucf.edu) on Aug 30, 1999 and last updated Aug 15, 2000

This page last modified by <your name here> (<your e-mail address text and link here> ) on <modification date here>