Guide to Preparing the

SOFTWARE PROJECT MANAGEMENT PLAN

© R. Buckley
CSc 190 Senior Project
Department of Computer Science - College of Engineering and Computer Science
California State University, Sacramento
Version 11.10.2014

1. INTRODUCTION

This is the software system proposal document for the <name of the project> project sponsored
by <name of sponsor>.

This project is being undertaken by the <name of team> development team. The team is
comprised of undergraduate students majoring in Computer Science at California State
University, Sacramento. The team members are enrolled in a two-semester senior project course
required of all undergraduate majors. Successful delivery of the desired software product will
fulfill the senior project requirement for the student team members.

PROJECT SPONSOR (if there is more than one person serving as sponsor, list each sponsor):

Name
Title
Company or Organization name
Contact information (phone number and Email address)

<NAME OF TEAM> DEVELOPMENT TEAM

List of team member names

Team contact information (phone number and Email address)

The remainder of this section is intended to introduce the reader to the document and to serve as
a high level, executive-like summary to the document.

NOTE. Write this section last! In preparing the document, the project team may have a general
understanding of the purpose and scope of the document but one that is not sufficient to inform
the general reader. In most cases, it is best to leave this section to the very end, or at least
reserve final review and revision until a draft of the document has been completed.

1.1. Purpose

This subsection should describe the purpose of this document. Explain why this document is
being written and what the reader should expect, in general, to learn.

1.2. Scope

This subsection should describe what specifically is to be covered by the document and what is
not. The reader should be informed as to the context of the information being provided in the
document.
1.3. Definitions, Acronyms and Abbreviations

This subsection serves as a glossary for the document. All technical terms used as well as
all acronyms and abbreviations used should be arranged in alphabetical order. The
purpose of this subsection is to provide the reader with quick access to the definitions of
technical descriptors used throughout the document.

For example:

Baseline. A baseline is a work product that has been formally reviewed and accepted by
the involved parties. A baseline is changed only through formal configuration
management procedures.

Milestone. A scheduled event used to measure progress.

Project Deliverable. A work product that is delivered to the project sponsor.

Task. The smallest unit of work subject to management accountability.

1.4. References

This subsection serves the same purpose as a bibliography. If any documents were used
in the preparation of the document, the formal bibliographic information should be
specified here. A reference to a specific bibliographic entry should be made at the
location in the document where information from that specific source is used.

For example:

Steve McConnell, Software Project Survival Guide, Microsoft Press, 1998.

Ali Behforooz and Frederick J. Hudson, Software Engineering Fundamentals, Oxford

University Press, 1996.

P1058: Standard for Software Project Management Plans, Draft 2.1, Institute of
Electrical and Electronics Engineers, Inc., 1998.

1.5. Overview of Contents of Document

This subsection briefly describes each of the remaining sections in the document as well
as the contents of each appendix. The words used can be identical to those used to
introduce each of the sections and each appendix.

2. PROJECT OVERVIEW

This section contains a brief description of the project, the deliverables and the process
to be used in managing the project. In addition, an explanation is provided as to how the
team intends to manage the project. For example, what and how changes will be made.

Software Project Management Plan 2

 2.1. Project Summary

This subsection should contain an overview of the project, indicating the phases of
work that will take place and when this work will be scheduled into the various phases
of the software development. The purpose is to explain how and where the work and
the project’s various products fit into the development life cycle.

2.2. Project Deliverables

In this subsection, list all the items to be delivered to the sponsor. The items would
include, at a minimum, the Project Charter document, the Software Requirements
Specification Document and the Software User’s Manual. The copy of the software
along with copies of all the software development documentation and the project logs
will be included on a CD to be delivered at the time of delivery, the installation and
demonstration meeting with the sponsor at the conclusion of CSc 191. Additional items
may be identified by the team’s sponsor and/or faculty adviser. If this is the case,
include in this section what additional items would be considered as deliverables.

2.3. The Management Plan and the Planning Process

This subsection should specify how this baseline plan will be used and how it will be
updated over the course of the project. From day one, a regular and consistent
review of progress should be done on a weekly basis. At the start of CSc 190, the
work is concentrated on establishing a working relationship with the sponsor,
developing the team’s management plan and the process to be used for weekly
reviews and updates of the work required.

This initial management plan contains estimates for start and finish of each phase
of work. This applies to the preparation of the Project Charter through to the final
delivery and installation of the software. The start and end times for each phase are
estimates that will be reviewed by the team on a weekly basis and modified if
necessary as part of the project team’s ongoing project management process.

Software Project Management Plan 3

3. PROJECT ORGANIZATION

The section includes an explanation of the phases of work that will be scheduled, monitored and
managed throughout the project’s development life cycle. Also included is a description of the
team’s planned organizational structure for both CSc 190 and CSc 191. Individual team member
assignments and responsibilities will be also described.

3.1. Process Model

This subsection should specify the process model to be followed by the team throughout
the CSc 190 and CSc 191 development life cycle. An explanation should be provided
that identifies the flow of information and work products between the major project
phases and the supporting processes. Most senior projects use a form of the process
model represented in Figure 1. The activities and supporting processes are represented
by the rectangles. The directed line segments represent the flow of information and work
products from one activity and supporting process to another. The Management Plan
provides for the monitoring and control of the work required in all phases of the project.

NOTE. If a different process model is to be used, the team will need approval from their
faculty adviser.

3.2. Organizational Structure and Interfaces

This subsection should discuss the project team’s organizational structure. The project
manager should be identified along with a description of the project manager’s roles and
responsibilities. The team members should also be identified and their roles clearly
identified. In addition, the team’s faculty adviser should be identified along with the role
and responsibility assumed by the adviser.

Finally, the administrative and managerial boundaries between the project, the sponsor
and the sponsor’s organization should be described.

3.3. Project Responsibilities

This subsection should identify each major phase of work and activities associated with
the phase and identify one or more of the individuals whose job it will be to provide the
management and oversight necessary for the successful completion of the phase and the
approval of its deliverable product. Included should be initial assignments of team
“leads” for various phases of work along with a list of responsibilities.

4. PROJECT MANAGEMENT AND CONTROL

This subsection should include answers to the following:

 How will the plan be kept current?

 How will the project be managed?
 How will progress be measured?
 How will schedules be monitored and adjusted as needed?

Software Project Management Plan 4

  What specific methodology will be used for software development and why?
 How will verification and validation be conducted?

Indicate in this subsection how the project team intends 1) to validate that the requirements
satisfy the sponsor’s need, and 2) to verify that the product designed conforms to the
requirement specifications. Samples of any forms to be used by the team should be
referenced in the appropriate subsection with copies of the forms provided as appendices.
The intentions described above will change over the course of the project and should
be well documented.

Also provided in this section the procedure the project team will follow in delivering
the software to the sponsor. Describe specifically the plan for delivery, installation and
acceptance of the product.

Figure 1. Senior Project Process Model

Project Charter Architectural

Interaction Design
Design Prototypes
Mgt
Plan

Req’t Design Baseline User

Spec Spec Code Manual

System Test Plan Prepare

& Test Specs Delivery CD
Interaction CSc 190
Design
Sketches
Testing &
SPONSOR MTG Test Report SPONSOR MTG:
Sign-off on Baseline Delivery and Sign-off
Req’ts

CSc 191

4.1 Project Management Objectives and Priorities.

This subsection describes the team’s plan; that is, how the team views of their goals, the
objectives needed to achieve this goal, and team’s priorities as they relate to the various
management activities that must be carried out throughout the development life cycle in
order to achieve their goal. The activities will include at least the frequency and
mechanisms for reporting project status, the structure and scheduling of meetings, the
agendas and minutes of all meetings between team members, the team and the project
sponsor, and the team and the faculty project adviser. Included in this section should be a
description of the Project Log and its planned use in providing an “audit trail” for all
decisions made by the team throughout the project.

Software Project Management Plan 5

 4.2 Assumptions, Dependencies, and Constraints

This subsection should clearly specify the assumptions upon which the project is based,
the external events the project is dependent upon, and the constraints under which the
project will be conducted. Included may be a copy of the assumptions, dependencies and
constraints cited in the Project Charter document.

Failure to clearly articulate the assumptions being made by the team can impact their
ability to successfully deliver the right software to their sponsor. In addition, if the
project's success is dependent upon certain events taking place, these events should be
clearly specified. For example, commitments made by the sponsor should be fully
explained. Finally, there may be certain constraints that limit the way in which the
development is to proceed. Typically, such constraints appear in the form of time
constraints or technical constraints, each of which could be imposed on the development
team.

4.3. Risk Management

Software development risk is the potential occurrence of an event that would be

detrimental to the software development process, its plans and/or its products. Risk
management is an organized way

 To identify each potential risk

 To prioritize the risk according to its likelihood of occurrence and its impact on
the project
 To identify ways to avoid the risk
 To mitigate its impact by identifying alternatives or corrective actions that will be
taken in the event the undesirable event does occur

Risk management is necessary throughout the project. Currently identified risks may
become less likely, while new risks may emerge and need to be managed. Consequently,
the team’s list of risks should change throughout the project.

In addition to the describing the risk management process that the team will implement,
the team should also include a list of immediate, relatively high priority risks facing the
team and their project. The description should include the nature of each risk, the impact
on the project if the risk event would occur, what the team plans to do in order to prevent
the risk event from occurring, and what the team intends to do if the risk does occur.

4.4. Change Management

Changes will be required throughout the development. Changes to requirements, design,

testing and schedules are unavoidable. The project must have a formal means for
identifying each change request, determining the impact of the change and deciding on
how to respond. In this subsection identify how the team will manage and control such
changes as well as the role of the team, the sponsor and the team’s faculty advisor in
recommending and approving changes. For changes that apply to already approved
baseline specifications, reference should be made to the manner in which these changes
will be documented and accounted for in the Project Log.

Software Project Management Plan 6

 This section should reference the Project Charter which should contain the agreed
upon negotiation process that will be required to deal with changes requested by the
project sponsor.

4.5. Schedule Control

This subsection should explain how the team intends to monitor progress against the
baseline schedule. As the project nears completion, estimates become more accurate.
For that matter, as the team works through the development life cycle, estimates should
also improve as the team becomes more comfortable and efficient in their working
together.

This monitoring and updating of the project’s schedule and projected work plan is
essential. Each phase of the project is made up of a number of tasks. Some of these can
be worked on and completed concurrently, while others may need to be scheduled in a
specified sequence. In order to monitor the work, each of these tasks should be clearly
specified and assigned to one or more project members. The task must also produce a
tangible product. The plan must contain an estimate of the time needed to complete each
phase and its associated product. Then, monitoring involves checking progress against
the schedule, where progress is associated with producing the tangible product associated
with each phase.

NOTE. The baseline schedule is the initial estimate (guess) at how the major phases
of work will be accomplished over the life of the project. Changes occur as the team
modifies the work schedule to be consistent with the expected progress.

4.6. Issue Resolution

During the course of the project many issues will arise. Each must be addressed in a
timely manner to ensure that development can proceed. A plan for resolving these issues
should be described in this subsection. Issues may arise in the course of a meeting with
the team’s sponsor or during the Technical Review of one of the deliverables. Typically,
the particular issue cannot be immediately answered. A form to record the issue should
be devised and the manner in which the form is used to resolve the issue should be
specified (with a reference to a copy included as an appendix).

Software Project Management Plan 7

5. TECHNICAL PROCESS

This section includes a description of the methods the team will use in representing the
technical details that will need to be recorded and published during project development. In
addition, the team’s documentation plan is described along with a list of all documents to be
produced over the development life cycle. In addition, this section should describe how
documents will be collaboratively modified and the version control process that will be
used. In addition, this section should describe coding standards that will be used and
the manner in which technical work will be reviewed and approved.

5.1 Methods, Tools, and Techniques

Typical senior project uses the UML model and the set of diagrams* to represent various
aspects of the software system to be developed. For example, the requirement
specifications are represented with a set of Use Cases and their associated specifications.
In addition, the informational requirements of the system are represented with an
information model depicted as an Entity Relationship Diagram (ERD).

If the team has identified and plans to use specific methods, tools and techniques, they
should be described in this section. This would include development methodologies,
programming languages and other notations, and whatever tools and techniques will be
used to specify, design, build, test, integrate, document and deliver the project’s work
products.
* http://www-306.ibm.com/software/awdtools/developer/rose/index.html

5.2 Software Documentation

Documentation is an essential communication medium to be used during the software

development process. For most of the development time is will be the only manifestation
of the product that is visible. As such, the development life cycle is, in effect, document
driven. Each phase involves the completion of technical work that must then be formally
reviewed and published in document form.

This subsection should specify the project team’s documentation plan, that is, the team’s
approach to preparing the various documents over the course of the project. For each
phase indicate the key milestones necessary prior to the establishing that phase’s baseline
document. Milestones might include 1) verification of the technical work, 2) completion
of the first draft of the document, 3) review, revision and approval of the draft through
formal technical reviews, and 4) submittal of the team’s approved draft to the team’s
faculty adviser. The final milestone for the phase would be the approval of the document
establishing it as the baseline version. In addition, this section should describe the way in
which the team intends to ensure quality assurance through its own internal review and
revision process, as referred to above in item 3).

5.3 Documents

This subsection should contain a list of all the documents to be produced over the
development life cycle and a brief description of the content and purpose of each. In

Software Project Management Plan 8

 addition, the estimated delivery dates should be specific. Team member “leads” should
be assigned along with a description of their responsibilities. NOTE. Subsection 2.2
refers to only the deliverables that need approval by the project sponsor.

6 ACTIVITIES AND SCHEDULE

This section contains a description of the activities and tasks to be performed in each of the
development phases, the resources required to accomplish the work, an estimated (and
hypothetical) budget, and the baseline schedule for the project.

6.2 Activities and Tasks

This subsection at the completion of the project would contain the Work Breakdown
Structure (WBS) for each phase of the project. Initially, the only WBS that would be
included in this section would be that of the phase that produces the requirements
specification document. As each subsequent phase is begun, a baseline WBS should be
developed by the team and included as a “change” to the Project Management Plan.

For each phase, first list in outline form the phase associated with each of the major
deliverables that must be produced. Then the phase can be broken down into a number of
activities. Having committed to completion dates for the Software Requirements
Specification (the end of CSc 190) and for delivery, installation and acceptance by the
sponsor of the product (the end of CSc 191), scheduling these activities should be done
from “right to left”. That is, the team should work from the completion date backwards,
assigning start and end times for each activity to completed in order to complete that
phase of work as scheduled. Each activity should have duration of one week (or at most
two weeks). Completion of the activity should be demonstrated by the “delivery” of a
tangible product. Team members should be assigned to activities, as appropriate.
Preparation, oversight and updating of the WBS should be the focus of each week’s team
management meeting.

The team’s staff training plan should also be included in the WBS. The training schedule
should include the types of training needed, the team members involved, entry and exit
criteria for the training, the training method, and the schedules for the training during the
development life cycle.

6.3 Schedule

The subsection should contain the baseline schedule of the project’s development phases
and the corresponding Gantt chart. The schedule should be identical to that which was
provided in the Project Overview Specification document. Once the Project Management
Plan has been approved and established as a baseline, this schedule will be used to track
progress. Adjustments to the baseline project schedule will be made as required.

Software Project Management Plan 9

 6.4 Resource Requirements

This section should be used to specify whatever specific resources might be needed
during the course of the project. Included should be an explanation of how budgeted
items (those that are not hypothetical estimates) that were provided in the Project
Charter document will be provided.

7. Document approval page.

The introduction to this section should indicate what specifically is being agreed to. The
approval page should be used to indicate approval of and agreement to the management
process to be used over the course of the development life cycle.

The signatories should include each member of the project team and the project team’s
faculty adviser. This would include for each the name and responsibility for each of the
signatories.

Software Project Management Plan 10