Software Project Planning

“Weeks of programming can save you hours of planning.”

Introduction

• Planning is critical to project success.

• In one study of over 250 large projects, Capers Jones found a strong correlation between planning and project outcomes. Successful projects were always well-planned and failing projects nearly always had inadequate plans [Jones Crosstalk Oct 2004].

The reasons for planning a project are a lot like the reasons for planning a vacation.

• In both cases there is a limited amount of time and money. You can make the most of limited resources by planning ahead.

• You are likely to avoid many problems by thinking through them in advance of starting on your journey.

• There is no confusion about what to do each day—the plan provides optimal direction.

Vacation Analogy [cont]

• The plan serves as a baseline for tracking progress and controlling performance.– Tracking Progress: “Are we there yet?” “I don’t know, let me look

at the plan. No, we aren’t there yet, but according to the plan we will be there in 3 hours.”

– Controlling performance: On the third day you notice that you are consistently underachieving. Each day you are seeing on average half of what you planned to see. Some analysis of the problem reveals you are spending much more time than anticipated on meeting and coordinating individual activities. You decide to purchase walky-talkies so you can better coordinate activities.

• Detailed planning results in better estimates. The guide said “Europe on $100 a day,” but after detailed planning you conclude that for the kind of trip you have in mind it’s more like $300 a day.

Reasons for Planning a Project

• You can avoid problems and rework by thinking through your actions before performing them.

• Plans serve as a baseline for tracking progress and controlling performance. A project can’t be “on track” unless there is a plan with which to compare actual progress against.

• Detailed planning provides for more accurate bottom-up estimates.

• Planning and the schedules that come from planning establish commitments that others outside the project can use to make their own plans and commitments.

• A plan serves as roadmaps for completing the work of a project.• A plan is a tool for gaining visibility into a project.• Planning provides for more efficient and effective use of

resources.

Project Lifecycle

• The software development process is iterative and incremental

• Artifacts are progressively refined over a series of iterations

• Planning is divided between initial planning (step 4), release planning (step 5) and iteration planning (step 6).

• Product architecture shapes project planning.

Inputs and Outputs of Project Planning

Four main components of a project plan

• Not surprisingly, the four main components of the project plan are closely aligned with the four main variables of a project. A full project plan will have:– A budget for managing the cost component– A schedule for managing the time

component (most notably, delivery date).– A release plan for managing the scope of

the project.– A quality plan for managing product quality.

Release Plans and Iteration Plans

• On an iterative project, two kinds of plans are useful [Kruchten 2002]:– A release plan, one per project, which specifies

the timing of iterations and a rough allocation of product features to iterations.

– Iteration plans, one per iteration, which specify the detailed tasks for an iteration, and in some cases an assignment of tasks to individuals.

Release Plan compared to Iteration Plans

Internal and External Releases

• There are three important opportunities for feedback and control: during frequent integration, at the end of an iteration with an internal release and at the end of an iteration with an external release.

Predictive and Adaptive Planning

• There is a range of planning options available to the project manager from adaptive to predictive:

Adaptive Planning

• With adaptive planning, near-term work is planned in detail and work further out in the schedule is planned at a higher level of abstraction.

• Adaptive planning is the idea of progressive elaboration applied to project planning.

• Note that adaptive planning is not the same as doing little or no planning. With adaptive planning there are detailed plans; they just aren’t long-range. There are long-range plans; they just aren’t detailed.

Predictive Planning

• Predictive planning starts with a major upfront effort to understand product requirements. This knowledge is used to construct a detailed plan for implementing the product definition.

• Predictive planning is most effective when requirements are well-understood and stable.

• Changes are permissible and are handled according to formal change control procedures.

How much planning is enough?

Home ground for adaptive and predictive planning

Planning Horizon

• A project’s planning horizon is the distant into the future in which work items are well understood.

Finding the Right Balance

Some projects need more planning

Some are better off with less

Planning Process

Work Breakdown Structure (WBS)

• Creating a WBS is a systematic way of identifying the tasks needed to complete a project.

• It provides a hierarchical decomposition of the work.

• A WBS can be presented in graphical or outline form.

Widget Project1.0 Initiate2.0 Define Requirements 2.1 Gather Requirements 2.2 Analyze Requirements 2.3 Document Requirements3.0 Plan . . .

WBS Structure• There are two types of tasks:

– Summary, and

– Detailed elemental tasks (aka work packages)

• Summary tasks may be activities or deliverables. Summary tasks always have detailed subtasks.

• Detailed tasks are always the actual schedulable tasks. They are leaf nodes in the WBS hierarchy.

Widget Project1.0 Define Requirements 1.1 Gather Requirements 1.2 Analyze Requirements 1.3 Document Requirements2.0 Plan Project . . .

Widget Project1.0 Requirements Document 1.1 Gather Requirements 1.2 Analyze Requirements 1.3 Document Requirements2.0 Software Project Management Plan . . .

Work Packages• Information needed for each schedulable task or

work package:– Tasks description– Owner– Schedule start and stop date– Effort estimate– Expected output or deliverable (optionally with

completion/acceptance criteria)– Staff and material resources needed to complete the

task.

Task Dependencies

• Before you can schedule tasks you have to know the predecessor and successor relationships between tasks.

• The standard dependency between nodes in a network diagram is finish-to-start. That is, if there is a finish-to-start dependency from A to B, A must finish before B starts.

Network Diagram

Types of Dependencies

• Finish-to-Start - Task A must finish before task B can start. This is the most common type of dependency.

• Finish-to-Finish - Task A must finish before task B finishes. This is common with work that is largely sequential but can also benefit from feedback from downstream activities

• Start-to-Start - Task A can not start until task B starts. 

• Start-to-Finish - Task A must start before task B finishes. This dependency is rarely used.

Estimation

• Effort and duration estimates are made for each task.

• After scheduling, these estimates are rolled up (bottom-up estimation) into overall estimates for project cost and duration.

• There are several estimation techniques that may be used (analogy, algorithm models, expert opinion, etc.)

Effort vs. Duration

• Effort is the amount of labor required to complete a task, typically measured in terms of person months or person hours.

• Duration is the amount of calendar time or clock time needed to complete a project or task.

• Effort is used to measure resource usage and duration is used in scheduling.

Effort vs. Duration—Example

Cutting a tree with a two-person saw

Ironing a shirt

Effort = 10 minutes

Duration = 10 minutes

Cooking a turkey

Effort = 1 hour

Duration = 3 hours

Effort = 30 minutes

Duration = 15 minutes

Scheduling

• The Gantt chart is probably the most common tool for presenting schedule information. It shows start and and stop types for tasks in a visually recognizable calendar form. It also shows timing of milestones.

Critical Path Analysis and Float Time

• The critical path is the longest sequence of activities in the network diagram. A delay for any activity on the critical path will delay the project completion date.

• Free slack - the amount of time a task can slip without delaying another task.

• Total slack -the amount of time a task can slip without delaying the project completion date

Order of Events

• Is it better toAssign resources Estimate effort Schedule

OR

Estimate effort Schedule Assign resources

Resource Leveling

Documenting the Plan

• There is significant value in just planning

• Most projects will also need a written plan which documents the planning work done

• Software Project Management Plan (SPMP)

A comprehensive SPMP will address the following items:

1. Project goals and objectives

2. Major milestones and deliverables

3. Priorities and constraints

4. Work breakdown structure (WBS). The WBS fleshes out the detailed tasks that must be completed in order to accomplish the goals of the project.

5. Schedule which shows the timing of major milestones and deliverables. As much as possible, work should be planned in units of customer-visible functionality [Beck 2005]. The schedule should show timing of iterations and features planned for each iteration.

6. Estimates for cost, effort and duration.

7. Project budget. The budget shows expenditures over time.

8. Organizational structure including project roles, lines of authority and reporting relationships. The organizational structure may also include an initial assignment of people to roles.

9. Configuration Management Plan.

10. Risk Management Plan. The risk management plan identifies threats to project success and documents the planned actions for mitigating these threats.

11. Communication Plan - A project's communication plan states: (1) what information is collected and by whom, (2) to whom the information should flow and by what method, (3) a schedule for producing and disseminating the needed information.

12. Metrics collection plan

13. Status and progress reporting

Communications Planning

• During the course of a project people need information in order to do their job

• Communication planning is the process of…– Determining the information needs of each

stakeholder, and– Making sure the needed information is created

and delivered to the right people at the right time in the right format

Creating a Communication Plan

1. Determine the information and communication needs of each stakeholder

2. Determine the source of the needed information

3. Decide on the format and frequency of distribution

4. Create a plan for the free flow of information during the project

Determining the Information Needs of Stakeholders

• Standard stakeholder roles include: customer, users, project sponsor, project manager, developers, senior management, etc.

• Stakeholder information needs include: Summary project status, detailed project status, task assignments, solutions to technical problems, product quality, changes and updates to requirements/scope/plan, major risks and risk mitigation strategies, issues and problems, forecasts, lessons learned.

Example: Stakeholders and Their Information needs

Sources of Information

• Most information passes directly from one individual to another, but may also be stored for later use.

• Example information stores:– Issues database– Configuration management system– Process assets database

Format and Timing

• Format dimensions: formal / informal; written / verbal; push / pull.

• Example formats: email, memo, written report, casual conversation, meeting, telephone/conference call, white paper, presentation, web site, Wiki

• Example timings: weekly, monthly, on demand, project closeout.

Documenting the Communication Plan

• The communication plan states:– What information is collected and by whom– To whom the information should flow and by what

method– A schedule for producing and disseminating the needed

information

• The communication plan may also include guidelines and procedures for communications (e.g. guidelines for conducting an effective team meeting)

• Change control and issue tracking are typically described outside of the communication plan

Sample Communications Plan

Informal Spontaneous Communication

• Informal spontaneous communication is an important form of information exchange.

• Although, planned spontaneous communication might seem like a contradiction in terms, it is reasonable to make plans to foster (or at least not hamper) the opportunity for spontaneous communication [example from psychology of computer programming].

• Part of communications planning is taking steps to nurture the opportunity for informal spontaneous communication

Team Meetings

• Holding a regularly scheduled team meeting (weekly for most projects) is one of the best ways to keep everyone informed, identify problems, make decisions, build relationships and establish commitments.

• The basic agenda for a team meeting is to have each individual or group representative briefly present:– What was accomplished since the last meeting?

– What work is planned between now and the next meeting?

– What issues or problems are blocking progress?

• The team meeting isn’t the forum for solving problems. Problems are better handled in smaller groups outside of the team meeting

Configuration Management

• The freedom to change a document is more restricted after the document is baselined.

Change Control

Procedure

Timing

• The planning phase of the project life cycle comes after some portion of the product requirements are known

• The output of planning is a project plan which provides direction for the remainder of the technical development activities.

• The project plan sets a course of action for accomplishing the goals and objectives outlined in the project charter

Communication Planning

• During a project people need information in order to do their job

• Communication planning is about…– Determining the information needs of each

stakeholder, and– Creating a plan that ensures needed information

is delivered to the right people at the right time in the right format

Selecting a Methodology

• Just as the plans used to built most homes are adaptations from generic plans that fit within certain architecture styles, most software development plans are adaptations of generic plans that fit within a certain software development methodology.

• For example, a group might select to use Extreme Programming (XP) with formal inspections in place of pair programming.

New Slides

Progressive Elaboration

• The major artifacts and deliverables associated with a software project are rarely created and finalized in one step.

• More often they are conjured up in a primitive form and evolved over time to become more explicit and detailed.

• It’s generally easier to grow a complicated and complex artifact than it is to engineer one in a single step.

• created in a primitive ini• tend to evolve over time becoming more explicit and detailed over time as

more information becomes available. through a process of continuous refinement.

• Progressive elaboration describes the way that most major artifacts associated with a software projects are created and refined.

• is a characteristic of projects were by process by which there is an initial attempt at creating an artifact, followed by repeated cycles of incremental improvement.