Identify Contract Deliverable Documents

(Activity) for Tier: Product

View Training

PURPOSE

Contract deliverable documents are products that need to be planned, created (written), and delivered to the customer in order to satisfy contract requirements. For each new contract or task order (TO) award, there are typically a series of deliverable documents required for delivery by the end of the specified period of performance (POP). Some of these documents may require routine updates and delivery based on certain project milestones, such as the incremental deployment of functional software. In order to meet this business need, it is important to identify these requirements and create a plan to monitor their status throughout the contract POP.

WHEN

Upon contract or task order award.

PARTICIPATING ROLES

ENTRY CRITERIA

  • The team has enough information to start identifying documents that need to be delivered and potentially when they need to be delivered.

SUB-ACTIVITIES

  1. Identify Deliverable Documents

    • Analyze the available contract artifacts (such as the SOW, PWS, and/or CDRL) to identify deliverable documentation requirements. These requirements may include product support documentation (e.g., software user manual, system administrator manual, etc.) as well as software development documents (e.g., database design description, software test report, etc.).
    • If deemed necessary, create a waiver form to record an agreement between the project team and the government customer that amends the list of contract requirements to be delivered. This form should be signed by both parties and provided to the Contracting Officer Representative (COR).
  2. Create Documentation Tasking

    • Based on the identified documentation requirements, create tasking that supports planning efforts, execution, timely delivery, and data gathering for future project estimations.
      • Planning efforts may include determining the number of technical writers needed to support a timely delivery and identifying subject matter experts who need to provide input.
      • Execution goals may include tracking lead indicators to ensure timely delivery or other quality measures.

    Note

    The default method for tracking is to create feature work items for each release, child user stories for each document in that release, and child tasks for users to track hours against each document. If a team is using an alternative method, please document in your team procedures. For example, a team may choose to use just tasks and tags. We want to support new effective ideas in this area, please provide feedback and good ideas.

    Note

    Consider managing Features, User Stories, and Tasks in a separate AzureDevOps Board so as to not to interfere with product development metrics.

EXIT CRITERIA

Note

Work items are not expected to be complete at this point, for example, hours may not have been estimated and tasks may not have been assigned.