Each Project Issue should be considered for its impact and alternative actions considered. Only then make a decision on which action is best.
The sub-process Capturing Project Issues (CS3) captures all of the Project Issues that have not been resolved.
During the sub-process Reviewing Stage Status (CS5) they should be reviewed and appropriate actions recommended for consideration.
An initial examination of a Project Issue should be performed as soon as it is logged.
All open Project Issues should be reviewed on a regular basis.
The Project Issues should reviewed against:
When this is done a decision can be made as to the appropriate action.
This would not be appropriate if the Project Issue raises and urgent matter needing immediate action.
This sub-process must also consider the wider impact of any Project Issues outside the project.
Should an issue be transferred elsewhere the Issue Log should record it as ‘closed’ with an appropriate note attached.
This may arise if the Project Issue is moved upwards to a programme for consideration.
To prepare Project Issues for the sub-process Reviewing Stage Status (CS5) the following steps are needed:
The Project Manager is responsible for this sub-process.
Members of the teams may be required to assess the impact of Project Issues on products, workload, cost, schedule and risk, and devise alternative courses of action.
Some of the administrative work may be delegated to a Project Support role.
Those with a Project Assurance responsibilities should be involved in the examination of the impact of Project Issues on the products, risk and the Business Case.
The Configuration Librarian, where appointed, will be responsible for maintaining the Issue Log.
Who makes decisions on the actions to be taken about the Project Issues depends on decisions made during the 'Initiating a Project (IP)'.
The Project Manager will have discussed the likely volume of changes with the Project Board.
They will have decided whether to make decisions themselves or delegate this to a change authority.
See Authority Levels in Change Control.
|Business Case||Input||Reference back to the Business Case to evaluate the impact of the Project Issue.|
|Stage Plan||Input||One of the bases for impact analysis.|
|Project Plan||Input||To check whether a Project Issue affects the project.|
|Issue Log||Update||A list of all outstanding Project Issues and their status, updated with impact analysis information.|
|Risk Log||Update||Current risks that may be affected by a Project Issue. To be updated if any action is recommended that will affect a risk or generate a new one.|
These are given in tabular form in the file ‘CS4 examining project issues.doc’ in the product package.
Time should be built into the Project Plan for experts to carry out the necessary impact analysis as soon as a Project Issue materialises.
Review of open Project Issues should occur regularly and frequently.
This sub-process and Reviewing Stage Status doesn’t have to be formally separated in small to medium sized projects, but information gathering / talking to the originator might be hard to do during a stage status review.
Urgent and important are not the same thing. Deal with urgent immediately and with important comprehensively.
Focus on the important Project Issues by filtering out the trivial items.
Give feedback to the Project Issue authors on any actions that arise.