How to carry out a successful proof of concept for the roll-out of Teamwire

Choosing a new communications platform is not a gut decision – nor should it be. Where operational communications, data protection and reliability intersect, a robust and transparent basis for decision-making is required. This is precisely what a well-planned proof of concept (PoC) provides.

A proof of concept demonstrates, under real-world conditions, whether Teamwire meets your requirements for secure (operational) communication – from a technical and organisational perspective, and in day-to-day use. This guide takes you step by step through a structured PoC process tailored to the requirements of regulated and safety-critical organisations.

What a PoC is intended to achieve – and what it is not

Before you begin, it is worth establishing a clear distinction. A proof of concept answers a narrowly defined question: does the solution work for your specific, critical use cases? It is time-limited, focuses on a few key scenarios and serves to minimise risk before an investment decision is made.

This is to be distinguished, on the one hand, from the pilot, which involves a broader, longer-term trial with a larger user group. This usually takes place following a successful PoC and with a view to live operation. And, on the other hand, the roll-out is the widespread introduction of the system once a decision has been made.

A common mistake is to expect a PoC to already represent a fully operational system. A PoC is not intended to cover everything – it is designed to answer the key questions: Does the solution meet our security and compliance requirements? Will it be accepted by users? Does it function reliably in our mission-critical scenarios?

Phase 1: Preparation and definition of objectives

The success of a PoC is determined before the first message is sent. It is during this phase that you lay the foundations.

Defining success criteria

Set out measurable criteria against which you will evaluate the PoC at the end. Avoid vague objectives such as ‘the app should work well’. Instead, be specific; for example:

• The central alert system reaches defined recipient groups in under X seconds.
• At least X per cent of the test group are actively using Teamwire after two weeks.
• All data protection requirements are met.
• Integration with existing systems (MDM, directory service) can be achieved without the need for workarounds.

Involving the right stakeholders

In regulated organisations in particular, projects rarely fail because of technical issues, but because certain stakeholders have been overlooked. Bring all the relevant roles together at an early stage:

• IT and IT security for technical and safety assessments.
• Data Protection Officer for the GDPR compliance assessment and the data protection impact assessment.
• The staff council or works council, as the introduction of communication software is generally subject to co-determination. Involving them at an early stage helps to prevent obstacles arising later on.
• The specialist department – such as the operations management team, crisis management team, nursing management or departmental management – which is aware of the actual requirements.
• Department heads and managers of the respective working groups, who, on the one hand, are aware of their teams’ requirements for such a communication solution and, on the other hand, are often in a position to authorise the introduction of a tool such as Teamwire.
• Where applicable, senior management, the executive board and C-level executives, if Teamwire is to be rolled out company-wide or within senior management, or if its introduction requires approval from the very top. Furthermore, it sends a positive signal to all staff if senior management takes the trial seriously and plays an active role in the decision-making process.

Select the test group and use cases

Select a representative, diverse test group – not just the staff who are most tech-savvy. Define two to four key use cases that are truly critical to your organisation. Examples: rapid alerting during operations, secure transmission of sensitive information, coordination within the crisis management team, or shift handover involving sensitive personal data.

Define the duration of the test and organise a kick-off meeting

Set a clear trial period. You have 14 days to carry out a meaningful PoC with Teamwire. A defined timeframe creates a sense of commitment and ensures that the solution is actively used rather than simply installed.

Next, bring all those involved in the test together for a kick-off meeting. Here, you will lay the foundations for a successful test together. 

An important prerequisite for the kick-off: 

All participants should have downloaded the app and logged in beforehand. This will allow you to send an initial message or an alert to the group straight away during the meeting – a powerful ‘aha’ moment that demonstrates the solution works straight away.

Next, follow the four steps below.

Step 1: Explain the aim and purpose

What are your plans for the solution, what will it be used for, and which existing tool will it replace?

Step 2: Explain the benefits

Make the specific added value for participants clear. This boosts motivation and, as a result, the test’s validity.

Step 3: Live demonstration

Demonstrate Teamwire in action within the application. A brief, practical demonstration is far more convincing than a mere explanation.

Step 4: Announce the trial period

Give the go-ahead and make it clear that the test will now run for 14 days.