Project Plan Template Sample

8/8/2019 Project Plan Template Sample

1/4

2009 Altair Solutions. [email protected]

Project Plan Template

The COMPANY Corp. quality program assists the technical and managerial teams in performingtheir 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 plantemplate. This section describes the structure and use of this template.

Basic Components:1) Statement of Work2) Technical Introduction3) Lifecycle and Tools Adopted4) Standards and Procedures5) Needed Knowledge & Skills6) Estimating Guidelines7) Project Modules

8) Work Products9) Work Breakdown Structure10) The Budget11) Stakeholder Communication Plan12) Constraints13) Corrective Action Criteria14) Measurements15) AppendicesConfiguration Management Plan TemplateProject Quality Assurance Plan TemplateProject Knowledge & Skills Inventory FormProject Skills Set Form

Component Descriptions:

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

2) Technical IntroductionThe pro forma project plan should include a brief introduction or overview describing theprojects purpose, scope, goals, and objectives. This introduction should present to the teamand stakeholders a high level orientation to the work at hand. It can also be used in a mannersimilar to the SOW, as a bell-weather demonstrating a common understanding of the projectbetween client and vendor.


2/4


3) Lifecycle and Tools AdoptedIn this section include a description of the software development lifecycle to be used.COMPANY Corp. uses a range of development methodologies, lifecycles and tools. Theproject might be suited to the spiral method, the waterfall method, rapid applicationprototyping, or any of the other established methods. It may even call for a proprietarymethod. The selection of the lifecycle and documenting the tools to be used serves threebenefits: A) It explicitly defines the technical direction of the project; B) It positions theteam to work in a defined direction; and C) It informs the client as to the technical base ofthe project.

4) Standards and ProceduresIn this section the planner identifies the standards and procedures which will be used tomanage the project over the course of its duration. This can be a boilerplate-type insert andthe 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 macrolevel. Depending on the characteristics of design, development, and deployment a projectteam may need to possess specialized skills. One job of the planner is to determine this needand then document what skill sets are needed. There are two forms which may be used forthis purpose:

6) Estimating GuidelinesThe key to effective planning is to plan in cooperation with others. Varied and experiencedinput is valuable estimates that are reliable and dependable. During the planning processseek key technical team members or stakeholders and work with them to develop estimatesin two areas: project modules and work products. Project modules are design elements thatapproach the components that will go into the finished product. Naturally, the more

components, the more sophisticated the product typically is. Work products are thosedocuments (such Requirements, High Level Designs, and Test Plans) that may be required toproduce in order to create the product. Both Project Modules and Work Products need to beestimated; 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; andD) Keep the raw data for use in later planning efforts.

7) Product ModulesAs mentioned above, project modules are design elements that approach the componentsthat will go into the finished product. In the planning stage it is naturally difficult to identifythe number or size of the components, unless a comparative repository is available forreference. Nevertheless, even immature estimates are better than no estimates or ill-conceived ones. When estimating the product modules, first identify them.


3/4


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

8) Work ProductsWork 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 anddescribe these project deliverables. Usually included in this set are items such as userdocumentation and design specs. But there may also be non-deliverable work products, liketest plans, test cases, and low level designs. For effective planning its important that thislist be complete.

When estimating the work products, first identify them. Then, for each, calculate what staffresources, computing/tool resources, time, and dependencies would be required to produceeach. 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 asthe centerpiece of the project plan. The WBS should break the project down into a series ofdistinct, definable milestones and benchmarks, each representing a progression point for theproject. The schedule should be of sufficient detail that team members understand when andwhat they need to be focused on during the various stages of development. At the same timethe WBS and schedule should avoid too rigid detail that might encumber the process ofmanaging and executing the project. Here it is important to combine the plans of SoftwareConfiguration Management and Project Quality Assurance. These two teams will developtheir own plans for the project so their milestones and benchmarks need to be integrated intothe project plan as a whole. This section of the plan, in the end, should present aconsolidated picture of the activities of the entire team across the life of the project.

10) The BudgetThe schedule, the work breakdown structure, and the estimates for the work products andproject 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 PlanEffective plan execution requires regular and open communication with he projectstakeholders. Set the communication plan according to the needs of the project. Below is asuper-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 todiscuss direction and issues. This may or may not call for stakeholder attendance.

Weekly Checkpoint


4/4


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 weeklyreports 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) ConstraintsThis final section describe three things: the risks that might impact the plan, any assumptionsthat were used to create the plan, and any limitations contained in the plan data.. Theseitems can have potentially large impact on the schedule, costs, effort, and size of theproject. The number and scope of the risks and assumptions give a feeling for the solidity ofthe plan, and helps anticipate the possibility of plan adjustments down the road. For thisreason, 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 CriteriaEach development pan should establish corrective action criteria. These are standardized andaccepted guidelines project managers can use to evaluate development situations anddetermine 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 projectphases. Use the checklist with your team as a tool to uncover areas of weaknesses, cloudydefinitions, or lack of planning. Check to see that you have done or are positioned to do thefollowing. If not, revisit that aspect of your project planning and make the adjustments.

14) MeasurementsIn this section include the measurements that will be made over the course of the projectlifecycle, and identify at what point they will occur. This will include such projectmanagement measurements as deviations from expected timelines, average milestoneduration, project costs versus actual, or any measurements you specifically define. Thesemeasurements are important because they will provide you with raw data for analyzingperformance and identifying areas for improvement. It is a good idea to also include the SQAand SCM measurements in this section.

15) AppendicesFor 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. Thisincludes the data given to you by the team members in the estimating face of the planningprocess. You might also consider appending the full Software Configuration Management planand the Project Quality Assurance Plan if you havent fully integrated them into the SDP.

Documents

Project Plan Template Sample