Professional Documents
Culture Documents
Project Management Case Study
Project Management Case Study
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
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.
• 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:
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:
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.
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.
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.
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).
The degree of likelihood that a project will not be completed on schedule and within
budget or that a loan will not be repaid.
Project risk management is a structured process that allows individual risk events and
overall project risk to be understood and managed
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
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.
• 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 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.
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
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:
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:
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:
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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)
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:
• 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.
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.
2. No Executive Sponsorship
4. No Customer Involvement
5. Scope Creep
6. Invalid Pilots
7. Inadequate Testing
8. Poor Planning
Roadblocks Encountered
Non-strategic projects are first to be cancelled
Team members and other resources are pulled for higher priority “strategic”
projects
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
Roadblocks Encountered
Project does not get the right level of support when needed
Issue resolutions are slow to arrive, sometimes causing a stoppage of the project
No leadership
Action Items
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
The correct components were not budgeted or purchased until later in the project
Action Items
Roadblocks Encountered
Action Items
Roadblocks Encountered
Action Items
Roadblocks Encountered
Action Items
Roadblocks Encountered
Action Items
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
Action Items
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.
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
Lost revenue
Action Items
Roadblocks Encountered
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
Action Items
Understand the business process impact of the solution at the beginning of the
project
Roadblocks Encountered
Action Items