Project Risk and the SEI

Project Risk and the SEI

The Carnegie Mellon University's Software Engineering Institute developed a software risk model based on the Shewhart-Deming cycle. The model provides information and feedback, internal and external to the project, on the risk activities, current risks, and emerging risks. Figure 1 illustrates the model's processes:

●  Identify - search for and locate risks before they become problems;

●  Analyze - transform risk data into decision-making information, evaluate impact, probability, and timeframe; classify risks and prioritize risks;

●  Plan - translate risk information into decisions and mitigating actions (both present and future) and implement those actions;

●  Track - monitor risk indicators and mitigation actions;

●  Control - correct for deviations from the risk mitigation plans.

Software Engineering Institutes Risk Management Model

Communication happens throughout all the functions with common process characteristics being:

●  Identification - figure out what the risks are;

●  Analysis and quantification - gathering information and prioritizing the risks;

●  Response planning - deciding what to do about the risks;

●  Tracking and communicating - monitoring the risks and the controlling actions while communicating status.

Identifying Risks

The process of risk identification is completed using the same tools as any analysis task. Start out by having the team and the customer brainstorm possible risks to develop "known unknown" lists. Use checklists of problems from prior projects retrieved from the project repository or knowledge-base. Study all project assumptions in the project plan for the slightest hint of risk. Pay special attention to those that assume a rosy future where everything works. Interview stakeholders for risk identification and quantification.

Take the work breakdown structure and network diagrams from the project management plan and search for precedence bottlenecks. These will show up as tasks that require many other tasks to be completed before they can begin. These are the real choke points in the project planning network and have the highest risk reaction with schedule slips. Sometimes flowcharting a process helps spot risky areas. If the process is not familiar, draw the flow of execution necessary to see all the dependencies to successful completion. Look at the sources of key decisions in the project. Search for decision drivers.

Look at different types of risks:

●  Technical

●  Operational

●  Political

●  Legal

●  Regulatory

●  Market

●  Social

●  Internal

●  External

After the first pass at identifying project risk is made, the project team needs to step back and take a broader look at all the possible risk sources. Figure 2 graphically shows that there are three basic risk areas - supportability, technical, and programmatic - that add risk to cost and schedule. Keep in mind that cost and schedule are inherently risky.

Risk Sources

Table 1 shows possible risks for the three top risk sources. Technical risks are a major part of the software development business since software is the driver of high technology. Programmatic sources arise from the process of trying to manage the software development project. As the software product nears completion, the risks inherent in the software delivery, installation, and maintainability are very real and clear.

Examples of Risks Within Each Source

As is clear from Figure 2, cost and schedule are not only impacted by the top three sources of risk, but also impact themselves. Cost risk can further be found in estimating errors and under allocation of overhead, general, and administrative costs. Schedule is made riskier due to increases in the project task degree of concurrency, number of critical path items, and estimating error.

Figure 3 illustrates a simple diagrammatic method for representing the classes and types of risks identified. Risks can easily be grouped into clusters based on scope, quality, schedule, and cost, as well as more coarse divisions of business, technology, and environment. By spending the time to map the clustering and categorize identified risks, the project team can pinpoint areas where risks may remain but have yet to be identified. This process helps discover the "unknown unknowns."

Risk Clustering


software risk model, software development, project management, project risk
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
© Copyright 2018 SPMInfoBlog.
Designed by TechPlus