Risks coming in many categories!

Risks coming in many categories!

Some risks are fairly common. They pop up either as user stories, on risk logs or in conversations with team members. All risks need to be recognized, but not all risks are within the team’s ability to control or even influence. What a team can influence is how it reacts if a risk becomes an issue. Understanding common categories can help a team consider the risks they may face and whether they have considered everything they need to consider. A common taxonomy of risk categories is:

  1. Business Risk – Markets change due to changing tastes, regulations, and new discoveries, to name a few reasons. This is typically a difficult category of risk for technical teams to recognize, and is often recognized as changes and additions to scope. Inclusion of business product owner is useful to help a team to understand why change is needed and to provide leadership through prioritization. The groomed, managed product backlog is an active mitigation tool for this type of risk, HOWEVER business risk will exist for all projects.
  2. Technical Risk – Technology, like the business environment, evolves to generate risk. New projects that will require architectures and environments to be defined and implemented are fraught with risk (which is a reason many people buy commercial solutions rather developing their own). Maintenance and enhancement projects typically have the lowest amount of technical risk. Technical teams are generally adept at recognizing technical risks but are less adept at seeing when technical risks becomes an issue due to cultural biases. Agile techniques, such as short development cycles (sprints and program increments), test-driven development and continuous builds and integration, help to reduce technical risk.
  3. DevOps/Operational Risk – Many development teams and methods only play lip service or wait too late to consider how their software will fit within the organization’s operational environment. The organization’s operational ecosystem often includes operations, help desk personnel, IT personnel and business support personnel, such as training. Developing and testing a solution that no one can run or support is nearly meaningless. Barriers between organizational groups complicate recognizing and mitigating this category of risk in hierarchal organizations. Including DevOps personnel in project teams, in planning sessions (SAFe Release Planning, for example) and as active participants in demonstrations are mechanisms for reducing the possibility of this type of risk becoming an issue.
  4. Process Risk – Teams adopt and adapt techniques for delivering value based on organizational standards, environmental constraints and the problem they are trying to solve. Given that all projects have at least some unique characteristics, it is possible that the team’s common technique or the technique chosen may not be a match, causing risk. Consistent and honest retrospectives are useful for mitigating this risk and for minimizing the impact of process risks that become issues.
  5. Organizational/People Risk – Projects operate in an environment populated by people with all the possible caveats and footnotes that entails. The organizational/people risks can include personnel changes, dysfunctional office politics, conflicts for staff, multi-tasking and many others. Teams typically become blind to many of these risks believing that they can deal with these issues. Embracing stable teams and the Agile principles of self-organizing and self-managing teams are mechanisms for mitigating these types of risk.

Each of these categories can be further broken down to add focus on specific areas. Lists of risk categories and specific risks become less valuable when they are used as checklists that require each item on the list to be addressed. Having a set of risk categories is useful when they are used to direct thought and discussion about risk.

Advertisements