Clarifying Some Key Points
This section gives a bit of help on some key points in case you’re not quite sure of them. If, when you look at a heading, you feel confident that you know about the area, then simply skip it and move on to the next one.
Understanding Work Packages
If you’ve read this chapter from the beginning, then you’ve probably already picked up on what a Work Package is, even if you weren’t absolutely clear before. It’s simply a work assignment given to a Team Manager by the Project Manager.
You can think of the Work Package as being an instruction pack where the Project Manager tells the Team Manager:
What is to be produced in the assignment
How things are to be communicated to the project management level from the delivery level (such as team progress reporting – Checkpoint Reports)
How the finished work is to be returned or reported as complete
The Work Package, then, is both an instruction and an authority to produce a single product or perhaps two or three products which it makes sense to work on together. For example, for the cabling in a new suite of offices, there’s a need, say, for mains electrical cabling, lighting cabling and computer cabling. A decision has been made to give that work to a cabling company, and that company will send in a cabling team. But it makes sense for the team to do all the cabling at once and so ‘build’ the three products in parallel rather than do all of the mains cabling and finish it, then tackle the lighting and finally the computer cabling. The Work Package will specify that there are three products involved, and it will include copies of the three Product Descriptions.
Getting to grips with exception management
Exception management works at different levels in PRINCE2. Basically it allows everyone to get on with the job unless something is projected to go outside pre-specified limits such as a cost band. To revise exception management, have a look at the Progress theme chapter, Chapter 17. However, PRINCE2 For Dummies has much more detail, if you need clear explanation. [P2FD Ch17 Managing ‘By Exception’]
The Controlling a Stage process is the filling in the sandwich of the three levels where exception management is used in PRINCE2: project level, stage level and team level. The Project Manager is accountable to the Project Board for running the stage within the pre-determined limits, but will also set limits (tolerances) on the Team Managers for their Work Packages. So, the Project Manager will receive information on the status of each Work Package relative to its tolerance limits, but will also report to the Project Board on the status of the stage within its tolerances.
Being clear on when to escalate and when not to
The Project Manager has delegated authority to manage the stage. The Project Board should not, then, be involved in the day-to-day work of management. Owing to the rather strange approach and wording of the 2009 edition of the manual in relation to issue handling, you may be forgiven for thinking that the board is very involved in day-to-day things. However, the reality of the underlying dynamic is still the same: the Project Board stands back and lets the Project Manager get on with it, but within limits.
Consequently, Project Managers need only escalate something to the Project Board when the action will exceed their delegated authority. That doesn’t mean that the Project Manager can’t ask for a view, though. Just as in normal organisational management someone can ‘run it past the boss’, so too the Project Manager can get a view from one or more members of the Project Board. Giving such advice is a function of the Project Board in its activity ‘Give ad hoc direction’ within the process Directing a Project.
Appreciating the extent of the stage status review
When you first look at the activity ‘Review the stage status’, you’ll probably think about progress control. That’s fair enough, because it’s an important function of the activity. However, the activity has a wider scope, and you need to be aware of it. You’ll probably appreciate that the Business Case is checked at the end of each stage. In most projects, and especially those in a dynamic business environment, it clearly makes sense to check the Business Case more often than that. If so, then this is the activity that covers it. Equally, in a project with any degree of risk, you’re not going to leave risk monitoring until the end of the stage, although it’s an important check at that point. More frequent monitoring of risk is also done during a stage, and again it’s the ‘Review the stage status’ activity that covers it.
The review activity will normally be triggered at set time intervals, such as every week or every two weeks. However, there’s a second important trigger that you should be aware of, which is the area of issue handling. In the process, model you’ll see that the activity ‘Capture and examine issues and risks’ leads in to the review activity. The review comes before taking any necessary action on the issue to adjust the stage or escalate it to the Project Board. Have a look at Figure 7-1 to see the flow. For clarity in the figure, the flow is from left to right.
Figure 7-1: The handling flow of an issue.
Handling issues and risks
An issue can be sent to the Project Manager from anyone ‘with an interest in the project or its outcome’, which could be someone completely outside the project. In a real project, you may have very good reason to question that, but remember that the exams are based on the manual.
Using more than one register
Remember than an issue can lead to entries in more than one register. For example, if someone sends in details of a problem, it may be significant enough to record in an Issue Report, with the control information duplicated in the Issue Register. However, examination of the issue may also reveal a significant risk that even the author of the issue was unaware of. This may justify an entry in the Risk Register.
It doesn’t help that, unlike earlier editions, the 2009 edition of the PRINCE2 manual doesn’t include information in Appendix A for an issue. There’s a short explanation in the main text, repeated in the glossary, but that’s both inaccurate and misleading, because it describes the issue as ‘a relevant event that has happened’, but the continuing explanation correctly lists examples, of which some are not events!
Appreciating the types of issue
There are three types of issue, and you need to understand all three. You’ll find more on revising this area in Chapter 16, which covers the Change theme. Chapter 16 also has a quick quiz so you can quickly check your understanding of the three types. If you’re struggling with the types, stick with it because the problem is in the wording of the 2009 edition of the PRINCE2 manual, which is particularly poor in the area of change and issues. The 2009 manual mostly makes sense if you already understand PRINCE2, but it’s an uphill struggle if you’re trying to get to grips with the method for the first time – so don’t think it’s just you having difficulty. You might find PRINCE2 For Dummies rather easier to follow for explanation, if you have a copy to hand.