Risk Registry Policy


The risk register starts with a risk management plan. Every project manager must seek input from team members as well as stakeholders and possibly even end users. The risk register or risk log becomes essential as it records identified risks, their severity, and the actions steps to be taken.


Common Risks:

There are a number of risks that are common to every software development project regardless of size, complexity, technical components, tools, skill sets, and customers. The following list contains most of these:

  • Missing requirements – Requirements needed by the software system to be developed to meet the business goals and objectives of the project.
  • Misstated requirements – Requirements that have been captured but the original intent has been lost or misconstrued in the process of capturing them.
  • Key or critical resources are lost to the project – These resources are usually single contributors, or team members with skill sets in scarce supply for which there is a strong demand in the performing organization.
  • Bad estimation – The estimations for effort required for developing the software are either significantly understated (bad) or overstated (also bad). Underestimation is the most common event.
  • Missing or incomplete skill sets – The results of this risk event will be the same as the results of bad estimation, but the risk will be mitigated differently.


Other type of risks:


Organizational Risks

These are risks that are unique to the organization performing the project. They may include some of the risks in the list of common risks, and other sources, but will also include risks that have no other sources.
The project manager should consult the archives of previous software development projects for the common risks, where project records have been archived. Gather the risk registers of all the previous projects and try to match risks in each register.


SDLC Specific Risks

Your software development project will be exposed to some risks and shielded from others depending on which SDLC (Software Development Life Cycle) methodology you choose to use for your project. Risk avoidance is a significant consideration when choosing an SDLC for the project and your project should choose the SDLC which avoids or reduces the impact of the risks most probable in your case.


Rapid Application Development (RAD)

The intent of Rapid Application Development is to shorten the time required to develop the software application. The primary benefit from this approach is the elimination of change requests. The risks that will be the most likely to occur on a project using this methodology will have to do with the software applications fitness for use. The market or business could change during the project and not be able to respond to a resulting change request within the original schedule. Either the schedule will be delayed while the change is made, or the change will not be made resulting in the build of a system that does not meet the client’s needs.



The distinguishing characteristic of this development method is the lack of a project manager. This role is replaced by a team lead. The team lead may be a project manager, but it is unlikely that the performing organization will seek out and engage an experienced project manager to fulfill this role. The method avoids management by a project manager to avoid some of the rigors of project management best practices in an effort to streamline development. The risk introduced by this approach is that there will be a lack of necessary discipline on the team: change management, requirements management, schedule management, quality management, cost management, human resources management, procurement management, and risk management.


Iterative Methods

The main iterative methods are RUP (Rational Unified Process) and Agile. These methods take an iterative approach to design and development so are lumped together here. This method is intended to accommodate the changes to a project that a dynamic business requires.


Activity Specific Risks

Each activity in a development cycle has its own set of risks, regardless of the methodology chosen. The requirements gathering activity has the following risks: the requirements gathered may be incomplete, the requirements gathered may be misstated, or the requirements gathering exercise may take too much time.

The design portion of the cycle will have the following risks: the design may not interpret the requirements correctly so that the functionality built will not meet the customer’s needs. The design could be done in a way that calls for more complexity in the code than necessary. The design may be written in such a way that it is impossible for a programmer to develop code that will function properly. The design could be written in a way that is ambiguous or difficult to follow, requiring a lot of follow up questions or risking bad implementation.

Programmers may misinterpret the specifications, even when those are perfectly written, risking the development of an application that does not satisfy requirements. The unit, function, and system testing may be slipshod, releasing errors into the QA environment that consume extra time to resolve.

If you choose to work with us, we guarantee you that we will review your risk log regularly, especially before progressing to the next phase of the project. Our team will ensure that you are aware of the risks associated with the project.

Risks exist in all projects. At AHS, we Don’t skip the risk management process; failure to identify and document risks could end up killing the project. Creating, maintaining, and utilizing a risk register is a vital component of successful project management.


Marius Ion ANGEL HOT SOFT LLC (800) 316-7677