BAIT3153 Software and Project Management (SPM)

Chapter 2
Project Planning, Control and Process Models
Selection

1
Table of Contents
2.1 Introduction
2.2 Project Planning and Estimation
2.3 Project Monitoring and Control
2.3.1 Tracking the Schedule
2.3.2 Cost Monitoring
2.3.3 Earned Value Analysis
2.4 Selection of Process Models

2
2.1 Introduction
• Software project management begins with a set of activities that are
collectively called project planning.
• Before the project can begin, the software team should estimate
 the work to be done,
 the resources that will be required, and
 the time required from start to finish
• Once these activities are accomplished, the team should establish a
project schedule that
o Defines the software engineering tasks and milestones,
o Identifies who is responsible for conducting each task, and
o Specifies the inter-task dependencies

3
2.2 Project Planning and Estimation
2.2.1 Project Planning
2.2.2 Estimations in Projects

4
 Project Management Process Group and Knowledge Area Mapping
Initiating Planning Executing M&C Closing
Integration Develop Project Develop PM Plan Direct & Manage Project Work • M&C Project Work Close Project or Phase
Charter • Perform Integrated Change Control

Scope • Plan Scope Management • Validate Scope

• Collect Requirements • Control Scope
• Define Scope
• Create WBS
Time • Plan Schedule Management Control Schedule
• Define Activities
• Sequence Activities
• Estimate Activity Resources
• Estimate Activity Durations
• Develop Schedule
Cost • Plan Cost Management Control Costs
• Estimate Costs
• Determine Budget
Quality Plan Quality Management Perform Quality Assurance Control Quality

HR Plan HR Management • Acquire Project Team

• Develop Project Team
• Manage Project Team
Communications Plan Communications Management Manage Communications Control Communications

Risk • Plan Risk Management Control risks

• Identify Risks
• Perform Qualitative Risk Analysis
• Perform Quantitative Risk Analysis
• Plan Risk Responses
Procurement Plan Procurement Management Conduct Procurements Control Procurements Close Procurements

Stakeholder Identify Stakeholders Plan Stakeholder Management Manage Stakeholder Expectation Control Stakeholder Engagement
5
2.1.1 Project Planning
0. Select project
1. Identify project scope 2. Identify project
and objectives infrastructure
3. Analyze project
characteristics

4. Identify the products

and activities

5. Estimate effort for

each activity
For each
activity
6. Identify activity risks
10. Lower-level
planning
7. Allocate resources

9. Execute plan 8. Review/ publicize

plan
Steps in Project Planning
6
 2.1.1 Project Planning
Project Plan Contents
a. Introduction
b. Background: including reference to the business case
c. Project objectives
d. Constraints – these could be included with project objectives
e. Methods
f. Project products: both deliverable products that the client will receive and
intermediate products
g. Activities to be carried out
h. Resources to be used
i. Risks to the project
j. Management of the project, including
 Organizational responsibilities
 Management of quality
 Configuration management
7
 2.1.1 Project Planning
Stakeholders
• People who have a stake or interest in the project.
• Can be categorized as:
o Internal to the project team – i.e., they will be under the direct managerial
control of the project leader
o External to the project team but within the same organization. E.g., the project
leader might need the assistance of the users to carry out system testing
o External to both the project team and the organization. E.g., customers (or
users) who will benefit from the system that the project implements;
contractors who will carry out work for the project.
• Different types of stakeholders may have different objectives. Thus, the
project leader must recognize these different interests and to be able to
reconcile them.

8
 2.1.1 Project Planning
Setting Project Objectives
• Among the stakeholders are those who actually own the project and
control the financing of the project. Hence, they also set the objectives
of the project.
• The objectives should define what the project team must achieve for
project success.
• Objectives focus on the desired outcomes of the project rather than the
tasks within it – they are the post-conditions of the project.

9
 2.1.1 Project Planning
Sub-objectives and Goals
• In order to achieve the objective we must achieve certain goals or sub-
objectives first.
o i.e., the sub-objectives or goals are steps on the way to achieve an objective.
• An effective objective for an individual must be something that is within
the control of that individual.
• e.g., an appropriate goal or sub-objective for software developers would be to
keep development costs within a certain budget.

10
 2.1.1 Project Planning
SMART
Well-defined objectives should be:
• Specific – effective objectives are concrete and well-defined. Objectives should be
defined so that it is obvious to all whether the project has been successful.
• Measurable – there should be measures of effectiveness which tell us how
successful the project has been.
• Achievable – it must be within the power of the individual or group to achieve the
objective.
• Relevant – the objective must be relevant to the true purpose of the project.
• Time constrained – there should be a defined point in time by which the
objective should have been achieved.

11
 2.1.1 Project Planning

Gantt Chart
• A time-line chart where all project tasks are listed in the left-hand
column and the horizontal bars indicate the duration of each task.
• When multiple bars occur at the same time on the calendar, task
concurrency is implied.
• The diamonds indicate milestones.
• Produces project tables (i.e. a tabular listing of all project tasks, their
planned and actual start and end dates) which enable you to track
progress.

12
 2.1.1 Project Planning
Project Table

13
 2.1.1 Project Planning
Gantt Chart

14
 2.1.1 Project Planning

Program evaluation and review technique (PERT)

• Also known as network diagram.
• Developed to take account of the uncertainty surrounding estimates
of task durations.

15
 2.1.1 Project Planning

PERT Step 1: Identify specific activities and milestones

16
 2.1.1 Project Planning

PERT Step 2: Determine the sequence of activities

17
 2.1.1 Project Planning

PERT Step 3: Estimate the time for each activity

• Typically uses the 3-time estimates:
o Optimistic time (O): the shortest time in which the activity can be
completed
o Most likely time (ML): the completion time that has the highest
probability
o Pessimistic time (P): the longest time in which the activity can be
completed.
• Then, calculate the expected time using the weighted average formula.
te = (O + 4ML + P) / 6

18
 2.1.1 Project Planning

PERT Step 3: Estimate the time for each activity (cont’d)

19
 2.1.1 Project Planning

PERT Step 4: Construct a network diagram

• You can represent both sequential and parallel activities in the diagram.
• Each activity represents a node; arrows to show relationships between
activities.

20
 2.1.1 Project Planning
PERT Step 5: Identify the critical path
• The critical path includes the total amount of time necessary to complete the project (add
the times for the activities and determining the longest path).
• The total project time does not change if activities outside the critical path speed up or
slow down.

21
A PERT chart illustrates a project as a network diagram

22
2.1.2 Estimations in Projects
• Estimation of resources, cost and schedule for a software project
requires experience, access to good historical information (metrics),
and quantitative predictions.
• Estimation carries inherent risks, and this risk leads to uncertainty.
• Factors that effect the uncertainty in planning include:
o Project complexity
o Project size
o Degree of structural uncertainty (i.e. the degree to which requirements have
been solidified, the ease with which functions can be compartmentalized, and
the hierarchical nature of the information that must be processed)

23
2.1.2 Estimations in Projects
To achieve reliable cost and effort estimates,
• Delay estimation until late in the project
• Base estimates on similar projects that have already been completed
• Use relatively simple decomposition techniques to generate project
cost and effort estimates
• Use one or more empirical models for software cost and effort
estimation

24
2.1.2 Estimations in Projects
2.1 Project Planning and Estimation

Three-point Estimates
1. Simple Average
 (P+O+ML)/3
 Triangular distribution
2. Weighted Average
 (P+O+4ML)/6
 Beta distribution

25
2.1.2 Estimations in Projects
2.1 Project Planning and Estimation

Most Triangular Beta

Activity Optimistic Pessimistic
Likely Distribution Distribution
A 2 6 4 4 4
B 4 12 8 8 8
C 4 10 7 7 7
D 10 22 16 16 16
E 8 18 13 13 13
F 6 16 11 11 11
G 16 26 22 22 22
H 6 12 10 10 10

Always
round UP

26
2.2 Project Monitoring and Control
2.2.1 Tracking the Schedule
2.2.2 Project Control - Corrective Actions
2.2.2 Cost Monitoring
2.2.3 Earned Value Analysis

27
 Project Management Process Group and Knowledge Area Mapping
Initiating Planning Executing M&C Closing
Integration Develop Project Develop PM Plan Direct & Manage Project Work • M&C Project Work Close Project or Phase
Charter • Perform Integrated Change Control

Scope • Plan Scope Management • Validate Scope

• Collect Requirements • Control Scope
• Define Scope
• Create WBS
Time • Plan Schedule Management Control Schedule
• Define Activities
• Sequence Activities
• Estimate Activity Resources
• Estimate Activity Durations
• Develop Schedule
Cost • Plan Cost Management Control Costs
• Estimate Costs
• Determine Budget
Quality Plan Quality Management Perform Quality Assurance Control Quality

HR Plan HR Management • Acquire Project Team

• Develop Project Team
• Manage Project Team
Communications Plan Communications Management Manage Communications Control Communications

Risk • Plan Risk Management Control risks

• Identify Risks
• Perform Qualitative Risk Analysis
• Perform Quantitative Risk Analysis
• Plan Risk Responses
Procurement Plan Procurement Management Conduct Procurements Control Procurements Close Procurements

Stakeholder Identify Stakeholders Plan Stakeholder Management Manage Stakeholder Expectation Control Stakeholder Engagement 28
2.2.1 Tracking the Schedule
• The project schedule becomes a road map that defines the tasks and
milestones to be tracked and controlled as the project proceeds.
• Tracking can be accomplished in a number of different ways:
• Conducting periodic project status meetings in which each team member
reports progress and problems
• Evaluating the results of all reviews conducted throughout the software
engineering process
• Determining whether formal project milestones have been accomplished by
the scheduled date
• Comparing the actual start date to the planned start date for each project
task listed in the project table
• Meeting informally with practitioners to obtain their subjective assessment of
progress to date and problems on the horizon
• Using earned value analysis to assess progress quantitatively

29
2.2.2 Project Control - Corrective Actions
• Project manager needs to monitor the progress of the projects in terms of the
time, cost and quality (triple constraints)
• Control is more than monitoring and finding out problems, needs corrective
actions whenever and wherever needed.

30
2.2.2 Project Control - Corrective Action
a. Adding more staff
b. Adding different skills
c. Reassigning tasks
d. Increasing/decreasing individual supervision
e. Improving methods of working
f. Streamlining the process
g. Changing resource priorities
h. Re-planning the project
i. Changing the phasing of deliverables
j. Increasing/decreasing the number of inspection
k. Encouraging the team
l. Introducing incentives
m. Subcontracting part of the work
n. Negotiating changes in the specification
31
2.2.2 a. Adding more staff

• One of the possibilities when behind schedule

• Will work if task can be partitioned
• Need to consider learning curve, time to get-up to speed on work,
need for communication, etc. – affects overall productivity
• Sometimes, adding additional staff further delay the task

32
2.2.2 b. Adding different skills

• An alternative to adding more staff, consider adding people with

different or greater skills
• When problems need skill/knowledge or staff lack experience
• Adding experienced or skilled staff to a team may yield results

33
2.2.2 c. Reassigning Task

• Without needing to add staff or skills

• May get better productivity or better quality work by switching tasks
around as each has different strength
• Some are creative, some are thorough, while some are analytical
• Can make use of the knowledge of characteristics of the team
members to assign tasks that will make use of their strength

34
2.2.2 d. Increasing individual supervision

• Problems with the work of members are known only when they
deliver products
• Partitioning tasks and creating smaller deliverables to exercise quality
control more frequently
• Enable inexperienced/ less confident staff to obtain guidance

35
2.2.2 e. Decreasing individual supervision

• Opposite when dealing with experienced staff who may resent too
frequent check up
• May affect personal interest and affect the work quality
• Giving individual responsibility and increase job interest and
motivation for larger deliverables
• Reduces work of supervision and re-channel resourceful focus

36
2.2.2 f. Improving methods of working

• Besides the work itself, need to consider the suitability of methods for
the tasks
• E.g. using Joint Application Development (JAD) approach to reconcile
what seemed to be mutually exclusive requirements between
different users, staging workshop where all users can come together
to thrash out the differences during analysis stage
• Using 4th GL to obtain users interface requirements

37
2.2.2 g. Streamlining the process

• Some tasks like quality control may be bureaucratic and time-

consuming
• Will be aggravated if the procedures or processes are vague
• Streamline them by removing unnecessary activities and using
standardized forms and process

38
2.2.2 h. Changing resource priorities

• Access to some important resources may be limited and created

bottlenecks
• Need to negotiate for better access or find alternative
environment/facilities in which work can proceed
• Examine project critical path to relocate the priorities of access

39
2.2.2 i. Re-planning the project

• Problems evaluation may show some fundamental flaws in the way

project has been planned
• Although embarrassing, it is critical, project manager has to rework
the plan
• Some tasks dependencies become clear after the work has started
• Need to note while new plans remove problems of old plan may
introduce new risks
• A re-appraisal of the risks should be part of the re-planning process

40
2.2.2 j. Changing the phasing of deliverables

• Short of a complete revision of plan, it may prove effective by

changing the phasing of the deliverables
• Planning may show as one end-product but analysis may reveal that
the product can be partitioned into several discrete elements
• Some discrete elements may have higher priorities and may be
possible to consider phased delivery to concentrate on more urgent
requirements
• May also consider parallel working e.g. design overlap with analysis
• May introduce new risks and proper appraisal is needed

41
2.2.2 k. Decreasing the number of inspections

• Only if inspections (assessment) are uncovering an acceptably low no.

of defects
• Else problems will arise later and doesn’t result in any positive effects

42
2.2.2 l. Increasing the number of inspections

• For critical systems and if intermediate deliverables are less

satisfactory
• Or there is a high level of defects on completed deliverables
• To ensure errors are discovered earlier and rectified more quickly
• May delay the project when no. of inspections increases

43
2.2.2 m. Encouraging the team

• Project fatigue may arise = lower productivity, increased absenteeism,

resignations, complaints, etc.
• Actions may include:
• refocusing on team’s achievements to rekindle enthusiasm
• organizing social events in company time to engender a sense of team spirit
• redistribution of work to provide development opportunities
• a team building exercise of some sort
• reducing the size of deliverables (at the end may be larger!)

44
2.2.2 n. Introducing incentives

• Depending on the organization, the project manager may or may not

be able to offer financial incentives
• But incentives may be in other form, e.g. time off, recognition, etc.
• For multiple team, inter-team competition may be considered but
practiced with care

45
2.2.2 o. Subcontracting part of the work

• Despite all the tools and techniques, project may still not on schedule
• Project manager may consider sub-contracting out the tasks to those
with special skills/ facilities
• But responsibility will still be with the PM
• Must make sure the contractors work to the required standards

46
2.2.2 p. Negotiating changes in the
specification
• When all else fail, may negotiate to change the specification
• It may be original objective is too ambitious for the time or money
• Alternatively may resort to phased delivery with major functions
being delivered first
• Not usually well received but better than to fail the project totally

47
2.2.3 Cost Monitoring
• Cost/expenditure monitoring provides an indication of the effort that
has gone into (or at least been charged to) a project.
• A project might be on time but only because more money has been
spent on activities than original budgeted.
• A cumulative expenditure chart provides a simple method of
comparing actual and planned cost.
o By itself it is not particularly meaningful, e.g. the expenditure chart could
illustrate a project that is running late or one that is on time but has shown
substantial cost savings.
o Thus, we need to take into account the current status of the project activities
before attempting to interpret the meaning of recorded expenditure.

48
2.2.3 Cost Monitoring

49
2.2.4 Earned Value Analysis
• Earned value analysis is a refinement of cost monitoring.
• It is based on assigning a value to each task (as identified in the WBS)
based on the original expenditure forecasts.
o i.e., it is the equivalent of the price agreed upon by a contractor to do the unit
of work.
• The total value credited to a project at any point is known as the
earned value (EV) and this can be represented as a money value,
amount of staff time or as a percentage of the PV.
• A task that has not started is assigned an earned value of zero, and
when it has been completed, it (and hence the project) is credited
with the original planned value (PV) of the task.

50
 2.2.4 Earned Value Analysis
Techniques for Crediting Earned Value to the Project
• 0/100 technique: a task is assigned a value of 0 until it is completed, at
which it is given a value of 100% of the budgeted value.
• 50/50 technique: a task is assigned a value of 50% of its value as soon as
it is started and then given a value of 100% once it’s completed.
• 75/25 technique: a task is assigned a value of 75% of its value as soon as
it is started and then given a value of 25% once it’s completed.
• milestone technique: a task is given a value based on the achievement
of milestones that have been assigned values as part of the original
budget plan.
• % complete: the EV is based on the % of the project that has been
completed.
51
 2.2.4 Earned Value Analysis
Step 1: Create the baseline budget
• The baseline budget
(i.e. planned value, PV)
is created based on the
project plan.
• Shows the forecast
growth in earned value
through time.
• May be measured in
monetary values or
person-hours (or
workdays).
• This example uses the
0/100 technique for
crediting EV to the
project.

52
 2.2.4 Earned Value Analysis
Step 2: Monitor the earned value
• Having created the baseline budget, the next task is to monitor earned value
(EV) as the project progresses.
• This is done by monitoring the completion of tasks (or activity starts and
milestone achievements in the case of other crediting techniques).
• In addition, the actual cost (AC) of each task is also recorded.
Earned Value Management (EVM) – Basic Metrics
 Planned Value (PV): Estimated value of the work
planned to be done
 Earned Value (EV): Estimated value of the work
actually completed
 Actual Cost (AC): Actual cost incurred for the work
completed
 Budget at Completion (BAC): Total project effort
budget

53
 2.2.4 Earned Value Analysis
Step 3: Compute Performance Statistics

Earned Value Management (EVM) Variances

Schedule Variance (SV) = EV – PV (negative indicates behind schedule)
Cost Variance (CV) = EV – AC (negative indicates cost is exceeded)
Variance at Completion (VAC) = BAC – EAC
54
 2.2.4 Earned Value Analysis
EVM Forecasting

Earned Value Management (EVM) - Forecasting

Estimate At Completion (EAC) – current expectation on the total project cost
EAC = AC + ETC  used when the original assumptions are fundamentally flawed
EAC = AC + BAC – EV  used when current variances are typical
EAC = AC + (BAC-EV)/CPI  used when current variances are typical
55
Deliverable Estimated Duration Estimated Status
(month) Cost ($)
A 2 70,000 100%
B 3 27,000 85% Exercise
C 1.5 82,000 62%
D 2.5 25,000 48%
E 2 30,000 23%
You are now in the 9th month of
F 0.5 48,000 16%
29 months project. As of today,
G 1.5 100,000 0
you have spent RM198.000
H 2 10,000 0
based on the invoices
I 1 45,000 0
reconciliation. You need to
J 2.5 17,000 0
provide data to Mr. Jordon
K 3 32,000 0
(Project Sponsor), specifying if
L 1.5 12,000 0
you are making a profit or loss in
M 2 10,000 0
the Project. You are using EVM
N 3 24,000 0
technique to provide the
O 1 12,000 0
sponsor with this information.
Total 29 544,000 0
56
2.3 Project Process Model Selection
Models Budget User Man power User Development Project scope
Requirement Time
Waterfall High Well defined Many staffs Less involved Long Large-scale
system
Prototyping Limit Uncertain Few staffs Highly involved Flexible Small to medium

Rapid Application High Well defined RAD teams to Highly involved 3 months System that can
Development tackle component be partitioned/
(RAD) componentized
Incremental Low Well defined Lack of staff Highly involved Short Flexible/complex
(few staff)
Spiral High Uncertain Need Experts Highly involved Long Large-scale,
risky system
Component-based Low Well defined Less staffs Highly involved Short System that can
development be partitioned/
componentized