In the first part of this post, we discussed the challenges that issues present to every project.  In this post, we will review how to best establish severity of an issue and what process to follow based on that severity.

Establishing Severity

The people responsible for managing these issues must be able to quickly “triage” the issues and establish their severity. And just like an emergency room triage process, establishing the correct severity is critical to success. It is not always about what is bleeding the most; sometimes the worst problems are things that are not as obvious at first. The severity that the issue is assigned will determine how it is managed.

1. Crisis issues

  • A “fire”, this means that nothing else matters until this is resolved. The process here is to throw every person we can make any difference at getting this fixed as quickly as possible.
  • The problem a fire is that, by its very nature, we are looking for the fastest way to resolve the issue; this may result in the solution not being the best solution for the long run. But because of how critical the issue is, that is a valid trade-off as long as everyone recognizes that this trade-off is being made.

2. Urgent issues

  • An issue that is causing the business significant concern at this point in time.
  •  These are the most difficult issues to triage, because the trade-off for a quick fix versus a complete solution is often not the best decision, but because of the discomfort being felt by the business, we tend to want to react quickly and not consider the longer term options.
  • Frequently, the work done on an urgent issue ends up causing more problems later, and this may result in more fires.

3. Important Issues

  • This is work that needs to be done to improve the business and resolve long-term concerns. This is where we want to spend our time and energy if at all possible. These are often important or even vital to the business but they may not always have the urgency of some of the other issues.
  • If we always let the “crisis” or “urgent” items take precedence then we don’t have time to work on these kinds of issues and the business loses out on the benefits that come from working these more strategic items.
  • Important issues do not necessary require dramatically more effort. If these kinds of issues are considered in a more reasoned way, with better communication, and better visibility into the objectives and business direction, they can be more complete solutions.

Process

Each of these issue severities demands a unique response process.

For example, a crisis needs to be handled with speed and efficiency and although communication and coordination are still important they are not the principle concerns.

After the triage takes place to establish the correct severity, here are the basic processes that should be used to manage the issues:

Step 1: Identify the issue

Step 2: Triage performed and severity established

Step 3: Issue worked on based on established severity

 

Severity specific processes:

1. Crisis Issues:

a. Stakeholders and vendors notified of issue
b. Solution identified, developed, and deployed as quick as possible
c. Document the causes, effects, and solution
d. Postmortem to identify what can be done to prevent this kind of fire from ever happening again.

2. Urgent and Important Issues:

a. Stakeholders and vendors must establish priority of this issue compared to all other Crisis, Urgent or Important Issues that are already under way. This priority is used to establish sequence for when this issue will get attention.
b. Stakeholder, business experts, and vendors should define a solution to meet the business needs. It is important to document the causes of the issue, the effect the issue is having, as well as proposed solution.
c. Approval to proceed given
d. The project team must be identified, both from the vendor as well as the business
e. Schedule should be determined
f. Solution should be developed and tested *
g. Solution communicated as necessary to all users *
h. The business must validate the solution *
i. Solution deployed to production *
j. Project team, stakeholders and possibly users review solution and process and identify ways to improve. *

* Note: if running this process in an iterative fashion (for example using agile development practices) steps f-j could be repeated multiple times.

Some additional points regarding severity

Often less experienced project teams classify many issues as a crisis that should not be. If you have too many issues classified this way, it is likely that you are defining it too broadly. Ask, “Is this issue so important that I need to stand up and yell to the whole team, we have a crisis! We need everyone to drop everything right now!” If it does not warrant that kind of response then it should not be classified as a crisis. Crisis issues need to be managed in a way that is different from other issues, they bypass some controls and this can cause other problems if this is happening too often.

It is tempting to want to manage Urgent and Important issues as if they are separate kinds of issues, but this would be a mistake and introduce other problems. If you are not always comparing urgent and important items against each other, you will quickly forget the important issues and only focus on urgent things.

The critical points in managing issues is to establish clear roles and responsibilities, have a clearly defined and simple triage process and then follow the process every time. And as with everything in business maintaining clear communications is always critical.

Issues will happen. Acknowledging this up front and preparing for them will make it much easier to manage them when they happen. Take control of your project!

What strategy do you use to establish severity and priority of the issues that arise in your projects. What happens if you don’t have a strategy in place?

Every project you undertake will have issues. That is one absolute for every software project.

On a recent project, we as the project team were having difficulty getting the business to give us actionable feedback. This was having two effects; First, it was causing the business to feel frustrated that the project team was not addressing their concerns quickly enough, or even addressing them at all. Second, it was causing the project team to feel frustrated because we did not feel we could successfully resolve the concerns because we didn’t know the concerns or we did not know the priority of the concerns.  My suggestion to this team was to establish some clear governance that would allow us to respond together to resolve these issues.

For every project you work on, either during the project effort or after the work has been released into the wild, issues will arise. Here are some of the reason issues come up;

  • Something does not work as designed – often called a bug or a defect. Not surprisingly, this is the kind of issue we spend most of our time trying to prevent. It turns out in the long run, these usually are the easiest type to deal with.
  • Something works as designed but it turns out what was done was not actually what was intended
  • Something is missing in order for the solution to be complete, perhaps an aspect was overlooked or just not understood during at the early phases of the project
  • The work that was done has introduced new ideas, new opportunities, or perhaps new complexities that now must be addressed.

All of these need to be reviewed, prioritized, funded, developed and then delivered. And after they are delivered, each of these changes could introduce a whole new round of issues.

It is important to manage the responses to these issues in a controlled and consistent manner. In every case decisions on how to respond to the issue need to be made. There are many aspects that need to be considered in these responses; impact on the business, priority of the issues, cost, effort, visibility, risk and schedule.

Roles and responsibilities

In order to execute the correct response to each issue some specific roles, responsibilities and processes need to be in place:

  1. The team of people who have authority to determine how to respond to these issues must be clearly identified.
  2. The business must communicate the strategic objectives to the project team.
  3. Collaboration and communication with all stakeholders, project team and users
  4. Fact-based decision-making
  5. Clear priorities
  6. Clear schedules

With these in place there can be:

  • Better control
  • Faster response
  • More satisfied users (both internal and external)

In the next post we will discuss a way to classify severity and how to ensure issues are responded to with correct processes.

Have you experienced projects where correct governance was in place and it benefited the project, how about the opposite?