In meiner Tätigkeit ist es mehrfach vorgekommen, das ich zu einem in ein 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 die fehlende Struktur und die indifferente Kommunikation im Projekt. Ich möchte auch an einem Beispiel aufzeigen, welche Möglichkeiten man hat, ein 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 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 Dokumenten Style Guide aufgebaut. (in Vorbereitung)

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 und Pünktlichkeit und Auskunftsfähigkeit im Projekt, sondern 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 K. mit den Nachbarprojekten und der Programmleitung neu organisiert werden. Dazu diente die vollständige Transparenz über den Stand, die Erläuterung der getroffenen Maßnahmen zur Abhilfe und die Festlegung der Personen, die für diese Kommunikation geeignet waren.

Diese Maßnahmen waren eine initale Maßnahme, die in der täglichen Zusammenarbeit positiv unterfüttert werden musste.

Dokumentation

Dokumentation, zumal in einem solch großen Projekt hat immer einen sehr hohen Stellenwert. Denn sie transportiert nicht nur das Ergebnis einer Aufgabe, sondern auch das warum 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

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 Team – 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. 

Gesamtverantwortung lag beim RTE (Release Train Engineer)

Der Teamaufbau folgte dem nachfolgenden Schaubild.

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 uns so ein gemeinsames Verständnis über den Stand der Dinge für die Technik wie auch für das Business zu erreichen.

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 des nur, wenn sich alle Projektteilnehmer nicht zu ernst nehmen, eine gewisse Demut vor der Aufgabe und Respekt vor den Kollegen aufbringen. 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 genug Ressourcen!