Lec 05 – Risk Management

Dr Saddaf Rubab

Ref: Software Project Management (A Process-Driven

Approach), by Ashfaque Ahmed, CRC Press; Chapter 04
1
2
OBJECTIVES

 What is a risk on a project?

 What kinds of risks exist for a project?
 What kind of impact may risks have on a project?
 What strategy is needed to deal with risks?

3
INTRODUCTION

 Risks are unforeseen or unplanned happenings, which, when they occur, adversely
affect our future plans.
 When we analyze any software project, what kinds of risk come to our mind?
 Basically, a project has these components: budget, time, resources, quality, and
technology. If any risk occurs that might affect any of these components, then the
project may fail.
 What is the best way to reduce or mitigate the risks?
 There could be many aspects to any project. But a project manager must develop a
comprehensive risk mitigation plan. If he has not made a proper risk plan, then if 4

anything wrong happens, he will not be able to handle it

 Suppose a project is to be coded using a
particular programming language, and one
developer on the team is not conversant with
it. In this case, he is given training so that he
can pick up this language.
 However, if even after training, this team
member is not able to use the programming
language, he will not be able to do the task
assigned to him, and his inability will be
considered an internal risk.
 Now, suppose that this particular training is
not available from any training service
provider, then in that case, the risk becomes 5

an external risk.
INTRODUCTION

 Many environmental factors affect a project. Some of the external risks can be
managed by a proactive approach. But many external risks cannot be managed.
 Example: the obsolescence of a technology.
 When the project starts, a particular technology is chosen (a prebuilt vendor component,
for instance) little realizing that the vendor will not support that component by the time
the project finishes. Similarly, the customer may go out of business due to economic
recession and the project may need to be scrapped.
6
CAUSES OF RISK

 For any good project manager, it is of utmost importance that he first of all makes a
list of risks which his project faces. After that, he can find solutions for tackling
them.

7
1. Quality Constraints
 Quality is one of the major concerns for software products. Indeed, meeting quality
requirements is a big risk for all projects.
 Software vendors realize that it is much cheaper to make a good quality software
product with low support costs than to produce a software product of poor quality
and end up with high support costs.
 So an elaborate set of quality constraints are imposed from the start of the project to
the finish. In fact, nowadays, a separate software process group is formed that
oversees the quality of projects.
8
2. Resource Unavailability
 As software professionals are in great demand the world over, finding and procuring
a good software professional is a complete project in itself.
 Retaining him within the organization is yet another challenge.
3. Disinterest
 Lack of interest is a concern that needs to be mitigated by project managers as it
severely affects productivity. A good motivation program for individuals who lack
interest in the project can be organized.

9
4. Attrition (Wearing away)
 Due to the high demand for software professionals, most professionals have many job
offers in hand at any given time. When they find a lucrative offer, they quit an
organization to join another organization, thus leaving a project midway. Attrition has
become such a big issue that managements at big corporations have specialized
programs to tackle it.
5. Scope Creep
 It always impacts the project severely. Requirements keep changing and new
requirements keep piling up even after the project has completed the testing phase
and is into the implementation phase. A good change management mechanism can
10
tackle this threat/risk effectively.
6. Cost Constraints
 Once a project is approved for commencement, a budget is allocated and procured for
the project.
 But due to unavoidable reasons, the budget can be constrained.
 In such situations, the project cannot proceed as sources of funds have dried up and
project expenses cannot be met. There is no solution for this problem, but if this risk
is known in advance (an unlikely occurrence), then the project could be cut short and
scrapping of the project could be avoided.
11
7. Bad Negotiation
 If the project manager has good negotiation skills, then he can procure an
additional/modified budget, support, and resources, whenever the need arises.
8. Unrealistic Estimate
 It is also a fact that effort estimates for software projects are difficult to make because
of the uncertainties involved.
 It is always better to keep a buffer when an estimate is made, to take care of
uncertainties.

12
9. Human Error
 Due to human error, the requirements or design, or the construction may get injected with
defects. To overcome this, we must have review processes for the work done to remove any
defects.
10. Poor Management
 Not all project managers are naturally talented. Many of them learn managing things from
experience.
 If a project manager lacks experience in managing a project, then it is a big liability for the
project and it will show up in project results. Even if a project manager has experience, personal
traits dictate whether he can handle the project well or not.
 The project manager for a project must be chosen carefully, taking into account his experience13
and personal traits.
RISK CATEGORIES

1. Budget Risks
 If for some reason the budget goes above the permissible limit, then the project manager must
do something to control it.
 It is common practice for the project steering committee to decide to cut short some product
features to contain the project within the budget. But this is not a good practice.
 Instead, remedial action must be taken as soon as the project shows the risk of cost overrun, so
as to prevent the problem from actually happening. That is why, at all times, project expenses
should be tracked and controlled.
14
 Then there are cases when project cost control is not in the hands of the project manager.
 For instance, due to market forces, the salaries of team members have to be increased, otherwise
they might leave the project to get a better salary. In such instances, the management may decide to
increase salaries so that they do not leave. In such a case, the project manager has no choice but to
revise the project costs and inform the customer about it. This fact can adversely affect the project.
 To reduce the impact of budget risks, the budget allowance should include reserve funds. So
when such risks occur, allowances can be taken up from the reserves to avoid the project from
failing.
15
2. Time (Schedule) Risks
 Business opportunity loss may occur if project schedule slips. Project should never be allowed
to cross the targeted release dates.
 Due to unforeseen circumstances, the project dates may get affected. Sometimes, unexpected
rework to be done on software construction will lead to the slippage of the task schedule. There
may also be instances when due to a lack of proper communication, customer requirements are
completely misunderstood, resulting in an inappropriate product being delivered to the
customer, and thus, complete rework is required to prepare the software. This will again lead to
project schedule slippage.
To reduce the impact of schedule slippages,
a schedule allowance/buffer should be taken for
16
each time-related risk
3. Resource Risks
 On one hand, the project manager needs to keep project costs at the bare minimum, and on the
other, he has to make a provision for reserved project resources as contingency for any risk of
losing any project team member at any time during the execution of the project.
 Most projects run the real risk of team members leaving the project for more lucrative offers. In
such a situation, a project may suffer if any team member decides to leave the project midway.
 Generally, it is not a good idea to keep a paid reserve on the project as it would add to the cost
of the project. But keeping a pipeline open for probable replacements is a good idea. When a
replacement is needed, the project manager can tap this pipeline and get the replacement.
 But sometimes getting the right replacement takes time, and thus, the project suffers. This risk
can be mitigated by keeping a reserve in the project schedule for any delay in resource
17
replacement.
 This results in a big loss to the project. This risk can be mitigated to some extent by
implementing a knowledge management system.
 It will store all the knowledge acquired by team members during the project. It will also store
all the work performed by the project team.
 If a team member leaves the project, the knowledge acquired and the work done by him is in the
knowledge management system. Thus, the project team will not lose all the work that has been
done.

18
4. Quality Risks
 Supporting a poor quality software product becomes a losing proposition.
 The quality of the product may be poor due to bad software design or bad software construction. Even if it is
good, there is still a chance of defects inadvertently creeping in due to complexity, large integration interfaces,
or due to the large number of changes in the design when the requirements are altered.
 To deal with quality risks, the best policy is to have a check for quality integrated in the project schedule itself
(quality planning). This will ensure that the quality at the work product level is on par with the desired level.
Peer reviews, code reviews, and other formal quality review processes should be followed.

19
5. Technology Risks
 With the rapid introduction of new products into the market, older products quickly become
obsolete.
 Many projects face the prospect of having an outdated technology on which the software
product is being built. In such cases, the software product becomes unusable even before it is
implemented.
 Similarly, if any hardware component that may have been integrated with the software and the
hardware becomes obsolete, the software product becomes unusable.
 An appropriate selection of programming language, hardware platform, and user access
methods will make sure that the software product does not become obsolete during the expected
lifespan usage of the product.
20
 When selecting technology tools and techniques, contact the vendors to make sure that they will
be providing support in future as well for the tools you are buying from them.
RISK ANALYSIS

 The analysis should consider the kind of impact risk can have on the project as well as the
chance of it happening.
 Based on the analysis, you then need to sort risks and put them in order.
 Risks with high probability and high impact will be put on top of this list, while risks with low
impact and low probability will be put at the bottom.
 The project manager will then be better prepared to deal with all kinds of risks in a systematic
manner.

21
22
 Different risks occur at different times in the project.
 The product quality may not meet the expected standards during the design stage, and the design
may need to be reworked. The rework may stretch the project schedule and the project plan may
need to be redone. So, this is a risk that can occur at the design stage.
 During testing, a lot of unexpected defects might be found, and the time taken to fix these defects
will overshoot the budgeted time.
 A team member may fall sick and it may take time to replace him. This may cause a delay in
finishing the assignment that was given to the team member.

23
 project risks are dynamic in nature. They can occur at any stage of the project.
 So the project risk matrix where the project manager has listed risks and their impact as well as
their probability needs to be revised at regular intervals and the risks that are likely to happen at
that moment in time need to be assessed and remedial action should be taken.

24
BALANCING ACT
 No project can be executed 100% as per the project plan. There is bound to be something
different than planned due to the occurrence of any kind of risk and the subsequent impact it has
on the project.
 Each project is different. It depends on the importance of each deliverable on the project
compared to the other deliverables.
 At the top level, quality level considerations come from the kind of application being developed,
and for what purpose.
 If the application is meant for a general purpose information displaying system, and the end users
do not mind occasional bugs, then the quality level for the project can be compromised in
preference for costs or schedules.
 On the other hand, if the application needs accurate transactions without any compromise, then
quality cannot be undermined. In that case, costs or schedules can be allowed to overrun to get the25
desired level of quality
 These are all subjective considerations. The project manager must decide what limits to cross
and what limits to abide with. In doing so, he also should have consent from the project
stakeholders.

26
PROJECT RISK MANAGEMENT IN AGILE MODELS

 Using a waterfall model to execute your project is a big risk. It is because the
outcome of the project (the software product) is ready only after the whole project is
completed after a prolonged period of time.
 Suppose the project duration is 6 months, then the outcome of the project is known only after
investing time and money for these 6 months. The outcome could be positive or negative.
Waiting for such a long time to get the result is a big risk indeed.

27
PROJECT RISK MANAGEMENT IN AGILE MODELS

 To reduce this risk, iterative approaches to software development have been tried. Instead of
taking all the requirements and doing the entire product development in one go, requirements
are broken into small sets of manageable requirements. Each small set of requirements is then
used to develop a small product. The duration for making these small products (software
features) is kept at 4–6 weeks or even less. After each iteration, there is a product
deliverable/document that can be tested to see if it works as intended, and as per the
requirements.
 This approach reduces the big risk into a set of small risks.

28
 PROJECT RISK MANAGEMENT IN AGILE MODELS

 All the risks associated with the waterfall model are either miniaturized or totally eliminated in
the iterative model. They can be managed in a better way as well due to the small size of these
iterative projects.
29