Eigentlich fast fertig – die verflixten letzten 10%

 

Einer der häufigsten Sätze, die ein Projektmanager zu hören bekommt, dürfte sein: „Ich bin eigentlich fast fertig“.  Mathematisch begabte Projektmitarbeiter hinterlegen gerne noch den konkreten numerischen Wert: „ich bin zu 90% fertig“. Zeit vergeht linear, der Projektfortschritt jedoch nicht. Während wir auf die letzten 10% warten, sterben schnell mal die Dinosaurier aus, ganze Zivilisationen streben empor und zerfallen. Was können wir tun, um endlich ganz fertig zu werden?

Ich entschuldige mich vorab - dies soll ein Beitrag zur Projektfortschrittsverfolgung werden - leider nimmt einen großen Teil des Textes allerdings wieder einmal die Anforderungs- und Zieldefinition ein. Eine Fortschrittsverfolgung, die ja im Kern eine Soll - Ist - Gegenüberstellung ist, kann jedoch nicht durchgeführt werden, wenn das Soll nicht vorab definiert wurde. Stellen Sie sich vor, Sie laden Ihr Smartphone: Ein stylisher Ladebalken wandert vom roten Bereich linear auf 100% - das ist Ihre Fortschrittskontrolle. Stellen Sie sich nun vor, dieser Balken würde nicht existieren: Sie wüssten nicht vorher, wann der Akku Ihres Smartphones leer sein wird und sie wüssten nicht, wann es voll geladen sein würde. Sie wären im völligen Blindflug unterwegs. Im Projektmanagement sind die "100% Akku" die Anforderungen bzw. Ziele und der Ladebalken der Projektfortschritt.

Um ganz fertig zu werden, müssen wir also zunächst natürlich wissen, was "ganz fertig" bedeutet. Dazu verlangt das agile Projektmanagement eine anpassbare Definition von Fertig („Definition of Done“), im klassischen Projetmanagement wird versucht, das Problem über vorab formulierte Abnahmechecklisten, Abnahmekriterien für die zu Projektbeginn definierten Ziele oder Akzeptanzkriterien zu lösen.

Das erste Problem liegt somit im Bereich des Anforderungsmanagements oder auch Demandmanagement. Der Anforderer ist dafür verantwortlich, dass seine Anforderungen ernst genommen werden und überhaupt erst realisiert werden können. 

Wer ist der Anforderer eines Projektes? Formell natürlich der Auftraggeber, also eine Person, die in der Führungsriege zu finden ist. Allerdings kann auch ein Sachbearbeiter eine Projektidee geben, um eine Verbesserung aus operativer Sicht anzustoßen. Nicht zuletzt munkelt man, dass Projekte mitunter dazu dienen, um die Wünsche der Kunden besser befriedigen zu können - somit tun wir gut daran, die Anforderungen möglichst vieler Stakeholder zu kennen und sie systematisch aufzunehmen. Die Anforderer sollten sich dazu vorab Gedanken zu folgenden Punkten machen:

• Was ist das (Haupt)Ziel? 
• Welche Nebenziele existieren? 
• wie kann die Erreichung der Ziele gemessen und belegt werden?
• Was ist der Nutzen hinter der Anforderung? 
• Welche Ziele müssen zwingend erreicht werden, welche Ziele sind nur nützliches Beiwerk? (z.B. anhand der Muss- Kann- Soll oder MoSCoW- Priorisierungstechnik) 

Bei der Zielspezifizierung helfen wie bereits in meinem Beitrag zur Anforderungsdefinition beschrieben die üblichen Methoden wie  SMART, AROMA oder User- Stories, um nur einige Möglichkeiten zu nennen.

Was tut nun der Projektleiter, außer bei der Vorstellung der Anforderungen Kaffee zu trinken und so zu tun, als ob er zuhört? 

Der Projektleiter moderiert das entsprechende Meeting mit dem Ziel, ein einheitliches Verständnis der Stakeholder auf das kommende Projekt zu erwirken. Ziel dieses Abstimmungsprozesses ist, dass die Beteiligten sich von ihren individuellen Anforderungen auf ein gemeinsames Bild einigen - insbesondere hinsichtlich der angesprochenen Priorisierungen der Anforderungen. 

Wenn die Anforderungen klar sind, kann mit der Realisierung begonnen werden.

Ob wir nun zu Beginn einen klassischen Projektablaufplan erstellt haben oder uns die wichtigsten Anforderungen für den nächsten agilen Sprint rausgesucht haben, sei an dieser Stelle erst einmal unerheblich - wir wollen ja so langsam zum Kern dieses Blogs, nämlich der Fortschrittskontrolle kommen. An dieser Stelle wissen wir nun also, was "100% Akku voll" bedeutet.

Wie etablieren wir also eine wirkungsvolle Fortschrittskontrolle?

Das Zauberwort lautet wenig überraschend: Kommunikation. Fragen Sie Ihre Realisierungspartner in regelmäßigen Abständen nach dem Status. Geben Sie sich dabei nicht mit allgemeinen Aussagen wie „fast fertig“ oder „ca. 80%“ zufrieden – fragen Sie konkret nach: Welches Ziel wurde bereits erreicht, woran wird gerade gearbeitet? Was sind die nächsten Schritte? Jeder Fortschrittsbericht ist subjektiv: Schwarzseher werden ihre Fortschritte eher geringer einschätzen, optimistische Personen erledigen gefühlt schnell 90% der Arbeit und benötigen für die restlichen 10% länger. Ein persönliches Gespräch mit den Realisierungspartnern hilft, Missverständnisse zu vermeiden und eventuelle verschiedene Sichtweisen auf den Fortschritt kritisch zu hinterfragen. Die wichtigste Komponente im Projektfortschritt ist immer der Mensch: Sind die Projektmitarbeiter motiviert und kann der Projektleiter ihre Arbeitseinstellung und individuelle Sichtweise auf den Projektfortschritt richtig einschätzen, so ist ein genereller Projektfortschritt sichergestellt. Ob dies in dem festgelegten Maße geschieht, ist dann "nur" noch Feintuning. 

Ich verspreche Ihnen, dass die Wahrscheinlichkeit für Abweichungen zwischen Plan und Ist umso geringer ist, je besser die Anforderungen bzw. Ziele definiert sind und je intensiver Sie den Fortschritt kontrollieren.  "Intensiv" bedeutet dabei häufiger und genauer - kurz gesagt: Je mehr Zeit Sie als Projektleiter darauf aufwenden, Fragen zum Fortschritt zu stellen, desto eher können Sie bei Planabweichungen gegensteuern. Ja, richtig gelesen: Die Arbeit des Projektleiters ist nicht damit getan, Abweichungen festzustellen, das wäre ja noch recht einfach, letztendlich geht es darum, Gegenmaßnahmen umzusetzen um nach Möglichkeit wieder in den Plan zu kommen.

Trotz allem Verständnis und klassischer oder agiler Zieldefinition kann es leider zu Abweichungen kommen. Die Frage ist dann, wie wir darauf reagieren. 

Im klassischen Projektmanagement können wir "einfach" entlang des magischen Dreiecks entscheiden: Eine Fortschrittsverzögerung zu einem festgelegten Berichtzeitpunkts stellt eine Abweichung in der Leistungsdimension dar - diese kann durch die Dimensionen "Zeit" oder "Kosten" kompensiert werden, sprich: Wir benötigen halt länger oder wir setzen mehr interne oder externe Ressourcen ein, um die Leistungsabweichung zu kompensieren. Im agilen Projektmanagement haben wir evtl. ein Sprintziel durch die Leistungsabweichung nicht erreicht und kompensieren ebenfalls, indem wir das Ziel in einen folgenden Sprint aufnehmen oder das Backlog verlängern - auch hier kompensieren wir primär anhand der Dimension "Zeit" und indirekt in der Dimension "Kosten".

Genug der Theorie: Planabweichungen sind ärgerlich. Ob agil oder klassisch sollten wir diese im Team diskutieren und im Zuge einer Lessons Learned oder Sprint Review dafür sorgen, dass das gesamte Team daraus lernen kann, damit sich Abweichungen zumindest aus denselben Gründen nicht wiederholen. Sollten wir es dabei schaffen, das Team so zu motivieren, dass es diese Verzögerung zeitnah aus eigener Kraft aufholen möchte, so hat der Projektleiter ein episches Werk geleistet. Hier möchte ich den Aspekt der individuellen Entwicklung der Teammitglieder in den Fokus stellen: Wenn ein Kollege es nicht gewohnt ist, im Projekt zu arbeiten und seinen Arbeitsaufwand für ein bestimmtes Arbeitspaket oder einen Sprint zu schätzen, so wird er den Arbeitsaufwand tendenziell unterschätzen. Daraus resultiert höchstwahrscheinlich eine Verzögerung. Durch mehr Erfahrung in der Projektarbeit und einen Projektleiter, der den Lerneffekt fördert statt Verzögerungen bestraft, sollten sich die Schätzungen im Laufe der Zeit verbessern und Abweichungen so mit zunehmender Erfahrung des Projektteams (oder Scrumteams) verringern. 

Der große Vorteil der agilen Vorgehensweise liegt hinsichtlich der Fortschrittsverfolgung übrigens darin, dass Fortschritte in kleinen Zyklen von typischerweise 2 Wochen kontrolliert werden. Der klassische Projektleiter kann sich diese Philosophie nutzbar machen, indem er ebenfalls in kleineren Zyklen Fortschrittsbesprechungen ansetzt und insbesondere bei länger andauernden Projektphasen nicht erst zum Ende einer Phase hin Fortschrittscontrolling betreibt. So ist auch der Ladebalken in unserem Smartphone in aussagekräftige, gleichmäßige Teilschritte unterteilt - eine Einteilung, bei der der Ladebalken so lange auf 0% bleibt, bis er schließlich auf 100% springt macht keinen Sinn, genauso wie eine Fortschrittsanzeige in sagen wir mal zunächst 10%, dann bei 50% und schließlich bei 80% und 100% - wir könnten die Fortschrittsdauer mit diesen Fortschrittsmesszeitpunkten einfach nicht sinnvoll planen.

Wie und in welchen Zyklen verfolgen Sie den Status in Ihren Projekten? Wie gehen Sie mit Ihrem Projektteam bei Planabweichungen um? Wie entscheiden Sie, welche Gegenmaßnahmen Sie einleiten? Wie oft kontrollieren Sie den Ladebalken Ihres Smartphones? Lassen Sie es mich in Ihrem Kommentar wissen.

Das Problem mit den Socken: Wie definieren wir sinnvoll Anforderungen?

Komm, wir spielen Lastenheft - Pflichtenheft: Ein Spiel, bei dem es nur Verlierer gibt - das Spiel für alle diejenigen, die eigentlich Romanautoren werden wollten, bei denen es aber doch nur zum Projektmanager gereicht hat. Hier kann sich der klassische Projektmanager noch voll austoben, seine Gedanken in Prosaform darlegen und das tolle ist ja: Je mehr wir als Auftraggeber schreiben, desto besser denken wir sind unsere Anforderungen dargelegt und desto mehr können wir auch in Form eines Pflichtenheftes vom Auftragnehmer erwarten. Trotzdem bemerken wir oft im laufenden Projekt, dass Auftraggeber und Auftragnehmer sich in wesentlichen Punkten nicht verstanden haben - das Projekt wird teurer oder verzögert sich. 

Ein Lastenheft enthält die Anforderungen des Auftraggebers. Das ist per se eine gute Sache: Wenn ich etwas tolles zu Weihnachten bekommen möchte, sollte ich eine Wunschliste schreiben, andernfalls kann ich mich nicht beschweren, wenn wieder nur Socken unter dem Christbaum liegen. Wenn ich als Stichwort "Auto" auf meinen Wunschzettel schreibe, kann dies von den geneigten Empfängern sowohl als Spielzeugauto als auch als Kleinwagen aufgefasst werden - da ist es also hilfreich wenn ich spezifiziere, dass ich schon gerne den neuen Porsche Taycan GTS in der Farbe Schwarz mit 598 PS und sämtlicher Sonderausstattung hätte. Dafür zeigt mir dann jeder in meiner Verwandtschaft einen Vogel und zur Strafe werde ich abermals mit Socken beschenkt - die Anforderung wurde zwar klar definiert, aber leider nicht auf Machbarkeit hin überprüft.

Im agilen Projektmanagement sagen wir uns von den Lastenheftromanen los und arbeiten stattdessen mit kurzen Userstories als Anforderungsbasis - eine Wunschliste aus Sicht des Kunden oder zumindest davon, was wir meinen, was der Kunde sich wünscht. Somit schreibe also ich als Product Owner  eine Wunschliste für jemand anderen, also etwa so: Ich habe vor kurzem mal mit meiner Frau gesprochen, sie hat im Winter oft kalte Füße und findet Socken generell ganz praktisch - also denke ich, dass meine Frau sich Socken zu Weihnachten wünscht. Schon ist die Userstory komplett.  

Die Userstory wird in Tasks aufgeteilt, also in Aufgaben umgewandelte Anforderungen - aber wie können wir die sinnvoll und objektiv priorisieren? In der Praxis kann nicht nach jedem Sprint ein lauffähiges Produkt entstehen und beim fortlaufenden Entwickeln von Verbesserungen entsteht regelmäßig ein höherer Testaufwand dieser Verbesserungen, als wenn Verbesserungen systematisch implementiert werden würden. 

Am Anfang eines Projektes stehen immer Anforderungen - darum geht es im Kern. Bleiben wir beim Bild der weihnachtlichen Wunschliste, die die meisten von uns aus Kindertagen kennen dürften. Wie bauen wir unsere Wunschliste am besten auf? 

Als Kinder haben wir die Wunschliste auf einen Zettel geschrieben, in Stichpunkten und evtl. mit Erläuterungen. Jetzt sind wir erwachsen, im Büro und können Excel bedienen. Zusätzlich wirkt es irgendwie klarer strukturiert, wenn wir in der ersten Spalte eine fortlaufende Nummer hinzufügen, das mag der Chef halt und wir können in nachfolgenden Dokumenten einfach auf die Anforderungsnummer verweisen, damit der Leser dann halt noch ein weiteres Dokument suchen muss und so die Gefahr verringert ist, dass er am Arbeitsplatz einschläft. 

Die aussagekräftige Gestaltung der Erläuterungsspalte ist gar nicht so leicht - überhaupt kann ich die ja eigentlich leer lassen, ich weiß ja, was gemeint ist, oder? Das Bild der Wunschliste zeigt sehr gut, dass nicht der Absender wissen muss, was gemeint ist, sondern dass die Empfänger es verstehen müssen - und das ist erfahrungsgemäß wesentlich schwieriger. Machen wir es uns an dieser Stelle leicht und verwenden wir ein Konzept zur Zieldefinition -SMART. Ziele müssen 

• Spezifisch
• Messbar
• Erreichbar
• Realistisch und
• Terminiert

sein, dann funktionieren sie als Leitplanken. Ziele sind nun nicht gleich Anforderungen, aber aus Anforderungen resultieren Ziele. Daher schadet es nicht, bereits die Anforderungen zum Verständnis in einem breiteren Empfängerkreis SMART zu definieren. AROMA ginge natürlich ebenfalls.

So, an dieser Stelle haben wir eine tolle Liste mit Anforderungen, bestehend aus 3 Spalten. Welche Anforderung realisieren wir nun zuerst? Das wissen wir noch nicht. Wir finden im Excel allerdings noch eine Menge leerer Spalten vor, also: Füllen wir eine davon. Nennen wir diese Spalte "Priorität" und legen wir eine Skala fest. 1 bis 5, Schulnoten, 1 bis 10. Gehen wir unsere Anforderungen durch um sie derart zu priorisieren, so stellen wir fest, dass natürlich alle Anforderungen wichtig sind- andernfalls hätten wir uns ja auch nicht die Mühe gemacht, sie nieder zu schreiben. Wir machen ja schließlich nichts unwichtiges. Schlimmer wird das Problem noch, wenn wir die Anforderungsliste sinnvollerweise in einem bereichsübergreifenden Team durchgehen - da findet jeder etwas anderes wichtig und keiner will seine Anforderungen hinter denjenigen der Anderen zurückstellen. Die Lösung: Wir benennen die Spalte "Priorität" um in "Rangfolge" - eine Rangfolge ist eindeutig, Prioritäten sind das nicht - mit anderen Worten: Ich kann eine unendliche Anzahl von Aufgaben auf der maximalen Priorität haben, nur eine Rangfolge gibt eine eindeutige Abarbeitungsreihenfolge wieder. Unsere Anforderungsliste sieht nun so aus: 

Wir bekommen das Projektteam dann irgendwie dazu, sich auf eine gemeinsame Rangfolge zu einigen und können glücklich sein?

Nein, leider noch nicht. Wer bis hierhin durchgehalten hat, kann nun schonmal eine tolle Anforderungsliste mit nur 4 Spalten erstellen, und die hilft wirklich enorm - der Clou kommt jedoch der Spannungskurve wegen natürlich am Ende: Die Rangfolge der Anforderungen stellt leider nur in den seltensten Fällen eine sinnvolle Abarbeitungsreihenfolge dar, insbesondere in komplexen Systemen. Auf die Abarbeitungsreihenfolge sollten wir jedoch bestenfalls bei der Anforderungsdefinition bereits achten, um dem nachfolgenden Realisierungsprojekt einen geschmeidigen Verlauf zu ermöglichen.

Nehmen wir ein Beispiel aus der Automobilindustrie: Das Team hat per Kundenbefragung herausgefunden, dass Reifen das wichtigste am Auto sind, die haben ja den Kontakt zur Straße - also Rang 1. Dicht gefolgt vom Motor, der muss kraftvoll sein und einen ordentlichen Sound haben - Rang 2. Also legen wir besonderes Augenmerk auf den Motor und lassen uns gute Reifen zuliefern - das können wir so nur leider nicht zusammen testen, dafür bräuchten wir mindestens noch die Karosserie - die ist allerdings aus Kundensicht Standard und vollkommen unsexy, also hat sie den letzten Platz bei der Rangfolge erhalten. Im schlimmsten Fall merken wir einen Konstruktionsfehler im Zusammenspiel der Komponenten unseres Autos dadurch erst kurz vor Fertigstellung. Das Beispiel mit dem Auto soll anschaulich sein - bei IT- Projekten ist es wesentlich schwieriger, eine sinnvolle Reihenfolge für Realisierungsschritte zu finden. 

Die absolut beste Lösung, welche ich für dieses Problem gefunden habe ist, anstatt eines langatmig ausformulierten Lastenheftes, einer vermeintlich kundenfreundlichen Userstory oder einer langweiligen Excel- Liste einen anschaulichen Sollprozess zu malen. In den meisten IT- Projekten kann der Sollprozess alle davor genannten Schritte ersetzen, auch wenn die beschriebene Anforderungsliste ein tolles Dokument zur zusätzlichen Spezifizierung der Anforderungen darstellt. Bei der Erstellung physischer Projektergebnisse wäre der Sollprozess nachgelagert der Anforderungsliste zu erstellen. 

Der Sollprozess gibt anschaulich eine praktikable Realisierungsreihenfolge vor: Als erstes werden diejenigen (System) Aufgaben realisiert, welche vorne im Sollprozess liegen - die können bereits getestet werden und liefern somit früh diejenigen Testgegenstände, welche auch nach Realisierung weiterer Prozessschritte benötigt werden. Testfälle müssen somit nicht für jeden Schritt neu erstellt werden, stattdessen werden sie zum Test nach Realisierung weiterer (System) Komponenten weiterverwendet. Anhand des Sollprozesses kann somit früh und mit möglichst wenig Aufwand mit zielführenden Tests begonnen werden.

Beherzigen Sie diese Hinweise, so haben Sie als Projektmanager mehr Zeit für die wesentlichen Dinge, die unsere Berufung erlebnisreich machen, z.B. das Schreiben von meterlangen Romanen per E-Mail oder dem Erstellen von umfangreichen Excel- Tabellen, die niemand außer Ihnen selbst versteht. 

Welche Erfahrung haben Sie mit der Anforderungsdefinition und deren Abarbeitung in Projekten sammeln können? Werden Ihre Lastenhefte vom Empfänger verstanden und verstehen Sie die Pflichtenhefte Ihrer Auftragnehmer? Wünschen Sie sich Socken zu Weihnachten? 

Lassen Sie es mich in Ihrem Kommentar wissen.