Project Plan Outline/Template

 

The project plan puts the meat behind the charter. The Charter defines what the project will accomplish, i.e., what the product will do. This document adds more detail to the what, and is used to define specifically how the project will be accomplished, including a detailed schedule. You will use it to coordinate all activities of the project, both those to manage the project and those to do the work that will achieve the project goals.

 

The Project Management Plan will have several sections, and generally should follow the following outline. However, you should adapt the contents of the plan to suit the needs of your particular project.

 

Keep in mind:

The project includes all the things you will do to create a successful product. The product is what you are creating for your sponsor such as a database, website, or network. The product also includes all the supporting documents. You will have both project and product deliverables and activities. This plan is a project deliverable. The various tasks to create it are project tasks. User requirements documents, design documents, etc. are project deliverables. The tasks to create them are project tasks. This plan specifies how you will accomplish both.

 


REMINDER: This is a template. Follow the instructions for template use.
Project Title & Sponsoring Organization: Give the name of the project and sponsoring organization

 

Team: name the team and list the members here

Project Description

Start with the project description from your Charter and then take it to the next level of detail. As you add those details, make sure you are adding information, not changing the intent. If you find you need to change the Charter, you can do that, but make sure you get appropriate agreements. This should still be brief, and written from the business perspective (think about business functions and the relationship to product features and functions). After you write it, look at your Charter success criteria and make sure everything still matches.

 

Project Feasibility Assessment

This section should evaluate the economic, technical, operational, and organizational feasibility of the project; identify and assess project risks that are significant factors in the overall project feasibility for both you and the sponsor. Include a statement that indicates whether you believe the project is doable or not, for both your team and your sponsor. (If not, you’ll want to do a different project!). You will want to write this section after you complete the Constraints, Resource Requirements and Risk Analysis sections of this plan.

 

Constraints

List any known constraints imposed by the environment or by management. Constraints are externally imposed restrictions on what you can do or how you can do it. Typical constraints may include fixed budget; limited resources; imposed interim and/or end dates; predetermined software systems and packages; and other predetermined solutions. For example, if your sponsor already has a website and uses Frontpage, you will also use Frontpage for your additions even if you hate it.

 

Resource Requirements and Budget

This section of your report should describe what resources you will need and any costs associated. There will generally be four sections here: human resources, material/equipment and operating expenses and other resources. For the initial plan, these can be rough order of magnitude (ROM) estimates. You should update these to definitive estimates as soon as you complete the Technology Review.

 

Human resources. Identify your stakeholders: list everyone whose time you will need to complete your project and what their role in the project will be. Include your team members, sponsor and any staff or end-users, and any on-site, vendor, or SJSU experts with whom you may consult for advice in completing your project. Be sure to list contact information for them. Estimate how much time you will need from each of these resources. For this project, the cost of these resources should be expressed in time, e.g., hours/week.

 

NOTE: You are not only allowed to ask for help with any aspect of the project, but encouraged to do so. For example, you might want to ask a member of the faculty or other expert to advise you on technology choices before you turn in your technology review.

 

Material/Equipment Requirements. This section should define the hardware/software and any other capital resources needed to complete your project successfully. This includes all requirements for your team as well as all requirements for your sponsor, not just to develop the system but to maintain and operate it. Identify costs associated with these items, and who will provide them. If you or the sponsor already owns them, show the cost as $0, but you should still list the item and indicate where it is coming from. NOTE: All software must be legally licensed. Don’t even think about “helping” your sponsor by giving them illegal software.

 

NOTE: the department can provide hardware and software resources for you to use in developing your project. However, you must request resources as part of your Technology Review and show them in this plan.

 

Operating Expenses are expenses and fees, such as for an ISP or webhost. Distinguish between one-time and ongoing expenses. For ongoing expenses, budget for a reasonable length of time, such as one year. Operating expenses also include non-capital expenditures such as for travel, training, supplies, books, copying, printing, etc.

 

Other resources include space and any documentation of the existing system, vendor technical literature, systems manuals, etc. that you will need to consult. Space includes a designated team meeting and work site, including any on-site office space your sponsor may provide.

 

For all categories, make crystal clear who will provide what! For example, does the sponsor assume that you have the necessary software tools to complete your project, or will your sponsor provide them?

 

Risk Analysis

Even highly feasible projects have associated risks: this is where you identify and assess them. Risks are external factors or conditions that might happen along the way and could cause your project to fail or change direction. For example, your sponsor bringing in new stakeholders late in the project could be a risk. Your lack of experience is not a risk—it’s not external, and is just something you have to deal with.

 

List the risks you identify in the following table and rate (high, medium, low) the probability the risk will occur and the impact on your project if it does occur. Describe how you will monitor the situation so you will know if any of the risks occurs, or better, is about to occur. Describe what you are going to do about the risk. Anything rated as both high probability and high impact should be addressed in your feasibility assessment. Add appropriate project management activities to your schedule.

 

Risk Description

Probability

Impact

Monitoring Strategy

Response Strategy

 

 

 

 

 

 

 

 

 

 

 

Change Management

Describe how you will handle project changes. For example, who makes the go/no-go decisions, including changes in project scope or requirements? Add appropriate project management activities to your schedule.

 

Communication Management

Describe the system of communications and the project performance documentation that will be provided to the various stakeholders, i.e., what information will be provided for whom.

 

The purpose of this section is to outline the structure of your stakeholder interactions, whether by phone, e-mail, in person, or in formal reports. I’ve added a couple typical examples to the table: you need to add the rest If you are working with more than one person at your sponsor’s organization, you’ll want to specify who, either by name or by their job. Be sure to add appropriate project management activities to your schedule.

 

 

Stakeholder

Communication and format

Frequency

Sponsor

Progress reports: email

Weekly

Sponsor

Product reviews: in person

Scheduled

Sponsor

Questions/answers: email and cell phone

As needed

Instructor

Progress reports: email

Weekly

 

 

 

 

 

 

 


 

Project Schedule and Milestones

This section specifies the milestone and activity schedule of the project, integrating three key elements: deliverables, due date or duration, and critical dependencies. Your schedule will cover activities in two main areas:

Project: activities required to conduct the project. Activities like team meetings, sponsor review meetings, completing progress reports, etc. are in this category.

Product: activities to create your product. This includes all the things you will do to design, test, implement your product, train users, etc.

 

This section contains diagrams/charts as well as a text overview section.

 

In the text section, list and describe the key milestones that you must meet to succeed with your project. Each milestone should have an associated deliverable: the milestone is passed when the deliverable completion criteria is satisfied.  Include both project milestones (e.g., completion of your charter and this plan) and product deliverables (completion of your application analysis, design, build, test, and implementation phases). Key milestones/deliverables are the big ones, either because they have importance after the project is complete or because their completion is necessary to continue the project. You won’t list here every deliverable you will create, and you may have internal milestones as well, but do include in this table anything that someone looking for an overview of the project would want to know about. For example, completing your data model or a research report comparing the capabilities and costs of different ISP’s would not be listed as a key milestone, but should be included in your work breakdown structure and Gantt chart. These are deliverables leading up to the passing the Technology Review, which is a milestone that should be included here.

 

Be as clear as possible in defining your milestones and deliverables. Include completion criteria that specify how you will know each deliverable is really finished (e.g., passes testing, sign-off by sponsor—whatever is appropriate for the deliverable). Clear and obtainable deliverables set the direction of the project and eliminate confusion about what work is performed and what products/services are to be delivered. Completion Criteria gives you a way to control quality.

 

Use the comments column to identify any critical task or resource dependencies or concerns that may significantly impact your ability to adhere to the planned schedule (e.g., if the sponsor must provide certain IT resources or access to end-users in order for you to complete a task). This is the place to point out anything important that someone might overlook in your Gantt chart.

 

The template includes the usually-required project deliverables: if they do not apply to your project, delete them (but for this class, you’ll need to explain). You should add any other key milestones that are appropriate for your project, and replace all the “TBD’s” with actual dates. Pin these dates down: some of them are given to you as class assignments while some of them are up to you to figure out. Product deliverables are much more dependent on the particular project: I’ve included a few of the usual ones in the template, but you need to consider this list carefully to include what is appropriate for your project. The list here is definitely not comprehensive!

 

 

Product System Documentation – Appendices

 

The product system documentation should include the following but is not limited to:

 

- Requirements-detailed requirements for the application or database

- Functional Specification-a written summary of the product and how it satisfies the requirements

- Data Model

- Process documentation–define the technical and operation processes for the product

- Inputs/Outputs include forms or reports

- Logic Specification-the structure of logic and any specific calculations required to be preformed

 

All of these outputs must be signed off by your Project Sponsor

 


 

Key Milestones

Description

Completion Criteria

Date Due

Comments/Concerns

Key Project Deliverables

 

 

 

 

Team Agreement

Rules governing how the team will work

Agreed by team

draft: 6/12 final: 6/17

 

Charter

Written agreement defining what the project is and how success will be measured

Signed by team, sponsor and instructor

draft: 6/12

final: 6/21

 

Technology Review

External review of hardware, software and services choices

Signed by instructor

Final: 6/26

 

Project Plan

Complete specification of how the project will be accomplished

Accepted by instructor

draft: 6/19

working: 6/26

 

Product System Documentation

Signoff

All relevant documentation described “product system documentation” above

Accepted by the sponsor

Signoff for each to complete 8/6

 

Final Report

The final version of all documentation including agreement, project plan, system documentation, etc. and a summary and evaluation of how the project went

Turned in to instructor

8/6

 

Project Acceptance From

Written acceptance or refusal of the product

Signed by sponsor

8/6

 


 

Key Product Deliverables

 

 

 

 

 

 

 

 

 

Website (or database, etc.) –you should generally break this down into major sections or functions

The website or database itself.

Accepted by sponsor

8/2

 

User Manual

Documentation for end user on how to use the product

Accepted by sponsor

8/2

 

Implementation Guide

Documentation on how to install, change and maintain the product

Accepted by sponsor

8/2

 

Service or Enhancement Guide

Documentation for future support personnel on how to approach  enhancement and maintenance

Accepted by sponsor

8/2

 

 

Include your work breakdown structure and Gantt chart as an appendix to this document. In your initial project Gantt chart, identify and schedule -- in detail! -- all early project activities and resources related to analysis and design and -- more broadly -- later activities such as construction, testing, and installation. You will identify and schedule these later activities in detail as you develop a clearer sense of your project deliverables (i.e., after you have minutely defined system requirements). “In detail” means your work breakdown structure should specify work packages that will take you no more than 3 days to complete.

 

Your Gantt chart should include at least the following information: