Our 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
INITIATION
1	Problem discovery, project motivation/idea, project contract, project assignment and project approval	Project idea/concept/proposal
		Business case/feasibility study
		Program management
		Contract
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
SETUP
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
PLANNING AND DELIVERY
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
CLOSURE
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