Tackling IT-related projects with a proof of concept has prevailed. The advantages and functioning of this approach is explained in this post. […]
Practicing change projects on the green field may well have its appeal. If you want to play it safe, however, you should prefer a feasibility study. The keyword is called Proof of concept.
A proof of concept (PoC) is a test phase that precedes a possible change process. The change can be a classic IT project, a process change or even an organizational measure.
A PoC should provide information about the feasibility of the change. At the same time, effects that allow for reliable planning are rehearsed. This includes costs, duration and scope of a possible project. In addition, a PoC should also provide initial indicators of which benefits can be achieved with the planned change and which risks must be taken into account.
Thus, a decision template can also be derived at the end of a proof of concept. In addition to the actual project idea and the project application, the PoC is another important component in the run-up to a change process. The results of the PoC are decisive in determining whether a measure is implemented or not.
The possible applications of a proof of concept are very different. On the one hand, this approach serves to test feasibility or, in the opposite case, the so-called “fast fails”. Before a new technology is used in an upcoming project, functions and features can be examined in detail in a PoC. Modified business processes or modified processes can be simulated in a PoC and the expected results can be predicted. Thus, the proof of concept serves as a weighty indicator of the pros and cons of actually making the planned changes.
On the other hand, the proof of concept can also be an important planning tool in the run-up to a project. The results not only provide information about whether a project measure is technically and functionally meaningful. Reliable data can be obtained for the project frame data, which expenses (time, use, material) and with what duration should be planned. Therefore, the PoC is also a final milestone, which on the basis of these results and the estimates based on them allows approval or rejection for the planned project commitment.
A proof of concept is basically nothing more than a stand-alone project. Referring to the purpose and intention of the proof of concept, this project can have a very short or arbitrarily long duration. Sufficient time should be invested in expectation management in the run-up to the PoC:
- What are the objectives of this experimental balloon?
- What resources are needed for its implementation?
- How much time is estimated?
- What is a sensible approach for the upcoming PoC (waterfall, agile, etc.)?
Depending on the scope and context of the mini-project, a short concept should be formulated in which the initial situation should be outlined and the questions described above answered. This business blueprint can also be used as a guide to implementation and then provide the framework for the results and building decision template.
The actual proof of concept can have very different attention from case to case:
- If this evaluation phase serves as a kind of “beauty contest” in which different tools are compared, each solution is tested against the same use case. Subsequently, the collected values in areas such as performance, usability or costs can be compared and subjected to an evaluation matrix.
- If, on the other hand, only a selected solution is to be examined in more detail, several representative use cases are simulated on this platform.
- Or the focus is on modifying existing processes and business models. Then the established platforms and tools are used in a test environment and the modified processes and their effects are analyzed.
In any case, it is advisable to have a clear understanding of which building blocks remain fixed and thus unchanged in the overall trade and which components are new or have been changed. This is the only way to carry out a reliable analysis and subsequent evaluation of these isolated issues. The implementation can be carried out according to classical waterfall methodology or can also be carried out in several waves. This largely depends on the context and depends to a certain extent on the available resources or the expected results. In any case, at the end of each proof of concept, an intensive examination of the findings of this exercise takes place, in which the following questions should be answered:
- Were the expectations fulfilled?
- Were there surprising results?
- What is the consequence?
It is not uncommon for a PoC to result in a draft decision, which is then submitted to a steering committee. On the basis of this recommendation, this committee decides whether a project initiative will be implemented or not. Thus, a PoC and its results also serve as an internal test.
The digital transformation and the increasingly rapid development of technical possibilities are forcing companies to take new paths. In order to keep up with the trend on the market and, if possible, even to gain competitive advantages, the early adopter is becoming more and more important.
It is a permanent balancing act whether a company should rely on new technical options at an early stage or not. The additional functions and features that offer advantages in terms of performance or analysis depth, for example, are contrasted with any “teething problems” that a tool still brings with it in the beta phase. On the other hand, if you wait until a new software or a new release has established itself, the competition can already be the famous nose ahead.
The more IT – and data-driven a company is, the more often you will find organizational units, such as Softlabs. These departments have made it their main task to constantly identify new solutions and to check them for possible early deployment in the company. So to speak: the institutionalized proof of concept.
A softlab can be suspended as a pure – bred group in the in-house IT, as well as act as a hybrid conglomerate, which acts like a competence center consisting of IT and professional competencies. Department delegates can be permanent members of the Softlab or work temporarily for selected project initiatives.
The line functions can use their departmental requirements to address to the Softlab which new solutions and features are to be tested in the near future. The findings from this proof of concept then serve for a possible project initiative and serve planning and organization. Should negative conclusions be drawn from this experiment, this exercise served at least as a quality gate.
Of course, the Softlab itself can also conduct market research and proactively deals with new software solutions or releases in order to fill the role of innovation driver for the business. Previously unknown components are tested against an internally known test catalog in the form of selected use cases and tested for their further use. Subsequently, in the positive case, an offer is made to the affiliated departments and a joint project initiative is applied for.
Technical progress is gaining more and more speed. New providers find their way into well-known markets and familiar players disappear or are swallowed up by larger manufacturers. For the user companies, it becomes a permanent challenge to keep an overview and answer the question “” What’s in for me?“.
Companies that find the right balance here and rely on new tools in good time and at the same time filter out less profitable solutions will be able to maintain their market position in the long term or even gain competitive advantages. Either this situation is met with regular project initiatives that provide the desired insights in the form of feasibility studies. Or you can establish dedicated organizational units with Softlabs, which have exactly these analyzes to the task. Either way, proof of concepts are increasingly becoming the means of choice for initiating the right projects and ensuring the company’s success. Research and development (R&D) is therefore no longer just a domain of laboratories in the chemical industry, but also a process model for IT in more or less all branches of industry.
* Daniel Eiduzzis is Manager Alliance & amp; Business Development at initions AG. In this position, he is responsible for the strategic partnerships for selected cooperations as well as the further development of the consulting portfolio and the initions brand core.