6/14/2014 Aceit PMP Exam Prep - Risks Common to most Software Projects

http://threeo.ca/commonrisksp827.php 1/3

Home
About Us
Site Map
Products
Services
PMP Certification
PM Tips & Tricks
PM Tools &
Techniques
Links
Contact Us
BLOG


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 teams 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 wont 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.

6/14/2014 Aceit PMP Exam Prep - Risks Common to most Software Projects
http://threeo.ca/commonrisksp827.php 2/3
7. The hardware, Operating System, OEM, or software application components do not
integrate properly.
8. The volume of change requests overwhelms the teams 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 isnt 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.
6/14/2014 Aceit PMP Exam Prep - Risks Common to most Software Projects
http://threeo.ca/commonrisksp827.php 3/3
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).

POWERED BY
ULTIMATE WEBSITES

SITEAPEX WEBMAIL