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.
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).
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.
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.
team is given contradictory requirements and needs.
schedule planned for the project does not provide sufficient time to
develop and test the functionality that meets the stated requirements.
are not finalized in time to begin the development/build phase.
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.
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
misinterpret the FS or SRS.
software developed does not function as designed (i.e. does not conform to
the Detail Design Document).
test plans and test cases do not thoroughly exercise the code.
re-work caused by "buggy” software overwhelms development capacity.
hardware, Operating System, OEM, or software application components do not
volume of change requests overwhelms the team’s ability to analyze them.
are excessive integration problems during the build of the application for
duration of development activities exceeds the scheduled time.
promised to the project are not available on time.
working on the project are transferred to another project with higher
priority than this one.
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.
development technology chosen will not meet requirements for performance
Manuals and/or Help facilities are poorly written, unclear, unhelpful
difference in environments makes reproduction of a bug discovered in QA
test impossible or difficult to re-produce in the development environment.
QA organization does not have sufficient resources available to meet their
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.
high failure rate causes excessive re-testing.
load, or stress testing requirements are not available or are not well
required to perform performance testing is not available. Performance
testing may require a specific volume of data to replicate production
required to perform load or stress testing is not available. Load testing
is frequently dependent on large volumes of data.
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.
do not sign up to participate in User Acceptance Testing.
encounter conflicts for their time between their testing and operational
is an insufficient supply of hardware and/or software licenses to support
data sets are not available.
exercise the system differently than QA testers.
use the problem reporting tool to request new features, changes in
functionality, or design changes.
encounter major bugs that block further testing.
do not have access to the problem reporting tool.
Cutover and Production
resources are not available for the scheduled cutover
in the production platform make cutover impossible, or extend the cutover
period beyond the cutover window.
data (data supplied by the organization or system) is unavailable or
cannot be ported to the production environment.
help desk is overwhelmed by users who cannot use the new system. This
could be the outcome of insufficient training or inadequate communication.
find problems with untested functionality, or functionality that does not
support the way they perform their jobs.
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).