Hi, this is Dave Litten from Projex Academy, and this video is in response to confusion that can occur for those who are preparing for their PRINCE2 Practitioner exam – in particular, the PRINCE2 Controlling a Stage Process. There are of course seven processes and seven themes and seven principles. When learning PRINCE2, for all the right reasons, you are taught specific sections, one at a time. For example, you might be taught the starting up a project process, then you might look at the business case theme, and so on.Dave Litten – Chief PRINCE2 Instructor
Sometimes it is forgotten that in fact the PRINCE2 Themes are used and often play quite a central role within some of the PRINCE2 Processes. Probably center-stage, pardon the pun, is the Controlling a Stage process and in particular, the way in which corrective action is taken which normally involves risks and issues i.e., the Risk Theme and the Change Theme.
So, let’s dive into the PRINCE2 Controlling a Stage process and show you how things link together.
Controlling a Stage – Simplified
So let me start off with a simplified diagram of the controlling a stage process:
You will be aware of course that the project manager gives out work packages and the specialist team in managing product delivery, creates the products from the product descriptions that lay within each work package. The project manager may give out several work packages all at once – possibly to several different teams and several different team managers or just one work package at a time.
The golden rule is that every work package should have at least one product description contained within it – there is no such thing in PRINCE2 as a work package that conducts work without it being defined by a product description, with its appropriate quality criteria.
So, I have to break that loop somewhere – and in my simplified diagram, I’ve done it as you can see at the point where the project manager regularly reviews the status of one or more work packages. Sometimes this is called ‘capturing the actuals’ because what it means is the data the project manager is after is what has actually happened.
One of the main ways in which that will occur is via checkpoint reports sent by the team manager or the team members themselves to the project manager.
In terms of reviewing work package status, what about when a work package gets completed? Well, that too would be an input of an ‘actual’, so here is a completed work package and it’s being received by the project manager.
Be clear, they are not returning the work package document per se, they are actually advising the project manager that all the products within the work package have been created, have passed their quality check, and have been approved. So these are two main inputs that the project manager uses.
Controlling a Stage – Forecasting
The next step of course is to look upwards and see the bigger picture of the stage itself and this is called forecasting. For obvious reasons what the project manager will do, is see what the actual situation is and compare it to the stage plan that the project board approved, to see whether the project is on track.
There are various progress evaluation techniques that are used here, such as Gantt Charts and the like, so reviewing the stage status is done directly against the stage plan. Now comes the interesting part – since we know your actual status at this time on what the future looks like, we may like what we see or not!
Nonetheless, there are some other things that I need to include here. Let us start with the easy ones first – as laid down by the project board, the project manager will need to report highlights regularly by issuing them with a highlight report and it may also go to other senior stakeholders.
Having reviewed the stage status, the project manager might realize it is time to issue the next work package or work packages – so those would now be given out. However, what if things do not go to plan? Well, here’s where corrective action comes into play.
PRINCE2 Taking Corrective Action
The project manager needs to implement corrective actions whatever they are, and it might be the project manager who conducts such actions themselves, or it might be that as a result of this corrective action, a new or modified work package needs to be given out to the team so that they can take those actions.
So why is control needed here?
Well, that’s because the best-laid plans will never be 100% accurate – they’ll be as good as you can get due to estimating, which by its very nature means that it is your best intelligent thought-through guess, but apart from variances from small estimates, there will be other things that happen that were not planned for.
After all, a project does not take place in a vacuum, and I am talking here about issues and risks, and therefore the activity within controlling a stage called Capture and Examine Issues and Risks does exactly that. I will be talking about this in just a moment.
So, here’s where a new issue might be raised by just about anyone and both issues and risks can be captured in a formal or informal way. If they are captured informally then the project manager would use their Daily Log in the same structured manner, of course, to track and manage such issues or risks.
Whether it is estimating, the outside world changing in some way, or issues and risks have cropped up, it may well be that the project manager can see that the stage and/or project are not going to be completed within tolerances.
There are six types of tolerances and it could be any one of them that’s at play here because one of the principles of PRINCE2 is that you manage by exception. So what happens next is immediately the project manager forecasts a stage or project is to exceed tolerances, then they must raise an exception report.
Again, I am missing out on some lower-level details here because let’s say this new issue was raised as the project manager realized that the stage or no project was not going to complete within tolerances – not only would an exception report be raised but also an issue report – not shown here for brevity but just be aware of that.
So, for the remainder of this blog, I want to simplify this even further so we can focus on the project manager’s actions here, and it would look something like this:
Remember, the project manager is an action-oriented individual, a critical thinker, and a problem-solver. The controlling a stage process has the actual data that has come in from various sources, and this is the activity again forecasting reviewing the state status once more.
The stage plan, is your benchmark here, as it’s baselined once it’s been authorized by the project board, and this is the planned data against which you review your actual data. You could be using various progress evaluation techniques which I do not intend to discuss any further in this article.
You can have any issues or risks arising in an ad hoc way and they need to be planned and managed in a controlled manner so whichever one or several of these occur, it is the output of Reviewing the Stage Status where the project manager needs to implement actions to remove such deviations to get the project or stage (or both) back on track.
Here is where I want to share with you some other chapters within the PRINCE2 manual so you can pull those ideas together and see how they are used within the Controlling a Stage process. The first which I have mentioned already is about issue and change control and as you know these can come in various flavours.
PRINCE2 Issue and Change Control
PRINCE2 uses the term issue to mean the common usage of the word issues as well as changes – so it could be an issue in the form of a problem a concern. However, it could also be a request for change or an off-specification.
Again, I do not wish to go into any more detail about those now, however, you will probably recognize this diagram as it shows the five steps:
If you are managing any type of issue, first capture it, then assess it, then look at different options for managing it, and recommend the best one. This may or may not be implemented. The project manager may be able to do that themselves if it is within their authority, or it may need to be escalated up to the project board.
Whatever happens, there needs to be a decision made either to proceed with it or not, and in that case, this is the implement step. Notice in the small print that this is where corrective action is taken, and yes, that takes place within the Controlling a Stage process.
So, the steps here are, first to capture the issues either formally on an issue register, or if it’s an informal issue, in your daily log. You then need to assess the issue and conduct some form of impact analysis.
Then it is time to propose which corrective actions you think would be best, recommending the best option for recovery of the situation. After that you then need to decide which corrective action is to be used and then implement – it or as I have suggested here, escalate it if it is beyond the project manager’s delegated authority.
The final step then is to implement it.
What about risks?
Again, you will recognize this diagram here are the five steps. Do not forget to communicate (the one in the middle).
The first step is in two parts, identify the risk context, which project objectives are at risk, and how that relates to the delivery approach (for example, agile). The second part is to identify each risk, taking care to first capture the risk cause, then the risk event itself, leading to identify the risk effect (impact).
The next step is the assess step, and here for each risk, we are looking at the risk probability and impact usually using the probability impact matrix. The second thing you do in assess is to evaluate the full risk exposure for the project and again another technique you might use here is called the expected monetary value.
After that, you’re into the plan step, which is where you are choosing your risk responses, and again I’m not here to teach you risk per se, but do remember there are positive risks called opportunities and there are negative risks which are called threats. All types need to be considered, so in the plan here, you are choosing which is the best response to use for each individual risk.
Then we need to implement those actions, which are implemented within the Controlling a Stage process, and often using the Managing Product Delivery process (when it is the team that will be putting these actions in place).
The fifth step is communicate, which is happening all the time. Usually, when we talk about communicating the risks we are talking about checkpoint and highlight reports, end-stage and end project reports, and should they ever be necessary, Exception Reports. So, this slide summarizes the risk procedure. Again, my intention here is to keep you focused that all of these get implemented within the Controlling a Stage process.
Taking corrective action is as you know part of the Controlling a Stage process and it is those actions you need to take so that you keep the project and the stage on plan.
NOTE. The implement step for risks, FIRST happens when planning a stage, so that the time, cost, and resources involved in implementing risk responses, are included in that stage plan. However, the sequence I am referring to here is during a delivery Management Stage and the use of the Controlling a Stage process.
The above diagram shows you issues, problems, concerns, requests for change, and off-specification, the risks (which might be existing risks or new risks or risks that have been modified), and all of these start their life in the activity called Capture and Examine Issues and Risks.
The activity called Take Corrective Action is used when you are implementing any of these issues and or any of these risks. They all take place in the Controlling a Stage process and once you have taken some form of corrective action, you then want to see what that means to the stage status.
So, this feeds into the Review the Management Stage Status activity within the Controlling a Stage process.
Capture and Examine Issues
Let us go through those in simple steps – again I have simplified these slightly.
Step one then in terms of issues, is to check the Change Management Approach.
Step two, whenever a new issue arises, is to enter and categorize each issue. Let us say in the issue register and raise an issue report, or if it has been done informally, then we would use the Daily Log.
Step three is again looking at the issue register, assess the severity and priority of each issue, and step four assesses the impact. Again, when we assess the impact of issues, we don’t just look at the plans, we also look at the business case to see what the impact on that would be with regard to this specific issue.
Step five is to document the Issue Report which will be used throughout and updated right through to the closure of the issue.
Again for risks, I have simplified this somewhat:
Capture and Examine Risks
Step one would be to check the approach in which you are managing the risks (this is from the Risk Management Approach document). Both of these if you remember form parts of the Project Initiation Documentation (PID).
Step two is to enter and describe the cause and effect in the risk register and step three assesses the risk and plans the appropriate response with regard to the stage plan project plan and the business case.
Step four is then to take the appropriate action, in other words, implement the responses.
Review The Management Stage
Looking at the activity Review the Management Stage Status sequence, the steps here are:
Step one is reviewing the stage progress using checkpoint reports compared against the stage plan. Step two is then estimating the remaining work and work packages. If you are using configuration management, you would then want to update your product status account, but it is optional.
Step three, check for any quality issues. Remember you are reviewing the management stage status, determining where are we, and what the real status is right now. Looking at the quality register will show you the quality checking steps which have taken place and which products have been approved or otherwise.
Step four and step five are to check for any new or revised risks again looking at the stage plan project plan and business case and checking for issue impacts.
Step six is to look at resource utilization and any due benefit reviews. Again, you have the Benefits Management Approach document which describes how these will take place and when and what resources are required.
We are looking at resource utilization here because it is important that when you implement an action or set of actions for an issue or when you implement responses for risk, this would need work to be conducted. This means someone is likely booking time and therefore cost to such actions, and it’s therefore important to look at this in the light of what resources you have available.
Take Corrective Action
Let us then look at the take corrective action sequence – do remember that although the project manager may take such corrective actions themselves. As an example, suppose one of the team members has gone sick and the project manager needs to talk this through with a resource manager for a replacement, they can do that themselves.
But often, the corrective action that needs to be taken, is that of a specialist nature and will therefore involve the specialist team – in which case this may mean authorizing a new work package or modifying an existing one to include these extra steps.
Corrective action step number one is to collect all this data that we’ve talked about – I’ve included these here as examples of the type of source information you’d be looking for.
Step two is to identify potential actions to reduce the problem whatever the cause of the problem is, and what you are doing is to choose the most appropriate action and then go on to implement such corrective action.
You then want to update as required – this may be updating configuration item records if you have them, updating the issue report to show the current status, updating any of the registers and logs, and updating the stage plan to show the new actual and forecast.
The project manager will be doing this, and that would include informal issues or risks, the Daily Log itself, and of course do not forget if you are using configuration item records those need to be updated to reflect accurately any products that have been affected by issues and risks. The project manager will be updating the issue report and stage plan.
Project assurance is part of the project board, if you recall would they be there to review any or all of the above to give an independent audit of such documents.
I will leave this slide with one final point and that’s to remind you again that taking any form of corrective action in a project may indeed have little to do with issues or risks. It may just be due to external influences – market forces are one example. Nonetheless, whatever the source of the problem it should be logged either formally or informally as an issue or a new risk.
Note. An issue is something that has happened or is about to happen, whereas a risk is something that may or may not happen at some point in the future.
Don’t forget issues and risks can both interact – a new issue can cause a new risk or impact positively or negatively an existing risk and the reverse is true, the arrival of a new risk or the change of a risk severity could give rise to new issues.
Here is the PRINCE2 Controlling a Stage process to summarise what we have covered in this blog:
I’m sure that now you’ve got a bit more insight into how the mechanisms of the Controlling a Stage process works, so I have just one last question for you – that is, are you looking for a personal PRINCE2 Mentor and Coach?