Ausgangslage

Das Prozessbild hängt im Flur: Phasen, Gates, je Gate eine Liste der Unterlagen, die das Gremium sehen will. Lastenheft, Business Case, technisches Konzept, Prüfbericht. Der Prozessverantwortliche hat menschzentrierte Gestaltung dort eingezeichnet, wo aus seiner Sicht Platz war: als eigene Phase „UX-Konzept" zwischen Anforderungen und Entwicklung. Ich habe dieses Bild in mehreren Organisationen gesehen, und mein erster Vorschlag war lange, es so zu lassen und die Phase gut zu füllen.

Der Vorschlag war falsch, weil er den Zyklus zu einem einmaligen Abschnitt macht. Was die Evaluation am Ende der Phase zeigt, erreicht keine Phase davor, und das Konzeptgate ist zu diesem Zeitpunkt passiert. Die vier Aktivitäten der Norm, Nutzungskontext verstehen, Nutzungsanforderungen festlegen, Gestaltungslösungen entwerfen, Lösungen evaluieren, sind unabhängig vom Vorgehensmodell definiert. Sie fügen sich in einen Stage-Gate-Prozess ein, wenn sie an die Gates gebunden werden, statt eine Phase zu bilden. Wie das geht, beschreiben wir in vier Schritten, aus Projekten in klassischen Entwicklungs-Workflows.

Die Gates als Entscheidungspunkte lesen

Der erste Schritt nimmt die vorhandenen Gates auf: Welche gibt es, wer entscheidet, welche Unterlagen liegen vor, welche Frage wird beantwortet. Typisch sind ein Gate für die Freigabe des Konzepts, ein Gate für die Entwicklungsfreigabe, ein Gate vor der Pilotierung und ein Gate vor dem Marktstart. Namen und Anzahl unterscheiden sich je Organisation.

Je Gate halten wir fest, welche Entscheidung dort über das Produkt fällt, die vom Nutzungskontext oder von der Gebrauchstauglichkeit abhängt. Am Konzeptgate wird über den Umfang entschieden. Am Entwicklungsgate über die Lösung. Vor dem Marktstart darüber, ob das Produkt in dieser Form ausgeliefert wird. Diese Zuordnung ist in unserer Erfahrung der Teil, an dem sich später entscheidet, ob der Zyklus im Prozess bleibt.

Je Gate ein Ergebnis aus dem Zyklus

Der zweite Schritt ordnet jedem Gate das Ergebnis zu, das dort aus dem Gestaltungszyklus vorliegt, und macht es zur Gate-Unterlage.

Am Konzeptgate liegt die Kontextbeschreibung vor: Nutzende, Aufgaben, Arbeitsmittel und Umgebung, erhoben im Feld, mit Quellen. Dazu die Nutzungsanforderungen mit Erfolgskriterien. Das Gremium entscheidet über den Umfang auf Grundlage erhobener Erfordernisse.

Am Entwicklungsgate liegt eine evaluierte Gestaltungslösung vor: ein Prototyp, der gegen die Nutzungsanforderungen geprüft wurde, mit Erfüllungsstatus je Anforderung. Das Gremium gibt eine Lösung frei, von der bekannt ist, welche Anforderungen sie erfüllt und welche nicht.

Am Gate vor der Pilotierung liegt die Evaluation des entwickelten Systems vor, unter Bedingungen, die dem Nutzungskontext entsprechen. Vor dem Marktstart liegt der Nachweis vor, dass die Nutzungsanforderungen erfüllt sind, oder eine dokumentierte Entscheidung, mit welchen Abweichungen ausgeliefert wird.

Für den letzten Punkt gilt: Bevor Sie ausrollen, wissen Sie, ob es funktioniert.

Die Rückkopplung zwischen den Gates

Der dritte Schritt betrifft die Phasen zwischen den Gates, und hier liegt der Einwand, den Gremien uns am häufigsten entgegenhalten: Ein Zyklus widerspreche der Phasenlogik, weil er Anforderungen ändere, die das Gremium bereits freigegeben habe. Der Einwand ist berechtigt, solange die Änderung unsichtbar bleibt.

Innerhalb einer Phase läuft der Zyklus mehrfach. Zwischen Konzeptgate und Entwicklungsgate werden Lösungen entworfen, evaluiert, überarbeitet und erneut evaluiert, bis die Kriterien erfüllt sind oder das Gate erreicht ist. Die Evaluation in einer Phase kann zeigen, dass der Nutzungskontext unvollständig war. Dann werden Kontextbeschreibung und Anforderungen aktualisiert, auch wenn das Konzeptgate schon passiert ist.

Diese Rückwirkung braucht eine Regel, und mit der Regel löst sich der Einwand: Änderungen an Anforderungen nach dem Konzeptgate werden dokumentiert und dem Gremium beim nächsten Gate als Änderung vorgelegt. Die Freigabelogik bleibt intakt, das Gremium sieht, was sich seit seiner Entscheidung verändert hat, und der Zyklus behält seine Rückkopplung.

Die Gate-Kriterien ergänzen

Der vierte Schritt schreibt die Ergebnisse in die Gate-Kriterien. Ein Gate hat eine Checkliste, die das Gremium abfragt. In diese Liste kommen die Fragen aus dem Zyklus: Liegt eine Kontextbeschreibung mit Quellen vor? Haben die Nutzungsanforderungen Erfolgskriterien? Wurde die Lösung gegen diese Kriterien evaluiert? Welche Anforderungen sind nicht erfüllt, und wer hat die Abweichung entschieden?

Erst mit diesen Fragen in der Liste wird die Gebrauchstauglichkeit zur Gate-Bedingung. Ohne sie bleibt der Zyklus eine freiwillige Leistung, und freiwillige Leistungen entfallen bei Zeitdruck. Wir haben das in Projekten gesehen, in denen die ersten drei Schritte gemacht waren und der vierte fehlte.

Grenzen

Stage-Gate-Prozesse haben lange Phasen. Der Zyklus innerhalb einer Phase braucht Feldzugang und Testpersonen, und die Phase muss dafür Zeit vorsehen. Wo Gates von Terminen und nicht von Ergebnissen gesteuert werden, kommt die Evaluation am Gate an, bevor sie abgeschlossen ist. Dann muss das Gremium entscheiden, ob es ohne Ergebnis freigibt, und diese Entscheidung dokumentieren. Der Zyklus verändert die Gate-Logik nicht. Er liefert die Unterlagen, an denen sich die Entscheidung messen lässt.

Ob die Zuordnung in Organisationen mit deutlich mehr Gates oder mit parallel laufenden Teilprojekten ebenso funktioniert, wissen wir aus eigenen Projekten nicht.

Was danach vorliegt

Eine Zuordnung von Ergebnissen des Gestaltungszyklus zu den Gates der Organisation, ergänzte Gate-Kriterien und eine Regel für Anforderungsänderungen zwischen den Gates. Die Gremien entscheiden weiter nach ihrer Logik, mit Unterlagen, die aus Beobachtung und Evaluation stammen.