Rajman Md Rawi on his article “Project Risk Identification for New Project Manager” for PM Times gives us a few tips to identify risks as a project manager.
It starts the article with a very clear definition of Project Risk Management, taken from the book Project Management Institute. A Guide to the Project Management Body of Knowledge “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.”
Then Rawi gives us a few tools/techniques to identify risks like: 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 and Expert Judgment.
He also gives us 5 categories of potential risk that a project could be exposed: Human Resources & Contractors Risk, Customer Risk, Product/Technology Risk, Requirement Risk, Schedule Risk.
Schedule Risk, he advise us to be aware when our schedule is not realistic, we have a missing task in the schedule, we don’t take on account a potential delay in one task that could delay other tasks in the future, and unfamiliar areas of the product that could take more time that initially though due design and implementation.
Requirement Risk, he recommend to be alert to continuing changes in requirements, requirements poorly defined, some areas of the product could be more time-consuming than others, we are only aware of some requirements when the project start, and total features could be more than what the development team can deliver at the time.
Project Management Risk, he mention that the project manager could have little authority in the organization and low power to influence decision-making and resources, priorities change during the project, we have to clearly defined evaluation criteria for every project phase, we have to be aware that multiple projects within the same company could need the same resources at the same time. And that sometimes the date is driven by marketing demo, tradeshows or other events and not been taking under consideration project teams estimates
Product/Technology Risk, we have to be vigilant that development of the wrong user interface, application or program could result in redesign and implementation errors. Development of extra software functions that are not required could extend the schedule. You could depend in technology that is still under development. And the technology selected could be a problem to the customer
Customer Risk, customer could insist on new requirements or other technical decision, Customer review/decision cycles for plans, prototypes, and specifications could be slower than expected. Even if you product meets all specifications, the customer could not accept the product. And Customer has expectations for development speed that developers cannot meet.
Human Resources & Contractors Risk, Critical development work is being performed by one developer, some developers or contract personnel 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, there could be conflicts among team members result in poor communication, poor designs, interface errors and extra rework. When looking for new personnel, there is a risk that you cannot find someone with critical skills needed. And contractor could not deliver components when promised.
I agree with his conclusion, I also think that in order to manage and successfully complete a project we have to be able to identify risks and have to be proactive to mitigate the negative impacts that those risks could have, and make a routine out of identifying risk because as he explains, risk can be change throughout the project and vary their importance. The only statement that I disagree is “we should not spend too much time in identifying risks”. Even though it could be time consuming I think that, you should spend time identifying risks to mitigate future negative outcomes.
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 fromhttp://certifedpmp.wordpress.com/2008/10/13/identifying-risks-in-your-project/