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 outline 1.Problem statement a.Project background – summary of problem to solve b.Stakeholders – name, title or role c.Users d.Risks – factors that could impact or delay project e.Assumptions – generated by Wideband Delphi est.? 2.Vision of the solution a.Vision statement – what the project is expected to accomplish b.List of features – software that provides services or capabilities, usually ~10 will be listed here c.Scope of phased release – used when software is released in phases d.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 WBS 2.Estimate of the effort required for each task in the WBS 3.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