Project Plan

Project Information

Project: PROJECT-NAME
Project Time-frame: START-DATE - END-DATE
Attached worksheets:
Related Documents:
Process impact: This plan will be used to evaluate and estimate the project schedule. Key assumptions that affect the plan should be documented here. Individual work items should be assigned and tracked in an issue tracking tool. The project plan should be updated throughout the lifetime of the project.

Introduction

What are the business problem, scope, and goal of this project?
For a summary of this project, see the project proposal.
Who will sponsor, manage, and lead the project?
  • Sponsor: PERSON-NAME
  • Manager: PERSON-NAME
  • Technical lead: PERSON-NAME
What authority does the project manager have?
  • Hire, dismiss, or reassign personnel in his/her department
  • Hire contract employees or manage subcontractors
  • Purchase equipment, software, and other needed capital
  • Assign specific tasks to other departments
  • Negotiate requirements and schedules with customers
  • Negotiate with vendors, suppliers, and partners
What planning lessons were learned in previous releases?
None yet. This is the first release.
  • We can reduce training time, but it significantly increases development time.
  • Maintaining a past release takes more than 20% of our time, due to low quality in that release.
  • The customer seems to always change the requirements after the second demo.
  • There are always defects. We planned time to test, but we forgot to plan time to fix the defects. On this project, we will actually estimate the number of undetected defects.
  • Issue XXXX made us realize that we forgot to plan time for DEVELOPMENT-TASK.
How is this project plan organized?
This main project plan page describes the methodology, work breakdown structure, deliverables, and schedule. Attached worksheets deal with resource needs and risk management.
What are the most important facts that a project stakeholder should know about this plan?
Based on recent experience, we decided to plan more time for testing and other quality-improving activities in this release.
It may seem that we are getting off to a slow start, but that is because we will not have our full team available until week 6.
We are following an iterative development methodology with fairly short release cycles. This schedule represents one of those short cycles. We will begin planning the next cycle in week 9 of this cycle.

Summary of Methodology

What general development approach will be used?
THREE TO FIVE SENTENCES OR BULLETS HERE. COVER GENERAL APPROACH, IMPORTANT ASSUMPTIONS, KEY PRACTICES, AND PROJECT COORDINATION CONTROLS. For more information see the Software Development Methodology.
How will the project team be organized?
The development team will consist of ...
The change control board will consist of ...
What development and collaboration tools will be use?
We plan to use the following tools extensively throughout the project:
  • Project website
  • Project mailing lists
  • UML design tools
  • Issue tracking system
  • Version control system
  • Automated build system
  • Automated unit test system
  • Record-and-playback GUI testing
How will changes be controlled?
  • Requests for requirements changes will be tracked in the issue tracker.
  • The change control board (CCB) will review requested changes and authorize work on them as appropriate.
  • After the feature complete milestone, no new features will be added to this release.
  • After the code complete milestone, no entirely new product source code will be added to this release.
  • All source code commit log messages must refer to a specific issue ID, after the feature complete milestone.
  • All source code commits in critical components must be reviewed by a second developer.
How will this plan be updated?
This project plan will be updated by PERSON-NAME as needed throughout the project. It has been placed under version control and instructions for accessing it are on the project website. Any change to the plan automatically sends a notification to a project mailing list.

Planning Goals

What are the relative priority and flexibility of planning variables?
Absolutely not flexible: Schedule of final delivery
Not flexible: schedule of deliverables, essential features, quality of critical components
Somewhat flexible: budget, quality of non-critical components, schedule for SPECIFIC-MILESTONE
Flexible: schedule for other internal milestones
Absolutely not flexible: PLANNING-VARIABLE
Not flexible: PLANNING-VARIABLE
Somewhat flexible: PLANNING-VARIABLE
Flexible: PLANNING-VARIABLE

Work Breakdown Structure and Estimates

TODO: List tasks that will be needed for this project. Continue to refine tasks into subtasks until you feel that you have enough detail to expose risks and make reasonable estimates in ideal engineering hours.
TIP: Label each step uniquely to show its position in the WBS, e.g., Step 1.1.4.A. Use numbers for steps that you intend to do in sequence, and use letters for steps that you intend to do in parallel. E.g., Step 1.1 comes before Steps 1.2.A and 1.2.B, but those two steps may be done in parallel, and Step 1.3 will be done after all 1.2.* steps have been finished. Don't worry about renumbering if you delete a step.
StepDescriptionPlanned Hours
1.Preparation
1.1.Developer training60
2.Inception
2.1.Requirements gathering60
2.2.Requirements specification40
2.3.Requirements validation20
3.Elaboration
3.1.High-level design10
3.2.Low-level design (BREAK DOWN BY COMPONENT)
3.2.A.Object design20
3.2.B.User interface design20
3.2.C.Database design6
3.3.Design review and evaluation10
4.Construction
4.1.A.System implementation
4.1.A.1.Implement COMPONENT-NAME 150
4.1.A.2.Implement COMPONENT-NAME 250
4.1.A.3.Implement COMPONENT-NAME 350
4.1.A.4.Implement COMPONENT-NAME 425
4.1.A.5.
Integrate Components
(mostly done during component implementation)
5
4.1.B.Technical documentation (BREAK DOWN BY COMPONENT)20
4.1.C.User documentation (BREAK DOWN BY COMPONENT)40
4.1.D.Testing
4.1.D.1.Test planning20
4.1.D.2.Test code implementation (BREAK DOWN BY COMPONENT)60
4.1.D.3.Test execution30
4.2.Implementation review and evaluation20
5.Transition
5.A.Release packaging8
5.B.Documentation for other groups6
6.Reflection
6.1. Postmortem report20
Total

Deliverables in this Release

TODO: List project deliverables with descriptions and delivery dates.
Deliverables Description Planned Delivery Date
Web application The main web application for the site 2004/12/31
Desktop application, application data, and on-line help The main application for the product. All data that comes with the application, including examples, clip-art, and templates. Help files in FORMAT. Kickoff + 8 weeks
PRODUCT-NAME Server Special server software that processes requests from clients 2004 Q4
PRODUCT-NAME Client Desktop application that connects to the server DATE
User guide and quick-start guide Manual for end users, administrators, and system integrators DATE
Installer Program to install and update the product on PLATFORMS. Detailed step-by-step installation instructions. DATE
Draft release-specific documentation Updated release notes, FAQ, demo script, marketing materials, etc. DATE
DELIVERABLE-NAME DESCRIPTION DATE
DELIVERABLE-NAME DESCRIPTION DATE
DELIVERABLE-NAME DESCRIPTION DATE
Entire product first test release All parts of the product released to QA Dept. for system test DEADLINE - 4 weeks
Entire product second test release All parts of the product released to QA Dept. for system test DEADLINE - 3 weeks
Entire product early access release All parts of the product released to partners and key customers for evaluation DEADLINE - 2 weeks
Entire product third test release All parts of the product released to QA Dept. for system test DEADLINE - 1 week
Final release-specific documentation Finalized release notes, FAQ, demo script, marketing materials, etc. DEADLINE - 3 days
Entire product golden master All parts of the product released to manufacturing department for shipment to customers, or to ASP operations department DEADLINE

Schedule for this Release

TODO: Make the rows in this table match the steps in your WBS above. If you have a large number of detailed steps, you can skip the most detailed ones. The columns of the table represent weeks of calendar time. For each cell in the table, enter the number of hours of ideal engineering time that the team will spend on that task that week. The hours are automatically summed, across and down.
TIP: These hours should total to the same as the total of the hours listed in your resource needs document. And, the hours for each type of effort resources needed should correspond to the sum for each type of task.
Task \ Week W-01 W-02 W-03 W-04 W-05 W-06 W-07 W-08 W-09 W-10 W-11 W-12 Task Total
1. 00 00 00 00 00 00 00 00 00 00 00 00
2. 00 00 00 00 00 00 00 00 00 00 00 00
3. 00 00 00 00 00 00 00 00 00 00 00 00
4.1.A. 00 00 00 00 00 00 00 00 00 00 00 00
4.1.B. 00 00 00 00 00 00 00 00 00 00 00 00
4.1.C. 00 00 00 00 00 00 00 00 00 00 00 00
4.1.D. 00 00 00 00 00 00 00 00 00 00 00 00
4.2. 00 00 00 00 00 00 00 00 00 00 00 00
5. 00 00 00 00 00 00 00 00 00 00 00 00
6. 00 00 00 00 00 00 00 00 00 00 00 00
Weekly Totals

Risk Management

TODO: Work through the risk management worksheet and add any risk mitigation tasks to your plan.

The main risks of this project are described in the risk management worksheet.

Project Planning Checklist

Which of the follow planning variables have some flexibility?
The schedule can change somewhat, if needed to implement the planned functionality and quality with the planned human resources without excessive risk. Later release schedules may be shortened or delayed.
More human resources can be added, if needed to implement the planned functionality and quality on the planned schedule without excessive risk. We will allocate additional budget if needed.
Some features can be slipped to a later release, if needed to meet the same schedule and quality with the same human resources without excessive risk. We will try to add the missing functionality in later releases.
The product quality can be lowered in this release, if needed to meet the same schedule and functionality with the same human resources without excessive risk. We will try to raise the quality in later releases.
The project risk will be raised substantially if anything goes wrong because we have no flexibility in functionality, quality, schedule, or resources. We have our fingers crossed and we are willing to ignore problems that no one else points out.
Does this project conflict or compete for resources with any other project?
No, this is the only project that we are working on.
Yes, it competes. We have determined how many hours each person can actually dedicate to this project.
Yes, it conflicts. We are counting the same person's available hours more than once, so this schedule is not realistic.
Are the same human or machine resources allocated to maintenance of past versions and/or planning of future versions during this release time period?
No, this is the first release, so there are no past releases to maintain. Management will work on planning the next release without taking team members away from this release.
Yes, we predict that team members will spend an average of 20% of their time maintaining previous releases and planning future releases during this release time frame. Some weeks may be higher if an urgent patch to a previous release is needed.
Yes, and the past version needs a lot of maintenance. Our resources will need to take time away from the current project, so this schedule is unrealistic.
Does this project depend on the success of any other project?
No, this project stands alone.
Yes, project P1 must provide library L, and project P2 must improve the usability of feature F, and ....
Yes, project P1 must complete before human resources can be reassigned from that project to this project.
Does any other project depend on this project?
No, this project is not producing any components that will be used in other current projects.
Yes, we must produce library L for us in this project and then support users of L in projects P1 and P2.
Are there any other important dependencies that will affect this project?
No, everything is covered above.
Yes. DETAILS ...
TODO: Check for words of wisdom for additional advice on this template.
Company Proprietary
Copyright © 2003-2004 Method Labs. All rights reserved. License terms. Retain this copyright statement whenever this file is used as a template.