Proactive Project Management- Risk Identification and Analysis

 
Nov. 13, 2013 - PRLog -- Risk is a part of every day life.  A software development or technology project, whether simple or complex, packaged or custom, waterfall or agile is no exception when it comes to high risk.  Technology projects can pose enormous risk to the business or organization.

“An ounce of prevention is worth a pound of cure” - Benjamin Franklin, Philadelphia's Union Fire Company organizer, circa 1736.

The Project Management Institute (PMI) is an organization focused on educating and certifying project managers.  A part of that is managing risk effectively.  The ability to identify and understand risk on a project increases the likelihood for a successful project. Trillium’s approach to risk is represented by the graphic on the left below.  This perspective was created based on our extensive project delivery experience coupled with a deep understanding of the value of the PMI risk management model.

Keeping in mind the cyclical process of Risk Management, the key take-aways for risk identification and analysis include:

Identify

Timing is everything
! Leverage the work breakdown structure (WBS) when setting up all projects. Gaps and areas to monitor more carefully will become more easily visible. Look for integration points, critical path deliverables, data conversion points, and resource availability.
Listen, really well! Project managers are generally a part of more meetings and hallway discussions. Each is an opportunity to gage how well the project is moving or any risks that are starting to surface. Identifying risks is more than just asking if anyone has any problems on a status meeting. It is really listening to what is said and NOT said when discussing the "Basic 4":  scope, budget, resources and schedule.

Analyze

What is a Proof-of-Concept anyway?
A proof-of-concept (POC) should be considered when projects have new or heavily changing technology. The added advantage is that they enable management to assess the skill set of the team and proactively offer training.  More importantly, planning for POCs enables you to assess the viability of the design before reaching critical mass in the project.  This is a topic that merits its own discussion; however, a common mistake on the part of managers is a lack of appreciation on how POCs avoid cost overruns and technical disasters.
Clear Business Requirements. Commonly, schedule or budget adjustments are traced back directly to unclear business requirements.  Signed off and clear requirements are foundational to the success of a project.

Control and Monitor

The Basic 4.
Basic analysis of any risk includes analysis across the “Basic 4”:  scope, schedule, budget, resources. Fully understanding the area(s) at risk and why will enable clearer communication and action on the part of leadership.
Classify risks by their probability and impact. To communicate the impact and likelihood of a risk, include both in assessments to leadership. Define impact as events that could have an impact on the outcome or ability to meet deliverable requirements, schedule due dates, cost, or system performance.
Develop your planned response ahead of time.  Include assigned owners who are responsible for tracking and managing the risk until it is closed out or moved to an issue status. PMBOK states the responses are Avoidance, Acceptance, Deflection, or Mitigation.  Avoidance involves developing alternatives to eliminate or resolve factors that contributes to the risk event. Acceptance means planned courses of actions designed to accommodate the incremental costs or impacts.  Stakeholders agree to accept the risk and establish thresholds for decision points, including acceptance of slower system performance or even the extreme of canceling or terminating the project. Deflection (the PMI term is Risk Transfer) means a planned course(s) of action to transfer or move risk to another party, area, or department, usually by some form of contract. Pushing responsibility to those who have vested interests or direct control over the resources, systems, or causes. Mitigation is a planned course(s) of actions to manage and reduce the impacts.
There is no such thing as over-communication. Communication to executives, management, and key stakeholders must be relevant, timely, and avoid surprises. The degree of information shared must keep them apprised but not cause unnecessary controversy, or drive premature decisions. Communications for identified risks, including status, and risk response outcomes include Risk Management and Decision Logs, and Communication Plans. Risk Management Logs provide ongoing details that will feed summary reports. Decision Logs provide context and background for key decisions, including risk mitigation decisions. Communication plans and contact lists provide reminders that ensure the appropriate people are kept informed with appropriate levels of detail.

Risk Management should be a fundamental tool in every project manager’s bag.  In the best-case scenario, it enables taking action early enough to avoid detrimental impacts to the project deliverables.  In the worst case scenario, it provides opportunity to ensure your stakeholders are informed, and have agreed to planned responses to the risks, including decision thresholds should the risks become reality.

About Trillium

Trillium Solutions Group, Inc. is a professional services firm headquartered in Chicago that provides technology consulting and strategic sourcing services for industries such as trade associations, financial services, telecommunications, and healthcare. For more information, please visit www.trilliumsg.com.

Robert Sanchez (http://trilliumsg.com/index.php/insights/author/sanchez), Sr. Project Manager, was a contributor to this Trillium Insights blog post.
End
Trillium Solutions Group News
Trending
Most Viewed
Daily News



Like PRLog?
9K2K1K
Click to Share