Project Management: Risk Management

Get the PDF Version

By CJ Williams

In many projects, risks are identified and analysed in a random, brainstorming, fashion.
This is often fatal to the success of the project, as unexpected risks arise, which have not
been assessed or planned for and have to be dealt with on an emergency basis, rather than
be prepared for and defended against in a planned, measured, manner. Very early in the
preparation and planning stage, it is essential that potential risks are identified, categorized
and evaluated. Rather than look at each risk independently and randomly, it is much more
effective to identify risks and then group them into categories, or, to draw up a list of
categories and then to identify potential risks within each category. This way, common
influences, factors, causes, potential impacts and potential preventative and or corrective
actions, can be discussed and agreed on.
Categorising risks is a way to systematically identify the risks and provide a foundation for
awareness, understanding and action. Each project will have its own structure and
differences, but here are some categories that are common to most projects (to which you
can add your own local, sector, or project specific, categories). I have not given deep detail
here, but your project team and sponsors should be able to relate to these categories and
use them in the risk assessment process. For example, with "operational resources" your
team can discuss issues such as, availability, delivery timing, cost, capability, necessary
conditions for operation (eg. ground, weather, light); with "stakeholder resources" your
team can identify all stakeholders and list potential risks that these stakeholders may
generate, such as bad publicity from the media, delays caused by community or
environmental groups, delays caused by utility companies, problems with trade unions.
Related risks and potential actions, must then be documented in the risk management plan
and discussed at all the key stages as the project progresses. All the details and the actual
action taken and the outcomes, must then be recorded and reviewed during the closure and
review stage, for lessons to be learned and applied to future projects.
Here the question that most project managers ask: "how do we know if we can manage the
risk, if it arises?" Often, sadly, no evaluation is carried out to determine the expertise,
experience, capabilities of the team, individuals, organisations that would be required to
deal with, manage that risk, if it occurred. As a result, if it did, the team may not be able to
deal with it effectively, even though the initial forecast was that the risk could be managed.
This happens frequently when the planning team is not the project team that manages the
project and/or when key individuals in the original project team leave the team during the
project and are replaced by individuals with different skills, experience and capabilities. The
clear message here is that setting a risk tolerance level is a dangerous business. Each
potential risk needs to be carefully, rigorously, analysed and the project team, the
supporting teams and individuals, the organisation(s) involved in managing the project, all
need to be evaluated to determine whether there is the capability to manage that risk
successfully, should it arise. Where gaps in capability are identified, then appropriate
corrective action must be taken. During the project itself, this capability must be constantly
monitored and, where necessary, action taken to return the level of capability to the
required level.
Conflict over resources often arise during the middle to later stages of a project, because,
often unexpected other, newer demands arise which are seen as being of higher priority.
This can lead to resources that were originally allocated to the project being taken away, or
reduced in quantity or quality, almost certainly to the detriment of the project. The answer
to this dilemma is not easy, but in essence, the project management team must include
"conflict over resources during the life of the project" as a major potential risk and plan for
it accordingly by securing agreements and then monitoring the situation continuously. If a
dispute does arise, there is a role here for the project champion and or the client to ensure
that the allocated resources are not taken away.
Fundamental to many of the issues that we discuss here is the question of who should be
responsible for risk assessment and management. Too often the responsibility for risk
identification, assessment and management, are left to the project team, especially once
the project has started. But there are other individuals and groups, including some external
stakeholders, who should be continuously monitoring particular activity and feeding back
regularly to the project team leader. Some are easy to identify. They include of course, the
client, the sponsor, key specialists in the project team's organisation, or organisations, the
major external participants, such as emergency services, local authorities and contractors.
The easy way to identify other individuals and groups is to look at your list of stakeholders.
Each one has a responsibility, to a greater or lesser degree, to help identify potential risk
and give information on this to the project team. Again, the answer to managing the
question of risk responsibility is to build discussion, planning and action, on this into the
project planning and operational activity.
CJ Williams is a tutor and management consultant currently working with Brighton School of
Business and Management in the UK, specialising in Business and Management courses
taught via distance learning. The writer, CJ Williams, can be contacted
atcjwilliams@brightonsbm.com or via Brighton School of Business and Management

Reducing Risk and Increasing the

Probability of Project Success
IT Software Development Just Isn't Working!
Get the PDF Version

By Cliff Murphy

IT systems are at the heart of modern business and the development of new software
applications and maintenance of existing systems are critical to productivity and
profitability. Advances in software technology over the last 20 years have allowed
progressively more complex business solutions to be created enabling companies to offer
their customers exciting new services and products. And yet, software development projects
still suffer from similar problems and characteristics, regardless of the technologies being
used, that they suffered from more than ten years ago.
A report from the Standish Group clearly shows that the reliability of delivery of IT software
applications has not improved over the years. Figure 1 is for 2001 and this looks remarkably
similar to a diagram from the same source in the early 1990's.
Figure 1: Software Projects
The important question that needs to be addressed is why is software development so
risky?

Change Is Inevitable
All software projects implicitly have associated risks. One of the major sources of risk
results from changes that occur during the project's lifecycle. In its most common form, this
is seen as changing user requirements. It is, however, not just confined to this area. For
example the following changes all present real risk to projects:

1. Changes to the makeup of the project team or in stakeholders

2. Changes in the technology being used

3. Changes to any external systems with which the new software must work

How you deal with changes to the project is the key to reducing your development risks,
and to increasing the overall chances of success of your project.
But what is the best way to do this? The major influence lies in the development process
you choose and not the technologies being used.

Picking The Right Process

As a project manager you may be tempted to try and eliminate change in your project
through a rigid policy of no change.
This is the case for waterfall processes where the major assumption is that development can
proceed in an orderly, linear and predictable fashion. Waterfall processes have a clearly
defined sequence of stages, each of which must be completed and signed off before
progressing to the next stage.
For example Requirements (capturing) is completed before Analysis is started. Design
cannot then be started until Analysis is complete and signed off...and so on.
Figure 2 shows the typical lifecycle of a waterfall development process.
Figure 2: Waterfall Development Lifecycle
Waterfall processes may appear at first glance to be a reasonable and common sense
approach. The problem is that developing software is inherently unpredictable and this type
of process does not cope effectively with change. The result is that this approach to
developing software almost always fails to mitigate risk.
Worse still, with this type of process, you may all too often be lulled into to a false sense of
security as the project progresses. By adopting a rigid sign off strategy for each activity in
the project, it is all too easy to believe that the project is getting easier and risk is reducing
as you get nearer to the go live date.
Change will inevitably occur during the project lifecycle, and this is usually the result of
feedback. As we see in figure 3, waterfall processes have a late feedback cycle for the part
that really counts, the actual software code, and not the signed off paperwork.

Figure 3: Coping with Change

The result is that changes often need to be made to the system during the later project
stages such as integration (when the different modules of software code are assembled into
one application system) and the testing of the system proper. Imagine having to write off a
100 man-year project, after having already spent 95 man-years of the budget, because of a
fundamental misunderstanding in the user's requirements!
The risk profile for waterfall processes, as shown in figure 4, is inappropriate for software
development.

Figure 4: Waterfall Risk Profile

The fundamental problem with waterfall processes is that they rely on the assumption that
the progress of a software project can be predicted with reasonable accuracy from the
outset, and that a reliable completion date can be derived from this. By assuming that the
development lifecycle will be predictable, you are admitting that a high degree of risk
cannot exist within a project. This is a fools paradise! The Waterfall process is the wrong
approach for software development.

A Lower Risk Approach - Iterative Development

Project risks are associated with the unknown. These can be technical, organisational or
business oriented in nature, such as:

1. How will my system communicate with system A?

2. How do I manage my offshore development group?

3. Do the system requirements actually reflect the true needs of the users?

4. etc...

Adaptive software development processes realise that producing software is a risky business
and highly unpredictable in nature. They also recognise that the best mechanism for
achieving successful delivery is to contain and mitigate risk by means of the regular and
controlled delivery of testable software code to provide a reality check on progress and to
give feedback to the users throughout the entire lifecycle of the project.

Key Principles
There is no single overriding rule that guarantees project success but the following key
principles will greatly increase your chances:

1. The adoption of an Iterative Risk Driven Approach

2. The commitment and involvement of senior management

3. A high level of communication between all project team members

4. A highly skilled development team

5. The adoption of a Use Case driven approach

6. The adoption of a comprehensive and rigorous system of change control

7. The use of Visual modelling

Iterative Risk Driven Approach

This will reduce risks by developing small pieces of the system over a short timeframe (a
maximum of four weeks for large projects). At the end of each development cycle, the
software should be demonstrated to the users to obtain feedback on its functionality and
suitability.
An iterative approach will continuously reduce project risk from the outset. The reason why,
is that it forces the team to address the most important aspects of functionality and to
resolve high risk issues at an early stage.
A real example of how an iterative approach reduces risk occurred in 2001 when I was
working on developing an application to monitor financial transactions. One of the users'
requirements meant that the system had to process one million financial trades within an
eight hour window. The client was adamant that this was a key requirement and that the
application must be capable of running on low cost hardware. We recognised that there was
a major risk that we might not be able to meet these performance objectives, so we built a
basic working system within three weeks and provided critical feedback to the users that we
could only achieve 10% of the performance required.
Result - the users reassessed their objectives and realised that a lower processing target
was indeed adequate. This major risk was thus mitigated within the first three weeks of the
project.
Figure 5 provides a comparison of typical risk profiles between iterative and waterfall
development lifecycles. The iterative cycle continuously mitigates risk from the early project
stages as a result of regular feedback from users.
Figure 5: Risk Profile Comparison Between Iterative and Waterfall Processes

Senior Management Commitment

Changing the way people work is probably the hardest thing to do in any business and when
it involves technologists it can be an even harder challenge. It is important to ensure you
have full executive support for any type of process change. You will need backup to drive
through changes in the early stages - but once the process starts working, people will
naturally want to be associated with it.

High Level of Communication - Keep Talking!

First and foremost projects are about people. Without everybody working together you
haven't got a team and the project will fail.
Communication is paramount within the team and more importantly with your users and
sponsors. This has to be on a regular basis, daily with the team, and at least weekly with
the users and sponsors. Your end goal should be to make all these groups part of the
project team. Iterative development will greatly increase communication with the users.
Communication comes in many forms - not just verbal, and includes producing good
documentation. Aim to keep documentation lightweight by adopting a 'just enough' policy.
Use visual modelling (key principle) whenever possible to raise the level of communication.

Highly Skilled Development Team

A highly skilled group of individuals that understands how to work together should form the
nucleus of your team. They will be very efficient and productive. If you haven't already got
the right mix of skills (technical and process), then invest in training focused on meeting
your project's needs. Do not, however, waste time and money with off-the-shelf 'one size
fits all' training courses. Consider supporting your project team with expert mentors to
assist and accelerate process adoption.

Use Case Driven Approach

Use Cases are highly effective because they provide a contextual representation of the
system requirements. One of the main reasons why they should be used is that they are
non-technical in nature and provide a written step by step description of how the actors
(system users - human or otherwise) shall interact with the system. Simplicity is the key
strength of use cases.
So many times I have seen documents that purport to contain the complete system
requirements, when in fact they are just a set of business rules and a list of user needs. To
drive a project forward, you need objectives and goals to aim for, and Use Cases are the
best way do this. They bind together the whole development process from the capturing of
user requirements through to the testing of the application software.

Change Control
This is very different from stopping change from occurring to your project. Instead the
emphasis is on the careful consideration of new requests and deciding (with the users) how
these should be accommodated. For example, if the delivery date is fixed, does a new
request mean that an existing requirement has to be removed from the live release, or that
a further system release should be considered?

Visual Modelling - 'A picture is worth a thousand words'

Visual modelling is the modern equivalent of the "flowcharts" used in the early days of
software production. The value of visual aids remains valid and diagrams should be used
throughout the project. Demand that all roles use the same modelling notation, from
business analysts to designer and coders through to testers. The UML (Unified Modelling
Language) is the de facto standard for the visual modelling of systems and should be used
to communicate consistently and concisely across the project. There is no excuse for not
using it.

Are You Really Risk Focused?

I have worked with many clients and spoken to senior managers and technical specialists
who swear that they are risk focused and follow an iterative approach. You will come across
the same situations, so how do you know if your IT group is really doing risk based iterative
development?
Ask a few telling questions:
How long is an iteration?
The answer should be anywhere from a few days to a maximum of about four weeks.
Answers of three months or more should indicate the process is still waterfall with long
feedback cycles with the associated high risk of getting it badly wrong before being able to
rectify the situation.
What is delivered at the end of each iteration?
The answer should be a demonstration of some actual working software to the users, during
which they will have the opportunity to provide feedback. If the answer is documents for
sign-off, then they are missing the point.
When do you the users see what they are going to get?
The answer should be at the end of every (short) iteration. An answer of "only during
acceptance testing prior to delivery" is just not acceptable.
When do you intend to start integration testing?
The answer should be that integration testing is a continuous activity that occurs during
each iteration.
How do you manage risk?
The answer should be that there is a regular assessment of risk, quantified in terms of
probability and impact to the development schedule along with proposed mitigation
strategies. The project manager should maintain a running risk list, available for inspection
by all people associated with the project.

Longer Term Business Continuity

So if I adopt all these good practices what does this really mean to my business?
We know that software development is a highly risky business that costs a lot of time, effort
and money. But the greatest costs occur long after the initial development is over, as shown
in diagram 6, when the system enters the support and maintenance phase of it lifecycle.

Figure 6: Software Cost Breakdown

Adopting these good practices, with the focus on developing systems that deliver what the
users actually want, will usually produce systems that are of a higher build quality and are
'fit for purpose'.
This typically results in systems that are easier to maintain and revise and thereby reduce
the long term operational costs and associated risks.
Cliff Murphy is a founder and director of Liemur Limited Liemur is a UK based company
providing a range of specialised services to optimise software development and maximise
business return on investment in IT. Copyright: Liemur Limited

10 Golden Rules of Project Risk

Management
Get the PDF Version
By Bart Jutte

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.
This article gives you 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. Also the big pile of literature available on the subject has been
condensed in this article.

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.
Success with your project!
Bart Jutte is a founder and consultant at Concilio, a NL based company specialising in
project risk management. Concilio offers consultancy, training and sells its own easy to use
risk management software. A free demo is available at ProjectFuture.

The Seven Deadly Sins of Risk Management

Get the PDF Version
By Kareem Shaker, PMP

26 Sep
2010
Risk management is the heart and soul of project management. Failing to practice it right
can have fatal consequences on projects and programmes. Doing real effort in the planning
stage can save the entire investment and will increase the likelihood of project success.
However, planning alone is not enough if monitoring risks is not handled seriously. These
are seven deadly sins of risk management and how to take preventive actions to avoid
them.

1. Disregarding Enterprise Risk Management

Enterprise Risk Management (aka ERM) specifies the processes, frameworks, and
methodologies an organisation uses to identify and manage enterprise risks of all types,
such as operational, strategic, financial, compliance, etc. The project manager has to
consider the enterprise-wide risks and study what threats the organisation is likely to
encounter during the projects' lifetime. Consulting the Chief Risk Officer (CRO) before and
while building the risk management plan can have a mammoth impact on the way the
project management plan will be developed. The project risk management has to be
congruent with ERM, since the ERM governance can impose certain documents to be
delivered, probability/impact scales, risk appetite, and risk management software to be
used. Project Management Institute refers to those as Enterprise Environmental Factors
(EEF).

2. Using Incomplete Risk Breakdown Structure

Risk Breakdown Structure (RBS) is the catalyst to identify large numbers of risks. Risk
management teams use it to identify risks and stimulate the minds of the stakeholders who
will be participating in the risk identification stage. RBS can be developed by listing all the
root causes of potential risks. RBS highly depends on the project domain. Every industry
has its own associated risks. Risks that are valid to a software project may not be applicable
to a construction project. The project manager can start with a template from a known body
and customise it based on previous project history and project-specific risk categories.

3. Ignoring Subjectivity
Subjectivity can make risk management lose its essence. You will find that risk averse stakeholders
will identify large numbers of risks; in contrast, risk takers may be oblivious to real risks. It is
important to mediate these conflicts during risk identification.
The risk identification process is substantial for successful risk management. I believe that
identifying risks will always get 60% of the job done, and the rest is sort of "Just Do It!"
There are different information gathering techniques to solicit stakeholders' input. The
perpetual problem of risk management information is subjectivity. Different people will
perceive risks in different ways. For instance, a financial risk may not grab a technical
manager's attention, and a technical risk is very unlikely to be deemed as a risk by a
financial manager. It is the responsibility of the risk management team to remove
subjectivity and ensure quality of risk information. Subjectivity can be avoided by using the
Delphi Technique, as it keeps the views of different subject matter experts anonymous,
even after finishing the identification phase.

4. Assigning All The Risks to The Project Manager

Successful risk management can never be a one-man army. The risk management team has
to set clear expectations and inform subject matter experts, stakeholders, customers, team
members of what is expected from them. The ownership of risks has to be communicated to
the risk owners. The project manager has to follow up on the status of assigned risks, and
the risk owner has to report risk status updates on a frequent basis. The project manager
should not be the only individual who owns risks. Potential risk owners may be reluctant
during risk identification stage, fearing that they may be responsible for the risks they will
be identifying. Creating a risk management RACI Matrix (Responsible, Accountable,
Consulted, Informed) will ensure roles and responsibilities are clearly identified and
communicated.

5. Neglecting Risk Management Benefit Cost Analysis

Not all risks have to be managed; some risks just need to be accepted. Response strategies
of negative risks (yes, there are positive risks, those are known as opportunities) are Avoid,
Transfer, Mitigate, and Accept, but oftentimes the acceptance strategy is never considered.
Risks have to be accepted for two main reasons; first is unfeasibility of the first three
response strategies, and second is due to unfavourable benefit cost analysis. For instance, if
the loss value is much smaller than the benefit gained, due to implementing a control, it
would be rational to accept the risk; otherwise you would be paying $100 to save a $60
risk.

6. Misusing Contingency Reserve

Contingency reserve can only be determined after the project manager has had multiple
revisions of the project management plan. Contingency reserve should only be used when a
planned risk (aka known unknown) materialises. The contingency reserve should not be
used for any unplanned risk (unknown unknown). The unplanned risk can only be handled
by the management reserve. It is also not right to use the contingency quota of one risk at
the expense of another risk, unless the latter has already become void.

7. Doing it Once
Risk management is an iterative process and should be practiced in all project stages, from
inception to closure. It is not right to do it during the planning stage only, nor is it right to
stop looking for new risks during the execution phase. Many project managers conduct risk
identification at the beginning of the project, and shelve risks until they turn into issues.
The project manager should elevate the culture of risk management and ask team members
to report new risks. The new risks have to go through the process of analysis and response
strategy planning. The project manager has to visit the reserve balance and make sure that
no risk will have no contingency. It is also important to put risk management on the agenda
of frequent progress and status update meetings.
These are the seven deadly sins of project risk management as I could identify them. It
would be great if you can share your experience and articulate what could be a sin in risk
management from your perspective and how to avoid it.
Kareem Shaker, PMP is a project manager at Dubai World, he has over 10 years of
experience in IT projects, consulting, and pre-sales. Read his blog
atwww.KareemShaker.com

Project Risk: Is It All Bad?

Get the PDF Version
By Paul Slater
 30 Jan
2010
No one would disagree that managing risk within a project is not a good idea. Risk
Management is an essential part of any programme or project and can vastly contribute to
successful delivery. Where it can and does go wrong is when there is an over-reliance on
the risk aspects of the project and they in themselves start driving the way the project
moves forward. The management of risk is part and parcel of project management, but is
not the be all and end all of it as it sometimes becomes in more risk averse organisational
cultures.
To help understand how risk within projects can be better managed it is worth considering a
number of aspects of the risk identification and mitigation processes involved.

Appropriate Monitoring and Mitigation

The most important aspect here is the word 'appropriate'. For large, complex programmes
covering numerous disciplines, say construction, software, and telecommunications and
running for a number of years it is entirely appropriate to have a risk set-up that matches
that complexity. Matches and is appropriate, a set-up that identifies risks in the disparate
areas of the programme and allows judgments to be made across the programme as a
whole. There may well be a Risk Manager and team to assist that individual in collating the
requisite management information. The difficulties arise however when the scale of
programme or project is much reduced, but the risk processes of large complex
programmes are applied. When this happens, the risk process starts to drive the
programme and stops providing a benefit.

Record Once not in Multiple Related Projects

Far too often the same risks are identified across multiple related projects or within a
programme of projects. Even with sophisticated risk software the potential for confusion is
great with different scores being applied to probabilities and impacts. Make sure you identify
the one true risk and record it and track it within the correct project. If other projects or a
higher level programme need to be aware of it that is fine, make them aware of it, but
make sure you don't start double or triple scoring the same risk.

More Risks Recorded, the Longer the Project will Take

Strange but true. The more risks you identify and manage within a project the greater the
chance the project might not come in on time. The reason for this? Well, think about it, it's
very easy to identify lots of risks for any project, but it's how far you go that really matters.
Get right down 'in the weeds' and you will still have to identify risk owners and people to
investigate mitigation strategies etc. etc. All this takes valuable time and effort away from
the main job of project delivery itself. So, make sure you have the important risks identified
and managed and keep reviewing to ensure your list is up-to-date.

Accept the Risk as is

Once you have identified your set of appropriate risks for your project you need to decide
what to do about each and every one of them. Putting in place some form of mitigation may
be necessary and add cost to the budget, but that's just the way it is. Having said this there
could well be risks that you decide simply to accept as they are because either the
probability of them occurring is so low and/or the cost of putting in place some mitigation is
so high. You aren't ignoring the risk you are making a conscious decision to accept that it
may happen.

Opportunities Arise
Risks happen in any project and some may have been predicted and planned for while
others may not have been. The project is the project with its set requirements, that's what
everyone accepts as the truth. But, what if a risk occurs which starts to make you think
seriously about the validity of the project or the direction in which it's going? When
reviewing the project risks and looking at those that have occurred ask yourself the
question "Does this project still need to go in this direction or should we consider altering
it?" Of course, the ultimate might mean cancelling the project altogether, never an easy
decision for anyone.
So, are all risks bad? Of course not. Make sure you are managing the risks that are
appropriate to the project and make related programmes and projects aware of them and
you are most of the way there. Opportunities can be anywhere within a project space, but
just remember to think about them as you go through the risks; it starts to make that risk
review meeting far more meaningful.
Paul Slater owns and runs Mushcado Consulting in the UK, advising businesses and
organisations on how best to employ project management techniques to improve project
delivery. As a leadership coach, he works with individuals and organisations to bring out the
potential inherent in people. You can follow Paul on Twitter @Mushcado

The Principles of Risk Management

Get the PDF Version
By Simon Buehring
 21 Jul
2009
Every project manager and business leader needs to be aware of the practices and
principles of effective risk management. Understanding how to identify and treat risks to an
organisation, a programme or a project can save unnecessary difficulties later on, and will
prepare managers and team members for any unavoidable incidences or issues.
The OGC M_o_R (Management of Risk) framework identifies twelve principles, which are
intended "not ... to be prescriptive but [to] provide supportive guidance to enable
organisations to develop their own policies, processes, strategies and plan."

Organisational Context
A fundamental principle of all generic management methods, including PRINCE2 and MSP as
well as M_o_R, is that all organisations are different. Project managers, programme
managers and risk managers need to consider the specific context of the organisation in
order to ensure thorough identification of risks and appropriate risk treatment procedures.
The term 'organisational context' encompasses the political, economic, social, technological,
legal and environmental backdrop of an organisation.

Stakeholder Involvement
It is easy for a management team to become internalised and forget that stakeholders are
also key participants in everyday business procedures, short-term projects and business-
wide change programmes.
Understanding the roles of individual stakeholders and managing stakeholder involvement is
crucial to successful. Stakeholders should, as far as is appropriate, be made aware of risks
to a project or programme. Within the context and stakeholder involvement, "appropriate"
concerns: the identity and role of the stakeholder, the level of influence that the stakeholder
has over and outside of the organisation, the level of investment that the stakeholder has in
the organisation, and the type, probability and potential impact of the risk.

Organisational Objectives
Risks exist only in relation to the activities and objectives of an organisation. Rain is a
negative risk for a picnic, a positive risk for drought-ridden farmland and a non-risk for the
occupants of a submarine.
It is imperative that the individual responsible for risk management (whether that is the
business leader, the project/programme manager or a specialist risk manager) understands
the objectives of the organisation, in order to ensure a tailored approach.

M_o_R Approach
The processes, policies, strategies and plans within the M_o_R framework provide generic
guidelines and templates within a particular organisation. These guidelines are based on the
experience and research of professional risk managers from a wide range of organisations
and management backgrounds. Following best practices ensures that individuals involved in
managing the risks associated with an organisation's activity are able to learn from the
mistakes, experiments and lessons of others.

Reporting
Accurately and clearly representing data, and the transmission of this data to the
appropriate staff members, managers and stakeholders, is crucial to successful risk
management. The M_o_R methodology provides standard templates and tested structures
for managing the frequency, content and participants of risk communication.

Roles and Responsibilities

Fundamental to risk management best practice is the clear definition of risk management
roles and responsibilities. Individual functions and accountability must be transparent, both
within and outside an organisation. This is important both in terms of organisational
governance, and to ensure that all the necessary responsibilities are covered by appropriate
individuals.

Support Structure
A support structure is the provision within an organisation of standardised guidelines,
information, training and funding for individuals managing risks that may arise in any
specific area or project.
This can include a centralised risk management team, a standard risk management
approach and best-practice guidelines for reporting and reviewing organisational risks.

Early Warning Indicators

Risk identification is an essential first step for removing or alleviating risks. In some cases,
however, it is not possible to remove risks in advance. Early warning indicators are pre-
defined and quantified triggers that alert individuals responsible for risk management that
an identified risk is imminent. This enables the most thorough and prepared approach to
handling the situation.

Review Cycle
Related to the need for early warning indicators is the review cycle. This establishes the
regular review of identified risks and ensures that risk managers remain sensitive to new
risks, and to the effectiveness of current policies.
Overcoming Barriers to M_o_R
Any successful strategy requires thoughtful consideration of possible barriers to
implementation. Common issues include:

• Established roles, responsibilities, accountabilities and ownership.

• An appropriate budget for embedding approach and carrying out activities.

• Adequate and accessible training, tools and techniques.

• Risk management orientation, induction and training processes.

• Regular assessment of M_o_R approach (including all of the above issues.

Supportive Culture
Risk management underpins many different areas and aspects of an organisation's activity.
A supportive culture is essential for ensuring that everybody with risk management
responsibilities feels confident raising, discussing and managing risks.
A supportive risk management culture will also include evaluation and reward of risk
management competencies for the appropriate individuals.

Continual Improvement
In an evolving organisation, nothing stands still. An effective risk management policy
includes the capacity for re-evaluation and improvement. At a practical level, this will
require the nomination of an individual or a group of individuals to the responsibility of
ensuring that risk management policies and procedures are up-to-date, as well as the
establishment of regular review cycles of the organisation's risk management approach.
Simon Buehring is a project manager, consultant and trainer. He works for KnowledgeTrain
which offers management of risk training in the UK and overseas. He can be contacted via
the M_o_R Practitioner training website.

Is Software Development Risk Costing You

Money?
Get the PDF Version
By ExecutiveBrief
Poor software project management often means missed deadlines, cost overruns
or even outright failure of the project. How can your company avoid this industry-
wide problem? In our brief you'll learn best practices for successfully completing
software projects.
Software development projects are plagued with risk and impending failure. According to
The Standish Group's 2006CHAOS Report, only about one-third (35 percent) of the
researched software development projects undertaken in the previous two years were
considered "successful," that is, they met all requirements and were completed on time and
within budget. Almost half (46 percent) were reported to be "challenged," meaning that
they were completed and operational, but were delivered late, went over budget, or did not
support all of the features originally required. And 19 percent were considered outright
failures or cancelled prior to completion. According to the same report, 41 cents of every
dollar spent on software development was considered wasted.
Anyone involved with software development projects knows why bringing them to successful
completion can be so difficult to achieve. The most frequently cited factors that contribute
to the challenge include:

• Poor communication. The legendary communication gap between developers and

business clients or stakeholders often leads to poorly defined requirements, which in
turn will lead to inadequately designed software that doesn't provide the functionality
needed by the customer.

• Time. Because market forces today are continually changing, and at such a fast
pace, the longer a development project takes to get off the ground and cycle through
to completion, the more likely it will be that the software will fail to meet the current
needs of users. Requirements and priorities can change multiple times as projects
progress through planning, development, testing, and production.

• Scope. Poor communication, time creep, and intense market competition lead to
scope creep, where requirements are frequently changed and added to the project
without a proper evaluation of their true importance and without corresponding
increases in resources, budget, or schedule. A project whose scope is too broad will
become too complex, exceed allotted costs, overrun schedule, and ultimately fail. A
 project whose scope has been defined too narrowly may finish on time, but likely will
fail to perform according to customers' real requirements.

• Unorganised development processes. Despite the availability of established best

practices in software development, such as the U.S. Software Engineering Institute's
(SEI's) Capability Maturity Model Integration (CMMI), many development
departments don't follow a coherent development methodology. A study by the SEI
in 2005 found that, when it came to the quality of their development processes,
almost 40 percent of companies gave themselves a low rating of 1 or 2 out of a
possible 5 on the CMMI scale.

• Budget, resources, and schedule. Software development is rife with unrealistically

low budgets, inadequate resources, and limited time.

• Risk. Success for any IT project, particularly in software development, is very much
dependent on effective management of risks, both early on in the project and
throughout its lifespan. Not long ago, risk was defined almost exclusively in negative
terms, but in the past seven years or so, risk management philosophy has expanded
to include unexpected opportunities. "Risk can be defined as uncertainty that
matters," says David Hillson, director of Risk Doctor and Partners, a well-known
global consulting firm specialising in project risk management. "Uncertainties, when
they happen, can damage a project, but some uncertainties can help."

For example, new hires can bring new expertise that takes a project in a positive new
direction. A company could discover reusable code that it didn't know it had. Certain parts
of a project could finish early, opening up possibilities that seemed impossible at first. "You
can either rely on good luck or be proactive and seek out those opportunities."
There is more than one approach to risk management. The most widely known is probably
the one detailed in A Guide to the Project Management Body of Knowledge (PMBOK Guide)
published by the Project Management Institute (PMI), considered by many to be the project
management bible. Like any religious text, the PMBOK Guide has its legions of followers as
well as its fervent detractors, and alternative methodologies abound. But most approaches
to risk management follow steps similar to those outlined below.

Step #1: Identify

Identification of project risks is usually accomplished via a brainstorming session that
includes the development team and the stakeholders. Including stakeholders in this process
is essential for fostering good communication and gaining a true understanding of the
business risks associated with the project. For example, the company's financial calendar
may influence when certain accounting or other financial-related systems must be in place.
Including stakeholder representatives is also a great way to gauge their skills, availability,
and authority to make decisions for their part of the project. In the case of software
development, many of the risks analysed will stem from the factors outlined above (i.e.
communications, time, scope).
Risk experts cite two principles for the success of this step. The first is to avoid an
unfocused, free-for-all discussion. "The meeting really must be facilitated and structured,"
says Hillson. The PMBOK Guide includes a risk breakdown structure (RBS) that can help the
team to map out risks in a very detailed, hierarchical fashion. Another useful tool for
gauging internal and external treats and opportunities is the SWOT (strengths, weaknesses,
opportunities, and threats) analysis. It's also helpful to generate and repurpose checklists of
risks from similar past projects to help map out risks for the current one.
The second principle for success in the identification step is to ensure that the meeting
doesn't become an empty exercise done solely to comply with company policy. "My problem
with this process is that people often go through the steps without any real thinking," says
Gartner analyst Donna Fitzgerald. "They end up filling out the forms, but missing the real
substance." Fitzgerald points out that company politics play a big role in project risk and
that risk mitigation often entails measures that lie outside the original project. These factors
should not be ignored.
Hillson agrees. "The whole idea of this process is to be innovative and think outside the box.
Real risk management is about exceptions to the normal day job."

Step #2: Quantify and Prioritise

Once the identified risks are mapped out, the team should prioritise them based on
probability and expected impact. Certain risks can kill a project all by themselves; even if
the probability of such risks is low, they should be assigned a high priority. Risks that have
low impact and low probability often can be ignored. This is also a good time to map out
specific early warning signs for each of these risks.

Step #3: Address

The next step is to develop strategies for addressing each risk. Some of the classic
strategies include:

• Avoid it. Sometimes it's possible to find a strategy for avoiding a risk completely.
For example, if there's a risk that a certain supplier will deliver an essential item too
late to meet your deadline, it may be possible to use a different supplier.

• Minimise it. Some ways to minimise risks include lining up contingency plans and
funding, bringing in team members who have the expertise to take over a key task if
other members quit, or nurturing a positive relationship with people outside of the
team whose co-operation is essential for success. "No one person should be so
indispensable that losing this resource would mean a significant delay for the
 project," says Fitzgerald. In one of her projects, Fitzgerald had to add $80,000 to the
budget in order to hire a consultant who could take over if an unhappy critical team
member quit. "In every organisation, there's an off-org chart network of people who
get things done," says Fitzgerald. "Build your team so that you are tied into that
network from the start." Fitzgerald also points out the importance of putting together
a team of people who are known to be flexible and eager to adjust to new
circumstances.

• Transfer it. Sometimes you can hand over responsibility for certain risks to a
vendor, an outside consultant, or even a stakeholder.

• Accept it. If the impact and probability are minimal, it may not be worth addressing
the risk at all.

Again, it's always a good idea to keep records of successful strategies from past projects
that could be useful for addressing the risks of a current one. This is also the time to assign
each risk to an owner who will be responsible for detecting and addressing it.

Step #4: Monitor

Murphy's Law reigns in just about every project. Frequent risk reviews should be conducted
to continually monitor for early warning signs of risks, assess progress in addressing
identified risks, close out some risks, and discover new risks that have cropped up. Ongoing
communication with stakeholders about a project's progress and shifting risk profile is
important as well.
This is also the time to assess whether the project may be in real trouble. Fitzgerald points
out some key early warning signs, including a high number of unresolved issues, persistent
disagreements about what should be done, and early slippage in the schedule. Any of these
circumstances may indicate a need to reassess your entire risk management and project
implementation strategy.

Step #5: Record

Post-mortem reviews can be extremely valuable in planning for successful future projects.
Conduct an end-to-end evaluation of the project, from conception to delivery. Compare the
risks that you originally identified with the real risks that you ultimately needed to address.
Which strategies worked, which didn't, and what would you do differently next time? Record
this information and use it to create checklists that can be referenced during your next
initiative.

Consider Agile Development Techniques

In recent years, agile development has risen in popularity as a way to minimise risks related
to time, scope, and communication. Rather than undertaking massive software projects in
their entirety, agile development methods promote development of one small complete
piece at a time. "Software is evolutionary by nature, which is why projects that last longer
than six months have a very high failure rate," says Fitzgerald. "Get in, and get something
done in less than six months. Then, when the state of affairs changes, do something else."

Get Real
A structured risk-management process is vital to success, but it's also important to align the
structure to the size and type of project and to your company philosophy. "Your risk process
should be scalable," says Hillson. "A small project probably requires a light touch, perhaps
an hour-long meeting every couple of weeks." On the other hand, a large project at a large
company with many players and stakeholders very well could require a highly structured,
detailed approach to managing risk. Perhaps more important, however, is to cultivate an
organisational culture in which everyone understands and lives the concepts of risk
management instinctively. Fitzgerald offers this suggestion: "Your company should adopt an
attitude that likens risk management to breathing."
ExecutiveBrief, the technology management resource for business leaders, offers proven
tips, techniques, and action plans that companies can use to better manage people,
processes and tools - the keys to improving their business performance. To learn more,
please visit: http://www.executivebrief.com
© ExecutiveBrief 2008

Ranking Risks: Rare to Certain, Negligible

to Catastrophic
Get the PDF Version

By ExecutiveBrief

Risks your project or business is exposed to may be worth reviewing now more
than ever to see which ones need more attention than others.
Risk is a concept that denotes a potential negative impact to an asset or some characteristic
of value that may arise from some present process or future event. In everyday usage, risk
is often used synonymously with the probability of a known loss. Risk is measured in terms
of impact and likelihood. Since risk is directly correlated to loss, it is important to be able to
assess risks in one's business and to address them. Needless to say, inattention to risks can
definitely affect a company's bottom line.
Some businesses actually go by without a formal risk assessment policy, nor is there a unit
that directly assesses the impact of risks in the organisation. We have been so accustomed
to risk in our everyday lives that the tendency is to ignore minor ones and react when major
ones occur. Moreover, effective risk management carries with it some costs, which, when
presented to stakeholders, naturally would lead to questions on how the costs could be
justified.
Risk management is a modern buzzword, but in no means a new science. More and more
businesses and organisations recognise the need to identify risks within them so that they
can be controlled and mitigated. It is important to exercise risk mitigation when it affects
people, the environment, and one's business, to name a few. Risk avoidance cannot make
the potential of even greater loss from happening go away.
The question is, as a manager, how would I know which particular sets of risks need a
special level of attention? Given limited resources, how would I know which particular types
of risks need to be prioritised and addressed?
A risk matrix is a risk assessment tool which exposes aspects of risks that could be
subjected to some form of ranking. The matrix has ranges of consequence and likelihood as
axes. A risk matrix shows the manager and the decision maker a clearer view of what the
risk is, what is involved (in terms of procedural changes, costs, behavioural adjustments,
and the like), and what amount of time can be afforded given the severity and probability of
the risk event. It can help a manager visualise, in an organised manner, the risks he or she
faces in quantitative and qualitative terms and plan and make a more informed decision
when the situation arises.
How does one construct an effective risk matrix?

1. Identify what the risk matrix is to be used for

Normally a risk matrix is called for during exercises involving hazard analyses, facility siting
studies, and safety audits. Depending on the intended use of the matrix, one may need to
establish tolerance or risk acceptability levels and a means of assessing the effectiveness of
risk mitigation measures.

2. Define consequence and likelihood ranges

A typical risk matrix is a four by four grid. On the Y (vertical) axis is the
"probability/likelihood" description range while on the X (horizontal) axis is the
"consequence" range
Figure 1: Sample Risk Matrix
Consequences of risks as laid down in the grid use descriptive words and are ranked
according to severity: Negligible, Marginal, Critical, and Catastrophic. Negligible risks are
the least severe and would be assigned the lowest rank. Inversely, catastrophic risks are
those that would be first in the severity ranking. Determine tolerance by assigning dollar
values to each severity ranking, as well as some qualitative characteristics of the
consequence being described. For example, Negligible Risks are those that involve USD
2,000 but less than USD 10,000 and could result in minor illness or injury to employees not
exceeding a day, does not violate laws, or has little or minimal environmental damage and
will be assigned Rank 1 in the matrix. Catastrophic Risks are those that involve USD 1M,
could result in death or permanent disability, result in irreversible environmental damage or
permanent closure to business, and will be assigned Rank 4 in the matrix.

Rank Range Amount of Loss Description of Loss

in USD

4 Catastrophi 1M or more • Results in death or permanent

c
disability of employees.

• Irreversible environmental damage.

• Closure to business.

3 Critical 200,000 but less • Results in partial permanent disability,

than 1M
injuries or illness of 3 employees or
more.

• Reversible environmental damage.

Rank Range Amount of Loss Description of Loss
in USD

• Violation of law/regulation.

2 Marginal 10,000 but less • Injury or illness of resulting in one or

than 200,000
more work days lost.

• Mitigable environmental damage

where restoration activities can be
done.

1 Negligible 2,000 but less than • Minor illness or injury to employees

10,000
resulting in one day's absence.

• Does not violate laws.

• Little or minimal environmental

damage.

Figure 2: Sample Consequence Ranking

The Probability axis describes the likelihood of the risk happening and can be assigned
either Frequent, Probable, Occasional, Remote, or Improbable, or simply Certain, Likely,
Possible, Unlikely, or Rare. Again, it would be helpful to state the likelihood criteria in
numeric terms (example, "Possible" means the risk will occur several times in a lifetime but
not less than 10 times nor over 100 times in that lifetime) and to assign logical rankings.

Rank Range Probability (over the life of Description

a business)

5 Certain Once in 2 years Continually experienced

4 Likely Once in 4 years Will occur frequently

3 Possible Once in 6 years Will occur several times

Rank Range Probability (over the life of Description
a business)

2 Unlikely Once in 12 years Unlikely, but can be

reasonably expected to occur

1 Once in 24 Unlikely to occur, but possible

years

Figure 3: Sample Probability Ranking

Once the criteria for consequence and likelihood has been laid down, proceed to determine
specific incidents, events or conditions that pose risk for the business and assign them along
the blocks in the matrix. Example of an incident in the office would be "burst pipes and
leaks" - this could be assigned in the block Rare (Rank 5 Likelihood) and Negligible (Rank 1
Consequence).

3. Translate the tolerability criteria into the matrix

The design of the matrix should be able to show clearly which of the blocks are intolerable
or tolerable. For example, a Possible (Rank 3 Likelihood) intersecting with a Catastrophic
(Rank 4 Consequence) would be intolerable for any business, given the description and
values you have previously assigned. This block is a clear subject of risk mitigation efforts in
the organisation compared to a block (risk) pertaining to a Negligible (Rank 1 Consequence)
intersecting with a Certain (Rank 2 Likelihood) which could be addressed, say, with a simple
change or adjustment in organisational policy.

Figure 4: Determining Tolerance Points in the Matrix

Care in assigning values

Risk matrices are fairly easy to construct and understand. However, one has to be careful in
assigning values, taking care not to be overly quantitative and not affording to include what
is called a "layer of protection" approach, a means of including protective measures, which,
when applied, brings down the risk a level lower. As in all planning and risk management
efforts, it is recommended that the risk planner or analyst, even the manager, exercise
conservatism in its design as well as point out areas of alarm. Decision makers are
recommended to use this tool in policy formulation and include budgetary allocations to
address not only persistent risks but also be ready for potentially catastrophic ones.
ExecutiveBrief, the technology management resource for business leaders, offers articles
loaded with proven tips, techniques, and action plans that companies can use to better
manage people, processes and tools - the keys to improving their business performance. To
learn more, please visit: http://www.executivebrief.com
© ExecutiveBrief 2008

The Top Five Software Project Risks

Get the PDF Version
By Mike Griffiths

I recently posted an entry on a risk assessment tool you can download and use. Risk
management (or more precisely risk avoidance) is a critical topic, but one that is often dull
to read about and therefore neglected. One of the few useful and entertaining books on the
subject is "Waltzing with Bears: Managing Risk on Software Projects" by Tom Demarco,
Timothy Lister, authors of the ever popular "Peopleware" . This post provides a useful
summary of their top 5 software project risks.
While not an agile focussed book, I find it interesting that of the top five software project
risks identified in Waltzing with Bears, all have suggested solutions rooted in agile methods.
Demarco and Lister rate the top five risks and their mitigation strategies as...

Risk 1: Inherent schedule flaws

Explanation: Software development, given the intangible nature and uniqueness of
software, is inherently difficult to estimate and schedule.
Waltzing...Solution: Get the team more involved in planning and estimating. Get early
feedback and address slips directly with stakeholders.
Agile Practice: On agile projects the team is heavily involved in planning and estimating
through activities such as XP's planning game and Wideband Delphi workshops. By working
in short increments the true velocity of the team quickly emerges and is visible to all
stakeholders who are now more closely involved in the project. In short, the true progress is
hard to hide and quickly revealed, giving feedback to the stakeholders.
Risk 2: Requirements Inflation
Explanation: As the project progresses more and more features that were not identified at
the beginning of the project emerge that threaten estimates and timelines.
Waltzing...Solution: Constant involvement of customers and developers.
Agile Practice: Agile projects plan in the regular trade-off discussions about features and
estimates at every iteration boundary. Changes and requirements inflation are accepted as
a fact of software projects. Rather than utilising change-suppression mechanisms,
prioritisation sessions are scheduled that allow worthwhile changes to proceed and initially
envisioned features to be superseded if the business gives their authorisation. It has never
been possible to squeeze a pint into a quart cup, but now at least we anticipate the likely
issue and have mechanisms in place to address the matter as part of the project from its
early stages.

Risk 3: Employee Turnover

Explanation: Key personnel leave the project taking critical information with them that
significantly delays or derails the project.
Waltzing...Solution: Increased collaboration and information sharing on the team.
Agile Practice: Agile projects practice information sharing techniques such as pair
programming, common code ownership, and frequent reporting at daily stand-ups
specifically to reduce the "bus-factor". When this "bus factor" (the impact to the project of a
key member being hit by a bus) is reduced multiple team members share key information
and the risk due to employee turnover is small. Also, often overlooked, is the fact that when
working in an engaging, rewarding, empowered, collaborative environment such as agile
projects, people are far less likely to want to move elsewhere so the risk is often avoided as
well as reduced.

Risk 4: Specification Breakdown

Explanation: When coding and integration begin it becomes apparent that the specification
is incomplete or contains conflicting requirements.
Waltzing...Solution: Use a dedicated Product Manager to make critical trade off decisions.
Agile Practice: Agile projects utilise the concept of an ambassador user, subject matter
expert, or customer proxy to play the product manager role. The idea is that someone (or
some group) need to be readily available to answer questions and make decisions on the
project. Traditional projects suffer specification breakdown when no one will own the role
and conflicting assumptions or decisions are made. Agile projects have some form of
product owner role central to their core team composition to ensure decisions are made in a
timely fashion.

Risk 5: Poor Productivity

Explanation: Given long project timelines, the sense of urgency to work in earnest is often
absent resulting to time lost in early project stages that can never be regained.
Waltzing...Solution: Short iterations, right people on team, coaching and team
development.
Agile Practice: Agile methods recognise Parkinson's Law and the Student Syndrome apply
to software projects. Parkinson's Law says that: "Work expands to fill the time available"
and Student Syndrome: "Given a deadline, people tend to wait until the deadline is nearly
here before starting work." By having short iterations, work is timeboxed into a manageable
iteration (typically 1-4 weeks) and there is always a sense of urgency. Agile methods do not
specifically address getting the right people on team, coaching and team development, but
these are core leadership roles applicable to both agile and traditional projects.

On Agile Solutions
It should really be no surprise that agile methods have techniques built right into them to
address each of the top software project risks. They were created out of the experience of
what worked well for practical software development. Given that these problems occur time
and time again on software projects it is natural that their solutions should become baked
into the DNA of agile methods.
So, while risk management is a dry and dull subject to many, Waltzing with Bears brings the
subject to life with valuable pointers for software project managers and is a recommended
read.
Mike Griffiths is an independent consultant specialising in effective project management.
Mike was involved in the creation of DSDM in 1994 and has been using agile methods
(Scrum, FDD, XP, DSDM) for the last 13 years. He serves on the board of the Agile Alliance
and the Agile Project Leadership Network (APLN). He maintains a leadership and agile
project management blog at http://www.LeadingAnswers.com

The Risky Business of Project Management

Get the PDF Version
By MA&A Group, Inc.

Undertaking any project, whether in-house or in partnership with a professional services

firm, entails risk. Project risk is defined as any area of concern that could prevent a project
from achieving all of its benefits. Project risk requires careful management and involves
identification, assessment, and mitigation.
It is important at the beginning of any project to go through the risk identification process.
Not all project risks are obvious. When identifying risks, look for areas in the project that
are based on:

1. Insufficient or unreliable data

2. Insufficient preparation

3. Inadequate resources

4. Lack of control

Some areas to pay close attention to are:

• Requirements identification

• Involvement of project sponsorship

• Level of project management experience

• Third-party involvement

• Political/cultural environment

• Change control procedures and management

• Complexity of the technology

Risk identification is only the first step. Risks need to be assessed to quantify and prioritise
them according to their impact on the project. Keep in mind significant professional
judgment is required during the assessment process to quantify the magnitude of potential
negative impact and to develop risk control measures. The assessment process should
determine the (1) likelihood of the risk occurring, (2) range of outcomes, (3) estimated
timing of the risk, and (4) the frequency with which it will occur. It should also determine
the warning signs of the risk that will forecast that the occurrence of the risk is imminent.
The prioritised risks provide the basis for establishing Project Success Factors (PSFs).
Specific action plans are developed to address each PSF. For example, assume that required
key policy changes are a high risk. An action plan must be developed to:

• Focus on thorough and frequent communications

• Implement a steering committee structure

• Obtain strong support for the project team from executive management

• Stress the benefits of the project

 • Identify training needs early

Once risks have been identified and assessed, mitigation plans should be developed. The
plans document what the response will be when a risk event occurs. Keep in mind a
mitigation plan might be to do nothing to mitigate the risk. The need is to accept that a risk
exists and be prepared to deal with the consequences when and if it happens. This type of
action plan typically applies to low priority/minimal project impact risks. A mitigation plan
should outline plan B for the project area impacted by the risk. Knowing what plan B is prior
to having to execute it will greatly reduce the probability of increasing the negative impact
of the risk event or causing other unknown risks to occur.
An effective risk project management process means choosing and implementing risk-
control strategies that work. Identifying, assessing, and developing mitigation plans are not
one-time events. These processes need to occur throughout the life of the project. As the
project progresses and project risk changes occur, documentation resulting from the
identification, assessment, and mitigation planning processes need to be updated. The risk
management process must be continuous.
Canadian Management Centre has earned the reputation as a trusted partner in worldwide
professional development, project management and management education.

Project Management: Stakeholder Risk

Management
Get the PDF Version
By Tris Brown

In this article we'll address the people swirling around your project: stakeholders. You'll find
some tips and other resources for optimising stakeholder involvement in your project.

• Who cares?

• What do they care about?

• What am I going to do about it?

Those are the three simple questions a project team can ask to understand their
stakeholders and develop a strategy for keeping them happy.
As we developed a workshop on stakeholder management built on those three questions
one of our project management experts, put all the pieces together when he said, "That's
just risk management for people."
We think he's right. Review this classic risk management process. Can you see the parallel?

1. Identify risks.

2. Analyse and quantify the risk.

3. Develop a risk response.

So on your next (or current) project consider treating your stakeholders as opportunities or
threats.

Step One: Identify Risks (Who cares?)

Just as with risk management, we can only manage stakeholders that we are aware of, so
be creative and energetic in identifying stakeholders. Cast your net wide and consider all
those stakeholders that won't make a peep unless you step on their toes. Regulators, end-
users, your customer's customers, and internal support staff such as accounting or
procurement. Too many project managers don't include these secondary stakeholders in
their normal communication plans yet get indignant when they obstruct the project. In risk
management we identify threats and opportunities. Stakeholders can be project adversaries
just as easily as advocates.
While you are trying to uncover the hidden stakeholders, don't forget about the obvious
ones: your team, your sponsor, and the people who will be approving the funding.
Tip: Make sure your stakeholders have a name and email id. Stakeholders are people, not
organisations. "Facilities" isn't going to sign off on your change request, but Cindy, who runs
the department, might.

Step Two: Analyse and Quantify the Risk (What do they care about?)
Risk management calls for prioritising the risks according to probability and impact. We can
prioritise stakeholders similarly - by authority and interest. Interest means "how much do
they care?" and authority equates to their ability to affect the project.
Now analyse the high priority stakeholders. You won't be able to quantify your stakeholders
as much as your project risks, but you can organise some key information: What do they
care about? How will the project affect them? How does this project fit into their priorities?
What do you need from them for the project to run smoothly?

Step Three: Develop a Risk Response (What are you going to do about
it?)
What we do to leverage our supporters and minimise the effect of our opponents will
depend upon the answers to the questions above. The more we know about our
stakeholders, the better we can plan to work with them. One thing is certain: ignoring them
will sap their support and inflame their opposition, so plan for communication.
Rapid changes in information technology continue to bring us new ways to flood our
stakeholders with data, but that doesn't necessarily make us effective communicators. Who
needs information? What information? How often? In what format? These questions form
the basis of your communication plan. As you develop your communication plan remember
these two tips:

1. Positive personal relationships are the foundation of effective communication.

Personal relationships magnify the value of the technology we use to deliver
information.

2. Use two or more mediums of communication for every stakeholder. For example,
meetings should be accompanied by documentation.

The Secret to Success

What's the secret to risk management? Do it. Proactive, systematic risk management
means finding the problems before they find you. Risk management doesn't have to be
complex, but it does have to be disciplined. The same holds true for our stakeholders.
Understanding who they are and what they want often isn't that difficult. The key is to be
proactive, to reach out, and influence them before they influence you.
Since 1995, LSA has helped organisations create and maintain distinct competitive
advantages through human capital. We work with leading organisations to drive success
through their people and the strategies, structures, systems, and processes that attract,
inspire, develop, and retain top talent. Know more about Project Planning and Project Risk
Management at www.LSAGlobal.com. . Copyright © 2008 Learning Alliance
Corporation DBA LSA Global. All Rights Reserved.

Risk Management Options

Get the PDF Version
By Paul Bower
Risk management as a shared or centralised activity must accomplish the following tasks:
identity concerns; identify risks & risk owners - evaluate the risks as to likelihood and
consequences; assess the options for accommodating the risks; prioritise the risk
management efforts; develop risk management plans; authorise the implementation of the
risk management plans; track the risk management efforts and manage accordingly. It is
possibilities that are being accommodated. It is management's job to do the planning that
will accommodate the possibilities. The customer is the final judge, but internal goals should
be to a higher level than customer expectations.
The key words in risk management are: proactive; management; accommodate;
acceptably; professional; possibility. The need for new risk assessment and management
techniques is required to continuously track down potential and critical risks, and to develop
strategies for handling these risks, for example: during product development. It is obvious
that without a strong risk management plan as part of the process, a company will waste
time, money, and resources, and will fail to manage their projects correctly.
Risk management is the sum of all proactive management directed activities within a
programme that are intended to acceptably accommodate the possibility of failures in the
elements of a programme. From an organisation's perspective a failure is anything
accomplished in less than a professional manner and/or with a less-than-adequate result.

Risk Management Options

Risk management options are usually cited as risk handling options subdivided as:
avoidance, control, assumption, risk transfer, and knowledge and research. Generally, the
assessment of management options is a hip shot since the necessary decisions must occur
early in a programme when things are still fuzzy. However, if experienced personnel are
given the facts, one can expect very good decisions since there is seldom any real mystery
about the practicality of options available. (The practicality of any option is usually just an
issue of schedule and funding.)
Avoidance: Use an alternate approach that does not have the risk. This mode is not always
an option. There are programmes that deliberately involve high risks in the expectation of
high gains. However, this is the most effective risk management technique if it can be
applied.
Control: Controlling risks involves the development of a risk reduction plan and then
tracking to the plan. The key aspect is the planning by experienced persons. The plan itself
may involve parallel development programmes, etc.
Assumption: Simply accepting the risk and proceeding. However, there can be a tendency
within organisations to gradually let the assumption of a risk take on the aura of a
controlled risk.
Risk Transfer: Means causing another party to accept the risk, typically by contract or by
hedging. Liability among construction or other contractors is often transferred this way.
Knowledge & Research: This mode is not "true" risk handling, but rather a technique for
strengthening other techniques. This approach can best be viewed as an adaptation of the
approach used by a student writing a thesis: intensive study with specialised testing - in
other words doing your homework.
Never expect initial risk management plans to be perfect. Practice, experience, and actual
loss results will dictate changes in the plan to allow different decisions to be made in dealing
with the risks being faced. In order for companies to succeed in the twenty-first century,
they need to excel in all aspects of their business, which includes risk management, so they
can fulfill their own and their customer's goals.

Conclusion
Risk management is an on-going process, and is a combination of proactive management
directed activities within a programme that are intended to accommodate the possibility of
failures.
Paul Bower wrote the article "Risk Management Options" and recommends you
visitwww.afaprojects.com/training_m_o_r.asp. for more information on MoR
management of risk training courses in London.

Your Risk Management Process: A Practical

and Effective Approach
Get the PDF Version
By Vicki Wrona, PMP

Some experts have said that a strong risk management process can decrease problems on a
project by as much as 80 or 90 percent. In combination with solid project management
practices, having a well-defined scope, incorporating input from the appropriate
stakeholders, following a good change management process, and keeping open the lines of
communication, a good risk management process is critical in cutting down on surprises, or
unexpected project risks. Such a process can also help with problem resolution when
changes occur, because now those changes are anticipated and actions have already been
reviewed and approved, avoiding knee jerk reactions.

Defining "Risk"
Before one can embark on a risk management process, one must have a solid
understanding of some key definitions. Project risks as defined from a PMI perspective are,
at their core, unknown events. These events can be positive or negative, so that the word
"risk" is inherently neutral. That said, most of the time and focus is spent handling negative
project risks, or "threats," rather than positive project risks, or "opportunities."
Often, companies that do perform a risk management process on a fairly typical multi-
month project (no longer than 12 months) will identify and manage possibly five to ten
easily recognised project risks. However, that number should in fact be much higher. With a
high number of project risks identified early on, a team's awareness of what to look for is
increased, so that potential problems are recognised earlier and opportunities are seen
more readily.
It may seem that project risks cannot be managed without taking away from the actual
work of the project. However, this can effectively be accomplished with a seven-step risk
management process that can be utilised and modified with each project.

The Risk Management Process

Step one of the risk management process is to have each person involved in the planning
process individually list at least ten potential risk items. Often with this step, team members
will assume that certain project risks are already known, and therefore do not need to be
listed. For example, scope creep is a typical problem on most projects. Yet it still must be
listed because even with the best practice management processes in place, it could still
occur and cause problems on a project over time. Therefore it should be addressed rather
than ignored.
Step two of the risk management process is to collect the lists of project risks and compile
them into a single list with the duplicates removed.
Step three of the risk management process is to assess the probability (or likelihood), the
impact (or consequence) and the detectability of each item on the master list. This can be
done by assigning each item on the list a numerical rating such as on a scale from 1 to 4 or
a subjective term such as high, medium, or low. Detectability is optional, but it can be
simple to assess - if a risk is harder to see, such as with scope creep, then it's a riskier
item. If it's easier to catch early, such as loss of management support or loss of a key
resource, then it's lower risk.
Step four of the risk management process is to break the planning team into sub-groups
and to give a portion of the master list to each sub-group. Each sub-group can then identify
the triggers (warning signs) for its assigned list of project risks. All triggers should be noted,
even minor ones. Normally there will be at least three triggers for each risk.
Step five of the risk management process is for those same sub-groups to identify possible
preventive actions for the threats and enhancement actions for the opportunities.
Step six of the risk management process is for the sub-groups to then create a contingency
plan for most but not all project risks - a plan that includes the actions one would take if a
trigger or a risk were to occur. This plan will be created for those risks scoring above a
certain cut-off point, which is determined after looking at the total scores for all risks. This
keeps the risk management process manageable. The risk management process is not
effective if it is so time-consuming that it is never done.
Step seven, the final step in planning the risk management process, is to determine the
owner of each risk on the list. The owner is the person who is responsible for watching out
for triggers and then for responding appropriately if the triggers do in fact occur by
implementing the pre-approved and now established contingency plan. Often, the owner of
the risk is the project manager, but it is always in the best interest of the project for all
team members to watch for triggers while working on the project.
Rather than start this risk management process from scratch for every new project, it can
be followed once to establish a list of generic project risks and triggers, skipping step three.
Then, a team simply has to add project-specific project risks and triggers and assess the
probability, impact, and detectability for each risk, saving a great amount of time and
helping to ingrain a risk mentality into your project culture.

Creating a Risk Register or Risk Matrix

Upon completion of the risk management process, a master document, known as a risk
register or risk matrix, is created. The most effective format for this document is a table,
because it will allow a great deal of information to be conveyed in a few pages. If the
information is instead presented in paragraph form, it may not be read by people and will
be rendered ineffective. The columns in the table can include risk description, probability,
impact, detectability, triggers, preventive actions, and contingency plan. Other columns,
such as quantitative value, can also be added as appropriate.

Important Things to Remember

Often, the steps in which triggers and preventive actions are identified are overlooked.
However, these are vital to the entire risk management process. After a team has
completed this exercise once, the members will be better conditioned on what to pay
attention to while managing the project so they are more proactive in catching changes or
issues early. If these steps in the risk management process are skipped, the team can find
themselves in constant reaction mode, simply implementing a contingency plan for each risk
after that risk catches them by surprise. They could also ignore a seemingly overwhelming
list of project risks, which is why narrowing the list down to the most important risks is
critical for making sure the list is used.
Once the risk register is complete, it is easy to maintain. It can be reviewed during regular
status meetings, with as little as 15 minutes spent making sure the list is still current.
Determine if any project risks can be closed (but not removed completely), if any risks have
increased or decreased in value, and if there are any new project risks to add. This will
ensure that the list is continually seen as relevant and useful throughout the life of the
project.

Conclusion
A risk management process does not have to be complicated or time consuming to be
effective. By following a simple, tested, and proven approach that involves seven steps
taken at the beginning of each project (fewer if a generic list of project risks has already
been established), the project team can prepare itself for whatever may occur. Of course
there will always be changes and there may still be surprises, but the end result is that they
are fewer, that the team feels prepared and that the project is not taken off course.
Vicki Wrona, PMP, is the president of Forward Momentum, LLC, an 8(a) consulting and
training company, and an instructor with Westlake Training and Development . She has
20 years of project management experience, has trained over 3,800 people, has mentored
individuals and organisations, and has authored multiple white papers. She is currently
serving on the PMI's committee to write the PMBOK Guide 4th edition in general and a
content reviewer specifically on the Communication and Procurement knowledge areas.

Project Risk Management: It's Either

Contingency Planning Now or Emergency
Relief Later
Get the PDF Version

By Chris Wright

Several years ago, I was concluding a project risk review meeting, and I received a text
page from my project's executive sponsor ("Jim") summoning me to his office. As soon as
the meeting concluded, I went to Jim's office where he launched into a lecture about the
need to cultivate a "positive environment" for the project team. After a few minutes of his
diatribe, I explained to Jim that I did not know what triggered this discussion. Jim then
explained the regular risk review sessions I was facilitating had created a "negative vibe"
throughout the project team, since we were focusing on reasons that the project could not
be done. He went on to request that we limit our discussions on project risks and focus on
the things we can control instead of those things we cannot. As a seasoned project
management professional, I was admittedly stunned that our project sponsor advised his
project manager to virtually eliminate our risk management efforts from the project!
I have learned in the years since that this scenario is not that uncommon in the project
management environment. The competitive market and stakeholder risk tolerance levels
exacerbate the myth that risk management initiatives are a waste of project resource time;
that time should be focused on the actual work of the project, not events that may or may
not occur. The fact is, however, that it is either contingency planning now or emergency
relief later for our projects.
The Common Constraints
In most cases, risk management initiatives either do not occur at all or are done as a mere
checklist formality early in the project. The three most common constraints with project risk
management are:

1. Risk management is applied inconsistently

Even when potential risk events are identified for a project, this process typically occurs
early in the project and is never revisited. As a result, the project team may not be
prepared to respond to new uncertainties and issues that have not been identified.

2. Risk management is not prioritised

The risk planning, analysis, and response planning efforts are rarely integrated into the
overall project plan. As a result, risk management is not a priority for the project team, and
adequate resources (budget and people) are not allocated to address issues caused by risk
events. This "we will deal with those events if and when they occur" mentality leaves little
or no room for error on the project.

3. Risk management earns limited buy-in and support

In many cases, project sponsors and senior management discount risk management efforts
for their projects because the benefits are unclear. Additionally, senior management,
hearing the phrase risk management, might say, "We have a group that handles our risk
management, so why do we need to have a separate effort on the project. Plus, we are not
reducing project costs or delivery time so why should we invest in risk management?"
As you have likely discovered, the challenges present in project risk management are just
another element to worry about as a project leader. There are three basic tenets you can
incorporate that can turn your risk management efforts into a consistent and proactive
process. They include:

Project Risk Management Tenet #1: Assess Early and Often

Project risk management must occur throughout the life cycle of the project. Uncertainties
can be discovered at any time, while the relative probability and consequence of identified
risks can change over time. For instance, the farther along a project goes into the schedule,
the more likely you will lose team members to other efforts. In addition, the impact of
poorly defined requirements will typically have a greater impact on project success in the
latter stages of the project. It is imperative that the project team address uncertainty early
and often, throughout the entire term of the project.

Project Risk Management Tenet #2: Build It into the Schedule

In order to adequately deal with uncertain events, the project schedule must include risk
management activities. The project manager must ensure that risk assessment
(identification and analysis) and response planning initiatives are a regular occurrence.
Depending on the size, scope, and complexity of the project, risk reviews can either be an
agenda item on the weekly review meeting or a bi-weekly review by itself. Either way, the
project manager must incorporate consistent risk management mechanisms into the project
schedule.

Project Risk Management Tenet #3: Communicate and Illustrate Ownership

The inherent uncertainty of risk events tends to make key stakeholders avoid the subject
altogether. Therefore, it is up to the project manager to employ effective communications
and clear ownership of risk elements. Potential risks need to be clearly identified and
assessed, and accompanied by targeted, yet realistic, response strategies. Simply put, risk
response strategies need to function as a rifle, not a shotgun. Also, the project leader must
ensure that team members are properly aligned as owners for specific risk events. When
key stakeholders know who to contact regarding a critical uncertainty, clear communication
is better facilitated.
Proper project risk management entails more than simply identification and analysis at the
beginning of a project. Risk management must be integrated into the project plan,
consistently applied, and clearly communicated throughout the life cycle of the project.
Copyright © 2007, Global Knowledge. All rights reserved. This article was originally
published in Global Knowledge's Management in Motion e-newsletter (now named Business
Brief). Global Knowledge (www.globalknowledge.com ) delivers comprehensive hands-on
project management, business process, and professional skills training. Visit our online
Knowledge Centre for free white papers, webinars, and more.