Issues are worth tracking

An issue is something that is raised by anyone on the project.  Issues are something that has been unresolved; is causing a problem; or that raises a question.  It is information that is incomplete.  An item that needs clarification or further investigation.  How do you track them?

Definition of ‘issue’

The dictionary defines an issue as “something proceeding from any source, as a product, effect, result or consequence”

In Prince 2 speak a Project Issue is “A term used to cover any concern, query, Request for Change, suggestion or Off-Specification raised during the project. They can be about anything to do with the project.”[1]

PMBOK define an issue as “A point or matter in question or in dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements.”[2]

These three definitions  added together describe what I class as an issue.

I define an issue as anything that is going to cause a problem with the ‘happy path’ to delivery.  Why do I say that, I find that issues come up when there are unanswered or unresolved items or questions that sit in the way of completion of the delivery in the way that is expected.

The value of tracking issues

I have found it very valuable to track even the smallest of items.  Why?  Because these are often the ones that slip through the cracks and they will be the one thing that will cause your project to fail at a key time.

It doesn’t matter if an item is on the issue register for all of 15 minutes.  The fact that it has been listed, tracked, captured and resolved is of benefit.  Later on in your project someone might ask if such and such has occurred, been considered etc., and by having that item on your issue register you are clearly able to acknowledge that it has been seen, and resolved.

This is especially true when you are asked by your project Sponsor or Business Owner to explain what and how a decision was made.  By going to your issues register, you can see what has occurred and the process of analysis that took place to gain resolution.

The ‘sticky’ items that are going to cause your delivery path to fail are best captured as issues, so that you are aware of them and can manage them.  Yes there is a difference between a risk and an issue, but my theory is, if an items begins as an issue and it is then considered something that will cause a risk to your project and is turned into a risk, that is great.

Remember, it is better to start with the issue, then consider the item a risk and log it, than not and it cause your project to fail.

You might find this presentation useful in helping you find and monitor your project issues.




[1] ‘Managing Successful Projects with Prince 2’, 4th ed.

[2] ‘A guide to the Project Management Body of Knowledge (PMBOK Guide)’, 4th ed.