Management products will be mentioned in the following sections – it may be an idea to refer to these in Appendix A of the PRINCE2 manual as you read through. All Management products are shown in italic
Consider the effort put into Planning by a PRINCE2 Project Manager (PM). Each Stage Plan will have involved the creation of a Product Breakdown Structure, Product Descriptions, a Product Flow Diagram and the Stage Plan itself. In addition, during PL6 Analysing Risks, the PM will have been seeking to identify new (or changed) risks, introduced by the timescales, dependencies and resourcing of that plan. PL7 Completing a Plan also sees considerable effort being put into the narrative elements of that plan. All in all, a significant amount of work needs to be completed by the PM.
We want to deliver exactly what this plan represents, and so it would be a great pity to simply leave the plan to its own devices and see where it ends up. What is needed is control, and PRINCE2 provides the simple feedback loop shown below to achieve the required control.
Of course, ALL levels of plan in the project need to be controlled, whether the plan is a Project Plan, a Stage Plan or a Team Plan.
So what is a control? Simply put, a control is a mechanism employed by a level of management to have a deciding influence on the actions of the level of management below. In other words, the control allows (eg) the Project Board (PB) to make decisions on the work being done by the PM. The same description applies to the work relationship between the PM and the Team Manager (TM). (Don’t forget that exactly the same thing is also happening between Corporate/Programme Management and the PB).
In effect, a control is exercised so as to keep the plan of interest as close to its schedule (and objectives) as possible. As the project progresses, changes and minor problems often cause the project to diverge from its original intent – controls are there to bring the plan back onto track (or as nearly as possible).
A control is, therefore, a decision/recommendation/suggestion made by the higher level of management to the lower level in order to keep the plan on schedule (including timescale, budget and objectives).
The missing link between the plan (and information about the plan, eg progress information) is the Monitoring element. This Master Class will seek to draw the 4 elements above together to give a rounded view of how Controls work in a PRINCE2 project.
Levels of Control
The way in which control is exercised is shown in the figure below. We will concern ourselves with the lower three levels (although it should be remembered that Corporate/Programme Management will have issued the overall project tolerances to the PB in the first place – a major control).
We will also need to consider where we are in the project, to see where controls are first imposed and then implemented. To do this, we will divide a PRINCE2 project into 3 areas:
At this highest level of abstraction we can see 5 of the major PB controls in operation. They are decisions to continue, or stop, the project. Controls do not get any more major than that. The above decisions (controls) are issued via unique PB processes:
Authorise the Project;
Authorise a Stage or Exception Plan (End Stage Assessment & Exception Assessment);
Authorise Project Closure).
Give ad-hoc direction, although not shown on the figure, is also an important control function for the PB, since this is where more immediate day-to day decisions can be conveyed to the PM. This sub-process is an integral part of Controlled Progress.
Taking each of the above processes in turn, we can examine the concepts in play and the monitoring methods used to enable control at the PB level.
This process uses the following main products from SU to inform the decision-making process for the PB.
Project Management Team structure and role descriptions;
Outline Business Case;
Project Product Description;
Stage Plan (for the Initiation Stage).
The decision being made here is essentially about whether the project, as currently defined, looks like a valid and viable project for the Organisation to be undertaking (to the extent that further definition will now be paid for to develop the PID).
Authorise the Project;
This process uses the following main products from IP to inform the decision-making process for the PB.
Project Initiation Documentation;
Stage Plan (for the 1st Stage of specialist work). Note that the Stage Plan will contain details of the stage tolerances available, as handed down by the PB (another of the PB’s prime controls, stage tolerances set the limits within which the PM must work if he or she is to avoid seeking further direction from the PB. This would arise if any of the tolerances were predicted to be breached, necessitating the production of an Exception Report – see DP3).
The PID is primarily an assembly of other management products which, in some cases, make use of other control concepts. These are expanded below:
Project definition; constrains the objectives, scope & exclusions of the project.
Project Controls; defines the reporting and monitoring mechanisms to be employed and also defines the process to be followed when handling exceptions.
Business Case; provides the rationale for the project, including any financial appraisal.
Initial Project Plan; defines the overall timescales and costs for the project, but also introduces the concept of Stages, a prime control of the PB whereby they decide when the major project reviews should be undertaken. The PB essentially impose Stage boundaries on the Project Plan to enable their effective control via an End Stage Assessment (see DP3). Will include the project tolerances.
Risk Management Strategy, decisions on PM recommendations for Risk Management will have een made by the PB (ie control). Also the creation of the initial Risk Register.
Communication Management Strategy; defines the stakeholder information requirements for the project and therefore provides some control over User involvement etc.
Quality Management Strategy; defines the quality regime under which the project must be conducted. This is a control of use to both the PB and the PM.
Configuration Management Strategy, applies control to the products of the project
As can be seen, many control concepts are initiated within the PID for use in decision-making later. If the PB approve the PID (ie Authorise a Project) then they are also approving the proposed control mechanisms within it.
The decision being made here is now about whether the project deliverables should be commenced. The decision is based on the project now being fully defined and presenting a valid and viable project for the Organisation to be undertaking.
Authorise a Stage or Exception Plan
End Stage Assessment
Here we see some of the controls mentioned earlier coming together to enable the 2 types of assessment to be conducted. For an End Stage Assessment to occur the PB need to refer to the PID and 2 other management products:
End Stage Report;
Stage Plan; (for the next Stage of specialist work)
These management products are generated by the process Managing a Stage Boundary, a process which is only triggered by the presence of a Stage boundary on the Project Plan (or an implied Stage boundary introduced via an exception condition).
An Exception Assessment will be required when the following sequence of actions and controls has occurred:
A Stage has been approved by the PB in a previous authorisation decision and work has commenced under the tolerances set for the Stage;
An issue has arisen whose impact analysis indicates that a tolerance breach will occur if the issue is left uncorrected;
An Exception Report is created by the PM and sent to the PB (see below) – the PB decide that an Exception Plan is needed to allow formal assessment of the PM proposals. This is produced within Managing a Stage Boundary and presented to the PB for the formal assessment to be made.
In the case of either an End Stage or Exception Assessment, the PB is looking to approve or reject the grounds for continuing the project based, again, on the continuing viability of the project.
Give ad-hoc direction
As we have seen, this sub-process can make some major decisions (such as whether to request an Exception Plan instead of merely closing the project immediately. Indeed the PB do not need to wait for an Exception Report to trigger the closedown decision – they can issue this instruction at any time).
Other decisions being made by include decisions on Risk recommendations from the PM and decisions on Changes (Change Control).
The sub-process is also used by the PB to receive and review the Highlight Report produced by the PM. In setting the frequency and content of this report, the PB is, again, exercising control over the PM. Any Highlight Report can result in ad-hoc direction from the PB – another example of exercising control.
Don’t forget that this is also the sub-process which will receive reports from the PB Project Assurance activities, which are themselves likely to result in control actions being taken by the PB.
Authorise Project Closure
The major control of the PB here is the issuing of the Project Closure Notification. This will only be done once the PB has assured itself that the project has, indeed, met its objectives and that all planned work has been completed. The decision is informed by the following management products, all created by the PM:
Lessons Learned: may exert control over later projects.
Follow On Action Recommendations: proposes action to be taken over unresolved issues and risks.
End Project Report; summary of the project and its successes and failings.
Project Manager Controls
The PM controls are clearly restricted to IP and CS. In IP, for example, the PM may have needed to specify time and cost tolerances for the work of creating a PID (although this is not necessary where IP is expected to be a very short process).
However, the prime controls of the PM arise when considering the relationship(s) with the Team Manager(s) (TM).
Firstly, the PM controls the start and execution of work via sub-process Authorise Work Packages. The Work Package (WP) itself is the PM’s major control, since:
1. No work may begin in the absence of a WP;
2. The WP defines the work to be done (via Product Descriptions), the tolerances for the WP and the nature of the quality work to be undertaken when the WP is completed.
3. The WP also specifies the frequency of the Checkpoint Report, which the TM must produce as defined. This report allows occasional corrective advice from the PM in the same way as the PB use the Highlight Report.
4. Allocating work in this way ensures that the project products are built according to the Product Description for that product. This neatly squares the circle of control, since the Product Description is a control of the PB – when they approve a plan they are also approving the various Product Descriptions contained within that plan.
Team Manager Controls
No explicit PRINCE2 controls are defined for TMs except perhaps the Daily Log (a different log from that of the PM), but we must recognise that the TM will be employing the same mechanisms to control the activities of the Team as the PM is to control the TM’s activities.
It is important to understand controls in the context of Planning, Delegating, Monitoring and Control (the final element being the decision made to change some aspect or other of the project). Remember that the Project Board and the Project manager exercise the vast majority of controls in a PRINCE2 project, but that we must also recognise the same functions at the Team Manager and Corporate levels.
Finally, the controls and their monitoring methods (and the repositories of this monitoring information) can form some quite complex interactions – one triggering the next and so on