acm - an acm publication


Controlling risk

Ubiquity, Volume 2001 Issue January, January 1 - January 31, 2001 | BY Patricia Duhart McNair 


Full citation in the ACM Digital Library

Better products result when software project managers also become risk managers.

Risk management is the planned control of risk. It involves monitoring the success of a project, analyzing potential risks, and making decisions about what to do about potential risks.

Integrating formal risk management with project management is a new phenomenon in the software engineering and product management community. It requires that project managers be involved in a project from the concept phase to the product's retirement.

Risk Management Roles

Projects support a business's goals and objectives, have defined, unique scopes of work, agreed-upon starting and ending dates, and committed resources. Project managers should develop new roles and responsibilities in risk management. These roles ensure responsibility for overall risk management and should be defined in a project management plan document. The following describes three key players in project risk management.

Software Project Manager: The Project Manager is the person who is directly accountable to the sponsor and program manager for successful execution of a project. The term "Project Manager" refers to both project leader and project manager throughout the rest of this article. The Software Project Manager (SPM) determines the responsibilities for risk management within in a given project. The SPM has overall responsibility for ensuring risk management occurs on the project, and directs or approves risk management planning efforts and all substantive changes to the risk control plans. The SPM assumes overall responsibility for all risk management actions associated with risks assigned to the project.

Software Development Manager: The Software Development Manager (SDM) coordinates risk management planning to ensure that risks are identified, risk assessment data is prepared, and control plans are complete. The SDM supports the SPM in reporting risk status to senior management and the customer. The SDM should prepare and maintain the risk plans and coordinate all subsequent risk statusing and reporting actions as well as evaluate risk control action effectiveness and recommend control actions. The SDM should coordinate the continuous review of the risk plan to keep the set of risk issues and associated risk assessment data and control plans current with project conditions.

Risk Owner: The Risk Owner is the individual identified by the SDM as the responsible individual for overseeing the risk. The Risk Owner identifies and assesses "own" risk to produce probability and impact information. He or she should develop risk mitigation and contingency plans and provide status data for respective risk issues and assist in evaluating risk control action effectiveness. The Risk Owner also documents threshold criteria of high and medium risk and supports identification of new risks.

Oftentimes in projects, a plan is created for risk every time a system is developed, and an assessment is done of that risk. Both managers and technical personnel develop risk plans for current projects, based on historical data. However, quite often the risks are identified and then forgotten throughout the product's lifecycle. They are listed and put on the risk watch list, but not addressed until they become problems. To prevent this from happening, at each "project review" the Risk Owner should give the status of the mitigation or contingency plan, and the project team should decide to 1) take action on the risk, 2) eliminate the risk or 3) retire the risk. Monitoring the risk should only be done when the risk does not have a high impact. As the risk management planning activities begin addressing risk identification, and assessment and control plans near maturity, use a spreadsheet to prepare a risk management plan that captures the risk planning data and provides a means to collect and report risk status.

In order to effectively evaluate risks for a project the basic risk attribution of probability and impact is not enough. A third element called timeframe should be given in order to provide a basis for comparison to other risks. The timeframe allows the project to readily assess prioritization. Prioritizing the risks relative to one another assists the team in deciding how to allocate resources for mitigation, particularly if the project team has identified a large number of risks.

The formula for risks is Probability * Impact * Timeframe (P*I*T). These three elements determine each risk's Risk Priority Number (RPN) by multiplying attribute ratings for probability, impact and timeframe

During risk tracking and control the project leaders must ensure that risks stay visible to the project and business management teams. They should recognize that those risks and their attributes (probability, impact and timeframe) will change over time. This helps to eliminate or retire risks when applicable. The project manager should track new identification of risk and create or modify mitigation and contingency plans on a regular basis. The identification of risks that become a problem should be deleted from the list of risks. The risk control actions defined by the mitigation and contingency plans should be implemented in accordance with the details of those plans. The Risk Owner is commonly responsible for the implementation of these actions.

Passive acceptance of risk is not an option. The likelihood of a product defect is reduced when risk management applies to all software development and spans the lifecycle of a product.

Patricia DuHart McNair, principal staff engineer at Motorola Corporation, has 22 years of architecture and software engineering experience and is currently an authorized lead assessor in the Carnegie Mellon University Software Engineering Lead Appraisal program. She serves as an adjunct professor at DePaul University in the Department of Management and previously was an adjunct professor at State University of New York - Binghamton in the Computer Science Department. This article is excerpted from a white paper previously written by author.


Great article. The method of assigning risk factors to multiple people helps mitigate risk by having additional eyes and strategies. What I like most about the article is the idea of trying to be pro-active and not reactive about risk when possible. The three steps of how do deal with risk factors is a great model to address risk - take action, eliminate the risk, or retire the risk.

��� james soltis, Sun, 17 Feb 2013 14:05:19 UTC

Leave this field empty