RISK MISSING, MONITORING AND MANAGEMENT PLAN (RMMM Plan)

RISK MISSING, MONITORING AND MANAGEMENT PLAN (RMMM Plan)
 1.0 INTRODUCTION
[This paragraph gives a general overview of the RMMM plan]
1.1 Space and scope of RMMM activities
[RMMM General Focus Description including Organizational Objectives and Responsibilities]
 1.2 Organizational Risk Management Roles
[Description of those who have the responsibility for managing rigor. ]

2.0 PROBLEM RISKS
[Describe all risks recognized for the project.]
2.1 Checklist for Identification of Risks
[Answering Questions]
2.1.1 Risks related to product size
O Estimated size of the product in LOC or FP?
O Degree of confidence in estimated size estimate?
O Estimated size of product in number of programs, files, transactions?
O Percentage deviation in size of product from average for previous products?
O Size of database created or used by the product?
O Number of users of the product?
O Number of projected changes to the requirements for the product? Before delivery? After delivery?
O Amount of reused software?
2.1.2 Dangers Affecting Business
O Affect of this product on company revenue?
O Visibility of this product by senior management?
O Reasonableness of delivery deadline?
O Number of customers who will use this product and the consistency of their products relative to the product?
O Number of other products / systems with which this product must be interoperable?
O Sophistication of end users?
O Amount and quality of product documentation that must be produced and delivered to the customer?
O Governmental constraints on the construction of the product?
O Costs associated with late delivery?
O Costs associated with a defective product?

2.1.3 Customer-related risks
O Have you worked with the customer in the past?
O Does the customer have a solid idea of ​​what is required? Has the customer spent the time writing it down?
O Will the customer agree to spend time in formal requirements gathering meetings (Chapter 11) to identify project scope?
O Is the customer willing to establish rapid communication links with the developer?
O Is the customer willing to participate in reviews?
O Is the customer technically sophisticated in the product area?
O Is the customer willing to let your people do their job-that is, will the customer resist looking over your shoulder during technically detailed work?
O Does the customer understand the software engineering process?
2.1.4 Dangers of the Process
Process Problems
O Does your senior management support a written policy statement that emphasizes the importance of a standard process for software development?
O Has your organization developed a written description of the software process to be used on this project?
Are staff members "signed-up" to the software process as it is documented and willing to use it?
O Is the software process used for other projects?
Has your organization developed or acquired a series of software engineering training courses for managers and technical staff?
O Are published software engineering standards provided for each software developer and software manager?
O Have document outlines and examples been developed for all deliverables defined as part of the software process?
Are formal technical reviews of the requirements specification, design and code conducted regularly?
O Are regular technical reviews of test procedures and test cases conducted regularly?
Are the results of each formal technical review documented, including defects found and resources used?
O Is there some mechanism for ensuring that work carried out on a project conforms with software engineering standards?
O Is the configuration management used to maintain consistency between system / software requirements, design, code, and test cases?
O Is a mechanism used to control changes in customer requirements that impact the software?
O Is there a documented statement of work, software requirements specification, and software development plan for each subcontract?
O Is a procedure followed for tracking and reviewing the performance of subcontractors?

Technical problems
O Are the facilitated application specification techniques used to aid communication between the customer and the developer?
O Are specific methods used for software analysis?
Do you use a specific method for data and architectural design?
O Is more than 90 percent of your code written in a high order language?
O Are defined conventions for code documentation defined and used?
Do you use specific methods for test case design?
O Are software tools used to support planning and tracking activities?
O Are the configuration management software tools used to control and track the change activity throughout the software process?
Are software tools used to support the software analysis and design process?
Are tools used to create software prototypes?
Are the software tools used to support the testing process?
O Are the software tools used to support the production and management of documentation?
Are quality metrics collected for all software projects?
Are productivity metrics collected for all software projects?
O If a majority of the above questions are answered "no," the software process is weak and the risk is high.
2.1.5 Technological Risks
O Is the technology to be built new to your organization?
Do the customer's requirements require the creation of new algorithms, input or output technology?
O Does the software interface with new or unproven hardware?
O Does the software to be built interface with vendor supplied software products that are unproven?
O Does the software work with a database system whose functionality and performance have not been proven in this application area?
O Is a specialized user interface demanded by product requirements?
O Do the requirements for the product require the creation of program components that are different from any previously developed by your organization?
O Do requirements require the use of new analysis, design or testing methods?
O Do requirements require the use of unconventional software development methods, such as formal methods, AI-based approaches, artificial neural networks?
Do the requirements put excessive performance constraints on the product?
O Is the customer uncertain that the functionality requested is "do-able?"
O If the answer to any of these questions is "yes", further investigation should be undertaken to assess the risk potential.
2.1.6 Risks to the environment where development is taking place
O Is a software project management tool available?
O Is a software process management tools available?
Are tools for analysis and design available?
O Do analytical and design tools provide methods that are appropriate for the product to be built?
O Are compilers or code generators available and appropriate for the product to be built?
O Are testing tools available and appropriate for the product to be built?
Are software configuration management tools available?
O Does the environment make use of a database or repository?
Are all software tools integrated with one another?
O Have members of the project team received training in each of the tools?
O Are local experts available to answer questions about the tools?
O Is online help and documentation for the tools adequate?
O If a majority of the above questions are answered "no," the software development environment is weak and the risk is high.
2.1.7 Risks related to size and staff experience
Are the best people available?
Do the people have the right combination of skills?
Are there enough people available?
Are staff committed for the entire duration of the project?
O Will some project staff be working part-time on this project?
Do staff have the right expectations about the job at hand?
Have staff received necessary training?
O Will turnover among staff be low enough to allow continuity?
O If the answer to any of these questions is "no", further investigation should be undertaken to assess the risk potential.
 2.2 Risk table
[Presentation of all risks, probabilities and their impact.]

3.0 RISK MANAGEMENT, MONITORING AND MANAGEMENT
RMMM is discussed for any danger.
 3.1 risk mitigation risk m
[How to avoid this danger? Section reiterated for each identified risk]
 3.2 Risk monitoring m
[What conditions should be monitored to determine if the risk is more or less likely to become a real problem? The section is repeated for any danger.]
3.3 Risk Management m
[Action plan in case the risk will turn into reality. The section is repeated for any danger.]
4.0 VARIOUS CONDITIONS
[Discussion of specific conditions that may incite critical risks to the project and action to be taken if these special conditions are met.]