© 2009 Altair Solutions. JPersse@AltairSol.

com

Project Plan Template

The COMPANY Corp. quality program assists the technical and managerial teams in performing
their work in a consistent, predicable, and repeatable fashion. In line with this, the
organization supports an established method for creating the plan for all COMPANY Corp.
development projects. An important part of this method is the use of a standardized plan
template. This section describes the structure and use of this template.

Basic Components:
1) Statement of Work
2) Technical Introduction
3) Lifecycle and Tools Adopted
4) Standards and Procedures
5) Needed Knowledge & Skills
6) Estimating Guidelines
7) Project Modules
8) Work Products
9) Work Breakdown Structure
10) The Budget
11) Stakeholder Communication Plan
12) Constraints
13) Corrective Action Criteria
14) Measurements
15) Appendices
Configuration Management Plan Template
Project Quality Assurance Plan Template
Project Knowledge & Skills Inventory Form
Project Skills Set Form

Component Descriptions:

1) Statement of Work
All COMPANY Corp. projects are initiated through the creation of a Statement of Work. The
Statement of Work (SOW) is a (usually) brief narrative description of a product to be built for
a customer. The SOW, while general in nature, tends to bind the scope of the project within
reasonable limits, sets general cost and schedule expectations, and includes a high level
overview of product use and required functionality. The SOW is reviewed, approved, and
signed by COMPANY Corp. and customer representatives. The approved/signed SOW should
be included in the development plan.

2) Technical Introduction
The pro forma project plan should include a brief introduction or overview describing the
project’s purpose, scope, goals, and objectives. This introduction should present to the team
and stakeholders a high level orientation to the work at hand. It can also be used in a manner
similar to the SOW, as a bell-weather demonstrating a common understanding of the project
between client and vendor.
 © 2009 Altair Solutions. JPersse@AltairSol.com

3) Lifecycle and Tools Adopted

In this section include a description of the software development lifecycle to be used.
COMPANY Corp. uses a range of development methodologies, lifecycles and tools. The
project might be suited to the spiral method, the waterfall method, rapid application
prototyping, or any of the other established methods. It may even call for a proprietary
method. The selection of the lifecycle and documenting the tools to be used serves three
benefits: A) It explicitly defines the technical direction of the project; B) It positions the
team to work in a defined direction; and C) It informs the client as to the technical base of
the project.

4) Standards and Procedures

In this section the planner identifies the standards and procedures which will be used to
manage the project over the course of its duration. This can be a boilerplate-type insert and
the organization encourages its planners to use the following text from project to project,
with tailoring employed based on the unique characteristics of each project.

5) Needed Knowledge and Skills

COMPANY Corp. projects tend to share distinct and explicit similarities only at the macro
level. Depending on the characteristics of design, development, and deployment a project
team may need to possess specialized skills. One job of the planner is to determine this need
and then document what skill sets are needed. There are two forms which may be used for
this purpose:

6) Estimating Guidelines
The key to effective planning is to plan in cooperation with others. Varied and experienced
input is valuable estimates that are reliable and dependable. During the planning process
seek key technical team members or stakeholders and work with them to develop estimates
in two areas: project modules and work products. Project modules are design elements that
approach the components that will go into the finished product. Naturally, the more
components, the more sophisticated the product typically is. Work products are those
documents (such Requirements, High Level Designs, and Test Plans) that may be required to
produce in order to create the product. Both Project Modules and Work Products need to be
estimated; only then will the planner have a true picture of the size of the effort.

When the planner works with others to derive these estimates, keep four things in mind: A)
Provide guidelines for estimating in a consistent way;
B) Provide as much data as practical;
C) Solicit assumptions; and
D) Keep the raw data for use in later planning efforts.

7) Product Modules
As mentioned above, project modules are design elements that approach the components
that will go into the finished product. In the planning stage it is naturally difficult to identify
the number or size of the components, unless a comparative repository is available for
reference. Nevertheless, even immature estimates are better than no estimates or ill-
conceived ones. When estimating the product modules, first identify them.
 © 2009 Altair Solutions. JPersse@AltairSol.com

Then, for each, calculate what staff resources, computing/tool resources, time, and
dependencies would be required to produce each. Make sure to document any assumptions
associated with the estimates.

8) Work Products
Work products are those documents (such Requirements, High Level Designs, and Test Plans)
that may be required to produce in order to create the product. In the project plan list and
describe these project deliverables. Usually included in this set are items such as user
documentation and design specs. But there may also be non-deliverable work products, like
test plans, test cases, and low level designs. For effective planning it’s important that this
list be complete.

When estimating the work products, first identify them. Then, for each, calculate what staff
resources, computing/tool resources, time, and dependencies would be required to produce
each. Make sure to document any assumptions associated with the estimates.

9) Work Breakdown Structure

The work breakdown structure (WBS) and the schedule that accompanies it is usually seen as
the centerpiece of the project plan. The WBS should break the project down into a series of
distinct, definable milestones and benchmarks, each representing a progression point for the
project. The schedule should be of sufficient detail that team members understand when and
what they need to be focused on during the various stages of development. At the same time
the WBS and schedule should avoid too rigid detail that might encumber the process of
managing and executing the project. Here it is important to combine the plans of Software
Configuration Management and Project Quality Assurance. These two teams will develop
their own plans for the project so their milestones and benchmarks need to be integrated into
the project plan as a whole. This section of the plan, in the end, should present a
consolidated picture of the activities of the entire team across the life of the project.

10) The Budget

The schedule, the work breakdown structure, and the estimates for the work products and
project components will provide you with the data needed to derive the project budget.
Provide the budget numbers in detail adequate to the needs of the client and COMPANY Corp.
management. This level may well vary from project to project.

11) Stakeholder Communication Plan

Effective plan execution requires regular and open communication with he project
stakeholders. Set the communication plan according to the needs of the project. Below is a
super-set list of potential communication avenues.
Communication Description
Weekly Team Meeting
Usually an hour in length these status meetings allow the COMPANY team members,
including the Project Manager, to participate with any relevant stakeholders and raise and
address project issues.

Daily Stand-Up Meeting

Often, the team may find it beneficial to hold a brief, daily 15-minute stand-up meeting to
discuss direction and issues. This may or may not call for stakeholder attendance.
Weekly Checkpoint
 © 2009 Altair Solutions. JPersse@AltairSol.com

The COMPANY team may elect to conduct a 30-minute “checkpoint” meeting every week to
discuss status of progress, planned activity, and specific issues to be addressed in the weekly
Status Report.

Weekly Status Report

As a formal communication vehicle, the COMPANY team can provide to stakeholders weekly
reports documenting overall status, open active issues, accomplishments for the week, goals
planned for the coming week, overall milestone progress, and change requests that occurred
during the week.

12) Constraints
This final section describe three things: the risks that might impact the plan, any assumptions
that were used to create the plan, and any limitations contained in the plan data.. These
items can have potentially large impact on the schedule, costs, effort, and size of the
project. The number and scope of the risks and assumptions give a feeling for the solidity of
the plan, and helps anticipate the possibility of plan adjustments down the road. For this
reason, the risks and assumptions should be followed with a brief description of the
contingencies which may be called into play should deviations occur.

13) Corrective Action Criteria

Each development pan should establish corrective action criteria. These are standardized and
accepted guidelines project managers can use to evaluate development situations and
determine whether or not a new course of action --- a correction to the plan – is needed.

The following criteria can be used to assess issue and problems that may arise during project
phases. Use the checklist with your team as a tool to uncover areas of weaknesses, cloudy
definitions, or lack of planning. Check to see that you have done or are positioned to do the
following. If not, revisit that aspect of your project planning and make the adjustments.

14) Measurements
In this section include the measurements that will be made over the course of the project
lifecycle, and identify at what point they will occur. This will include such project
management measurements as deviations from expected timelines, average milestone
duration, project costs versus actual, or any measurements you specifically define. These
measurements are important because they will provide you with raw data for analyzing
performance and identifying areas for improvement. It is a good idea to also include the SQA
and SCM measurements in this section.

15) Appendices
For the sake of reference and future measurement you should consider including an appendix
at the end of the plan that includes all the raw planning data used to create the plan. This
includes the data given to you by the team members in the estimating face of the planning
process. You might also consider appending the full Software Configuration Management plan
and the Project Quality Assurance Plan if you haven’t fully integrated them into the SDP.