Lava is not a risk category that is commonly encountered in software development.

Lava is not a risk category that is commonly encountered in software development.

I have recently been asking software development practitioners (including enhancements and maintenance) why they think that risk management is not consistently being practiced or practiced well. The group includes methodologists, developers, project and program managers, testers and test managers, operations personnel and executives. Very few have indicated that they thought that risk management was top of mind for any project, other than on an occasional event basis, or as one executive stated “when a project is asked publicly about risks.” The most common reasons why risk management is a second-class citizen include:

  1. There are too many other things to do directly related to delivering functionality. When asked why some project managers are perceived not to see the value in risk management, one respondent answered “They can’t when they’re working 12 hour days to keep the critical path moving.” This is a fairly common point of view. First, when you’re trying to do a twelve-hour job in an eight-hour day you will cut corners (add in multitasking and a disaster looms). Building risk management into the flow of work so that it isn’t a separate process with a separate risk plan and risk register should reduce the overhead generated when risk is an add-on to day-to-day project activities. A lean risk-management process will incorporate risk activities into team activities, but what needs to be addressed to mitigate the problem is the growing insistence on 50 – 60 hour workweeks.
  2. Risk management processes are driven by a need for an external certification. Many if not most of the people I talked with had a risk process, and if pressed could find a list of risks. However those processes and deliverables were developed for auditors and appraisers. In many cases the linkage between external frameworks, an organization’s expectations and policies (specifically for risk) have not been clearly linked to project outcomes. This is a common problem when teams are early in the adoption of Agile. Coaching is generally required to help teams develop the understanding that they will be able to deliver more value when then spend some time considering risks that could impact their ability to deliver. Coaches need to spend the time needed to help the team, organization or project manager to see the linkage between avoiding real issues and delivering value.
  3. Common risks are continually identified and nothing is done about those risks. Continually identifying environmental or long-term organization cultural issue that can’t be solved by team or the IT department is debilitating. In many cases what is being identified are issues that need to be mitigated or planned around. The example used above of project managers working 12-hour days to keep projects on track is not a risk, but an issue. Everyone involved needs to help address the problem the behavior will cause, unless the organizational culture can be changed and that is not something totally up to a team. Techniques such as sharing roles (team level self-organization) can be helpful to mitigate these types of issues. This is similar to issues seen in retrospectives that continually focus on issues that are not solvable (for example, a team that wants to work from home, but corporate policy forbids it due to security reasons). Over time a team will begin to feel helpless and will reject process. This, very simply, is a training and coaching problem.

One person noted that since risk management was not directly mentioned in the original book on Scrum, it must not be very important. I believe the comment was meant sarcastically, however it does make the point that risk management is only an issue in large projects or when project or program managers are involved. Risks and issues plague every human endeavor large or small, and must be addressed for effective and efficient delivery. Overburdened, multitasking teams need to be addressed as a rule. Incorporate a lean risk process into standard Agile or waterfall processes. Risks are just a different kind of user story or requirement that can be addressed in the common flow of work.

Advertisements