Product Selection Report

Definition

A product selection report is the architecture and environments work product that reports the results of commercial vendor and product evaluation, comparison, selection, and acquisition.

Objectives

The typical objectives of the product selection report are to:

• Report the results of the evaluation, comparison, and selection of commercial products and their vendors.
• Enable the architecture team to perform the technology vendor selection and physical architecture production tasks.
• Enable the environments team (supported by the process team) to perform the vendor and tool evaluation, selection, and acquisition tasks.

Benefits

The typical benefits of the product selection report include:

• It helps ensure that due diligence was taken in the evaluation of the commercial off-the-shelf (COTS) products (e.g., data components, hardware components, software component, and software tools).
• It helps ensure that the best (e.g., quality, feature set, cost, availability) products are evaluated, compaired, selected, and acquired.

Contents

The typical contents of the product selection report are:

• Product Category:
  (including objectives, common capabilities, requirements, and product evaluation approach)
  • Product Evaluations
    (including vendor size, reputation, financial security, longevity, and website as well as associated product capabilities, quality, industry usage, and cost breakdown)
  • Product Comparison
    (including strengths, weaknesses, differentiators, and costs possibly in the form of a spreadsheet, matrix, or table)
  • Product Selection
    (including selected vendors, products, tools, and rationales for the selection)
  • Product Acquisition
    (including contact information, cost and payment information, acquisition schedule, and shipping information such as carrier, planned ship date, shipping cost, and receiver)
• Appendices
  • Major Issues
    (e.g., potential product limitations, availability of budget and staffing for due diligence during product evaluation, and dependencies on other tasks and work products)
  • TBDs
    (incomplete parts of the document with estimated dates to be completed)
  • Assumptions
    (e.g., available budget for evaluation and purchase of components, planned future availability of required component capabilities)

Stakeholders

The typical stakeholders of the product selection report are:

• Producer:
  • Architecture Team
  • Process Team
  • Environments Team
• Evaluator:
  • Architecture Inspection Team
  • Environments Inspection Team
• Approvers:
  • Technical Leader
  • Project Manager
  • Customer Representative
• Maintainers:
  • Architecture Inspection Team if it is for components of the application
  • Process Team if it is for components of the environments
  • Environments Team if it is for components of the environments
• Users:
  • Project Management Team, which uses it to help determine the cost of (and to procure) the selected products
  • Customer Organization, which uses it to understand the products that they are procuring (and their vendors)
  • Architecture Team, which uses it to produce the system architecture document
  • Process Team, which uses it to ensure that appropriate software tools to support the project process are evaluated
  • Environments Team, which uses it to produce the project environments description document

Phases

• Business Strategy: Not applicable
• Business Optimization: Not applicable
• Initiation: Completed
• Construction: Maintained
• Delivery: Archived
• Usage: Archived
• Retirement: Archived

Preconditions

The product selection report can typically be started if the following preconditions hold:

• The initiation phase is started.
• The architecture team is adequately staffed and trained in data, hardware, and software product evaluation, comparison, and selection.
• The environments team is adequately staffed and trained in tool evaluation and selection.
• Adequate funding, staffing, and schedule is available for product evaluation, comparison, and selection.

Inputs

The typical inputs to the product selection report include:

• Work Products:
  • Master Schedule, which constrains the schedule in evaluating vendors and products
  • System Requirements Specification, which documents the operational, data, and quality requirements (and design constraints) that the physical components of the application must help implement
  • System Architecture Document, which documents the physical components of the application
  • Project Environments Description Document, which documents the various environments requiring software tools
• Stakeholders:
  • Requirements Team, which clarify requirements for the application components to be selected and acquired
  • Architecture Team, which supply required criteria for the application components to be selected and acquired
  • Process Team, which specifies requirements for the support the project process
  • Configuration Management Team, which specifies their needs for the support of the configuration management activity
  • Integration Team, which specifies their needs for the support of the integration activity
  • Independent Test Team, which specifies their needs for the support of the system testing activity
  • Security Team, which clarifies security mechanisms to be implemented by the environments
  • User Experience Team, which specifies their needs for the support of user experience tasks (e.g., graphics and multimedia software tools and any associated hardware components such as recording and digitizing equipment)
  • Product vendor representatives and domain experts (consultants, methodologists, and industry analysts), who provide input on commercial products to be potentially incorporated into the application or various environments

Guidelines

• Parts of this document may be reused from project to project if the development organization evaluates commercial data, software, and hardware components and tools at the organizational level.
• Parts of this document may be included by reference to other documents (e.g., industry reports and commercial reviews of products).
• This is a living document that is developed incrementally and iteratively in parallel with other work products (e.g., the system architecture document and project environments description document).
• Different parts of this document may be due at different times. For example, tools for the development environments are typically evaluated and documented before those for the production environments.

Conventions

The product selection report is typically constrained by the following conventions:

• Content and Format Standard
• MS Word Template
• XML Template
• Inspection Checklist

Examples

• Example Product Selection Report