Project Management Book

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:

• Before the project starts design an issue process that will meet your project's need.
• When an issue arises write down what it is.
• Assign the issue to somebody to resolve. In a small project the project manager will decide who to give the issue to for resolution. In a large project that might be delegated to the team leaders - they decide which team member should be asked to resolve an issue.
• The person asked to resolve the issue does whatever it takes to get it resolved.
• Escalation paths must be open. The last thing you want to happen when the first major issue arises is not to know how to get to the sponsor - so you send him an email which sits in his inbox for a week. Before the project starts, agree with the sponsor and steering committee members how you'll get urgent issues to them - via their secretary, via a phone call? Get them to agree they will make timely decisions. (In one case this ground work hadn't been done. A key team member left, the PM identified a contractor with the same rare skills. An email to the sponsor asked for authorisation for the cost. It sat in the sponsor's inbox for a fortnight. When he eventually said yes the contractor had got a job elsewhere.)
• Write down how the issue was resolved.
• In status meetings monitor open issues and give particular attention to issues that are past their target resolution date. Occasionally what seems to be a minor issue is raised, given to a team member to resolve by Friday - but they don't resolve it by Friday - and what seemed to be a minor issue conceals a much bigger problem lurking underneath.

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.

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:

• there's no problem - phew.
• there is a problem but it has been sorted out like this...
• there is a problem which necessitates a change to a previously signed off project deliverable: the issue is closed, a PCR is raised and the change is managed under the auspices of the change control process.

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.

...next

Privacy Policy and Cookies