Chapter4– Project

Management
2 Topics covered

Risk management
Managing people
Teamwork
 Software project management
3

 Concerned with activities involved in ensuring that

software is delivered on time and on schedule and
in accordance with the requirements of the
organisations developing and procuring the
software.

 Project management is needed because software

development is always subject to budget and
schedule constraints that are set by the
organisation developing the software.
 Success
4
criteria
 Deliver the software to the customer at the agreed
time.

 Keep overall costs within budget.

 Deliver software that meets the customer’s

expectations.

 Maintain a coherent and well-functioning

development team.
Software management distinctions
 The product is intangible.
5
 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.
Factors influencing project management
6
 Company size
 Software customers
 Software size
 Software type
 Organizational culture
 Software development processes
 These factors mean that project managers in
different organizations may work in quite different
ways.
 Universal management
7 activities
 Project planning
 Project managers are responsible for planning.
estimating and scheduling project development
and assigning people to tasks.
 Risk management
 Project managers assess the risks that may affect
a project, monitor these risks and take action
when problems arise.
 People management
 Project managers have to choose people for their
team and establish ways of working that leads to
effective team performance.
 Management
8 activities
 Reporting
 Project managers are usually responsible for
reporting on the progress of a project to
customers and to the managers of the company
developing the software.
 Proposal writing
 T h e first stage in a software project may involve
writing a proposal to win a contract to carry out
an item of work.
 The proposal describes the objectives of the
project and how it will be carried out.
9

Risk management
 Risk management
10
 Risk management is concerned with identifying risks
and drawing up plans to minimise their effect on a
project.
 Software risk management is important because of
the inherent uncertainties in software development.
 These uncertainties stem from loosely defined
requirements, requirements changes due to
changes in customer needs, difficulties in
estimating the time and resources required for
software development, and differences in
individual skills.
 Risk
11 classification
 There are two dimensions of risk classification

 T h e type of risk (technical,

organizational, ..)
 w h a t is affected by the risk:
 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 project, product, and business risks
1
Risk 2 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 There will be a larger number of changes to
product the requirements than anticipated.
Specification delays Project and Specifications of essential interfaces are not
product available on schedule.
Size underestimate Project and The size of the system has been underestimated
product
CASE tool Product CASE tools, which support the project, do not
underperformance 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
13
 Risk identification
 Identify project, product and business risks;
 Risk analysis
 Assess the likelihood and consequences of
these risk;
 Risk planning
 D r a w up plans to avoid or minimise the effects
of the risk;
 Risk monitoring
 Monitor the risk throughout the project;
 The risk management
1 process
4
 Risk
15
identification
 May Be a team activities or based on
the individual project manager’s
experience.
 A checklist of common risks may be used
to identify risks in a project
 Technology risk.
 Organizational risk.
 Pe o p l e r i s k .
 Requirements risk.
 Estimation risks.
 Examples of different risk
1Risk type
types
6Estimation
Possible risks
The time required to develop the software is
underestimated. (12) The rate of defect repair is
underestimated. (13)
The size of the software is underestimated. (14)
Organization The organization is restructured so that different
al management are responsible for the project. (6)
Organizational financial problems force reductions in the
project
budget. (7)
People It is impossible to recruit staff with the skills
required. (3) Key staff are ill and unavailable at
critical times. (4) Required training for staff is not
available. (5)
Requirement Changes to requirements that require major design
s rework are
proposed. (10)
Customers fail to understand the impact of
requirements changes. (11)
Technology The database used in the system cannot process as
many
Transaction per second as expected.(1)
 Risk analysis
17

 Assess probability and seriousness of each risk.

 Probability may be very low, low, moderate, high

or very high.

 Risk consequences might be catastrophic,

serious, tolerable or insignificant.
 Risk types and examples
1
8
Risk Probability Effects

Organizational financial problems force Low Catastrophi

reductions in the project budget (7). c
It is impossible to recruit staff with the skills High Catastrophi
required for the project (3). c
Key staff are ill at critical times in the project (4). Moderate Serious
Faults in reusable software components have Moderate Serious
to be
repaired before these components are reused. (2).
Changes to requirements that require Moderate Serious
major design rework are proposed (10).
The organization is restructured so that High Serious
different management are responsible for the
project (6).
The database used in the system cannot Moderate Serious
process as
many transactions per second as expected (1).
 Risk types and examples
1
9
Risk Probability Effects

The time required to develop the software High Serious

is
underestimated (12).
Software tools cannot be integrated (9). High Tolerable

Customers fail to understand the impact Moderate Tolerable

of requirements changes (11).

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

The rate of defect repair is underestimated Moderate Tolerable
(13).
The size of the software is underestimated High Tolerable
(14).
Code generated by code generation tools Moderate Insignificant
is inefficient (8).
 Risk
20 planning
 Consider each risk and develop a strategy to
manage that risk.
 Avoidance strategies
 The probability that the risk will arise is
reduced;
 Minimization 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;
 Risk
2
2
monitoring
 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.

 Each key risk should be discussed at

management
progress meetings.
 Risk
2
3
indicators
Risk type Potential indicators
Estimation Failure to meet agreed schedule; failure to clear
reported defects.
Organization Organizational gossip; lack of action by senior
al management.
People Poor staff morale; poor relationships amongst
team members; high staff turnover.
Requirement Many requirements change requests; customer
s complaints.
Technology Late delivery of hardware or support software;
many reported technology problems.
Tools Reluctance by team membersto use tools; complaints
about CASE tools; demands for higher-powered
workstations.
2
4

Managing
people
 Managing people
25

 Pe o p l e 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.

 P o o r people management is an important

contributor to project failure.
 People management
26 factors
 Consistency
 Te a m 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
 Yo u should always be honest about what is
going well
and what is going badly in a project.
 Motivating people
27
 An important role of a manager is to motivate the people
working on a project.
 Motivation means organizing the work and the working
environment to encourage people to work effectively.
 If people are not motivated, they will not be interested in
the work they are doing. They will work slowly, be more likely
to make mistakes and will not contribute to the broader
goals of the team or the organization.
 Motivation is a complex issue but it appears that their are
different types of motivation based on:
 Basic needs (e.g. food, sleep, etc.);
 Personal needs (e.g. respect, self-esteem);
 Social needs (e.g. to be accepted as part of a group).
 Teamwork
28

 M o s t software engineering is a group activity

 T h e 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.
 G r o u p 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
29 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.
 Selecting group
30 members
 A manager or team leader’s job is to create a
cohesive group and organize their group so that
they can work together effectively.
 This involves creating a group with the right balance
of technical skills and personalities, and organizing
that group so that the members work together
effectively.
 Assembling a
Mayteam
31
 not be possible to appoint the ideal people to
work on a project
 Project budget may not allow for the use of highly-
paid staff;

 Staff with the appropriate experience may not be

available;

 An organization may wish to develop employee skills on

a software project.

 M a n a g e r s have to work within these constraints

especially when there are shortages of trained
staff.
 Group
32
 composition
G r o u p composed of members who share the
same motivation can be problematic.
 Task-oriented - everyone wants to do their own
thing;
 Self-oriented - everyone wants to be the boss;
 Interaction-oriented - too much chatting, not
enough work.
 An effective group has a balance of all types.
 This can be difficult to achieve software engineers
are often task-oriented.
 Interaction-oriented people are very important as
they can detect and defuse tensions that arise.
 Group organization
33
 The way that a group is organized affects the decisions
that are made by that group, the ways that information is
exchanged and the interactions between the
development group and external project stakeholders.
 Key questions include:
 Should the project manager be the technical leader of the
group?
 W h o will be involved in making critical technical
decisions, and how will these be made?
 H o w will interactions with external stakeholders and
senior
company management be handled?
 H o w can groups integrate people who are not co-
located?
 H o w can knowledge be shared across the group?
 Group
34 communications
 Good communications are essential for
effective group working.

 Information must be exchanged on the status of

work, design decisions and changes to previous
decisions.

 Good communications also strengthens group

cohesion as it promotes understanding.
 Group
35communications
 Group size
 The larger the group, the harder it is for people to
communicate with other group members.
 Group structure
 Communication is better in informally structured groups
than
in hierarchically structured groups.
 Group composition
 Communication is better when there are different
personality types in a group and when groups are mixed
rather than single sex.
 The physical work environment
 Good workplace organisation can help encourage
communications.
35

THANK YOU !!!!