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. 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 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
Problem discovery, project motivation/idea, project contract, project assignment and project approval
Business case/feasibility study
Preliminary agreement on project structure, organization and high-level project elements
High-level project plan
Effort and cost estimation, business case
Problem & Scope definition
Problem & Scope Management Templates
Identification of stakeholders
Definition of 'chunks' of work > work breakdown structure and task structuring
Work Breakdown Structure
Project Work Plan
Definition of the sequence of work and activities resulting in a project schedule
Project Work Plan
Critical path method (CPM)
Define the task/time schedule
Detailed project plan
Define resource requirements and resulting resource plan
PLANNING AND DELIVERY
Estimate project costs
Cost calculation/estimation model
Identify potential project risks
Risk management plan
Define overall required resources, equipment, materials, facilities, etc.
Resources and materials plan
Define documentation and information requirements and standards
Documentation and information policy plan
Define quality assurance policy
QA policy plan
Define contractual and service delivery policies, e.g., SLAs, vendor management, etc.
Service delivery policy, procurement policy, SLA framework, etc.
Define a communication plan
Consolidate and document into a single source file.
Project Definition Report (PDR)
IMPLEMENTATION AND MONITORING (incl. steering, control, communication and documentation)
Manage risks, emergency, contingency and disaster recovery plans (DRP)
DRP and contingency plans
Manage tasks, content and project plan adjustments as well as scope creep (scope and change control)
Change request Tool
Manage internal and external communication
Collaborative Tools ex. Trello, Asana, Basecamp
Ensure adherence to quality standards
QA policy plan
Track time, cost and budget figures
Collaborative Tools ex. Project Place, JIRA, Asana
Track and monitor short and long-term benefits realization and other performance indicators (benefits tracking)
Manage financial and controlling indicators, costs and budgets
Prepare project handover for next phase or go-live
Project closure checklist
Final inspection, acceptance and approval of hand-over
Project hand-over acceptance
Review and evaluate project or project phase
Project review evaluation sheet
Expectation Review Tool ex. SharePoint
Document lessons learned
Lessons learned reports