There is very often more than one organization involved in a project. Maintaining an up to date project risk register across several organizations may be complicated, especially if you are using a spreadsheet to track risks and mitigations.

A better approach is for you to use a dedicated risk management software tool like MediumRisk for easy sharing of the risk register between multiple organizations.

Risk management

A risk management process involves identifying, analyzing and assessing risks. At the stage when you have completed the risk assessment, you are position to decide how to deal with identified risks.

This post goes through the five options for dealing with identified project risks.

Risk management

It is easy to get excited about the process of identifying risks. Because, in risk identification you can let your imagination run wild, in the attempt to identify what and why things may go wrong in your project.

Sometimes, however, you may come up with intricate risk scenarios that are quite unlikely or can have only insignificant impact on your project. When this happens, you need to be able filter out the imagined threats, and instead focus on the real risks.

When people say that a project has "failed" it is not always clear what they actually mean, and what factors went into their assessment. Is it helpful to apply categorical terms like "success" and "failure" when discussing IT projects, or any project in general?

It is well-known that many projects don’t meet their scheduled delivery date and/or cost a lot more than originally estimated. So, if you assess a late software project the day after the scheduled delivery, it has indeed "failed" with regard to this single measure.

Anybody sponsoring a software project needs to have an idea of what kind of return they're going to get on their investment, so that they can evaluate whether or not the investment is worth making.

If you want the project, you have to provide the client a positive answer to the basic question: Can you do this project within a time frame and budget that makes it possible for the client to realize an appropriate return on their investment?

Almost all IT projects end up behind schedule. So, there is really nothing special about your project being delayed. Delivering on time should not be your most important success criteria, anyway. Falling behind is okay, and it happens to everyone — repeatedly. Remind yourself that things are very seldom as bad as they could be.

Now that you have been comforted, let's take a look at some action steps to help you deal with the situation.