The Work Package – where PRINCE2 products are created
In this article, I want to describe the work package’s contents, purpose and use – 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, any work to create the specialist products must not start unless the project manager has authorised the work package. Chaos would ensue if the team decided when and what work should begin. Therefore, work packages define and control work that needs to be done and set tolerances for the team manager.
The work package within the Managing Product Delivery process passes responsibility for the work to the team manager or the team members. Dependent upon the nature of the project, a work package is carried out informally or formally and should include the work to create one or more specialist products.
Such a work package may consist of sections from, or reference to, the project plan, stage plan or project initiation documentation.
For example, the stage plan is examined to understand what products will be produced, the cost and work effort the work package will contain, and any available tolerances.
The project initiation documentation and the project controls for progress reporting arrangements should also be examined, including the quality standards that must be met. These are defined within the Quality Management Approach, and if any products are to be handed over after approval during the stage.
The Change Management Approach will lay out any handover procedures.
The project manager is responsible for authorising a work package, 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 covering the execution of one or more work packages.
Whenever the project manager takes corrective action generally in response to an issue or risk, this may result in a new or modified work package.
The team manager must review each work package to ensure they have accepted it and are authorised to begin work. If a team manager’s team plan has been created, then it should be reviewed by the project manager, or at least the milestone extracted from it if the project manager does not see the team plan contents.
As a result of accepting a work package, it may be necessary to update the stage plan and the configuration item records to show the status of the work package products are now under creation, and the plan’s quality management activities should be updated within the quality register.
If required, the risk and issue registers should also be updated as laid out within the Risk Management Approach and the Change Management Approach.
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 of those who are to create the products.
The team manager will produce checkpoint reports at the frequency and formality of each work package. The project manager will use these to ensure that the work package and the stage are on track to deliver on time, within budget, and tolerance.
For a work package to be deemed complete, all of the work should have been carried out, and the quality register entries show the products are finished, have passed their quality checks 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.
The Work package composition
The Work Package contains:
- 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
- The work effort description within the work package should include a scoping statement to clarify what should be included.
- Any particular techniques, tools, standards, processes or procedures that are to be used when creating the specialist products
- Development communication names individuals or groups who must be communicated with while developing the products to receive information from the specialist team or to give it.
- Operations and maintenance interfaces. This relates to the products created within the work package and describes how they interface with other products. These other projects may make such products or be existing products. The term interface is general; it may be a physical interface, an electrical interface, a standard protocol, or any aspect of form, fit or function.
- Configuration management requirements. This describes how those creating the products must interface with configuration management (generally 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, and 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 need 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 critical dates of the work package or milestones within it.
- Tolerances. These are optional on our work package but will be stated here if given.
- Constraints 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 regular checkpoint reports’ frequency, content, and formality.
- Problems handling and escalation. This describes all references to the procedures for raising issues or risks.
- Extracts or references. These may include excerpts from the stage plan and will always have the relevant product descriptions and quality reviews relating to the created products within the work package.
- Approval method. This will name an individual, role or group who will approve the completed product within the work package and describe how the project manager will be advised when the whole work package is completed.
- Authorisations. This may be used for signatures or the name of those responsible for the work package’s initial authorisation, its acceptance and return when completed.
Each product is first created, tested, and then checked that it meets the quality criteria, and if it passes, the right individual has authorised 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 as described above. The team manager may advise the project manager that the products are complete and 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 upon, 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 organisation.
You see, it is only when each product has been accepted by the person authorised 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 complete as a milestone within both stage and team plans, actual and unambiguous progress status can be used. Knowing exactly where you are, gives far more power to providing forecast data and considerably improves project control aspects.
Managing PRINCE2 Risks and Issues
I have written elsewhere on Projex Academy, exactly how risks and issues are to occur as based on the official PRINCE2 Manual.
I want to briefly explain some of the dynamics the project manager must be aware of.
The PRINCE2 Manual, for example, includes issues within the chapter on change control. This can lead to confusion because a particular issue needs not to do with change and therefore change control.
I’m sure in your daily life that issues arise regularly from all directions and in any particular aspect of your everyday life. Let us keep it simple and define an issue as anything unexpected and unplanned occurs. Some action will now be needed to resolve or minimise 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 likely be made considering the available tolerances agreed upon 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 needs help refining the design of a product. Maybe someone has gone sick, and a replacement resource needs to be found. There may be disagreements and arguments between two or more project members.
The above examples would come under the informal issue the project manager would typically handle.
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 generally 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 determined and the issue becomes more serious, then this fact should be entered in the daily log, and the formal route to the resolution should be 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 annual 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 needs more experience and needs to involve others to detail and determine the impact of this issue correctly.
Such individuals may be:
- Team Managers
- Specialists
- Suppliers
- Project Board members
- Project Assurance
- Operational managers
It is beyond the scope of this particular article to take you through the entire PRINCE2 issue process, as I have covered this elsewhere.
The PRINCE2 Risk Theme
Here is a definition of risk; “a risk is an event that may or may not happen in the future, but if it does, it will have an impact on the project objectives.”
So as part of risk planning, suitable responses will have been planned and included within the project and stage plan. Some types of risk responses may need action taken now to reduce the likelihood or impact of a risk.
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 occurs.
Two potential outcomes could manifest themselves here; one is that the impact of the risk is more significant than estimated, or two, that the response plan needs to have the desired effect in managing and controlling the threat itself.
If either outcome described in the above paragraph occurs, then this too may mean 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 problem, 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.
Like issues, risks must be continually monitored to add new or modified threats and manage the current risks effectively.
Risk and the Business Case
The solid relationship between risks and the business case is worth mentioning. The business case describes a balance between the project’s time, cost, and risks versus the benefits to be obtained.
Therefore, any change to the management of issues or risks has 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 cancelling the project. The Business Case contains the Benefits tolerance, which 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.
This course is DEPRECATED
The old PRINCE2 6th Edition Foundation and Practitioner syllabus was upgraded in 2024. Check out the brand NEW PRINCE2 7th Edition Masterclass, covering all the current syllabus, training material and online exam benefits HERE
Your Route To PRINCE2 6th Edition Practitioner
Study PRINCE2 6 Foundation and Practitioner Exams with our famous on-line course with streaming HD Video Lessons, study guides and mock exams. In the last fifteen years we have had 6,000+ Academy students successfully transform their careers as PRINCE2 Practitioners.
