Introduction

• Defintion
• Structure and terminology
• What is a project?

Processes

• The processes
• Management levels
• Starting up a project SU
  • Fundamental principles
  • Appointing an Executive and Project Manager (SU1)
  • Designing a Project Management Team (SU1)
  • Appointing a Project Management Team (SU3)
  • Preparing a Project Brief (SU4)
  • Defining Project Approach (SU5)
  • Planning an Initiation Stage (SU6)
• Initiating a project IP
  • Fundamental principles
  • Planning Quality (IP1)
  • Planning a Project (IP2)
  • Refining a Business Case and Risks (IP3)
  • Setting up Project Controls (IP4)
  • Setting up Project Files (IP5)
  • Assembling a Project Initiation Document (IP6)
• Directing a project DP
  • Fundamental principles
  • Authorising Initiation (DP1)
  • Authorising a Project (DP2)
  • Authorising a Stage or Exception Plan (DP3)
  • Giving Ad Hoc Direction (DP4)
  • Confirming Project Closure (DP5)
• Controlling a stage CS
  • Fundamental principles
  • Authorising Work Package (CS1)
  • Assessing Progress (CS2)
  • Capturing Project Issues (CS3)
  • Examining Project Issues (CS4)
  • Reviewing Stage Status (CS5)
  • Reporting Highlights (CS6)
  • Taking Corrective Action (CS7)
  • Escalating Project Issues (CS8)
  • Receiving Completed Work Package (CS9)
• Managing product delivery MP
  • Fundamental principles
  • Accepting a Work Package (MP1)
  • Executing a Work Package (MP2)
  • Delivering a Work Package (MP3)
• Managing stage boundaries SB
  • Fundamental principles
  • Planning a Stage (SB1)
  • Updating a Project Plan (SB2)
  • Updating a Project Business Case (SB3)
  • Updating the Risk Log (SB4)
  • Reporting Stage End (SB5)
  • Producing an Exception Plan (SB6)
• Closing a project CP
  • Fundamental principles
  • Decommissioning a Project (CP1)
  • Identifying Follow-on Actions (CP2)
  • Evaluating a Project (CP3)
• Planning PL
  • Fundamental principles
  • Designing a Plan (PL1)
  • Defining and Analysing Products (PL2)
  • Identifying Activities and Dependencies (PL3)
  • Estimating (PL4)
  • Scheduling (PL5)
  • Analysing Risks (PL6)
  • Completing a Plan (PL7)

Components

• The components
• Business case
  • What is it?
  • Developing
• Organisation
  • Overview
  • The customer / supplier environment
  • Project Manager
• Plans
  • Benefits
  • Levels of plan
• Controls
  • Purpose
  • Project start-up
  • Tolerance
  • Product Descriptions
  • Exception Report
  • Controlled close
• Management of risk
  • What is it?
  • Risk analysis
  • Risk profile
  • Mapping the management of risk to the PRINCE2® processes
  • Interdependencies
• Quality in a project environment
  • What is quality?
• Configuration management
  • Purpose
  • Configuration control
• Change control
  • Purpose

Techniques

• General
• Product-based planning
  • General
  • Producing a Product Breakdown Structure
  • Writing a Product Description
  • Creating a Product Flow Diagram
• Change control
  • General
• Quality reviews
  • What is it?
  • Steps in a formal quality review procedure

Other

• Risk categories
• Health check
  • Health check – part 1
  • Health check – part 2

Purpose

Change will occur in any project. Particular changes can have a large detrimental affect on a project unless carried out in a controlled manner.
For any item change is not inevitable as the process of change must be judged against certain criteria.

These might be:

• Assessing the impact of the change both on the project / programme and other areas
• The importance of the change
• The cost of the change

It might be that management decides not to proceed with the change following such an assessment.
All approved changes must be accounted for in the schedules and budget as necessary.

Change control can be used to capture a wide range of Project Issues which may include:

• Movement of personnel across teams / projects
• Suggestions
• Change requests
• Business Case modifications
• Risk changes etc

The project team must decide, with the approval of the Project Board what items come under change control.
Methods used to control change are given in ‘Change control technique’.

Project Issue management

All Project Issues must be captured, logged and categorised.
These may arise at any time and from anyone with an interest in the project.

Project Issues are not only negative but may be those having a positive impact on the project.

These may be:

• Changes in requirements. Even a minor change may lead to longer term issues
• Environmental changes:

Legislative change
Corporate change in direction
New customer
New supplier
Changes in project management team membership
Competitor activity
Directive from programme management
Corporate reorganisation

• Anything not covered by earlier risk analysis
• Anticipated unavoidable risk occurring
• A problem or error in work completed or underway
• Advice of a new risk
• Queries about aspect of the project

The management of Project Issues will involve:

• Capturing and logging of the issue
• Assessing to label the type and action required on the issue
• Considering and investigating the required actions
• Documentation of agreed action and their completion
• Regular review of the Issue Log to monitor the progress of outstanding Project Issues

As Project Issues can come form almost any source it is important to have a good process that will capture and assess their impact.

Project Issues can result in in two forms of change:

This will result in a change to the specification or Acceptance Criteria of the project or one of its products.
Any additional costs would normally be funded by the Customer.

This covers errors or omissions found in completed work or planned for the future.
Either situation will result in agreed Acceptance Criteria not being met.
Costs will normally be funded by the supplier involved.

Note that any such costs for suppliers should be agreed in their contracts.
These should include responsibilities and any arbitration processes.

Any new risks will need to be assessed for their impact (as part of Examining Project Issues (CS4).
Any measures that may require implementing should be approved by the Project Board if a major change to the project is anticipated.

Authority levels

Someone (or body) must have the responsibility to authorise change.
It will depend upon the nature of the change and the potential impact on the project.
The Project Board will have signed off on the project expecting a particular product and scope.
If any changes will affect this the Project Board should authorise any changes.
This would be suitable if only a few changes were anticipated.

Most projects have a lot of changes which would tie up the time of the Project Board.

The level of authorisation should be discussed and agreed during project initiation.
The key is to decide which Project Issues should be authorised by the Project Board and at what level of impact.
Others can be authorised by, say the Project Manager or to a group (called ‘change authority’), if agreed by the Project Board.
This is a vital aspect of project control and project success and nay authority should be identified in appropriate job descriptions.

Any projects that form part of a programme will be advised by programme management of the level of authority given to the Project Board.

Change budget

The Project Board must consider:

• How will changes be funded
• How will the change be managed in terms of this funding? Will the Project Board resort to asking corporate or programme management to modify funding, timetable or scope for each change?

It may be better to allocate a budget to the ‘change authority’ to improve efficiency. This will reduce the time spent by the Project Board on minor changes that may be frequent. The amount of any budget, the responsibilities, how it is used and any other constraints must be defined and agreed.

In addition, the Project Board may set a limit in the budget for the cost of implementing any one change and a limit to expenditure for any particular stage.

The ‘change authority’ may in fact be given to those individuals with delegated Project Assurance responsibilities.

Integrity of change

Benefit / Business Case driven

All Project Issues should be assessed against any impact on the Business Case.

The Risk Log

Project issues should be assessed for risk impact.

• Impact on existing risk
• Is it a known risk that has already been considered as part of the ‘risk management process’. Any risks here should already have plans to minimise or avoid their impact.
• Does it create a new risk

Time / cost / risk function balance

All changes must be balanced against the advantage of implementation versus the time, cost and risk in carrying it out.

• Will it be easy to obtain the extra funds?
• Could they be spent more wisely?
• Will the change save money and time?
• Can any project delay be tolerated?
• Should the change be delayed till the project ends?
• Can the change be delayed till the project ends?

Where the project is part of a programme

All change control procedures must be consistent with any used by a higher level programme.
All changes must consider the impact on such programmes as well as possible impact on other projects or areas outside of the programme.

Management of change and configuration management

Change control and configuration management should be consistent with each others approach.
This should be identified in the Configuration Management Plan.

During a project there may be many opportunities that are identified that could improve costs and performance.
These may not result in actual changes in a current project but should be noted as a Project Issue.
These would then be recorded in the Lessons Learned Log.