When performing the Risk Identification stage of the Risk Management Process, you will want to identify as many risks as possible. This project risk identification process typically takes inputs from the project or program steering group as well as all the different projects reporting to the program.
If you’re at the start of your project or program, holding a workshop to brainstorm risks is a great way to get the initial list of risks together before you being your project risk analysis. Do this as a team project to get everyone involved. The sooner you’ve identified the project risks facing the project or program the sooner you can start to do something about them. Using a checklist in the workshop can be a handy way to ensure you and your team are considering all the typical sources of risk. Below is the checklist which I like to use to identify risks to go on the project risk resister:
- What is the risk to the organization if the program or project fails (or even succeeds)?
- Does the organization have the capability to undertake the program or project?
- What has gone wrong in past programs? Here you should be looking at both project risk registers and lessons learned from previous projects and trying to pre-empt the same mistakes being made. From my experience I’ve seen that organizations makes the same mistakes over and over again.
- Will other initiatives (projects or programs) being undertaken within the organization impact your program negatively?
- Have all the sponsors reached a genuine consensus on the objectives for the program?
- Can the benefits of the program be defined objectively so that it is possible to measure success?
- Have the key stakeholders been involved in defining and planning the program?
- Are approval and sign-off procedures already understood?
- Are the interdependencies between different projects clearly defined?
- Is risk management a part of all sub-projects, and do you have visibility to the risks facing each project?
- Has enough time been allowed to arrange use of external resource?
- Is solid management in place for the management of 3rd parties?
- Are there any risks associated with 3rd parties? This is especially important if the relationships are not win-win in nature
- This might seem obvious, but are the expectations of senior management at the outset realistic?
- Has consideration been given to performing proper piloting of both operations (internal tools and processes) and of any product developed?
- Don’t forget to consider the End Game. By End Game I mean those things which typically happen at the end of a project causing it to delay, such as user testing, performance testing, end-to-end testing, and late stage integration.
- Are there any major open legal issues which should be considered, for example, possible patent infringement.
- Do you have any resourcing issues (wrong resource, project team working relationship issues)?
- Is program and project governance in place and has it been used before?
- Is any technology being used new, rather than tried and tested?
- Are there any big decisions still waiting to be made? This could include technology, business case, and which resources will carry out the work etc.
This is the list I use at the start of the program to get the initial list of project risks together as input to project risk analysis. It serves as a handy way to kick start reducing project risk. If you can think of any others then email me at firstname.lastname@example.org. I’d be really interested to receive some more questions to add to this list which is really a best practice for successful project management.
I recommend you amend the checklist to create your own. The projects and programs you manage in your organization will have their own particular types of risks, so as you move from project to project your risk checklist will grow, and you will be able to identify the majority of project risks being faced more quickly at the start of the project.
Charting Total Program Risk
Visualize Risks Using a Risk Map