prince2 issue management demystified€¦ · prince2 issue management demystified 3 | setting up...

PRINCE2 Issue Management Demystified

1 www.prince2primer.com | www.projex.com


www.prince2primer.com

Dave Litten

PRINCE2 Practitioner and Certified Trainer

http://www.prince2primer.com/

http://www.projex.com/



Contents Setting up the Issue Register ......................................................................................... 3

Defining a project issue ................................................................................................. 3

The three issue categories ............................................................................................. 3

Request For Change (RFC) ............................................................................................. 4

Off Specification (Off-Spec) ........................................................................................... 4

Dealing with a Concession ............................................................................................. 5

Accept it now – Fix it later ............................................................................................. 5

The steps to managing an issue ..................................................................................... 5

Step One – Capturing the issue ...................................................................................... 5

The Issue Register ......................................................................................................... 7

Step Two - Examining the issue ..................................................................................... 7

Step Three – proposing action ....................................................................................... 8

Step Four – deciding the actions .................................................................................... 8

Step Five – implementing the work ............................................................................... 9

Dealing with issues ..................................................................................................... 10

The Issue Report ......................................................................................................... 10

The Highlight Report ................................................................................................... 12

When an issue needs stage correction ......................................................................... 12

The relationship between issues and risks ................................................................... 13

The Business Case ....................................................................................................... 13

Reporting an exception ............................................................................................... 13

The Lessons Report ..................................................................................................... 14

The Issue Register and follow on action recommendations .......................................... 15

Video Modules – PowerPoint slide Graphics ................................................................... 16

Check out my other Project Management Primers: ...................................................... 33





Setting up the Issue Register

First up, an issue is a communication from anyone with an interest in the project straight to

the project manager at any time and about anything.

The subject matter of the issue may be to request that something be changed, or it may be

to report a problem, perhaps it is to put forward a good idea.

Once the project manager receives an issue, they must make a decision about whether or not

to deal with it formally or informally.

If the project manager’s decision is to deal with it informally, they simply record this in the

Daily Log, which could be seen as a project diary.

However, if the issue needs to be managed more formally, then the project manager records

the details on an Issue Report and then keeps track of the issue progress with entries in the

Issue Register.

Defining a project issue

A project issue is a communication from anyone in the project or anyone with an interest in

the project and it is sent directly to the project manager.

An issue can be sent to any time during the project and it can be about anything, in particular

it does not have to relate to change.

As soon as the issue is received it is logged in the Issue Register so that it can be tracked or,

if the project manager makes a decision that the issue should be handled informally, it is

entered into the Daily Log.

If It is entered into the Issue Register, the project manager first records the full detail of the

issue on an Issue Report.

The word of caution here. There may be those within your organisation who want to try to

influence everything and the project manager may get bombarded with lots of issues. One

way to resolve this and avoid overloading the project manager, is to agree that anyone

outside of the project raise such issues to the senior user and only then if it is agreed that It

is entered as a formal issue.

The three issue categories

PRINCE2 Has three categories of issue even though you would want to process them in exactly

the same way, and by this I mean record them and track their progress until they are resolved.

Let me deal with each issue category in turn:





A general issue or “Problem /concern/opportunity “

The use of the term “Problem/Concern” can mislead some folks because of the negative

connotation the word concern gives as being bad. However, an issue can be about anything

at all, not just bad situations. Issues can also be a good ideas or questions.

Request For Change (RFC)

An RFC is a type of project issue where someone wants a change to a product that is already

under change control since it has been baselined. The term baseline Is a configuration

management term and means that the product has been quality checked and signed off.

An RFC can be submitted for a specialist product that a team has built, or a management

product, for example the Business Case that you use to help manage the project.

Once a product has been baseline and, any change must go through the formal change control

procedure. This is obvious really because there is no point in quality control staff carefully

checking a product against its quality criteria and then signing it off if someone else and then

complete the change it a few minutes later.

After a product is quality checked and signed off, nobody is allowed to touch it except under

change control. This is equally true even if someone has a good idea for improvement and it

may not take long to do.

Off Specification (Off-Spec)

The term off specification means that the product has failed to meet its quality criteria during

testing and that you cannot easily correct the problem. An off specification could be raised

even before the product is tested in a situation where the team can see that the product is

never going to meet its quality criteria.

You may be thinking that if a product does not meet its criteria and it fails its test, the all you

need to do is to take it away on work on it until it does meet the standard and passes the test.

Although a reasonable thing to do, it may not always be that easy.

It may be that the correction is going to take some time and that time tolerance would be

exceeded, or perhaps the resources are no longer available, or that obtaining resources is

difficult, for example some components used within the product are no longer available.

So the usual case is that an off specification is for a product that has not met its quality criteria,

but sometimes it can be because a product exceeds its specification which may also cause a

problem.





Dealing with a Concession

On occasion, it may be the right thing to do to accept an off specification rather than try to

correct, or redesign the product in some way. Just accepting the product as it is may be the

best option for many reasons including time or cost. Such a situation within a PRINCE2 project

is called a Concession.

Most of the time, it will only be the Project Board who can sign off a Concession. But what

about highly technical projects where the Project Board’s experience may not be sufficient to

make an informed choice?

In such a situation it may make sense to delegate Concession decision-making to the team

manager or possibly even a team specialist. If this were to be the case, the Project Board

would merely be “Rubber stamping “such an evaluation.

Accept it now – Fix it later

This is often a decision that needs to be made in the real world. The way to approach this is

to combine a Concession with a follow on action – Which in turn allows the situation to be

managed as a temporary Concession.

This would be a smart move particularly if you don’t have time to correct it without missing a

key delivery milestone. You would make a Concession and accept the product knowing that

it is only a temporary fix.

You would need the supplier or technical team to provide a new reworked product that does

meet its quality criteria and come back after some time, maybe even after the project has

finished, and get it accepted.

You would pass the follow on action to a manager in the organization who would then take

responsibility for it after the project, and is committed to ensuring that the supplier provides

be improved product.

The steps to managing an issue

Step One – Capturing the issue

The first decision the project manager must make is whether the issue should be handled

formally and tracked, or informally by making a note of it within the Daily Log.

If the issue is to be handled formally, then the full detail will need to be recorded in the Issue

Report and then recording the tracking information of who sent its, its current status, etc.

within the Issue Register.





It is important that you see the Issue Register as a control document. It provides an overview

of all the current issues shown when each was received, what action is being taken on each,

and whether or not it has been resolved.

The Issue Report records to full detail of each single issue. For experienced PRINCE2 team

managers, you could ask them to submit any issues in the Issue Report format by completing

as many sections That they can. Whether this information is then copied on to the Issue

Register or the Daily Log does not matter.

A summary of the control information within the Issue Report is copied into the Issue Register.

Here is an overview of the sections contained within an Issue Report:

Issue identifier. This is a unique reference, sometimes just a number other times

alphanumeric.

Issue type. Here you state whether it is an RFC, An off spec or A problem/Concern.

Date raised. This is obvious I hope!

Raised by. This is normally the name of an individual although it could be a team or group

Issue Report author. This is normally the project manager but could be a team manager or

an individual

Issue description. Here you detail the issue including the cause of the problem along with

the Issue impact using one or more of the six PRINCE2Control areas of cost, time, quality,

scope, risk and benefits

Recommendation. This will be a scale as laid down during initiation and recorded in the

configuration management strategy document. It could be as simple as high, medium, or low

or to use A phrase such as “Essential “Through to a “Nice to have “

Severity. Once more, this will use a scale as identified within the configuration management

strategy, in addition the severity could indicate who is authorized to make a decision on the

issue.

Decision. This refers to the outcome, which may be to reject a Request For Change, or to

make a Concession on an off specification.

Approved by. This gives information on who made a decision which could be the project

manager, the Project Board, or even the Change Authority if you have one.

Decision date. Obvious I hope!

Closure date. It may be that an issue situation where no action has been taken in which case

the closure date will be the same as the decision date. But where action was needed, it will

occur at some point After that.

The Issue Report covers all of the information on a single issue and that includes the action

taken on it. A summary of the control information is also dedicated in the Issue Register but

slightly modified as I will describe shortly.





The Issue Register

This is a control document that gives an overview of all issues and will repeat much of the

information as described within the Issue Report:

Issue identifier

Issue type

Date raised

Raised by

Issue Report author

Issue description

Priority

Severity

Status. This was not included on the Issue Report although it could be if you wish

Closure date

A point to consider here is that the severity and priority ratings may not be known at this

point until the next step when the issue is examined. In such a case simply make your best

estimate at this point in time and be prepared to come back and modify it after further

examination.

It is often the case that the person who raised the issue will be emotionally motivated and

overate its true status.

Step Two - Examining the issue

This should involve all appropriate individuals not just the project manager. These individuals

could include team managers, team members, specialist contributors, Or even external third

parties such as suppliers.

Be careful about involving Project Assurance here as that may detract from the impartiality.

Remember that Project Assurance provides an audit function independent of the project

manager.

There are several impact areas that should be considered, and the following list give you some

ideas for those that should be included when examining the issue:

Costs

Risk

Quality

Business benefits and project justification

Time scales for the stage and project Including any knock on effects to future stages

Any impacts on a program or other related projects





Staffing levels and staff availability

A point worth considering here when planning the project with in the initiation stage, is

whether you predict and expect many changes to occur. In such a case it would be smart to

include resources and time in your plans for issue impact analysis.

Step Three – proposing action

There are three levels of decision-making authority here, the project manager, a Change

Authority if you have one, and the Project Board. Such actions if beyond the project

managers delegated authority needs to be proposed to ever is authorized to do so.

Exactly who that authority should be, falls to the Project Board. During initiation, the Project

Board must decide how much authority, and what type they are prepared to delegate to the

project manager, and this includes a clear definition of the point where the project manager

must come back to them for a decision.

Very often this decision point is cost or budget. The way to do this is to set a band of cost

where if any issue action occurs within it, then the project manager can make the decision.

Any point above that and it will need to go before the Project Board.

But there is another dimension to this, as some decisions although falling within the authority

banned described above, may have operational consequences that the Project Board need to

be involved in.

Step Four – deciding the actions

Such actions would be entered into the Issue Register and all the relevant Issue Report. If the

issue has been escalated to either the Project Board or a Change Authority in the decision will

be taken at that level.

The decision could be a simple as a “yes or no “, but it may be an agreement to defer a decision

until they obtain more information. In such a situation the project manager will collect the

information and return for a decision.

Such a deferment could be to review it later in the current stage, or if nearing the end of the

project, there is sufficient funds left in the Change Budget, or it could be done in a later stage,

or even to be done in a future project.

If the latter action is decided, then the follow on action would be used and passed to a

responsible role to carry that through after the project has finished.





Step Five – implementing the work

If a decision is made to proceed within the project, then the project manager needs to manage

this.

It is often the case that some form of re-planning is needed within the Stage Plan or a Work

Package. Once the work is complete, the issue can be closed down within the Issue Register

and the Issue Report, or if it was being managed informally, within the Daily Log.

I have mentioned a Change Budget, and it is worth mentioning how that is set up.

It can be set up an authorized on a stage by stage basis, or for the project as a whole.

A Change Budget is a good idea as it will allow the project manager to accommodate any

unforeseen changes without having to constantly go back to the Project Board to approve

every single change no matter how small it is. Such a point should be made clear to the Project

Board if they are hesitant about approving a separate Change Budget.

Another option the Project Board has during the initiation, is to appoint a Change Authority

who would act on their behalf to manage and deal with any changes. This would free up the

Project Board to direct more appropriate areas rather than tie them down to long and

detailed meetings concerning the approval or otherwise of changes.

Whenever any form of delegation regarding changes is agreed, it is important that the “rules

of engagement “are made clear to all those involved.

I want to make one other point here, and it could be a better approach rather than just

implementing issue resolution actions.

This is particularly useful for complex issue resolution actions. The option I’m talking about is

to create an Exception Plan that replaces the rest of the current stage plan. The project

manager would produce a new plan showing all the work necessary to implement the change

and then presented to the Project Board for approval.

In summary then, the Issue Register is ready to use to record the existence, the progress and

the outcome of issues that are being handled formally within the project. The Issue Register

is maintained and used throughout the whole of the project and is Included within the last

delivery stage of the project.

Indeed, the end project report contains in the ongoing issues that need to be passed on to

operational management rather than be dealt with during the project before closure. These

are called follow on actions. The lessons learned report which forms part of the end project

report, will include any lessons learned from specific issues or their management throughout

the project.





The contents of an Issue Register are fairly logical. You would need to record who sent the

issue, when it was cent, a brief description of what the issue is about, the current status for

example under review, and finally when it is closed. This last point is important as it advises

you which issues have been resolved and which ones are still being worked on.

The Issue Register is set up in the initiation stage, ready for use in the delivery stages. Indeed,

there really is no problem in setting the Issue Register up at the very start of the initiation

stage as there may be several issues raised during that time which require formal resolution.

As you can see, when handling issues, it is not always just about problems, but also good ideas

as well. The exact procedure that you use for formal issue management should be laid out

clearly within the configuration management strategy created during the initiation stage.

Dealing with issues

As the project manager you can expect to receive project issues – often many of them.

Although within PRINCE2, Issues are covered under change control, it is important that you

understand and issue needn’t be anything to do with a change. For example, perhaps a

member of the team is passing on a good idea.

Remember that an issue can come from anyone within the project or anyone with an interest

in it. It can be sent in are any time and can be about anything that is relevant to the project.

As a project manager, when you first received an issue, you need to make a decision about

whether to deal with it formally or informally. If the latter, then you can simply note it within

the Daily Log.

It may be that It is an issue that needs to be dealt with formerly and therefore needs formal

tracking. In this case the Issue Register is used. Your first action having entered it into the

Issue Register is to then transfer the details of the issue into an Issue Report.

The Issue Report

This is a formal record of an issue that is normally created by the project manager upon

receipt of an issue. But be aware That it may have come from someone within the project

and that they have already written an Issue Report and use that form to submit the issue in

the first place.

Once you have recorded the issue, your next task is to see what action if any you need to take.

This is sometimes called impact analysis.

In my past, I have often run software development projects, and writing software is

something that I have not really done. If it is the case that you are not a subject expert of an

issue that has been raised, then go ahead and get advice and guidance from the people who

do know – Possibly those who make up the specialist team within the project.





Indeed, I would often run a risk analysis workshop or meeting with one or more individuals

who can help determine the exact nature of the issue.

While carrying out issue analysis, there are a number of aspects that need to be answered

and the following are examples of who you may wish to help with this:

Specialists within the team

Team managers

The organisations that are supplying products or services to the project

Members of the Project Board – This is particularly useful when dealing with resource

requirements and here the senior supplier role would be your best source.

Don’t forget Project Assurance who can be very helpful in Giving support and guidance

to issue impact analysis.

Don’t forget project managers of other projects or even Programme managers if your

project is part of a programme

Okay, so what some questions would you need answering at an issue analysis workshop or

meeting?

First, check whether it is an issue rather than a risk. The difference is fairly straightforward.

Put simply, an issue is an unexpected event that has just occurred, whereas a risk is something

which may or may not happen at some point in the future.

Determine whether the issue affects costs, timescales, the Business Case, or the timings or

level of expected benefits

Does the issue affect the nature of a product or several of the products?

Another useful question to ask is whether the impact of the issue that has arisen within the

present stage, does it affect this stage only or other stages during the project?

Going further, does this issue Have the potential to affect other projects, programmes, or on-

going operational management?

You will want to determine what action you need to take to address the issue, and then to

determine whether that action can be undertaken within your level of authority, or whether

you have to escalate it to the Project Board.

To help determine whether it needs to be escalated depends on the tolerance that you have

been given for the stage (Or if the impact is outside of that or the project).

There are two useful activities within the Controlling a Stage process. The first covers the

steps you would take If the project manager can resolve the issue within their own authority

and it is called “Take corrective action “.

If the project manager determines that the issue needs to be escalated, then the activity

called “Escalate issues and risks “would be used to escalate it to the Project Board.

Don’t forget, that even though the project manager feels confident that they can deal with

the issue within their own authority, it may be good common sense to talk it through with the





Project Board member informally. At the very least it will set the project manager’s mind at

rest, with an added potential benefits of gaining a new insight or another idea about how to

manage the issue.

The Highlight Report

The Highlight Report is not supposed to be a huge complex report. Rather, it should be

straightforward and at the right level of detail suitable for the Project Board to absorb quickly.

The Highlight Report is an important progress reports that the Project Board will find vitally

important during the stage as they are managing by exception. I make the point again that

the Highlight Report should be simple and take not much more than an hour of the project

manager’s time to create.

You will be aware of the social change that has occurred due to the proliferation of faster

Internet connections and smart phones. We have all become skimmers rather than readers.

We want to view information that is relevant and concise. The Project Board are no different.

So do not create complicated and time-consuming reports because the Project Board may

never read because of their complexity. They will not thank you for booking the hours that

you rack up while creating long and complex reports either.

One particular section of the Highlight Report is called “Key issues and risks “.

Be careful not to go into too much detail here, the Project Board do not need to know that

you are capable of dealing with the issue, only that you are bringing it to their attention and

that you are currently managing it.

As an example, going into glorious detail about the technical matter that is being resolved

within the specialist team may not be appropriate here.

Never forget that the Project Board are using the PRINCE2 principle of management by

exception.

This means that they assume the project manager has everything in hand unless it is escalated

formally or informally to them. In this way, their regular Highlight Report should be for

information only, and not alerting them to some crisis that they are not yet aware of.

The message here is to include key issues within the Highlight Report of significant Issues only,

not a mass of routine detail.

When an issue needs stage correction

If the stage is going off track, then the project manager needs to react with actions that bring

it back on track.





The project manager will first learn of such a deviation from the plan when checking the status

of the stage. It is important to check with regard to issues, where you are in order to see if

you have the capacity to absorb the issue impact of any action, or whether you need to

escalate the matter to the Project Board.

The activity you would use there is called “Review the stage status “and it is used to carry out

a thorough check on the progress of the whole stage, including any forecasts, to see whether

or not you are still likely to finish the stage within its tolerance limits.

The stage tolerances were set down by the Project Board at the beginning of the stage.

Just for completeness, do remember there is another activity within the Controlling a Stage

process called “Review work package status “. Although this too provides a progress check,

but it is only done for each work package, and don’t forget you may have several work

packages to completed during a stage, and often to or more of them may be executed in

parallel.

The relationship between issues and risks

I have already given you a simple definition of an issue and of a risk, and they are clearly

different. But did you know that one can cause the other?

If someone raises an issue, as part of carrying out issue analysis you may determine that this

particular issue has an impact on one or more risks. The issue could make a risk more likely

or less likely, the impact greater or less, or the impact areas may now be different.

It works that way when managing the risk too. When carrying out risk analysis a new or

modified issue may be discovered. Also, as part of resolving a risk, you may only be able to

minimize its impact rather than remove it completely. This remaining impact that for now,

you can do nothing about, In and of itself could give rise to a new issue.

The Business Case

When managing the details within a stage, it is easy to forget that any issue that is being

analysed may have an impact on the Business Case. I’m not just talking about benefits here,

but also other aspects of the Business Case such as risks, constraints, timescales and cost.

Reporting an exception

Any given issue may cause stage or project tolerances to be forecast to be exceeded. As the

project manager, if you have determined that no matter what action you take within your

authority, you cannot adjust the running of the stage to finish within the limits of the

tolerance, you must report this to the Project Board immediately.

The stage is now “in exception “.





The only action you should now be taking is to investigate the size of the problem and the

scope of the actions and produce an exception report. The structure of the exception report

was laid down within the communications management strategy document.

It is important to realise that the exception report is not necessarily a document that may be

a meeting, a phone call or an e-mail. Whichever makes most sense.

It is also worthwhile mentioning common sense. If the forecast deviation the tolerance is

relatively small, then I would recommend immediately contacting the Project Board and

discuss this with them verbally. Of course, first you would want to think through what actions

you would take and at that swift meeting get their buy-in to proceed.

It may be that the actions that you can take to bring the stage back within tolerance may have

other impacts such as Business Case impact.

So, whenever an exception occurs, the project manager recommends how it should be dealt

with, but it is the Project Board that must decide how it will be dealt with.

With regard to issues, and as part of assembling an Exception report, you would want to check

out the Issue Register to determine the latest progress of this or any other issues being

currently managed under formal control, and if it has already been created, the formal Issue

Report itself.

The Lessons Report

It is worth spending a moment considering the Lessons Report, which after all should be

created at the end of each stage and at the end of the project. However, this is the minimum,

and frankly a Lessons Report can be created at any point during the project.

With regard to issues and their inclusion within a Lessons Report, you should consider any

statistics such as trends. The statistics may be helpful with resourcing similar future projects

or future stages.

When detailing an issue within the Lessons Report, the following areas should be considered:

What specific event lead to the lesson – Or perhaps it was a constraint

Did the issue lead to a good or bad impact? Do not forget that an issue may be a good idea

rather than a problem or concern

Lay down exactly what triggered the event that lead to the issue and the lesson that was

learned

Were there any early warning indicators or signs that this issue was about to emerge

What actions taken to resolve or minimize the issue and what might be recommended if this

occurred again.





I mentioned earlier that issues and risks were related, and it is here whether you should

mention whether the trigger event had been previously identified as a risk – either as a threat

or an opportunity.

The Issue Register and follow on action recommendations

I do want to briefly mention that as the project comes to a close, you will be using the Closing

a Project process. As part of that, you will want to close down the Issue Register.

Follow on action recommendations are what the Project Board recommended for the

organization to do after the project has finished.

But you may carry some entries forward into follow on action recommendations, an example

here is a good idea That you would recommend the organization to do after the end of the

project.





Video Modules – PowerPoint slide Graphics

Issues


Welcome To Dave Litten’s PRINCE2 Issue Management

Demystified


PART ONE

Issues PRINCE2 Issue Management DemystifiedAn issue can be:

A request for a changeAn off-specification (product error/omission)A problemA concernA good idea that has yet to be implemented

An Issue is any relevant event that has happened,

was not planned, and requires management action

So what is a risk?“A risk is an uncertain event or set of

events that, should it occur, will have an effect on the achievement of objectives”

A risk and an issue are NOT the same – but one

can cause the other!

The aim of issue and change control is not to prevent changes, but to ensure

they are first agreed by the appropriate authority before they are implemented

Since issues and changes are inevitable, you need a

systematic approach to identify, assess and control them





Issues Change Responsibility Road-MapProject Assurance

Advise on examining and

resolving issues

Executive

• Set Change Authority & change budget• Set scale for priority/severity• Decide escalated issues (BC focus)

Senior User

Safeguard benefits from

escalated issues

Senior Supplier

Safeguard solution

integrity from escalated issues

Team Manager

Implement corrective

actions

Project Support

Administer CM andissue/change controlMaintain CIRProduce PSA (Report)

Project Manager

Create and Manage: Configuration ManagementIssue and change control Implement corrective actions

Issue Register





Issues Issue Report – 1

Typically numeric or alpha-numeric, as shown in the Issue RegisterIssue Identifier

Request for ChangeOff-specificationProblem/concern/opportunity

Issue Type

Issue Report Author The person who created the Issue Report

Date raised Date issue was originally raised, and who raised it

Raised by

Issue description A description of the issue, its cause and impact

Priority and severity

Priority. Use chosen categories for priority. Should be re-evaluated after impact analysisSeverity. Use the project’s chosen scale. Will indicate what management level will be required to make the decision

An Issue Report contains the description, impact assessment and recommendations for any

of the specific issues types, and is only created for issues that

are to be handled formally

Informal issues are managed in

the Daily Log





Issues Issue RegisterTypically numeric or alpha-numeric, as shown in the Issue RegisterIssue Identifier

Request for ChangeOff-specificationProblem/concern

Issue Type

Issue Report Author The person who created the Issue Report

Date raised Date issue was originally raised, and who raised it

Raised by

Issue description A description of the issue, its cause and impact

Priority and severity

Priority. Use chosen categories for priority. Should be re-evaluated after issue impact analysisSeverity. Use the project’s chosen scale. Will indicate what management level will be required to make the decision on each issue

Status and Closure Date

Status. Current status of the issue and date of last update.Closure Date. The date the issuewas closed

Issues

Reporting Report composition and format (Issue Report, Product Status Account), their purpose, timing, and recipients, including reviewing the performance of the procedures

Timing of configuration management and issue change control activities

When formal activities are to be undertaken, for example, configuration audits

Roles and responsibilities

Who will be responsible for which aspects of what procedures.Also describes whether a Change Authority/Change Budget will be set up, under development, in review, approved, operational, etc

Scales for priority and severity

For prioritizing requests for change/off-specifications and the management levels needed for decision-making on various levels of severity

Configuration Management StrategyCapturingExaminingProposingdeciding and implementing

Issue and change control procedure

Description of or reference to procedures to be used. Should cover:

Defines the composition and format of the Issue Register

and Configuration Item Records

HOW we are going to apply

CM to this project





Issues Daily Log

Results

Target Date

Person responsible

Problem, action, event or comment

Date of entry

The Daily Log is used as a “catch-all” for any information, to record informal issues,

required actions or significant events not caught by other PRINCE2 registers or logs

It acts as a diary, actions checklist for

the Project Manager

Created during the Starting Up a Project

process

Used to capture ANY issues and risks during Starting Up a Project process, and

any informal issues, actions and risks once the project has formally started

Daily Log

It´s really a powerful action list…

Could be a spreadsheet

for data/action filtering and prioritization





Issues Initiating a Project - 1

How progress, issues, risks, and changes will be assessed,

monitored and controlled

When you fail to plan, you

plan to fail

Prepare the Configuration Management

Strategy

Project Kick-off

CMS

Issue Register

CIRCIR

CIR

Prepare the Configuration Management Strategy

IssueRegister

Prepared and set up by Project Support

CapturingExaminingProposingdeciding and implementing

Issue and change control procedure

Description of, or reference to the procedures to be used. Should cover:

ReportingReport composition and format (Issue Report, Product Status Account), their purpose, timing, and recipients, including reviewing the performance of the procedures





Issues Reports AND The Business Case

A summary of the current set

Issues and risks

The Project Manager’s forecast for both the next stage and for the project against planned targets such as time, cost, quality, scope, benefits and risk. Include reference to tolerances

Forecast

End Stage Report

What went well and what went badlyLessons Review

Errors foundRisk and issue statistics

A review of useful measurementsLessons Review

Lessons Report

Business Case

Issue or Risk Impact

Assessment

Business Case impact?

Project Manager

Issue/risk impacts on Business Case

Reviewing The Business Case





Issues


Issue and Change Control Actions

1

Capture

2

Examine (Impact Analysis)

Include customer, business and supplier

RiskRegister

• Severity• Priority

3

Propose

Benefits Impact

< cost< time> quality<> scope> benefits< risks

< cost< time> quality<> scope> benefits< risks

Alternative options

Implement

Update or issue new:

Exception Plan

5

Work Package

4

Decide

PM can resolve?

Exception Report?

Issue Report

Issue Register

update

Project Manager

Issue Register

Creates an entry in the Issue Register

Capture and examine issues and risks

• Severity• Priority

Issue Report

CT

SQ

B

Rimpact Involve

specialistsother

projects


Issue Report

Issue Register

Propose authority

Project Board

Change AuthorityTake corrective action.

Escalate issues and risks.

Issue Report

Issue Register

Issue Report

update

Review the stage status

Authorize Work Package

Managing a stage

boundary

Stage Plan

Business Case

Project Plan





Issues


Authorize a Work Package

Authorize a Work Package

Issue Register

Authorize an unplanned Work Package in response

to an issue?

Risk Register

Review Work Package status

Issue Register

Update as needed

Review the stage status

Update Issue

Register

Issue Register

Issue Report

Check for issue impacts

Issue Register

Stage Plan

Business Case

Project Plan

Report highlights

Issue Register

Highlight Report (current period)

Key issues and risks

Summary of actual or potential problems

Issues


Issue process in detail

Raised issue

Project Manager

either…

Issue register

Daily Log

Project Manager creates an accompanying

Issue Report

Carried out in the “capture and examine

issues and risks” activity

Issue description Priority Severity Status Closuredate

App not compatible with Windows 10

High Medium Examinestep

Issue Register

IssueID

IssueType

Date Raised by:

Issue Report author

14 RFC 10 Dec 2016

Nick Nathan

John Doe

Issue ID Issue Type Issue Report author

14 RFC John Doe

Date raised Raised by

10 Dec 2016 Nick Nathan

Issue Description: App not compatible with Windows 10Impact Analysis: This has been carried out and App owner will fix the bug free of charge. It will take 4 business days duration to resolve

Recommendation

There is sufficient stage time tolerance to absorb the fix, and the project manager has authorized to proceed with the bug fix

Priority Severity Decision Date

High Low

Approved by: Closure Date:

Decision:

Issue Report





Issues


Take Corrective Action Sequence

Collect deviation information

1

Configuration Item Records

Issue Register

Risk Register

Issue Report

Daily Log

Exception ReportAdvice

Stage Plan

Update

update Configuration Item Records

updateIssue Report

update Issue Register

Daily LogRisk

Register

4

Update as required

3

Implement corrective action

Identify actions to resolve problem

2

Choose most appropriate

action

Issues



Capture and examine issues

and risks

Before deciding on courses of action, each issue or risk

should be registered and then assessed

for its impactExamine impacts

and update

Issue Register

New issue Issue Report

If an issue can be dealt with informally, then make a note in

the Daily Log

Daily Log

Take corrective action

Update as a result of an issue

Issue Register

Issue Report

Corrective

action

Issue Register

Issue Report





Issues


Escalate issues and risks


Create and update

Issue Register

Tolerance threat

Exception raised

Issue Report

Issue Register

Escalating issues and risks is good practice and should

not be seen as failure


Continued Business Justification

Focus On Products

Manage By

Exception


Continued Business Justification

Focus On Products

Controlling a Stage

Principles

Issues


Escalate Issues and Risks Sequence

Stage Plan

Project Plan

1

Define extent/impact

Business Case

Determine options for recovery

2

Request more information

Change Request

Approve, reject, defer

Off Spec:Approve, reject, defer

Off Spec:CONCESSION

Increase Tolerance

produce Exception Plan

Premature close

Courses of action

3

Stage Plan

Assess impact of options

Skills/experience

4

Exception Report

Create Exception Report

...reviewed by the Project Board and Project Assurance –

approved by the Executive...

PRINCE2 principle- continued business

justification





Issues


Managing Product DeliveryExecute a

Work Package

Create or update

Should the Work Package be forecast to exceed tolerances,

the Team Manager should raise an issue to the Project Manager, who will decide what to do next

New Issue raise

Check Work Package

Risk Register

IssueRegister

Monitor and control

Issue If tolerance is exceeded

Review and report work status to Project Manager

Issuesand risks

Update on all associated issues and risks

Problem handling and escalation

The procedures for raising issues and risks

Checkpoint Report

Execute a Work Package

Risk Register

Issue Register

Notify the Project Manager of any new issues, risks or lessons

The Team Manager does NOT raise an Exception Report –

just an Issue

Work Package

Issues


Closing a Project – Overview

Issue Register

Lessons Log

Risk Register

Daily Log

Recommend project closure

Directing a

Project

Closure recommendation

Premature close

Directing a

Project

Review project against baselinesAssess realized benefits and update Benefits Review PlanAddress all unfinished business

Issue Register

Additional work estimates

Prepare premature closure

update

Hand over products

Issue Register

Evaluate the project

Issue Register

Uncompleted issues





Issues


Closing a Project – Actions and Reports

Review of useful measurements:

Errors foundRisk and issue statistics

Lessons Report

Lessons Report

Current Issues and Risks

Project Manager forecast

Off-specifications - Actual and missing products that did not meet the original requirements including any granted concessions

Summary of follow-on recommendations for the project board (e.g. uncompleted issues)

Review of products

End Project Report

Project Manager updates

Prepare premature closure

Issue Register

Project Manager closes

Recommend project closure

Issue Register

Issues


Hope You Enjoyed My PRINCE2 Issue Management Demystified!

Thanks For Stopping By …

Grab YOUR Copy of my

PRINCE2 Primer MasterClass






Everything I do believes in challenging the current way that project management training is

delivered. My video training products are beautifully designed, simple to absorb in easy

steps, and are downloaded direct to your computer. I call these video trainers, Primers -

Want To Own One?

Check out my other Project Management Primers:

http://www.prince2primer.com

(Pass your PRINCE2 Foundation and Practitioner exams!)

http://www.pm-primer.com

(Pass Your PMP Exam First Time!)

http://www.directingaproject.com

(Lean the art of Advanced PRINCE2 Governance)

http://www.project-management-primer.com

(Introduction to Project Management)

http://www.apmic-primer.com

(Introductory Certificate exam for the APM)

http://www.msproject2010primer.com

(Master MS Project 2010!)

http://www.taskpack.com

(Hone your personal assignment skills)

http://www.AgileProjectManagementprimer.com (pass your Foundation & Practitioner

exams)

COMING SOON …

http://www.LeanSixSigmaPrimer.com (Master Green Belt Practitioner Lean Six Sigma)

http://www.AgilePrince2.com (pass your Foundation & Practitioner exams)




http://www.pm-primer.com/

http://www.directingaproject.com/

http://www.project-management-primer.com/

http://www.apmic-primer.com/

http://www.msproject2010primer.com/

http://www.taskpack.com/

http://www.agileprojectmanagementprimer.com/

http://www.leansixsigmaprimer.com/

http://www.agileprince2.com/

prince2 issue management demystified€¦ · prince2 issue management demystified 3 | setting up...

Documents