Software Project Management

Outline

• Management concepts
• Project Management Processes
• Project Scope Management
• Project Initiation
• Project Planning and Tracking
• Project Risk Management
• Project Personnel and Organization
• Project Cost Management
• Project Quality management
• Project Communication Management
• Project Control
• Project Audit and Closure
 Characteristics of projects

A task is more ‘project-like’ if it is:

• Non-routine
• Planned
• Aiming at a specific target
• Work carried out for a customer
• Involving several specialisms
• Made up of several different phases
• Constrained by time and resources
• Large and/or complex

3
Activities covered by project management

• Feasibility study
– Is project technically feasible and worthwhile from a business
point of view?
• Planning
– Only done if project is feasible
• Execution
– Implement plan, but plan may be changed as we go along
4
 What is management?
This involves the following activities:

• Planning – deciding what is to be done

• Organizing – making arrangements
• Staffing – selecting the right people for the job
• Directing – giving instructions
• Monitoring – checking on progress
• Controlling – taking action to remedy hold-ups
• Innovating – coming up with solutions when problems
emerge
• Representing – liaising with clients, users, developers and
other stakeholders
5
 Objectives
• Informally, the objective of a project can be defined by
completing the statement:

– The project will be regarded as a success if completed and

become operational by 4th of April 2015

• Rather like post-conditions for the project

• Focus on what will be put in place, rather than how
activities will be carried out

6
 Measures of effectiveness

• How do we know that the goal or objective has been achieved?

• By a practical test, that can be objectively assessed.

Example: for user satisfaction with software product:

• Repeat business – they buy further products from us

• Number of complaints – if low

7
Step wise approach for Software Project
Planning
 Step Wise – An Overview
0.Select
project
1. Identify 2. Identify project
project objectives infrastructure
3. Analyse
project
characteristics
Review
4. Identify products
and activities

5. Estimate effort
Lower for activity For each
level activity
detail 6. Identify activity
risks
10. Lower level
7. Allocate
planning
resources

8. Review/ publicize
9. Execute plan plan 9
 Activity Planning

• A project plan is a schedule of activities indicating the

start and stop for each activity
– Also provide the project and resource schedules
• The start and stop of each activity should be visible
and easy to measure
• Each activity should have some ‘deliverables’ for ease
of monitoring

10
 Activity Planning (cont’d)
• During planning, managers consider:
– Resource availability

– Resource allocation

– Staff responsibility

– Project Monitoring

– Cash flow forecasting

– Re-planning of the project towards the pre-defined goal

11
 Other Objectives of Activity Planning

• Feasibility assessment

• Resource allocation

• Detailed costing

• Motivation

• Co-ordination

12
 Different Levels of Plans

• Project Schedule: a plan that shows

– the dates when each activity should start and stop

– when and how much of the resources will be required

• Activity Plan: a plan that describes

– how each activity will be undertaken

13
 Project Schedule in 4 Stages

• Ideal Activity Plan

– An activity plan without any constraints

• Risk consideration for each activity

• Resource consideration for whole project

• Schedule production and publication

14
Various Approaches Towards Identifying Activity

• Activity-based approach

• Product-based approach

• Hybrid approach

15
 Activity-based Approach

• Use Work Breakdown Structure (WBS) to generate a task list

• WBS involves
– identifying the main tasks
– break each main task down into subtasks
– The subtasks can further be broken down into lower level tasks.

16
 Activity-based Approach (cont’d)

Work Breakdown Structure (an extract)

Software
project

Requirements System Coding Testing

Analysis Design

Data Process
Design Design

17
 Activity-based Approach (cont’d)

• Advantages
– More likely to obtain a task catalogue that is complete and is
composed of non-overlapping tasks
– WBS represents a structure that can be refined as the project
proceeds
– The structure already suggests the dependencies among the
activities

• Disadvantage
– Very likely to miss some activities if an unstructured activity list is
used

18
 Product-based Approach

• Product Breakdown Structure (PBS)

– To show how a system can be broken down into different products
for development
• Product Flow Diagram (PFD)
– To indicate, for each product, which products are required as ‘inputs’
• Advantages
– Less likely to miss a product unexpectedly from a PBS
A Product Breakdown Structure (an extract)

Inventory
Control

Inventory Item Management

Databases Processing Reporting

Item Vendor Item Item Item Sales

Database Database Purchasing Sales Reporting Reporting

Item Item Item Invoicing Sales Order

Addition Deletion Modification subsystem Processing
19
 Hybrid Approach

• A mix of the activity-based approach and the product-based

approach
• More commonly used approach
• The WBS consists of
– a list of the products of the project; and
– a list of activities for each product
Software Project

System Installation Software component User manual User Training

Analyse requirements Review requirements Analyse requirements Design course

Detailed design Outline design Design manual Write materials

Integrate system Detailed design Document manual Print course materials

Test system Code software Capture screens Training

Deliver system Test software Print Manual 20

Size and Cost Estimation

21
 Overview

• Different level of estimation

• Project Evaluation

• Introduction to Estimation

• Size Estimation

• Cost Estimation

22
 Issues related to Estimation
• Difficult to make accurate estimation.

• Better to have previous data and analyze the actual

values against their estimates so that you know how
accurate you are.

• Even better to have previous data of the whole

organization so that you know how accurate the
estimation method, if any, used within the
organization is.

23
 Constructive Cost Model II (COCOMO II)

• A parametric cost model

– Important aspects of software projects are characterized by variables
(or parameters)

– Once the value of the parameters are determined, the cost can be
computed from an equation

• Recognizes different approaches to software development

– Prototyping, Incremental development etc.

24
 COCOMO 2 models
• COCOMO 2 incorporates a range of sub-models that produce
increasingly detailed software estimates.

• The sub-models in COCOMO 2 are:

– Application composition model. Used when software is composed from
existing parts.
– Early design model. Used when requirements are available but design
has not yet started.
– Reuse model. Used to compute the effort of integrating reusable
components.
– Post-architecture model. Used once the system architecture has been
designed and more information about the system is available.

26
Software Project Risk Management
 Overview

• Project risks

• Nature of risks

• Risk identification

• Risk estimation

• Risk evaluation

• Risk management

• Risk reduction strategies

28
 Nature of Project Risks

• Planning assumptions

• Estimation errors

• Eventualities

29
 Planning Assumptions (cont’d)

• Why assumptions
– Uncertainties in early stage of the project
• Common assumption:
– “Everything will go smoothly”
• Environment is reliable and fixed
• Design will be perfect first time
• Coding will be ‘nearly perfect’
• Guidelines
– List all the assumptions
– Identify the effects of these assumptions on the project if they are
no longer valid

30
 Estimation Errors

• Difficult to have accurate size or time estimations

– Lack of experience of similar tasks
– Lack of historical data
– Nature of the task

• Estimation can be improved by analyzing historic data for

similar tasks and similar projects
– Keep historic data of your estimation and the actual performance
– Compare your estimation and the actual value
– Classify the tasks that are easy or difficult to give accurate estimation

31
 Eventualities

• Unexpected and unimaginable events

• Common unexpected events

– Hardware cannot be delivered on time
– Requirements specification needs to be rewritten
– Staffing problem

32
 Boehm’s Risk Engineering

Risk
Engineering

Risk Risk
Analysis Management

Risk Risk Risk Risk Risk Risk Risk Risk

Identification Estimation Evaluation Planning Control Monitoring Directing Staffing

33
 Risk Identification (cont’d)

• Type of risks
– Generic risk (common to all projects)
• Standard checklist can be modified based on the risk analysis of
previous projects
• Examples are misunderstanding of the requirements and key staff
being ill.
– Specific risk (only applies to individual projects)
• More difficult to find
• Need to involve project team members
• Need an environment that encourages risk assessment

34
 Risk Identification

• Identify the hazards that might affect the duration or resource

costs of the project
Hazard  Problem  Risk

• A hazard is an event that might occur and will create a

problem for the successful completion of the project, if it does
occur

35
 Risk Identification (cont’d)

• Guideline
– Use checklist that lists the potential hazards and their corresponding
factors
– Maintain an updated checklist for future projects

36
 Common Risk Factors

• Application factors • Changeover factors

• Staff factors • Supplier factors

• Project factors • Environment factors

• Hardware and software factors • Health and safety factors

37
 Application Factors

• Nature of the application

– A data processing application or a life-critical system (e.g. X-ray
emission system)

• Expected size of the application

– The larger is the size, the higher is the chance of errors,
communication problems and management problems

38
 Staff Factors
• Experience and skills:
– Experienced programmers are less likely to make errors.
• Appropriateness of Experience:
– Experience in structural design (using JSD) may not be related to
OOD in UML.
– Experience in coding COBOL may not be related to coding in C++ or
Java.
• Staff satisfaction:
– Dissatisfied or Unmotivated staff may cause a project to fail.
• Staff turn-over rate:
1.Key personnel leaving unexpectedly would cause a project to fail.
2.High turn-over rate would cause much communication overhead
and may delay a project.
39
 Project Factors
• Project objectives:
– Ill defined
– Unclear to every team member and user
• Project methods:
– Ill specified methods
– Unstructured methods

40
 Hardware and Software Factors
• New hardware
– Stability of the new hardware system
• Cross platform development
– Development platform is not the operation platform
– Does the language used support cross platform development?
• Platform Issue:
1.the development platform and the operation platform may not be the same.
2.Adjustment is needed to cater for the operation platform. This leads to
extra time and effort.
3.Problems may only occur in the operation platform.
• Language Issue:
1.Availability of languages in the development platform as well as the
operation platform
2.High portability languages should be used such as C, C++, and Java.
3.This also relates to the skills of the staff.
4.Integration issues of different development off-the-shelf components such
41
 Changeover Factors

• ‘All-in-one’ changeover
– The new system is put into operation
• Incremental or gradual changeover
– Adding new components to the system by phases
– However, it is not always practical because it involves too many
issues such as
1.the order of integration of the components,
2.the scheduling of the components,
3.the interface between the replaced components and the replacing
components, and
4.training of operation personnel.
• Parallel changeover
– Both the existing system and the new system are used in parallel

42
 Supplier Factors

• Late delivery of hardware

• Instability of hardware

• Late completion of building sites

43
 Environment Factors

• Changes in environment such as hardware platforms

• Changes in government policies

• Changes in business rules

• Restructuring of organizations

44
 Health and Safety Factors

• Health and safety of staff and environment

– Staff sickness, death, pregnancy etc.
– Any tragic accident to staff

45
 Boehm’s Top Ten Risk Items

• Personnel shortfalls

• Unrealistic schedules and budgets

• Developing the wrong software functions

• Developing the wrong user interface

• Gold plating

46
 Boehm’s Top Ten Risk Items (cont’d)

• Continuing stream of requirements changes

• Shortfalls in externally performed tasks

• Shortfalls in externally furnished components

• Real-time performance shortfalls

• Straining computer science capabilities

47
 Risk Estimation
• Recall that
Hazard  Problem  Risk

• Risk estimation is to assess the likelihood and impact of each

hazard

• Risk exposure (risk value)

– It is the importance of the risk
Risk exposure = risk likelihood × risk impact

48
 Risk Estimation (cont’d)
• Risk likelihood
– The probability that a hazard is going to occur
• Risk impact
– The effect of the problem caused by the hazard

• Advantages
– The only way to compare or rank the risks
– To have a good quantitative estimate, the extra effort can provide a
better understanding of the problem
• Disadvantages
– Estimation is difficult, subjective, time-consuming and costly

49
 Risk Estimation Techniques
• Risk likelihood
– Rank from Low, Medium to High
– Rank from 1 (least likely) to 10 (most likely)
• Risk Impact
– Rank from 1 to 10 Project Risk assessment matrix
Probability of Severity of Overall
Occurrence Impact Project Risk
High High
High Medium High
Medium High
High Low
Low High Medium
Medium Medium
Medium Low
Low Medium Low
Low Low

50
 Staffing Requirements

• What kind of skills are required?

• What type of individuals are required?

• What is the ideal group structure?

• Time frame available for staffing.

• Staff form a subset of overall resource requirements identified

during resource planning.

51
 Constraints

• Factors that limit the project team’s options:

– Team structure may be dictated by organizational culture (or
procedures).

– Unions and employee groups impose some constraints.

– Educational qualifications (may be similar level but from different

universities).

52
 Templates

• Using a common template will help in developing the required

documentation.
• Templates can be patterns that have worked before (like an
organizational structure, documentation structure, reporting
structure etc…).

Professional Staff
Area of Tasks
Name Firm Position
Expertise Assigned

53
 Roles/Responsibility Assignment
• Who does what?
• Who decides what?
• A RAM (Responsibility Assignment Matrix is often used).
• In large projects RAMs may be developed at various levels.

Phase People A B C D E
Requirements S R A P P
Analysis S A
Design S A I
Implementation/Build R S S
Legend: P = Participant, A = Accountable, R = Review Required,
I = Input Required, S = Sign-Off Required
54
 Organization Chart

• A graphical display of project reporting relationships (with

Names and Roles).

• Should be formal (on smaller projects this may be

communicated informally, but it achieves best results when
formally presented).

• A specialised role and responsibility detail should be made

available.

55
 Organization Chart- Example

John Smith
Project Manager

Clark Kent Lucy Lu Jackie Chan

Software Architect Creative Team Leader Documentation Engineer

56
Project Schedules

57
 What is a project schedule?

• The project schedule is a calendar that links the tasks to be

done with the resources that will do them.

– Before a project schedule can be created, the project manager must

have a work breakdown structure (WBS) and estimates.

– The schedule is part of the project plan.

58
 Scheduling concepts: Effort vs. Duration

• Effort represents the work required to perform a task.

– Effort is measured in person-hours (or person-days, person-weeks, etc.)

– It represents the total number of hours that each person spent working
on the task.

• Duration is amount of time that elapses between the time the

task is started and the time it is completed.

– Duration is measured in hours (or days, weeks, etc.)

– It does not take into account the number of people performing the task

59
 Scheduling concepts: Slack and Overhead
• Slack is the amount of time which any of the tasks can be
delayed without causing the due date of the final task in the
sequence to be delayed as well.
– A tight schedule has very little slack; a delay in any task will
cause a delay in the due date
– Parkinson’s Law: “Work expands so as to fill the time
available for its completion.”

• Overhead is any effort that does not go to the core activities of

the task but is still required in order for the people to perform
it—a sort of “real world” cost of actually doing the work.
– Two people performing a task will require more effort than
one person doing the same task
– Assigning two people to the task requires more effort, but
the task has a shorter duration
60
 Building the project schedule

• Allocate resources
– For each task in the WBS, one or more resources must be assigned

– Choose person or people for each task based on qualifications,

familiarity and availability

– Take overhead into account when calculating the duration of each

task

61
 Building the project schedule

• Identify dependencies
– A task has a dependency if it involves an activity, resource or work
product which is subsequently required by another task

– Tasks may have dependencies because they require the same

resource

62
 Building the project schedule

• Identify dependencies (continued)

– Every dependency has a predecessor, or a task that must be begun,
in progress, or completed, for another task to begin
– Identify the type of predecessor for each dependency

63
 Building the project schedule

• Step 1 Create the

schedule
– Most project schedules are
represented using a Gantt
chart
– The Gantt chart shows
tasks, dependencies and
milestones using different
shapes

64
 Building the project schedule

• (Step 2) Reconcile the schedule with the

organization’s needs
– Once resources are allocated to each task, a final date can
be calculated
– If this date is unacceptable, the project plan must change

– Either additional resources must be allocated to the project

or the scope must be cut down

– Brooks’ Law: “Nine women cannot have a baby in one

month.”
• In other words, some tasks can only be done by one person, no
matter how critical they are.

65
 Building the project schedule

• (Step 3) Add review meetings to the schedule

– Progress reviews are meetings held regularly to check the

progress of a project versus it's scheduled progress.

– Milestone reviews are meetings which the project manager

schedules in advance to coincide with project events.
• The most common way for project managers to handle milestone
reviews is to schedule them to occur after the last task in a project
phase (such as the end of design or programming).

66
 Building the project schedule

• Step 4: Optimize the schedule

– The critical path is the sequence of tasks that represent the minimum
time required to complete the project.
• If a task is only on the critical path when delaying that task will delay
the project.
• Allocating resources to tasks on the critical path will reduce the
project schedule; allocating them to other tasks will have less effect.

– A resource is over-allocated if more than 100% allocated to multiple

tasks simultaneously
• If any resource is over-allocated, it means that there is a dependency
between two tasks which was not discovered.
• When this happens, the schedule is guaranteed to be inaccurate. Find
and fix over-allocated resources.

67
 Don’t abuse buffers

• A buffer is a task added to the schedule with no specific purpose except to

account for unexpected delays.
– This practice involves either adding extra tasks or padding existing tasks at
strategic points in the schedule where overruns are “expected”.

– Buffers can be useful:

• On a year-long project, every programmer will take two weeks of vacation
• Buffers can be used to account for this known delay

– Buffers are often abused

• The idea that overruns are expected means that there is an implicit assumption that
the estimate is incorrect.
• Buffers should not be used to add time to compensate for an inaccurate estimate.

68
 Project metrics

• The baseline is the version of the schedule that has

been approved
– The schedule will change based on the actual work done by
the project team.
– When the deadline of the revised schedule is later than that
of the baseline, the project has slipped.

• Variance is the difference between the estimated

effort in the baseline and the actual effort performed
by the team.
69
 Project metrics

• Earned value management tracks the project by

considering effort “earned” against a budget only
after it has actually been performed
– The budgeted cost for work scheduled (BCWS) is the
estimated effort of the actual tasks that appear on the
schedule to date.
– The actual cost of work performed (ACWP) is the effort
spent on the tasks in the schedule that have actually been
completed by the development team members.

– Variance = BCWS – ACWP

70