The list of evil things that can befall a software project is depressingly long. The enlightened project manager will acquire lists of these risk categories to help the team uncover as many concerns as possible early in the planning process. Possible risks to consider can come from group brainstorming activities or from a risk factor chart accumulated from previous projects. In one of my groups, individual team members came up with descriptions of the risks they perceived, which I edited together and we then reviewed as a team.
The Software Engineering Institute has assembled a taxonomy of hierarchically-organized risks in 13 major categories, with some 200 thought-provoking questions to help you spot the risks facing your project (Carr et al. 1993). Steve McConnell’s Rapid Development (1996) also contains excellent resource material on risk management and an extensive list of common schedule risks.
Following are several typical risk categories and some specific risks that might threaten your project. Have any of these things have happened to you? If so, add them to your master risk checklist to remind future project managers to consider if it could happen to them, too. There are no magic solutions to any of these risk factors. We need to rely on past experience and a strong knowledge of software engineering and management practices to control those risks that concern us the most.
Note
Expecting the project manager to identify all the relevant risks. Different project participants will think of different possible risks. Risk identification should be a team effort.
Some risks arise because of dependencies our project has on outside agencies or factors. We cannot usually control these external dependencies. Mitigation strategies could involve contingency plans to acquire a necessary component from a second source, or working with the source of the dependency to maintain good visibility into status and detect any looming problems. Following are some typical dependency-related risk factors:
Customer-furnished items or information
Internal and external subcontractor or supplier relationships
Intercomponent or intergroup dependencies
Availability of trained and experienced people
Reuse from one project to the next
Many projects face uncertainty and turmoil around the product’s requirements. Some uncertainty is tolerable in the early stages, but the threat increases if such issues remain unresolved as the project progresses. If we don’t control requirements-related risks we might build the wrong product or build the right product badly. Either outcome results in unpleasant surprises and unhappy customers. Watch out for these risk factors:
Lack of a clear product vision
Lack of agreement on product requirements
Inadequate customer involvement in the requirements process
Unprioritized requirements
New market with uncertain needs
Rapidly changing requirements
Ineffective requirements change management process
Inadequate impact analysis of requirements changes
Although management shortcomings affect many projects, don’t be surprised if your risk management plan doesn’t list too many of these. The project manager often leads the risk identification effort, and most people don’t wish to air their own weaknesses (assuming they even recognize them) in public. Nonetheless, issues like those listed here can make it harder for projects to succeed. If you don’t confront such touchy issues, don’t be surprised if they bite you at some point. Defined project tracking processes and clear project roles and responsibilities can address some of these conditions.
Inadequate planning and task identification
Inadequate visibility into project status
Unclear project ownership and decision making
Unrealistic commitments made, sometimes for the wrong reasons
Managers or customers with unrealistic expectations
Staff personality conflicts
Software technologies change rapidly and it can be difficult to find suitably skilled staff. As a result, our project teams might lack the skills we need. The key is to recognize the risk areas early enough so we can take appropriate preventive actions, such as obtaining training, hiring consultants, and bringing the right people together on the project team. Consider whether the following factors apply to your team:
Lack of training
Inadequate understanding of methods, tools, and techniques
Insufficient application domain experience
New technologies or development methods
Ineffective, poorly documented, or ignored processes
Technical approaches that might not work
Outsourcing development work to another organization, possibly in another country, poses a whole new set of risks. Some of these are attributable to the acquiring organization, others to the supplier, and still others are mutual risks. If you are outsourcing part of your project work, watch out for the following risks:
Acquirer’s requirements are vague, ambiguous, incorrect, or incomplete.
Acquirer does not provide complete and rapid answers to supplier’s questions or requests for information.
Supplier lacks appropriate software development and management processes.
Supplier does not deliver components of acceptable quality on contracted schedule.
Supplier is acquired by another company, has financial difficulties, or goes out of business.
Supplier makes unachievable promises in order to get the contract.
Supplier does not provide accurate and timely visibility into actual project status.
Disputes arise about scope boundaries based on the contract.
Import/export laws or restrictions pose a problem.
Limitations in communications, materials shipping, or travel slow the project down.