Typical phases of a Turnkey Project deployment
The deployment of a Turnkey Project follows the classic waterfall approach, where all tasks and activities are first inventoried and laid out in a very detailed Project Plan for subsequent execution by the pre-allocated resources, under the control of a Project Manager. All dependencies are clearly defined and documented, and they are assumed to be complied with in a timely fashion, in line with the Project Plan.
Strict alignment and compliance with the plan are essential to the success of a Turnkey Project deployment. Change is to be avoided, and too much change can be very disruptive and result in a lot of wasted energy and eventually a lot of inefficiency.
The following high-level phases are typically part of the Turnkey methodology:
Initial Requirements & Budgeting: A Turnkey Project starts with User Requirements. An initial estimated budget is provided for the project based on those requirements, along with an initial estimated timeline for that kind of project, based on the information available at that time.
Letter of Intent or Purchase Order: The Consultancy & Detailed System Design of a Turnkey Project cannot start without a firm commitment to the commercial terms & conditions (e.g. unit pricing, payment terms, contract terms, etc.) that came with the budget. Typically, there needs to be a clear and firm agreement on the funding of the design and consultancy services required for the Consultancy & Detailed System Design phase.
Consultancy & Detailed System Design: During this phase, the entire solution must be designed, described and documented in great detail along with all activities that will be required for the implementation of the solution, in order to create a solid project plan fit for a waterfall Turnkey Project execution. This typically includes:
FDS & DDS – Functional & Detailed Design Specification: In a first phase, a very detailed Functional and Detailed Design Specification must be established between both parties. As this involves both parties, this is typically established through a series of iterative workshops. Note that this phase can be quite elaborate and time-consuming, as a very detailed and very firm FDS/DDS is crucial, and this time expenditure must also be accounted for both commercially and in terms of the project execution timeline.
Workflow Description: For any projects that involve automation and/or orchestration, a detailed Workflow Description must be established. This is a detailed step-by-step description of the exact logic, down to every single reading and control, covering all required checks and decisions to deal with the necessary corner cases. This therefore also includes a detailed review and evaluation of the third-party APIs involved in the process, as well as review sessions with users who must approve the logic of the workflows. Furthermore, it is advisable to also test and validate the envisioned workflows manually, to ensure that they are properly vetted before the automation processes are developed in the context of the Turnkey Project deployment.
Roles & Responsibilities: A Turnkey Project typically comes with a set of well-defined Roles & Responsibilities, to ensure a clear definition of which of the activities are the responsibility of Skyline and which are considered to be taken care of by the user or a third party, such as a systems integrator or technology vendor. It is essential that this is clearly defined, mainly because of the many inter-dependencies between various parties that need to be strictly managed in line with the Project Plan for a successful outcome.
TAP - Test Acceptance Plan: Along with the FDS/DDS, the user also must draft a Test Acceptance Plan with a detailed description of all the points of verification and all tests that must be executed for the formal acceptance, along with an accurate description of the expected outcome, in tangible, easy-to-measure and unambiguous terms. The success of the outcome of the project is measured by verifying the TAP against the implemented solution.
Update of Project Price and/or Project Plan: Depending on the delta between the initial requirements and the final FDS/DDS, Skyline is entitled to update the pricing and implementation timeline as compared to the initially provided budget and timeline (i.e. if fundamental new requirements were included in the FDS/DDS, which were not referenced in the initial requirements, and/or if certain initial requirements were further developed beyond what could have been reasonably expected, then this has an impact on both the cost and the implementation timeline).
Sign-Off: Only after all parties have formally signed off these documents, can the actual implementation and deployment of the project start.
System Implementation & Deployment: During this phase, the assigned Project Team executes the implementation in line with the agreed FDS/DDS and Project Plan. As outlined in detail in this document, any deviations from the agreed design (which have to be avoided at all costs to begin with) are governed by a formal Change Request procedure. Note also that any cosmetic and non-critical feedback, which is not essential towards the required functionality that must be delivered according to the FDS/DDS, by default goes on a separate project backlog, and is not dealt with by the project team during the ongoing deployment phase. It is only processed towards the end of the project and only in case the Project Team deems enough time is still available to do so before the formal closure of the project.
Design Lock: At least 6 weeks before the anticipated end of the project, or earlier if indicated as such in the Project Plan, no more Change Requests can be processed, and the project must enter its final stage to prepare for end-to-end system testing and a final burn-in period before the go-live.
System Acceptance & Handover: At the end of implementation, there is a formal handover, for which the agreed Test & Acceptance Plan is used as a sole reference. All tests must be executed as planned, and the outcome of the tests must be solely referenced against the documented expected outcome.
