Risk Management Primer For Small Teams

In software engineering, every single activity is an act of mitigating or removing one or more risks. For example, upfront architecture of the product mitigates the risk of poor performance; testing mitigates the risk of failure at production; analysis mitigates the risk of unhappy customer and project failure. Let us give this risk mitigation technique a name: In-process Risk Mitigation And Prevention.

However, there are some risks that must be pinpointed and observed closely. The In-process technique is not enough in these cases. Here are some examples:

Requirements Risks:

• Requirements are vague
• Lack of experience in the problem space
• Communication problem between the team and the customers/users.

Technical Risks:

• New technology, new tools.
• Performance and Scalability risks
• Integration of work products of dispersed teams.

Scheduling Risks:

• tight schedule imposed by the customer/market/management

There are so many risks that may be identified. However, many of them are not of such importance to be kept spotted. In my experience, the following risks are typically not that important to be tracked:

People:

• People get sick
• Team member leaves the company, or re-assigned to another project

Scheduling risks

• Team receives L2 support requests
• Requirements risks
• Many change requests from customer

Very important note: these risks may well be risks, and may impact the project negatively. However, the reason they are not spotted is that they are very well handled in the In-process risk mitigation technique.