Wie man mit Standards Projekte ruinieren kann

Standards sind für Systementwickler gut, sinnvoll und vernünftig. Doch häufig stellen sie nicht die Lösung, sondern das eigentliche Problem dar.

CMMI, SPICE, ISO 900X, ITIL, ISO 26262 – das sind die Hypes der vergangenen zehn Jahre. Die Softwarekrise zu bewältigen, die Qualität zu sichern, einfach besser zu werden – so lauten die Versprechen dieser Standards. Ohne Standards herrschten Chaos und Zähneknirschen, möchte man meinen. In jedem mir bekannten (und vermutlich in den meisten mir noch nicht bekannten) Unternehmen, die sich mit der Entwicklung von Software und Elektroniksystemen beschäftigen, wird die Umsetzung mehrerer dieser Standards vorangetrieben.

Doch diese Schönwettermeldung trügt. Natürlich ergeben Standards Sinn, wenn sie als eine Richtschnur betrachtet werden. Fakt ist jedoch, dass ihre Umsetzung überdurchschnittlich häufig fehlschlägt. Die Gründe sind vielfältig, aber letztendlich scheitert eine Standardumsetzung fast immer am Faktor Mensch.

Denn Standards sind wie ein Skalpell: In der Hand eines erfahrenen Chirurgen können sie Wunder bewirken, in der Hand eines Psychopathen können sie Angst und Schrecken verbreiten. Ich tippe, dass es in dieser Welt wesentlich mehr Psychopathen als Chirurgen gibt; und sogar wenn dies nicht der Fall ist, kann ein einziger Psychopath den Ruf aller Skalpellhersteller arg ruinieren.

Also machen sich die Verantwortlichen auf den Weg, um diese Standards umzusetzen. Das ist im Grunde eine gute Nachricht, denn niemand möchte in ein Flugzeug einsteigen, das aus einer chaotischen Projektarbeit hervorgegangen ist.

Doch nun setzt das Tagesgeschäft ein: Die Zeit drängt, Experten für die Standards fehlen, und die Entwickler wehren sich gegen die durch solche Standards häufig wuchernde Bürokratie. Die typischen „Anti-Muster“ der Standardumsetzung setzen ein:

• Die eingeplante Zeit für die Umstellung ist unrealistisch kurz.
• Das Budget für die Umstellung ist unrealistisch niedrig.
• Die Erwartungen an die Ergebnisse sind unrealistisch hoch.
• Der Mehraufwand für Projektmitarbeiter, die an der Standardumsetzung beteiligt sind, wird unterschätzt.
• Die Standardumsetzung wird von jungen Beratern betrieben (ohne eigene Projekterfahrung).

Die Vorstellung, dass sich die Mitarbeiter auf neue Standards freuen und kräftig mit anpacken, ist nicht realistisch. Niemand sitzt da und wartet darauf, neue Entwicklungsabläufe auszuprobieren und zu dokumentieren. Diese Zeit ist einfach nicht da.

Die sogenannte Prozessoptimierung, betrieben unter solchen Vorzeichen, bringt Projekte um. Diese werden regelrecht ruiniert, wenn Standardumsetzung derart stattfindet. Das Ergebnis sieht in der Regel so aus, dass die neuen Arbeitsanweisungen im Regal verstauben, die Standards gar nicht mehr laut erwähnt werden dürfen und man sich mit dem Kunden mehr oder weniger stillschweigend auf eine „Hoffentlich geht es gut“-Vorgehensweise geeinigt hat.

Die Lösung? Sie besteht darin, dass das alles einfacher werden muss. Das bedeutet nicht, dass alle Projekte nun rein agil werden müssten. Allein mit Stand-ups und Burn-downs kann man ein großes Projekt nicht stemmen. Das ist in Branchen, in denen Systemfehler Menschenleben aufs Spiel setzen, einfach zu riskant. Die Lösung steckt in der Umsetzung des Gedankenguts, das in Standards und in der Expertenerfahrung steckt. Meiner Erfahrung nach müssen aber Standards überhaupt nicht wörtlich umgesetzt werden. Noch nicht einmal alle Prozesse müssen implementiert werden. Hier mein Ansatz für eine gelungene Standardeinführung:

• Erfahrung, Erfahrung und nochmals Erfahrung. Für die Standardumsetzung müssen Experten mit Erste-Hand-Projekterfahrung her.
• Eine minimale Teilmenge aus den Standards festlegen. Unter anderem Konfigurationsmanagement, Projektplanung, gute Design-Praktiken (wie Expertenreviews) und Qualitätssicherung (insbesondere Tests auf allen Ebenen) sind unabdingbar. „Prozesse“ wie „Risikomanagement“ als separate Entitäten aufzusetzen ist in der Regel überflüssig.
• Standards sowohl für Assessoren als auch für Entwickler umsetzen, aber so, dass sie sich nicht gegenseitig in die Quere kommen.
• Ergebnisse, Vorlagen und Tools in den Vordergrund stellen. Abläufe schwach gewichten.
• Auf Experten im Projekt setzen.

Der letzte Punkt ist entscheidend. Es gibt Organisationen, in denen viel Infanterie eingesetzt wird. Dort sind individuelle Skills nicht wichtig, die Befehlskette und die Abläufe sind entscheidend. Andere verfolgen eher das Ziel, SWAT-Teams auszubilden. Die Projektteams sind kleiner, denn sie bestehen aus hochproduktiven, hochmotivierten und auch hochbezahlten Experten. In solchen Teams können Standards richtig Spaß machen, wenn sie richtig angepackt werden.

Nun stellt sich natürlich die rhetorische Frage, ob so viele gute Experten auf dem Markt sind, dass man mit ihnen ein Projekt staffen kann?

Nein, es sind nicht genügend Experten da. Ich habe aber nicht versprochen, dass der pragmatische Ansatz einfach wird. Ich sehe jedoch immer wieder, dass speziell bei neuartigen Produktentwicklungen nur dann Erfolg erwartet werden kann, wenn man bestmögliche Leute anwirbt. Es ist nicht einfach. Ich bin jedoch inzwischen absolut sicher, dass dies der beste Weg ist: minimalistische Prozesse in Expertenteams sind ein Ansatz, der unglaublich agile „T-Rex“-Organisationen erzeugt. Unternehmen wie Google zeigen diesen Weg auf. Google heuert sehr gut bezahlte, hochkarätige Experten an. Zugleich genießen diese Experten viel Freiraum, zu Deutsch: minimalistische Prozesse.

Und eine Profitabilität wie Google – die möchte ja jeder haben.