The PRINCE2 Work Package

The PRINCE2 work package.

In this article I want to describe the contents, purpose and use, of work package – but first I want to put it into context to show the part it plays within each PRINCE2 stage.

Within the Controlling a Stage process, it is vital that any work to create the specialist products must not start unless the work package has been authorized by the project manager, for if the team made their own decisions about when and what work should start, then chaos would ensue.  Therefore, work packages are used to define and control work that needs to be done and to optionally set tolerances or the team manager.

The work package is used to pass responsibility for the work to be carried out to the team manager or the team members themselves, and are used within the Managing Product Delivery process

A work package can be done informally or formally dependent upon the nature of the project, and it should include the work to create one or more specialist products.  Such a work package may include sections from, or reference to, the project plan, stage plan or project initiation documentation.

For example, the stage plan should be examined to understand what products are to be produced, and cost and work effort that the work package will contain, and any tolerances that are available.

The project initiation documentation should also be exam and to note the project controls required with regard to progress reporting arrangements, the quality standards that must be met, and these are defined within the quality management strategy, and if any products are to be handed over after approval during the stage.  The configuration management strategy will lay out any Handover procedures.

The project manager is responsible for the activity of authorize a work package, and this will be the first activity within a stage.  Work packages may be given out singularly or several at a time, and every work package must contain at least one product description.  The team manager will optionally produce a team plan, and this will cover the execution of one or more work packages.

Whenever the project manager takes corrective action normally in response to an issue or risk, then this may result in the issue of a new, or a modified work package.

Each work package must be reviewed with the team manager to ensure that they have accepted it and that they are authorize to begin work.  If a team managers team plan has been created then they should be reviewed by the project manager, or at least the milestone extract from it if the team plan contents should not be seen by the project manager.

As a result of accepting a work package, it may be necessary to update the stage plan, the configuration item records to show the status of the work package products are now under creation, the plans quality management activities should be updated with in the quality register, and if required the risk and issue registers should also be updated as laid out within the risk management strategy and the configuration management strategy.

Of particular importance is the project assurance should be consulted to ensure that the selected quality reviewers are acceptable to both from a knowledge, skills and experience perspective and that they are suitably independent from those who are to create the products.

The team manager will produce checkpoint reports at the frequency and formality laid down within each work package.  The project manager will use these to ensure that the work package and hence the stage, is on track to deliver on time, budget, and within tolerance.

For a work package to be deemed complete, all of the work should have been carried out, the quality register entries show the products are complete, have passed their quality checked and have been approved as laid out within the work package.  The project manager should also confirm that the configuration item record for each product within the work package has been updated.

I now want to describe the typical contents of a work package:

Work package composition.

• The date that the work package was agreed
   
• The name of the team manager or member of the specialist team with whom the work package has been agreed
   
• A description of the work within the work package.  It is helpful to include a scoping statement here to clarify precisely what is to be included.
   
• Any particular techniques, tools, standards, processes or procedures that are to be used when creating the specialist products
   
• Development communication.  This names individuals or groups who must be communicated with while developing the products, either that they are to receive information from the specilaist team, or to give it
   
• Operations and maintenance interfaces.  This relates to the products that are being created within the work package and describes how they are to interface with other products.  Such products may be created by this, other projects, or they may be existing products.  The term interface should be seen as a general one; it may be a physical interface, an electrical interface, a common protocol, or indeed, any aspect of form, fit or function.
   
• Configuration management requirements.  This describes how those creating the products must interface with configuration management (normally supplied by project support).  It should include aspects such as version control, obtaining copies of other products all their product descriptions, how the product is to be given to configuration management, any storage for security requirements, or if appropriate those who need to be advised of changes in the status of the work package.
   
• Joint agreements.  This will vary according to the formality and commercial environment of the work package.  In the case of a third party it may only needs to reference the contract covering the execution of the work package.  If appropriate, it will describe the amount of effort and cost of the work package, and will describe key dates of the work package or milestones within it.
   
• Tolerances.  These are optional on our work package, but if given will be stated here
   
• Constraints.  This will describe any aspects that the work package is to be constrained by.  Examples are the knowledge skills and experience of those working on the work package, security clearance requirements, rules, processes or procedures to be followed, work environments for example safety procedures, schedule or milestone timings, costs, charges, payments or external agencies that must be used for example for certification of the products.
   
• Reporting arrangements.  This covers the frequency, content, and formality of the regular checkpoint reports
   
• Problems handling and escalation.  This describes all references the procedures to be used for raising issues or risks.
   
• Extracts or references.  These may include extracts from the stage plan and will always include the relevant to product descriptions and their quality reviews relating to the products that the work package must create.
   
• Approval method.  This will name an individual, roll or group who will approve the completed product within the work package, and will describe how the project manager is to be advise when the whole work package is completed.
   
• Authorisations.  This may be used for signatures or the name of those responsible for the work package initial authorisation, its acceptance and return when completed.
  
  For more information on how to pass your PRINCE2 Foundation and Practitionber exams CLICK HERE