Common Software Risks

One of the standard approaches to identifying risks is the categorization of risk events. The purpose of categorization is to focus the team’s attention on a specific area of the project so that risks that might otherwise be missed will get identified. This article attempts to take this process one step further with a generic set of risk events that are common to just about any software project.

The article does not address the strategies that you might employ to mitigate the risk event. Strategies are very much dependent on the project environment; mitigation strategies should be specific to the environment to be practicable, for one thing the implementation of the strategy must be the responsibility of a team member. This web site does contain a number of articles on the various Software Lifecycle Development Methodologies (SLDC) and these articles do refer obliquely to risks attendant on the various methods. The risks are referred to as "cons”, or drawbacks, of the method.

We will divide the project into its various phases and identify the risks common to each one of these categories.

Planning

1. The project stakeholders and users are not engaged and the project team is not successful in soliciting their needs and requirements. This risk will not apply to those projects undertaken under contract where work is specified by the Statement of Work (SOW).
2. The project stakeholders and users provide a wish list of requirements which exceed the budget and schedule constraints of the project. Some excess of requirements over development capacity is to be expected. The risk event is when demand is significantly in excess of capacity.
3. Requirements and needs are not clear, concise, or unambiguous. Again, this is a subjective judgment. This risk event will lead to the design and development of functionality which does not meet the stakeholders’ needs.
4. The team is given contradictory requirements and needs.
5. The schedule planned for the project does not provide sufficient time to develop and test the functionality that meets the stated requirements.
6. Requirements are not finalized in time to begin the development/build phase.

Development/Build

1. Business Analysts (BAs), or Systems Analysts misinterpret stakeholder/user requirements. This will lead to a Functional Spec (FS) or Software Requirements Specification (SRS) which won’t deliver the functionality required.
2. The software development tools do not support developing the required software. This does not necessarily mean that the tools (e.g. development platform, automated test tools, etc.) cannot be used to develop the software but that they are not a good fit and make development excessively complex.
3. Developers misinterpret the FS or SRS.
4. The software developed does not function as designed (i.e. does not conform to the Detail Design Document).
5. Development test plans and test cases do not thoroughly exercise the code.
6. Excessive re-work caused by "buggy” software overwhelms development capacity.
7. The hardware, Operating System, OEM, or software application components do not integrate properly.
8. The volume of change requests overwhelms the team’s ability to analyze them.
9. There are excessive integration problems during the build of the application for system testing.
10. The duration of development activities exceeds the scheduled time.
11. Resources promised to the project are not available on time.
12. Resources working on the project are transferred to another project with higher priority than this one.
13. Data required for testing is unavailable, or excessively difficult to access. This will only apply to software projects where a database is involved but can be fairly common where an organization has a set of standard data and software functionality is influenced by the data.
14. The development technology chosen will not meet requirements for performance or capacity.
15. User Manuals and/or Help facilities are poorly written, unclear, unhelpful

QA Testing

1. A difference in environments makes reproduction of a bug discovered in QA test impossible or difficult to re-produce in the development environment.
2. The QA organization does not have sufficient resources available to meet their testing schedule.
3. QA testing encounters a bug which prevents further testing. This isn’t a problem as long as an emergency build can produce a new system version in a timely fashion but will cause problems if it happens frequently.
4. A high failure rate causes excessive re-testing.
5. Performance, load, or stress testing requirements are not available or are not well defined.
6. Data required to perform performance testing is not available. Performance testing may require a specific volume of data to replicate production conditions.
7. Data required to perform load or stress testing is not available. Load testing is frequently dependent on large volumes of data.
8. Users required to perform load or stress testing are not available. Load or stress tests often test the system when usage is at a peak. The number of users who can log on to a system at once is one example.

User Acceptance Testing

1. Users do not sign up to participate in User Acceptance Testing.
2. Users encounter conflicts for their time between their testing and operational duties.
3. There is an insufficient supply of hardware and/or software licenses to support UAT.
4. UAT data sets are not available.
5. Testers exercise the system differently than QA testers.
6. Testers use the problem reporting tool to request new features, changes in functionality, or design changes.
7. Testers encounter major bugs that block further testing.
8. Testers do not have access to the problem reporting tool.

Cutover and Production

1. Key resources are not available for the scheduled cutover
2. Differences in the production platform make cutover impossible, or extend the cutover period beyond the cutover window.
3. System data (data supplied by the organization or system) is unavailable or cannot be ported to the production environment.
4. The help desk is overwhelmed by users who cannot use the new system. This could be the outcome of insufficient training or inadequate communication.
5. Users find problems with untested functionality, or functionality that does not support the way they perform their jobs.
6. The new system cannot support the volume of data, number of users, or type of usage that production demands.

This list is meant to be used as a "straw man” for the software development project. Not all the risks mentioned here will be appropriate for every project and every risk that your project may be exposed to has certainly not been identified here. For example, software applications that must be packaged and installed on individual desk tops or laptops will have an additional set of risks. The list should stimulate thought and identify additional risks that are unique to your project.

Risk identification is an integral part of Risk Management. You can strengthen your expertise in this area by pursuing certification by the Project Management Institute (PMI®) as a Risk Management Professional (PMI-RMP®). Before taking that step, you should be certified as a Project Management Professional (PMP®). Training to prepare you for that certification is available on this web site in both on-line form (AceIt©) and classroom form (three O virtual classroom courses). You can learn more about the certification process at (PMP® Certification).