In meiner Tätigkeit ist es mehrfach vorgekommen, das ich zu einem Projekt berufen wurde, das vor dem Scheitern stand. Es waren in der Regel komplexe Projekte mit vielen Stakeholdern und ambitionierten Zielen.

Der Grund für die hohe Eintrittswahrscheinlichkeit war meist fehlende Struktur und indifferente Kommunikation im Projekt. Ich möchte an einem Beispiel aufzeigen, welche Möglichkeiten man hat, ein solches Projekt zu retten.

Als Beispiel dient ein großes Projekt zur Entwicklung eines multifunktionalen Arbeitsplatzes mit einem speziellen Frontend auf Basis von Windows 10. Dieser Arbeitsplatz sollte den Betriebsablauf im Drei- Schicht- Betrieb mit damals 17.000 Mitarbeitern unterstützen. Der vorherige Arbeitsplatz basierte auf Windows XP.

Anforderungen waren in Form von Erwartungshaltungen formuliert, d.h. es gab lediglich Aussagen wie „Der Arbeitsplatz muss genauso aussehen und funktionieren wie der alte Arbeitsplatz“.

Da der Kunde Software- und Infrastruktur- Entwicklung nicht trennte, wurde ein Software- Entwickler als Architekt und PM beauftragt, das Projekt zu verwirklichen.

Die Krise

Ein definitiver Stand der Entwicklung war bei der Übernahme des Projektes nicht erkennbar:  Der Basis-Client war begonnen und dokumentiert, jedoch wurde die Entwicklungsarbeiten für das Frondend am Betriebssystem vorbei programmiert. Somit entstanden u. a. redundante Funktionen, die zu größten Teil nicht die Qualität der bereits vorhandenen Funktionen erreichte.

Der bedrückendste Teil war aber die vollständig fehlende Entwicklungs- Test- und Fehlerbehebungs- Kultur. Es fehlte an dokumentierten Aufgaben, (Teil)- Abnahmen und der gesamten Dokumentation. Zudem war der Delivery- Prozess in der Software- Entwicklung vollständig von einer Person abhängig und nicht durchgängig automatisiert..

Der Deployment- Prozess für den Basis-Client fehlte vollständig.

Die Kommunikation zwischen Projekt, Nachbarprojekten und Programmleitung war  vollständig zum Erliegen gekommen. Das Projekt war zu diesem Zeitpunkt bereits mehrere Jahre alt.

Was war zu tun ?

Um das Projekt aus dem verfahrenen Status Quo in eine produktive Situation zu bringen, waren einige grundsätzliche Änderungen im Projekt notwendig. Sie werden in den nachfolgenden Kapiteln beschrieben.

• Etablierung eines Entwicklungsprozesses
• Quality-Gates
• Einführung von Kommunikationsregeln
• Kommunikation mit Programmleitung und Nachbarprojekten
• Dokumentation
• Projektplanung und agile Projektführung
• Teams und Verantwortlichkeiten

Etablierung eines Entwicklungsprozesses

Damit die einzelnen Aufgaben des Projekts zielgerecht bearbeitet werden können, ist ein klarer Entwicklungsprozesses notwendig.

Der Prozess startet mit der Annahme einer Anforderung, über die Entwicklung, den Test und die Abnahme im Projekt. Alle abgenommenen Aufgaben werden zyklisch zu einem Release zusammengestellt. Dabei sind folgende Regeln zu beachten:  

• Anforderungen werden immer an das Anforderungsteam gestellt
• Anforderungen durch das Anforderungsteam werden bewertet nach: Erwartungshaltung des Fachbereichs, Inhalt, Lösungsraum,  Aufwand, Dauer, Testrelevanz
• Das Anforderungsteam bestand aus Business Analyst, Solution Architekt, dem RTE  und / oder techn. Project Manager
• Alle Projektmitglieder sind in Ihrem Themengebiet CONSULTANT
• Alle Projektmitglieder sind in der Kerngeschäftszeit (9:00 – 17:00 Uhr) auskunftsfähig
• Dokumentation wird nach dem Dokumentations-Style-Guide aufgebaut.

Der Entwicklungsprozesses wurde in die nachfolgenden Prozessschritte gegliedert:

• Anforderung
• Qualifizierung /Priorisierung
• Entwicklung
• Test (Integrations-Test & U.A.T)
• Release & C.R.
• Produktion

Quality-Gates

Entlang des Entwicklungsprozesses musste die Qualität der Ergebnisse wiederholt überprüft werden. Das begann mit dem Code Review oder einem (Vier Augen) Systemtest, einen Integrationstest, einem Performancetest (wenn notwendig), dem User Acceptance Test (UAT) Jedes Test- Szenario entspricht einem Quality Gate.

In der Software-Entwicklung konnten die Tests bis auf Integrationstest und UAT automatisiert werden.

Neben den Quality Gates im Entwicklungsprozess wurden weitere Quality Gates beim Deployment der notwendigen Infrastruktur eingeführt. Über dies Quality Gates wurden Defekts im Deployment Prozess identifizierbar.

Generell gilt: zu Viele Quality Gate werden kontraproduktiv.

Einführung von Kommunikationsregeln

Jede Person kommuniziert gerne individuell. Das ist aber in einem Projekt nicht möglich. Das bedeutet, das es feste Regeln und Tools für die Kommunikation geben muss. Kommunikation bedeutet auch nicht nur die Erreichbarkeit, Pünktlichkeit und Auskunftsfähigkeit im Projekt. Es umfasst auch die Bereitstellung der Arbeitsergebnisse ohne weitere Aufforderung an einen festgelegten Ort.

• Teams ist das gesetzte synchrone Kommunikationsmittel, ersatzweise Telefon etc.
• Mail die das gesetzte asynchrone Kommunikationsmittel. (informell)
• Jira ist das gesetzte asynchrone Kommunikationsmittel (formell)
• Es gibt ein gesetztes Test- und Defects- Management- Tool im Projekt
• Jedes Projektmitglied stellt die Informationen zur Kommunikation (sofern sie nicht durch das Projekt bereitgestellt werden) zur Verfügung.
• SharePoint unterstützt Dokumentensammlung und fasst Quellen zusammen
• Git ist das Repository für Scripte und Programmcode
• Ein Glossar ist verbindlich

Kommunikation mit Programmleitung und Nachbarprojekten

Da hier Stillstand erreicht wurde, musste die Kommunikation mit den Nachbarprojekten und der Programmleitung neu organisiert werden. Dazu diente die vollständige Transparenz über den Stand. Sie beinhaltete die u.a. Erläuterung der getroffenen Maßnahmen zur Abhilfe. Außerdem wurde festgelegt, welche Personen für diese Kommunikation geeignet waren.

Dokumentation

Dokumentation, zumal in einem solch großen Projekt hat immer einen sehr hohen Stellenwert. Denn sie transportiert nicht nur das Ergebnis einer Aufgabe. Sie vermittelt auch den Grund an die Personen, die mit der Doku arbeiten sollen.

• Dokumentation ist Teil der vollständigen Bearbeitung einer Aufgabe
• Dokumentation richtet sich immer an eine ist immer Zielgruppe.
• Dokumentation ist immer auf dem Stand der Entwicklung
• Dokumentation folgt immer einem Style Guide
• Dokumentation ist an das Style Guide anzupassen
• Dokumentation muss überprüft und bewertet werden (Review).
• Dokumentation ohne Review = keine Einlieferung

siehe: Grundlagen für eine sichere IT-Organisation – Dokumentations-Reifegrade

Teams und Verantwortlichkeiten

• Jede Person im Projekt ist verbindlich mit einem oder mehreren Themen verbunden. Diese Verbindungen wird an alle Projektmitglieder tagaktuell kommuniziert.

• Um Aufgaben besser koordinieren zu können wurden drei Teams gebildet:

• Frondend Software- Entwicklung
• Basis-Client Entwicklung
• Client-Deployment Entwicklung

• Pro Team wurde ein Team- Lead bestimmt. Jeder Team- Lead plant und koordiniert mit seinem Team den nächsten Sprint. Die Team- Leads stimmten sich mit dem techn. Projektleiter ab.

• Darüber hinaus wurden verschiedene clusterübergreifende Positionen entlang des Delivery-Prozesses geschaffen: Anforderungs-Manager / Business-Development -Manager Test-Manager Release-Manager

Verantwortlich für den Delivery- Gesamtprozess war der techn. Projektleiter. 

Die Gesamtverantwortung lag beim RTE (Release Train Engineer)

Der Teamaufbau erfolgte nach der folgenden Grafik.

Projektplanung und agile Projektführung

Das Infrastrukturprojekt konnte am sinnvollsten durch eine Hybride Lösung von Wasserfall und agilen Projekt-Management Methoden begleitet werden.

• Die Wasserfall-Planung kann die Bereitstellungs- Reihenfolge von Infrastruktur-Komponenten darstellen. Zudem eignet sie sich besser zur Kommunikation mit den Projekt- Owner oder dem Lenkungskreis.
• Agile Methoden wie Scrum sind sehr gut geeignet, einzelne Komponenten – Funktionen zu entwickeln, zu testen und zur  Integration vorzubereiten.

Die Herausforderung für den Projektleiter war es, beide Methoden zu verbinden. So konnte ein gemeinsames Verständnis über den Stand der Dinge für die Technik erreicht werden. Auch für das Business wurde ein gemeinsames Verständnis erzielt.

Fazit

Ich möchte Niemanden übermäßig mit der Aufzählung von Schulbuch -Weisheiten quälen. Deshalb nur soviel: Ein Projekt kann nur funktionieren, wenn die o.g. Punkte in geeigneter Weise im Vorfeld gelöst sind. Erfolgreich wird es, wenn alle Projektteilnehmer sich nicht zu ernst nehmen. Sie sollten eine gewisse Demut vor der Aufgabe haben. Respekt vor den Kollegen ist ebenfalls wichtig. Und wenn man auch noch das Ganze mit Humor würzen kann, dann kann fast nichts mehr schiefgehen.

P.S. Für den Projekt-Owner: Zu einem Projekt gehört immer ausreichend Ressourcen!