In einer Beziehung ist es wie in einem Projekt. Wenn die Partner bzw. Beteiligten aneinander vorbeireden, kann es zu Missverständnissen mit gravierenden Folgen kommen.
In einer Beziehung schauen sich die Partner irritiert an und können vielleicht herzhaft darüber lachen. In einem IT-Projekt kann der Hintergrund dieses kleinen Wortwitzes zur puren Verzweiflung führen.
Nehmen Sie sich kurzweilige 10 Minuten Zeit und lesen Sie die Tragik hinter diesem Witz.
Wer kennt es nicht?
Hochmotiviert geht es in die ersten Gespräche mit den Auftraggebern bzw. Product Owner. Seitenweise werden Notizen angefertigt und schnell kristallisieren sich die ersten Aufgaben heraus, die in den Backlog wandern und die ersten Funktionen und Oberflächen werden besprochen.
Nach sehr kurzen Gesprächen beginnt für die Entwicklung der erste Sprint für die Implementierung. Ein paar Module können von älteren Projekten übernommen werden und schnell ist der erste Prototyp erstellt.
So starten sehr viele agile Softwareprojekte.
Egal, ob es neue Implementierungen sind oder Erweiterungen bestehender Software. Nach den ersten Gesprächen sind die Entwickler Feuer und Flamme für das neue Projekt und der Product Owner kann es nicht erwarten, die erste Version der Software zu bekommen.
So startete auch das Projekt von Denis. Es fanden spannende und konstruktive Gespräche mit den Product Ownern statt. Alle waren begeistert und legten los. Scrum war für die Projektplanung gesetzt und passte auch zum Projekt. Die Product Owner sollten schnell etwas zum Testen bekommen.
Schnell wurde der Backlog für den ersten Sprint gefüllt und die Entwicklung legte los. Zwei Wochen dauerte ein Sprint. Während der erste Sprint lief, füllte Denis mit den Product Ownern und dem Scrum Master den Backlog. Die Product Owner sprudelten nur so vor Ideen.
Nach zwei Sprints war der erste Prototyp fertig und die Product Owner bekamen die erste Version zum Testen. Das erste Feedback kam nach einer Woche und war schon recht positiv. Es fehlten nur hier und da ein paar Kleinigkeiten, die ja kein Problem sein sollten. Somit wurden die Aufgaben in den Backlog für den nächsten Sprint gelegt.
So startete auch das Projekt von Denis. Es fanden spannende und konstruktive Gespräche mit den Product Ownern statt. Alle waren begeistert und legten los. Scrum war für die Projektplanung gesetzt und passte auch zum Projekt. Die Product Owner sollten schnell etwas zum Testen bekommen.
Nach zwei Sprints war der erste Prototyp fertig und die Product Owner bekamen die erste Version zum Testen. Das erste Feedback kam nach einer Woche und war schon recht positiv. Es fehlten nur hier und da ein paar Kleinigkeiten, die ja kein Problem sein sollten. Somit wurden die Aufgaben in den Backlog für den nächsten Sprint gelegt.
Schnell wurde der Backlog für den ersten Sprint gefüllt und die Entwicklung legte los. Zwei Wochen dauerte ein Sprint. Während der erste Sprint lief, füllte Denis mit den Product Ownern und dem Scrum Master den Backlog. Die Product Owner sprudelten nur so vor Ideen.
Da diese neuen Aufgaben wichtig waren, wurden Sie auch gleich abgearbeitet. Andere Aufgaben wurden dafür nicht geschafft und in den nächsten Sprint geschoben.
Das Vorgehen wiederholte sich für mehrere Sprints. Der Backlog ist immer mehr gewachsen und es wurden immer weniger, bald schon gar keine neuen Funktionen in einem Sprint fertiggestellt.
Es dauerte auch nicht lange und die Product Owner wurden unruhig und erhöhten den Druck. Die Software sollte nach einem Jahr komplett fertig sein und es waren, nach einem dreiviertel Jahr, nicht einmal die Hälfte der wichtigen Funktionen fertig.
Nicht nur die Product Owner, auch die Chefetage konnte nicht verstehen, warum alles so lange dauerte. Es wurde fast täglich ein Report zum aktuellen Funktionsstand angefordert.
Aber auch von der anderen Seite kamen Beschwerden. Die Entwickler waren sauer, weil die GUI und Datenbankfelder schon wieder angepasst werden mussten. Die Klassen und Funktionen waren voller Code, wo niemand mehr richtig wusste, ob dieser noch benötigt wurde. Durch die vielen Anpassungen tauchten auch immer mehr Bugs auf, die behoben werden mussten.
Denis bekam also Druck von drei Seiten: Chefetage, Product Owner und Entwickler-Team und jeder forderte eine Lösung. Das blieb nicht ohne Folgen.
Am Abend, wenn der Körper zur Ruhe kam, merkte Denis diesen Druck, eine innere Unruhe machte sich mehr und mehr breit.
“Man wälzt sich von Links nach Rechts, das Einschlafen wird immer schwieriger. Der Kopf arbeitet und geht immer wieder den Tag durch: die Gespräche mit dem Team, den Projektverantwortlichen, die Diskussionen mit den Product Ownern über den aktuellen Projektstand, die offenen Aufgaben, die Deadline.”
Immer wieder tauchen die selben Frage auf:
“Wie sollen wir diesen gigantischen Berg an Aufgaben schaffen?“
“Wieso werden keine neuen Funktionen mehr fertig?”
“Was können wir tun, damit wir schneller werden?”
Dann kommen die Selbstzweifel:
“Warum zum Teufel sind meine Projekte immer so furchtbar stressig?”
“Es fängt immer so gut an und dann?”
“Was mache ich falsch?“
Die Schuld wird auf andere geschoben:
“Warum sind die Programmierer nur so maximal unfähig?”
“Die Product Owner haben doch gar keine Ahnung und wissen nicht was sie wollen?”
Die schlaflosen Nächte, die Diskussionen mit dem Team und den Product Ownern, der Druck von allen Seiten und die Überstunden zeigten bei Denis die ersten Gesundheitsprobleme: Tinnitus, Kreislaufprobleme und Erkältungen waren dauernde Begleiter.
Nach einem Jahr sollte die Software fertig sein.
Es fehlten ⅓ der Funktionen, die für den Einsatz der Software extrem wichtig waren.
Es war ein Desaster!
Mit maximalem Einsatz wurde ein Plan erstellt. Alle wichtigen Funktionen wurden in Aufgaben gepackt. Diese Aufgaben wurden mit höchster Priorität angegangen und das Projekt um ein halbes Jahr verlängert.
Der Druck, fertig zu werden, stieg enorm an, da das Budget nach diesem halben Jahr komplett verbraucht, wenn nicht sogar überschritten sein wird.
Obwohl das Projekt den Abgabetermin überschritten hatte und das Budget drohte aufgebraucht zu werden, stellte keiner der Projektbeteiligten die Frage:
“Was müssen wir am Vorgehen ändern, um unser Ziel zu erreichen und warum lief es bis jetzt so mega schlecht?”
Jeder steckte so tief in seinen Aufgaben drin und niemand nahm sich Zeit für eine offene Reflexion. Alle hatten schon Zeit und Geld investiert und nun musste die Software fertig werden, egal wie.
Die Priorisierung und der Fokus auf die wichtigsten Funktionen war der richtige Schritt, aber das Vorgehen, welches zu diesem Dilemma führte, wurde nicht geändert. So wurde weiter gewerkelt wir im vergangenen Jahr und es kam wie es kommen musste.
Nach dem halben Jahr war die Software immer noch nicht fertig und überschritt gnadenlos das Budget.
Diese Geschichte ist kein Einzelfall. Viel zu oft höre ich von solchen Projekten. Alle sind Feuer und Flamme, wollen die Welt einreißen und legen sofort los. Dabei wurde noch nicht einmal das Fundament für das Projekt erstellt.
Das gleiche passierte auch in Denis seinem Projekt. Nach Projektabschluss nahm er sich Zeit und wollte herausfinden, was er beim nächsten Projekt besser machen kann. Gemeinsam haben wir seine Projekte aufgearbeitet.
Am Anfang unserer Betrachtung sah alles völlig normal aus.
Die Entwickler haben nach bestem Wissen und Kenntnissen die Software implementiert.
Die Feedback-Schleifen zwischen Entwickler und Product Owner haben sehr gut funktioniert.
Auch Scrum als Methode hat seinen Dienst getan.
Die Probleme lagen also weder an der Technik, noch am agilen Vorgehen.
Es fand ein regelmäßiger Austausch zwischen Entwickler und Product Owner statt und das Projektmanagement hat ebenfalls funktioniert.
Wir betrachteten die einzelnen Parteien!
Als erstes schauten wir uns die Product Owner an und stellten fest, dass die Unterlagen zum Teil recht schwammig waren. Die Product Owner konnten nicht genau erklären, was sie konkret wollten. Sie hatten zwar viele Ideen, konnten diese aber weder konkret zu Papier bringen, noch waren Sie in der Lage, die Funktionen für die Entwicklung greifbar zu beschreiben.
Auf der anderen Seite waren die Entwickler überzeugt, verstanden zu haben, was das eigentliche Ziel der Software ist und begannen mit der Implementierung, ohne darauf zu achten, ob die Beschreibungen in den Aufgaben im Projektkontext plausibel waren.
So kam es immer wieder zu Nachbesserungen und Änderungen und jeder weiß, dass Änderungen im Quellcode Tür und Tor für Bugs öffnen.
Die Probleme lagen überwiegend bei den Anforderungen. Die Erhebung, die Erfassung und die Kontrolle über das gemeinsame Verständnis waren komplett mangelhaft.
Wir schauten uns die Anforderungserhebung und die Formulierung der Anforderungen an und erarbeiteten eine Strategie, wie die Vorgehensweise beim nächsten Projekt sein muss, damit die gleichen Probleme nicht wieder auftauchen.
Das nächste Projekt ließ auch nicht lange auf sich warten und startete ähnlich wie die Projekte davor. Alle wollten gleich loslegen mit der Implementierung. Durch unser geplantes Vorgehen zum Projektstart, konnte der Implementierungsdrang etwas eingedämpft werden und es wurde ein Sprint, nur für die Anforderungserhebung gestartet. Die Entwicklung wurde zu Planungs- und Schätzrunden eingeladen und die Product Owner arbeiteten an Ihren Ideen für die Software.
Nach dem Sprint waren die Anforderungen für die ersten Sprints viel besser ausformuliert, das Ziel der Software war laserscharf definiert und jeder konnte fokussiert daran arbeiten.
Wenn die Product Owner und die Entwicklung aneinander Vorbeireden kann das gravierende Folgen haben.
Der Wortwitz in der Überschrift verliert schlagartig seinen Witz. Vereinbarte Termine platzen, Budgets werden gnadenlos überschritten und die Gesundheit der Beteiligten kann massiv darunter leiden. Laserscharfe Anforderungen und klar kommunizierte Ziele sind das A und O in jedem Projekt.
Wenn Sie mehr zum Thema Projekt- und Anforderungsmanagement in IT-Projekten lesen möchten, dann freuen Sie sich auf den nächsten Beitrag mit dem Titel:
“Kann das in den Müll oder brauchen wir das Wissen noch?”
Projektmanager und Anforderungsmanager
Seine Botschaft: Jeder kann erfolgreich Projekte planen, managen und dokumentieren.