Making decisions is exhausting. It involves perception and analysis, and most of all: taking responsibility.
Mental load and the worry cache, Seth Godin, June 15, 2017

In most organizations, software development and maintenance is not a solitary activity.  Even a relatively simple enhancement require the involvement of multiple roles to identify, translate and implement an idea.  Teams are the tool used to effectively gather and coordinate all the needed roles in one place. While it is easy to perceive the team as a monolithic unit, every individual on a team is a decision-making machine.  Each person will have a different tolerance for uncertainty and ambiguity which will affect how they make decisions. (more…)

An obituary was written when a queen was interned

In keeping with a slightly morbid bend in storytelling techniques, we add to the premortem technique the idea of a business (or project) obituary.  An obituary is a specialized form of a news story that communicates the key points in the life or a person, organization, event or project. During my college years, I spent time in college radio stations on air both playing music and doing the news (where do you think the podcasting came from? Check out the Software Process and Measurement Cast).  In the newsroom we largely knew how to put together an obituary.  We kept a few critical local celebrities written and ready just in case (in the business, this is called a morgue).  Just like any story an obituary is comprised by a set of attributes.  A typical (simplified) set of components found in obituaries (Chapter 51 from the News Manual – Obituaries) includes: (more…)

Identify the risks before you start with a premortem.

Storytelling generates the big picture to guide a project or to help people frame their thoughts. A story can provide a deeper and more nuanced connection with information than most lists of PowerPoint bullets or a structured requirements documents. Storytelling can be used as a risk management tool.  Premortems are a useful tool for helping project teams anticipate risks.  Premortems were described in the Harvard Business Review, September 2007 by Gary Klein.  The basic premortem approach can be can be customized with storytelling to increase the power of the technique. (more…)

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 422 features our interview with Phil Lew.  Phil and I talked about the topic of Agile risk management.  We explored how risk can be managed in Agile projects and the barriers to effective risk management.  As important as the mechanics of Agile risk management are, Philip and I also explored the relationship between quality and risk, which may be more important in the long run.


You can't capture risk with your camera. You need to have a conversation with a diverse group of stakeholders.

You can’t capture risk with your camera. You need to have a conversation with a diverse group of stakeholders.

At a recent Q&A session I was asked: Where could a person get their project risks? I stifled a smart-alecky answer that would have included driving to the grocery store, and decided that the question that was being asked was really: How do I go about recognizing and capturing risks? Perhaps a more boring question, but far more important. If I answered the first question the answer would have been that risks are generated by the interaction of the project with other projects, applications, the business, technology and world (risk categories) – pretty much the existence of a project could be considered a risk magnet. The answer to the second question is that once you have a risk magnet (a project) you will need to ask as many different people as is feasible to recognize the possible risks. The discussion of risk is always appropriate; however, the typical meeting/events and the types of people to consider in the conversation needs to be planned. The discovery process typically follows the requirements/user story discovery process outlined below. (more…)


Risk tolerance can be visualized as a curve. Above the curve represents a combination of high probability and a potential negative impact that will prevent the team from accepting the risk. Below the curve, the risk is deemed acceptable.  Outside of a few psychologically damaged individuals, everyone has a risk curve (whether they know it or not). On a team, everyone’s natural risk tolerance differs.  Complicating the discussion is that risk tolerance changes depending on context the person or team faces.  For example, at one point in my life riding my bike down a hill at top speed to see if I could slalom stop at the bottom was an acceptable risk.  I have the scars to prove I was that silly. Thinking back, I am not sure why I am alive today.  My risk tolerance is different now. While reminiscing about my unsafe days as a seven-year-old is fun, what is more important is to recognize that the same lesson can be applied to teams and in organizations. This leads us to the conclusion that we must talk about risk tolerance.   (more…)

This is a risk I'm willing to take.

This is a risk I’m willing to take.

A risk is the potential or exposure to danger, harm or loss. The concept of risk is understandable to everyone involved in delivering work, at least at a basic level. We understand that “stuff” can happen when we least expect it to happen, in a project or in our individual lives.  The question is whether any specific risk or the accumulation of risks is worth taking action to avoid.  Which risks are perceived to be so daunting that they need to be actively avoided is based on personal and organizational perspectives and biases.  The technical term for this behavior is risk tolerance.  In response to Internal and External Risk, Matt Williams commented:

“An important step that I think often gets overlooked is the act of defining a risk tolerance.While many teams (or organizations) may have an intuitive sense of their risk tolerance, I think it’s helpful to have an explicit, conscious discussion about risk tolerance.”

We can define risk tolerance in simple terms as how much value are we willing to lose if a risk materializes.  The impact of a risk materializing and becoming an issue can range from rework, a reduction in returns, shifting positive perceptions or a compliance failure. A reflection of risk tolerance, in the financial markets, is the difference between the rates of return for a financial instrument (e.g. stocks, bonds, and others) and another financial instrument (such as a treasury bond). In finance the higher the risk the higher the return is required to balance.

If risk tolerance is important for the governance of software development and maintenance projects, we need a mechanism to define tolerable and intolerable risks before we decide how to ROAM risks.  Assessing risk tolerance is an evaluation of the willingness to take on risks and how much “exposure” from threats from outside the company are acceptable.

In a further comment Mr. Williams went on:

“I think risk tolerance is very context-specific. It depends in part on the organization – its size, culture, mission, etc. – in part on the project and its specific nature, and in part on the nature of the risk itself.”

Every person and organization has a different level of risk tolerance.  We can visualize risk tolerance in a chart as a curve. Risk tolerance is a balance between probability the probability a risk occurs and the impact that will be realized if it does occur.  In most software development and maintenance efforts defining the risk/tolerance curve is an implicit rather than explicit act.  The issue is that a team’s or organization’s level of  risk tolerance will cause different behaviors.  Risk avoiders, teams or organizations that fear the impact of risks, will tend to do more research or analysis before committing to a direction.  Risk takers tend to try approaches and then pivot if needed.

Risk tolerance affects how everyone in an organization behaves.  Rarely, however, does everyone in an organization have the same tolerance towards risk.  Defining or at least developing an understanding of a team’s risk tolerance isn’t merely an academic discussion.  Differences in risk tolerance can generate tensions and risks of its own, therefore at the very least teams need in the words of Mr. Williams, “have an explicit, conscious discussion.”

Current Risk Arc:

Internal and External Risks

Incorporating the Idea of External Risk into Agile Efforts

Risk Tolerance (Current) 



Next Page »