Work package: Difference between revisions
Ceopediabot (talk | contribs) m (→Important notes: typos fixed: and and → and) |
m (Infobox5 upgrade) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
'''[[Work]] package''' is the lowest '''work breakdown structure''' level. At this level, the [[project]] manager can designate the resources and record development, without getting stuck in too much detail (James Taylor, 2008, p.46) | '''[[Work]] package''' is the lowest '''work breakdown structure''' level. At this level, the [[project]] manager can designate the resources and record development, without getting stuck in too much detail (James Taylor, 2008, p.46) | ||
==80-hour rule== | ==80-hour rule== | ||
The question often asked: "How big or how small should the work package be?". There is no quick and solid answer to that question, but one ground rule is to be sure that every '''work package''' is small enough to be designated to an individual and small team. Second one is that called an '''80-hour rule'''. It means that any '''work package''' must not exceed 80 hours of work. This rule is used by the '''Project [[Management]] Institute''' as a ground rule to help determine the size of '''work package''', but often some tasks require more than 80 hours of work to complete. In those instances, it would be the best to assign secret milestones to the task to break it into parts that are easier to be monitored and controlled (James Taylor, 2008, p.46). | The question often asked: "How big or how small should the work package be?". There is no quick and solid answer to that question, but one ground rule is to be sure that every '''work package''' is small enough to be designated to an individual and [[small team]]. Second one is that called an '''80-hour rule'''. It means that any '''work package''' must not exceed 80 hours of work. This rule is used by the '''Project [[Management]] Institute''' as a ground rule to help determine the size of '''work package''', but often some tasks require more than 80 hours of work to complete. In those instances, it would be the best to assign secret milestones to the task to break it into parts that are easier to be monitored and controlled (James Taylor, 2008, p.46). | ||
According to '''James Taylor''' "If, on the other hand, while working on plans for costs, schedules, and resources, there is a [[need]] to consider part of '''work package''' in one place and another part later or someplace else, it is probably more than one '''work package''' and requires reexamination to correctly identify the work". | According to '''James Taylor''' "If, on the other hand, while working on plans for costs, schedules, and resources, there is a [[need]] to consider part of '''work package''' in one place and another part later or someplace else, it is probably more than one '''work package''' and requires reexamination to correctly identify the work". | ||
| Line 22: | Line 8: | ||
Every single [[action]] required by the '''scope statement''' must be wrapped in a '''work package''', occasionally referred to as an '''activity''' or a '''task'''. "If something is not in a work package, it should not be done" - quote by James Taylor. Certainly, there are individual segments and work efforts that are at lower heights than the '''work package''', but these should not be distinct in '''work breakdown structure'''. Some of these [[information]] ought to go into '''work breakdown structure's''' dictionary. The important note is that: | Every single [[action]] required by the '''scope statement''' must be wrapped in a '''work package''', occasionally referred to as an '''activity''' or a '''task'''. "If something is not in a work package, it should not be done" - quote by James Taylor. Certainly, there are individual segments and work efforts that are at lower heights than the '''work package''', but these should not be distinct in '''work breakdown structure'''. Some of these [[information]] ought to go into '''work breakdown structure's''' dictionary. The important note is that: | ||
* If a '''work package''' is not big enough, it will be micromanaged. | * If a '''work package''' is not big enough, it will be micromanaged. | ||
* On the other hand, if it is too immense project monitoring and control will be troublesome | * On the other hand, if it is too immense project [[monitoring and control]] will be troublesome | ||
(James Taylor, 2008, p.46). | (James Taylor, 2008, p.46). | ||
| Line 37: | Line 23: | ||
* Confirm that the discharge for the delivered '''work package''' has been acquired. | * Confirm that the discharge for the delivered '''work package''' has been acquired. | ||
If the '''work package''' is being completed by independent workers, then the signing off of the delivered '''work package''' by the project manager happens when any financial payments, for instance invoices, are approved and paid (Hans Fredriksz, Bert Hedeman, Gabor Vis van Heemst, 2010, p. 148). | If the '''work package''' is being completed by independent workers, then the signing off of the delivered '''work package''' by the project manager happens when any financial payments, for instance invoices, are approved and paid (Hans Fredriksz, Bert Hedeman, Gabor Vis van Heemst, 2010, p. 148). | ||
{{infobox5|list1={{i5link|a=[[Critical chain method]]}} — {{i5link|a=[[Baseline schedule]]}} — {{i5link|a=[[Project initiation]]}} — {{i5link|a=[[Validation master plan]]}} — {{i5link|a=[[Stages of project]]}} — {{i5link|a=[[Product backlog]]}} — {{i5link|a=[[Scope of work]]}} — {{i5link|a=[[PMBOK framework]]}} — {{i5link|a=[[Preparation of project]]}} }} | |||
==References== | ==References== | ||
Latest revision as of 04:54, 18 November 2023
Work package is the lowest work breakdown structure level. At this level, the project manager can designate the resources and record development, without getting stuck in too much detail (James Taylor, 2008, p.46)
80-hour rule
The question often asked: "How big or how small should the work package be?". There is no quick and solid answer to that question, but one ground rule is to be sure that every work package is small enough to be designated to an individual and small team. Second one is that called an 80-hour rule. It means that any work package must not exceed 80 hours of work. This rule is used by the Project Management Institute as a ground rule to help determine the size of work package, but often some tasks require more than 80 hours of work to complete. In those instances, it would be the best to assign secret milestones to the task to break it into parts that are easier to be monitored and controlled (James Taylor, 2008, p.46). According to James Taylor "If, on the other hand, while working on plans for costs, schedules, and resources, there is a need to consider part of work package in one place and another part later or someplace else, it is probably more than one work package and requires reexamination to correctly identify the work".
Important notes
Every single action required by the scope statement must be wrapped in a work package, occasionally referred to as an activity or a task. "If something is not in a work package, it should not be done" - quote by James Taylor. Certainly, there are individual segments and work efforts that are at lower heights than the work package, but these should not be distinct in work breakdown structure. Some of these information ought to go into work breakdown structure's dictionary. The important note is that:
- If a work package is not big enough, it will be micromanaged.
- On the other hand, if it is too immense project monitoring and control will be troublesome
(James Taylor, 2008, p.46).
Deliverance of a work package
The deliver of a work package action outlines the turning over of the work package to the Project Manager and attaining discharge for the work package concerned.
The actions that the team manager has to accomplish to deliver the work package are:
- Confirm that all related activities from the quality register have been completed;
- Confirm that all deliverable products have been permitted and allowed;
- Confirm that all quality files have been provided to project support and if the quality register and the configuration item records have been updated appropriately;
- Confirm that work package has been completed by updating the team plan;
- Confirm that the delivered products have been handed over and inform the project manager about this in keeping with the agreements specified in the work package;
- Confirm that the discharge for the delivered work package has been acquired.
If the work package is being completed by independent workers, then the signing off of the delivered work package by the project manager happens when any financial payments, for instance invoices, are approved and paid (Hans Fredriksz, Bert Hedeman, Gabor Vis van Heemst, 2010, p. 148).
| Work package — recommended articles |
| Critical chain method — Baseline schedule — Project initiation — Validation master plan — Stages of project — Product backlog — Scope of work — PMBOK framework — Preparation of project |
References
- Fredriksz H, Hedeman B, Vis van Heemst G, (2010), Project management based on Prince2® 2009 edition, Van haren publishing, Netherlands
- Trendowicz A, Jeffery R, (2014), Software project effort estimation: foundations and best practice guidelines for success, Springer, Switzerland
- Taylor J, (2008), Project scheduling and cost control: planning, monitoring and controlling the baseline, J. Ross publishing, USA
Author: Jakub Winiarski
