ZeePedia buy college essays online


Software Project Management

<<< Previous Risk and Change Management: Risk Management Concepts Next >>>
 
img
Software Project Management (CS615)
LECTURE # 39
9. Risk and Change Management
9.1
Risk is defined as the possibility of loss. It is the inability to achieve program
objectives within defined cost, schedule, and technical constraints. Risk
management is a set of actions that helps the project manager plan an approach to
deal with uncertain occurrences.
A software project encounters two types of risks, development process risks and
product- related risks. Some of the development process risks are developer
errors, natural disasters, disgruntled employees, and poor management objectives.
Some project related risks are incomplete requirements, unclear project
deliverables and objectives, and complexity of the product.
The steps of risk management involve risk identification, risk analysis, and risk
mitigation. Risk identification involves identifying risks. Risks are identified after
discussion with team members about the requirements documents, available
technology, resources, and other project-related factors.
Contingency planning involves maintaining an alternative plan if the original plan
fails. Contingency plans are put to use when risks become a reality.
What is it? Risk analysis and management are a series of steps that help a
software team to understand and manage uncertainty. Many problems can plague
a software project A risk is a potential problem - it might happen, it might not But
regardless of the outcome, it's a really good idea to identify it, assess its
probability of occurrence, estimate its impact, and establish a contingency plan
should the problem actually occur.
Who does it? Everyone involved in the software process ­ managers, software
engineers and customers - participate in risk analysis and management
Why is it important? Think about the Boy Scout motto: "Be prepared" Software is
a difficult undertaking. Lots of things can go wrong, and frankly, many often do.
It's for this reason that being prepared, understanding the risks and taking
preventive measures to avoid or manage them is a key element of good software
project management.
What are the steps? Recognizing what can go wrong is the first step, called -
risk identification. Next, each risk is analyzed to determine the likelihood that it
will occur and the damage that it will do if it does occur. Once this information is
established, risks are ranked by probability and impact. Finally, a plan is
developed to manage those risks with high probability and high impact.
305
img
Software Project Management (CS615)
What is the work product? A risk mitigation monitoring and management
(RMMM) plan or a set of risk information sheets is produced. How do I ensure
that I've done it right? The risks that are analyzed and managed should be derived
from thorough study of the people, the product, the process and the project. The
RMMM should be revisited as the project proceeds to ensure that risks are kept up
to date. Contingency plans for risk management should be realistic.
9.2
Risk Management Concepts
Ever wondered why people insure their lives, their homes, their cars, or their
valuables? Suppose your house, along with all the valuables, is burgled. You will
be definitely disheartened. However, you will suffer less if all your valuables are
insured. At times such as these, you realize the importance of planning in advance
for the uncertain events in your life. Just as you plan for unforeseen events in your
life, project managers also need to prepare for uncertainties affecting projects. All
project management skills of a project manager can fall in the face of
uncertainties and unplanned problems.
Robert Charette [CHA89] presents a conceptual definition of risk:
·
First, risk concerns future happenings, Today and yesterday are beyond active
concern, as we are already reaping what was previously sowed by our past
actions, The question is, can we, therefore, by changing our actions today,
create an opportunity for a different and hopefully better situation for
ourselves tomorrow
·
This means, second, that risk involves change, such as in changes of mind,
opinion, actions, or places
·
Third risk involves choice, and the uncertainty that choice itself entails, thus
paradoxically, risk, like death and taxes, is one of the few certainties of life,
When risk is considered in the context of software engineering, Charette's three
conceptual underpinnings are always in evidence. The future is our concern ­
what risks might cause the software project to go awry? Change is our concern -
how will changes in customer requirements, development technologies, target
computers, and all other entities connected to the project affect timeliness and
overall success? Last, we must grapple with choices - what methods and tools
should we use, how many people should be involved, how much emphasis on
quality is "enough"?
Any project can encounter uncertainties in the form of increased costs, schedule delays,
and diminished qualities. Unless tackled, these uncertainties can lead to major project
disasters. The uncertainties encountered during project execution are the potential project
risks. Every software project has to grapple with the new risks threatening information
306
img
Software Project Management (CS615)
security along with the conventional risks, such as hardware failure, time and cost
escalation, defects, or resource crunch. Risk can be defined as the possibility of loss. Risk
arises due to the inability to achieve objectives within defined cost, schedule, and
technical constraints. Risk has two components. The possibility of not achieving a
particular outcome is one, and the result of failing to achieve the outcome is the other.
The former is the probability of loss, and the latter is the loss. Software project
management deals with managing both these components of risk.
According to the risk management guru Barry Boehm, "Risk management focuses the
project manager's attention on those portions of the project most likely to cause trouble
and compromise participants' win conditions." In other words, risk management is a set
of actions that helps the project manager plan to deal with uncertain occurrences. It is
through risk management that project managers assess risks and manage to reduce risks
to an acceptable level.
Software risk management is not about managing risks faced by a software organization.
Here, the focus is on managing risks encountered during software development process.
Therefore, the concern is about managing the future of a software project.
In this chapter, you will 1ook at the unforeseen events that might affect a software
project. You will also learn about the steps for managing and mitigating software project
risks.
Types of Risks
To be able to manage project risks, you must first understand what constitutes, a risk. All
uncertain occurrences are not risks. Only those occurrences that have an adverse impact
on the progress of a project are risks to the project. Risk is not a bad thing. Risk is bad
only when it results in loss for an organization. Unless there is a potential for loss, there
is no risk. Moreover, loss can be interpreted as either a bad outcome or a lost opportunity.
The tendency of most project managers is to jump at the statement this is a risk.
However, the desired reaction is to pre-empt all possible outcome and plan for them.
Project risks can be broadly categorized into development process risks and product risks.
Development Process Risks
The risks encountered during product development are categorized as development
process risks. These comprise developer errors, natural disasters, disgruntled employees,
and poor management objectives.
Developer errors could be attributed to poor training due to budgetary constraints and
inadequate skills and software tools. Ergonomic problems, environment problems, and
interruptions or distractions at office also account for developer risks. Other risks in this
category include problems in personnel acquisition and retention.
Similarly, natural disasters such as flood, cyclone, fire, storm, and snowfall are also risks
to a project.
Disgruntled employees can also become a risk to an organization. For example, a sacked
employee can use password snuffers to gain unauthorized access. A dismissed person can
307
img
Software Project Management (CS615)
flood the system with senseless messages. A disgruntled employee can also try to
sabotage the project work by destroying files and programs.
A poorly defined management objective is another development process risk. If the
language in the management objective is ambiguous and not stated clearly, the risk
management program will not function properly. Narrowly focused and changing
objectives that are not updated can also be counted as risks. Lack of contingency plans,
incomplete cost estimates, and unrealistic schedules are also potential risks in a project.
Similarly, unrealistic performance standards are also potential risks to the development
process. Other possible risks include contractual risks, technological risks, and
inadequate documentation of other concurrent projects.
Product Risks
Product risks crop up in the form of changing requirements during product development.
Incomplete and unclear requirements are a risk to the product during development.
Similarly, problems in meeting design specifications can also be categorized as risk to
product development.
Risks could arise if the project deliverables or objectives are not clearly defined or if
technical data is missing. The possibility of several alternatives at any given time during
the project is also a cause of concern. If errors are not recognized during the design
phase, they could turn into risks for the project. Similarly, risks could arise due to the size
and complexity of the product or while achieving client acceptance of the product.
Note:
The key idea in risk management is not to wait for a risk to materialize and
become a problem. The objective of risk management is to ensure that for each
perceived risk, you know well in advance how to tackle it.
Risk Management Process
Project Risk Management includes the processes concerned with conducting risk
management planning, identification, analysis, responses, and control on a project. The
objectives of Risk Management are to increase the probability and impacts of positive
events and decrease the probability and impacts of events adverse to project objectives.
The process of risk management begins during the analysis phase of software
development life cycle. However, the actual process of managing risks continues
throughout the product development phase. Risk management is a dynamic process
because it deals with the activities that are yet to happen. Risk management has a two-
fold agenda. First, deciding actions for preventing risks from happening, and second,
deciding actions for tackling risks that materialize. Therefore, risk management is all
about pre-empting a risk, coming up with a plan for resolving the risk, and finally
executing the plan.
Figure 6.1 displays the steps of the risk management process. Formally, articulated, risk
management process consists of three steps:
1. Risk identification
2. Risk analysis
308
img
Software Project Management (CS615)
3. Risk mitigation
Figure 6.1: Risk Management Process
Risk Management
Risk
Risk
Risk Identification
Analysis
Mitigation
Risk Probability
Risk Avoidance
Risk Impact
Risk Monitoring
Risk Factor
Contingency Planning
Risk Identification
In this step, the project manager gathers information about the potential risks in the
project. The project manager plans the strategies for avoiding risks or controlling them.
The project team conducts brainstorming sessions and discussions among team members
about the requirements document. They discuss the available technology, manpower,
prevailing environment, and all project-related factors. The project manager picks up the
thread from these and creates a risk log. After the risk log is prepared, the project
manager calls a meeting within the team and technical experts to discuss the risk log and
the mitigation plans. An effective way of identifying' risks is using a questionnaire.
Table 6.1 displays a sample risk identification questionnaire.
Table 6.1: Sample Risk Identification Questionnaire
Yes/No/Not Applicable
SN
Risk Description
(NA)
A.
Product Engineering
Are requirements changing continuously during
1)
product development?
Do the changing requirements affect each of the
2)
following:
Quality
Functionality
Schedule
Integration
Design
Testing
309
img
Software Project Management (CS615)
3)
Are the external interfaces changing?
Are the requirements missing or incompletely
4)
specified?
5)
Are there any missing requirements?
Can these requirements be incorporated into the
6)
system?
Does the client have unwritten requirements or
7)
expectations?
8)
Is there a way to capture these requirements?
9)
Are requirements unclear or in need of interpretation?
Are you able to understand the requirements as
10)
written?
Will the requirements lead to the product the client
11)
wants?
Are there any requirements that may not specify what
12)
the client really wants?
B.
Product Design
Do you encounter problem in meeting functionality
1)
requirements?
Are there any specified algorithms that may not
2)
satisfy the requirements?
Will the design and/or implementation be difficult to
3)
achieve?
Are there any requirements or functions that are
4)
difficult to design?
C.
Reusability
1)
Are you reusing the program?
2)
Do you foresee any problems in documentations?
3)
Do you foresee any problems in performance?
4)
Do you foresee any problems in functionality?
The sample questionnaire in Table 6.1 includes an exhaustive list of risks that might be
encountered during the progress of a project. The answers to the questions in the risk
identification questionnaire enable the project manager to estimate the impact of risks. In
the sample questionnaire Table 6.1, the risks are categorized under product engineering,
product-design, and reusability. From this table, you obtain a list of risks that are relevant
to each category. You compare the information obtained from this table with past results
and estimate the criticality of risk. In short, during risk identification, you obtain answers
to the following queries:
·
Why is the risk important?
·
What information is needed to track the status of the risk?
·
Who is responsible for the risk management activity?
·
What resources are needed to perform the activity?
·
What is the detailed plan to improve the risk and / or mitigate it?
310
img
Software Project Management (CS615)
Risk Analysis
After identifying the risks, the project manager needs to analyze the risks. Uncertainty
and loss are the two characteristics of risk. The uncertainty factor in risk means that the
unknown event mayor may not happen. While analyzing risks, the project manager needs
to quantify the level of uncertainty and the degree of loss. Based on this, the project
manager plans schedules and costs. During analysis, information on risk is converted into
information on decision-making. Analysis provides the basis for the project manager to
work on the "right" risks.
Table 6.2: Risk Analysis Table
Probability of
Impact on
Risk Factor
Risk
Occurrence
Project
(Probability x
Description
(0 ­ 1)
(1 ­ 10)
Impact)
Table 6.2 displays a risk analysis format. There are various tasks involved in risk
analysis. First, the WBS elements are identified. One of the tasks in the risk analysis
phase is to describe the risk. The risk can be product-related, process-related,
organization-related, client-related, or infrastructure-related.
Second, the WBS elements are evaluated to determine the risk events. Then the project
manager quantifies the probability of occurrence of risk. The project manager can assign
probability values between 0 and 1. For example, a risk with a low probability of
occurrence is marked 0.2 while that with a high probability of occurrence is marked 0.8.
The reason why a particular risk has a high or low probability depends on the actual
circumstance of the project.
Third, the risks are rated depending on their probability of occurrence. Based on the
probability of risk, the project manager identifies the impact of the risk. The impact of
risk on cost, schedule, and quantity needs to be calculated and graded. The impact of risk
can be graded on a scale of 1 to 10, 1 being the lowest, and 10 being the highest.
Then the risk factor is calculated by multiplying the probability of risk and the impact of
risk. Finally, each risk is prioritized relative to other risks. The risk factor is used to
prioritize the identified risks. For example, the risk with a probability value 0.1 and an
impact value 2 will have minimal impact. While risks close to probability value 0.8 and
with an impact value 9 will have greater impact. Therefore, the project manager can
prioritize risks based on the probability and the impact of risks. A risk that has a high
impact and low probability will not absorb a significant amount of the project manager's
time. However, high-impact risks with moderate to high probability will catch the
attention of the project manager.
311
img
Software Project Management (CS615)
Risk Mitigation
Risk mitigation is the best possible approach adopted by the project manager to avoid
risks from occurring. The probability of the risk occurring and the potential impact of the
risk can be mitigated by dealing with the problem early in the project. Essentially, risk
mitigation involves three possibilities and the project manager needs to adopt a risk
mitigation strategy aimed at them. The three possibilities include:
·  Risk avoidance
·  Risk monitoring
·  Contingency planning
Risk Avoidance
To avoid risks from occurring, the project team prepares the risk plan before the
commencement of the project. The project team identifies the potential risks and
prioritizes them based on their probability of occurrence and impact. Then, the team
prepares a plan for managing risks. In most software projects, this plan is popularly called
the risk management plan. Table 6.3 displays the format of a risk management plan.
Table 6.3: Risk Management Plan
Impact
Probability
Risk
on
Risk
of
Factor
Mitigation
Start  End
Project
Responsibility
Description Occurrence
(Probability
Steps
Date Date
(1 ­
(0 ­ 1)
x Impact)
10)
To prepare the risk management plan, the project team first identifies and assesses the
risks associated with the project. Then, the probability of occurrence of each risk is
estimated and the possible impact is calculated. In the plan, the probable cost and damage
is also quantified. The project team also identifies the contingency plans for all the
identified risks. The contingency plan for each risk is based on the project's defined
operational software process. The plan is modified throughout the software development
life cycle of the project based on the changes taking place. The contingency plan also
includes the cost, in terms of effort, in carrying out the plan. The software risks identified
are tracked, reassessed, and re-planned at the end of each phase. The project manager
revisits the plan if significant changes are introduced in the software project.
Risk Monitoring
As the project proceeds, risk-monitoring activities commence. It is not possible to
monitor closely all the risks that are identified for the project. For example, if 100 risks
are identified for a project, only top 20 risks are monitored. There are re-planning
checkpoints where the information obtained from monitoring the risks is used to refine
the risk assessments and management plan. The project manager monitors the top 20
312
img
Software Project Management (CS615)
percent of the factors that may indicate the status of the risks in the project. In the case of
large teams, the project manager also needs to monitor the attitude of the team members
and their problems. This helps the project manager monitor any possible team-related
risks.
Besides monitoring the top 20 percent of the risks, the project manager needs to monitor
the mitigation steps also. Consider an example. To ensure that particular software is
browser- independent, the software is created on the lowest compatible browser. Such
software will work on any browser thus making it browser-independent. Therefore,
mitigating a project risk involves working hard at reducing the possibility that the risk
will ever occur. Mitigation includes nearly all actions that a project team takes to
overcome risks. For example, choosing a more expensive but proven technology over, a
newer, less expensive technology is a step toward mitigating project risks.
Contingency Planning
The possibility of contingency planning arises when mitigation efforts fail and risk
becomes a reality. Contingency planning is used to monitor risks and invoke a
predetermined response. According to the plan, a trigger is set up. If the trigger is
reached, the contingency plan is put into effect. Contingency planning involves
maintaining an alternative plan if the original plan fails. A simple example could be the
savings people make for a rainy day. Contingency plans are a must for the top 20 percent
of the risks identified. These plans are put to use after the risks become a reality. The
importance of contingency planning can be realized from this example. Despite the
massive attack on WTC, the stock markets in the US resumed functioning within a few
days. This was possible because the finance companies had backed up their data and
information on computers elsewhere. The contingency planning of finance companies
prevented the risk of huge data loss for the stock market.
Managing Risks: Case Study
Consider a scenario. Your organization is a vendor of software solutions. A bus transport
company the US wants you to develop a Schedule Adherence system. The team that will
develop this software is new and the platform selected for development is also new to
your organization. The project team needs to be trained intensively for this.
During this project, the team is expected to manage a large volume of data. The team has
never had any experience in managing such a large volume of data. The system also
needs to use this data to generate various MIS reports related to delays or adherence of
bus services.
The performance requirement is less than fifteen seconds for all popular browsers. Your
organization is anticipating numerous requirement changes during the development
process. The system needs to be implemented across several states in the country. The
data related to the system is highly confidential because it can provide an edge to the
competitors.
Now, as a project manager, you need to prepare a risk management plan for this project.
The project starts on May 15 and should be completed on November 15.
313
img
Software Project Management (CS615)
First, you need to identify the potential risks involved in the project. The potential risks to
the project are described in Table 6.4.
Table 6.4: Potential Risks to a Project
Risk Description
Inexperienced staff
Performance risk due to high volume of data to be processed
Cross-browser compatibility
Involvement of new technology
Design changes during development
After identifying the risks, you need to estimate the probability of their occurrence and
their impact on product development. Based on this, you calculate the risk factor and plan
the mitigation steps.
Your risk management plan is displayed in Table 6.5.
Table 6.5: The Risk Management Plan for Building a Schedule Adherence System
Impact
Probability
Risk
on
Risk
of
Factor
Mitigation
Start End
Project
Responsibility
Description
Occurrence
(Probability Steps
Date  Date
(1 ­
(0 ­ 1)
x Impact)
10)
Conducting
training
Inexperience
Project
sessions before
May
July
0.8
3
2.4
Staff
Manager
the need
15
15
commencement
of project
Massive tuning
of architecture
Performance
Till
during the
risk due to
the
design phase
May
high volume
0.6
7
4.2
Architect
end of
and conducting
15
of data to be
the
a proof of
processed
project
concepts for
the design
Cross-
Using the
May
Till
0.6
5
3.0
Developer
browser
lowest
15
the
314
img
Software Project Management (CS615)
compatibility
compatible
end of
browser for
the
development
project
Ensuring all
details
pertaining to
Till
the technology
Involvement
the
Project
is available and
of new
0.5
5
2.5
May
end of
Manager
keeping in
technology
the
close touch
project
with the
technology
vendor
Designing a
flexible
Till
Design
architecture
the
changes
that can
May
0.6
8
4.8
Architect
end of
during
accommodate
15
the
development
future changes
project
and
enhancement
In Table 6.5, the risk factors with high values are the high priority risks. Here, the high
priority risks are design changes during development, performance risk due to high
volume of data to be processed, and cross-browser compatibility. The high priority risks
need to be monitored closely and continuously. The rest of the risks can be monitored
periodically. Certain risks need contingency planning despite being low in the priority
list. For example, the risk due to involvement of new technology is a low priority risk.
However, the probability of occurrence of this risk is 0.5, which is fairly high. This calls
for contingency planning because you may not be aware of all the details of the new
technology. Suppose the system fails to respond if the number of users exceeds a certain
number. In such a situation, you need to have a contingency plan ready. You need to
discuss with the vendor regarding a workaround for such a situation. The workaround
should be ready in the case of failure of the system.
Robert Charette [CHA89] presents a conceptual definition of risk:
First, risk concerns future happenings, Today and yesterday are beyond active concern, as
we are already reaping what was previously sowed by our past actions, The question is,
can we, therefore, by changing our actions today, create an opportunity for a different and
hopefully better situation for ourselves tomorrow, This means, second, that risk involves
change, such as in changes of mind, opinion, actions, or places...[Third] risk involves
choice, and the uncertainty that choice itself entails, Thus paradoxically, risk, like death
and taxes, is one of the few certainties of life,
315
img
Software Project Management (CS615)
When risk is considered in the context of software engineering, Charette's three
conceptual underpinnings are always in evidence. The future is our concern ­ what risks
might cause the software project to go awry? Change is our concern -how will changes in
customer requirements, development technologies, target computers, and all other entities
connected to the project affect timeliness and overall success? Last, we must grapple with
choices - what methods and tools should we use, how many people should be involved,
how much emphasis on quality is "enough"?
What is it? Risk analysis and management are a series of steps that help a software team
to understand and manage uncertainty. Many problems can plague a software project A
risk is a potential problem - it might happen, it might not But regardless of the outcome,
it's a really good idea to identify it, assess its probability of occurrence, estimate its
impact, and establish a contingency plan should the problem actually occur.
Who does it? Everyone involved in the software process ­ managers, software engineers
and customers - participate in risk analysis and management
Why is it important? Think about the Boy Scout motto: "Be prepared" Software is a
difficult undertaking. Lots of things can go wrong, and frankly, many often do. It's for
this reason that being prepared, understanding the risks and taking preventive measures to
avoid or manage them is a key element of good software project management.
What are the steps? Recognizing what can go wrong is the first step, called - risk
identification. Next, each risk is analyzed to determine the likelihood that it will occur
and the damage that it will do if it does occur. Once this information is established, risks
are ranked by probability and impact. Finally, a plan is developed to manage those risks
with high probability and high impact.
What is the work product? A risk mitigation monitoring and management (RMMM)
plan or a set of risk information sheets is produced.
How do I ensure that I've done it right? The risks that are analyzed and managed
should be derived from thorough study of the people, the product, the process and the
project. The RMMM should be revisited as the project proceeds to ensure that risks are
kept up to date. Contingency plans for risk management should be realistic.
6.1
REACTIVE VS. PROACTIVE RISK STRATEGIES
Reactive strategies have been laughingly called the "Indiana Jones School of risk
management" [THO92]. In the movies that carried his name, Indiana Jones, when faced
with overwhelming difficulty, would invariably say, "Don't worry, I'll think of
something!" Never worrying about problems until they happened, Indy would react in
some heroic way.
Sadly, the average software project manager is not Indiana Jones and the members of the
software project team are not his trusty sidekicks. Yet, the majority of software teams
rely solely on reactive risk strategies. At best, a reactive strategy monitors the project for
likely risks. Resources are set aside to deal with them, should they become actual
problems. More commonly, the software team does nothing about risks until something
goes wrong. Then, the team flies into action in an attempt to correct the problem rapidly.
316
img
Software Project Management (CS615)
This is often called a fire fighting mode. When this fails, "Crisis Management" [CHA92]
takes over, and the project is in real jeopardy.
A considerably more intelligent strategy for risk management is to be proactive. A
proactive strategy begins long before technical work is initiated. Potential risks are
identified, their probability and impact are assessed and they are ranked by importance.
Then, the software team establishes a plan for managing risk. The primary objective is to
avoid risk, but because not all risks can be avoided, the team works to develop a
contingency plan that will enable it to respond in a controlled and effective manner.
6.2 SOFTWARE RISKS
Although there has been considerable debate about the proper definition for software risk,
there is general agreement that risk always involves two characteristics [HIG 95]:
·
Uncertainty - the risk may or may not happen; that is, there are no 100 % probable
risks.
·
Loss - if the risk becomes a reality, unwanted consequences or losses will occur.
When risks are analyzed, it is important to quantify the level of uncertainty and the
degree of loss associated with each risk. To accomplish this, different categories of risks
are considered.
Project risks threaten the project plan. That is, if project risks become real, it is likely that
project schedule will slip and that costs will increase. Project risks identify potential
budgetary, schedule, personnel (staffing and organization), resource, customer, and
requirements problems and their impact on a software project. In Chapter 5, project
complexity, size, and the degree of structural uncertainty were also defined as project
(and estimation) risk factors.
Technical risks threaten the quality and timeliness of the software to be produced. If a
technical-risk becomes a reality, implementation may become difficult or impossible.
Technical risks identify potential design, implementation, interface, verification, and
maintenance problems. In addition, specification ambiguity, technical uncertainty,
technical obsolescence, and "leading-edge" technology are also risk factors. Technical
risks occur because the problem is harder to solve than we thought it would be.
Business risks threaten the viability of the software to be built. Business risks often
jeopardize the project or the product. Candidates for the top five business risks are (1)
building a excellent product or system that no one really wants (market risk), (2) building
a product that no longer fits into the overall business strategy for the company (strategic
risk), (3) building a product that the sales force doesn't understand how to sell, (4) losing
the support of senior management due to a change in focus or a change in people
(management risk), and (5) losing budgetary or personnel commitment (budget risks). It
is extremely important to note that simple categorization won't always work. Some risks
are simply unpredictable in advance.
317
img
Software Project Management (CS615)
Another general categorization of risks has been proposed by Charette [CHA89J. Known
risks are those that can be uncovered after careful evaluation of the project plan, the
business and technical environment in which the project is being developed, and other
reliable information sources (e.g., unrealistic delivery date, lack of documented
requirements or software scope, poor development environment). Predictable risks are
extrapolated from past project experience (e.g., staff turnover, poor communication with
the customer, dilution of staff effort as ongoing maintenance requests are serviced).
Unpredictable risks are the joker in the deck. They can and do occur, but they are
extremely difficult to identify in advance.
6.3 RISK IDENTIFICATION
Risk identification is a systematic attempt to specify threats to the project plan (estimates,
schedule, resource loading, etc.). By identifying known and predictable risks, the project
manager takes a first step toward avoiding them when possible and con- trolling them
when necessary.
There are two distinct types of risks for each of the categories that have been presented in
Section 6.2: generic risks and product-specific risks. Generic risks are a potential threat to
every software project. Product-specific risks can be identified only by those with a clear
understanding of the technology, the people, and the environment that is specific to the
project at hand. To identify product -specific risks, the project plan and the software
statement of scope are examined and an answer to the following question is developed:
What special characteristics of this product may threaten our project plan?
One method for identifying risks is to create a risk item checklist. The checklist can be
used for risk identification and focuses on some subset of known and predictable risks in
the following generic subcategories:
·
Product size-risks associated with the overall size of the software to be built or
modified.
·
Business impact-risks associated with constraints imposed by management or the
marketplace.
·
Customer characteristics-risks associated with the sophistication of the customer
and the developer's ability to communicate with the customer in a timely manner.
·
Process definition-risks associated with the degree to which the software process
has been defined and is followed by the development organization.
·
Development environment-risks associated with the availability and quality of the
tools to be used to build the product.
·
Technology to be built-risks associated with the complexity of the system to be
built and the newness of the technology that is packaged by the system.
·
Staff size and experience-risks associated with the overall technical and project
experience of the software engineers who will do the work.
318
img
Software Project Management (CS615)
The risk item checklist can be organized in different ways. Questions relevant to each of
the topics can be answered for each software project. The answers to these questions
allow the planner to estimate the impact of risk. A different risk item checklist format
simply lists characteristics that are relevant to each generic subcategory. Finally, a set of
"risk components and drivers" [AFC88] are listed along with their probability of
occurrence. Drivers for performance, support, cost, and schedule are discussed in answer
to later questions.
A number of comprehensive checklists for software project risk have been proposed in
the literature (e.g., [SEI93], [KAR96]). These provide useful insight into generic risks for
software projects and should be used whenever risk analysis and management is
instituted. However, a relatively short list of questions [KEI98] can be used to provide a
preliminary indication of whether a project is "at risk."
6.3.1 Assessing Overall Project Risk
The following questions have derived from risk data obtained by surveying experienced
software project managers in different part of the world [KEI98]. The questions are
ordered by their relative importance to the success of a project.
1. Have top software and customer managers formally committed to support the project?
2. Are end-users enthusiastically committed to the project and the system/product to be
built?
3. Are requirements fully understood by the software engineering team and their
customers?
4. Have customers been involved fully1n the definition of requirements?
5. Do end-users have realistic expectations?
6. Is project scope stable?
7. Does the software engineering team have the right mix of skills?
8. Are project requirements stable?
9. Does the project team have experience with the technology to be implemented?
10. Is the number of people on the project team adequate to do the job?
11. Do all customer/user constituencies agree on the importance of the project and on the
requirements for the system/product to be built?
If anyone of these questions is answered negatively, mitigation, monitoring, and
/management steps should be instituted without fail. The degree to which the project is at
risk is directly proportional to the number of negative responses to these questions.
6.3.2 Risk Components and Drivers
The U.S. Air Force [AFC88j has written a pamphlet that contains excellent guidelines (or
software risk 1dentification and abatement. The Air Force approach requires that the
project manager identify the risk drivers that affect software risk components-
Performance, cost, support, and schedule. In the context of this discussion, the risk
components are defined in the following manner:
319
img
Software Project Management (CS615)
·
Performance risk - the degree of uncertainty that the product will meet its
requirements and be fit for its intended use.
·
Cost risk - the degree of uncertainty that the project budget will be maintained.
·
Support risk - the degree of uncertainty that the resultant software will be easy to
correct, adapt, and enhance.
·
Schedule risk - the degree of uncertainty that the project schedule will be
maintained and that the product will be delivered on time.
The impact of each risk driver on the risk component is divided into one of four impacts
categories-negligible, marginal, critical, or catastrophic. Referring to Figure 6.1
[BOE89], a characterization of the potential consequences of errors (rows labeled 1) or a
failure to achieve a desired outcome (rows labeled 2) are described. The impact category
is chosen based on the characterization that best fits the description in the table.
Figure 6.1 Impact assessment
Components/Category
Performance  Support
Cost
Schedule
1 Failure
to
meet
the
Failure
results
in
Catastrophic
requirement would result in
increased
costs
and
mission failure
schedule  delays  with
expected values of $500
K
2 Significant
Non
Significant  Unavoidable
degradation to responsive or
financial
IOC
non
unsupportable
shortages,
achievement
software
budget
of  technical
overrun
performance
likely
1 Failure
to
meet
the
Failure
results
in
Critical
requirement  would  degrade
operational delays and/or
system performance to a point
increased
costs
with
where  mission  success  is
expected $100 K to $ 500
questionable
K
2 Some
Minor delays
Some
Possible
reduction  in in
software
shortage of slippage  in
technical
modification
financial
IOC
performance
resources,
possible
overruns
1 Failure
to
meet
the
Costs, impacts and / or
Marginal
requirement would result in
recoverable schedule slips
degradation  of  secondary
with expected value of $ 1
mission
K to $ 100 K
320
img
Software Project Management (CS615)
to Responsive
Sufficient
Realistic
2 Minimal
small
software
financial
achievable
reduction  in support
resources
schedule
technical
performance
1 Failure
to
meet
the
Error results in minor cost
Negligible
requirement  would  create
and / or schedule impact
inconvenience
or
non
with expected value of
operational impact
less than $ 1 K
2 No reduction Easily
Possible
Early
in
technical supportable
budget
achievable
performance
software
under run
IOC
Note:
(1) The potential consequence of undetected software errors or faults.
(2) The potential consequence if the desired outcome is not achieved.
6.4 RISK PROJECTION
Risk projection, also called risk estimation, attempts to rate each risk in two ways-the
likelihood or probability that the risk is real and the consequences of the problems
associated with the risk, should it occur. The project planner, along with other managers
and technical staff, performs four risk projection activities:
(1) Establish a scale that reflects the perceived likelihood of a risk,
(2) Delineate the consequences of the risk,
(3) Estimate the impact of the risk on the project and the product, and
(4) Note the overall accuracy of the risk projection so that there will be no
misunderstandings.
6.4.1 Developing a Risk Table
A risk table provides a project manager with a simple technique for risk projection. A
sample risk table is illustrated in figure 6.2.
Figure 6.2 Sample risk table prior to sorting
Risks
Category
Probability
Impact
RMMM
Size estimate may be significantly low
PS
60%
2
Larger number of users than planned
PS
30%
3
Less reuse than planned
PS
70%
2
End-users resist system
BU
40%
3
Delivery deadline will be lightened
BU
50%
2
Funding will be lost
CU
40%
1
Customer will change requirements
PS
80%
2
Technology will not meet expectations
TE
30%
1
Lack of training on tools
DE
80%
3
321
img
Software Project Management (CS615)
Staff inexperienced
ST
80%
2
Staff turnover will be high
ST
60%
2
Impact values:
l- Catastrophic
2- Critical
3- marginal
4- Negligible
A project team begins by listing all risks (no matter how remote) in the first column of
the table. This can be accomplished with the help of the risk item check-lists referenced
in Section 6.3. Each risk is categorized in the second column (e.g., PS implies a project
size risk, BU implies a business risk). The probability of occurrence of each risk is
entered in the next column of the table. The probability value for each risk can be
estimated by team members individually. Individual team members are polled in round-
robin fashion until their assessment of risk probability begins to converge.
Next, the impact of each risk is assessed. Each risk component is assessed using the
characterization presented in Figure 6.1, and an impact category is determined. The
categories for each of .the four risk components - performance, support, cost, and
schedule - are averaged to determine an overall impact value.
Figure 6.3 Risk and management concern
Very
hh
High
Impact
Disregard
risk factor
Management
concern
Very
low
0
Probability
1.0
Of occurrence
Once the first four columns of the risk table have been completed, the table is sorted by
probability and by impact. High-probability, high-impact risks percolate to the top of the
322
img
Software Project Management (CS615)
table, and low-probability risks drop to the bottom. This accomplishes first order risk
prioritization. The project manager studies the resultant sorted table and defines a cutoff
line. The cutoff line (drawn horizontally at some point in the table) implies that only risks
that lie above the line will be given further attention. Risks that fall below the line are re-
evaluated to accomplish second-order prioritization. Referring to Figure 6.3, risk impact
and probability have a distinct influence on management concern. A risk factor that has a
high impact but a very low probability of occurrence should not absorb a significant
amount of management time. However, high-impact risks with moderate to high
probability and low-impact risks with high probability should be carried forward into the
risk analysis steps that follow.
All risks that lie above the cutoff line must be managed. The column labeled RMMM
contains a pointer into Risk Mitigation, Monitoring and Management Plan or
alternatively, a collection of risk information sheets developed for all risks that lie above
the cutoff. The RMMM plan and risk information sheets are discussed in Sections 6.5 and
6.6.
Risk probability can be determined by making individual estimates and then developing a
single consensus value. Although that approach is workable, more sophisticated
techniques for determining risk probability have been developed [AFC88]. Risk drivers
can be assessed on a qualitative probability scale that has the following values:
impossible, improbable, probable, and frequent. Mathematical probability can then be
associated with each qualitative value (e.g., a probability of 0.7 to 1.0 implies a highly
probable risk).
6.4.2 Assessing Risk Impact
Three factors affect the consequences that are likely if a risk does occur: its nature, its
scope, and its timing. The nature of the risk indicates the problems that are likely if it
occurs. For example, a poorly defined external interface to customer hardware (a
technical risk) will preclude early design and testing and will likely lead to system
integration problems late in a project. The scope of a risk combines the severity (just how
serious is it?) with its overall distribution (how much of the project will be affected or
how many customers are harmed?). Finally, the timing of a risk considers when and for
how long the impact will be felt. In most cases, a project manager might want the "bad
news" to occur as soon as possible, but in some cases, the longer the delay, the better.
Returning once more to the risk analysis approach proposed by the U.S. Air Force
fAFC88), the following steps are recommended to determine the overall consequences of
a risk:
1. Determine the average probability of occurrence value for each risk component.
2. Using Figure 6.1, determine the impact for each component based on the criteria
shown.
3. Complete the risk table and analyze the results as described in the preceding sections. .
323
img
Software Project Management (CS615)
The overall risk exposure, RE, is determined using the following relationship [HAL98]:
RE=P x C.
where P is the probability of occurrence for a risk, and C is the cost to the project should
the risk occur.
For example, assume that the software team defines a project risk in the following
manner:
Risk identification. Only 70 percent of the software components scheduled for reuse
will, in fact, be integrated into the application. The remaining functionality will have to
be custom developed.
Risk probability. 80% (likely).
Risk impact. 60 reusable software components were planned. If only 70 percent can be
used, 18 components would have to be developed from scratch (in addition to other
custom software that has been scheduled for development). Since the average component
is 100 LOC and local data indicate that the software engineering cost for each LOC is
$14.00, the overall cost (impact) to develop the components would be 18 x 100 x 14 =
$25,200.
Risk exposure. RE = 0.80 x 25,200 - $20,200.
Risk exposure can be computed for each risk in the risk table, once an estimate of the cost
of the risk is made. The total risk exposure for all risks (above the cutoff in the risk table)
can provide a means for adjusting the final cost estimate for a project. It can also be used
to predict the probable Increase In staff resources required at various points during the
project schedule.
The risk projection and analysis techniques described in Sections 6.4.1 and 6.4.2 are
applied iteratively as the software project proceeds. The project team should revisit the
risk table at regular intervals, re-evaluating each risk to determine when new
circumstances cause its probability and impact to change. As a consequence of this
activity, it may be necessary to add new risks to the table, remove some risks that are no
longer relevant, and change the relative positions of still others.
6.4.3 Risk Assessment
At this point in the risk management process, we have established a set of triplet of the
form [CHA89]:
[rj, lj, xj]
where rj is risk, lj is the likelihood (probability) of the risk, and xj is the impact of the risk.
During risk assessment, we further examine the accuracy of the estimates that were made
during risk projection, attempt to rank the risks that have been uncovered, and begin
thinking about ways to control and/or avert risks that are likely to occur.
324
img
Software Project Management (CS615)
Figure 6.4 Risk referent level
Referent point (cost value, time value)
Projected
Project termination will
schedule
overrun
Projected cost overrun
For assessment to be useful, a risk referent level [CHA89] must be defined. For most
software projects, the risk components discussed earlier - performance, cost, support, and
schedule also represent risk referent levels: That is, there is a level for performance,
degradation, cost overrun, support difficulty, or schedule slippage (or any combination of
the four) that will cause the project to be terminated. If a combination of risks create
problems that cause one or more of these referent levels to be exceeded, work will stop.
In the context of software risk analysis, a risk referent level has a single point, called the
referent point or break point, at which the decision to proceed with the project or
terminate it (problems are just too great) are equally weighted. Figure 6.4 represents this
situation graphically.
In reality, the referent level can rarely be represented as a smooth line on a graph. In most
cases it is a region in which there are areas of uncertainty; that is, attempting to predict a
management decision based on the combination of referent values is often impossible.
Therefore, during risk assessment, we perform the following steps:
1. Define the risk referent levels for the project.
2. Attempt to develop a relationship between each (rj, lj, xj) and each of the referent
levels.
3. Predict the set of referent points that define a region of termination, bounded by a
curve or areas of uncertainty.
4. Try to predict how compound combinations of risks will affect a referent level.
6.5 RISK REFINEMENT
325
img
Software Project Management (CS615)
During early stages of project planning, a risk may be stated quite generally. As time
passes and more is learned about the project and the risk, it may be possible to refine the
risk into a set of more detailed risks, each somewhat easier to mitigate, monitor, and
manage.
One way to do this is to represent the risk in condition-transition-consequence (CTC) II
format [GLU94). That is, the risk is stated in the following form:
Given that <condition> then there is concern that (possibly) <consequence>.
Using the CTC format for the reuse risk noted in Section 6.4.2, we can write:
Given that all reusable software components must conform to specific design standards
and that some do not conform, then there is concern that (possibly) only 70 percent of the
planned reusable modules may actually be integrated into the as-built system, resulting in
the need to custom engineer the remaining 30 percent of components. This general
condition can be refined in the following manner:
Sub condition 1. Certain reusable components were developed by a third party with no
knowledge of internal design standards.
Sub condition 2. The design standard for component interfaces has not been solidified
and may not conform to certain existing reusable components.
Sub condition 3. Certain reusable components have been implemented in a language that
is not supported on the target environment.
The consequences associated with these refined sub conditions remains the same (i.e., 30
percent of software components must be customer engineered), but the refinement helps
to isolate the underlying risks and might lead to easier analysis and response.
6.6 RISK MITIGATION, MONITORING, AND MANAGEMENT
All of the risk analysis activities presented to this point have a single goal to assist the
project team in developing a strategy for dealing with risk. An effective strategy must
consider three issues:
risk avoidance
risk monitoring
risk management and contingency planning
If a software team adopts a proactive approach to risk, avoidance is always the best
strategy. This is achieved by developing a plan for risk mitigation. For example, assume
that high staff turnover is noted as a project risk, rl Based on past history and
management intuition, the likelihood, ll of high turnover is estimated to be 0.70 (70 per
cent, rather high) and the impact, xl is projected at level 2. That is, high turnover will
have a critical impact on project cost and schedule.
To mitigate this risk, project management must develop a strategy for reducing turnover.
Among the possible steps to be taken are
326
img
Software Project Management (CS615)
o Meet with current staff to determine causes for turnover (e.g., poor working
conditions, low pay, and competitive job market).
o Mitigate those causes that are under our control before the project starts.
o Once the project commences, assume turnover will occur and develop techniques to
ensure continuity when people leave.
o Organize project teams so that information about each development activity is widely
dispersed.
o Define documentation standards and establish mechanisms to be sure that .documents
are developed in a timely manner.
o Conduct peer reviews of all work (so that more than one person is "up to speed").
o Assign a backup staff member for every critical technologist.
As the project proceeds, risk monitoring activities commence. The project manager
monitors factors that may provide an indication of whether the risk is becoming more or
less likely. In the case of high staff turnover, the following factors can be monitored:
·
General attitude of team members based on project pressures.
·
The degree to which the team has jelled.
·
Interpersonal relationships among team members.
·
Potential problems with compensation and benefits.
·
The availability of jobs within the company and outside it.
In addition to monitoring these factors, the project manager should monitor the
effectiveness of risk mitigation steps. This is one mechanism for ensuring continuity,
should a critical individual leave the project. The project manager should monitor
documents carefully to ensure that each can stand on its own and that each imparts
information that would be necessary if a newcomer were forced to join the software team
somewhere in the middle of the project.
Risk management and contingency planning assumes that mitigation efforts have failed
and that the risk has become a reality. Continuing the example, the project is well
underway and a number of people announce that they will be leaving. If the mitigation
strategy has been followed, backup is available, information is documented, and
knowledge has been dispersed across the team. In addition, the project manager may
temporarily refocus resources (and readjust the project schedule) to those functions that
are fully staffed, enabling newcomers who must be added to the team to "get up to
speed." Those individuals who are leaving are asked to stop all work and spend their last
weeks in "knowledge transfer mode. This might include video-based knowledge capture,
the development of "commentary documents," and/or meeting with other team members
who will remain on the project.
It is important to note that RMMM steps incur additional project cost. For example,
spending the time to "backup" every critical technologist costs money. Part of risk
management, therefore, is to evaluate when the benefits accrued by the RMMM steps are
outweighed by the costs associated with implementing them. In essence, the project
327
img
Software Project Management (CS615)
planner performs a classic cost/benefit analysis. If risk aversion steps for high turnover, it
will increase both project cost and duration by an estimated 15 percent, but the
predominant cost factor is "backup," management may decide not to implement this step.
On the other hand, if the risk aversion steps are projected to' increase costs by 5 percent
and duration by only 3 percent management will likely put all into place.
For a large project, 30 or 40 risks may be identified. If between three and seven risk
management steps are identified for each, risk management may become a project in
itself! For this reason, we adapt the Pareto 80-20 rule to software risk. Experience
indicates that 80 percent of the overall project risk (i.e., 80 percent of the potential for
project failure) can be accounted for by only 20 percent of the identified risks. The work
performed during earlier risk analysis steps will help the planner to determine which of
the risks reside in that 20 percent (e.g., risks that lead to the highest risk exposure. For
this reason, some of the risks identified, assessed, and projected may not make it into the
RMMM plan - they don't fall into the critical 20 percent (the risks with highest project
priority).
6.7 SAFETY RISKS AND HAZARDS
Risk is not limited to the software project itself. Risks can occur after the software has
been successfully developed and delivered to the customer. These risks are typically
associated with the consequences of software failure in the field.
In the early days of computing, there was reluctance to use computers (and soft- ware) to
control safety critical processes such as nuclear reactors, aircraft flight control, weapons
systems, and large-scale industrial processes. Although the probability .of failure of a
well-engineered system was small, an undetected fault in a computer- based control or
monitoring system could result in enormous economic damage or, worse, significant
human injury or loss of life. But the cost and functional benefits of Computer-based
control and monitoring far outweigh the risk. Today, computer hardware and software are
used regularly to control safety critical systems.
When software is used as part of a control system, complexity can increase by an order of
magnitude or more. Subtle design faults induced by human error-some- thing that can be
uncovered and eliminated in hardware-based conventional control-become much more
difficult to uncover when software is used.
Software safety and hazard analysis [LEV95] are software quality assurance activities
(Chapter 8) that focus on the identification and assessment of potential hazards that may
affect software negatively and cause an entire system to fail. If hazards can be identified
early in the software engineering process, software design features can be specified that
will either eliminate or control potential hazards.
6.8 THE RMMM PLAN
328
img
Software Project Management (CS615)
A risk management strategy can be included in the software project plan or the risk
management steps can be organized into a separate Risk Mitigation, Monitoring and
Management Plan. The RMMM plan documents all work performed as part of risk
analysis and are used by the project manager as part of the overall project plan.
Some software teams do not develop a formal RMMM document. Rather, each risk is
documented individually using a risk information sheet (RIS) [WIL97]. In most cases, the
RIS is maintained using a database system, so that creation and information entry,
priority ordering, searches, and other analysis may be accomplished easily. The format of
the RIS is illustrated in Figure 6.5.
Once RMMM has been documented and the project has begun, risk mitigation and
monitoring steps commence. As we have already discussed, risk mitigation is a problem
avoidance activity. Risk monitoring is a project tracking activity with three primary
objectives: (I) to assess whether predicted risks do, in fact, occur; (2) to ensure that risk
aversion steps defined for the risk are being properly applied; and (3) to collect
information that can be used for future risk analysis. In many cases, the problems that
occur during a project can be traced to more than one risk. Another job of risk monitoring
is to attempt to allocate origin (what risk(s) caused which problems throughout. the
project).
Risk management is not as well developed as are some of the more traditional project
management disciplines. Some organizations feel that risk management is too specialized
or
advanced for them. Others believe that risk management is optional. Others fear that risk
management may expose flaws in their project plans and strategies that will hurt them in
the competitive world. Certainly these organizations will not talk openly and honestly
about risk and will "shoot the messenger" that brings risk to their attention.
Risk-mature organizations overcome the barriers to practicing effective risk management
in their approach to projects.
Their organizational culture becomes "risk friendly."
Risk management gains priority to rank along with cost, time and scope management.
Decisions are made and resources are allocated based on the results of risk analysis.
The highest quality data are used for risk analysis and resources are committed to the
efforts.
Risk management is viewed as a career path in the organization and those that practice
it are treated as professionals.
Risk analysis functions are given independence in the organization even though that
may make it hard to "control."
Mature risk management organizations look to the best in class to benchmark their risk
management processes.
They use modern tools and are not disdainful of sophisticated and proven approaches.
They measure their effectiveness with metrics.
Project decisions are made on a "risk-adjusted" basis.
Continuous improvement is achieved through regular repetition.
329
img
Software Project Management (CS615)
They participate in professional interchanges through conferences and journals, sharing
what they have learned.
Project risk is an uncertain event or condition that, if it occurs, has a positive or a
negative effect on at least one project objective. A risk may have one or more causes and,
if it occurs, one or more impacts. For example, a cause may be requiring an
environmental permit to do work or having limited personnel assigned to design the
project. The risk event is that the permitting agency may take longer than planned to issue
a permit for some reason, or the design personnel available and assigned may not be
adequate for the task. If either of these uncertain events occurs, there may be an impact
on the project cost, schedule, or performance. Risk conditions could include aspects of
the project's or organization's environment that may contribute to project risk, such as
poor project management practices, lack of integrated management systems, concurrent
multiple projects, or dependency on external participants who cannot be controlled.
Project risk has its origins in the uncertainty that is present in all projects. Known risks
are those that have been identified and analyzed, and it may be possible to plan for those
risks using the processes described in this chapter. Unknown risks cannot be managed
proactively, and a prudent response by the project team can be to allocate general
contingency against such risks, as well as against any known risks for which it may not
be cost-effective or possible to develop a proactive response.
Organizations perceive risk as it relates to threats to project success or to opportunities to
enhance chances of project success. Risks that are threats to the project may be accepted
if the risk is in balance with the reward that may be gained by taking the risk. For
example, adopting a fast track schedule (Section 6.4) that may be overrun is a risk taken
to achieve an earlier completion date. Risks that are opportunities, such as work
acceleration that may be gained by assigning more expert staff, may be pursued to benefit
the project's objectives.
Individuals, and by extension organizations, have attitudes toward risk that affect both the
accuracy of the perception of risk and the way they respond. Attitudes about risk should
be made explicit wherever possible. A consistent approach to risk that meets the
organization's requirements should be developed for each project, and communication
about risk and its handling should be open and honest. Risk responses reflect an
organization's balance between risk-taking and risk-avoidance.
To be successful, the organization must be committed to addressing the management of
risk proactively and consistently throughout the project.
330
img
Software Project Management (CS615)
Figure: Project Risk Management Flow
331
Table of Contents:
  1. Introduction & Fundamentals
  2. Goals of Project management
  3. Project Dimensions, Software Development Lifecycle
  4. Cost Management, Project vs. Program Management, Project Success
  5. Project Management’s nine Knowledge Areas
  6. Team leader, Project Organization, Organizational structure
  7. Project Execution Fundamentals Tracking
  8. Organizational Issues and Project Management
  9. Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
  10. Project Execution: Product Implementation, Project Closedown
  11. Problems in Software Projects, Process- related Problems
  12. Product-related Problems, Technology-related problems
  13. Requirements Management, Requirements analysis
  14. Requirements Elicitation for Software
  15. The Software Requirements Specification
  16. Attributes of Software Design, Key Features of Design
  17. Software Configuration Management Vs Software Maintenance
  18. Quality Assurance Management, Quality Factors
  19. Software Quality Assurance Activities
  20. Software Process, PM Process Groups, Links, PM Phase interactions
  21. Initiating Process: Inputs, Outputs, Tools and Techniques
  22. Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks
  23. Project Planning Objectives, Primary Planning Steps
  24. Tools and Techniques for SDP, Outputs from SDP, SDP Execution
  25. PLANNING: Elements of SDP
  26. Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions
  27. Organizational Systems
  28. ORGANIZATIONAL PLANNING, Organizational Management Tools
  29. Estimation - Concepts
  30. Decomposition Techniques, Estimation – Tools
  31. Estimation – Tools
  32. Work Breakdown Structure
  33. WBS- A Mandatory Management Tool
  34. Characteristics of a High-Quality WBS
  35. Work Breakdown Structure (WBS)
  36. WBS- Major Steps, WBS Implementation, high level WBS tasks
  37. Schedule: Scheduling Fundamentals
  38. Scheduling Tools: GANTT CHARTS, PERT, CPM
  39. Risk and Change Management: Risk Management Concepts
  40. Risk & Change Management Concepts
  41. Risk Management Process
  42. Quality Concept, Producing quality software, Quality Control
  43. Managing Tasks in Microsoft Project 2000
  44. Commissioning & Migration