Recommendations and Risk Mitigation

Recommendations are really part of the assessment summary, not a separate phase in the assessment process, but they are so important we put them in a separate section. Developing recommendations is probably the most challenging part of the assessment, but it can also be the most beneficial part for the project.

There is no magic formula for developing recommendations. Just as the problems you identify will probably be unique for every assessment you do, so will the solutions and recommendations. However, reviewing good project management and risk mitigation techniques is useful for developing recommendations. A good understanding of the findings of software assessments and best practices in the industry will be helpful (for example, see Jones, 2000). Can dependency management help to resolve the potential for late test completion that you identified? Is more detailed planning required to successfully implement a new beta program? Can resources be shared across component teams of the project? If you are the project manager assessing the quality status of your project, this is the time to put your project manager hat back on. If you are the quality expert on the project team who is responsible for quality assessments, at this phase you need to think like a project manager.

Identification of risks and risk management is an important aspect of any assessment. It is akin to making a recommendation on a project checkpoint and is useful in determining the impact, consequences, or probable outcome of findings. Risk mitigation techniques include containing, reducing, or eliminating the risk. Table 15.2 shows risk management strategies as defined by the Project Management Institute, along with several examples. Brainstorming ideas for each type of strategy can help you to surface a viable solution to a risk or problem.

Table 15.2. Risk Mitigation Strategies

Strategy	Definition	Example
Contain	Minimize the occurrence of effect of the risk.	Establish and enforce a checklist for code integration (into the system library) to minimize problems during the driver build process.
Contingency	Create an action plan in case the risk occurs.	Develop an incentive program for additional defect removal at "development complete" that involves testers, developers, and service specialists who have good customer perspectives in the event that defect arrival during the system test phase is higher than desirable (an indication of more latent defects in the product).
Transfer	Transfer all or part of the risk to another party.
Ignore/accept	Accept the consequences if the risk occurs.
Avoid	Avoid the risk as in Use a different type of process. Eliminate the feature.	Identify functions that can be removed if schedule pressures occur.