Professional-PM Project Management - Risk Management

How to Bubble Wrap Your Project: Risk Management By the Numbers

root — Tue, 30 May 2006 03:41:44 +0200

Just imagine that you've found a stunning piece of crystal that you want to ship to your mother. You don't just plop the thing into a box, slap a stamp on it and send it off, do you? Of course not! If you're smart about it, you wrap it in cotton wool, then wrap THAT in bubble wrap, then fill the box with crumpled paper and carefully nestle the bubble-wrapped, cushioned delicate piece inside. Why would you treat the project that you're building with any less care?

When Ken Salchow Jr., who designs network security for a F5 Networks, defines risk management with the following simple equation:


RISK MANAGEMENT = RISK ASSESSMENT + RISK MITIGATION

he hits the nail squarely on the head. Risk management really is as simple as identifying possible things that could go wrong on your project, planning how to avoid them and how to deal with them – and then acting on your plan. Simple, right?

Okay, easier said than done. While every project is different and requires customization, there are a set of standard practices that you can follow to help you design and implement a risk management plan for your project.

Step 1: Do a risk analysis at the start of your project.

Before you can set about planning how to deal with risks, you have to know what they are and how they will affect your project. Your risk analysis needs three parts to be effective:

Identify all possible threats to your project, from a security leak to illness on your management team to a lightning strike that burns the building down.

Assess the vulnerabilities – where are the holes that will let those threats affect you?

Analyze the effects of each threat on your project or company. What’s the worst that could happen if the worst happens?

Step 2: Design a mitigation plan.

Once you know what dangers you face, you can start to plan how to mitigate the risks.

Mitigation consists of two parts:

Avoiding the Risk by plugging up those holes you found in your risk analysis
Lessening the Impact by planning how to deal with the effects.

Suppose your risk analysis identified the loss of a senior member of the project team as a threat that could derail your project. Your risk management plan might include:

Regular updates and collaboration notes to ensure that a new person could step in and pick up the work
An insurance policy to provide funds for a quick replacement
Tagging a backup team member to work closely with each senior project member so that they can carry on in his absence

That’s the essence of risk management in a nutshell. Everyone wants to be positive when they’re starting off on a new project – but by imagining the worst case scenario and planning how to deal with it in advance, you can bubble wrap your work and protect it from the bumps and bangs along the way.

Key Elements of a Successful Project

root — Thu, 28 Apr 2005 13:23:26 +0200

Matthew at Ganthead just released their second part of the article Ingredients for a Successful Project (part2 ) which urges me to comment some of the statements in the article (you need a free registration to read them...)

Split Scope

Developing a new application may cause the need for new infrastructure, hardware, software, etc. If possible (and I highly recommend doing so), split a project into two separate projects. While the new infrastructure is being decided upon, installed and tested, separate projects can handle the development of the application, which also has its own set of design, coding and testing.

No TPM should have the burden of managing these as one project--especially when it's never been proven in the organization. However, it's probably smart to have the same TPM manage both projects, although it is not necessary.

Well - as long as both projects do not relate to each other, or the application development can happen much later, I am fine with this. Don't get this wrong and start developing the customer's needs on an application framework that is old or just crap.

If you need new infrastructure in your project, you need to build that new infrastructure - and wait for it to complete You would have a hard time explaining your clients that the application is 90% done, while you just have to migrate everything to the cool new infrastructure you just built "by-the-way" .. don't you think? Also for your team it would be mega-frustrating to adapt their code to the new infrastructure... and don't get me wrong: this has nothing to do with "refactoring" ... refactoring refers to improving YOUR own code (hence a mental code cleanup as well...) - moving to a new infrastructure is the opposite - changing your code to RUN ANYHOW again with those new libs that the lab spit out after a few months of "creating a perfect world"

Pick Your Team

I know in a perfect world this would be possible. However, there are those projects that require key resources and it's okay to be selective in forming your team.

NO - be as picky as possible - every team member IS a KEY RESOURCE every team member you take "because it could fit will cost you 20-30% team performance for the whole remaining team to bring him where you thought he should be... if you are to select new team members every hour NOT SPENT WISELY in selection process will cost you a BIG multiple in development / testing / rollout costs for re-writing or fixing of a bad developer's results or even architects design... with that kind of effort you are better to do it yourself.

Manage Risks

It's a good practice to manage the risks before they turn into full-blown issues. However, no matter how well you mitigate a risk, issues will arise. In this case, tackle all issues first. Make sure those involved in the issue are aware of the impact and consequences, then decide who the action agent will be for resolving the issue. And put a timeframe on the issue so as not to have the issue extended and prevent a future risk of creating a non-manageable issue.

Yes - manage risks. If you know nothing about risk management, then start reading

Set the timeframe for your own re-check. If you don't manage the risks who would? ( unless you assign a specific risk manager to get you out of your optimistic PM views ... )

Waltzing With Risk

root — Sun, 07 Sep 2003 14:04:05 +0200

If you may select your next project, which would you take? The one with the most risk and most outcome ? If yes, you might be a winner like Fidelity or Schwab that chose to enter the online-broker market in the early 90ies. If not, you might be in fear like Merril Lynch that feared things like Perl, Java, CGI, serverside logic, HTML and other "silver-bullets" of the early 90ies... and keep your growth stale at +/- 0%. On the other hand - a lot of companies that chose the risky way to not exists anymore...

This is the latest incredible book by Tom De Marco and Tim Lister that was on my Amazon wishlist for almost 5 months now until Chris reminded me with a recommendation about it. Now having finished it I can just agree with Edward Yourdon (Creator of the incredible ) that this will become the bible for IT Project Managers.

It not only adresses the "Reason why" to cope with risk management in your projects, but for instance the anti-thesis, the "Reason why not" (if you live in a culture of fear for instance...).

Tom DeMarco and Timothy Lister provide an enjoyable to read, with great examples and their typical, somewhat sarcastic, view on the general issue of project management and the fact that a project - whatever risks it might impose - typically extends the first and most optimistic schedule by 150 to 200 % (that is 3-4 times more!).

Managing risks does not mean to manage the resulting problems or catastrophes alone, but simply the probabilities of these with adequate safety buffers and alternative strategies.

The visualization of a risk - a "we could maybe not make it"-issue is the first and probably most important step they motivate you to. Many organziations simply obey the "can do"-super-hero approach (I would call it CMM level zero) where not the infantile project plans and the resulting schedule and effort slips and therefore money and people loss are sanctioned, but the "questionable" behaviour to ask for possible bad outcomes and problems during the project path to take care of. (the organizations where there is always another dude with a "Hey Boss, I will deliver in your {impossible} schedule 100 pro, let me do it!")

From the practical viewpoint they even provide an easy to understand arithmetic approach to probabilty calculations aswell as some tools (Excel based) you can download from their web-page. Not the most important issue in my opinion but nice for the more detailled analysis. I will take a look at that later.

You can even get some sample chapters of Waltzing With Bears: Managing Risk on Software Projects at their website.

This is a must-read for every project manager, developer, customer and CEO.

You can also download from the October issue of IEEE Software, Lister and DeMarco's article on Risk Management during Requirements

I am currently reading the german edition.