Availability: If you don't know the availability of COTS products that meet functional requirements before you begin development, then the estimated development cost and schedule are highly uncertain.

• Conduct market research per DOD Standardization Document 5 (SD 5), Market Research: Gathering Information about Commercial Products and Services
• Solicit industry inputs (e.g., Request for Information, industry day, demonstrations).
• Encourage vendors to change product capabilities and performance to meet your requirements only if the change will be incorporated into the commercial product.

Functionality and Performance: If the actual functionality and performance of a COTS product are not as advertised, then the system may not meet its requirements.

• Ask vendors to conduct demonstrations.
• Evaluate through prototyping.
• Consult other users with similar requirements to see what their experiences have been with the product.

Requirements Gap: If the COTS product does not match the current operational requirements or procedures and these can not be changed, then the COTS product can not be used.

• Re-evaluate user requirements by keeping the user involved in trade-offs between COTS functionality, requirements, and cost and schedule.
• Encourage user to consider changing operational processes to match those embedded in COTS products.
• Maintain an up-to-date Operational Requirements document, especially to avoid failing operational testing.
• Document requirement and operational procedure deviations.
• Consider using a non-COTS solution rather than modify the COTS product so it deviates from the commercial product

Security and Safety Issues: If there are stringent security requirements, it may not be possible to certify that the product meets requirements because the COTS product must be tested as a black box without its implementation

• Analyze the vulnerability of the system due to untrusted COTS components and determine if the system can be designed to reduce the vulnerability to an acceptable level or else use custom software at the key points of vulnerability.

Conformance to DOD Standards: If conformance to DOD technical standards is not supported by the COTS product, funding may be jeopardized or the COTS product may not be acceptable.

• Make every effort to find candidate COTS products that comply with current, relevant standards.
• Investigate ways to obtain waivers or to add the product to accepted standards.
• For Mil-Standard requirements on hardware, determine if COTS equipment that cannot meet these rigorous requirements can be packaged in an environment that insulates it from the more demanding conditions.

Conformance to Commercial Standards: If candidate COTS products do not conform to commercial standards, then interoperability with other selected COTS products may be difficult, costly, and time consuming or impossible.

• Choose COTS products that have interfaces that conform to well-known, well-defined standards that are widely used.
• Establish and maintain an integration facility to verify conformance.
• Determine if results are available from other verification or operational activities.

Integration Contractor's Capability: If the contractor does not have the technical experience to deliver a COTS-based system, then the system may not meet requirements, cost, and schedule.

• Specify contractor selection criteria to include demonstrating experience with selecting, integrating, and testing COTS products.
• Make sure the contractors are familiar with the specific COTS products they proposed.
• Determine the contractor’s ability to perform COTS-based system engineering (e.g., past performance).
• Ensure that the contract's configuration management capability can track versions of COTS products.

Quality Requirements: If a candidate COTS product does not meet quality requirements (e.g., reliability, performance, usability) then cost, schedule, and operational capability may be impacted.

• Use market research to determine size and satisfaction of customer base.
• Conduct demonstrations, prototyping before final selection.
• Consult other users with similar requirements.

Adaptability: If candidate COTS products do not fully support initial and evolving requirements and do not have built-in flexibility, then custom code may be needed or the product may be difficult to integrate with other products and may become unsuitable as the system changes.

• Assess ability of COTS products to be adapted, tailored, extended, and integrated.
• Determine how "open" the application programmer interface (API) is for adding capability and integrating with other products.
• Evaluate tools available to tailor a COTS product.
• Do not modify code of COTS products.
• Do continuous market research for alternatives and market trends throughout the system’s life cycle.
• Take a pro-active role in influencing commercial standards so that commercial products will better integrate into military systems.

Portability: If a candidate COTS package is not supportable across a variety of hardware and operating system platforms, then hardware platform choices over a program lifecycle may be limited.

• Select portable COTS products that can run on a broad-spectrum of platforms or can be easily implemented for new platforms
• Check the vendor's record for moving to new platforms and operating systems.

Sustainment: If market research is not conducted and new COTS products and technology are not considered, then there may be missed opportunities to introduce new technology.

• Use market research to track technology trends, anticipate future products releases, vendors' plans.
• Participate in beta tests of new products and versions in the integration lab.
• Perform cost/benefit analysis for replacement, e.g., impact on licensing, other system software affected, operator interfaces and procedures, training, performance, other sustainment costs.
• Involve users if operational capabilities, operator interfaces, interoperability affected.
• Plan for security recertification.
• Plan capability delivery schedule to coincide with emerging product releases to the extent possible.
• Plan for replacement, upgrades at regular intervals.

Evolution: If new hardware upgrades or replacements are not compatible with current COTS software products, then COTS software products may have to be replaced at the same time.

• Coordinate plans for hardware upgrades with software upgrades.
• Evaluate hardware and software upgrades together in the integration lab.
• Determine vendor plans for COTS product compatibility with hardware.
• Do not count on vendor delivery schedules for achieving hardware compatibilities.
• Accept shorter lifespans for COTS. Sometimes, throwaway is a realistic part of evolution.

Source Code: If there is no access to source code, then it may be difficult to trace integration and testing problems to COTS products.

• Plan to have COTS vendors provide product and debugging support.
• Develop alternative methods and tools for system fault diagnosis.

Security: If security requirements are levied, then integration of COTS products may introduce security vulnerabilities.

• Select certified products in accordance with the system requirements if such products are available.
• Design the system to encapsulate the non-secure products and limit the vulnerabilities they create.
• Plan for the certification of the integrated products.
• Use custom software or hardware components when the security of COTS products cannot be assured and will make the system unacceptable.

Upgrades: If upgrades to COTS software increase the size of the programs or the files they produce, the size of the hardware memory in the system may be insufficient and may have to be replaced or upgraded.

• Plan for large size growth in COTS software upgrades. Buy large amounts of spare memory initially.
• Make sure hardware and system architecture have a growth path.

Acquisition Alternatives: If alternative methods of acquiring COTS products are not evaluated, then the cost may be unnecessarily high.

• Evaluate alternatives for licensing such as third party vendors.
• Seek licensing terms that give the most favorable conditions based on requirements and utilization, e.g., number of users, number of CPUs.
• Choose the appropriate time to buy COTS products in volume to assure latest technology at installation.

Vendor Reliability: If a vendor of a candidate COTS product is financially weak or unstable, then the product may have poor support or become unsupported, potentially leading to unexpected or unplanned cost and schedule slips.

• Assess vendor’s market share and financial status.
• Evaluate vendor’s history of product support.

Cost and Schedule Completeness: If cost and schedule estimates do not consider all the ongoing costs of acquiring a COTS-based system, then the system may not be adequately funded.

• Consider market research results when developing estimates for initial cost.
• Include cost of integration lab, license renewals, continuing market research, version upgrades, etc. in annual budgets for development as well as support.

Business Skills: If the vendor relationship and business skills of the contractor are weak, then system component costs and licensing may be more costly than necessary.

• Assess ability of contractor to establish business relationships with vendors, including product services and licensing.
• Consider contractor's preferred vendor list.

Vendor Support: If vendor stops supporting the maintenance or further distribution of a product or a version of that product, or the vendor goes out of business, then lifecycle costs may increase and continued sustainment may not be possible.

• Use continuous market research to identify alternatives and anticipate vendor termination.
• Determine if another organization has assumed maintenance responsibility for the product.
• Consider upgrade to the latest product the vendor supports to avoid loss of vendor maintenance support.
• Negotiate level of vendor support based on system availability requirements and geographic distribution of installations.

Statement of Work: If tasks in the contractor's Statement of Work are not supportive of acquiring a COTS-based system, then the appropriate risk mitigation strategies may not be applied, potentially leading to cost and schedule slips.

• Task statements should specify:
• Do early and frequent prototyping
• Do continuous market research
• Maintain integration lab
• Perform system engineering when selecting, adapting, and integrating COTS products with each other and system hardware.