5

Could someone give me the information about how one structures the s.c. "work packages"? I have never done this before but that's my task now. I need to describe use-cases, preliminary definitions, example workflows of the application, goals, I/O of the application, requirements etc. Does someone have a sample document with "work packages" or a link to some corresponding resource in the Web?

This is for a software development project.

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
azerIO
  • 153
  • 1
  • 1
  • 3
  • Are you by any chance confusing a work package with a work breakdown structure? – Jesse Nov 23 '11 at 17:33
  • I don't know for sure whether its the right term I've used. I took it from an English version of the German Wiki Page "Arbeitspaket". – azerIO Nov 23 '11 at 18:33

3 Answers3

4

A work package is typically the lowest level of your WBS. It is the level at which you are able to adequately estimate the required resources: human, materiel, time. The package itself is usually described in the WBS Dictionary. This artifact would detail for a package its target costs, the planned start date and finish date, dependencies, inputs and outputs, verification and validation criteria, who is accountable, resources involved, and risks and mitigation / contingency information. Information that goes into the dictionary are the things the package manager needs to know. Keep it simple and short but make sure it is comprehensive enough such that a replacement package manager can read it and go.

Is this what you are talking about?

David Espina
  • 37,143
  • 4
  • 34
  • 91
  • Yes, that is it. Almost. In case of software design I need also to include the design of the system, its use cases and requirements. – azerIO Nov 24 '11 at 10:47
  • I am assuming your system design, use cases, and requirements are separate project artifacts. You can include in the dictionary a table that allows the reader to map back to the 3 artifacts to which that package is associated. The point is, design your dictionary template so that it is useful to you. – David Espina Nov 24 '11 at 12:12
1

The default PRINCE2 template is located at this location, just click on the link to "Download the PRINCE2 Templates". This will open a zip file that includes work package documentation among others.

Doug B
  • 8,899
  • 17
  • 40
0

Wikipedia provides a definition of work packages. @DavidEspina provided a better definition. The things you think you need "use-cases, . . . requirements" are not characteristics of work packages. I think you may need to take a step back and figure out what you really need.

There is considerable variety in how people define work packages. My practice, based on the advice of my mentor and the best practices I have seen in the industry is:

  1. Less than 40 hours of effort, but more than 1 hour of effort. 0 hours of effort is a milestone, not a work package
  2. Produces a single complete object/deliverable. e.g. "set of requirements"
  3. Described by an active verb and predicate. e.g. "Define Requirements"

  4. Cannot be decomposed further without breaking the rules. "e.g. "define requirements" could theoretically be broken down in to "define first requirement", but "first requirement" isn't a single deliverable, it is a partial deliverable

    • Define requirements is frequently a work package
    • I/O is probably not a work package - Although in some cases writing the I/O portion of software might be a deliverable, in the general case, I prefer that the deliverable have a stronger tie to value to the customer.
    • Example workflows .... Depending on the size & complexity of the application, there are situations where this might be a deliverable, but in general, capturing workflows is a technique to define requirements.
    • Use cases - almost always a tool to develop/capture/ requirements.

As I said at the beginning, I'm not sure we understand what you are really asking for.

MCW
  • 8,718
  • 2
  • 28
  • 48