A Proposal for an Automatic Indicator for Issues

Intro

Some people do not like issue management; to them it is constant firefighting. These people prefer risk management over issue management. The truth is indeed that if you do risk management perfectly, you will not need issue management. On the other hand, if you do issue management perfectly, you will still need risk management, since you will still end up with some risks that cannot be (entirely) mitigated in the last minute and the residual impacts from these risks will become issues.

Issues are often qualified in terms of their priority. For example, it is more important to avoid a collision with a car in front of you right now than it is to improve your driving skills on the longer term by learning to avoid texting while driving.

Priority is a term that has two components to it: (source: Merriam-Webster dictionary)

• Right to precede: matters of high-priority need to be dealt with first.
• Importance: because the matter is important, it needs to be considered.

As you can see, this term has two different dimensions to its meaning.

Risks have two dimensions as well; they are measured in terms of impact and probability. Since an issue is a risk that materialized, we could also measure issues in terms of impact, just like we do for risks. The impact from an issue can be on the scope, quality, cost, time or resources of a project. Also, the original impact has been managed and decreased by risk mitigation, so an issue will have the residual impact of its related risk. The risk left over after mitigation is the residual risk, which could turn into an issue if not taken care of. In this article, we have chosen to use the term priority to qualify issues, but you could replace it with (residual) impact. However, if you do so, you will lose the dimension of the right-to-precede, which is also captured in ‘priority’. I think it is important to measure the right-to-precede as well when measuring and managing issues.

The Challenge

Over the years, I have been struggling to automate a traffic light for issues. I could not figure out how to summarize a list of tens or perhaps hundreds of issues into one, single traffic light: green, yellow or red. Here is what I did know:

• Executives prefer automated key performance indicators over manually set indicators. I have personally observed that the management layer in the middle “greens” the project status reports. Middle managers insist that the report is first signed off on by them before publishing, which gives them a chance to censor the message they send up the tree. The practice of “greening” tends to be very contagious; after all: Would you like to be the one and only project manager who presents yellow and red projects to executives? The practice tends to spread like an epidemic in organizations. In the end, executives have to look at one green status portfolio report after yet another green status portfolio report. Executives tend to lose interest in such non-information. One executive once exclaimed to me: I am sick and tired of looking at reports that are always green! They stop looking at these reports and prefer to spend their scarce time in talking to some workers at the bottom of the project to get a real sense on what is going on in a project, therewith skipping and ignoring the middle layer of management.
• Executives love the risk grid. Here is an example of a risks grid:
  
• It gives them a very good sense of:
  • How many active risks are floating around this project? This is the sum of all counts in each cell: 2 + 2 + 1 + 1 + 3 = 9
  • What are the most pressing, active risks in this project? The high-probability and high-impact risks, the red risks. Often, the top 3 risks are shown in all their detail on the dashboard: e.g. description, mitigation plan, and residual risk.
  • How much pressure is this project experiencing from the risks they perceive? Four out of nine active risks are red in the red area, so this project manager is, relatively speaking, experiencing a high level of risk.
• Executives love solving issues, it is what they are good at and have been promoted for … many times. So the cream of the crop of issue resolvers are at the top of our organization. We need to feed their hunger for issues to resolve, so executives can also go home at night with the feeling they actually contributed something to their organization that day. As project managers, we need to feed the beasts that we (may) have come to fear. Ever been to a zoo and looked lions or tigers in their eyes?
• There is already one dimension of issues captured that presents its relative importance: Priority. Often this priority is categorized as: low, medium or high. What that means is often not clear, but organizations have operationalized this often in their own way. Here is one way of operationalizing them I have come across:
  • Priority = Low = On track. Achievement of the intended business outcomes is expected.
  • Priority = Medium = Some course correction likely required. One or more of the intended business outcomes may not be achieved unless some course correction is implemented.
  • Priority = High = Significant course correction required immediately. One or more business outcomes are in jeopardy. The identified threats will negatively impact scope, quality, cost, and/or schedule unless swift and effective course corrections are undertaken.

The Question to Answer

So, the question I have been struggling with is: What are the issues that executives want to know about (apart from the issues that are marked as high-priority)? When should the light be red to summarize a long list of issues? If we leave the coloring of issues to project managers who will be censored by middle managers, the real issues will never reach the top and we will not be feeding the “beasts” at the top.

Last night, my unconsciousness came up with a solution for this problem. I woke up in the middle of the night and realized that the issues that should be escalated automatically are the issues that live too long. After all, an issue is a risk that materialized. The issue is doing harm to the project when it is active. The longer the issue is active, the more harm it can do to the project. For example, the project I am currently on, a Project Server 2010 implementation at one of the largest Federal Government Departments of Canada, was slowed down by not being able to find an SQL-developer with the right skillset. This was identified as a risk early on and was taken on by people who thought they could find someone, then, when that did not work, the risk got stuck in procurement-hell, when finally unstuck, the risk had turned into an active issue and was now affecting the project. The procurement produced Oracle-SQL candidates instead of Microsoft SQL developers, and when the right SQL developer was finally found, he was not immediately available and on and on and on. So, the age of the issue increased and the issue became a high-priority issue; it started to affect our deadline accomplishment. It also started to affect morale among project team members, as well as our credit with executives (who, ironically, did not help resolve this issue). It even started to increase the cost for the department beyond our project as a negative business outcome, because a lack of an automated report meant that project managers would have to generate their project dashboards manually once again instead of in an automated way. This would waste again hundreds of person hours for the department, be very expensive and produce censored reports.

So, issues need to be addressed sooner rather than later, because the longer they exist, the more harm they do. They can even kill a project, program and even a policy-initiative on the national level, just look at how much damage the poorly functioning website HealthCare.Gov has done for Obama-care, which may have never been raised as a risk, but smacked the president as a forceful issue.

My Proposal for Handling Issues

Considering the previous discussion, I would like to propose to you as a practicing project manager that we measure an issue in terms of (priority and) age and that we score each issue on its relative age: low, medium or high. How can we do this?

• The age of the issue is the difference between today and the date is was created (automatically created by the system). The date an issue is closed by the project manager is not needed because you do not want to see closed issues in the grid anyways; they are like water under the bridge. When an issue is closed, it is ejected from the grid.
• We can look at the entire list of issues and calculate the average age of an issue within our organization.

For example, our company, EUSSI, has an issue database that contains 1000 issues (closed or open) and the average age of an issue is 6 weeks. Now we cut this average age in three intervals for the categorization of issues into low, medium and high: I propose that you categorize an issue as follows:

• Issue lives shorter than one third of the average age as low age.
• Issue lives between one-third and two-thirds of the average age as medium age.
• Issue lives longer than two-thirds of the average age as high age.

Therefore, the maximum age at EUSSI for low-age issues is 2 weeks, for medium-age issues between 2 and 4 weeks, and, for high-age issues, greater than 4 weeks.

One of EUSSI’s projects, named Conversion to the Cloud, has an issue register with 30 active issues. The register looks like this:

• 1 high-priority issue of 1 day of age: low age.
• 4 medium-priority issues of 1 week of age: low age.
• 10 medium-priority issues of 3 weeks of age: medium age.
• 13 low-priority issues of 5 weeks of age: high age.
• 2 high-priority issue of 4 months of age: high age.

At this point, you can construct an issues grid similar to the much-loved risks grid that presents an overview of all, active issues:

Some reviewers of this article observed that if you use the same risk grid as is now globally accepted practice and you transfer that as-it-is to issues, you ignore the fact that issues have different dimensions than risks and this forces us to think critically on what an important issue is (red issue). A high-priority issue should always be on the radar screen of executives and should, therefore, be red all the time.

If we incorporate these two insights, the following issues grid emerges that I labeled Red-is-Bad (coincidentally similar to the flag of Bolivia):

This grid communicates to executives:

• How many issues are plaguing the project? This is the sum of all counts in each cell. It says something about if the issue register is used (there are active issues at every reporting period). The total also says something about how much pressure issues exert on the project. Personally, I would rather be part of a project with few issues than one with hundreds of issues and a constant fountain of new issues showering the project.
• How many high-priority issues are there? The number of high-priority issues tells you what the level of fire-fighting is the project manager and his/her team currently are doing or need to do.
• How quickly are issues resolved by the project manager? As time goes by and issues are not addressed, they float automatically from the left to the right in the grid. If an executive sees a bow-wave of issues on the right-hand side of the grid, the executive can rightfully conclude that the project is slowly, but surely drowning in the issues. This drowning may look like this: many issues are in the cells on the right-hand side in the grid with a much lower flow of new issues drifting in from the left as can be seen in this Bow-wave Issue Grid:

Back to the design of our issues dashboard: The only problem that remains is: How can you summarize our initial issue grid of 30 issues (named Issues Grid) into one traffic light color that is either green, yellow or red? One way might be to look at percentages. There are 4 green issues, 24 yellow and 2 red: total 30 active issues:

• % green: 4 / 30 = 13.3%
• % yellow: 24/30 = 80%
• % red: 2/30 = 6.7%

These percentages give some indication what the overall status of the issues might be, but does not provide a way to easily summarize all issues into one light that is green, yellow or red. The high percentage of yellow may suggest to turn the traffic light to yellow.

The same summarization has been done already for risks and we can use the same way for accomplishing this for issues. One way I have used in the past originates from the Government of Canada (pretty smart people up North here!). The idea behind it is that you are most concerned about red issues. First, you convert the number of red issues into yellow issues using a weighing factor that you choose. For example, you could weigh a red issue twice as important as a yellow issue, so the total number of converted-to-yellow issues for the Issues Grid is: 4 red * 2 + 24 yellow = 28 converted-to-yellow issues in the context of 4 red issues. The color for the issues will now be determined using the following rules (as per the Government of Canada):

• If the number of red issues is less than 40% of the total number of converted-to-yellow issues, the issue dimension of the project should turn green.
• If the number of red issues is between 40% and 60%, the issue indicator should turn yellow.
• If it is more than 60%, the issue indicator should turn red.

In this case, the health indicator for the issues is: 4 red issues out of 28 converted-to-yellow issues = 14% and, thus, the light should turn green.

Let’s follow an issue through its life in an imaginary organization EUSSI. EUSSI has thousands of issues (open and closed) in its database with an average life of 6 weeks. We can divided this average life into three even segments: low: age of issue < 2 weeks, medium: age between 2 and 4 weeks, high: age is > 4weeks. Team member Joe raises an issue on Nov 22, 2014 within our EUSSI organization; he suggested that the late arrival of new server computers that were already ordered may delay the installation by two weeks and delay the whole project by one week. The issue is conveniently ignored for some time by people who are all very busy and they only notice the issue one week later. Using the average life of issues in EUSSI (6 weeks), the age of the issue is still low. A meeting is scheduled one week later. At the meeting, the issue has already turned yellow because its age is now two weeks. In the meeting it is decided that the project manager will call the supplier to explore speeding up the delivery. The supplier is working many clients and cannot speed up. The project manager discusses the issue with his superior. Alternative suppliers are contacted. No alternative suppliers are found, the issue has now been ravaging for 4 weeks and turns automatically red, which puts the issue as high priority and high age in our issue grid and turns red which draws the eye of our executives. Executives are getting involved. They pull their weight with their contacts at higher levels in the suppliers’ organizations, they scold the initial supplier and conclude that the best option is to pay a small premium switching to another supplier who can deliver earlier. The issue is resolved after a ripe life of 6 weeks and is then closed off by the project manager; it disappears from the issues grid.

I hope you like my suggestion to monitor the age of issues. Since this is a NEW way of working that I propose here to you as project practitioners, please, leave your comments below. I look forward to them!

Eric Uyttewaal, PMP, MVP Project