Project Risk Management Process

Project Risks tend to come to prominence either during project initiation with the writing of the Project Initiation Document, or if you're like most project manager's desperately trying to get the project moving, then after initiation.

This process is usually kicked off with a Project Risk Workshop but it really depends on the emphasis the Organisation you work for places on following a project management methodology. You would be surprised how many pay mere lip service to process. Needless to say, in my career of consulting at large blue chip Organisations I have only been involved in two Risk workshops in thirteen years! The remainder of the time I simply acertained and raised the risks myself. The reason for this was that the Organisations involved simply didn't care what risks were involved. They wanted the project delivered and no excuses would be tolerated why it couldn't be done.

However with the Credit Crunch and much tighter Human Resources legislation, you will be pleased to know that this type of approach is dying out, and more emphasis is being placed on properly quanitifying and managing project risk.

So back to the Project Risk Workshop, well this is usually conducted by either ITQA or Business Assurance. It involves all the workstream leads who will work on the project. Basically everyone sits in a room and is given a PC. After a brief introduction regarding the project, everyone is asked to type up the risks they perceive the project to have from their perspective and score them in terms of seriousness of them occurring and their potential impact on the project.

Now these risks should fall into one of the following categories which are:

1. Management - The risk that there won't be enough Sponsor or Stakeholder input to ensure business requirements are delivered.

2. Resources - The risk that there will not be enough resources available to deliver the project

3. Requirements - The risk that the requirements will not be either fully specified or not correctly understood

4. Technical - The risk that the proposed deliverables cannot actually be delivered, or else won't work utilising the technology used within the Organisation

5. Environment - The risk that something will change in the environment the project will utilise.

6. Acceptance - The risk that either the Project Sponsor / Client will want to change the scope of the deliverables, or else will not accept the defined deliverables once developed.

Once this is done, and usually 1 hour is allocated to the task, each Risk raised needs to discussed by the group. Usually because of time constraints only the most serious Risks are discussed. The general idea is to ensure no duplicate risks are raised and also to try to prune the list of risks down to something more manageable.

So after this session you should end up with a list of Risks which can be entered into the Project Risk Log to be managed and mitigated. This then becomes a key project document which will be referred to and updated as the project progresses.

Project Risk Management Process - Tip

The Project Risk Workshop is one which can be useful but often becomes nothing more than a bunfight between workstreams who are all trying to raise as many risks as possible to cover their own delivery. You need to find a way to stop this otherwise you will be managing the risks raised full-time to the detriment of the project delivery.

---