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|
|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|
|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|
|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 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|
|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|