Three Risk Management Best Practices That Will Save Your Project

As promised in my last post, here are three very valuable Risk Management best practices that you should  apply on your project (and you should always carry out risk management on every project, whether big or small).






1.  Remove the most likely risks from your project.

If you estimate the probability of the risk occurring is 50% (0.5) or above, treat the risk as an event, not a risk.  You are predicting that the risk is more likely to happen than not, so why not build your plan and project activities assuming it is definitely going to happen.  By removing these potential risks from your project, you are automatically avoiding many potential issues and dealing with them in a more controlled and less costly way.  Think about the effort that is needed to save the Titanic before (compared to after) it hits the iceberg.

2.  Establish a Project Contingency reserve

Add up the Expected Monetary Value (EMV) for your top five to ten risks - this amount will typically be about 10 to 15% of your project budget and should be obtained as an additional "Project Contingency reserve".  You should use your list of top risks and expected impacts as justification to your management and client for the additional budget needed to establish this project reserve.  If the total EMV for your top risks is greater than say 15%, even after you have eliminated the risks with probability of occurrence greater than 50%, than you still have too many risks and should also treat some of them as events and eliminate those from your project risks.

3.  If you cannot get approval for a Project Contingency reserve, carve it out anyway!

Set aside 15% of your budget as a Project Contingency reserve and reduce the budget for all project activities accordingly.  In most cases, with the buffers already built in to most estimates, your project team will be able to complete their activities with 85% of their original estimate.  For the few cases where they cannot, as well as for all the threats that do occur, you now have a reserve to draw upon.  Without any project contingency reserve at all, your project is destined to go over budget.

Let us know your experiences with these and any other risk management best practices that you have applied on your projects.

Webinar:  Risk Management Made Easy
If you are interested in learning more about Risk Management processes and best practices, and also  would like an Excel based Risk Register that you may use for all four stages of Risk Management, sign up for the recorded webinar APM05 "Risk Management Made Easy" at www.alphapm.com/webinars.

Don't Let The Icebergs Sink Your Project

  On April 10, 1912 the Titanic left Southampton on its maiden voyage to New York.  In spite of many warnings of icebergs ahead, Captain Edward John Smith kept full speed ahead.  He had a schedule to meet and the ship, after all, was unsinkable.  Of course, we all know the rest of this tragic story.

In my webinar on Risk Management I take a poll on whether people are doing Risk Management on their projects and find a surprising result.

Risk Management processes are only being consistently applied to projects about half the time..  How can this be?

I believe this is likely due to a combination of these factors:
-  Risk Management processes are considered to be "bureaucratic", with more effort needed to carry them out than any benefit to be gained
-  It is seen as too difficult to accurately identify project risks, their probability of occurrence or expected impact
-  A Project Manager has no time at the beginning of a project to worry about future imaginary risks when there are real problems and issues to tackle.

  If you are one of those who do not always apply Risk Management to your project, let me walk you through the steps in all four Risk Management stages and show you how easily you can apply them to your next project, big or small.

Addressing risks before they occur is always going to be easier and less costly than waiting for them to happen first before addressing them.


Risk Identification


-  Identify project risks in Risk Workout sessions with your project team, client and other key project stakeholders.
-  Use a Risk Checklist or Risk Breakdown Structure to ensure you cover all the key areas of potential risk on your project.
-  Don't forget to identify Opportunities (risks with a positive impact) as well as Threats (risks with a negative impact).
-  Use a simple Register to identify and easily manage and track your project risks through all four Risk Management stages.

Risk Analysis


-  Estimate the Probability of Occurrence for each risk.

An easy way to do this is to decide:
-  if the risk is not too likely to happen, use 0.3
-  if the risk is quite likely to happen, use 0.8
-  if you think it is somewhere in between, use 0.5 for the probability.

-  Estimate the Expected Impact for each risk; i.e. how much is it going to cost to address this risk if it were to occur.  This can be difficult to assess with any accuracy, so don't get hung up here.  Use your team, client and subject matter experts to come up with an order of magnitude estimate (e.g.  is it $500 impact, $5000 impact, $50,000 impact etc).  It is far better to come up with rough estimates like this then to do no risk management at all, and essentially be saying that all potential risks will have zero impact and zero probability of occurring.

-  The next step in the Risk Analysis stage is the easy part - calculate the Expected Monetary Value for each risk, using the formula:
Expected Monetary Value (EMV) = Probability of Occurrence x Expected Impact.

-  Now sort all risks by the size of their Expected Monetary Value, keeping the Top 5 to 10 or so for your further action and delegating the rest for review and action by the appropriate project team members and stakeholders. You can vary the number that you are going to track, but don't try and track all the risks that are identified, or you will sink in the quagmire.  The Pareto Principle will usually apply here - about 20% of the risks you identify will cause 80% of the expected $$ impact, so just focus on this top 20%.

If you use a spreadsheet for your Risk Register, the EMV can be automatically calculated and your risks can be readily sorted by EMV size.

Risk Response Planning

-  Now determine with your team a suitable response for each of your top risks.

For threats, use any of the following strategies to address each risk (and use several, if appropriate):
-  Avoid (take a different path, like the captain of the Titanic should have done)
-  Transfer (e.g by insurance, or outsourcing)
-  Mitigate (any solution that will lessen the probability and/or impact of the threat)
-  Accept (normally not a good choice, unless the expected impact is small)

For opportunities, the strategies should increase the probability of occurrence and expected benefit, so would include, for example:
-  Develop
-  Exploit
-  Grow
-  Support

Make sure each of the selected strategies and actions have a person assigned to action them, with target dates for check-pointing progress or completion.

Risk Monitoring and Control

- On a regular basis, review your project Risk Register to update the status of all identified risks, remove any that are no longer applicable and add any new risks.  This review can be incorporated into your weekly team meeting, or the action items can be transferred to your Project Schedule or Project Issues Log, depending on the nature of the planned actions.
- Major risks and related action items should also be tracked and reported on your Status Reports, Project Dashboard and at your Project Executive Steering Committee, to ensure they get the attention and support needed for their successful resolution.

In my next post, I will provide you with three very valuable Risk Management best practices, that together with the above Risk Management processes, will help you to successfully avoid those icebergs. 

Webinar:  Risk Management Made Easy
If you are interested in learning more about Risk Management processes and best practices, and also  would like an Excel based Risk Register that you may use for all four stages of Risk Management, sign up for the recorded webinar APM05 "Risk Management Made Easy" at www.alphapm.com/webinars.

There Is No Such Thing As Scope Creep

A question I get asked quite often in my project management training classes and webinars is "How should you deal with scope creep".

I have a very simple answer.  "There is no such thing as scope creep.  Don't talk about it, don't write about it, don't even think about it".

What you need to talk about is scope change, and as Shrek said to Donkey in the movie Shrek 2, "Change is good".

Now this does not make sense to many project managers.  How can scope change be good?  Does this not mean that your client is trying to get some changes made to the project, without paying for them or allowing the schedule to be extended.

No it does not.  We tend to assume that is the case. Some clients may even tell us "we have no more money for this project, so just do it".

My advice is, just treat this as good input and reply,  "I understand - let us go back and examine the changes you have requested and we will let you know their impact and how we can accommodate them".

Before we go any further, let's explore why scope change is good and something to be embraced, rather than resisted. 

Scope change can be needed by your Client for a variety of reasons, such as:
-  It was missed during the Scope Definition stage
-  It is needed because of a change in business direction
-  Some project stakeholders were not involved in the scope definition and are now demanding the change.

Whatever the reason, the project is going to be much better off with the change, so we need to find a way of implementing it in a "win-win" way.

Some of the ways you can accommodate a requested change include:
-  The change is minor and can be implemented with no or minimal cost
-  The change can be easily implemented as an enhancement, or in a future phase of the project
-  The change does have a cost and impact if implemented immediately and this cost and impact should be determined.

But if the client has no more money for the project and the changes do have a significant cost, now what?

Here's a true story.  I was overseeing an important project for our company, when the project manager came to me and said "The client wants some changes".  I replied "You know our process - fill out the change request with the cost and get him to approve it".

He came back and said the client said he has no more money for the project, but needs the change.  This was an important project for us to be successful on, and even though it was fixed price, I decided we would absorb the change.  A few weeks later, the project manager came back and told me the client wants some more changes.  Again I told him to fill out the change request and submit it to the client.  This time I received an irate call from the client asking me to fire the project manager.  "He keeps coming to me asking for more money and I keep telling him we have no more money".  I said, "Don't blame the project manager.  I asked him to give you the change requests".

We went back and looked into what we could do and came up with the approach that maybe the client would accept not doing some other functions that we felt were not as beneficial, in exchange for doing the requested changes. When we submitted our proposal to the client, to our surprise he accepted it without hesitation.

So don't forget, trading scope can be a great way to accommodate scope changes without incurring additional cost.  The client benefits with the changes, and the project benefits from keeping on schedule and within budget.  Talk about "win-win".

Are We Having Fun Yet?

Somewhere between that magic time when we are very young, to becoming an adult, we seem to lose the ability to have fun.

When we are young, we take delight in the world around us.  As we get  older, we start to see problems instead of opportunities, work instead of play, limitations instead of freedom.  The list goes on, but I am sure you get the idea.

Is this a problem, or is it just reality?  I vote that it is a problem, because in the process, we start to lose creativity.  As my son so nicely points out on his own blog, we are taught to color within the lines, because it is "wrong" to do otherwise.  We ensure (at least most of the time) that we follow the rules of others, instead of our own rules.

Perhaps worst of all, we start to accept things as they are instead of as we would like them to be.

What has all this got to do with project management?   In my last post, I talked about the "one most important thing", the importance of focus on and commitment to project goals.   As Steve Jobs was fond of saying (just before he announced yet another amazing product from Apple) there is "one more thing" that we should embrace for our projects to be successful, and that is the importance of "having fun" on our project.

If you are lucky, having fun is part of the culture of your organization.  We can debate at some other time whether the reported Apple culture of secrecy and paranoia bred by Steve Jobs is something to be emulated, since it has somehow produced such stellar results to date for Apple.

But I think it is true to say that for most people and for most organizations, the ability to have fun and enjoy what you do is a better ingredient for success than living in fear of your boss, or working in an atmosphere of paranoia and secrecy  When you and your project team are having fun, there is likely to be more creativity, more trust and more productive team work then when there is fear, distrust and conflict within the team.  If your team is having fun, then your project is more likely to be successful.

So how do you make sure that you and your project team are having fun.  Is it just a matter of having more pizza Fridays, a casual dress policy and team picnics?  These may certainly help, but we need to go much deeper than this.

Ask your project team what is needed for them to have fun on your project, and I don't believe you will find that Pizza Fridays is high on their list.  You will more likely find that improving communications, better team work, and helping them achieve their personal goals and develop their technical and managerial skills will rank much higher.

As a result of making your project a fun place to work, you will also be making it more productive and successful as well.  And as Martha might say, that can only be a good thing.

Your assignment:  Do a short "Are We Having Fun" plus/delta session with your project team at your next team meeting, and please share the results with us.

• Plus:    What are the things that make our project fun to work on?
• Delta:  What are the things we (as a project team, and I the Project Manager) need to do to make it more fun to work on our project?

The One Most Important Thing

I always start to laugh when I see questions like “What is the one most important thing that a project manager should do to be successful?” posted on sites such as LinkedIn. 

There are hundreds of things that a project manager needs to do on a project, and all can be very important at a particular point in time, depending on the project size, complexity and phase.  So trying to pin down one as the most important thing is surely futile.

However, upon further reflection, I think there is indeed “one most important thing” that a project manager should do, for all projects and at all times, and that is to maintain a strong passion for, focus on and commitment to project goals.

All goals should be SMART (Specific, Measurable, Achievable, Relevant and Time-based). 

 

Perhaps the best and most concise example ever of a SMART goal, was the goal set by President Kennedy on May 25, 1961:
“I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth”.

In spite of the many financial, logistical and technological obstacles encountered, this most ambitious goal was spectacularly and completely achieved with the Apollo 11 mission landing on the moon on July 20 followed by the safe  splashdown of the astronauts on July 24, 1969.

A SMART project goal could be:
“The goal of our (name project) is to deliver the committed functionality by (cutover date) within budget ($$$), so that we may meet (specify the key project objectives) to the complete satisfaction of all our stakeholders.”

Now here’s the scary part. According to studies by The Standish Group, only about one third of all projects are completed successfully.  This tells me that in spite of the generally high levels of expertise, methodologies, tools and technologies applied to projects, we still have a long way to go before we can consistently meet what should be readily  attainable project goals - goals which are usually set by us in the first place.

On any project of significant size today, there are many financial, technological and other obstacles and challenges that impede or prevent project goals from being achieved.  Without a high level of passion, motivation and commitment to project goals by the project manager, it is highly improbable that the project will succeed, no matter what resources, methodologies, tools and techniques are brought to bear on the project. 

 

The project managers who are most likely to achieve the project goals are those who ensure the goals are highly visible in every facet of their project, are passionate and excited about the goals and are highly committed and motivated to achieve them.

Your thoughts?

Does The World Really Need Another Blog?

With over 156 million blogs already in existence throughout the world, is there really a need for another blog?

It has often been suggested to me that I write a book on project management, but I have come to the conclusion that a blog will be more timely and practical (and definitely more fun) and can provide a free, collaborative and interactive resource and environment to facilitate your project success.


I have enjoyed sharing my project and executive management experiences with the thousands of you who have attended my project management training classes and webinars over the past twelve years, but I have lots more to share, particularly in areas not covered by these sessions, such as leadership, team development and other soft skills, global project management, managing multiple projects and many, many others.

Equally important, through my interactions with you in our training and webinar sessions, I know you also have great project management knowledge, insights and experiences.  I would like you to share these, either through this blog, or by co-hosting with me to deliver webinars on any topics of your choosing.

I do believe that the world could use another blog, and I will work hard to ensure this blog will live up to its objective "Facilitating Project Success Through A World Of Experience" (referring, of course, to the collective experience of our global blog community). 

This blog will only succeed in its objective with your active participation, so please tell us your project management challenges, issues and experiences, and let's start sharing the project management best practices, insights, solutions, methodologies, tools and techniques to help you all succeed on your projects.