Project Management Book

"If project content is allowed to change freely the rate of change will exceed the rate of progress."

Chapter 11 - Change and Issue Management

At the start of a project there is always uncertainty. However well the requirements are defined, they will change as the project progresses. Issues will arise that were not foreseen.

What is an 'Issue' in the context of a project? A risk that has happened, something unexpected that has occurred, a potential problem that has come to light - in other words a threat to project success has been identified. We need to deal with these threats, not leave them lying around festering.

What is the difference between an Issue and a Risk? Some people will offer definitions and distinctions and argue their view with religious fervour. In practice what sometimes happens is this. Threats to project success that are identified at the start of the stage or project are called risks. Things that crop up during the project are handled as issues - though if a potential problem that wouldn't bite for 3 months crops up maybe that should be added to the risk register and handled as a risk whereas if the problem would bite in two days time maybe that's an issue. You can see how the arguments start.

Frankly it doesn't matter too much whether these things that crop up during the project are called issues or risks. What does matter is that they are managed.

In a small project the issue management process may boil down to discussing the issues in the weekly status meeting, assigning them to a person to resolve and documenting in the minutes the issue and its eventual resolution.

In one very large project the project office devised an electronic process for handling issues. There were 6 categories. Category 6 could be raised within a team and resolved by the team with nobody above the team leader being involved. But if a category1 issue was raised, as soon as enter was pressed an email went to the project sponsor - by definition category 1 issues required the sponsor to make a decision. The system produced excellent reports of issues raised by category, number open, number overdue resolution, average time to close, etc.

Whichever extreme your project is closer to the issue management process comes down to this:

Let's have a look at a sample issue form and illustrate the process with an example. Half way through the build phase one of the developers is about to write some code that will do a complex interest rate calculation. The calculation specified in the design document looks wrong to him. He's not quite sure so he raises it as an issue and completes the form as far as the 'Description of Issue' box.


Project Name:


Issue No:

Short Description of Issue:

Raised By:

Date Raised:

Description of Issue:





Resolution Comments:

Closed By:

Date Closed:

Issue Closing Agreed By:


No. of PCR (if one was raised as a result of closing this Issue):

Someone - maybe him maybe someone else - asks the relevant business person whether the calculation specified is right or not. If you're lucky the business person says that although it looks odd it is in fact perfectly correct. The resolution is a huge sigh of relief - there's no problem.

If you're unlucky the business person says the calculation has got completely garbled somehow and is completely wrong. The expert spends five minutes writing down the correct calculation. However, this represents a change to the signed off User Functions Design document and as such it must be managed as a Project Change Request. So the issue resolution is: the calculation is wrong in the UFD, this is the correct calculation, PCR number 735 has been raised.

A third way of closing issues is also possible. For example, the team is growing and was due to move into the refurbished canteen next week. But the refurbishment isn't finished - we have an issue. After investigation the conclusion is the refurbishment will be 3 weeks late and in the interim the team will colonise the sponsor's palatial office - that's how the issue will be resolved. You probably wouldn't raise a PCR for that.

So issues can have 3 closings:

One thing to watch out for on larger projects: make sure the person who raised the issue is satisfied it is closed. Otherwise, if the loop isn't closed like that, and they aren't happy with the closing they will raise the issue again under a slightly different title.

The form above is only an illustration - as are any forms to be found in project management standards or in a methodology text book. Before your project begins design a form that meets the specific needs of your project.

Project Management Book
Copyright M Harding Roberts 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
This book must not be copied either as is or in modified form to any website or other medium

Home   Sitemap   Contact Us   Project Management Articles   Project Management Book

Privacy Policy and Cookies