« Managing The Project Time - Conclusion
Costing and Budgeting - Introduction »

Typical Software Risks

June 15, 2008 | Author: admin | Filed under: Risk Management

Typical Software Risks (#3 in the series Know Your Enemy: Software Risk Management)
By Karl E. Wiegers

The list of evil things that can befall a software project is depressingly long. The enlightened project manager will acquire extensive 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 group I’ve worked in, individual team members came up with insightful descriptions of their risk factors, which I edited together and we then reviewed as a team.

The Software Engineering Institute (SEI) has assembled a taxonomy of hierarchically-organized risks in 13 major categories, with about 200 thought-provoking questions to help you spot the risks facing your project. These are listed in SEI Technical Report CMU/SEI-93-TR-006, “Taxonomy-Based Risk Identification,” by Marvin Carr, et al. Steve McConnell’s Jolt Award-winning Rapid Development (Microsoft Press, 1996) also contains excellent resource material on risk management.

Following are several typical risk categories and risk items that may threaten your project. Have any of these things have happened to you? If so, add them to your master risk factor checklist to remind future project managers to ask themselves if it could happen to them, too. There are no magic solutions to any of these risk factors, so we need to rely on past experience and a strong knowledge of software engineering and management practices to control those risks we are most concerned about.

Dependencies

Many risks arise because of dependencies our project has on outside agencies or factors. We cannot usually control these external dependencies, so mitigation strategies may 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. Here are some typical dependency-related risk factors:

  • customer-furnished items or information
  • internal and external subcontractor relationships
  • inter-component or inter-group dependencies
  • availability of trained, experienced people
  • reuse from one project to the next

Requirements Issues

Many projects face uncertainty and turmoil around the product’s requirements. While some of this uncertainty is tolerable in the early stages, the threat to success increases if such issues are not resolved as the project progresses. If we don’t control requirements-related risk factors, we might either build the wrong product, or build the right product badly. Either situation 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

Management Issues

Although management shortcomings inhibit the success of many projects, don’t be surprised if your risk management plan doesn’t list very many of these. After all, the project manager is usually the person who is writing the risk management plan, 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 we don’t confront such touchy issues, we shouldn’t be surprised if they bite us at some point. Defined project tracking processes, and clear project roles and responsibilities, can address some of these risk factors.

  • inadequate planning and task identification
  • inadequate visibility into actual 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

Lack of Knowledge

The rapid rate of change of software technologies, and the increasing shortage of skilled staff, mean our project teams may not have the skills we need to be successful. The key is to recognize the risk areas early enough so that we can take appropriate preventive actions, such as obtaining training, hiring consultants, and bringing the right people together on the project team. These factors might 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 may not work

Adapted from “Practical Project Initiation: A Handbook with Tools” (Microsoft Press, 2007), with permission from author.

Karl Wiegers, Ph.D., is Principal Consultant with Process Impact, a software process consulting and education company in Portland, Oregon. Karl’s most recent book is “Practical Project Initiation: A Handbook with Tools.” Karl is also the author of four other books and 170 articles. Karl is a frequent speaker at software conferences and professional society meetings. You can reach Karl through www.projectinitiation.com or www.processimpact.com.

Share this article:
  • StumbleUpon
  • Digg
  • del.icio.us
  • Technorati
  • Reddit
  • YahooMyWeb
  • blogmarks

Related Articles

This entry was posted on Sunday, June 15th, 2008 and is filed under Risk Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories