Was ist ein Proof of Concept?
Foto: Kunal Mehta - shutterstock.com
Veränderungsprojekte auf der grünen Wiese zu praktizieren, mag durchaus seinen Reiz haben. Wer auf Nummer sicher gehen möchte, sollte allerdings eine Machbarkeitsstudie bevorzugen. Das Schlüsselwort heißt Proof of Concept.
Proof of Concept - Definition
Ein Proof of Concept (PoC) ist eine Testphase, die einem möglichen Veränderungsprozess vorangestellt wird. Dabei kann es sich bei der Veränderung um ein klassisches IT-Projekt, eine Prozessänderung oder gar eine organisatorische Maßnahme handeln.
Ein PoC soll Aufschluss über die Machbarkeit der Veränderung geben. Gleichzeitig werden Auswirkungen verprobt, die eine belastbare Planung zulassen. Dies umfasst u.a. Kosten, Dauer und Umfang eines möglichen Projektes. Zudem soll ein PoC auch erste Indikatoren liefern, welche Benefits mit der geplanten Veränderung erzielt werden können und welche Risiken zu beachten sind.
So lässt sich am Ende eines Proof of Concepts auch eine Entscheidungsvorlage herleiten. Der PoC ist also neben der eigentlichen Projektidee und dem Projektantrag ein weiterer gewichtiger Baustein im Vorfeld eines Veränderungsprozesses. Die Ergebnisse des PoC entscheiden maßgeblich darüber, ob eine Maßnahme durchgeführt wird oder nicht.
PoC - Einsatzzwecke
Die Einsatzmöglichkeiten eines Proof of Concept sind sehr unterschiedlich. Auf der einen Seite dient diese Herangehensweise um Machbarkeiten bzw. im umgekehrten Fall den sogenannten "Fast Fails" zu verproben. Bevor in einem anstehenden Projekt auf eine neue Technologie gesetzt wird, können Funktionen und Features in einem PoC eingehend geprüft werden. Modifizierte Geschäftsprozesse oder abgeänderte Abläufe können in einem PoC simuliert und die zu erwartenden Ergebnisse vorhergesagt werden. Somit dient der Proof of Concept als gewichtiger Für- und Wider-Gradmesser, die geplanten Veränderungen tatsächlich vorzunehmen.
Immer häufiger sehen IT-Verantwortliche sich den Anforderungen aus dem Business gegenüber, zu neuen Technologien, wie Blockchain, Stellung zu beziehen. Oder aber eine über Jahre gewachsene SAP-Landschaft soll in Teilen durch neue und wenig erprobte Plattformen bisher unbekannter Cloud-Anbieter ersetzt werden. Diese Fragestellungen können nicht ad-hog oder ohne eingehende Prüfung beantwortet werden.
Desweiteren können modifizierte Geschäftsprozesse oder abgeänderte Abläufe in einem PoC simuliert und die zu erwartenden Ergebnisse vorhergesagt werden. Somit dient der Proof of Concept als wichtiger Für- und Wider-Gradmesser, die geplanten Veränderungen tatsächlich vorzunehmen.
Auf der anderen Seite kann der Proof of Concept auch ein bedeutendes Planungsinstrument im Vorfeld eines Projektes sein. Die Ergebnisse geben nicht nur Aufschluss darüber, ob eine Projektmaßnahme technisch und funktional sinnstiftend ist. Es lassen sich für die Projektrahmendaten belastbare Daten gewinnen, welche Aufwände (Zeit, Einsatz, Material) und mit welcher Dauer geplant werden sollten. Daher ist der PoC auch ein finaler Meilenstein, der auf Basis dieser Ergebnisse und der darauf fußenden Schätzungen eine Zustimmung oder auch Ablehnung für das avisierte Projektengagement zulässt.
Proof of Concept - Aufbau und Ablauf
Ein Proof of Concept ist im Grunde nichts anderes als ein für sich stehendes Projekt. Bezugnehmend zum Zweck und zur Intention des Proof of Concept, kann dieses Projekt eine sehr kurze oder auch beliebig lange Dauer haben. Im Vorfeld des PoC sollte ausreichend Zeit in das Erwartungsmanagement investiert werden:
Was sind die Ziele dieses Versuchsballons?
Welche Ressourcen werden für die Durchführung benötigt?
Wieviel Zeit wird veranschlagt?
Was ist eine sinnvolle Vorgehensweise für den anstehenden PoC (Wasserfall, agil o.a.)?
Je nach Umfang und Kontext des Miniprojektes, sollte ein Kurzkonzept formuliert werden, in diesem die Ausgangssituation skizziert und die oben beschriebenen Fragen beantwortet werden. So kann dieser Business Blueprint auch als Leitfaden für die Durchführung genutzt werden und anschließend den Rahmen für die Ergebnisse und aufbauende Entscheidungsvorlage liefern.
Der tatsächliche Proof of Concept kann von Fall zu Fall ein sehr unterschiedliches Augenmerk haben:
Dient diese Evaluierungsphase einer Art "Beauty Contest", in dem verschiedene Werkzeuge gegenübergestellt werden, so wird jede Lösung gegen den gleichen Use Case verprobt. Im Nachgang können dann die erhobene Werte in Bereichen wie Performance, Usability oder Kosten verglichen und einer Bewertungsmatrix unterzogen werden.
Soll demgegenüber nur eine ausgewählte Lösung genauer begutachtet werden, so werden mehrere repräsentative Use Cases auf dieser Plattform simuliert.
Oder aber es liegt der Fokus auf der Modifikation bisheriger Prozesse und Geschäftsmodellen. Dann werden die etablierten Plattformen und Werkzeuge in einer Testumgebung herangezogen und die abgeänderten Prozesse und deren Auswirkungen analysiert.
In jedem Fall ist es ratsam, ein klares Verständnis davon zu haben, welche Bausteine im Gesamtgewerk fix und damit unverändert bleiben und welche Komponenten neu sind oder verändert wurden. Nur so lässt sich eine belastbare Analyse und spätere Bewertung dieser isolierten Fragestellungen vornehmen. Die Durchführung kann nach klassischer Wasserfallmethodik erfolgen oder auch in mehreren Wellen durchgeführt werden. Dies hängt maßgeblich vom Kontext ab und richtet sich ein stückweit auch nach den verfügbaren Ressourcen oder auch den zu erwartenden Ergebnissen. In jedem Fall findet zum Ende eines jeden Proof of Concepts eine intensive Auseinandersetzung mit den Erkenntnissen dieser Übung statt, in der folgende Fragen beantwortet werden sollten:
Wurden die Erwartungen erfüllt?
Gab es überraschende Ergebnisse?
Was ist die Konsequenz?
Nicht selten mündet ein PoC in eine Entscheidungsvorlage, die dann einem Steering Committee vorgelegt wird. Dieses Gremium entscheidet auf Basis dieser Empfehlung, ob eine Projektinitiative durchgeführt wird oder nicht. Somit dienen ein PoC und seine Ergebnisse auch als internes Testat.
- 1. Unklare Arbeitslast
Bryan Fagman vom Anbieter Micro Focus sagt, dass viele Projekte an einem nicht klar umrissenen Arbeitsaufwand scheitern. Schleichen sich hier Unschärfen ein, leidet das ganze Projekt. Im schlimmsten Fall bleibt undefiniert, wann es überhaupt abgeschlossen ist. Fagman mahnt deshalb an, Ziele im Dialog mit den Kunden klar zu benennen. - 2. Undefinierte Erwartungen
Alle Beteiligten müssen von Beginn an wissen, welche Anforderungen ein Projekt stellt und welche Erwartungen zu erfüllen sind – sonst droht ein Fiasko. Tim Garcia, CEO des Providers Apptricity, nennt zwei entscheidende Dinge, die alle Team-Mitglieder vorab wissen sollten: was getan wird und wie man weiß, wann das Projekt abgeschlossen ist. „Ohne eine dokumentierte Vereinbarung, die Antworten auf diese beiden Fragen liefert, ist ein Projekt von Anfang an in Gefahr“, sagt Garcia. - 3. Fehlende Management-Unterstützung
Die Unterstützung aus der Firmenspitze sollte unbedingt gesichert sein. Befindet man sich dahingehend mit der Chef-Etage nicht in Einklang, mindert das die Erfolgsaussichten beträchtlich, meint Brad Clark vom Provider Daptiv. - 4. Methodik nach Schema F
Im Projekt-Management wird gemeinhin mit standardisierten Schlüsselaufgaben und Leistungen gearbeitet. Darin lauert nach Einschätzung von Robert Longley, Consultant beim Beratungshaus Intuaction, aber auch eine Gefahr. Die Standard-Ansätze seien meist auf Projekte einer bestimmten Größe ausgerichtet. Sie passen möglicherweise nicht mehr, wenn man sich an größere Projekte als in der Vergangenheit wagt. - 5. Überlastete Mitarbeiter
„Team-Mitglieder sind keine Maschinen“, sagt Dan Schoenbaum, CEO der Projekt-Management-Firma Teambox. Projekte können auch daran scheitern, dass Mitarbeiter mit Arbeit überfrachtet werden. Vermeiden lässt sich das, indem man sich vorab ein klares Bild über die Stärken der Team-Mitglieder macht und auf eine sinnvolle Verteilung der Aufgaben achtet. - 6. Ungeteiltes Herrschaftswissen
Projekte leben davon, dass Informationen nicht monopolisiert, sondern miteinander geteilt werden. Das geschieht oft dann nicht, wenn Ergebnisse erst nach langer Anlaufzeit geliefert werden müssen. Tim Garcia von Apptricity rät deshalb dazu, Projekt in kurze Phasen einzuteilen. An deren Ende sollte es jeweils Resultate geben, mit denen das ganze Team weiterarbeiten kann. - 7. Unklare Entscheidungsfindung
Im Verlauf eines Projektes sind Änderungen der ursprünglichen Roadmap oft unvermeidbar. Es sollte beim Change Management aber klar dokumentiert werden, wer wann was geändert hat und wie die neue Marschrichtung aussieht. - 8. Fehlende Software
Exel-Spreadsheets nötigen Projekt-Manager zu manuellen Korrekturen und führen oft zu Problemen bei der Status-Aktualisierung. Insofern ist es befreiend, mit Project Management Software zu arbeiten, die für automatische Updates sorgt und von lästigen manuellen Berichten entlastet. Dazu rät Brian Ahearne, CEO des Anbieters Evolphin Software. - 9. Gefahr des Ausuferns
Change Requests sind alltäglich im Projekt-Leben, aber sie haben leider oft einen unerfreulichen Nebeneffekt: den Hang, Fristen und Budget-Rahmen immer weiter auszudehnen und auf Dauer zu Demotivation und Frust auf allen Seiten zu führen. Um dieser Entwicklung Einhalt zu gebieten, sind neben klaren Zielvorgaben auch tägliches Monitoring und ein definierter Prozess für gewünschte Veränderungen sinnvoll. Das empfiehlt in jedem Fall Sandeep Anand, der beim Software-Entwicklungshaus Nagarro für Project Governance verantwortlich ist. - 10. Nicht "Nein" sagen können
Im Sinne des Unternehmens sei es manchmal nötig, Anfragen abzulehnen, sagt Markus Remark vom Provider TOA Technologies. Gut sei es deshalb zu wissen, wie man "nein" sagt. Am besten habe man für solche Fälle auch gleich eine konstruktive alternative Lösung parat. - 11. Mangelnder Zusammenhalt
Projektarbeit ist Team-Arbeit. In der Praxis gerieren sich manche Projekt-Teams aber wie in Eifersüchteleien gefangene Sportmannschaften ohne Erfolg, beobachtet Berater Gordon Veniard. Der Fokus auf das eigentliche Ziel gehe verloren. Stattdessen beschuldigen sich Grüppchen gegenseitig, für Probleme und schlechte Leistungen verantwortlich zu sein. Um das zu verhindern, ist Führung durch den Projekt-Manager gefragt. Und der sollte es verstehen, sein Team mitzunehmen und in Entscheidungen einzubinden. Ohne Kommunikation sei das Desaster programmiert, so Hilary Atkinson vom Provider Force 3. - 12. Vergessener Arbeitsalltag
Hilary Atkinson hat nach noch einen weiteren Kommunikationstipp parat: Projekt-Manager sollten nicht vergessen, ihre alltäglichen Aufgaben zu erledigen. Wer als Verantwortlicher keine Meeting-Termine verkündet, Status-Berichte vergisst und E-Mails unbeantwortet lässt, riskiert unnötige Verzögerungen. - 13. Zu häufige Meetings
Meetings, in denen der Status Quo besprochen wird, können nerven – vor allem dann, wenn sie zu oft stattfinden oder zu lange dauern. Wichtige Informationen lassen sich durch Collaboration Tools häufig besser an die Team-Mitglieder bringen, meint Liz Pearce, CEO des Providers LiquidPlanner. Ihr Tipps: Meeting auf die Entscheidungsfindung beschränken. In ihrem Unternehmen gebe es lediglich zweimal in der Woche ein Treffen, um neue Aufgaben zu verteilen und Prioritäten zu definieren. - 14. Gut genug ist nicht immer gut
Sergio Loewenberg vom IT-Beratungshaus Neoris macht Nachlässigkeiten in der Qualitätssicherung als Problem aus. Es sei günstiger, Fehler zu vermeiden anstatt Geld und Zeit ins Ausmerzen ihrer negativen Folgen stecken zu müssen. Wer auf hohe Qualitäts-Standards achte, vermeide späteres Nacharbeiten und die Gefahr eines schlechten Rufes. - 15. Nicht aus Fehlern lernen
Liz Pearce mahnt außerdem an, mit Hilfe entsprechender Tools eine mehrstündige Analyse nach Ende des Projektes durchzuführen. Nur Teams, die sich des ständigen Lernens verschreiben, seien dazu in der Lage, die Fehler der Vergangenheit in der Zukunft zu vermeiden. - 15 Fehler beim Projektmanagement
Es gibt unzählige Wege, ein IT-Projekt an die Wand zu fahren. Unsere amerikanische Schwesterpublikation CIO.com hat 15 davon gesammelt – und verrät dankenswerterweise auch, wie man die Probleme beheben kann. Diese Tipps sind in der Bilderstrecke zu finden.
PoC - Softlabs
Der digitale Wandel und die immer rasantere Entwicklung der technischen Möglichkeiten, zwingt Unternehmen dazu neue Wege einzuschlagen. Um mit dem Trend am Markt mithalten zu können und wenn möglich sogar Wettbewerbsvorteile zu erschließen, wird dem Early Adopter eine mehr und mehr besondere Bedeutung zuteil.
Es ist ein permanenter Spagat, ob ein Unternehmen frühzeitig auf neue technische Optionen setzen sollte oder nicht. Den zusätzlichen Funktionen und Features, die beispielsweise Vorteile in punkto Performance oder Analysetiefe bieten, stehen etwaige "Kinderkrankheiten" gegenüber, die ein Werkzeug in der Beta-Phase noch mit sich bringt. Wartet man hingegen, bis sich eine neue Software oder ein neues Release etabliert hat, kann der Wettbewerb bereits die berühmte Nasenlänge voraus sein.
Je IT- und datengetriebener ein Unternehmen aufgestellt ist, desto häufiger findet man Organisationseinheiten, wie Softlabs, wieder. Diese Abteilungen haben es sich zur Hauptaufgabe gemacht, permanent neue Lösungen zu identifizieren und diese auf einen möglichen, frühzeitigen Einsatz im Unternehmen zu prüfen. Sozusagen: der institutionalisierte Proof of Concept.
Ein Softlab kann sowohl als reinrassige Gruppe in der hauseigenen IT aufgehängt sein, als auch als hybrides Konglomerat auftreten, das wie ein Competence Center bestehend aus IT- und Fachkompetenzen fungiert. Fachbereichsentsandte können dauerhaftes Mitglied im Softlab sein oder aber temporär für jeweils ausgewählte Projektinitiativen mitarbeiten.
Lesetipp: So bringen Sie IT und Fachabteilung unter einen Hut
Die Linienfunktionen können über ihre Fachbereichsentsandten Anforderungen an das Softlab adressieren, welche neuen Lösungen und Features demnächst einer Prüfung unterzogen werden sollen. Die Erkenntnisse aus diesem Proof of Concept dienen dann für eine mögliche Projektinitiative und bedienen Planung und Organisation. Sollten negative Schlussfolgerungen aus diesem Versuch gezogen werden, so diente diese Übung mindestens als Quality Gate.
Das Softlab selbst kann natürlich auch Marktrecherche betreiben und setzt sich mit neuen Softwarelösungen oder Releases proaktiv auseinander, um gegenüber dem Business die Rolle des Innovationstreibers zu besetzen. Bisher unbekannte Komponenten werden gegen einen intern bekannten Prüfkatalog in Form von ausgewählten Use Cases gefahren und auf ihren weiteren Einsatz getestet. Anschließend wird im positiven Fall den angeschlossenen Fachbereichen ein Angebot gemacht und gemeinsam eine Projektinitiative beantragt.
Proof of Concept - Mittel zum Erfolg
Der technische Fortschritt gewinnt immer mehr an Tempo. Neue Anbieter finden ihren Weg auf bekannte Märkte und gewohnte Player verschwinden oder werden von größeren Herstellern geschluckt. Für die Anwenderunternehmen wird es zur permanenten Herausforderung den Überblick zu behalten und hier die Frage zu beantworten" "What's in for me?".
Unternehmen, die hier die richtige Balance finden und rechtzeitig auf neue Werkzeuge setzen und gleichzeitig weniger gewinnbringende Lösungen aussieben, werden ihre Marktposition auf Dauer behaupten können oder sich sogar Wettbewerbsvorteile erschließen können. Entweder begegnet man dieser Situation mit regelmäßigen Projektinitiativen, die in Form von Machbarkeitsstudien die gewünschten Erkenntnisse liefern. Oder aber man etabliert mit Softlabs dedizierte Organisationseinheiten, die genau diese Analysen zur Aufgabe haben.
So oder so werden Proof of Concepts immer häufiger zum Mittel der Wahl, um die richtigen Projekte zu initiieren und den Unternehmenserfolg zu gewährleisten. Forschung und Entwicklung (F&E) ist also nicht mehr nur eine Domäne der Labore in der chemischen Industrie, sondern auch ein Vorgehensmodell für die IT in mehr oder weniger allen Industriezweigen.