Ad-hoc Issue Handling

At any time anyone may raise a (A.28) Project Issue which is recorded in the project's (A.15) Issue Log within the project's E.3 Quality File via Capturing Project Issues (CS3).

Project issues may be logged under a number of discreet headings: as a general enquiry, as an (A.18) Off-Specification or as an (A.33) Request for Change.

All forms of issue are all logged to the (A.15) Issue Log. Raising a project issue is the official method to ask any question or suggest any concern. Approving or otherwise deciding the response to a (A.28) Project Issue may need authority outside the current (team, stage or project) tolerances and so may trigger the exception handling process. Equally a change to a baselined product (IE One whose completion has been recorded and thus costs have been finalised) must receive the (B.1) Project Board’'s authority to approve the change irrespective of any tolerances or change budget that may cover the work.

How the board’s authority is sought for deciding changes was defined in Initiating a Project (IP). In Planning Quality (IP1) a suitable mechanism and possibly delegated authorities for change control were established within the project. IP2’s use of PL (PL4 and PL6) suggest the size of change and risk budgets.

The issue handling processes are the appropriate way to raise a new risk when the project is not engaged in one of the sub-processes with risk in their title (IE SU4[1], IP3, PL6 & SB4).

CS3 like CS2 is just an administrative logging and updating task. As soon as the project issue is logged Examining Project Issues (CS4) will perform Impact Analysis and update the project issue with the results for consideration in CS5.

Whether the project issue records a new risk or a Request For Change or Off-Specification the results of CS4’s assessment are inspected by the (B.5) Project Manager’s routine monitoring and control of the project at CS5 - One of the very few time-driven rather than event driven actions in PRINCE2®.

If there is no likelihood of exceeding tolerance and no baselined product is affected then corrective action (if any) is taken via CS7. Otherwise if corrective action is required that is beyond tolerance or to a baselined product a recommendation is prepared in CS8  (the (A.12) Exception Report) and reviewed by the board at DP4 (although the board may have delegated authority for the review to a separate Change Authority).

When reviewing the (A.28) Project Issue - of what ever specific type - The board may close the project down by immediate reference to CP or ask the (B.5) Project Manager to prepare an (A.11) Exception Plan by entering SB at SB6 for deliberations at DP3. DP3 may decide to ignore the issue, closing the project or authorise the amended plans for a resumption of the CS1+MP1, MP2+CS2, MP3+CS9->CS2->CS5->CS1 cycle.

Next Back To The Beginning For Another Look At Start-up


 

[1]      A slight cheat on the ‘risk in the name’ idea. SU4 is where the (A.34) Risk Log is created although it does not have ‘risk’ in its title. SU4 is the first task in the project aimed at the goal, so is formally the first sub-process charged with considering risk.