• R-A-G - Red-Amber-Green

1. A description of the identified risk
2. The impact level of the risk (e.g. high, medium, low)
3. The specific software cause of this risk, so it can be traced to the specific location in the software
4. Risk Control Method employed
5. Test or verification method used to confirm the Risk Control Method employed
6. Impact level of the Risk after the Risk Control Method has been implemented
• what the estimated impact of each risk is and how it was categorized
• what risk reduction and decrease techniques were implemented and how their effectiveness was accessed
• testing and evaluation demonstrating the implementation of the safety features

Risk Management:: Risk Estimation List

1. Requirements Risks: Unclear or uncertain requirements introduce large risks. This is the most common type of risk and is probably responsible for most failed or delayed projects. Competitive forces and business agreements with new partners force the Company and its software systems to change. Users find it hard to visualize software until they use it, which makes requirements fuzzy and subject to change.
2. Technology Risks: At some point in development (usually late in the cycle), the development team finds that the technology can not satisfy system requirements. For example, team members could assume that the database they use is not easily corrupted, but when they actually build the system, they find that it has bugs that can cause it to become corrupted frequently.
3. Business Risks: Business decisions introduce many risks. A deal with a vendor does not signed in time to use the desired platform. A conflict with a partner who supplies part of the solution stalls the project or the partner goes out of business.
4. Political Risks: These are the most difficult risks to overcome. Large organizations tend to behave like large families. Members are busy jockeying for power and influence over each other. Some groups might find the project threatening, which means that people do not cooperate, budgets get cut, or the project gets canceled. Contingency plans for this risk are hard to define, because these plans can cause embarrassment later, and if project opponents find out about the contingency plans, they can sabotage them.
5. Resources Risks: When a project does not get the required people, money, facilities, or equipment, the shortfalls degrade both schedule and morale. Identifying an alternative resource can help. For example, another team might be willing to share some of its servers until yours come in.
6. Skills Risks: These risks arise if, for example, the team is unfamiliar with the technology or business processes. Providing training and bringing in consultants with the missing skills, who can mentor the team, will help mitigate this risk.
7. Deployment and Support Risks: The team can not deploy the software on schedule because the required infrastructure is not in place or the support team is not ready for training or is already stretched too thin. Sometimes this risk occurs because the deployment and support team have no idea what the project team is doing, let alone what it needs. In this help, communication will help mitigate the risk.
8. Integration Risks: Most applications must integrate with other applications. Miscommunication and misunderstandings cause systems to miss sharing accepted interfaces, so they do not work together as expected. Communication is key to reducing this risk. It is necessary to try to do integration in parallel with development (using stubs that satisfy agreed-on interfaces). Variations and unexpected behavior should be communicated to all interested parties as soon as possible. A flexible development process will let the team try different designs if it encounters intractable integration issues.
9. Schedule Risks: These issues include components that are not available when needed, delivery at an extremely busy time, and so on. Communication can help people see that timing a product upgrade towards the end of a quarter is not a good idea because the sales staff are trying to reach their quotas. They do not want to re-price products and reeducate customers just when they are about to close deals. Good project planning can help prevent schedule risk.
10. Maintenance and Enhancements Risks: The company can not maintain and enhance the software properly because the documentation is inadequate, the support team is not properly trained, or the platform has become obsolete. Planning and setting aside time for adequate training and documentation can help reduce these risks. A flexible development process can make things worse if managers do not allow enough time, money, and people for training, documentation, and support.
11. Design Risks: Bad design decisions can degrade the software's usability and system performance. A flexible development process that can accommodate user input and changes late in the process can reduce this risk.
12. Miscellaneous Risks: This is a catch-all category for risks that are hard to foresee - a hurricane or fire shuts down offices for a week, a development server crashes, a virus attacks, and so on. Most of these risks involve a loss of some resource, so a mitigation strategy is to arrange for back up. Possible solutions: Set people up to work at home, store project data in multiple locations, or plan to use a spare server from another team.

Risk Management:: Risk Estimation Matrix

A Risk Estimation Matrix, shown on Figure 4, is used to see the overall risk of the Project.

• Red - Issue exists, high control risk or unknown resolution.
• Amber - Issue exists however no major control risk.
• Green - All OK, no outstanding issues, no further action required.
• N/A - Not applicable. 

• I denotes "Situation Improving/ Increasing Control"
• S denotes "Situation remaining at the same level of control"
• D denotes "Situation Declining/ Increasing Risks"

Please note that the Matrix is not 3-state (R-A-G only), but 9-state (3 more parameters added (I-S-D).

As a result, our estimation of the systems will be much better than if we will use so-called "magic quadrant" (will not shown).