Managing Risk

 

Risk, in the land of project management, is anything that could potentially get in the way of your project going according to plan and being delivered on time.

There are two types of risk; those that you can do something about, and, yes you guessed it, those that you can’t.

Let me give you some examples from my world as a web project manager at Headscape. Let’s say we have been asked to deliver a project to facilitate a small, but growing, web presence. The client has existing content which needs to be edited and integrated as well as new content that will be supplied by them. The client uses a third party system; previously not used by us but similar to systems we have used before. This third party system needs to be updated by the application we develop.

This is a limited, but not uncommon, project request. So what are the  main  risks here?

  1. Content
    Content is always a risk. The single biggest reason why a project is delayed at Headscape is content. Clients never, ever, appreciate how long it will take them source, edit, and deliver content.
    This is a risk that is completely out of your control.
  2. Third party system
    Whenever a third party system is involved (especially one that hasn’t been used before),  no matter how similar it is to current systems, you have a risk. There will be a learning curve for your team, documentation will most likely be inadequate, and there is bound to be a new release half way through development that will break everything you have managed to get working.
    This risk you can do something about.

Risky Business

Having located the risks what can we do about them?

Highlight them with the client from the very start. If you make the issue of content clear from the beginning, for example, it might, if you are really lucky, mean that the client will take it on board and actually deliver what they need to on time. Failing that it makes it a lot easier for them to swallow if it does end up being the reason a project is delayed.

Talk about potential issues with their third party system. Do not be afraid to present these to the client. My experience has been that, in the main, they appreciate a transparent approach.  You can legitimately build in time to the project timeline to allow for the research and learning involved. Even so, there is always an element of the unknown here. If something is going to go wrong with this project, it will involve interfacing with this third party system.

Build in contingency to the budget and the time line. You can not remove the risks but you can plan for them.

It’s easy to fall into the trap hoping that all will go well and you will have project that follows all the best possible scenarios.  If you close your eyes, and wish really hard, then you can sell a shorter time line and it might just work out for you. However, if you plan for the risks and build in the required contingency, you might even deliver early.

Clients love to be surprised like that.

As PM’s at Headscape we have started to work together  to launch each new project with a project risk assessment. Highlighting all the things that could be a risk to the project running smoothly. Things that are both internal and external to our environment. Things that we can do something about and things that we can’t.

Being aware of these risks and planning for them has had a big impact on our ability successfully set client expectations and deliver projects on time, and on budget.

One thought on “Managing Risk

  1. Nice post Rob.

    Complete transparency is how I prefer to run things too. I always find that although it can be scary to be open and honest with a client in the beginning because you’re trying to build confidence, in the long run it always pays off and the client respects and loves it.

    If done correctly, there are rarely any twists and turns within a web project that is a complete suprise to either the Web PM or client. Blagging in the beginning always results in horrible shocks!

    You need to post more 😉

Comments are closed.