Do you have work package descriptions for your project? Many of you will answer with “No”. “Such a thing is not necessary and only an over-organization!” I often hear that. Many project managers underestimate the benefits of good work package descriptions. But with little effort, you can bring more security to your project, increase quality, and improve project monitoring. Even with agile projects, there is a description for each user story. Isn’t that a reason for you to deal with the work package description once again? I would say, this is just good project management! Read on and learn more!
From Project Goals to the Work Package Description
Planning is the mental anticipation of future events. The planning should show the way in which the goals of the project are to be achieved. The following illustration shows you the 3 levels of project planning a typical project is passed through—the lower the level, the more often it is passed through.
The Work Breakdown Structure (WBS) divides the project hierarchically into sub-projects and subtasks. Its branches end with the work packages, which are not broken down further within the work breakdown structure. The elements of a work package are called activities or tasks. The PMBOK attaches particular importance to the fact that a work package is always bound to a deliverable.
In contrast to the WBS elements above it, each work package is a real, self-contained task in the sense of work. This work is carried out by a single person or organizational unit, up to a defined time with defined result and effort. Normally it is a task that consists of individual elements, but from the point of view of project management it does not have to be considered individually, but can be handled as a package. Each work package must have a work package manager. A work package can thus be considered a “mini-project” within the project.
Planning is the mental anticipation of future events. The planning should show the way in which the goals of the project are to be achieved.”
Work Package or Activity?
The work package description systematically continues the planning process at the lowest level. It is the basis for defining the activities that are necessary to complete a work package. The work package description also serves as a basis when you create detailed schedules and cost plans. The Gantt diagram and the network diagram arrange the work packages with logical relationships to the project schedule. It can also be useful to view individual activities (subtasks) within a work package. The following variants are possible when creating the activities:
- A work package corresponds to one activity
- A work package contains several activities (normal case)
- Several work packages are combined into one summary activity
The work package manager and his team define activities and carry out all other planning work.
Microsoft Project does not know the term work package, only task and summary task. Depending on the level of detail of your project schedule, a work package then corresponds to a task or a summary task.
How large should a work package ideally be? Learn more about the right work package size and duration.
The work package is not completed until the result is available and has been approved by the project manager or quality assurance. However, the acceptance can only be carried out in a meaningful way if measurable quality criteria are defined in the work package description.
The Work Package Description
Once you have defined the work breakdown structure and work packages, the next deeper planning step follows. Now you have to think about how to create the results/deliverables you defined in the work package.
A work package is not a black box with a title on the work breakdown structure. Now you think about how it will be implemented and record these thoughts in the work package description. The work package description defines:
- what is to be created (the result)
- how it is created (the main activities for this)
- what you need (resources, time, budget)
- Assumptions, dependencies, restrictions, and what could happen (risks)
A work package description does not give much work, and yet the work package manager and his team members (if he/she has) should take the time to plan the work package and collect the essential information.
The Contents of a Work Package Description
The following elements should be included in every work package description:
- Project name: Preferably a short name such as DILI or PAKT
- Work package ID: Each work package has a unique number. The PSP-code is often used here. I do not find this ideal and simply use a consecutive number. This can also contain a project name, e.g. DILI-243
- Creation date
- Work package title: Name of the work package in a few words. Can also be used as file name.
- Work Package Manager: Person who is responsible for the implementation of the work package.
- Subproject: To which subproject the work package belongs
- Short description of the work package: A few sentences so that everyone understands what the work package creates and what the context is.
- Detailed description of the work package: What are the deliverables and what are the specific and measurable requirements that the deliverables must meet.
- Implementation of the work package (activities): How are the deliverables created. Here a list of activities with efforts and responsibilities can be defined.
- Dependencies on other work packages: Is the work package dependent on supplies or results from other work packages?
- Risks: What are the risks involved in implementing the work package?
- Required resources: Who, from which areas/departments, and with what effort are necessary to implement the work package? Which material is necessary and at what cost?
- Estimated total costs
- Acceptance of the work package: How is the work package accepted and what are the acceptance criteria?
- Referencing documents: Where is further information available?
I would not put the desired date on the work package description. This can be taken from the project schedule and probably changes several times.
Here you find a Microsoft Word template for a Work Package Description
The Work Package Description for Agile Projects
Agile projects have the claim to be unbureaucratic and efficient. But there are also (small) work packages—called User Stories. Each user story includes a description of what is to be implemented and what the benefit for the customer should be. Traditionally this is written on index cards, and often also additional software tools.
User Stories are software requirements formulated in everyday language from the user’s perspective. A user story is deliberately kept short and usually comprises no more than two sentences.
On the front side of the card, for example, you write:
- The story ID
- Story title
- The story description (the requirement)
- the priority
- the size of the story (in story points)
- Name of the developer who implements the story
On the back of such a card you will find e.g.:
- The acceptance criteria (a user story must be verifiable)
- Dependencies to other stories
- The risk level of the story
- Notes and points to consider when implementing the story
Learn more about User Stories in Agile Projects
Where to Place the Work Package Description?
A work package description is best entered in Microsoft Word or any other similar program, but can also be entered directly in a project management software if one is suitable. In my opinion, this would be the better solution.
I prefer a Microsoft Word document, which I then store in a document library in SharePoint. Here I can then add additional metadata, such as progress level, release, etc.
How to Store the Work Package Description in Microsoft Project
Microsoft Project offers three different ways to store detailed work package descriptions:
- In the “Task Information” section of the “Notes” tab, you can enter the work package description directly using the (simple) text editor.
- In the “Task information”, you can “Insert object” in the “Notes” tab. Select “Create from file” and check the “Link” and “Show as icon” boxes. This is how you link an already existing Word document with the work package description.
- Insert the work package description as a hyperlink. To do this, define a new column with the column title “Hyperlink” in the Gantt view. Then insert the link to the document with the work package description in the Hyperlink column of the relevant work package by right-clicking on the empty field and selecting the “Hyperlink” menu item at the bottom.
The Benefit of the Work Package Description
The benefit of a detailed work package description is often underestimated, and the somewhat greater effort involved is dismissed as over-administration. Here are the most important benefits of a work package description:
- The work package description systematically continues the planning process at the lowest level.
- The person responsible for the work package and his team think intensively about how the result will be achieved – and this is recorded in writing.
- The work package description is the central source of information when the work package is implemented.
- The work package description is an important element of project controlling and quality management.
If you are not yet writing work package descriptions for your project, I hope I could motivate you to do so in the future. The small additional effort is really worth it.
Do you know somebody who might be interested in this article? Then simply forward it or share it. Thank you!
