A project is a finite endeavor (having specific start and completion dates) that requires

the organization and coordination of a group of two or more people, to create a unique
product or service which brings about beneficial change or added value. This finite
characteristic of projects stands in sharp contrast to processes, or operations, which are
permanent or semi-permanent functional work to repetitively produce the same product
or service. In practice, the management of these two systems is often found to be quite
different, and as such requires the development of distinct technical skills and the
adoption of separate management

Project management is the discipline of planning, organizing and managing resources to

bring about the successful completion of specific project goals and objectives.

Project management
PM is a business process of the project-oriented company. The PM process starts with the
project assignment and ends with the project approval. It consists of the sub-processes
project start, project co-ordination, project controlling, project discontinuity management
and project close-down.

The primary challenge of project management is to achieve all of the project goals and
objectives while honoring the project constraints. Typical constraints are scope, time and
budget. The secondary—and more ambitious—challenge is to optimize the allocation and
integration of inputs necessary to meet pre-defined objectives.

Project development stages

The project development stages.

Traditionally, project development includes a number of elements: four to five stages,

and a control system. Regardless of the methodology used, the project development
process will have the same major stages:

• initiation,
• planning or development,
• production or execution,
• monitoring and controlling, and
• closing.

Initiation
Initiating Process Group Processes.

The initiation stage determines the nature and scope of the development. If this stage is
not performed well, it is unlikely that the project will be successful in meeting the
business’s needs. The key project controls needed here are an understanding of the
business environment and making sure that all necessary controls are incorporated into
the project. Any deficiencies should be reported and a recommendation should be made
to fix them.

The initiation stage should include a cohesive plan that encompasses the following areas:

• Study analyzing the business needs in measurable goals.

• Review of the current operations.
• Conceptual design of the operation of the final product.
• Equipment and contracting requirements including an assessment of 'long-lead'
items.
• Financial analysis of the costs and benefits including a budget.
• Stakeholder analysis, including users, and support personnel for the project.
• Project charter including costs, tasks, deliverables, and schedule.

Planning and design

Planning Process Group Activities.

After the initiation stage, the system is designed. Occasionally, a small prototype of the
final product is built and tested. Testing is generally performed by a combination of
testers and end users, and can occur after the prototype is built or concurrently. Controls
should be in place that ensure that the final product will meet the specifications of the
project charter. The results of the design stage should include a product design that:

• Satisfies the project sponsor, end user, and business requirements.

• Functions as it was intended.
• Can be produced within quality standards.
• Can be produced within time and budget constraints.
Executing

Executing Process Group Processes.

Executing consists of the processes used to complete the work defined in the project
management plan to accomplish the project's requirements. Execution process involves
coordinating people and resources, as well as integrating and performing the activities of
the project in accordance with the project management plan. The deliverables are
produced as outputs from the processes performed as defined in the project management
plan.

Monitoring and Controlling

Monitoring and Controlling consists of those processes performed to observe project

execution so that potential problems can be identified in a timely manner and corrective
action can be taken, when necessary, to control the execution of the project. The key
benefit is that project performance is observed and measured regularly to identify
variances from the project management plan.

Monitoring and Controlling Process Group Processes.

Monitoring and Controlling includes:

• Measuring the ongoing project activities (where we are);

• Monitoring the project variables (cost, effort, ...) against the project management
plan and the project performance baseline (where we should be);
 • Identify corrective actions to properly address issues and risks (How can we get
on track again);
• Influencing the factors that could circumvent integrated change control so only
approved changes are implemented

In multi-phase projects, the Monitoring and Controlling process also provides feedback
between project phases, in order to implement corrective or preventive actions to bring
the project into compliance with the project management plan.

Project Maintenance is an ongoing process, and it includes:

• Continuing support of end users

• Correction of errors
• Updates of the software over time

Monitoring and Controlling cycle

In this stage, auditors should pay attention to how effectively and quickly user problems
are resolved.

Over the course of any construction project, the work scope changes. Change is a normal
and expected part of the construction process. Changes can be the result of necessary
design modifications, differing site conditions, material availability, contractor-requested
changes, value engineering and impacts from third parties, to name a few. Beyond
executing the change in the field, the change normally needs to be documented to show
what was actually constructed. This is referred to as Change Management. Hence, the
owner usually requires a final record to show all changes or, more specifically, any
change that modifies the tangible portions of the finished work. The record is made on
the contract documents – usually, but not necessarily limited to, the design drawings. The
end product of this effort is what the industry terms as-built drawings, or more simply,
“asbuilts.” The requirement for providing them is a norm in construction contracts.

When changes are introduced to the project the viability of the project has to be assessed
again. It is important not to lose sight of the initial goals and targets of the projects. When
the changes accumulate, the forecasted end result may not justify the proposed
investment.

Closing
Closing Process Group Processes.
Closing includes the formal acceptance of the project and the ending thereof.
Administrative activities include the archiving of the files and documenting lessons
learned. Closing phase consist of two parts:

• Close project: to finalize all activities across all of the process groups to formally
close the project or a project phase
• Contract closure: necessary for completing and settling each contract, including
the resolution of any open items, and closing each contract applicable to the
project or a project phase.

Understanding Risk and Uncertainty

Uncertainty Uncertainty is defined as an absence of information,knowledge, or
understanding regarding the outcome of an action, decision, or event. Project managers
constantly suffer from an absence of information, knowledge, or understanding. Risk
Risk is actually a measure of the amount of uncertainty that exists. It’s directly tied to
information. This is not exactly the way most of us think about risk in everyday
situations. However, in the world of project management, risk relates primarily to the
extent of your ability to predict a particular outcome with certainty. This interpretation is
Amount of Risk
derived from the study of decision and risk analysis, the statistical sibling to project risk
management

Threat :-The effects of risk can be positive or negative. Positive effects of risk are often
referred to as opportunities. Threats are the negative—or “downside”—effects of risk.
Threats are specific events that drive your project in the direction of outcomes viewed as
unfavorable (e.g., schedule delays, cost overruns, and inferior product performance).

Graphical representation of threat ratings

Responding to High-Threat Problems

There are a number of ways to address the high-threat problems you identify. Let’s
examine all of the options for dealing with risk and potential problems:
Avoidance. In avoidance, you choose a course of action that eliminates your exposure to
the threat. This often means that you’re now pursuing a completely different course from
what you’d originally planned. The space shuttle program provides an excellent study in
avoidance. Many flights are carefully planned and then, because of marginal weather
conditions, scrubbed. Delaying the takeoff of a space shuttle mission because of a
weather threat is a perfect example of risk avoidance.
Transfer. The most widely quoted example of risk transfer is something we’re all very
familiar with—insurance. Risk transfer does not “treat” the risk; it simply makes another
party responsible for the consequences of the risk.
Assumption. This means that you are aware of the risk, but choose to take no action on
it. You’re agreeing to accept its consequences or to simply deal with them if it happens.
That’s essentially how you’re treating threats that fall below the threat rating described
above. Assumption is also a valid strategy in situations where the consequences of the
risk are less costly and/or less traumatic than the effort required to prevent it.
Prevention. Prevention refers to action taken to reduce the probability of occurrence of a
potential problem. Ordinarily, it will be your first course of action in dealing with high-
threat problems. Prevention begins with identifying the root causes of potential problems.
Determining root cause may allow you to identify preventive measures that
could reduce the probability that a given problem will occur. Be sure to revise the project
plan to incorporate any preventive actions that you intend to take, so that they’re not
overlooked or forgotten.
Mitigation of Impact. This strategy aims at reducing the negative effects of a problem.
You’re taking measures to lessen the impact. For example, installing air bags in
automobiles does nothing to reduce the probability of accidents, but it may significantly
reduce the effects. It’s important to note that mitigation tactics may be viewed as a waste
of time, money, and effort, if the potential problem does not occur.
Contingency Planning. Contingency plans are specific actions that are to be taken when
a potential problem occurs. Although they’re intended to deal with problems only after
they’ve occurred, contingency plans should be developed in advance.
This helps ensure a coordinated, effective, and timely response. Also, some plans may
require backup resources that need to be arranged for in advance. Contingency planning
should be done only for the high-threat problems that remain after you’ve taken
preventive measures.
Risk assessment The combination of risk identification and risk quantification. The
primary output of a risk assessment is a list of specific potential problems or threats.
Common risks encountered on projects
 Risk management
Definitions of project risk

The degree of likelihood that a project will not be completed on schedule and within
budget or that a loan will not be repaid.

Definitions of project risk management

Project risk management is a structured process that allows individual risk events and
overall project risk to be understood and managed

Managing Risk: An Overview

Many approaches can be used to address risk and the threats it produces. However, most
processes for managing risk tend to follow some variation of this basic four-step
approach:
Step 1. Identification (determining what threats exist). Identify all significant
uncertainties (sources of risk), including specific threats (also called potential problems
or risk events) that could occur throughout the life of the project.

Step 2. Quantification (determining how big the threats are). Obtain information on the
range of possible outcomes for all uncertainties and their distribution and/or probabilities
of occurrence, to better understand the nature of the threats and their potential effects on
the project.

Step 3. Analysis (determining which threats are of greatest concern). Use the knowledge
gained through risk assessment to determine which potential problems represent the
greatest danger to achieving a successful and predictable project outcome, ordinarily by
considering the probability that a specific problem will occur and its anticipated impact
on the project.

Step 4. Response (dealing with the threats). Determine the best approaches for addressing
each high-threat potential problem, which may include evaluating and choosing among a
number of alternatives, and create specific action plans.

Nature or Extent of the Effect. Let’s say that the same strike could cause “a schedule
delay.” How much of a delay? A week? Two weeks? A month? Will the project
necessarily be delayed by that same amount? When gathering insight on the nature and
extent of problems and their effects, you’ll have to rely on several sources, including
the following:
• Survey data (preference, opinion, etc.)
• Historical data
• Product specification sheets
• Mockup, simulation, or testing
• Subject matter expert (SME) judgment
Areas of risk management

As applied to corporate finance, risk management is the technique for measuring,

monitoring and controlling the financial or operational risk on a firm's balance sheet. See
value at risk.

The Basel II framework breaks risks into market risk (price risk), credit risk and
operational risk and also specifies methods for calculating capital requirements for each
of these components.

Risk-management activities as applied to project management

In project management, risk management includes the following activities:

• Planning how risk will be managed in the particular project. Plan should include
risk management tasks, responsibilities, activities and budget.
• Assigning a risk officer - a team member other than a project manager who is
responsible for foreseeing potential project problems. Typical characteristic of
risk officer is a healthy skepticism.
• Maintaining live project risk database. Each risk should have the following
attributes: opening date, title, short description, probability and importance.
Optionally a risk may have an assigned person responsible for its resolution and a
date by which the risk must be resolved.
• Creating anonymous risk reporting channel. Each team member should have
possibility to report risk that he foresees in the project.
• Preparing mitigation plans for risks that are chosen to be mitigated. The purpose
of the mitigation plan is to describe how this particular risk will be handled –
what, when, by who and how will it be done to avoid it or minimize consequences
if it becomes a liability.
• Summarizing planned and faced risks, effectiveness of mitigation activities, and
effort spent for the risk management.

Risk management and business continuity

Risk management is simply a practice of systematically selecting cost effective

approaches for minimising the effect of threat realization to the organization. All risks
can never be fully avoided or mitigated simply because of financial and practical
limitations. Therefore all organizations have to accept some level of residual risks.

Whereas risk management tends to be preemptive, business continuity planning (BCP)

was invented to deal with the consequences of realised residual risks. The necessity to
have BCP in place arises because even very unlikely events will occur if given enough
time. Risk management and BCP are often mistakenly seen as rivals or overlapping
practices. In fact these processes are so tightly tied together that such separation seems
artificial. For example, the risk management process creates important inputs for the BCP
(assets, impact assessments, cost estimates etc). Risk management also proposes
applicable controls for the observed risks. Therefore, risk management covers several
areas that are vital for the BCP process. However, the BCP process goes beyond risk
management's preemptive approach and moves on from the assumption that the disaster
will realize at some point.

Risk management is activity directed towards the assessing, mitigating (to an acceptable
level) and monitoring of risks. In some cases the acceptable risk may be near zero. Risks
can come from accidents, natural causes and disasters as well as deliberate attacks from
an adversary. The main ISO standards on risk management include.

In businesses, risk management entails organized activity to manage uncertainty and

threats and involves people following procedures and using tools in order to ensure
conformance with risk-management policies.

The strategies include transferring the risk to another party, avoiding the risk, reducing
the negative effect of the risk, and accepting some or all of the consequences of a
particular risk
Principles of risk management

The International Organization for Standardization identifies the following principles of

risk management:

• Risk management should create value.

• Risk management should be an integral part of organizational processes.
• Risk management should be part of decision making.
• Risk management should explicitly address uncertainty.
• Risk management should be systematic and structured.
• Risk management should be based on the best available information.
• Risk management should be tailored.
• Risk management should take into account human factors.
• Risk management should be transparent and inclusive.
• Risk management should be dynamic, iterative and responsive to change.
• Risk management should be capable of continual improvement and enhancement.

Process

According to the standard ISO/DIS 31000 "Risk management -- Principles and guidelines
on implementation", the process of risk management consists of several steps as follows:

Establishing the context

Establishing the context involves

1. Identification of risk in a selected domain of interest

2. Planning the remainder of the process.
3. Mapping out the following:
o the social scope of risk management
o the identity and objectives of stakeholders
o the basis upon which risks will be evaluated, constraints.
4. Defining a framework for the activity and an agenda for identification.
5. Developing an analysis of risks involved in the process.
6. Mitigation of risks using available technological, human and organizational
resources.

Identification

After establishing the context, the next step in the process of managing risk is to identify
potential risks. Risks are about events that, when triggered, cause problems. Hence, risk
identification can start with the source of problems, or with the problem itself.
 • Source analysis Risk sources may be internal or external to the system that is the
target of risk management. Examples of risk sources are: stakeholders of a
project, employees of a company or the weather over an airport.
• Problem analysis Risks are related to identified threats. For example: the threat
of losing money, the threat of abuse of privacy information or the threat of
accidents and casualties. The threats may exist with various entities, most
important with shareholders, customers and legislative bodies such as the
government.

When either source or problem is known, the events that a source may trigger or the
events that can lead to a problem can be investigated. For example: stakeholders
withdrawing during a project may endanger funding of the project; privacy information
may be stolen by employees even within a closed network; lightning striking a Boeing
747 during takeoff may make all people onboard immediate casualties.

The chosen method of identifying risks may depend on culture, industry practice and
compliance. The identification methods are formed by templates or the development of
templates for identifying source, problem or event. Common risk identification methods
are:

• Objectives-based risk identification Organizations and project teams have

objectives. Any event that may endanger achieving an objective partly or
completely is identified as risk.
• Scenario-based risk identification In scenario analysis different scenarios are
created. The scenarios may be the alternative ways to achieve an objective, or an
analysis of the interaction of forces in, for example, a market or battle. Any event
that triggers an undesired scenario alternative is identified as risk
• Taxonomy-based risk identification The taxonomy in taxonomy-based risk
identification is a breakdown of possible risk sources. Based on the taxonomy and
knowledge of best practices, a questionnaire is compiled. The answers to the
questions reveal risks..
• Common-risk checking In several industries lists with known risks are available.
Each risk in the list can be checked for application to a particular situation. An
example of known risks in the software industry is the Common Vulnerability and
Risk charting (risk mapping) This method combines the above approaches by
listing Resources at risk, Threats to those resources Modifying Factors which may
increase or decrease the risk and Consequences it is wished to avoid. Creating a
matrix under these headings enables a variety of approaches. One can begin with
resources and consider the threats they are exposed to and the consequences of
each. Alternatively one can start with the threats and examine which resources
they would affect, or one can begin with the consequences and determine which
combination of threats and resources would be involved to bring them about.

Assessment

Once risks have been identified, they must then be assessed as to their potential severity
of loss and to the probability of occurrence. These quantities can be either simple to
measure, in the case of the value of a lost building, or impossible to know for sure in the
case of the probability of an unlikely event occurring. Therefore, in the assessment
process it is critical to make the best educated guesses possible in order to properly
prioritize the implementation of the risk management plan.

The fundamental difficulty in risk assessment is determining the rate of occurrence since
statistical information is not available on all kinds of past incidents. Furthermore,
evaluating the severity of the consequences (impact) is often quite difficult for immaterial
assets. Asset valuation is another question that needs to be addressed. Thus, best educated
opinions and available statistics are the primary sources of information. Nevertheless,
risk assessment should produce such information for the management of the organization
that the primary risks are easy to understand and that the risk management decisions may
be prioritized. Thus, there have been several theories and attempts to quantify risks.
Numerous different risk formulae exist, but perhaps the most widely accepted formula for
risk quantification is:

Rate of occurrence multiplied by the impact of the event equals risk

Later research has shown that the financial benefits of risk management are less
dependent on the formula used but are more dependent on the frequency and how risk
assessment is performed.

Potential risk treatments

Once risks have been identified and assessed, all techniques to manage the risk fall into
one or more of these four major categories:

• Avoidance (eliminate)
• Reduction (mitigate)
• Transfer (outsource or insure)
• Retention (accept and budget)

Ideal use of these strategies may not be possible. Some of them may involve trade-offs
that are not acceptable to the organization or person making the risk management
decisions.

Risk avoidance

Includes not performing an activity that could carry risk. An example would be not
buying a property or business in order to not take on the liability that comes with it.
Another would be not flying in order to not take the risk that the airplanes were to be
hijacked. Avoidance may seem the answer to all risks, but avoiding risks also means
losing out on the potential gain that accepting (retaining) the risk may have allowed. Not
entering a business to avoid the risk of loss also avoids the possibility of earning profits.

Risk reduction

Involves methods that reduce the severity of the loss or the likelihood of the loss from
occurring. For example, sprinklers are designed to put out a fire to reduce the risk of loss
by fire. This method may cause a greater loss by water damage and therefore may not be
suitable. Halon fire suppression systems may mitigate that risk, but the cost may be
prohibitive as a strategy.

Modern software development methodologies reduce risk by developing and delivering

software incrementally. Early methodologies suffered from the fact that they only
delivered software in the final phase of development; any problems encountered in earlier
phases meant costly rework and often jeopardized the whole project. By developing in
iterations, software projects can limit effort wasted to a single iteration.

Outsourcing could be an example of risk reduction if the outsourcer can demonstrate

higher capability at managing or reducing risks. In this case companies outsource only
some of their departmental needs.

Risk retention

Involves accepting the loss when it occurs. True self insurance falls in this category. Risk
retention is a viable strategy for small risks where the cost of insuring against the risk
would be greater over time than the total losses sustained. All risks that are not avoided
or transferred are retained by default. This includes risks that are so large or catastrophic
that they either cannot be insured against or the premiums would be infeasible. War is an
example since most property and risks are not insured against war, so the loss attributed
by war is retained by the insured. Also any amounts of potential loss (risk) over the
amount insured is retained risk. This may also be acceptable if the chance of a very large
loss is small or if the cost to insure for greater coverage amounts is so great it would
hinder the goals of the organization too much.

Risk transfer

In the terminology of practitioners and scholars alike, the purchase of an insurance

contract is often described as a "transfer of risk." However, technically speaking, the
buyer of the contract generally retains legal responsibility for the losses "transferred",
meaning that insurance may be described more accurately as a post-event compensatory
mechanism. For example, a personal injuries insurance policy does not transfer the risk of
a car accident to the insurance company. The risk still lies with the policy holder namely
the person who has been in the accident. The insurance policy simply provides that if an
accident (the event) occurs involving the policy holder then some compensation may be
payable to the policy holder that is commensurate to the suffering/damage.

Some ways of managing risk fall into multiple categories. Risk retention pools are
technically retaining the risk for the group, but spreading it over the whole group
involves transfer among individual members of the group. This is different from
traditional insurance, in that no premium is exchanged between members of the group up
front, but instead losses are assessed to all members of the group.

Create a risk-management plan

Select appropriate controls or countermeasures to measure each risk. Risk mitigation

needs to be approved by the appropriate level of management. For example, a risk
concerning the image of the organization should have top management decision behind it
whereas IT management would have the authority to decide on computer virus risks.

The risk management plan should propose applicable and effective security controls for
managing the risks. For example, an observed high risk of computer viruses could be
mitigated by acquiring and implementing antivirus software. A good risk management
plan should contain a schedule for control implementation and responsible persons for
those actions.

Implementation

Follow all of the planned methods for mitigating the effect of the risks. Purchase
insurance policies for the risks that have been decided to be transferred to an insurer,
avoid all risks that can be avoided without sacrificing the entity's goals, reduce others,
and retain the rest.

Review and evaluation of the plan

Initial risk management plans will never be perfect. Practice, experience, and actual loss
results will necessitate changes in the plan and contribute information to allow possible
different decisions to be made in dealing with the risks being faced.
10 Golden Rules of Project Risk Management

The benefits of risk management in projects are huge. You can gain a lot of money if you
deal with uncertain project events in a proactive manner. The result will be that you
minimise the impact of project threats and seize the opportunities that occur. This allows
you to deliver your project on time, on budget and with the quality results your project
sponsor demands. Also your team members will be much happier if they do not enter a
"fire fighting" mode needed to repair the failures that could have been prevented.

The 10 golden rules to apply risk management successfully in your project. They are
based on personal experiences of the author who has been involved in projects for over
15 years.

Rule 1: Make Risk Management Part of Your Project

The first rule is essential to the success of project risk management. If you don't truly
embed risk management in your project, you can not reap the full benefits of this
approach. You can encounter a number of faulty approaches in companies. Some projects
use no approach whatsoever to risk management. They are either ignorant, running their
first project or they are somehow confident that no risks will occur in their project (which
of course will happen). Some people blindly trust the project manager, especially if he
(usually it is a man) looks like a battered army veteran who has been in the trenches for
the last two decades. Professional companies make risk management part of their day to
day operations and include it in project meetings and the training of staff.

Rule 2: Identify Risks Early in Your Project

The first step in project risk management is to identify the risks that are present in your
project. This requires an open mind set that focuses on future scenarios that may occur.
Two main sources exist to identify risks, people and paper. People are your team
members that each bring along their personal experiences and expertise. Other people to
talk to are experts outside your project that have a track record with the type of project or
work you are facing. They can reveal some booby traps you will encounter or some
golden opportunities that may not have crossed your mind. Interviews and team sessions
(risk brainstorming) are the common methods to discover the risks people know. Paper is
a different story. Projects tend to generate a significant number of (electronic) documents
that contain project risks. They may not always have that name, but someone who reads
carefully (between the lines) will find them. The project plan, business case and resource
planning are good starters. Another categories are old project plans, your company
Intranet and specialised websites.
Are you able to identify all project risks before they occur? Probably not. However if you
combine a number of different identification methods, you are likely to find the large
majority. If you deal with them properly, you have enough time left for the unexpected
risks that take place.

Rule 3: Communicate About Risks

Failed projects show that project managers in such projects were frequently unaware of
the big hammer that was about to hit them. The frightening finding was that frequently
someone of the project organisation actually did see that hammer, but didn't inform the
project manager of its existence. If you don't want this to happen in your project, you
better pay attention to risk communication.

A good approach is to consistently include risk communication in the tasks you carry out.
If you have a team meeting, make project risks part of the default agenda (and not the
final item on the list!). This shows risks are important to the project manager and gives
team members a "natural moment" to discuss them and report new ones.

Another important line of communication is that of the project manager and project
sponsor or principal. Focus your communication efforts on the big risks here and make
sure you don't surprise the boss or the customer! Also take care that the sponsor makes
decisions on the top risks, because usually some of them exceed the mandate of the
project manager.

Rule 4: Consider Both Threats and Opportunities

Project risks have a negative connotation: they are the "bad guys" that can harm your
project. However modern risk approaches also focus on positive risks, the project
opportunities. These are the uncertain events that beneficial to your project and
organisation. These "good guys" make your project faster, better and more profitable.

Unfortunately, lots of project teams struggle to cross the finish line, being overloaded
with work that needs to be done quickly. This creates project dynamics where only
negative risks matter (if the team considers any risks at all). Make sure you create some
time to deal with the opportunities in your project, even if it is only half an hour. Chances
are that you see a couple of opportunities with a high pay-off that don't require a big
investment in time or resources.

Rule 5: Clarify Ownership Issues

Some project managers think they are done once they have created a list with risks.
However this is only a starting point. The next step is to make clear who is responsible
for what risk! Someone has to feel the heat if a risk is not taken care of properly. The
trick is simple: assign a risk owner for each risk that you have found. The risk owner is
the person in your team that has the responsibility to optimise this risk for the project.
The effects are really positive. At first people usually feel uncomfortable that they are
actually responsible for certain risks, but as time passes they will act and carry out tasks
to decrease threats and enhance opportunities.
Ownership also exists on another level. If a project threat occurs, someone has to pay the
bill. This sounds logical, but it is an issue you have to address before a risk occurs.
Especially if different business units, departments and suppliers are involved in your
project, it becomes important who bears the consequences and has to empty his wallet.
An important side effect of clarifying the ownership of risk effects, is that line managers
start to pay attention to a project, especially when a lot of money is at stake. The
ownership issue is equally important with project opportunities. Fights over (unexpected)
revenues can become a long-term pastime of management.

Rule 6: Prioritise Risks

A project manager once told me "I treat all risks equally." This makes project life really
simple. However, it doesn't deliver the best results possible. Some risks have a higher
impact than others. Therefore, you better spend your time on the risks that can cause the
biggest losses and gains. Check if you have any showstoppers in your project that could
derail your project. If so, these are your number 1 priority. The other risks can be
prioritised on gut feeling or, more objectively, on a set of criteria. The criteria most
project teams use is to consider the effects of a risk and the likelihood that it will occur.
Whatever prioritisation measure you use, use it consistently and focus on the big risks.

Rule 7: Analyse Risks

Understanding the nature of a risk is a precondition for a good response. Therefore take
some time to have a closer look at individual risks and don't jump to conclusions without
knowing what a risk is about.

Risk analysis occurs at different levels. If you want to understand a risk at an individual
level it is most fruitful to think about the effects that it has and the causes that can make it
happen. Looking at the effects, you can describe what effects take place immediately
after a risk occurs and what effects happen as a result of the primary effects or because
time elapses. A more detailed analysis may show the order of magnitude effect in a
certain effect category like costs, lead time or product quality. Another angle to look at
risks, is to focus on the events that precede a risk occurrence, the risk causes. List the
different causes and the circumstances that decrease or increase the likelihood.

Another level of risk analysis is investigate the entire project. Each project manager
needs to answer the usual questions about the total budget needed or the date the project
will finish. If you take risks into account, you can do a simulation to show your project
sponsor how likely it is that you finish on a given date or within a certain time frame. A
similar exercise can be done for project costs.

The information you gather in a risk analysis will provide valuable insights in your
project and the necessary input to find effective responses to optimise the risks.

Rule 8: Plan and Implement Risk Responses

Implementing a risk response is the activity that actually adds value to your project. You
prevent a threat occurring or minimise negative effects. Execution is key here. The other
rules have helped you to map, prioritise and understand risks. This will help you to make
a sound risk response plan that focuses on the big wins.

If you deal with threats you basically have three options, risk avoidance, risk
minimisation and risk acceptance. Avoiding risks means you organise your project in
such a way that you don't encounter a risk anymore. This could mean changing supplier
or adopting a different technology or, if you deal with a fatal risk, terminating a project.
Spending more money on a doomed project is a bad investment.

The biggest category of responses are the ones to minimise risks. You can try to prevent a
risk occurring by influencing the causes or decreasing the negative effects that could
result. If you have carried out rule 7 properly (risk analysis) you will have plenty of
opportunities to influence it. A final response is to accept a risk. This is a good choice if
the effects on the project are minimal or the possibilities to influence it prove to be very
difficult, time consuming or relatively expensive. Just make sure that it is a conscious
choice to accept a certain risk.

Responses for risk opportunities are the reverse of the ones for threats. They will focus on
seeking risks, maximising them or ignoring them (if opportunities prove to be too small).

Rule 9: Register Project Risks

This rule is about bookkeeping (however don't stop reading). Maintaining a risk log
enables you to view progress and make sure that you won't forget a risk or two. It is also
a perfect communication tool that informs your team members and stakeholders what is
going on (rule 3).

A good risk log contains risks descriptions, clarifies ownership issues (rule 5) and enables
you to carry our some basic analyses with regard to causes and effects (rule 7). Most
project managers aren't really fond of administrative tasks, but doing your bookkeeping
with regards to risks pays off, especially if the number of risks is large. Some project
managers don't want to record risks, because they feel this makes it easier to blame them
in case things go wrong. However the reverse is true. If you record project risks and the
effective responses you have implemented, you create a track record that no one can
deny. Even if a risk happens that derails the project. Doing projects is taking risks.

Rule 10: Track Risks and Associated Tasks

The risk register you have created as a result of rule 9, will help you to track risks and
their associated tasks. Tracking tasks is a day-to-day job for each project manager.
Integrating risk tasks into that daily routine is the easiest solution. Risk tasks may be
carried out to identify or analyse risks or to generate, select and implement responses.

Tracking risks differs from tracking tasks. It focuses on the current situation of risks.
Which risks are more likely to happen? Has the relative importance of risks changed?
Answering this questions will help to pay attention to the risks that matter most for your
project value.
The 10 golden risk rules above give you guidelines on how to implement risk
management successfully in your project. However, keep in mind that you can always
improve. Therefore rule number 11 would be to use the Japanese Kaizen approach:
measure the effects of your risk management efforts and continuously implement
improvements to make it even better.

Four steps for reducing project risk

Whether it's small or large, complex or simple, every project has risk. It's our job as
managers to do our best to not only minimize the risk in our projects but to minimize it as
soon as we can. In this article, you'll learn a simple four-step approach for doing just that.

Inventory

The first step to managing the risk of a project is to inventory the situation. That is,
identify all of the risks that you think are possible in the project. The inventory should
include all internal factors for the project such as resource changes, assumption failures,
and sponsor availability. It should also include all external factors such as a change in
company direction or a change of technology direction. Most of all, however, it should
include the things that are new in the project. If the project is working with a new
technology, is using a new development methodology, or even if there are new, relatively
unknown team members, these need to be listed as potential risks to the project.

The purpose of the inventory phase isn't to classify the risk or identify its importance.
That step happens later. The goal is to collect all the risks. If you mix in the process of
evaluating the risk you’ll find that you won’t get a complete inventory of the potential
risks for the project. Staying focused on capturing risks is essential to the process.

Evaluate

Once you have a complete list of potential risks, it’s time to evaluate them. Each risk
should be evaluated based both on its probability and on the impact that it would cause if
it happens. The loss of a key team member may have a low probability; however, the
impact to the project can be great.

Some people struggle with the evaluation step because both of the numbers, percentage
and impact, are guesses. They recognize that even subtle changes in the values for these
numbers can have a huge impact on the total risk of the project. However, in general, the
objective here isn’t to come up with a single number that represents each risk. The
objective is to develop a framework for evaluating the various risks against one another.
Although precision in the estimating process is useful it's not essential.

The other factor to evaluate when looking at a risk is its duration--how long that it can
have a potential impact on the project. For instance, the loss of a subject matter expert
early in the project is a risk because their input is still needed. However, later in the
project they may not have much input and therefore aren't a risk if they leave.The risk of
a functional analyst leaving is greatest in the initial phases of the project when they are
intensively interacting with the customer. Later on in the project, the loss of the
functional analyst has a smaller potential impact for the project.

In order to get a consistent number for all of the risks, multiply the probability which
should be per interval of duration by the impact and finally multiply that by the duration.
The resulting number is a single number, a risk quotient, which can be used to prioritize
risks within the project. For instance, if the probability of the risk happening in a given
week is 10%, the number of weeks the risk may happen is 10 weeks, and the impact is
$1000, the overall risk is $1000. (.10*10*1000 = 1000)

Prioritize

Now that you have a single risk quotient for the various risks, it's possible to prioritize the
risks for the project. It can give you a clear vision of what the risks are and which ones
you'll ultimately need to be concerned about. This is also a part of the process that
typically helps validate the estimates made above. For instance, if your greatest risk is
personnel turnover (as it usually is) you may want to more objectively evaluate the
probability. If the average person stays at your organization for three years you can
assume a probability of them leaving in a given week is 1/156 (3x52 weeks/year) which
is a 0.00641 percent chance.

Control and mitigate

Once the risks are prioritized you can go through the list and identify which risks are
controllable, which risks are things that can be mitigated, and which risks must be
accepted. For instance, the risk of loosing key personnel can be mitigated by providing
completion bonuses or even just monitoring their happiness more closely. Technical risks
can be controlled by moving them forward in the project so that they are proven out
nearly immediately.

In general, the fastest way to reduce the overall risk quotient for a project is to tackle the
controllable risks early in the project. The more quickly that you are able to validate the
risk associated with an item the more quickly the risk is no longer a risk (so its
probability can be zeroed out.) Focusing on controllable risks won't completely eliminate
risk but it will quickly cut it down.

The next step is to develop mitigation strategies for those risks that can’t be controlled.
Completion bonuses are a routine way that organizations which are closing down
operations mitigate the risk that the people participating will leave before the project is
ready to let them go.

Not every mitigation strategy needs to involve money. Simply getting a verbal, personal
commitment to finish the project is often enough to further reduce the probability that a
person will leave during the project. Most people value their own sense of self worth and
they believe that their ability to meet their personal commitments is a part of the
admirable part of their self.
No project is without some risk. The best way to identify risks is through a combination
of checklists and brainstorming. Checklists allow you to catch the typical risks that might
be inherent in projects like yours. A team brainstorming session allows you to find risks
that are specific to your particular project. You might end up identifying dozens of risks
through a combination of checklists and brainstorming.

After you identify all the risks, you must figure out which ones are important enough for
you to address (risk analysis). You want to classify each risk it in terms of high risk,
medium risk, or low risk. You do that by looking at the likelihood that the risk will occur
and the impact of the risk on the project if it does occur. For example, a risk that is highly
likely to occur and has a high impact to the project would definitively be a high category
risk. On the other hand, a risk that is not likely to occur and has a small impact to the
project if it does occur would definitively be a low-level risk. All other combinations fall
somewhere in the middle of this continuum. The following list gives you the various
combinations based on the impact to the project (high, medium, low) and the likelihood
of the risk occurring (high, medium, low)

Likelihood Impact Overall risk level

High High High
High Medium Medium
High Low Low
Medium High High
Medium Medium Medium
Medium Low Medium/Low
Low High Medium/Low
Low Medium Low
Low Low Low

This is one example of how you can categorize risks as being high, medium or low, based
on the likelihood of occurrence and the impact. There are many other techniques as well.
These high-level risks should be managed. The low level risks can be ignored. The
medium-level risks should be evaluated individually. You might need to respond to some
while others can be ignored for

Analyzing each risk allows you to determine which ones are important enough to
manage. This analysis save you the wasted time associated with managing risks that are
better documented, but ignored.
 Risk analysis

Risk analysis results and management plans should be updated periodically. Risk analysis
allows you to examine the risks that you or your organization face. It is based on a
structured approach to thinking through threats, followed by an evaluation of the
probability and cost of events occurring. . Risk management involves adapting the use of
existing resources, contingency planning and good use of new resources.

Risk analysis forms the basis for risk management and crisis prevention. There are two
primary reasons for this:

1. to evaluate whether the previously selected security controls are still applicable
and effective, and
2. to evaluate the possible risk level changes in the business environment. For
example, information risks are a good example of rapidly changing business
environment.

Managing risks in project is imperative for its success. We need to have a process (or
processes) in place for risk management to be effective. Here are the seven steps project
manager can use for risk management:

1. Identify Threats:

The first stage of a risk analysis is to identify threats facing you. Threats may be:

• Human - from individuals or organizations, illness, death, etc.

• Operational - from disruption to supplies and operations, loss of access to
essential assets, failures in distribution, etc.
• Reputational - from loss of business partner or employee confidence, or damage
to reputation in the market.
• Procedural - from failures of accountability, internal systems and controls,
organization, fraud, etc.
• Project - risks of cost over-runs, jobs taking too long, of insufficient product or
service quality, etc.
• Financial - from business failure, stock market, interest rates, unemployment, etc.
• Technical - from advances in technology, technical failure, etc.
• Natural - threats from weather, natural disaster, accident, disease, etc.
• Political - from changes in tax regimes, public opinion, government policy,
foreign influence, etc.
• Others - Porter's Five Forces analysis may help you identify other risks.

This analysis of threat is important because it is so easy to overlook important threats.

One way of trying to capture them all is to use a number of different approaches:

• Firstly, run through a list such as the one above, to see if any apply
• Secondly, think through the systems, organizations or structures you operate, and
analyze risks to any part of those
 • See if you can see any vulnerabilities within these systems or structures
• Ask other people, who might have different perspectives.

2. Estimate Risk:

Once you have identified the threats you face, the next step is to work out the likelihood
of the threat being realized and to assess its impact.

One approach to this is to make your best estimate of the probability of the event
occurring, and to multiply this by the amount it will cost you to set things right if it
happens. This gives you a value for the risk.

3. Managing Risk:

Once you have worked out the value of risks you face, you can start to look at ways of
managing them. When you are doing this, it is important to choose cost effective
approaches - in most cases, there is no point in spending more to eliminating a risk than
the cost of the event if it occurs. Often, it may be better to accept the risk than to use
excessive resources to eliminate it.

Risk may be managed in a number of ways:

• By using existing assets:

Here existing resources can be used to counter risk. This may involve
improvements to existing methods and systems, changes in responsibilities,
improvements to accountability and internal controls, etc.
• By contingency planning:
You may decide to accept a risk, but choose to develop a plan to minimize its
effects if it happens. A good contingency plan will allow you to take action
immediately, with the minimum of project control if you find yourself in a crisis
management situation. Contingency plans also form a key part of Business
Continuity Planning (BCP) or Business Continuity management (BCM).
• By investing in new resources:
Your risk analysis should give you the basis for deciding whether to bring in
additional resources to counter the risk. This can also include insuring the risk:
Here you pay someone else to carry part of the risk - this is particularly important
where the risk is so great as to threaten your or your organization's solvency.

4. Reviews:

Once you have carried out a risk analysis and management exercise, it may be worth
carrying out regular reviews. These might involve formal reviews of the risk analysis, or
may involve testing systems and plans appropriately.

5. Plan Actions - Explore all the possible ways to reduce the impact of threats (or exploit
opportunities). Plan actions to eliminate the risks (or enhance the opportunities). Action
plans should be appropriate, cost effective and realistic.
6. Monitor & Implement the Action - Track the risks throughout the project. If risks
occur then implement the risk strategy based on action plan. Ex. If mitigation strategy is
selected, execute the contingency plan based on risk triggers. In case contingency plan
fails, execute fallback plan.

7. Measure the effectiveness & Control the risk impact - Measure the effectiveness of
the planned action and controlling the risk impact by understanding risk triggers & timely
implementation of planned actions.

Risk management processes are cyclic which starts from identification of a risk and it
may result in identification of another new risk.

There are plenty of ways to fail when managing a project. When a project does fail, the
project manager and executives pay dearly for these mistakes since the staff and product
costs are usually high, and a failed project like a CRM implementation will effect the
business for years.
After years of project successes, some failures, and roundtable discussions
Avoiding these 12 common mistakes will keep your projects on track and successful.

1. Project is Not Part of The Strategic Plan

2. No Executive Sponsorship

3. Poor Technology Evaluation

4. No Customer Involvement

5. Scope Creep

6. Invalid Pilots

7. Inadequate Testing

8. Poor Planning

9. Rolling Out At The Wrong Time

10. Limited Training

11. Under Estimating Change To The Business

12. Avoiding Risk Analysis

1. Project Is Not Part Of The Strategic Plan

A strategic plan identifies your company’s business goals and the solutions needed to
support those business goals. If a project does not line up with one of the items on the
strategic plan, you should not do the project.
Many organizations are in a “re-active” mode. Their focus is on the hottest fire of the
day. These organizations usually look at a strategic plan once a year or sometimes never
create one. Within these organizations project failure is more prominent than project
success. What is the key? Projects aligned with business goals on the strategic plan will
“add value” to the business and your customers.
A large manufacturing organization implemented an expensive application monitoring
solution that was implemented on-time and 13% over budget. The justification for the
project: Help Desk staff would better understand the user application needs and problems
when they called in with an issue. The project team considered this a success, plus they
had some cool technology to play with. Unfortunately for the project team, the CFO
attended the project de-briefing. The CFO’s only question to the team was: “How does
this product help us produce more widgets, reduce inventory, or improve customer
service?” After a minute of silence and blank faces, the CFO then stated that this project
was a failure and just cost us $300,000 +, returning no value to the business. This project
team learned a lesson the hard way.

Roadblocks Encountered
Non-strategic projects are first to be cancelled

Team members and other resources are pulled for higher priority “strategic”
projects

Executive and business unit time commitments are limited

Project budget is reduced

Executives and business units are slow to respond to critical issues, risks, or
project activities

Action Items
Identify which item on the strategic plan your project supports

Understand the priority of this strategic plan item

Understand the “value” your project brings to the business

Decide whether the risks are to high too continue
2. No Executive Sponsorship
Executive sponsorship of your project is vital for project success. Active sponsor
participation has historically ensured a project will be on-time, within budget, and meet
the business goals. Take a look at the projects you have been involved in over the past
year. When there is an executive sponsor sitting in status meetings, reviewing plans,
meeting with team members, etc. the project team stays focused on the project objectives,
roadblocks are removed immediately, and morale is up. Project teams seem to feed off
the executives leadership and focus. Projects that are delegated down to line level
managers seem to float along, stop when issues arise, and go in fragmented directions.
These projects have a higher risk of failure.
There are three areas of sponsorship your project should have before moving forward. At
smaller companies, there may be one executive who will sponsor all three areas and in
larger organizations this will be three different executives. Technical Sponsorship: The
executive responsible for the technology strategy, issues and decisions. Business
Sponsorship: The executive responsible for the implemented features, functions and
business processes. Financial Sponsorship: The executive responsible for the project
costs, total cost of ownership, and return on investment.

Roadblocks Encountered

Project does not get the right level of support when needed

Project goes in fragmented directions

Issue resolutions are slow to arrive, sometimes causing a stoppage of the project

Project lacks focus

No leadership

Action Items

Identify the technical, business, and financial sponsor

Determine the sponsors participation in the project

Elicit sponsorship from C-Level executives who will receive the greatest value
from the project
3. Poor Technology Evaluation
Many project failures start at the beginning. The evaluation team is knowledgeable on
some aspects of the technology but they do not spend enough time researching solutions
and they believe all the hype from vendors and industry media.
We have found successful project teams perform an intensive due diligence upfront by
using tools like RFI’s, RFP’s, client visits, demo’s using live customer data, etc. Asking
the tough detail questions in the beginning can save your return on investment at the end.

Roadblocks Encountered

Products selected do not work

Products selected have never been implemented before

The correct components were not budgeted or purchased until later in the project

Vendor goes out of business before project completion

Action Items

Perform an intensive due diligence upfront

Verify reality vs. vaporware

See it, touch it, and use it in a comparable environment

4. No Customer Involvement
Successful projects need input from the people who will be affected most by the project.
The customers should be consulted on the value they will receive from a product. When
implementing an inventory control system, your best feedback will come from the
inventory control clerks and supervisors. They better understand the business processes
and how to improve efficiencies than anyone else on a project team. These customers can
best help with process improvements, features, and functions.
Another key factor on customer involvement is who will be included on the team.
Successful projects have the best and brightest customers on the team. These individuals
make the best decisions in a more timely manner. Also, their time is committed to the
project to avoid the day to day business priorities that would normally take them away
from the project.

Roadblocks Encountered

Products developed do not meet customer needs

New business process reduces productivity

Product design takes longer than expected

Product is not accepted by the customers

Products developed do not provide a return on investment or add value to the

business

Action Items

Assign the best and brightest customers to the project

Commit customer time to the project to avoid day to day priorities

5. Scope Creep
Adding additional scope without testing it against the business case and evaluating the
impact on the cost, schedule, and risks is the easiest way to sink a project. Modifying
products is risky and the most common form of scope creep. The project best practice is
to implement quickly, get the benefit quickly, and modify later. As an example, waiting
on software features is better than getting off the vendor upgrade path.
A large retailer implementing a retail management system decided their operations were
so unique that they changed 90% of the programs during a two year, $11 million
implementation. During the development phase of this project, the vendor released a new
and improved version of the software. Once the modified package was implemented, the
retailer looked at upgrading to the new release. First, they found that they were not
eligible for software upgrades since they modified the code. Second, analysis determined
that they would need one full year of programming effort to input the same modifications
into the new release. End result, they will be customizing and running this system until it
breaks or they can cost justify the purchase of a new system.
The least predictable “scope creep” issues are changing business needs, business models,
mergers, and acquisitions. These add complexity but have less impact to the project when
implemented in smaller milestones and phases.

Roadblocks Encountered

Development never ends, product changes frequently

Modifications to product during initial development drastically increases your risk

of failure

Getting off the vendor upgrade path

Unexpected increase in cost, effort, and duration

Action Items

Only modify products if business critical

Test the change in scope against the business case

Evaluate impact on cost, schedule, and risks

Implement scope changes in the next release

Set up a Change Management committee

6. Invalid Pilots
Pilot phases of a project can be very enlightening. What a great tool, test the product in a
smaller real life environment. Failure occurs when the pilot does not simulate reality.
A mid west distribution company built a brand new lab environment for the new Back
Office System project. The pilot was a complete success. Problems started occurring
during the rollout of the software to remote locations. Unknowingly, a project lead asked
“What is the hardware configuration of the pilot test lab?”. What did they find? The lab
was built with the latest and greatest server and desktop hardware. The remote facilities
were running hardware from five years ago and did not support the new software.
When performing a pilot, have an accurate inventory of all hardware, software, tools, etc.
Validate them all during a pilot.

Roadblocks Encountered

Pilot lab equipment does not mimic reality

Works in the lab, not on the production floor

Product can be a complete failure on the first day it is released

Action Items

Before starting, document an accurate inventory of all hardware, software, and

other production environment information

Validate the pilot tests for all environment configurations

7. Inadequate Testing
Question: What is the second item cut when a project is low on funding or over budget?
Answer: Testing of course.
Limiting your testing of a solution will increase the chance of system failure or unknown
bugs that can cripple your business. Do not skimp on testing to save time or money.
Eliminate features first.
To limit project failure, the testing phase should consist of system test, customer
acceptance testing, volume testing, and stress testing to test scalability.

Roadblocks Encountered

Dramatic increase in product bugs

Dramatic increase in quality issues

Increased risk of product failure

Increased costs during deployment and support

Low customer satisfaction

Action Items

Eliminate features before cutting back on testing

Testing should include system test, customer acceptance test, volume test, and
stress testing
8. Poor Planning
Rolling out a product to one location is fairly simple. Now, take the same product and try
deploying it to hundreds of locations across the country simultaneously. Multiple location
deployments are more of a challenge to do quickly and cost effectively. Larger
deployments require more planning due to greater chances of conflicts and timing issues.
Proper planning of equipment and resources will make or break the project.

Roadblocks Encountered

Number of outside locations to deploy products increases project complexity and

risk exponentially

Unknown conflicts and timing issues delay project

Unexpected staffing needs

Unexpected equipment and supply needs, increasing cost of project

Action Items

Perform a detail plan before the start of the project

Review and adjust plan on a daily basis

9. Rolling Out At The Wrong Time
Proper timing of a project “Go Live” is an important success factor that is often
challenged by missed milestone dates. Business sponsors want solutions implemented
before peak times where it will provide the greatest benefit. However, pilots and testing
cannot be sacrificed. Pressing your luck on the timing of a rollout can be disastrous.
A small specialty retailer was behind schedule on a warehouse system implementation.
The original planned completion date of the project was one month prior to the Christmas
rush where the facility pushed through 1/3 of the yearly volume. Scope creep added an
additional 2 months to the project, but the new date was not acceptable. Limiting the
software testing reduced this overage by 1 month. Therefore, the team was behind
schedule by 1 month but could be implemented days before the Christmas rush. This new
software was so important to the business that they made a decision to “Go Live” the
weekend before the heaviest volume would arrive. Due to poor testing, the system could
not handle the warehouse volume which slowed productivity and delayed shipments to
the stores. A project post mortem review estimated a $13 million loss of sales caused by
the poorly timed system roll out.

Roadblocks Encountered

Missed milestones and a “Go Live” date that cannot move will sacrifice other key
project needs (i.e. Testing, pilot, etc.)

Peak volume season sounds good to the business but adds unnecessary stress and
risk

Conflicts with other projects and initiatives targeted for the same period of time

Action Items

Once a “Go Live” date is available, evaluate the business cycle, other project
dependencies, alternative dates, etc.

Understand why the business needs a solution by a certain date

Allocate enough time between “Go Live” and Peak Season to work out any last
minute kinks
10. Limited Training
Training is the first thing cut from a project when funding is low or over budget. You get
the product released and the sponsors will not spend additional money on training.
Without proper training, the new system will not provide the expected return on
investment. Additionally, poor or no training will lead to low customer acceptance
resulting in a failed project. To receive value, the customer must know how to use the
new product.

Roadblocks Encountered

Low customer acceptance

Increased costs during deployment and support

Low morale and decreased productivity

Lost revenue

Action Items

Prepare a low cost training alternative

Involve customers more during the product testing

Eliminate features before cutting back on training

Delay the project if possible \

11. Underestimating Change To The Business
Change management involves the business process changes necessary to succeed. When
implementing software, failure occurs most of the time when the project sponsors do not
understand that they must change the business to work with the software or change the
software to work like the business.
Managing change is more difficult in organizations with high turnover, lack of education,
or high stress environments. To successfully manage change, a project should have 25 to
35% of the budget allocated to change management. This allocation will lower the project
risk and provide a cushion toward project success.
Take, for example, the shoe company that implemented a warehouse management
system to increase inventory accuracy and throughput. The project was, from the
beginning, focused on software features and functions. Little attention was given to
current and future operating practices on the warehouse floor, how they could
improve and must change. In the end, the implementation resulted in a 1.2 million-
square-foot facility that was very adept at quickly losing product. If process
improvements are identified early, as part of the business case effort, they are much
more likely to be carried through to implementation.

Roadblocks Encountered

Project and business processes are not aligned

Business process changes are not considered until the end of the project

Drastic process or project changes required at the last minute causing overages
and delays

Results in reduced or negative ROI

Action Items

Understand the business process impact of the solution at the beginning of the
project

Allocate a 25 to 35% change management budget (time and cost)

Set up a Change Management committee with the business

12. Avoiding Risk Analysis
No one likes discussing project risks. It is human nature to think positive, nothing will go
wrong.
Sometimes success or failure is determined by how well prepared a project team is when
disaster occurs. If the project team or organization is not prepared, the project may stop
unexpectedly until a new plan can be executed.
During a project milestone review session at one financial services company, the project
manager was asked “risk type” questions like, “What are the chances that vacations will
slow down the project?” and “What affects will a union strike have on the project?”. The
project manager answered with one statement, “We don’t worry about those things, we
are here to code, test and install this application.” As you guessed, no one analyzed the
risks so no mitigation plan was in place. In the end, consultants were hired to make up for
low staff counts, the project was over budget by 43% and implemented 4 months late.
An insurance company that ran a skeleton staff always ran projects by the seat of their
pants. Plans were sketched out on scrap pieces of paper and planning for the unexpected
was considered a waste of time. During a hardware and software upgrade that was to be
implemented before year end processing, there was no contingency plan if the hardware
was late. Due to production problems, the new hardware was delayed for 2 months. Two
weeks before the “Go Live”, they were scrambling around looking to rent hardware.
Unfortunately, the project was not implemented before year end.
Successful projects start a risk management log on the first day. Risks are identified
throughout the project, a mitigation or contingency plan is defined for each risk,
priorities, probabilities and ownership is assigned. Staying on top of project risks will
keep your project on track.

Roadblocks Encountered

Nobody likes discussing “risks”

Project teams are not prepared for disaster

Unrealistic view of the project status

A .01% risk probability can stop a $100 million project dead

Unexpected project delays and cost overruns

Action Items

Day 1, start a risk management log

Identify risks throughout the project

Continually revise risk mitigation and contingency plans

Avoiding These Common Mistakes Will …

Reduce project overruns and missed schedules

Improve project ROI and business value

Improve customer satisfaction