One of the current difficulties faced by a new
Project Manager today is not having a sample or general risk list to refer to when identifying the project risk.
This article provides a sample and general project list that a new project manager can refer to at the beginning of their project to identify potential risks within their project.
Project Risk Identification
Project Risk Management includes the processes of conducting risk management planning, identification, analysis, response planning, and controlling risk on a project. The objectives of project risk management are to increase the likelihood and impact of positive events, and decrease the likelihood and impact of negative events in the project.[PMBOK]
Project Risk identification is the most important process in the Risk Management Planning. Risk Identification determines which risks might affect the project and documents their characteristics. However, as recommended by [Donna Ritter], we should not spend too much time in identifying risks. After the list is made, qualitative and quantitative analysis is done to figure out which risks you spend time and/or money on.
As stated in [PMBOK], there are some specific tools and techniques for identifying risk as listed below:
- Documentation Reviews
- Information Gathering Techniques - Brainstorming, Delphi Technique, Interviewing, Root cause analysis
- Checklist analysis - previous similar project, lowest level RBS
- Assumption analysis
- Diagramming Techniques - cause and effect diagram, system and process flow chart, influence diagrams
- SWOT Analysis
- Expert Judgment
The risk identification method suggested in this article is to compliment the existing tools and techniques recommended by PMBOK.
The common Project Risk List Reference below which are divided into a number of risk categories are samples of potential risks of a project may be exposed to and should only be used by the Project Team as a reference and starting point for risk identification during the project risk management planning.
Risk Category : Schedule
- Schedule not realistic, only "best case".
- Important task missing from the schedule.
- A delay in one task causes cascading delays in dependent tasks.
- Unfamiliar areas of the product take more time than expected to design and implement
Risk Category : Requirement Risk
- Requirements have been base lined but continue to change.
- Requirements are poorly defined, and further definition expands the scope of the project.
- Specified areas of the product are more time-consuming than expected.
- Requirements are only partly known at project start.
- The total features requested may be beyond what the development team can deliver in the time available.
Risk Category : Project Management Risk
- PM has little authority in the organization structure and little personal power to influence decision-making and resources.
- Priorities change on existing program.
- Project key success criteria not clearly defined to verify the successful completion of each project phase.
- Projects within the program often need the same resources at the same time.
- Date is being totally driven by need to meet marketing demo, trade show, or other mandate; little consideration of project team estimates.
Risk Category : Product/Technology Risk
- Development of the wrong user interface results in redesign and implementation.
- Development of extra software functions that are not required (gold plating) extends the schedule.
- Requirements for interfacing with other systems are not under the team’s scope.
- Dependency on a technology that is still under development lengthens the schedule.
- Selected technology is a poor match to the problem or customer.
Risk Category : Customer Risk
- Customer insists on new requirements.
- Customer review/decision cycles for plans, prototypes, and specifications are slower than expected.
- Customer insists on technical decisions that lengthen the schedule.
- Customer will not accept the software as delivered even though it meets all specifications.
- Customer has expectations for development speed that developers cannot meet.
Risk Category : Human Resources & Contractors Risk
- Critical development work is being performed by one developer.
- Some developers may leave the project before it is finished.
- Hiring process takes longer than expected.
- Personnel need extra time to learn unfamiliar software tools, hardware and programming language.
- Contract personnel leave before project is complete.
- Conflicts among team members result in poor communication, poor designs, interface errors and extra rework.
- Personnel with critical skills needed for the project cannot be found.
- Contractor does not deliver components when promised.
Risk Identification in the project is critical in order to manage and complete the project successfully. The earlier the risk can be identified, the earlier the plan can be made to mitigate the effects of the potential risks. There are a lot of tools and techniques or method available to identify the project risks. The method suggested in this article will complement the existing risk identification method to get a more comprehensive risk list for Risk Management Planning. Identifying the risk is an iterative process, and the entire project team should be involved from the beginning of the project. Comprehensive and good risk identification will produce a good project results.
Don't forget to leave your comments below.
PMBOK; 2013 ; Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide) - Fifth Edition
Donna Ritter; 2013; Identifying Risks in Your Project. Retrieved 15 December 2013, available from http://certifedpmp.wordpress.com/2008/10/13/identifying-risks-in-your-project/