Our COTS Approach

Our Commercial of the Shelf (COTS) Approach

Our work on the strategic initiatives begins when the program components are initiated. Many of the components will be managed as projects, and formal project management processes should be followed. Each component would create a charter that will formally recognize the component as being worked on at this time.

A project manager would be assigned to each component, even if the organization has a different name for that role. The Project manager will manage initiating, planning, executing, monitoring and controlling, and closing the components for which he or she is responsible

COTS components are an important factor that we must consider when choosing or designing the architecture of a system. The use of COTS has its associated risks, as COTS components can be thought of as black boxes that just work. The tradeoffs between COTS components and homegrown components are development time versus flexibility and control.

COTS projects are surrounded by known and unknown risks, both for implementation and for ongoing sustained engineering and maintenance. COTS solutions begin with the WBS of deliverables. From the WBS, the deliverable “requirement abilities” or desired features or outcomes can be put into functional and technical requirements matrices or performance matrices that are provided by a COTS solicitation. These matrices make it easier for the vendor to identify if they have an exact match, similar functionality, need to make a modification, identify if there is a future release that will have the functionality, or that their solution cannot provide the specified requirement due to base system constraints.

The COTS model shifts in-house development resources to activities that proactively study for the best COTS solution match to the desired product requirements and to processes that integrate the chosen solution. Subcategories of COTS can be databases, hardware components, application systems, networking and middleware.

The requirements activity changes considerably as compared to traditional development. Projects reported that, with COTS, not all requirements are equal. Some are ‘free,’ or provided by the COTS. Some are not immediately available, but can be worked out with reasonable extensions and add-ons.

COTS feasibility “should consist of complete requirements definition, a high level architecture, an effort estimation, and a risk assessment model. The high level architecture allows the team to sketch dependencies amount COTS, incompatibilities, and integration effort.”

The project management strategy must bring added value, be based on data, prioritize objectives, understand resource availabilities and capabilities, and go for the maximum benefit.

COTS project management processes are challenging because of the integration of the vendor’s software and hardware as well as the extension of the in-house system or environment. Understanding the threat and value brought to the organization by COTS also requires a highly flexible plan

COTS configuration support and COTS tailoring activities must correlate to the COTS vendor milestones. COTS solutions still require some type of software development methodology to allow parallel activities of vendor and customer. The five project management process group activities for the overall project as well as the project phases or iterations.

The alignment for integration of the COTS solution between the customer in-house deliverables and vendor COTS deliverables cycle for integration testing and checkpoint integration milestones must be included in COTS contracts.

Checkpoints should be integrated into the overall project schedule to allow for appropriate learning, discovery, and prioritization.

The program team must assure that the component deliverables meet the requirements in order to fulfill the realization of benefits. Program status reports need to include the progress of meeting deliverables but also must communicate if there are any additional actions required to realize benefits

Signoff on deliverables is important within the program itself. The components will complete deliverables, and the program governance needs a process for review, measurement, and acceptance of them. A unique characteristic for a strategic plan program is that the benefits realized through the component deliverables may rely on the market or other factors. Nevertheless, the program team must manage the deliverables but focus and report on benefits realized. This necessitates communications and interactions with the highest levels within the company. The program team must seek to influence and/or control factors normally outside of the realm of a typical program team.

Through an ongoing process, while benefits are realized, the program team must transition the completed component work product to operations. The changes created through strategic initiatives now become the new norm for the organization. This transition necessitates that the program team be skilled in (or elsewhere purchase the skill) organizational change. The benefits realized from strategic initiatives and goals could be far reaching and extensive.

  Project / Program activities Suggested tools and/or documents
1 Problem discovery, project motivation/idea, project contract, project assignment and project approval Project idea/concept/proposal
Business case/feasibility study
Program management
2 Preliminary agreement on project structure, organization and high-level project elements High-level project plan
3 Effort and cost estimation, business case Costing model
Business case
4 Problem & Scope definition Problem & Scope Management Templates
5 Identification of stakeholders Stakeholder Templates
6 Definition of ‘chunks’ of work > work breakdown structure and task structuring Work Breakdown Structure
Project Work Plan
7 Definition of the sequence of work and activities resulting in a project schedule Project schedule
Project Work Plan
Critical path method (CPM)
8 Define the task/time schedule Gantt Chart
Detailed project plan
9 Define resource requirements and resulting resource plan Resource plan
10 Estimate project costs Cost plan/estimate
Cost calculation/estimation model
Budget calculation
Business case
11 Identify potential project risks
Risk management plan
12 Define overall required resources, equipment, materials, facilities, etc. Resources and materials plan
13 Define documentation and information requirements and standards Documentation and information policy plan
14 Define quality assurance policy QA policy plan
15 Define contractual and service delivery policies, e.g., SLAs, vendor management, etc. Service delivery policy, procurement policy, SLA framework, etc.
16 Define a communication plan Communication plan
17 Consolidate and document into a single source file. Project Contract
Project handbook/manual
Project Definition Report (PDR)
IMPLEMENTATION AND MONITORING (incl. steering, control, communication and documentation)
18 Manage risks, emergency, contingency and disaster recovery plans (DRP) Risk Analysis
DRP and contingency plans
19 Manage tasks, content and project plan adjustments as well as scope creep (scope and change control) Change request Tool
20 Manage internal and external communication Collaborative Tools ex. Trello, Asana, Basecamp
21 Ensure adherence to quality standards QA policy plan
22 Track time, cost and budget figures Collaborative Tools ex. Project Place, JIRA, Asana
23 Track and monitor short and long-term benefits realization and other performance indicators (benefits tracking) Business case
Benefits tracking
24 Manage financial and controlling indicators, costs and budgets Budget revision
25 Prepare project handover for next phase or go-live Project closure checklist
26 Final inspection, acceptance and approval of hand-over Project hand-over acceptance
27 Review and evaluate project or project phase Project review evaluation sheet
Expectation Review Tool ex. SharePoint
28 Document lessons learned
Lessons learned reports