CHAPTER 3

PROJECT MANAGEMENT
Project Management?
The Four P’s

• People — the most important element of a successful project

• Product — the software to be built
• Process — the set of framework activities and software engineering tasks to
get the job done
• Project — all work required to make the product a reality
 Software Project Management

• Objectives
• ensuring software is delivered on time and on
schedule and
• in accordance with the requirements of the organisations developing and
procuring the software.
• Why we need this?
• because software development is always subject to budget and schedule
constraints that are set by the organisation developing the software.
 Success criteria

• What are the criteria for a successful software project?

• Time  Deliver the software to the customer at the agreed time.
• Cost  Keep overall costs within budget.
• Expectation  Deliver software that meets the customer’s expectations.
• Team  Maintain a happy and well-functioning development team.
 Software management distinctions
(software project vs other project
management)
• The product is intangible.
• Software cannot be seen or touched. Software project managers cannot see progress by
simply looking at the artefact that is being constructed.
• Many software projects are 'one-off' projects.
• Large software projects are usually different in some ways from previous projects. Even
managers who have lots of previous experience may find it difficult to anticipate
problems.
• Software processes are variable and organization specific.
• We still cannot reliably predict when a particular software process is likely to lead to
development problems.
People Management
 Managing people
(Why this activity is important?)

• People are an organisation’s most important assets.

• The tasks of a manager are essentially people-oriented. Unless there is some
understanding of people, management will be unsuccessful.
• Poor people management is an important contributor to project failure.
 People management factors

• Consistency
• Team members should all be treated in a comparable way without favourites or
discrimination.
• Respect
• Different team members have different skills and these differences should be respected.
• Inclusion
• Involve all team members and make sure that people’s views are considered.
• Honesty
• You should always be honest about what is going well and what is going badly in a
project.
 Teamwork

• Most software engineering is a group activity

• The development schedule for most non-trivial software projects is such
that they cannot be completed by one person working alone.
• A good group is cohesive and has a team spirit. The people involved are
motivated by the success of the group as well as by their own personal goals.
• Group interaction is a key determinant of group performance.
• Flexibility in group composition is limited
• Managers must do the best they can with available people.
 The effectiveness of a team

• The people in the group

• You need a mix of people in a project group as software development involves
diverse activities such as negotiating with clients, programming, testing and
documentation.
• The group organization
• A group should be organized so that individuals can contribute to the best of
their abilities and tasks can be completed as expected.
• Technical and managerial communications
• Good communications between group members, and between the software
engineering team and other project stakeholders, is essential.
 The challenges in assembling a team

• May not be possible to appoint the ideal people to work on a project (due to many
reasons)
• Project budget may not allow for the use of highly-paid staff;
• Staff with the appropriate experience may not be available;
• An organisation may wish to develop employee skills on a software project.
• Managers have to work within these constraints especially when there are shortages
of trained staff.
Software Teams

How to lead?
How to organize?
How to collaborate?

How to motivate? How to create good ideas?

Software Teams

• The following factors must be considered when selecting a

software project team structure ...
• the difficulty of the problem to be solved
• the size of the resultant program(s) in lines of code or function points
• the time that the team will stay together (team lifetime)
• the degree to which the problem can be modularized
• the required quality and reliability of the system to be built
• the rigidity of the delivery date
• the degree of sociability (communication) required for the project
Project Scheduling and
Tracking
 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.
• Estimate the calendar time needed to complete each task, the effort required and
who will work on the tasks that have been identified.
• 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.
 Project 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.

• What are the milestones for CSC565/CSC577’s project?

• What are the deliverables for CSC565/CSC577’s project?
The project scheduling process
 Schedule representation

• Graphical notations are normally used to illustrate the project schedule.

• Tasks should not be too small. They should take about a week or two.
• Bar charts are the most commonly used representation for project schedules. They
show the schedule as activities or resources against time.
Tasks, durations, and dependencies
Task Effort (person-days) Duration (days) Dependencies
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)

Activity bar chart
Staff allocation chart
 Why are projects late?

• an unrealistic deadline established by someone outside the software

development group
• changing customer requirements that are not reflected in schedule
changes;
• an honest underestimate of the amount of effort and/or the number of
resources that will be required to do the job;
• predictable and/or unpredictable risks that were not considered when the
project commenced;
• technical difficulties that could not have been foreseen in advance;
 Why are projects late?

• human difficulties that could not have been foreseen in advance;

• miscommunication among project staff that results in delays;
• a failure by project management to recognize that the project is falling
behind schedule and a lack of action to correct the problem
 Scheduling Principles

• compartmentalization—define distinct tasks

• interdependency—indicate task interrelationship
• Time allocation—assign task to a specific time period
• effort validation—be sure resources are available
• defined responsibilities—people must be assigned
• defined outcomes—each task must have an output
• defined milestones—review for quality
Effort Allocation

• “front end” activities

• customer communication
40-50% • analysis
• design
• review and modification
• construction activities
15-20% • coding or code generation
• testing and installation
• unit, integration
• white-box, black box
• regression
30-40%
Defining Task Sets

• determine type of project

• assess the degree of rigor required
• identify adaptation criteria
• select appropriate software engineering tasks
Schedule Tracking

• conduct periodic project status meetings in which each team member reports progress
and problems.
• evaluate the results of all reviews conducted throughout the software engineering
process.
• determine whether formal project milestones have been accomplished by the
scheduled date.
• compare actual start-date to planned start-date for each project task listed in the
resource table.
• meet informally with practitioners to obtain their subjective assessment of progress to
date and problems.
• use earned value analysis to assess progress quantitatively.
Project Risk
Project Risks

What can go wrong?

What is the likelihood?
What will the damage be?
What can we do about it?
Assessing Project Risk-I

• Have top software and customer managers formally committed to support

the project?
• Are end-users enthusiastically committed to the project and the
system/product to be built?
• Are requirements fully understood by the software engineering team and
their customers?
• Have customers been involved fully in the definition of requirements?
• Do end-users have realistic expectations?
 Assessing Project Risk-II

• Is project scope stable?

• Does the software engineering team have the right mix of skills?
• Are project requirements stable?
• Does the project team have experience with the technology to be
implemented?
• Is the number of people on the project team adequate to do the job?
• Do all customer/user constituencies agree on the importance of the project
and on the requirements for the system/product to be built?
 Risk management

• Objective
• Risk management is concerned with identifying risks and drawing up plans to
minimise their effect on a project.
• Why we need risk management?
• Project risks affect schedule or resources;
• Product risks affect the quality or performance of the software being
developed;
• Business risks affect the organisation developing or procuring the software.
 Examples of common risks and affects to
the project, product, and business
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is finished.

Management change Project There will be a change of organizational management with different priorities.

Hardware unavailability Project Hardware that is essential for the project will not be delivered on schedule.

Requirements change Project and product There will be a larger number of changes to the requirements than anticipated.

Specification delays Project and product Specifications of essential interfaces are not available on schedule.

Size underestimate Project and product The size of the system has been underestimated.

CASE tool underperformance Product CASE tools, which support the project, do not perform as anticipated.

Technology change Business The underlying technology on which the system is built is superseded by new
technology.
Product competition Business A competitive product is marketed before the system is completed.
 The risk management process

• Risk identification
• Identify project, product and business risks;
• Risk analysis
• Assess the likelihood and consequences of these risks;
• Risk planning
• Draw up plans to avoid or minimise the effects of the risk;
• Risk monitoring
• Monitor the risks throughout the project;
The risk management process
 Risk identification

• Who do this?
• May be a team activities or based on the individual project manager’s experience.

• How to identify?
• May refer to a checklist of common risks (refer to the next slide for the details):
• Technology risks.
• People risks.
• Organisational risks.
• Requirements risks.
• Estimation risks.
 Examples of different risk types

Risk type Possible risks

Technology Database System  The database used in the system cannot process as many transactions per second as expected.
(1)
Software component  Reusable software components contain defects that mean they cannot be reused as planned.
(2)
People Quantity  It is impossible to recruit staff with the skills required. (3)
Illness  Key staff are ill and unavailable at critical times. (4)
Training  Required training for staff is not available. (5)
Organizational Restructuring  The organization is restructured so that different management are responsible for the project. (6)
Financial  Organizational financial problems force reductions in the project budget. (7)
Tools Tool inefficiency  The code generated by software code generation tools is inefficient. (8)
Tool mismatch  Software tools cannot work together in an integrated way. (9)
Requirements Change  Changes to requirements that require major design rework are proposed. (10)
Support  Customers fail to understand the impact of requirements changes. (11)
Estimation Time  The time required to develop the software is underestimated. (12)
Rate  The rate of defect repair is underestimated. (13)
Size  The size of the software is underestimated. (14)
 Risk analysis

• What is it for ?
• Assess probability and seriousness of each risk.
• What kind of probability?
• Probability may be very low, low, moderate, high or very high.
• What kind of seriousness?
• Risk consequences might be catastrophic, serious, tolerable or
insignificant.
 Risk types and examples (Analysis Outcomes)

Risk Probability Effects

Organizational financial problems force reductions in the project budget Low Catastrophic
(7).
It is impossible to recruit staff with the skills required for the project (3). High Catastrophic

Key staff are ill at critical times in the project (4). Moderate Serious
Faults in reusable software components have to be repaired before these Moderate Serious
components are reused. (2).
Changes to requirements that require major design rework are proposed Moderate Serious
(10).
The organization is restructured so that different management are High Serious
responsible for the project (6).
The database used in the system cannot process as many transactions Moderate Serious
per second as expected (1).
Risk types and examples (Analysis Outcomes)

Risk Probability Effects

The time required to develop the software is underestimated (12). High Serious

Software tools cannot be integrated (9). High Tolerable

Customers fail to understand the impact of requirements changes (11). Moderate Tolerable

Required training for staff is not available (5). Moderate Tolerable

The rate of defect repair is underestimated (13). Moderate Tolerable
The size of the software is underestimated (14). High Tolerable
Code generated by code generation tools is inefficient (8). Moderate Insignificant
 Risk planning

• What is the objective?

• Consider each risk and develop a strategy to manage that risk.
• What kind of planning?
• Avoidance strategies - The probability that the risk will arise is reduced;
• Minimisation strategies - The impact of the risk on the project or product
will be reduced;
• Contingency plans - If the risk arises, contingency plans are plans to deal
with that risk;
 Strategies to help manage risk

Risk Strategy
Organizational financial Prepare a briefing document for senior management showing how the
problems project is making a very important contribution to the goals of the business
and presenting reasons why cuts to the project budget would not be cost-
effective.
Recruitment problems Alert customer to potential difficulties and the possibility of delays;
investigate buying-in components.
Staff illness Reorganize team so that there is more overlap of work and people
therefore understand each other’s jobs.
Defective components Replace potentially defective components with bought-in components of
known reliability.
Requirements changes Derive traceability information to assess requirements change impact;
maximize information hiding in the design.
Strategies to help manage risk

Risk Strategy
Organizational restructuring Prepare a briefing document for senior management showing how the
project is making a very important contribution to the goals of the
business.
Database performance Investigate the possibility of buying a higher-performance database.
Underestimated Investigate buying-in components; investigate use of a program
development time generator.
 Risk monitoring

• What are the objectives?

• Assess each identified risks regularly to decide whether or not it is
becoming less or more probable.
• Also assess whether the effects of the risk have changed.
 Risk indicators to support Risk Monitoring

Risk type Potential indicators

Technology Late delivery of hardware or support software; many reported technology problems.

People Poor staff morale; poor relationships amongst team members; high staff turnover.

Organizational Organizational gossip; lack of action by senior management.

Tools Reluctance by team members to use tools; complaints about CASE tools; demands
for higher-powered workstations.
Requirements Many requirements change requests; customer complaints.

Estimation Failure to meet agreed schedule; failure to clear reported defects.

End of chapter