Chapter 5:

Software Planning and Risk Management

Software Engineering
Dr. Yahya Esmail Al-Ashmori
PH.D. Information Technology (IT)
Email: [email protected]
 Topics covered

• Software project management

• Plan-driven development

• Risk management

• Managing people

• Teamwork
2
 Software project management
• 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. 3
 Success standards
• 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.

4
 Software management distinctions
• 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.
5
 Factors influencing project management
• 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.
6
 Universal management 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.

7
 Management 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
– The 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.
8
 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. 9
 Plan-driven development
• 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
 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

11
 Project plan supplements
Plan Description
Configuration Describes the configuration management
management plan 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.
12
 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.

13
The project planning process

14
Risk management
15
 Risk management
• 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.
• You have to anticipate(expect) risks, understand the
impact of these risks on the project, the product and
the business, and take steps to avoid these risks.
16
 Risk classification
• There are two dimensions of risk classification
– The type of risk (technical, organizational, ..)

– what 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.
17
 Examples of project, product, and business risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project
before it is finished.
Management Project There will be a change of organizational
change management with different priorities.
Hardware Project Hardware that is essential for the project
unavailability will not be delivered on schedule.
Requirements Project and product There will be a larger number of changes to
change 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 Product CASE tools, which support the project, do
underperformance 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;

19
The risk management process

20
 Risk 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 risks.

– Organizational risks.

– People risks.

– Requirements risks.

– Estimation risks.
21
 Examples of different risk types
Risk type Possible risks
Estimation 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)
Organizational The organization is restructured so that different 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)
Requirements Changes to requirements that require major design 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 transactions
per second as expected. (1)
Reusable software components contain defects that mean they cannot
be reused as planned. (2)
Tools The code generated by software code generation tools is inefficient. (8)
Software tools cannot work together in an integrated way. (9)
 Risk analysis
• 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.

23
Figure 11-5. Sample Probability/Impact
Matrix

24
25
 Risk types and examples
Risk Probability Effects

Organizational financial problems force Low Catastrophic

reductions in the project budget (7).
It is impossible to recruit staff with the skills High Catastrophic
required for the project (3).
Key staff are ill at critical times in the project (4). Moderate Serious
Faults in reusable software components have to Moderate Serious
be repaired before these components are
reused. (2).
Changes to requirements that require major Moderate Serious
design rework are proposed (10).
The organization is restructured so that different High Serious
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
Risk Probability Effects

The time required to develop the High Serious

software 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 Moderate Tolerable
available (5).
The rate of defect repair is Moderate Tolerable
underestimated (13).
The size of the software is High Tolerable
underestimated (14).
Code generated by code generation Moderate Insignificant
tools is inefficient (8). 27
 Risk 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; 28
 What-if questions
• What if several engineers are ill at the same time?

• What if an economic downturn leads to budget cuts of

20% for the project?

• What if the performance of open-source software is

inadequate and the only expert on that open source
software leaves?

• What if the company that supplies and maintains

software components goes out of business?

• What if the customer fails to deliver the revised

requirements as predicted? 29
 Strategies to help manage risk
Risk Strategy
Organizational Prepare a briefing document for senior management
financial showing how the project is making a very important
problems contribution to the goals of the business and
presenting reasons why cuts to the project budget
would not be cost-effective.
Recruitment Alert customer to potential difficulties and the
problems 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 Replace potentially defective components with bought-
components in components of known reliability.
Requirements Derive traceability information to assess requirements
changes change impact; maximize information hiding in the
design.
30
 Strategies to help manage risk
Risk Strategy

Organizational Prepare a briefing document for senior

restructuring management showing how the project is
making a very important contribution to
the goals of the business.
Database Investigate the possibility of buying a
performance higher-performance database.

Underestimated Investigate buying-in components;

development time investigate use of a program generator.

31
 Risk 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.

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

34
 Managing people
• 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.

35
 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.
36
 Motivating people
• 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).
37
Human needs hierarchy

Maslow's hierarchy of needs 38

 Need satisfaction
• In software development groups, basic
physiological and safety needs are not an issue.
• Social
– Provide communal facilities;
– Allow informal communications e.g. via social networking
• Esteem
– Recognition of achievements;
– Appropriate rewards.
• Self-realization
– Training - people want to learn more;
– Responsibility.

39
 Personality types
• The needs hierarchy is almost certainly an over-
simplification of motivation in practice.

• Motivation should also take into account different

personality types:
– Task-oriented people, who are motivated by the work
they do.

– Interaction-oriented people, who are motivated by the

presence and actions of co-workers.

– Self-oriented people, who are principally motivated by

personal success and recognition. 40
 Personality types
• Task-oriented.
– The motivation for doing the work is the work itself;

• Self-oriented.
– The work is a means to an end which is the achievement of
individual goals - e.g. to get rich, to play tennis, to travel…

• Interaction-oriented
– The principal motivation is the presence and actions of
co-workers. People go to work because they like to go to
work.
41
 Motivation balance
• Individual motivations are made up of elements
of each class.

• The balance can change depending on personal

circumstances and external events.

• However, people are not just motivated by personal factors

but also by being part of a group and culture.

• People go to work because they are motivated by the people

that they work with.

42
Teamwork

43
 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.

44
 Group cohesiveness
• In a cohesive group, members consider the group
to be more important than any individual in it.
• The advantages of a cohesive group are:
– Group quality standards can be developed by the group
members.
– Team members learn from each other and get to know
each other’s work; Inhibitions caused by ignorance are
reduced.
– Knowledge is shared. Continuity can be maintained if a
group member leaves.
– Refactoring and continual improvement is encouraged.
Group members work collectively to deliver high quality
results and fix problems, irrespective of the individuals
who originally created the design or program.
45
 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.
46
 Selecting group 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.

47
 Assembling a team
• May 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 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. 48
 Group composition
• Group 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.

49
 Group organization
• 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?
• Who will be involved in making critical technical
decisions, and how will these be made?
• How will interactions with external stakeholders
and senior company management be handled?
• How can groups integrate people who are not co-
located?
• How can knowledge be shared across the group?
 Group organization
• Small software engineering groups are usually
organised informally without a rigid structure.

• For large projects, there may be a hierarchical

structure where different groups are responsible for
different sub-projects.

• Agile development is always based around an

informal group on the principle that formal structure
inhibits information exchange
51
 Informal groups
• The group acts as a whole and comes to a
consensus on decisions affecting the system.

• The group leader serves as the external interface of

the group but does not allocate specific work items.

• Rather, work is discussed by the group as a whole

and tasks are allocated according to ability and
experience.

• This approach is successful for groups where all

members are experienced and competent. 52
 Group 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.

53
 Group communications
• 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. 54
 Key points
• Good project management is essential if software
engineering projects are to be developed on schedule and
within budget.

• Software management is distinct from other engineering

management. Software is intangible. Projects may be novel
or innovative with no body of experience to guide their
management. Software processes are not as mature as
traditional engineering processes.

55
 Key points
• Risk management involves identifying and assessing project
risks to establish the probability that they will occur and the
consequences for the project if that risk does arise. You
should make plans to avoid, manage or deal with likely risks if
or when they arise.

• People management involves choosing the right people to

work on a project and organizing the team and its working
environment.

• People are motivated by interaction with other people, the

recognition of management and their peers, and by being
given opportunities for personal development. 56
 Key points
• Software development groups should be fairly small and
cohesive. The key factors that influence the effectiveness
of a group are the people in that group, the way that it is
organized and the communication between group
members.

• Communications within a group are influenced by factors

such as the status of group members, the size of the
group, the gender composition of the group, personalities
and available communication channels.

57