Project Risks 1/2

Project Risks are a key part of any project. Of course their importance depends on the perceived riskiness of the project. yes all projects have risk but believe you me, there are projects which are so risky only the insane project manager would take them on and actually get them delivered. Sad to say, I admit I do actually fall into this category!

Before one can embark on a project risk management process, one should have a solid understanding of some key definitions. Project risks as defined from a PMI perspective are, at their core, unknown or unexpected 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 not surprisingly spent handling negative project risks, or "threats," rather than positive project risks, or "opportunities."

To put this simply project risks are those which can de-rail the project or even cause it to fail should they materialise. Now documenting these and then managing project risk is absolutely vital to successful project management. But you need to be careful not to be distracted by "noise", also known as irrelevant risks. You need to focus instead on the key risks and actively monitor them.

What do I mean by this? Well from my experience of managing IT projects I can tell you there are a large number of "standard" risks which workstreams like to raise. Now these aren't specific to the project delivery you are managing, they are instead what I would call "excuses" for why the project can't be delivered.

An example of this would be:

"There is a risk that not enough time will be assigned to thoroughly test the software with the result that it will not be of sufficient quality to be able to launch within the timeframes desired."

or

"There is a risk that changes to requirements will be insisted upon by the Project Sponsors with the result that the development and test teams will be unable to deliver the products required to meet project timeframes."

Now I have seen teams trying to raise various flavours of these risks in virtually every project I've managed. But can you see why they are really project risks? I certainly can't which is why I always refuse to raise these. After all test teams will always moan that they need more time to ensure a quality product is delivered. The problem is that if you give them more time they still won't deliver what is required. Therefore I instead turn the tables and essentially force them to find a way to get the work done in the time stated insteading of wasting effort in raising risks why they can't deliver!

And with the other risk, well you as the Project Manager need to implement project management scope as well as managing and controling scope creep. Certainly this should not be raised as a risk, unless you want your team to draw attention to the fact that you may not be able to properly manage the project scope .

Of course there are numerous key risks which you must raise and manage in order to have a good chance of delivering successfully. Click here to read more about these key important Project Risks which you must raise.

Project Risks 1/2 - Tip

Do not allow your workstreams to raise risks which have no relevance to the specific project you are delivering. If you do, all that will happen is you give them a good excuse not to deliver, and in the meantime you have to waste your time managing and updating the non risks they have raised.

---