Chapter 8
Building the Deliverables
In This Chapter
Getting a work assignment and checking it out
Building project products and getting them tested and approved
Checking and reporting on progress
Checking the acceptances and handing over completed work
This chapter is going to be short. Conceptually it is by far the easiest part of PRINCE2 and the process is the simplest of the seven, but strangely this is where the huge majority of the project’s work is done. The process covers the work of Team Managers in building products during the delivery stages and getting them tested, approved and handed back.
Understanding the Process Managing Product Delivery
If you’re reading the book in chapter order, you’ve just finished Chapter 7 covering the work of the Project Manager in controlling the stage and you’ve read about three activities to control the work assignments, or Work Packages, given to Team Managers. Those activities were to give out a Work Package, check progress as the products are built, and then receive the products back when they’re finished. The process Managing Product Delivery is simply the mirror image of those three activities, reflecting the Team Manager’s perspective. Only three activities are here and those are to receive the Work Package, build the products and then hand them back when the whole Work Package is completed. Mind-blowing in complexity, isn’t it?
As with the other chapters about processes, the process diagram, shown in Figure 8-1, comes first and the chapter then walks you through the activities involved.
Before looking at the handling of a Work Package, it’s helpful to look in a bit more detail of what one contains. It has a number of headings but the concept behind it is very straightforward: it’s an instruction pack from the Project Manager to a Team Manager asking them to build a deliverable, which PRINCE2 calls a product, or perhaps more than one if it makes sense to develop them together. The Work Package defines what products are involved and sets down any constraints and requirements for the way the work is to be done. That includes the basic and obvious things like the requirements for progress reporting.
Figure 8-1: The activities of Managing Product Delivery.
Some people’s first reaction on hearing about Work Packages is to think of them as yet more documentation and more bureaucracy. Well PRINCE2, used properly, isn’t bureaucratic and although the Work Package is indeed a document it’s a really valuable one. If something is to be built, someone has to define what that ‘something’ is and if things like progress reports are required, it obviously makes sense to set down the content needed and specify the frequency required. Work Packages contain sensible information, but as always, keep to the minimum in balance with exercising sufficient control.
In a very small project with only one team, the Project Manager may also manage the team and you don’t need a Team Manager. That is quite okay. In effect then, if you’re the Project Manager you give yourself a Work Package. The whole interface now becomes very informal to the point of ceasing to exist. Don’t stand up in your office and start talking to yourself in order to agree the Work Package and then shake hands with yourself at the end. Your colleagues will think you’re even weirder than they’d imagined.
Unpacking the Work Package
The Work Package content is logical and this section briefly explains each element of it.
Date
The PRINCE2 manual says that you put the date on which the Project Manager and Team Manager agreed the Work Package, but many people use this heading for the date on which the Project Manager actually issued the Work Package for work to begin, because these dates can sometimes be different.
Team or person authorised
This is simply who’ll build the products in the Work Package; which team it’s going to.
Work Package description
This is an outline description of the product or products included. It can be, for example, all the electrical fittings in the new office, comprising the lighting circuit product, the mains circuit product, and the standby generator.
Techniques, processes and procedures
This section simply shows how you build the product. In some types of project, particular approaches or standards may be important.
Development interfaces
The interfaces in this section tend to be communications interfaces, where the team must keep in touch with another team. You can see that this can be important, particularly in the area of change. If a team building one product in one Work Package ends up changing the product slightly, then they may need to warn other teams working on products that must fit in with it.
In computer rapid application development (RAD) projects, teams are empowered to de-scope products to fit a development ‘time box’. If a team de-scopes a product, telling other teams who are building related products is usually extremely important.
Operations and maintenance interfaces
This sets out what the product(s) must eventually fit with. That may mean that you need to specify procedural interfaces, data interfaces, electrical interfaces, or even physical interfaces where something must physically fit something else.
Russian spacecraft and the American shuttle are both able to dock with the international space station. The space vehicle designs had to comply with this physical interface.
Configuration management requirements
Explaining the configuration management, or version control, requirements is especially important when the project involves teams from different organisations. These teams are likely to have different configuration management (CM) procedures and product identification systems. How the version control will operate in the project is set down in the Configuration Management Strategy which is explained in detail in Chapter 16.
Joint agreements
The agreements set down the resource and timescales for delivery of the products in the Work Package. The Team Manager must then manage the work to deliver in line with these limits.
Tolerances
Clearly, few Work Packages go exactly to plan, just as few projects go exactly to plan. Putting a plus and minus (a tolerance) on some of these delivery requirements, notably time and cost, often makes sense. The Project Manager doesn’t want to know whether the Work Package will finish £1 over budget on a £100,000 Work Package. However, the Project Manager will be concerned if the Work Package goes £150,000 over budget and costs £250,000 against its budgeted £100,000. The tolerances specify the bands – Chapter 17 offers a full explanation of this control mechanism, which can be applied at project and stage levels as well as here, at Work Package level.
Tolerance. This is a plus and minus variation on a target, because almost nothing ever goes exactly to plan. For the Work Package, the tolerances set down the Team Manager’s delegated authority and define the point at which something must be notified to the Project Manager. For example if the Work Package is now forecast to be more than four days late.
Constraints
The constraints section sets down anything that affects how the Team Manager and the team does the Work Package. In some environments you may have security considerations that affect, for example, who can enter certain restricted areas and when. Or if building works are taking place, limits may be placed on when builders can carry out noisy work, so that the work doesn’t disrupt the functioning of the business.
Reporting arrangements
Under the heading ‘Reporting arrangements’ the PRINCE2 manual refers to the frequency and content of Checkpoint Reports, which is right, but it’s not the whole story. Taking Checkpoint Reports first, you specify the frequency and content of these progress reports in the Work Package and not in the Communication Plan.
Checkpoint Report. A progress report that a Team Manager gives to the Project Manager at the intervals and with the content specified on the Work Package.
Being able to adjust the content and frequency of a Checkpoint Report between one Work Package and another is actually very powerful. In a very high-risk Work Package, for example, the Project Manager may require a Checkpoint Report every two days. At the same time a different team working on a less critical Work Package may be asked to submit a report every two weeks. See ‘Reporting progress on the Work Package’, later in this chapter, for more details on the Checkpoint Report.
But this section of the Work Package is headed ‘Reporting arrangements’ and not ‘Checkpoint Reporting arrangements’. An important reason for this has been rather lost sight of in the more recent editions of the PRINCE2 manual. That reason is that other reporting may be needed over and above the progress reports. Other requirements may cover things such as financial reporting to know when orders are being placed and what money is being committed in which financial year. Health and safety procedures can even necessitate daily reports to confirm things such as that fire exits have been checked each day.
Problem handling and escalation
If a Work Package tolerance is going to be exceeded, this is normally reported, or ‘escalated’ using an Issue. However, if the Project Manager wants the Team Manager to use a different procedure, this is where she would say so.
Extracts or references
This section is to pass on references to relevant other documents. For example, it may reference organisational security requirements or safety requirements for this sort of work. But it also includes project-related information and specifically two things
Stage Plan extract
Usually it’s simpler for the Project Manager to give the Team Manager a copy of the whole Stage Plan rather than just an extract – the Stage Plan isn’t usually that big – or it’s a computer file. But if she doesn’t want to do that – perhaps parts of it are confidential – she can instead pass on just that part of the plan needed for control of this particular Work Package.
Product Description(s)
PRINCE2 takes a product-led or product-based approach to planning (I explain this fully in Chapter 14). Part of this planning is to write a Product Description to define every deliverable or product to be created in this stage. The Product Description describes the product together with any quality criteria it must satisfy and details of how to quality-check it. As the Work Package may be to build more than one product, more than one Product Description may be included in this section.
Approval method
This section sets down who can approve the products in the Work Package after they’ve been built and tested. Sign-off is normally very simple, but can involve things like formal acceptances and even legal acceptances. If so, the details are set down here. This section also covers how the completed products in the Work Package are to be delivered. In some cases the Team Manager can hand them back physically or electronically to the Project Manager. But you can return the product(s) in a different way, such as into an automated CM (version control) system or by delivering direct to a final location. In this case the Project Manager needs to be notified that the product or products included in the Work Package are now complete and delivered.
Project communications don’t have to be difficult. The Team Managers can notify Work Package completion by email or even phone calls. You often don’t need to be formal, even in large projects, because the delivery of the product(s) can be verified in other ways.
Building the Work Package Products
For the Team Manager, things are actually very simple in terms of the method and as mentioned at the start of this chapter, there are just three activities.
Receiving the Work Package
The Team Manager discusses the Work Package with the Project Manager and makes sure that she’s clear on requirements and can agree to it. The Team Manager must now decide if the amount of detail in the Stage Plan is sufficient to control the development of the Work Package. If it is, which is often the case, all well and good. If not, the Team Manager can draw up a more detailed Team Plan just for the work involved in this particular Work Package. This uses exactly the same approach as for all other levels of planning in PRINCE2, an approach that Chapter 14 covers in detail.
Building the products
Using the detail of the Stage Plan or Team Plan, the Team Manager gets her team working to build and test the products. The Work Package gives information on any constraints and also sets down the reporting requirements.
Reporting progress on the Work Package
The Team Manager sets up progress measuring points called Checkpoints to establish progress and ensure that she can deliver the Work Package in the agreed time.
Keeping the version control up-to-date
As products go through the different stages of their development, testing and approval, the configuration management information must be kept up to date. Each product being configuration managed has a Configuration Item (CI) Record. Depending on the instructions in the Work Package, the Team Manager may notify changes of state to Project Support who maintains the CI Record, or the Team Manager may update the record.
Checkpoint or Checkpoint Meeting. The Checkpoint to establish progress is often a meeting. Typically, the meeting is at the end of the week and the team gathers round a flip chart and reports progress made during that week. People hand in their time sheets and talk through the outlook for the next week, together with any problems. If the Project Manager is available, she may also attend the meeting, but the Checkpoint is primarily for the Team Manager to check progress with team members.
If you’re the Project Manager, getting along to at least some of the Checkpoint meetings really helps. This has two very positive benefits. The first is that on large projects you’re less distant and the team members feel that you’re more a part of the project. The second is that you can find out a lot about what’s going on in your project. This doesn’t just concern listening to what team members say when discussing the work, but how they say it. Are they upbeat or downbeat? Do they sound enthusiastic and engaged, or de-motivated and worried? PRINCE2 focuses on planning and control and doesn’t cover human factors, but the human factors – the people management – are vitally important in working towards a successful project.
The Team Manager reports the progress achieved and the outlook for the rest of the Work Package to the Project Manager, using a Checkpoint Report. As always in PRINCE2, this report can be verbal and the Work Package sets down the frequency and content.
The Checkpoint Report is all predictable stuff, but a bit over the top in a lot of projects, so you can often simplify its contents. If you use a Product Checklist at the level of a Team Plan, which products were completed and which are due for completion in the next period become self-evident.
In large projects where the Project Manager may have regular meetings with the Team Managers, she can use Checkpoints to push information out into the project as well as gathering it in. The Project Manager can use a cascade mechanism to give information to her Team Managers and ask them to tell all their team members at the next Checkpoint.
Keeping an eye on quality
As well as monitoring progress during the work, the Team Manager also checks that the right tests and checks are being performed. This is done simply by checking the entries in the Quality Register, which lists all the required tests together with space for signing them off when they’re done.
Returning completed products
When the product or products in the Work Package are all complete, the Team Manager checks them over one last time before delivering the product(s) or notifying their completion, as the Work Package instructs. The Team Manager’s final checks include looking again at the Quality Register to make sure that all the tests required for these products have been completed and signed off. The Team Manager also confirms that all approvals and any other necessary acceptances have been obtained. For example, there may be legal or technical acceptances as well as user ones.
In a multi-agency project environment, there can sometimes be a large number of people involved in approving some products. Be careful to allow sufficient and realistic time for this in Stage and Team Plans.