PRINCE2 Work Package – where products are created

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.

PRINCE2 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 specialist 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.

• Authorizations.  This may be used for signatures or the name of those responsible for the work package initial authorization, its acceptance and return when completed.

Controlling PRINCE2 Work Packages, Risks and Issues

The purpose of this article is to take you beyond the standard information that is available within the PRINCE2 official Manual, and to give you a feel of the real dynamics that occur within a typical PRINCE2 stage using the Controlling a Stage process.

In the PRINCE2 processes ‘controlling a stage’ and ‘managing product delivery’ there is a partnership between the project manager and the team manager or the team members themselves.  This partnership comes about as result of the project manager being responsible for managing the entire stage, while the team manager is responsible for ensuring that the work package is carried out.

But it goes further than that; you see what is happening here is that the team manager and the specialist team do not have the authority to carry out any work unless the project manager authorizes it via a work package.  Within the scope of the stage, the team are not allowed to carry out any work on any potential work packages unless they too are authorized by the project manager.

This may seem rather autocratic, but it is a powerful control as many times the reason why the budget is overspent is because the specialist team are doing what they think should be done rather than what they have been told to do!

Work Package Control

As an absolute minimum, the project manager may give out one work package whose scope covers the creation of all of the products within that stage.  But normally this is not the case as there is usually a logical sequence within which the work and product creation must adhere to.

So it is highly likely that several work packages will be authorized by the project manager in either a parallel or series fashion.  Suppose for example that the project manager has several teams are working within a particular stage, it is highly likely that the project manager will want to specify the exact work and products to be created by each team, and will therefore issue more than one work package at the same point in time.

Remember also, that the project may be using a third party, and they too may receive a series of parallel and/or series set of work packages (maybe at the same time that ‘internal’ work packages are given to the organisation’s own resources.

Checkpoint Report

It is the team manager’s responsibility not just to except each work package but also to agree that the products within it can be created within, for example, cost and time constraints.  But a work package contains other instructions such as creating a regular checkpoint report back to the project manager.

The checkpoint report may be a document, an e-mail, a phone call, or a face to face meeting.  Such details are laid down within the work package itself.

This means of course, that the project manager will receive many checkpoint reports at any one time and throughout the remainder of the stage time-frame.

It is worth reminding ourselves that PRINCE2 advises that the team manager or the specialist team be involved in planning their responsibilities for the coming next stage.  This would occur when planning the next stage plan before that stage plan has been approved by the project board.  The point here is that when the project manager gives out work packages and asks the team manager to approve it, it is unlikely that there will be any new surprises or disagreements.

Rather, when the project manager issues and authorizes the work package, it is seen as an opportunity for the project manager and the team manager to run through the details one more time to make sure they are clear and acceptable.

Team Plan for Work Packages

On some occasions, the team manager may wish to create a team plan that covers one or more work packages that they are responsible for.  In which case, this team plan will need to be created by for the team manager can agree to accept the work package.

The reasons for this are that the team manager will develop some form of a Gantt chart, and check that the schedule is realistic and it is feasible based on resource availability.  Again, it is likely that the team plan had been already created during the planning of that particular stage as mentioned above.

But care should be taken here, as any planning and discussions of work to be done on the next stage will likely take time and cost, and the wise project manager will ensure that such costs are available within the current stage or the next stage plans.

PRINCE2 also advises that project support will need to create new configuration item records for the products are about to be produced.

Work Package progress

The project manager will be using the checkpoint reports as one of the main inputs to creating the regular highlight report that was agreed with the project board at stage approval time.  The checkpoint reports will contain the information, structure and format as laid down within the work package.

The project manager will want to collect actual information such as work effort, cost, and the duration of the work activities.  If this is being done via time sheets, then it is likely that project support a will aggregate and report such information to the project manager.

The project manager will also want to know that the products are fully complete and that they are being produced to the right level of quality.  The project manager will want to check that the right tests are being done at the right time by the right people.  In addition, the project manager will readily check the contents of the quality register which describes what actions have been taken and what the true status of each product is.

Put simply, each product is first created, then tested, then checked that it meets the quality criteria, and if it passes, that the right individual has authorized the product as complete.

Work Package completion

When all of the products within a work package are deemed complete as explained above, the team manager will deliver those products to the project manager as part of the process activity ‘deliver a work package’.

Of course, in the real world, that may not happen exactly as described above.  It may be that the team manager merely a advises the project manager that the products are complete and that the actual products themselves are passed to someone else.

So who is this ‘someone else’?

Well, it may be the customer, the end user, a secure storage area, configuration management, or a named individual.  But what if the product is an installed set of wiring for example at a customer’s site?  In such a case, after acceptance has been performed and agreed, the team manager will inform the project manager that the product has been ‘delivered’.

All of the above points, demonstrate the control power that using the PRINCE2 methodology provides to a project and the organization.

You see, it is only when each product has been accepted by the person authorized to do so, that the product is truly 100% complete.  In this way, the frailty of human progress interpretation is neatly sidestepped.

By including the date that each product is fully complete as a milestone within stage and team plans, then true and unambiguous progress status can be used.  Knowing exactly where you are, gives far more power to providing forecast data and hence considerably improves control aspects of the project.

Managing PRINCE2 Risks and Issues

I have written elsewhere on my PRINCE2 website exactly how risk and issues are to occur as based on the official PRINCE2 Manual.

What I want to briefly explain to you here, some of the dynamics that the project manager needs to be aware of.

The PRINCE2 Manual for example, includes issues within the chapter on change control and this can lead to confusion because a particular issue needs not have anything to do with change, and therefore change control.

I’m sure in your daily life that issues arise on a regular basis from all directions and on any particular aspect of your daily life.  Let us keep it simple, and issue is anything unexpected and unplanned there is just occurred.  Some form of action will now be needed to resolve or minimize the impact of that particular issue.

When is an Issue NOT an Issue?

PRINCE2 defines that issues may be dealt with formally or informally.  The point that is being made here is that some issues can be dealt with by normal management action while others need a more structured and agreed approach.

Some degree of judgement is therefore needed.  This judgment will almost certainly be made in light of the available tolerances agreed for the stage or work package.

Informal Issues

Suppose someone has come up with a good idea which is worthy of further investigation.  Perhaps one of the engineers is having a problem refining the design of a product.  Perhaps someone is gone sick and the replacement resource needs to be found.  Perhaps there is disagreement and argument between two or more members of the project.

I would consider, that all of the above examples would come under the category of an informal issue, and that it would normally be dealt with by the project manager.  In the event that any of the above became more serious or could not be resolved by the project manager either due to their level of authority or by the severity of the issue, then at that point in time, it should be dealt with formally.

To deal with an informal issue, the project manager would normally make a note in the daily log, and at the point in time when it is resolved enter that data into the daily log as well.  If as mentioned above it cannot be resolved and the issue becomes more serious, then this fact should be entered in the daily log, and the formal route to resolution taken.

Formal Issues

Let me now discuss if the issue needs to be managed formally.

The first step is for the project manager to place details of the issue within an issue report.  This information must also be entered into the issue register where the lifetime of actions of that specific issue will be logged.

The next step is to carry out an impact analysis.  This will often mean that the project manager does not have sufficient experience and needs to involve others to correctly detail and determine the impact of this issue.

Such individuals may be:

• Team managers
• Specialists
• Suppliers
• Project board members
• Project assurance
• Operational managers

Based on the impact, this may mean that the project manager needs to escalate it usually because the issue or its corrective actions will cause stage or project tolerance to be exceeded.  However the reason for escalation may be because the project manager sees it as sensible to involve the next management level.

It is beyond the scope of this particular article to take you through the entire PRINCE2 issue process as I have covered this elsewhere.

PRINCE2 Risks

Here is a definition of a risk; “a risk is an event that may or may not happen at some point in the future, but if it does, it will have an impact on the project objectives”

So is part of risk planning, suitable responses will have been planned and included within the project and stage plan.  Some types of responses may need action taken now as a way of reducing the likelihood or impact of a risk.  So you could see, but if such actions taken now did not seem to have the desired effect, then it could manifest itself as a new issue to be dealt with as explained above.

Other types of responses may only come into play if, and only if, the linked risk actually occurs.  Two potential outcomes could manifest themselves here; one is that the impact of the risk is greater than estimated, or two, that the response plan is not having the desired effect in managing and controlling the risk itself.

In either outcome described in the above paragraph occurs, then these too may mean that a new issue is raised using the formal process described above.

So you can see that there is a clear relationship between risks and issues.  But the relationship may also occur in reverse.  For example, suppose that a new issue, its impact, or the actions taken, may give rise to a new risk, or modification (for example greater probability or impact) of an existing risk.

Just like issues, risks must be continually monitored so that new or modified risks are added, and the current risks are being managed effectively.

Risk and the Business Case

It is worth mentioning the very strong relationship between risks and the business case.  The business case describes a balance between the time, cost and risks of the project verses the benefits to be obtained.

It therefore follows that any change to the management of issues or risks, have the potential to impact the business case even to the point where it ceases to be a viable undertaking.  In such an extreme, the project board may need to consider pausing, modifying the scope, or even cancelling the project. The Business Case contains the Benefits tolerance, and this may now be exceeded.

Just as the PRINCE2 Manual states, as part of any impact assessment of either risks or issues, the impact on the business case must be included and considered so that an informed choice should be made on what to do next.