Software Project Planning

Chapter 2

Applied Software Project Management, Stellman & Greene

Role of the project manager To motivate To ask for evidence of understanding To understand what the team needs To properly define the scope of the project To capture knowledge To see that the team agrees to the major

features of the software To gather consensus To talk to the major stakeholder

Vision and Scope Document

Should be circulated to everyone involved in the project Who is that?

Scope – the features that will be developed and the work that will be done

Vision – the goal of the software

Vision and scope document outline1. Problem statement

a. Project background – summary of problem to solveb. Stakeholders – name, title or rolec. Users d. Risks – factors that could impact or delay projecte. Assumptions – generated by Wideband Delphi est.?

2. Vision of the solutiona. Vision statement – what the project is expected to

accomplishb. List of features – software that provides services or

capabilities, usually ~10 will be listed herec. Scope of phased release – used when software is

released in phasesd. Features that will not be developed

Project Plan

Defines the work that will be done Usually consists of:

Statement of work Resource list Work breakdown structure Project schedule Risk plan

Statement of Work Detailed description of all work products

that will be created during the project Who is responsible for each? While the vision and scope talks about the

rationale for the project, the SOW is a list of the work products

SOW contains: List of features A description of the work products (deliverables):

about one paragraph, should list standards and templates used

The estimated effort for each work product

Resource List

A list that contains a description of each resource

The list shows: Resource name One line description Availability and cost

Estimates and project schedule Steps:

1. Define a WBS2. Estimate of the effort required for each task in

the WBS3. Create a project schedule by assigning

resources and determining the calendar time required for each task

The project plan should include a complete revision history of the WBS Tasks that have been added, changed or

removed and when

Risk Plan A risk plan is a list of all risks that

threaten the project and a plan to mitigate some or all of them

Predicting potential problems Brainstorm potential risks Estimate the impact of each risk – see p. 27 Make a mitigation plan: take actions to avoid

risks such as: Alter the project plan Add additional tasks Plan for risks – see Figure 2-1

Inspection Checklist Statement of work

Does project plan include SOW? Is SOW complete for all features? Are all work products represented? If estimates are known, are they included?

Resources Does project plan include a resource list? Does resource list contain all resources available to

project? Are some of those resources assigned to other projects? Are dates that resources will be unavailable known?

Inspection Checklist part 2 Project Schedule

Does project plan include a schedule? Are there missing or incorrect tasks? Does the schedule reflect all tasks defined in WBS? Does each task have a predecessor? Is a resource allocated to each task? Does the schedule contain periodic reviews?

Risk Plan Does project plan include a risk plan? Are there risks that are not in the plan? Is each risk prioritized correctly? Has the impact of each risk been estimated correctly? Have the risks been sufficiently mitigated?

Project Planning Problems Lack of leadership Mid-course corrections, additions, changes

There may be many reasons that changes are discovered late in the project; many are legitimate

A good vision and scope helps avoid this

A detached engineering team Missing link between users and builders Plan must include input of engineers estimates