Home Project Management General General An Issue, An Issue, We All Fall Down!
US FTC Compliance
Yes, all these ads are some kind of affiliate link and I get paid a commission if you click or buy.
Not enough to quit my day job, but it keeps the site alive.
- Jeb Riordan, Editor, PROJECTmagazine
An Issue, An Issue, We All Fall Down! Print
If you’re lying asleep in a Sangria-soaked stupor and are woken by a mosquito buzzing around your room, the worst thing you can do is ignore it and go back to sleep: it is unlikely to ignore you. Something has to be done and someone has to do it.

You could shake your wife awake. She probably won’t like being shaken awake to kill a mosquito and is already unhappy about the Sangria. So you have to get up yourself and grope around for that fat paperback you keep meaning to read.

The boozy mosquito, drunk on a skinful of your blood, is still flying around the room but with ever decreasing vigour. ‘I know the feeling,’ you think and wait patiently for it to settle. This takes time and the bed you’ve just left looks softly tempting. You persist. The weary mosquito finally settles on the wall, dreaming drunkenly of the next large Englishman to come its way, and blind to the falling shadow of the paperback.

What are the most commonly used words in any project?
‘Resource’? ‘Plan’? ‘Budget’? ‘Disaster’? ‘Coffee’?
All get their quota of air-time, but none come close to the rich abundance of ‘Issue’.
Issues are as rife in projects as mosquitoes in a swamp. Loiter by any coffee machine, pop your head round the door of any Steering Committee meeting, eavesdrop on that harassed Project Manager’s 47th phone call of the morning, and you will hear the same familiar, sneezy sound.

So what exactly is an issue? If we use the word so freely, surely its meaning must be clear. It isn’t – and that’s the point - or the issue perhaps. The dictionary will say that its meanings include “a discharge or flux” or “an ulcer produced artificially”. I’m sure these may be relevant to some projects but meanings such as “a point in dispute” or “a question awaiting decision” are more likely to apply.
Even then, these are hardly precise.

In reality, Project Managers don’t tend to worry too much about the exact meaning of the word. I’ve always been comfortable with the vague understanding that an issue is anything you realise you may have to do something about. Put it this way, you’d find it hard to name which of 2000 possible species a mosquito belongs to, but you’d know it was a mosquito that had bitten you. Issues can be recognised in the same way.
So why do we get issues at all?

I’m fond of the expression “Life is what happens when you’ve made other plans”. This applies perfectly to Project Management if we modify the wording slightly to say “Issues are what happen when you’ve made other plans”.
A project is a plan to achieve certain objectives. A plan is a theory because it defines what should happen, not what has. Issues arise from the friction between theory and practice i.e. the difference between what actually happens and what was supposed to happen. The Project Manager must lubricate this friction by ‘exterminating’ issues and thereby allowing the plan to progress smoothly and swiftly. To accomplish this, the Project Manager must have control. Issue management describes this control.

Like chess, issue management is a complex activity with simple rules. Not everyone can be a Grandmaster but, by adopting some basic principles, it is at least possible to avoid losing the game in half a dozen moves.

Ignorance Is Never Bliss.

Never ignore an issue

Like a peckish mosquito, issues don’t often go away voluntarily. Always log them. For this, you will need an issue log.
The log can be anything from a humble spreadsheet to a magnificently engineered database to a list on a whiteboard. Choose whatever is appropriate for the size and formality of the project but ensure that the documented details for each issue at least include a description, a severity, who raised it and what is being done to resolve it.

Appoint an Owner

Just as someone has to get up and do something about the mosquito, so each issue logged must have an owner. The owner doesn’t have to be the person who works directly on the resolution of the issue but they do have to be responsible for supporting the process of resolution with clarification, technical information and policy decisions. They require, therefore, both knowledge and jurisdiction over the subject to which the issue relates. Ultimately, the owner will also authorise the proposal for resolution and confirm it has been carried out successfully. 


Clarification is an essential stage in the logging process. It’s pointless being told, for example, that “there aren’t enough resources”. Log the issue by all means but immediately return it to whoever it was raised by and demand more detail. Tell them the details you need. Why? How much? When? For how long? To do what? Use the owner to facilitate the clarification. An issue without clarification is a moving target and, given enough time and effort, will eventually be hit. The notion of ‘eventually’ should be an obscenity to any self-respecting Project Manager.

All Issues are Important, But Some Are More Important Than Others

All issues must be assigned a severity. The severity is dictated by the impact of the issue on the project and not the impact on the individual who raised it. If the mosquito feasts on me it’s important to me; if it regards the wife as the sweet trolley, it becomes critical.

Impact is best measured against the success factors of time, cost and quality. Could the issue cause a significant delay? Could it incur significant additional cost? Could it degrade the quality of the deliverables? Few projects that control these three factors well will fail.

The severity prioritises the resolution activity. For example, a standard set of severity levels would be ‘resolve immediately’, ‘resolve before go-live’, ‘resolve after go-live’ and ‘resolve at any time’. These levels are typically expressed as numbers 1 to n where 1 is the highest severity. More complex projects will require more complex structures of severity.

The Next Move

The next move is what is done next to resolve the issue.
Defining the first of the next moves is the concluding act of the logging process.
The first move on an issue is unlikely to be the decisive act of resolution but rather a pre-requisite action for this such as arranging a meeting - or getting out of bed.
No next move is complete without a target date for its completion and an individual tasked with carrying it out.
Equally, the results of the next move must always be documented to provide a trace of the resolution process.


The next move should be more than a good intention which succumbs weakly to the allure of inaction. Equally, once the next move is complete, further actions may need to be defined. Constant monitoring of the issue log is, therefore, essential. Patience is a virtue where issue management is concerned.

The frequency of monitoring for an individual issue is dependent on its severity. Those with the highest severity can require constant monitoring, others daily, some weekly and those with the lowest priority ‘as and when’.

Collective reviews of an issue log are only useful for reviewing overall progress and should never be used to define next moves for individual issues. To do so is massively inefficient since, for any single issue, most of the attendees have no useful input – although many don’t actually realise this.
Any monitoring must include a review of the severity. The severity can increase or decrease over time. For example, lack of a testing strategy may seem relatively insignificant in the early days of a project but will become critical by the time testing is due to begin.

The Only Good Issue Is A Dead Issue.

Sooner or later, the next move will be a proposal for resolution, and the paperback will be poised to fall. Issues have a powerful survival instinct. Closure involves an authorisation of the proposal by the owner, its execution and verification of the results again by the owner.

The most common ways of closing an issue are:

  • Add new tasks to the plan.

  • Defer any further action.

  • Merge the issue with another similar issue.


    Reject the issue on the grounds it has no impact on or relevance to the project.

  • Where the issue threatens any dimension of the project’s scope, convert the issue into a change request.


Closed issues should be archived out of the open issue log but never erased.

The message ‘This issue can now be closed’ should be as much of a relief to a Project Manager as the red smudge on the wall is to the weary holidaymaker. In both cases, a more peaceful slumber should be the least of the rewards.
It is my experience that the issue log is a more accurate measurement of a project’s state of completion than any plan. Plans are as easy to make as good intentions and as seductive as a glossy, holiday brochure. Issues are the raw reality.

Believe me - the project is only finished when the issue log is clear.

My issue log (and trusty, fat paperback) are always the first things I pack when I set off on a new project.

2001 © Peter Andrew

Comments (0)Add Comment

Write comment
bold italicize underline strike url image quote Smile Wink Laugh Grin Angry Sad Shocked Cool Tongue Kiss Cry
smaller | bigger

Copyright © PROJECTmagazine (c) 1998 - 2019 for practical project management information. All rights reserved.