This guideline provides guidelines for detailing work products (artifacts, outcomes and deliverables). For general detailing guidelines that are common to all method elements, see Guideline: Detailing Method Elements (General).

Keep in mind the following guidelines when completing each of the work product-specific text fields (for guidelines regarding the common fields, see Guideline: Detailing Common Method Element Fields):   

• Purpose: The Purpose field describes the reason for the method element. For example, for a Work Product:  
  • Why is the work product produced? 
  • How will it be used?  

Do not repeat text already stated in other fields, such as the brief description or the main description.

• Main description. This field is optional for work products. It contains a detailed description of the work product if the Brief description and Purpose is insufficient. If the work product has significant state, include a state machine (i.e., a description of the states and their transitions) in the artifact's Main description.

• Key Considerations: This field is optional.  It contains useful material that does not easily fit into any of the other sections, such as advice and guidance of a critical nature, as well as warnings, cautions, pitfalls and dangers.

• Impact of not having: List and briefly describe the consequences of not producing this work product. Consider this from the delivery practitioners’ point of view. If the work product was not available, what would be the impact to the execution of the project? What information would the practitioners not have that they need? Write a short description of the impact.

• Reason for not needing: List the conditions when the work product might not be needed, and why. Is the information available somewhere else? Is it of secondary importance to other work products? Is the project small enough that it is not relevant? Write a short description of the normal reasons why the work product may not be needed.
  
• Guidance: Guidance can be associated to a task to provide further details about the work product. The type of guidance that is usually associated with a work product includes checklists, examples and templates. For information on these associations, see Guideline: Defining Method Content Elements.  

For work-product-type-specific guidelines, see the following sections.

Detailing artifacts

The following fields are artifact-specific:

• Brief outline: This field is optional. It describes the major sections or information topics that are covered by the work product. This information should be generic, in other words, not specific to any particular format or template.
    
• Selected representation: This field is optional. It is used when a particular representation is decided on. For example, a particular company may mandate the use of a particular tool or format. 
  
• Notation: This field is optional. It describes any notations used by the work product. Either Brief outline or Notation should be provided, or both [*** I got this last sentence from the template, but I am not sure what it means.  Should it be "not both"? ***]  This field may also contain explanations of any diagrammatic or textual notations. Include notations that are important or special terms, labels, headers, acronyms, etc. that are used in the artifact. Any items relating to how this is implemented in a specific template should be included in the description for that template, not here. Note this section should be general enough to apply regardless of the actual representation option selected, unless there are multiple notations such as IDEF1X or UML, in which case an overview of each can be included (preferably as contributions from the related techniques).
   
• Representation options: This field is optional. Describe alternative representations for this work product.
  

Detailing deliverables

The following fields are deliverable-specific:

• External Description: This field is intended to be a description of the deliverable that the client will read. It is usually copied into a Statement of Work or other agreement, or into sales and marketing material with a client. The content of this field may require legal approval of some sort. Seek guidance from the method authoring consultant. Keep to a description (what the deliverable is) rather than its use in an engagement. Build on the purpose but differentiate between the what and the why of the deliverable. The description is about what the deliverable is. The description must be understood by potential clients.
• Packaging Guidance: This field is intended to give an overview of the notation for the deliverable. For a root deliverable from which other will be derived, the packaging guidance should indicate the preferred notations. Note the plural here in that there may be several notations. The packaging guidance should provide a synopsis of them. For derived deliverables, variability can add details to notation and they can become more focused. The packaging guidance must account for the availability (or not) of a complete set of input work products. Depending on the configuration tailoring on a particular engagement, all input work product may not be available. Be aware of the purpose and governance level of the deliverable being defined when outlining notation. [*** Describing how the inputs are assembled into a deliverable including what particular sections may be relevant and what the expected state of those inputs should be along. Explicit guidelines on the formatting may be better included via a customization for that project of standard guidelines for a project that applies to all deliverables as defined in the agreement. ***]
• Deliverable Parts: Identify the work products that will be used to construct the deliverable.

Detailing outcomes

The following fields are outcome-specific:

• None at this time.