Turnkey Methodology

The Turnkey methodology is only applicable for projects with a very well-defined, exact scope, without ambiguity about the exact expectations of the users, and with very little risks for unexpected activities and changes. During the implementation of the project, no major changes or surprises are expected, neither from a user requirement perspective, nor from a technical implementation perspective. If exceptionally there are such changes after all, those are managed via a formal Change Request procedure to update both the initially envisioned implementation timeline and the cost of the Turnkey Project.

Turnkey Projects are very comparable to the construction of a building. You know exactly what you want, it can be specified down to the smallest detail, and then it can be executed like clockwork, exactly as planned. The project starts with a very detailed and comprehensive design of the building, where all involved parties spend considerable time to ensure that all details are clearly specified and fully in line with the expectations of the user. After that stage, the initially estimated project budget and execution time are updated to ensure full alignment with the detailed design, and the construction then starts in line with a mutually agreed and very detailed waterfall project plan.

Any changes as compared to the initial design (extra window, different type of door, etc.), or any unexpected circumstances beyond the control of the building contractor (e.g. bad weather conditions, unexpected issues with the underlying soil causing dimension changes for the foundations, etc.) are governed by a formal Change Request, which specifies the impact on both cost and timing, and which is only executed after formal approval by the user.

Another way you can verify whether a scope is very well-defined (and hence suitable for execution with the Turnkey Methodology) is to ask yourself the following question: if you were to give the scope definition to two independent and separate implementation teams and then walk away and let them execute the entire project without any further communication with you, would you get the exact same result two times in the end? If not, you do not have a well-defined scope, and hence a Turnkey implementation is not possible.

Note

If any of the aspects of a Turnkey Project feel uncomfortable for a project that you have in mind, this is very likely because the nature of that project does not fit a Turnkey type of methodology. In other words, there are effectively a lot of unknown factors and risks in the project. In such a case, flexibility to deal with changes (unexpected circumstances, new requirements or changing requirements and expectations, etc.) while also maintaining control of budget and timing is an absolute must. This means that one of the two Agile methodologies is the way forward instead.

Choosing a Turnkey approach in such a case would only result in a far more rigid, and hence more time-consuming and more costly implementation, with a likely far less satisfying result. This is due to the inherent resistance to change built into a Turnkey methodology.
In the context of DataMiner deployments (i.e. ICT integration & platform software), the Turnkey methodology is very unlikely to be the most suitable approach. It is therefore only applied exceptionally compared to the two flavors of Agile methodologies available. The latter typically, if not always, yield more value and results for the same budget and time frame, as compared to the Turnkey methodology.