The Execution Phase is typically delivered according to an industry standard methodology published by the selected COTS publisher (e.g. ASAP or AIM). System Integrators will typically have their own twist or value-add to the publisher’s methodology, but generally they are based on the manufacturer’s published standards. While naming conventions and milestone boundaries vary from one methodology to another, the implementation of a COTS application generally follows a waterfall process including: preparation, design, build, test, deploy and maintain.
This waterfall process is borrowed from the construction industry. It is a sequential process that freezes designs at a point in time to avoid costly changes later in the project. A note of caution in following a waterfall process, requested deviations from approved designs will result in budget overruns and delays – make sure designs are validated by a properly skilled resource before being approved (a good opportunity to use IV&V services).
Some discrete work packages in a COTS project may warrant a more iterative [vs. waterfall] approach, for example multiple data conversion cycles, with each conversion obtaining better results. This is a best practice and should be accepted. In these cases, iterations can occur in the work stream, but key deliverables (e.g. final conversion) line up with the otherwise sequential [waterfall] plan.
In addition to best practices found in the Governance, Project Management and Change Management tracks, keys to the success of the Execution phase include:
- Follow a proven, industry standard methodology which provides:
- Confidence in staffing and scheduling estimates
- A baseline for quality assurance of deliverables [using methodology samples or templates]
- Recoverability in the event of non-performance by the selected system integrator - a replacement can
pick up where the non-performing vendor left off vs. restarting
- Transfer budget, timeline and quality risk to the system integrator using the SI Toolkit contracting template
- Ensure all team members [buyer and vendor] possess requisite skills for the project role they have
- Design effectively and efficiently taking full advantage of out-of-the box capabilities of the COTS application
- Manage scope by implementing a change management process that includes escalation of
changes to a governance board
- A benchmark-supported, deliverables-based project plan – track all deliverables as discrete tasks and avoid activity level detail, it is distracting
- Rigorous testing events including entry and exit criteria
- Quality data
- Well rehearsed cutover process
There are several considerations when determining needs for a COTS implementation. The needs can vary from a project that is led and delivered by an in-house team with limited support from external vendors, to a systems integrator led project with limited support from in-house resources. Additionally, the amount and type of “specialized” functionality that may be required is a factor [“specialized” is functionality that is not supported by out-of-the-box capabilities of the COTS software].
- What are the skills required for the project team, and are those skills generally available in-house
- Business process skills
- Experience with industry standard methodologies
- Functional skills in relevant COTS modules
- Technical skills with infrastructure components including development tools, data conversion tools and middleware
- Business transformation capabilities including communication & training
- What is the likely level of customization required
- Are industry best practices well understood in-house
Vendor sourcing for the Execution phase typically includes a formal RFP process. If in-house, expert skills are not available for developing an RFP and assessing responses, this can be contracted for. Assuming the enterprise architecture is complete, for a typical COTS project, developing an RFP for Execution should take 3-5 weeks and the end-to-end process including vendor selection and negotiation can usually be achieved within 3 months.
As the availability of skilled in-house resources decreases and/or the complexity of the implementation increases, there becomes a need for a more robust, full-featured systems integrator. Finding broad skills and available capacity for a large, complex project typically warrants a large, Tier 1 systems integrator. For smaller scope projects and/or where in-house skills are available, more niche integrators or vendors who provide supplemental staffing may work well, especially if a niche vendor’s capabilities line up well with specialized requirements.
A large portion of the project's budget will be expended in the Execution Phase of a COTS project. Where possible, fixed price contracts should be used to mitigate budget risk. While some organizations opt for a fixed price contract for design work and another fixed price contract for subsequent build and deploy tasks, it is recommended that a single fixed price be negotiated for all tasks. Just as you would give cost constraints to an architect when designing a building, so also you should require the systems integrator to deliver an efficient design. Fixing the price prior to design motivates the system integrator (and your team) to design efficiently – a best practice for COTS implementations. For some very large programs this may not be possible, in these cases scope must be tightly managed during design, ideally constraining it to out-of-the-box capabilities of the COTS software where possible.
In addition to a fixed price for the project, other pricing related requirements include:
- A discounted rate card to be used for increasing or decreasing the fixed price when scope changes
- Rates held or rate increases limited for the duration of the project
- A fixed price for RICEF components [reports, interfaces, conversions, extensions, forms], pricing should be by component type by complexity (high, medium, low). Because the inventory of required RICEF components will not be available prior to design, have the systems integrator estimate the number and type of RICEF components based on benchmark projects, and manage RICEF like you would a fixture allowance for a new building (i.e. a certain number [budget] are included in the fixed price, exceeding the number would require a change order). Finally, try to manage the number RICEF components to the budget through the change management process. Do you really need the complex workflow implemented (imported marble counter top) when a report (Corian) will do?
- A detailed staffing plan by resource by month, if there are delays to the project, and the systems integrator has failed to staff to the plan, they may be held liable for the delay – the staffing plan plus rate card can also be used to validate the fixed price
For a discussion on contracting options select Contract Structures.
|4.1 Direct and Manage Project Execution
||Direct and Manage Project Execution is the process of performing the work defined in the project management plan to achieve the project's objectives.
|4.2. Perform Quality Assurance
||Perform Quality Assurance is the process of auditing the quality requirements and the results from quality control measurements to ensure appropriate delivery, quality standards adherence and operational definitions are used.
|4.3. Acquire the Project Team
||Acquire Project Team is the process of confirming human resource availability and obtaining the team necessary to complete project assignments from internal or external resources.
|4.4. Develop Project Team
||Development of the Team is the process of ensuring the proper mix of skills and experience of team members as well as team interaction, and the overall team environment to enhance project performance.
|4.5. Manage Project Team
Provide team leadership and management including tracking team member performance, providing feedback, issue resolution, and changes affecting the project to improve performance.
|4.6. Documentation and Communications
||Documentation necessary for knowledge maintenance and transfer is a core responsibility during the execution phase. This aligned with communications has a significant effect on risk control and project outcome.
|4.7. Manage Expectations
||Expectation management is required across the stakeholder community – users, executives as well as team members. Results expected are to meet their needs and address issues as they occur.
|4.8. Vendor Management
||The execution phase is the most intensive stage of vendor management since it is where vendor commitments must be fulfilled. Comprehensive vendor management is needed to avoid issues across a range of topics form contractual obligations to basic knowledge transfer from third parties.