Chapter 23 – Project planning

10/12/2014 Chapter 23 Project Planning 1

Topics covered

 Software pricing
 Plan-driven development
 Project scheduling
 Agile planning
 Estimation techniques
 COCOMO cost modeling

10/12/2014 Chapter 23 Project Planning 2

Project planning

 Project planning involves breaking down the work into

parts and assign these to project team members,
anticipate problems that might arise and prepare
tentative solutions to those problems.
 The project plan, which is created at the start of a
project, is used to communicate how the work will be
done to the project team and customers, and to help
assess progress on the project.

10/12/2014 Chapter 23 Project Planning 3

Planning stages

 At the proposal stage, when you are bidding for a

contract to develop or provide a software system.
 During the project startup phase, when you have to plan
who will work on the project, how the project will be
broken down into increments, how resources will be
allocated across your company, etc.
 Periodically throughout the project, when you modify
your plan in the light of experience gained and
information from monitoring the progress of the work.

10/12/2014 Chapter 23 Project Planning 4

Microsoft Project Planning

10/12/2014 Chapter 23 Project Planning 5

Proposal planning

 Planning may be necessary with only outline software

requirements.
 The aim of planning at this stage is to provide
information that will be used in setting a price for the
system to customers.
 Project pricing involves estimating how much the
software will cost to develop, taking factors such as staff
costs, hardware costs, software costs, etc. into
account

10/12/2014 Chapter 23 Project Planning 6

Project startup planning

 At this stage, you know more about the system

requirements but do not have design or implementation
information
 Create a plan with enough detail to make decisions
about the project budget and staffing.
▪ This plan is the basis for project resource allocation
 The startup plan should also define project monitoring
mechanisms
 A startup plan is still needed for agile development to
allow resources to be allocated to the project

10/12/2014 Chapter 23 Project Planning 7

Development planning

 The project plan should be regularly amended as the

project progresses and you know more about the
software and its development
 The project schedule, cost-estimate and risks have to be
regularly revised

10/12/2014 Chapter 23 Project Planning 8

 Software pricing

10/12/2014 Chapter 23 Project Planning 9

Software pricing

 Estimates are made to discover the cost, to the

developer, of producing a software system.
▪ You take into account, hardware, software, travel, training and
effort costs.
 There is not a simple relationship between the
development cost and the price charged to the customer.
 Broader organisational, economic, political and business
considerations influence the price charged.

10/12/2014 Chapter 23 Project Planning 10

Factors affecting software pricing

Factor Description
Contractual terms A customer may be willing to allow the developer to retain
ownership of the source code and reuse it in other projects.
The price charged may then be less than if the software
source code is handed over to the customer.
Cost estimate If an organization is unsure of its cost estimate, it may
uncertainty increase its price by a contingency over and above its
normal profit.
Financial health Developers in financial difficulty may lower their price to
gain a contract. It is better to make a smaller than normal
profit or break even than to go out of business. Cash flow is
more important than profit in difficult economic times.

10/12/2014 Chapter 23 Project Planning 11

Factors affecting software pricing

Factor Description
Market opportunity A development organization may quote a low price
because it wishes to move into a new segment of the
software market. Accepting a low profit on one project may
give the organization the opportunity to make a greater
profit later. The experience gained may also help it develop
new products.
Requirements volatility If the requirements are likely to change, an organization
may lower its price to win a contract. After the contract is
awarded, high prices can be charged for changes to the
requirements.

10/12/2014 Chapter 23 Project Planning 12

Pricing strategies

 Under pricing
▪ A company may underprice a system in order to gain a contract
that allows them to retain staff for future opportunities
▪ A company may underprice a system to gain access to a new
market area
 Increased pricing
▪ The price may be increased when a buyer wishes a fixed-price
contract and so the seller increases the price to allow for
unexpected risks

10/12/2014 Chapter 23 Project Planning 13

Pricing to win

 The software is priced according to what the software

developer believes the buyer is willing to pay
 If this is less that the development costs, the software
functionality may be reduced accordingly with a view to
extra functionality being added in a later release
 Additional costs may be added as the requirements
change and these may be priced at a higher level to
make up the shortfall in the original price

10/12/2014 Chapter 23 Project Planning 14

 Plan-driven development

10/12/2014 Chapter 23 Project Planning 15

Plan-driven development

 Plan-driven or plan-based development is an approach

to software engineering where the development process
is planned in detail.
▪ Plan-driven development is based on engineering project
management techniques and is the ‘traditional’ way of managing
large software development projects.
 A project plan is created that records the work to be
done, who will do it, the development schedule and the
work products.
 Managers use the plan to support project decision
making and as a way of measuring progress.

10/12/2014 Chapter 23 Project Planning 16

Plan-driven development – pros and cons

 The arguments in favor of a plan-driven approach are

that early planning allows organizational issues
(availability of staff, other projects, etc.) to be closely
taken into account, and that potential problems and
dependencies are discovered before the project starts,
rather than once the project is underway.
 The principal argument against plan-driven development
is that many early decisions have to be revised because
of changes to the environment in which the software is to
be developed and used.

10/12/2014 Chapter 23 Project Planning 17

Project plans

 In a plan-driven development project, a project plan sets

out the resources available to the project, the work
breakdown and a schedule for carrying out the work.
 Plan sections
▪ Introduction
▪ Project organization
▪ Risk analysis
▪ Hardware and software resource requirements
▪ Work breakdown
▪ Project schedule
▪ Monitoring and reporting mechanisms
10/12/2014 Chapter 23 Project Planning 18
Project plan supplements

Plan Description
Configuration management plan Describes the configuration management procedures
and structures to be used.
Deployment plan Describes how the software and associated hardware
(if required) will be deployed in the customer’s
environment. This should include a plan for migrating
data from existing systems.
Maintenance plan Predicts the maintenance requirements, costs, and
effort.
Quality plan Describes the quality procedures and standards that
will be used in a project.
Validation plan Describes the approach, resources, and schedule used
for system validation.

10/12/2014 Chapter 23 Project Planning 19

The planning process

 Project planning is an iterative process that starts when

you create an initial project plan during the project
startup phase.
 Plan changes are inevitable.
▪ As more information about the system and the project team
becomes available during the project, you should regularly revise
the plan to reflect requirements, schedule and risk changes.
▪ Changing business goals also leads to changes in project plans.
As business goals change, this could affect all projects, which
may then have to be re-planned.

10/12/2014 Chapter 23 Project Planning 20

The project planning process

10/12/2014 Chapter 23 Project Planning 21

Planning assumptions

 You should make realistic rather than optimistic

assumptions when you are defining a project plan.
 Problems of some description always arise during a
project, and these lead to project delays.
 Your initial assumptions and scheduling should therefore
take unexpected problems into account.
 You should include contingency in your plan so that if
things go wrong, then your delivery schedule is not
seriously disrupted.

10/12/2014 Chapter 23 Project Planning 22

 Project scheduling

10/12/2014 Chapter 23 Project Planning 24

Project scheduling

 Project scheduling is the process of deciding how the

work in a project will be organized as separate tasks,
and when and how these tasks will be executed.
 You estimate the calendar time needed to complete each
task, the effort required and who will work on the tasks
that have been identified.
 You also have to estimate the resources needed to
complete each task, such as the disk space required on
a server, the time required on specialized hardware,
such as a simulator, and what the travel budget will be.

10/12/2014 Chapter 23 Project Planning 25

Project scheduling activities

 Split project into tasks and estimate time and resources

required to complete each task.
 Organize tasks concurrently to make optimal
use of workforce.
 Minimize task dependencies to avoid delays
caused by one task waiting for another to complete.
 Dependent on project managers intuition and
experience.

10/12/2014 Chapter 23 Project Planning 26

The project scheduling process

10/12/2014 Chapter 23 Project Planning 27

Schedule presentation

 Graphical notations are normally used to illustrate the

project schedule.
 These show the project breakdown into tasks. Tasks
should not be too small. They should take about a week
or two.
 Calendar-based
▪ Bar charts are the most commonly used representation for
project schedules. They show the schedule as activities or
resources against time.
 Activity networks
▪ Show task dependencies

10/12/2014 Chapter 23 Project Planning 29

Project activites

 Project activities (tasks) are the basic planning element.

Each activity has:
▪ a duration in calendar days or months,
▪ an effort estimate, which shows the number of person-days or
person-months to complete the work,
▪ a deadline by which the activity should be complete,
▪ a defined end-point, which might be a document, the holding of a
review meeting, the successful execution of all tests, etc.

10/12/2014 Chapter 23 Project Planning 30

Milestones and deliverables

 Milestones are points in the schedule against which you

can assess progress, for example, the handover of the
system for testing.
 Deliverables are work products that are delivered to the
customer, e.g. a requirements document for the system.

10/12/2014 Chapter 23 Project Planning 31

Tasks, durations, and dependencies

Task Effort (person- Duration (days) Dependencies

days)
T1 15 10
T2 8 15
T3 20 15 T1 (M1)
T4 5 10
T5 5 10 T2, T4 (M3)
T6 10 5 T1, T2 (M4)
T7 25 20 T1 (M1)
T8 75 25 T4 (M2)
T9 10 15 T3, T6 (M5)
T10 20 15 T7, T8 (M6)
T11 10 10 T9 (M7)
T12 20 10 T10, T11 (M8)
10/12/2014 Chapter 23 Project Planning 32
Activity bar chart

10/12/2014 Chapter 23 Project Planning 33

Staff allocation chart

10/12/2014 Chapter 23 Project Planning 34