1. Requirements

2.5.7 The project shall document software acquisition planning decisions.

1.1 Notes

This may be in an acquisition plan or in another project planning document.

1.2 Applicability Across Classes

Class F is labeled as "X (not OTS)" which means that the project is required to meet this requirement for all software that is not considered off-the-shelf.

Class G is labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement.

2. Rationale

There are many reasons to document acquisition planning decisions, not the least of which is to have a record of those decisions for future reference.

Documentation of software acquisition planning decisions is essential to project management and is important when changes to initial project formulation assumptions require renegotiation of acquisition activities. Records of decisions also serve as confirmations or reminders to project participants should any misunderstandings or conflicts arise as the project progresses. Lengthy projects with multiple development groups, including subcontractors, with the potential for changing personnel make it important to document decisions so that everyone continues to work toward the same goals using the same guidelines.

3. Guidance

When capturing acquisition planning decisions, be sure to include any related analysis that led to those decisions as that information could be important for lessons learned and future acquisition activities. The analysis typically includes the alternatives considered, the selection or evaluation criteria used to arrive at the decision, and any process used to arrive at the decision. If the team used a documented process to arrive at the decision, a reference to the process document including its location in a Center or NASA Process Asset Library (PAL), if applicable, is captured as background for the decision. Additionally, it may be useful to include the name or role of the person making or approving the acquisition planning decision for the project. All of this information will be useful to those who need to make similar decisions in the future.

When determining the information to capture, consider the following, as appropriate for the project:

• Decisions and related analysis and/or justification regarding project scope.
• Make vs. buy analysis and resulting decisions, see SWE-033.
• Information needs for monitoring the management and technical performance on the contract.
• Division of responsibilities between government and contractor.
• Selection process, including evaluation criteria, and award decision for acquired software development services, see SWE-035.
• Negotiated contract decisions and justification, including, but not limited to, negotiated decisions related to:
  • Requirements included or excluded from the contract, including tailoring of requirements.
  • Processes, activities, and tasks included or excluded from the contract or Statement of Work (SOW), see SWE-036.
  • Standards to be followed.
  • Cost and budget.
  • Risk and risk management.
  • Schedule, including milestones and reviews, see SWE-037.
  • Deliverables.
  • Acceptance criteria for deliverables, including software, see SWE-034.
  • Support from developer such as maintenance, operations, and retirement support.
• Stakeholder commitments.

Capture this information as accurately as possible in the project acquisition plan.

The following Center guidance may provide insights into acquisition planning decisions that are documented in the acquisition plan:

• Acquisition.
• Planning.
• Process Monitoring and Control (PMC).

See the Topic 7.03 - Acquisition Guidance in this Handbook for additional guidance on acquisition activities and related decisions.

When considering which decisions are important enough to document:

• Consult experienced project management personnel for advice.
• Consider the impact of the decision on the project; the higher the degree of impact on cost, schedule, safety, technical outcome, software performance, etc. the more important it is to document the decision.
• Be sure to capture controversial decisions and "command" decisions.

4. Small Projects

If an acquisition plan does not exist for the project, another project planning document, such as the Project Plan or Software Development Plan, may be used to document acquisition planning decisions.

5. Resources

5.1 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

6. Lessons Learned

No Lessons Learned have currently been identified for this requirement.