Projekte in der Krise IV

Wie ein Projekt seiner Ausbaustufe das Leben schwer machen kann

Puh. Es war ein harter Weg, doch das Projekt steht endlich. Wir befinden uns in der Abnahmephase. Einige kleinere Findings und Nice-To-Have-Wünsche hat der Kunde noch. Wir haben noch etwas Budget in unserem Projekt und diese letzten Aufgaben werden gerade realisiert. Der Business Consultant hat das Ohr direkt am Kunden und wir erfüllen diese neuen Anforderungen quasi in Realtime. Ein kurzes Meeting mit dem Kunden, eine Mail an den Entwickler und los. Der Kunde testet jede neue Funktionalität direkt am System. Damit das knappe Restbudget für die Extras noch reit, machen wir sie schnell direkt auf dem System, welches bald live gehen soll. Der Code wird dann anschließend gesammelt in das Quellcodeverwaltungssystem eingecheckt. Der letzte Code, der letzte Test, Booya!

Der GoLive verläuft weitgehend problemlos. Die Codes sind JavaScript und andere Frontend-Logik, die wir in das Produktivsystem eingespielt haben. Damit musste die Seite nun nur noch öffentlich bekannt gemacht und die Rechte für die Benutzergruppen gesetzt werden. Alles läuft weitgehend glatt. Kleinere Bugfixes im Livesystem werden ebenfalls zeitnah gefixt. Die Akzeptanz ist hoch, die Stimmung gut.

Die Zeit vergeht. Das System läuft stabil, die Endnutzer arbeiten damit und entwickeln neue Ideen für Verbesserungen und neue Use Cases. Da das System wichtig ist, hat das Steering Board die wichtigsten Vorschläge und neuen Anforderungen gesammelt und ein neues Paket geschnürt. Das Projekt geht in Phase II und aufgrund der guten Leistung sind auch wir wieder als Entwicklungs- und Consultingmannschaft mit dabei.

Leider ist das damalige Entwicklungsteam inzwischen in anderen Projekten eingesetzt und nur sporadisch erreichbar. Daher wird ein neues Team eingesetzt. Der Business Consultant und Projektleiter konnten glücklicherweise aus anderen Projekten abgezogen werden und somit stehen zumindest an der Kundenfront die gleichen Ansprechpartner. Ein mehr oder weniger typisches Setting für eine Folgebeauftragung also.

Die Phase II

Und so beginnt es von Neuem. Doch schon bei Beginn liegt Ärger in der Luft. Die Entwicklermannschaft hat sich in die Dokumente der Anforderungsphase eingearbeitet und auch die INT- und QA-Maschine angesehen. Irgendwie ist es passiert, dass in den Anforderungs- und CR-Dokumenten etwas anderes steht, als im INT-System umgesetzt wurde. Das QA-System scheint sich außerdem ebenfalls in einzelnen Aspekten vom INT-System zu unterscheiden. Zudem geistern immer wieder E-Mails von dem letzten Entwicklerteam durch den Raum, die noch etwas anderes verkünden.

Klar, es war ja etwas hektisch zu Projektende. Aber im Quellcodesystem sind ja die aktuellsten Sources hinterlegt. Dann erneuern wir INT- und QA-System eben. Und schon tauchen die nächsten Fragen auf. Scheinbar wurden die Codes ohne oder unzureichendem Kommentar eingecheckt. Auch lassen sich daraus keine Pakete mehr erkennen weil gleich mehrere Pakete auf einmal eingecheckt wurden. Also lassen sich daraus keine Rückschlüsse auf Änderungen und Bugs schließen und auch der aktuelle Stand lässt sich so nicht eindeutig ermitteln. Na schön. Also installieren wir alles und schauen es uns an.

Der Business Consultant drängelt inzwischen etwas, da er für die neuen Anforderungen gerne einige Konzeptpapiere erstellen würde. Doch dazu braucht er Daten aus dem Bestandssystem und auch einige Screenshots.

Und nun wieder das Entwicklerteam, denn es ist leider wurden auch noch einige Konfigurationen nicht aktualisiert und nun funktionieren einige Funktionen nicht. Schließlich muss ein Entwickler der letzten Phase aus einem anderen Projekt losgeeist werden, damit dieser die Konfigurationen einstellen kann.

All das verzögert leider auch unsere Phase II immer weiter und der Anfangs gute Eindruck des Kunden wird leider getrübt. Natürlich kann man die Aufwände durch entsprechende Mehrarbeit wieder hereinholen, doch nun müssen auch die Dokumentationen aus Phase I noch nachbereitet werden. Und da nicht mehr alle Anforderungen vorhanden sind und man sich dem Kunden gegenüber natürlich auch keine Blöße geben will, wird man nie völlig aus dieser Klemme herauskommen und immer wieder gezwungen sein Dinge nach zu dokumentieren und durch Mehraufwände auszugleichen.

Was kann man tun?

Die Lösung ist natürlich offensichtlich und greift die Prinzipien aus dem ersten Teil der Serie auf. Nicht nur ein Projektplan muss sauber erstellt werden, sondern auch alle Änderungen im späteren Prozess müssen nachgetragen und aktualisiert werden. Man sollte bei der Umsetzung eines Projektes immer auch den gesamten Application Lifecycle im Blick haben. Was passiert, wenn eine Phase II kommt, oder ich die Applikation ablösen und auf eine neue Plattform heben will? Wir profitieren selbst davon, dass wir sauber dokumentieren und auch neue Anforderungen nachhalten. Denn wenn man gute Arbeit geleistet hat, ist es sehr wahrscheinlich, dass ein Kunde auch für den Folgeauftrag wieder den gleichen Dienstleister auswählt, anstatt sich der Gefahr auszusetzen mit einem etwas günstigeren Anbieter neues Lehrgeld zahlen zu müssen. Im Idealfall wirkt sich saubere Arbeit also sogar auf den Tagessatz aus, da man einen guten Ruf durchaus auch mal etwas höhere Kosten ausgleichen kann.

Und im Detail?

Soweit die Theorie. Aber was kann man denn nun ganz konkret tun? Nun, ich empfehle das ALM-Tool Visual Studio Online (ehem. Team Foundation Server). Durch geringe Kosten, hohe Verfügbarkeit und gute Skalierbarkeit bietet dieses Tool nahezu für jede Anwendung optimale Voraussetzungen. Außerdem bietet es diverse Werkzeuge für das ALM-Management. Zum Beispiel bei der Erfassung von Requirements, Tasks, Bugs, Issues, Testcases und ähnlichem, oder bei der Planung von Teams, Sprints und Kanban Boards. Aber auch für die Abbildung großer Projekte mit unterschiedlichen Epics, Features und User Stories ist es gut geeignet. Außerdem kann man die erstellen Dokumente oder auch Quellcode direkt zu jedem dieser Elemente direkt referenzieren. Die Vorteile sind so vielseitig, dass es für eine eigene Serie reicht. Deshalb soll dies nur als Anregung gedacht sein, sich selbst zu informieren. Oder natürlich auf ebenjene Serie zu warten. 🙂

Mehr zum Thema?

Angebot und Schätzung II

Im ersten Teil dieser Serie ging es darum, wie die Projektleitung ein Projekt beeinflusst und welche Auswirkungen dies auf eine gute Schätzung haben kann. Aus meiner Sicht ein Thema, welchem oftmals zu wenig Beachtung geschenkt wird. Im zweiten Teil wird es nun etwas offensichtlicher, denn es geht darum wie die Anforderungsqualität sich auf ein Angebot auswirken kann.

Zur Erinnerung, in dieser Serie möchte ich mich mit diesen Fragen auseinander setzen:

Weitere interessante Meinungen zu diesem Thema könnt ihr außerdem hier finden:

Wie wirken sich Anforderungen auf die Schätzung aus?

Es ist natürlich klar, dass man umso genauer schätzen kann, je mehr von den Anforderungen weiß. Ein plakatives Beispiel, woran sofort deutlich wird was ich meine, ist „Als Berater muss ich jeden morgen zu meinem Kunden kommen, um dort meine Leistungen erbringen zu können.“ Hinter dieser Anforderung ist ein riesiger Berg an Möglichkeiten verborgen. Geht der Berater zu Fuß, mit dem Rad, dem Auto, dem Zug oder dem Flugzeug? Wie schnell muss er dort sein? Wie weit ist die Entfernung? Gibt es die Möglichkeit eines Hotels und so weiter. Vielleicht gibt es auf der Strecke besondere Herausforderungen wie Baustellen oder die Parkmöglichkeiten sind vor Ort eingeschränkt. Vielleicht gibt es in der Nähe auch keinen Flughafen etc. etc. Allein mit dieser Anforderung können wir also quasi gar nichts anfangen und eine sinnvolle Planung und Abschätzung des Aufwandes ist nicht möglich.

Wie geht man im Idealfall mit Unklarheiten um?

Doch was, wenn nun genau so eine unklare Anforderung auf dem Tisch liegt? Der Auftraggeber hat vielleicht nicht daran gedacht, dass es so unklar ist. Für ihn, der täglich den Weg zurücklegt, ist die Anforderung doch ganz klar. Nun, das einfachste ist natürlich den Kunden danach zu fragen. Selbst in großen Ausschreibungen, bei denen der Kunde nicht direkt angerufen werden kann, gibt es die Möglichkeit Fragen als E-Mail einzureichen. Die Qualität der Fragen zeigt dem Kunden dabei oft schon, wie qualifiziert der Fragesteller ist. In meiner Laufbahn ist es öfter vorgekommen, dass dem Kunden allein die Qualität der Fragen besonders aufgefallen ist und er schon damit eine Vorauswahl der Kandidaten durchgeführt hat.

Mist. Jetzt hat man die Fragerunde in einer Ausschreibung hinter sich gelassen und dennoch gibt es Unklarheiten. Entweder, weil die Antworten neue Fragen aufgeworfen haben, oder weil man vergessen hat diesen Punkt anzusprechen. Welche Mittel haben wir dann? In diesem Fall bedienen wir uns einem Mittel des Risikomanagements. Wir stellen Annahmen auf und grenzen uns damit ab. Um unser Beispiel hierfür wieder zu Rate zu ziehen. Der Kunde hat seine Anforderung spezifiziert:

– Wohnort: Mannheim
– Zielort: Frankfurt
– Übernachtung: Nein
– Primäranforderung: Möglichst wenig Zeitverlust durch die Reisetätigkeit

So weit, so gut. Doch wieder stellt sich eine Frage. Voraussichtlich meinte der Kunde Frankfurt am Main, schließlich ist oder relativ weit für das tägliche Pendeln. Aber sicher können wir uns nicht sein und beides würde unterschiedliche Herangehensweisen erfordern. Wir grenzen uns also ab und schreiben in unser Angebot zu dieser User Story einen Unterpunkt „Annahmen und Abgrenzung“. Wir gehen davon aus, dass der Kunde Frankfurt am Main meint. Daher raten wir ihm zum Zug und den Öffentlichen. Im Zug kann der Kunde am Laptop arbeiten und damit seinen Zeitverlust minimieren. Andernfalls hätten wir eventuell zum Flugzeug geraten.

Wie man abgrenzt

Was haben wir gemacht? Wir haben versucht über eine Plausibilitätsprüfung zu ermitteln, welche Annahme die Wahrscheinlichste ist. Dann haben wir die weniger wahrscheinlichen Möglichkeiten abgegrenzt. Die Gründe für unsere Abgrenzung sollten dem Kunden ebenfalls in dem Kapitel erläutert werden. Selbst wenn wir dann falsch liegen und der Kunde nach Frankfurt/Oder will, kann er nachvollziehen wie wir auf den Schluss kommen. Dann kann er uns die Möglichkeit zur Nacharbeit geben, da er von unserer Arbeitsweise überzeugt ist. Würden wir diese Abgrenzung nicht hinein schreiben und der Kunde beauftragt uns, könnte er auf die vorgeschlagene Lösung beharren. In unserem Fall würden wir ihm also eine tägliche Reise nach Frankfurt/Oder zum Preis von der Reise nach Frankfurt am Main ermöglichen. Natürlich hakt das Beispiel hier etwas, aber ich denke das Prinzip ist klar.

Was man noch beachten sollte

Damit ist das wichtigste eigentlich schon gesagt. Doch es gibt noch einige Feinheiten, die man beachten sollte. Grundsätzlich kann man natürlich eine große Liste an Annahmen und Abgrenzungen zu einer Anforderung schreiben, doch meist lohnt das nicht. Der Kunde bekommt dann das Gefühl, dass sich der Auftragnehmer herauswinden will und bereits im Vorfeld nach Rechtfertigungen und Gründen für ein mögliches Scheitern oder für Mehraufwände sucht. Bei einer großen Ausschreibung ist das eventuell notwendig, bei normalen Angeboten meist tödlich. Wichtig ist, dass man fragt. Erst wenn die Fragen nicht beantwortet werden, sollte man mit ein bis maximal drei Abgrenzungen der Anfrage eine gewisse Richtung geben. Reichen diese für eine Anforderung nicht aus, gibt es zwei Möglichkeiten. Handelt es sich um einzelne Punkte, kann man dafür einen entsprechenden Risikopuffer hinein rechnen. Dies kann man entweder in den Kosten verstecken, oder man deklariert diese Aufwände unter einem Punkt Risiken separat und transparent. Bei transparenten Risikoaufschlägen kann der Kunde noch gegensteuern und die Anforderungen genauer spezifizieren. Bei verborgenen Aufschlägen gehen sie meist in der Gesamtmasse unter. Welchen Weg man wählt ist dabei eine Frage der eigenen Firmenkultur.

Mir persönlich ist Transparenz lieber. Warum, dass kann ich gerne mal in einem anderen Beitrag detailliert erörtern.

Mut zum Nein

Sind in einem Angebot zu viele Punkte unklar und hat man bereits bei der Erstellung des Angebotes das Gefühl, dass dieses Projekt viel Potenzial für Ärger enthält, sollte man auch bereit sein eine Ausschreibung abzusagen. In diesem Fall sollte man dem Interessenten detailliert erklären, warum man nicht bereit ist das entsprechende Angebot abzugeben. Welche Risiken man sieht und wie man diese aus dem Weg räumen würde. Dann hat der Interessent das letzte Wort. Entweder er möchte die Probleme aus dem Weg räumen, oder er nimmt die Absage an. Sollte das Projekt, so wie es ausgeschrieben wurde, dann tatsächlich scheitern, kommt der Interessent eventuell wieder auf einen zurück. Vielleicht nur um die Scherben zusammenzukehren und neu anzufangen, oder um das Projekt doch noch irgendwie zu retten. In beiden Fällen ist man dann in einer sehr starken Position und kann gut über Aufwände und Tagessätze verhandeln. Und selbst wenn das nicht passiert hat der Kunde den Eindruck, dass es sich um eine qualifizierte Absage handelt und wird einen zumindest nicht in schlechter Erinnerung behalten. Eventuell gibt es dann ja ein anderes Projekt, bei dem die Fähigkeiten besser zu den Anforderungen passen.

Projekte in der Krise III

Die Krux mit der Entwicklungsmaschine

Und wieder kommt ein neuer Stolperstein in das Projekt. Dieses mal handelt es sich gar nicht um die Projektmethodik selbst, sondern um ein viel banaleres und dennoch genauso ärgerliches Thema. Wir haben die Planung sauber durchgeführt, auch das Kick-Off war gut und jeder weiß was zu tun ist. Wir haben Qualitätsprozesse etabliert und sind nun bereit endlich den ersten Code zu schreiben! Wir gehen also zu unserem Entwicklungsteam und sagen, dass sie starten können. Und nun die Ernüchterung. Das Entwicklungsteam, dass wir ab heute voll eingeplant haben, und das ab heute auch unser Budget aufzehrt, kann nicht arbeiten! Wieso? Nun, wir haben für das Team keine Entwicklungsmaschinen.

Ja, aber! Das ist ja wohl Aufgabe des Entwicklers, dass er sein Handwerkszeug mitbringt! Schließlich habe ich ihm als Projektleiter ja auch keinen Laptop oder Tastatur besorgt! Schon, aber so einfach ist das nicht. Natürlich hat der Entwickler bereits für viele Kunden gearbeitet und natürlich hat er sich irgendwann auch mal eine Development-VM aufgesetzt. Doch die ist leider nicht das, was wir für unsere Anforderungen brauchen. Das kann dann sein, wenn wir z.B. mit einer ganz neuen Version von SharePoint arbeiten, für die es schlicht noch nichts gibt. Oder wir benötigen eine K2 oder Nintex Engine. Außerdem wurde diese Entwicklungsmaschine ja schon von 10 Projekten mit 1.000 Einzelanforderungen genutzt. Jede hat die Maschine etwas weiter kaputt konfiguriert und nun ist sie für uns einfach nicht mehr brauchbar.

Diese Problem mag einigen Projektleitern etwas weit hergeholt zu sein. Und tatsächlich tritt es auch nicht so häufig auf. Besonders in Zeiten des Client-Server-Object-Models ist es ehr selten, dass ein Projekt wirklich den ganzen Server kaputt konfiguriert. Doch auf der anderen Seite steht, dass der Schaden beträchtlich sein kann, wenn es wirklich auftritt. Spätestens bei Release-Wechsel der Host-Plattform (z.B. SharePoint) muss definitiv eine neue Maschine her. Im Idealfall haben wir tatsächlich eine Maschine pro Projekt und/oder Kunde, auf der wir den letzten Stand einfach archivieren können und wenn der Kunde eine Weiterentwicklung möchte, reaktivieren wir einfach die Maschine und arbeiten weiter. Meist ist dies aus Platzgründen Wunschdenken. Außerdem möchten die Projekte diese Konfiguration der Entwicklungs-VMs natürlich nicht zahlen. Also, was machen wir nun?

Die eleganteste Lösung bietet aus meiner Sicht die Azure Cloud an. Vor allem, wenn man selbst ein Entwickler mit MSDN-Subscription ist. Denn dann hat man auf der Azure Plattform bereits ein gewisses Cloud-Kontingent gratis dabei. Ja, schön. Aber ist das Problem dann jetzt nicht nur von meiner eigenen VM in eine Cloud-VM verschoben? Die Antwort ist nein. Denn Microsoft bietet inzwischen unzählige Images an, die verschiedenste Anforderungen abdecken. Im Rahmen dieses Artikels habe ich mir den aktuellsten Stand selbst einmal angesehen. Aktuell werden aktuell bereits Visual Studio 2017 RC und die SharePoint 2016 Trail Version als Konfigurationssetting für die eigene VM angeboten.

Ich habe der Vollständigkeit halber auch einmal getestet, wie lange die Installation der beiden Systeme dauert. Für Visual Studio hat es mich vom Einstellen der Parameter bis zur Eingabe der ersten Quellcode-Zeile etwa 30 Minuten gekostet. Das Öffnen von Visual Studio innerhalb der neuen VM hat beinahe genauso lange gedauert wie das Provisionieren der VM durch Azure. Aus meiner Sicht eine wirklich überzeugende Geschwindigkeit.

Für den SharePoint 2016 sah das Ganze ähnlich aus. 20 Minuten vom Konfigurieren bis zum Öffnen des Config Wizards. Insgesamt haben wir also innerhalb von etwa einer Stunde sowohl eine SharePoint 2016er Plattform als auch Visual Studio als Entwicklungsumgebung aufgesetzt und konnten anschließend arbeiten.

Wer übrigens eine vollständige Anleitung zum Installieren einer VM für SharePoint 2016 auf Azure benötigt, wird hier fündig: https://technet.microsoft.com/de-de/library/mt723354(v=office.16).aspx

Nachdem diese Maschinen übrigens einmal aufgesetzt wurden, kann man in den Einstellungen auch so genannte Automatisierungsskripte finden. Diese Skripte erlauben es einem exakt die gleiche Umgebung erneut aufzusetzen, indem man bspw. über PowerShell das Skript erneut ausführt. Das ist also dann interessant, wenn jemand zum Start eine blanke 2016er SharePoint VM mit Visual Studio 2015 R3 benötigt. Ein Skript absetzen und etwas warten. Dann wird in der eigenen Azure Umgebung eine neue Applikation provisioniert und kann anschließend eingesetzt werden.

Aber die Kosten! Ja, die sollte man nicht aus den Augen verlieren. Für eine virtuelle Maschine mit 8 Kernen und 14 GB RAM werden bei 160 Stunden Laufzeit (also 20 Tage * 8 Stunden) ca. 100€ fällig. Nimmt man einen separaten Domain Controller mit 2 Kernen und 4 GB RAM dazu ist man zusammen bei etwa 120€ pro Entwickler und Monat. Ein nicht unerheblicher Betrag. Doch man muss bedenken, dass einem Entwickler mit MSDN Lizenz ohnehin etwa 130 Euro Guthaben pro Monat zur Verfügung stehen. In diesem Fall würde er also nicht einen Euro echten Geldes kosten und hätte eine frische virtuelle Maschine für jedes Projekt, die auch nur dann das Guthaben belastet, wenn sie wirklich eingeschaltet ist.

Einzig die Staging-Maschinen sollten dann von einem Konto betrieben werden, dass nicht direkt den Entwicklern zugeordnet ist, um nicht die Budgetgrenzen zu sprengen. Oder man entscheidet sich dafür, dieses Geld zu investieren.

Und wenn man einen guten Sales Manager hat, dann verkauft dieser die entstehenden Kosten gleich mit. Immer mit dem Argument, dass die Entwicklungsmaschinen anschließend nicht gelöscht werden müssen und damit der letzte Entwicklungsstand sauber archiviert wird. Ein ziemlich guter Vorteil für Unternehmen im agilen Umfeld, wenn ihr mich fragt.

Mehr zum Thema?

Angebot und Schätzung I

Auch das ist immer wieder ein leidiges Thema. Wie schätzt man so, dass die Zahlen möglichst genau sind und wie kann ich sicherstellen, dass dabei nichts vergessen wird?

Nun, leider gibt es dafür kein Patentrezept. Viele Faktoren spielen in so eine Ausschreibung mit hinein. Aus meiner Erfahrung spielen vor allem folgende Punkte eine Rolle:

In dieser Serie möchte ich mich also mit genau diesen Fragen auseinandersetzen.

Weitere interessante Meinungen zu diesem Thema könnt ihr außerdem hier finden:

Wie beeinflusst der Kunden-Projektleiter die Ausschreibung?

Eine der wichtigsten Fragen ist wer das Projekt später leitensoll und wie es um die Fähigkeiten der Beteiligten steht. Und das sowohl bei dem Auftragnehmer und Auftraggeber. Gerade Projekte mit einem neuen Kunden oder mit einem bis Dato unbekannten Projektleiter sind oft extrem schwierig, da man die Fähigkeiten des anderen nicht einschätzen kann. Man schätzt also gegen eine Blackbox.

Und warum ist das ein Problem? Nun, im Idealfall hat man auf der Gegenseite einen erfahrenen Projektleiter, der bereits andere Projekte erfolgreich geführt hat und weiß, wie man eine Kundenanforderung zu einem sauber umgesetzten Stück Software transformiert. Die Faktoren, die der Kunden-Projektleiter beeinflusst sind vielfältig. Doch ich möchte versuchen, die wichtigsten einmal aufzugliedern.

  • Detailtiefe der Ausschreibung und der Anforderungsspezifikation
  • Klärung der Erwartungshaltung der einzelnen Parteien
  • Vereinbarung von Teilzielen mit Einbindung der Fachseite (z.B. Sprintabschluss)
  • Regelmäßige Abstimmungsmeetings
  • Saubere Aufstellung und Einforderung der Aufwände und Kosten
  • Koordination zwischen Projektteam und internen Abteilungen (z.B. Technik)
  • Deeskalierende Grundhaltung

Man merkt schon an diesen Punkten, was ein guter Projektleiter ausmachen kann. Je besser diese Punkte koordiniert werden, desto weniger Arbeit muss der Lieferant in diese Punkte stecken. Das kann in Form einer eigenen Projektleiter-Position sein, oder im dümmsten Fall in Form von Eskalationsmeetings. Der Faktor Projektleiter kann also leicht einen Unterschied von 15% in der Kostenrechnung ausmachen. Und das nur, wenn man auf die sichere Karte setzt und direkt einen eigenen Projektleiter ernennt. Ist das Projekt erst einmal in Schräglage und man hat keinen eigenen Projektleiter wird durch Eskalationsmeetings, Korrekturen und Beweisketten leicht ein Vielfaches dieses Prozentsatzes aufgewendet. Und zu allem Überfluss wird das dann wahrscheinlich auch kein Kunde mehr bezahlen und der eigene Ruf ist schnell angekratzt. Besonders der Rufschaden kann bei einem derartig vernetzten Geschäftsfeld wie der IT schnell zu einem echten Problem werden.

Doch warum nehmen wir dann nicht einfach grundsätzlich den Mehraufwand hin und schätzen einen eigenen Projektleiter ein? Nun, gerade bei neuen Kunden, die mit der Arbeitsweise der eigenen Firma noch nicht vertraut sind ist der Faktor Kosten entscheidend. Gehen wir von einem Projekt mit 100 PT aus, wäre der zu kalkulierende Faktor Projektleitung zwischen 10 PT und 25 PT einzuordnen. Wir sehen daran schon, dass es wirklich ein erheblicher Faktor ist.

Weniger als 10 % sollte man übrigens auf keinen Fall schätzen. Und auch die 10% gelten nur, wenn wirklich ein sehr fähiger Projektleiter auf der Gegenseite sitzt. Üblich sind tatsächlich ehr 20 %. Die Zeit ist für Abstimmungsmeetings mit dem Kunden, Statusreports, Zeitenbuchung, Teilergebnisvorstellung und ähnliches angesetzt.

Was ist nun also die Empfehlung für die Projektleiter-Frage? Das lässt sich leider nicht ganz einfach beantworten. Ist man neu bei einem Kunden ist man immer in der ungünstigen Situation, dass man den Projektleiter und seine Arbeitsweise nicht kennt. Ein guter Rat wäre es, den Projektleiter in Erfahrung zu bringen. Während es bei den Lieferanten üblich ist eine Vita zu verlangen, ist das umgekehrt leider nicht zu erwarten. Daher wäre das beste den Projektleiter um ein persönliches Gespräch zu bitten um die Stärken und Schwächen etwas auszuloten. Wenn das aus diversen Gründen nicht möglich ist, würde ich tatsächlich einen Aufwand von 20 % veranschlagen und einen eigenen Projektleiter einsetzen. Sollten in der Ausschreibung bereits Punkte auftauchen, welche die Kompetenz des Projektleiters fragwürdig machen, sollte man dies mit zusätzlichen Risiken bewerten. Diese Punkte könnten beispielsweise sein, dass kein fester Zeitplan aus der Ausschreibung ersichtlich ist, oder der Kunde insgesamt in seinem Kommunikationsverhalten unzuverlässig oder unschlüssig wirkt. In diesem Fall sollte man durchaus noch einmal 5% aufschlagen. Ist der Kunde hingegen bereit zu einem Gespräch und macht der Projektleiter auf den ersten Eindruck einen Kompetenten Eindruck, würde ich den Aufwand um 5% reduzieren und lediglich 15 % veranschlagen. Weiter sollte man diese Aufwände tatsächlich nur reduzieren, wenn man bereits erste Projekterfahrung mit dem Kunden-Projektleiter sammeln konnte.

Der Projektleiter des Lieferanten

Soweit so gut. Und was ist mit dem eigenen Projektleiter? Ich habe in dem Abschnitt vorher eine recht hohe Messlatte für eine Projektleitung des Kunden angelegt. Natürlich muss ich dann als Lieferant auch in der Lage sein diese Ansprüche selbst zu erfüllen. Nichts wirkt verheerender als einem Kunden Aufschläge für Projektleitung aufzuhalsen und dann genau in diesen Punkten selbst zu scheitern. Der eigene Projektleiter hat leider weniger Einfluss auf das Projekt als ein Projektleiter auf Kundenseite. Beispielsweise hat er in der Regel keinen direkten Draht zu der Fachseite oder den internen Abteilungen wie beispielsweise Technik. Das bedeutet für ihn, dass er alles über seinen Ansprechpartner beim Kunden organisieren muss und dort im Notfall auch regelmäßig nachfragen und Termine setzen muss. Und das alles auf eine Weise, die sympathisch und nicht bedrängend wirkt. Eine echte Mammutaufgabe also. Und mit der Größe des Projektes steigt natürlich auch die Komplexität der Aufgabe.

Was ist also zu beachten, wenn ich den Projektleiter aus meinen eigenen Reihen bestellen will? Es sollte jemand sein, der das Ganze nicht zum ersten Mal macht und sich bereits als Projektleiter bewährt hat. Vielleicht sogar bereits einen guten Ruf in der gleichen Branche hat und sich entsprechend auch mit der Fachproblematik auskennt. Natürlich ist das immer so eine Sache. Jeder verlangt erfahrene Projektleiter. Doch wie wird man das? Indem man als Anfänger beginnt. Logisch. Allerdings sollte diese Anfangserfahrung nicht darin bestehen, dass man Projektleiter einen Projektes wird, bei dem man auch die Kundenseite steuert. Ein Anfänger sollte mit einer Teilprojektleitung beginnen, bei der er nur seine Seite oder nur einen bestimmten Aufgabenbereich verantwortet.

Und was ist, wenn ich so jemanden nicht in meinen Reihen habe? In diesem Fall kann ich nur dingend empfehlen sich an einen externen Projektleiter zu wenden, der in dieser Materie und Branche bereits ausreichend Erfahrung sammeln konnte. Vielleicht kann ja auch der Kunde den entsprechenden Kontakt beisteuern. Ansonsten gibt es dafür Personalagenturen, die gute Freelancer vermitteln können. In diesem Fall sollte man auch einen internen Mitarbeiter als Projektassistenz an die Seite des Externen stellen, der das Projekt beobachtet und sich die Fähigkeiten des Projektleiters abschauen und aneignen kann. Dieser kann dann in einem kleineren Projekt seine neuen Fähigkeiten als Junior-Projektleiter unter Beweis stellen.

Projekte in der Krise II

Über Testmanagement und Qualitätsansprüche

Nachdem ich im ersten Teil dieser Serie davon geschrieben habe, wie wichtig gute Projektinitialisierung ist kommen wir im zweiten Teil auf einen Dauerbrenner. Das Testmanagement. Ich möchte diesen Teil relativ früh in der Serie bringen, obwohl die Entscheidung dafür bei den Tests zu sparen oft sehr spät fällt. Wieso? Weil es einer der häufigsten Missstände ist und oft sowohl von den Lieferanten als auch den Kunden als der Punkt angesehen wird, bei dem man schnell mal 20 % Budget einsparen kann. Ein Trugschluss, wie sich oft zeigt.

Aber von Anfang. Das Projekt ist gestartet, die Voraussetzungen gut. Zwar sind die Anforderungen etwas nebulös, aber wir haben im Vertrag einen guten Grundstock gelegt. Konzeption, Realisierung, Test und Abnahme. Alle Phasen vorhanden und als Milestones definiert. Das Zeitfester ist gerade ausreichend. Die Mitarbeiter sind für Ihre Jobs qualifiziert und haben sich auf Ihre Aufgaben committed. Die Konzeption findet direkt mit dem Kunden statt und erstmals definiert der Kunde wirklich, was er sich unter den einzelnen Punkten vorstellt. Der Nebel verschwindet und Klarheit kehrt ein. Langsam wird klar, dass das Projekt an der ein oder anderen Stelle deutlich komplexer ist als angenommen. Zum Teil verstecken sich die entsprechenden Anmerkungen in Nebensätzen der Ausschreibung, zum Teil wurde einfach vergessen die entsprechenden Bereiche abzugrenzen. Der Kunde weigert sich mehr Budget bereitzustellen, da diese Anforderungen aus seiner Sicht Kern-Bestandteil der Anwendung sind. Was nun? Der Projektleiter möchte den Kunden nicht verärgern und dieser hat Jahresziele auf dieser Applikation und möchte bei seinem Vorstand nicht schlecht dastehen, indem er mehr Budget aushandelt. Man geht also gemeinsam durch das Konzept und identifiziert schließlich einen großen Block, der nicht wirklich etwas zum Projekt beiträgt. Das Testmanagement!

Natürlich fordert der Vorstand einen entsprechenden Bericht von dem Projekt. Schließlich ist das ja eine wichtige Vorgabe aus dem V-Modell! Da das Projekt natürlich agil läuft hat sich der Vorstand letzten Ends darauf eingelassen, dass ein einzelner Testbericht erstellt wird. Aber der muss dann umfänglich sein.

Die Projektsteuerung aus Kunde und Lieferant kommt auf eine einfache Lösung. Das Testmanagement in der geplanten, strukturierten Form mit Unit-Tests, Testfällen und eigenem Integrationstest wird gestrichen. Stattdessen sollen die Entwickler ihren Code testen und die Ergebnisse in einem Excel zusammenfassen. Am Ende wird so ein Testbericht entstehen, der alle Bereiche umfasst und somit klar den Anforderungen des Vorstandes entspricht. Ursprünglich waren 20% für Testmanagement eingeplant. Nun konnte es auf 5% reduziert werden. Die Ersparnisse werden ausreichen um das Projekt umzusetzen und sogar noch etwas Puffer überlassen um ein paar Bugs mehr zu beheben, die diesem Vorgehen geschuldet sind.

Das Projekt läuft gut an. Die Kollegen sind zufrieden die lästigen Tests los zu sein und arbeiten schnell und effektiv die Aufgaben ab. Als weiteren Einsparungseffekt hat man auf Sprintplanung und -abschluss verzichtet. Gelegentlich zeigt man dem Projektleiter und dem Kunden einen zwischenstand und diese wirken auch soweit zufrieden. Ab und zu treten Bugs während dieser Vorführung auf. Diese werden jedoch immer bis zur nächsten Vorstellung beseitigt.

Schließlich erreicht das Projekt einen Stand, in dem die ersten Testbenutzer des Kunden auf das System kommen. Und schnell stellt sich die Ernüchterung ein. Zwar funktionieren alle Module so, wie sie vom Entwickler entwickelt wurden, doch einige gingen einfach komplett an der Anforderung vorbei. Andere erfüllen zwar ihre Aufgabe, doch bei der ersten Fehleingabe entstehen völlig unnütze Daten oder das System katapultiert sich in einen undefinierten Zustand. Auch fachliche Defizite werden schnell wieder offenkundig, da der Projektleiter des Kunden zwar weiß worum es in der Anwendung ging, er selbst jedoch nicht aus der Fachabteilung kommt, sondern Teil der IT ist. Schnell werden Fragen laut. Warum wurde die Fachseite in die Erstellung der Tests nicht involviert? Wie wurde denn dies oder jenes überhaupt getestet? Natürlich wurde das neue Testvorgehen nicht schriftlich fixiert, da es ja unter dem Radar laufen sollte und nun passiert das, was zu erwarten war. Der Projektverantwortliche auf Kundenseite zieht seinen Kopf aus der Schlinge und beruft sich auf das Angebot. Dort steht ja ganz klar etwas von der Erstellung von Testfällen für die einzelnen Testschritte der Testphase.

Das Ganze eskaliert. Der Projektverantwortliche des Kunden wird abgezogen und ein Projektteam übernimmt die Fertigstellung. Es stellt sich heraus, dass das Projekt einige schwerwiegende Punkte falsch oder unzureichend implementiert hat. Die Fehlerrate ist überdurchschnittlich hoch und Testergebnisse sind nicht nachvollziehbar. Der Lieferant bangt um Folgeaufträge, da es sich um einen wichtigen Kunden handelt und verspricht die Missstände zu beseitigen. Es wird sich darauf verständigt die fehlenden Tests nicht mehr nachzuholen und die Bugs im Eskalationsmodus zu beheben. Ein Testteam des Kunden wird aus der Fachabteilung zusammengestellt und die Fehler gefunden und behoben. Das Budget war bereits vorher stark strapaziert und für Bugfixing bleiben lediglich 5 % über, die nun deutlich überschritten werden. Insgesamt belaufen sich die Mehraufwände auf weitere 15 % und das Projekt hat damit die Grenze der Wirtschaftlichkeit erreicht. Beide Parteien bringen das Projekt zu Ende. Die fertiggestellte Applikation ist lauffähig. Leider nicht so performant wie erhofft, denn dafür hat unter dem Strich die Zeit gefehlt. Änderungen sind teuer, da man sich immer durch den Code der Eskalationsphase quälen muss, welcher natürlich mit der heißen Nadel gestricht wurde. Durch das fehlen von Unit-Tests sind auch nachfolgende Änderungen nicht ohne Risiko und Fehler schleichen sich immer wieder ein, die auch die Wirtschaftlichkeit der Änderungen immer wieder gefährdet. Unter dem Strich kann dieses Projekt zwar als Erfolg, jedoch nicht als Glanztat gewertet werden und jeder Entwickler stöhnt leise auf, wenn wieder eine Änderung daran stattfinden soll oder ein Bug aus alter Zeit doch noch aufgrund von Gewährleistungsansprüchen gelöst werden muss.

Hätte all das verhindert werden können? Meiner Meinung nach ja. Und auch wenn in diesem Beispiel mehr Faktoren als nur das Testmanagement eine Rolle gespielt haben, ist es doch dieser Punkt auf den ich mich konzentrieren möchte. Weitere Faktoren waren sicherlich bereits im Angebot mit fehlenden Abgrenzungen und unzureichenden Fachkenntnissen, oder auch das knappe Budget der Kundenseite. Beides lässt sich nicht so einfach abstellen aber ich werde diese Themen in einem späteren Beitrag sicherlich noch einmal ausführlich behandeln.

Warum sollten wir Testmanagement betreiben? Ich denke, es wurde deutlich. Testmanagement umfasst viele verschiedene Aspekte mit dem gleichen Ziel. Die Anforderungen des Kunden möglichst scharf zu zeichnen, diese durch den Kunden abnehmen zu lassen und anschließend genau gegen diese Anforderungen zu entwickeln und das Ergebnis anhand dieser Anforderungen zu verifizieren. Wie kann das funktionieren? Nun, als erstes haben wir einen Wunsch von einem Kunden. Im Agilen Prozess nennen wir das einmal Feature. Jedes Feature besteht aus einer Anzahl an Anforderungen oder Use-Cases oder User-Stories, welche alle umgesetzt werden müssen, damit der Kunde das Feature benutzten kann. Beispielsweise könnte das Feature eine Kontaktverwaltung sein. Die einzelnen Use-Cases sind dann Anlegen, Löschen, Bearbeiten, Anzeigen, Exportieren etc. Jeder Use-Case hat dann noch Vorgaben. So genannte Abnahmekriterien. Abnahmekriterien für die Anlage können Pflichtfelder, Validierungen, Designvorgaben oder Ansprechzeiten sein.

481cd1a2-bf0c-4c03-a9e8-87d81bf15e91tests%20pro%20artefakt

Und genau dieser Struktur stellen wir nun unsere Tests gegenüber. Beispielsweise werden für die Akzeptanzkriterien entsprechende Unit-Tests erstellt. Für die Anlage der Pflichtfelder prüfen wir wie sich das Feld verhält, wenn es ausgefüllt wurde, wenn es nicht ausgefüllt wurde und wenn in ein Zahlenfeld Text eingetragen wird. Entsprechen alle Testergebnisse unseren Erwartungen, können wir davon ausgehen, dass das Akzeptanzkriterium damit erfüllt ist.

Nun schreiben wir noch einen Oberflächen-Test für den Endnutzer. Dort sollten wir die Akzeptanzkriterien berücksichtigen. Also etwa lege einen Eintrag an. Prüfe dabei ob die Pflichtfelder richtig dargestellt werden. Prüfe ob die Validierungen greifen, prüfe ob die Designvorgaben stimmen. Prüfe ob die Reaktionszeit im gewünschten Bereich liegt. All das kann in einem oder in mehreren Testfällen geschrieben werden. Da dieses Beispiel tatsächlich alles die Anlage behandelt würde ich alles zusammen in einen Test schreiben. Würde es Anlegen und Löschen behandeln wären es 2, usw.

Als letztes machen wir unseren Integrationstest und prüfen damit, ob unser neu erstelltes Feature auch zu den restlichen Komponenten passt. Das kann bspw. dann interessant werden, wenn der Kontakt als Referenz zu einem Kunden dient oder für Veranstaltungen. Wir führen also alle Tests unserer Use Cases nun gemeinsam auf der Integrationsumgebung aus.

All diese Arbeit erfüllt 4 Ziele. Erstens, durch die Untergliederung der Features bis hinunter zu Akzeptanzkriterien haben wir eine Anforderungsebene erreicht, auf der sich auch der Entwickler wohl fühlt und genau weiß was er machen muss, damit das Feature umgesetzt werden kann.

Zweitens, der Kunde versteht bei dieser Untergliederung den Zusammenhang zwischen seinem Feature und den Akzeptanzkriterien des Entwicklers und kann anhand dieser Abstufung verstehen was er da genau vor sich stehen hat und auch was er von der fertigen Anwendung erwarten kann.

Drittens, durch dieses Verständnis kann der Kunde die Akzeptanzkriterien freigeben, bevor die eigentliche Entwicklung startet. Damit haben wir die Sicherheit, dass wir die Anforderung richtig verstanden haben und wir haben eine konkrete Liste bei der wir sagen „Lieber Kunde, das waren die konkreten Anforderungen, die wir umgesetzt haben. Nichts links, nichts rechts davon. Wenn jetzt etwas fehlt ist das ein Change.“ Das gibt uns Planungssicherheit.

Und schließlich viertens, durch die Erstellung, Ausführung und Protokollierung der Tests erhalten wir die Sicherheit, dass die Anwendung tut was sie soll und der Kunde erhält die Sicherheit, dass wir auch alle Akzeptanzkriterien und damit schlussendlich das Feature vollständig umgesetzt haben.

Und somit erreichen wir unser eigentliches Ziel. Wir setzen genau das um, was der Kunde fordert und zwar so, wie es besprochen war. Die Missverständlichen Features wurden in einfach verständliche Akzeptanzkriterien heruntergebrochen. Natürlich macht das alles Mehraufwände. Doch wir sparen am Ende die Zeit bei der Fehlerbehebung und der Nacharbeit wegen falschen oder fehlenden Schritten wieder ein. Leider ist Testmanagement immer eine Gefühlssache, da man natürlich nicht messen kann, wie viel Zeit man dadurch gespart oder mehr verbraucht hat. Währen die guten Ergebnisse mit Testmanagement auch ohne erreichbar gewesen? Ich sage, vielleicht. Aber nur dann, wenn es sich um einen stark standardisierten Prozess handelt und jeder beteiligte über großes Fachwissen verfügt. Für einen Dienstleister im Projektgeschäft halte ich es für nicht realistisch und dementsprechend das Testmanagement für unabdingbar.

Mehr zum Thema?

Projektabschluss

Der Projektabschluss ist wohl die Projektphase, die am häufigsten ignoriert, oder nur halbherzig durchgeführt wird. Die Projektmitglieder sind in der Regel bereits für neue Themen eingespannt. Der Projektleiter ist froh, dass alles in Time und in Budget funktioniert hat, oder er möchte das Projekt lieber schnell vergessen, da es total schief gelaufen ist und das Projekt ein Fehlschlag war.

Dazu kommt noch, dass ein sauberer Projektabschluss in der Regel nicht durch den Kunden bezahlt wird, der das Projekt in Auftrag gegeben hat. Auch seine Leute sind bereits wieder neu eingespannt und er hat nur wenig Interesse daran, die Strukturen des Auftragnehmers zu stärken und zu verbessern.

Warum also sollte man dennoch auf einem Projektabschluss bestehen? Und was umfasst dieser Abschluss eigentlich alles? Genau darum soll es im folgenden gehen.

Was sind die Pflichtaufgaben beim Projektabschluss?

Damit wir überhaupt vom gleichen reden können, möchte ich hier die aus meiner Sicht wichtigsten Faktoren eines Projektabschlusses benennen. Natürlich müssten wir dafür erst einmal definieren, wo der Projektabschluss beginnt. Das Ganze ist ein fließender Prozess. Es gibt optionale und nicht optionale Bestandteile. Ich würde gerne an dem Punkt beginnen, an dem das erstellte Stück Software den Go-Live absolviert hat. Hier kann man guten Gewissens vom Ende des Projektes reden. Eventuell gibt es noch einen Wartungsvertrag für das Produkt, doch dies ist dann nicht länger Teil eines Projektes, sondern ein neuer Abschnitt des Produktes.

Nun sollten beide Seiten, Auftraggeber und Auftragnehmer, noch einmal überprüfen ob auch alle Abnahmegegenstände geliefert wurden.

  • Gibt es alle verlangten Dokumentationen?
  • Sind die Testfälle alle sauber abgeschlossen?
  • Liegt der Testbericht beiden Seiten vor?
  • Gab es eine Quellcode-Überlassung, die nun noch durchgeführt werden muss?
  • Oder wurde der Code beim Kunden entwickelt und muss nun noch in die eigenen Systeme zurück gespiegelt werden?
  • Sind alle Aufwände im Buchungssystem erfasst?
  • Wurden diese auch in Rechnung gestellt?

All diese Fragen sind nicht optional und sollten definitiv bei jedem Projektabschluss gestellt werden. Nur so sind tatsächlich auch alle Bedingungen für eine saubere Projektübergabe sichergestellt.

Wie kann man seine Erfahrungen für die Unternehmen nutzbar machen?

Über diese Pflichtaufgaben gibt es noch die Kür. Der Prozess, der für beide Seiten einen Mehrwert in der Methodik schaffen kann. Es gibt de Facto kein Projekt, dass absolut glatt läuft. Immer gibt es kleinere und größere Fehler, Missverständnisse und Kompromisse. Diese Erfahrungswerte befinden sich nun in den Köpfen der Projektmitarbeiter auf beiden Seiten. Sie sind noch frisch und man hat genau in Erinnerung was man auf keinen Fall wieder tun würde, oder wo es zumindest Verbesserungsbedarf gibt. Die Dinge, die man nie wieder tun würde, vergisst man natürlich nicht. Aber was ist mit den Kleinigkeiten, über die man vielleicht sogar schon mehrfach gestolpert ist, dann aber wieder vergessen hat? Und wie können die Kollegen im Unternehmen auf beiden Seiten von diesen Erfahrungen profitieren? Genau darum geht es bei der zweiten Phase des Projektabschlusses. Folgende Punkte sollte man dabei berücksichtigen und einsetzen, wenn diese sinnvoll erscheinen.

  • Eine offene Projekt-Retropektive, bei der Kunde, das Projektteam und der Kundenvertreter (Sales) gemeinsam darüber reden, was in dem Projekt gut und was nicht so gut gemacht wurde.
  • Blick nach vorne. Wie fügt sich das Projekt in die Landschaft des Kunden ein. Es gibt eventuell weitere Punkte, an denen der Kunde noch Bedarf sieht.
  • Daraus folgend ein Lessons Learned, bei dem die wichtigsten Erkenntnisse erfasst werden. Sowohl im Positiven, als auch im Negativen.
  • Einzelgespräche mit den Projektmitarbeitern, bei dem man die konkreten Stärken und Schwächen des Einzelnen anspricht und Verbesserungspotenziale sichtbar macht (Die Protokolle können auch für die Personalentwicklung interessant sein)
  • Prüfung, ob aus dem erfolgreichen Projekt eine Case Study gemacht werden kann. Eventuell erklärt sich der Projektverantwortliche des Kunden auch dazu bereit seinen Fall und das Projekt in einem Vortrag zu erläutern.
  • Man sollte prüfen, ob Module, Dokumente oder andere Ergebnisse künftig auch für andere Projekte genutzt werden können. Das kann als Codeschnipsel sein, als Dokumentenvorlage, als Template oder ähnliches. Hier sollte man allerdings auch prüfen, ob der Aufwand den Nutzen rechtfertigt.

All diese Punkte bieten für das abgeschlossene Projekt keinen Mehrwert mehr. Doch für die Organisation als Ganzes und auch die Bindung zum Kunden können diese sehr nützlich sein. Denn dies ist noch einmal die Gelegenheit dem Kunden zu zeigen, dass man sein Projekthandwerk versteht und wirklich daran interessiert ist die aufgetretenen Fehler nicht erneut zu begehen. Im Idealfall ergibt sich aus dem Gespräch mit dem Kunden und dem Blick nach vorne auch die Möglichkeit neue Felder zu erschließen und eventuell lassen sich daraus – und mit dem guten Gefühl, dass der Kunde durch so ein Gespräch erhält – neue Projekte, die man im Idealfall sogar mit dem bereits eingespielten Projektteam bestreiten kann um somit möglichst viele Synergien nutzen zu können.

Selbst wenn dies nicht der Fall ist, eine ausführliche Nachbereitung des Projektes dauert meist nur sehr kurz, vor allem wenn die agilen Mechanismen und Scrum sauber genutzt wurden und dadurch ohnehin bereits regelmäßig Verbesserungen erfolgt sind. Der Nutzen diese Verbesserungen nun festzuhalten dient allen in der Firma und sollte möglichst weitgehend genutzt werden um ein Verständnis dafür zu schaffen und die Leute zu sensibilisieren.

Ein Sprichwort sagt, dass die Erfahrung die Summe der Fehler ist, die ein Mensch gemacht hat. Wenn diese Erfahrung nun dazu genutzt wird auch bei anderen Kollegen ein Wissen aufzubauen, ohne die Fehler machen zu müssen, dann ist dies ein Prozess der positiven Verstärkung und der eigentliche Vorteil, den eine starke projektorientierte Firma gegenüber einem Freelancer auszeichnen kann.

Mehr zum Thema?

​ Projekte in der Krise I ​

Warum Projektplanung wichtig ist.

Das Projektgeschäft ist bekanntermaßen ziemlich tückisch. Oft gibt es Probleme, die man erst im Nachhinein erkennt und selten nimmt sich jemand die Zeit die Probleme aus der Vergangenheit wirklich zu reflektieren und auszuwerten. Das führt dazu, dass einige Projektleiter mit großer Erfahrung ein Projekt zum Erfolg führen können. Hauptsächlich dann, wenn genügend Probleme der aus vorhergehenden Projekten bereits bekannt sind und man weiß wie man damit umgeht. Kommen zu viele unbekannte Probleme oder ist der Projektleiter nicht erfahren in dieser Materie, wird irgendwann der kritische Punkt überschritten, bei dem das Projektteam die Fehler nicht mehr ausgleichen oder korrigieren kann. In diesem Fall wird das Projekt dann ein Desaster.

Viele Firmen, die ich kennen gelernt habe sind der Meinung, dass sie mit Projekten umgehen können. Eben weil sie ausreichend Projekte absolviert haben, bei denen das Ergebnis letzten Ends den Erwartungen des Kunden entsprochen hat – oder zumindest die Mindestanforderungen erfüllt hat. Am Ende zählt nur noch das Ergebnis und der Weg dorthin verschwindet oft im Gedächtnis des Einzelnen. Selten wird das Projekt noch einmal reflektiert oder gar Erkenntnisse schriftlich festgehalten.

Aus diesem Grund möchte ich in dieser Beitragsserie mal über meine persönlichen Erfahrungen der größten Projektfehler berichten und mögliche Gegenmaßnahmen zeigen. Leider sind das alles keine magischen Werkzeuge, die alles einfach machen, sondern nur Strukturen und Prozesse, die Initial erst einmal wieder Mehraufwände verursachen, bevor sie ihre Magie wirken können. Ein gewisses Maß an Vertrauen und auch Durchsetzungsvermögen gegenüber den Projektbeteiligten ist also durchaus notwendig.

Keine ausreichende Planung zu Beginn eines Projektes

Tatsächlich ist die mangelnde Planung am Anfang oft schon der Grundstein für das Fiasko. Dabei waren die Absichten gut. Der Kunde hat Zeitdruck, es geht nur um einen sehr überschaubaren Projektrahmen oder der Entwickler hat ohnehin schon signalisiert, dass er genau weiß was zu tun ist oder man möchte man Zeit aufholen. Es gibt diverse Gründe dafür den Projektstart ad hoc durchzuführen und einfach mal loszulegen. Oft ist die Ursache auch nicht bei einem einzelnen Grund zu suchen, sondern ergibt sich aus einer Summe verschiedener Teile.

Und dann passiert es. Zum Beispiel hat sich der entscheidende Entwickler krank gemeldet. Der Zeitplan ist aufgrund von Fehlern im Projekt nun unhaltbar geworden und es ist viel zu spät aufgefallen um noch Gegenmaßnahmen zu ergreifen. Der überschaubare Projektrahmen wurde durch diverse kleinere Änderungen aufgebläht, ohne das es aufgefallen ist. Die Architektur hat sich durch diese kleineren Änderungen nun doch entscheidend geändert.

Das Ergebnis ist oftmals verheerend. Der mangelnde Pflegeaufwand am Anfang zieht sich dann meistens wie ein roter Faden durch das Projekt. Änderungswünsche werden nicht dokumentiert, Probleme nicht an den Kunden kommuniziert und der Druck auf die Projektmitarbeiter wird immer größer. Da nicht klar ist, welche Anforderung wann und wie rein kam, wird einfach gemacht was der Kunde sagt. Man weiß nicht mehr, wie genau er seine Anfrage gestellt hat und irgendwann ist das Geld alle und das Produkt noch nicht fertig. Beide Parteien streiten sich um das Produkt und am Ende wird das Projekt entweder eingestampft oder unter enormen Kosten zu Ende geführt. Niemand ist glücklich und voraussichtlich war es das letzte Projekt in dieser Konstellation.

So könnte zumindest der Extremfall aussehen. Normalerweise ist es so, dass die Mitarbeiter des Zulieferers mit Überstunden, Vermutungen und einer gewissen Bugtoleranz doch noch das Ziel erreichen. Der Kunde ist zwar nicht glücklich, doch die Fehler werden mit dem nächsten und übernächsten Release gefixt und das Projekt unter „Erfahrung“ verbucht. Leider wieder ohne Retrospektive.

Dieses Beispiel zeigt wie leicht aus gutem Willen am Anfang und der Idee die eigene Agilität zu demonstrieren ein Desaster werden kann. Doch was hilf dagegen? Natürlich, Struktur. Sonst hätte ich den Beitrag ja nicht so eingeleitet. Aus meiner Sicht gibt es einige Grundsätzliche Dinge, die beim Projektstart auf jeden Fall erledigt werden müssen. In welcher Ausbaustufe das ganze Stattfindet, hängt dabei vom jeweiligen Projektumfang ab und einige Sachen können auch zunächst grob Skizziert und später ausdefiniert werden. Aber zumindest die Grundstrukturen sollten da sein.

Ein Projektplan auf Basis der Schätzung

Für das Projekt wurde initial irgendetwas geschätzt. Sonst hätte man den Auftrag ja nicht bekommen. Das sind die Zahlen, die für einen ersten Projektplan als Grundgerüst dienen. Welche Pakete wurden vereinbart, welche Zahlen stehen in PT für welche Rolle daran. Gibt es Abgabetermine und wer kann die Rollen besetzen. Je detaillierter dieser Projektplan definiert werden kann, umso besser sind die Ergebnisse später messbar. Doch es reicht am Anfang auch ein grobes Gerüst als Richtschnur. So sehen wir zumindest, wenn etwas völlig aus dem Ruder läuft und wir gegensteuern oder den Kunden informieren müssen.

Personalplanung auf Basis des Projektplans

Damit die richtigen Leute für mein Projekt zur Verfügung stehen muss ich diese auch einplanen. Je früher und weitreichender ich diese Planung durchführen kann, desto höher ist die Chance, dass meine Leute auch verfügbar sind. Damit ich nicht rate, wann ich welche Leute benötige, sollte der Projekt- und Meilensteinplan vorher zumindest in einem ersten Stand sein. Somit weiß ich, dass ich nach Meilenstein M1 die Person XY benötige, da sie eine Kernkompetenz für die Erbringung von M2 hat. Natürlich kann ich noch nicht auf den Tag genau sagen welche Personen ich von Anfang bis Ende benötige. Aber über den Projektplan bekomme ich eine Vorstellung und kann die Leute in dem betreffenden Zeitraum zumindest schon einmal vorplanen. Mit jedem Statusmeeting und jedem erfolgreichen Modul, dass abgeschlossen wurde, kann ich den Projektplan nachschärfen und auch die Personalplanung optimieren. Somit wird nicht nur für mich, sondern auch meine Leute der eigentliche Termin immer greifbarer und andere Projekte können sich nach dieser Planung immer besser richten.

Klärung der Abnahmekriterien der ersten Meilensteine / Sprints etc.

Bis zum nächsten Meilenstein, besonders am Anfang, gibt es oft sehr viel zu tun. Auch Dinge, die eigentlich nichts mit meiner Zielerreichung zu tun haben, sondern bereits vorgeplant werden für spätere Schritte. Damit man das eigentliche Ziel des aktuellen Meilensteins nicht aus den Augen verliert und sich in Details verstrickt, sollte für jeden Meilenstein klare Abnahmekriterien definiert sein. Was muss erreicht werden, damit der Kunde glücklich ist? In Scrum würden diese Aspekte einen möglichst hohen Wert in Story Points bekommen und somit zeitnah erledigt werden. Während die Arbeiten für später oder die weniger relevanten Nebentätigkeiten entsprechend herunter priorisiert werden. Dies hilft jedem einen klaren Blick auf das Ziel zu behalten und dem Projektleiter die Erreichbarkeit des Ziels und den aktuellen Status leichter zu messen.

Definition und Beschaffung der benötigten Arbeitsmaterialien

Es hört sich total trivial an, doch oftmals ist genau hier der Knackpunkt von vielen Projekten. Spätestens beim Projekt-Kick-Off muss klar sein, welche Arbeitsmaterialien benötigt werden, wer diese beschafft und wann die Arbeitsfähigkeit hergestellt ist. Erst dann – und wirklich erst dann – lohnt es sich mit einem Team in das Projekt einzusteigen. Bis zu diesem Zeitpunkt sollten lediglich die Experten für die Arbeitsmaterialien arbeiten und alle anderen Personen in anderen Aufgaben aktiv sein. Zu diesen Arbeitsmaterialien gehören in unserer Welt VSTS (TFS)-Projekt, Entwicklungsmaschinen, Zugriffe auf Kundensysteme, vollständige Anforderungen (zumindest für die ersten 2 Sprints), Ansprechpartner, Architekturkonzepte, Testkonzepte und ähnliches. So lange diese Bausteine nicht verfügbar sind und problemlos ihre Aufgabe erfüllen ist jede Art von operativer Hektik kontraproduktiv und wird letzten Ends die Qualität des Projektes untergraben und einem später wieder auf die Füße fallen.

Klärung der Aufgabenbereiche und Rollen

Auch das klingt einfach. Ein Entwickler soll natürlich den Code schreiben! Dafür haben ihr ihn ja dazu genommen! Ja, schon. Aber was denn noch? Ist er für das Aufsetzen der Entwicklungsmaschine zuständig? Ist der Architekt für Kundenkommunikation zuständig? Ist der Qualitätsmanager für die Erstellung der Testfälle zuständig? Für jeden Mitarbeiter sollte es ein gezieltes Onboarding in das Projekt geben. Wenn dies nicht möglich ist, sollte das Onboarding zumindest zentral in einem Projekt-Kick-Off stattfinden. Am Ende muss sich der Mitarbeiter genau auf diese Rollenbeschreibungen verlassen können und sich auch direkt darauf committen. Denn nur so ist sichergestellt, dass er eine implizite Andeutung nicht überhört hat. Gerade bei den oben genannten Beispielen ist dies nicht zwangsläufig so und der Kollege fühlt sich vielleicht gar nicht zuständig, obwohl der Projektleiter es eigentlich genau so gemeint hat. Deshalb lieber einmal zu viel sagen, was der Kollege machen soll und ihn das auch noch einmal in eigenen Worten wiederholen lassen, damit alle auf den selben Stand sind. Besonders bei langen Projekten bietet sich außerdem an, diese Aufgaben noch einmal schriftlich zu fixieren, damit sie nicht in Vergessenheit geraten. In Scrum könnte man diese dann zum Teil der Retrospektive machen. Waren wirklich alle Teammitglieder in Ihrer Rolle aktiv? Sind sie gut damit klar gekommen, oder bestehen irgendwo Lücken, die es zu schließen gilt?

Mehr zum Thema?

Komponenten-, Integrations-, System- und Abnahmetests

Ein kleiner Exkurs. Diesmal zu Testverfahren. Ich war gerade im Gespräch mit einem Kollegen über verschiedene Testverfahren. Dabei kam die Frage auf, wie man verschiedene Testfälle angehen kann. Hier nun also das Resultat.

Komponententest

Klassische Unit-Tests. Im Minimalmodell müssen hier vor allem die Schnittstellen zwischen den Systemen abgetestet werden. Die meisten Qualitätsverfahren gehen davon aus, dass die meisten Fehler genau an den Schnittstellen passieren, da der Entwickler sein eigenes Modul gut kennt und die Fehler ehr durch unerwartete Parameter entstehen können.

Im Fall von O365 ist JavaScript wahrscheinlich die häufigste Oberfläche. Daher würde ich die Unit-Tests auch auf dieser Ebene ansiedeln und jede Kommunikation zwischen der Oberfläche und dem Backend abtesten. So wissen wir, welche Funktionen wir aufrufen und bei welchen Parametern wir welche Ergebnisse erwarten. Genau diese würde ich hier testen. So kann man bei jedem Aufruf einmal den Positivfall und die eingebauten Fehlerfälle abtesten.

Ein Beispiel:
GetYearOfDate(„2007-12-12“) assert „2007“
GetYearOfDate(„2. Feb. 2017“) assert „2017“
GetYearOfDate(„30.02.2002“) assert InvalidDateException

Integrationstest

Integrationstests sind Testfälle die zu Testszenarien verbunden sind. Ich habe das zum Beispiel immer gemacht, indem ich mir eine UserStory/UseCase/Requirement des Kunden geschnappt habe. Das war mein Testszenario. Dann habe ich für jedes von mir identifizierte Akzeptanzkriterium einen Testfall geschrieben um es abzuprüfen.

Diese würde ich üblicherweise im VSO Test Manager schreiben. Der Vorteil ist, dass wir diese Testfälle über unseren SSO-Login und den Web-Client auch bei Kunden in ihrem eigenen System nutzen können. Für ausgeführte Testfälle erhalten wir dann nämlich auch ein sehr detailliertes Testprotokoll.

Idealerweise werden Integrationstests auf einer expliziten Testumgebung (der INT-Stage) ausgeführt. Diese Testfälle sind bei mir immer durch einen Tester auf Entwicklerseite ausgeführt worden. Nicht jedoch durch den Entwickler, der das Modul geschrieben hat. Gerne aber durch einen anderen Entwickler, der daran nicht beteiligt war.

Ein Beispiel:

Anforderung:
Ein Nutzer möchte eine Übersicht aller seiner aktiven Projekte aus der Projektliste auf der Startseite.

Implizite Akzeptanztests (zur Abnahme beim Kunden):

  • Es muss möglich sein, dass auf der Startseite ein Anzeigemodul (z.B. Webpart) platziert wird, dass eine Liste von Projekten anzeigen kann
  • Die Liste auf einen speziellen Nutzer gefiltert werden
  • Projekte anderer Nutzer sollen nicht angezeigt werden
  • Es sollen nur aktive Projekte aus der Liste ermittelt werden.
  • Inaktive oder beendete Projekte sollen nicht angezeigt werden.

In diesem Fall schreiben wir ein Testszenario „Aktuelle Projektübersicht eines Nutzers“ und haben darin 5 Testfälle, die jeweils ein Akzeptanzkriterium enthalten.

Systemtest

Der Systemtest ist die Gesamtheit aller Testszenarien die hier im Zusammenspiel getestet werden. Es sollte also eine Testumgebung geben (normalerweise der QA-Stage), auf der kurz vor der Abnahme einmal alle Komponenten installiert werden. Hier testet ein Test-Team, welches wieder vom Entwicklungsteam gestellt werden kann.

Bei mir war es oft so, dass zu diesem Zeitpunkt bereits einige Key-User auf der Plattform unterwegs waren und über Exploratory Testing – also freies Testen nach Gefühl – unterstützt haben, um somit Fehler zu finden, die mehr Fachwissen benötigen.

Auch gibt es als Output ein Testprotokoll.

Abnahmetest

Dieser kann als einziger Test nicht durch den Zulieferer erfolgen. Er wird auch User Acceptance Test (UAT) genannt und lässt die späteren Nutzer – oder eine Teilmenge davon – auf die Umgebung. Im Idealfall kann dieser Test bereits auf der späteren Produktivumgebung stattfinden, damit sichergestellt ist, dass alles richtig eingerichtet wurde. Sollte dies nicht möglich sein, findet der Test auf der QA-Umgebung statt, welche per Definition identisch mit der Produktivumgebung ist.

Zusammenfassung

Komponententest dienen der Abprüfung der Applikationsschnittstellen über Unit-Tests um die Konsistenz der Applikation zu gewährleisten. Liefergegenstand ist das Protokoll der Unit-Tests.

Die Integrationstests entsprechen dem Schreiben von Testszenarien anhand der Requirements und von Testfällen anhand abgenommener Akzeptanzkriterien. Ausführung erfolgt bei Fertigstellung einzelner Module auf der Integrationsumgebung. Liefergegenstand ist das Testprotokoll der Integrationsumgebung.

Als Systemtest versteht man die Ausführung aller Testszenarien der Integrationstests. Ausführung erfolgt auf der QA-Umgebung bei Abschluss der Implementierungsphase. Liefergegenstand ist das Testprotokoll der QA-Umgebung.

Und der Abnahmetests beschreibt die Ausführung aller Testszenarien oder eigener Tests auf der QA- oder Produktivumgebung durch die Fachabteilung. Wir sind hier lediglich beratend tätig und halten Ressourcen für die Fehlerbehebung bereit.

Meetingkultur

Worauf man bei Meetings achten sollte

Während meines bisherigen Arbeitslebens habe ich verschiedenste Arten und Organisationsformen von Meetings und Schulungen erlebt. Einige empfand ich und meine Kollegen als extrem zielgerichtet und wirkungsvoll. Es wurden Dinge beschlossen und die Umsetzung sauber geplant. Die Leute gingen motiviert und mit einer Vision aus dem Raum. Bei anderen Meetings hatte ich das Gefühl das mein Hirn in Watte gepackt ist. Man hört zwar zu, doch es interessiert einen nicht. Die dritte große Kategorie waren Meetings, bei denen wohl selbst der Veranstalter nicht wusste, worum es eigentlich ging und bei denen es schnell in ein unorganisiertes Durcheinander ausgeartet ist.

Doch woher kommen diese Unterschiede? Gibt es Regeln, die man beachten sollte? Und bringen diese Wirklich einen Mehrwert? In diesem Beitrag soll es genau darum gehen. Was muss bei einem Meeting beachtet werden.

Vor dem Meeting

Die Vorbereitung eines Meetings ist ebenso wichtig wie das Meeting selbst. Man sollte sich bewusst machen, dass man bei einem Meeting eine große Anzahl (3 oder mehr) von Personen in einem Raum versammelt um gemeinsam einen Sachverhalt zu klären oder eine Entscheidung herbeizuführen. Hierbei sollte einem immer klar sein, dass hierfür enorme Mengen an Arbeitszeit aufgewendet werden. Bei einem Meeting über 2 Stunden und mit 4 Personen ist bereits ein ganzer Arbeitstag aufgewendet. Umso wichtiger ist es, dass der Veranstalter möglichst viele Informationen bereits im Vorfeld bereitstellt und seine Anfragen und Klärungsabsichten möglichst klar formuliert. Hierfür eignet sich am besten direkt die Einladung, die beispielsweise über Outlook versendet wird.

Das Wichtigste ist dabei direkt der Titel, mit dem diese Einladung versendet wird. Steht dort prägnant um was es in diesem Meeting gehen soll? Wenn es nicht möglich ist den Zweck dieses Meetings in einem einfachen Titel zu umschreiben, sollte man noch einmal grundsätzlich über die Ausrichtung dieses Meetings nachdenken. Ist die Aufgabenstellung für das Meeting überhaupt geeignet? Sind die Fragen und Aufgaben prägnant genug um in einem solchen Meeting geklärt zu werden? Erst wenn man einen prägnanten Titel (z.B. Sprintplanungsmeeting, Klärung des Bugs XY, Mentoring für Person ABC) hat, sollte man hier fortfahren.

Ebenso wichtig ist der Empfängerkreis. Lade ich wirklich nur die Personen ein, die direkt in die Entscheidung eingebunden werden sollen? Haben die Personen also einen wichtigen Beitrag zu leisten? Wenn es nur darum geht, dass diese Personen ein oder zwei Anmerkungen machen sollen, oder an einem Teilproblem mitwirken, wäre es dann vielleicht besser, diese Personen gesondert zu einem anderen Termin einzuladen? Oder ist es dem Veranstalter möglich die Informationen bereits im Vorfeld einzuholen, sodass auf die Personen verzichtet werden kann? Es wäre ja auch möglich diese Leute einfach per Skype zu dem Meeting dazu zu holen, wenn es notwendig wird. So könnten diese den Rest des Meetings fernbleiben und während dieser Zeit etwas anderes machen.

Kommen wir zum Text der Einladung. Dieser sollte mindestens eine Agenda enthalten, in welcher die Sachverhalte erläutert werden, um die es im Meeting geht. Im Idealfall wird bereits so gut wie möglich vorgearbeitet und die Anfrage möglichst klar kommuniziert. Auch weiterführende Links zur Projektablage oder ähnlichem können hier weiterhelfen. Es sollte nach Möglichkeit alles enthalten sein, was den Beteiligten im Vorfeld hilft ein detailliertes Bild von der Situation zu bekommen. Da es sich bei den meisten Meetings um kein völlig neues Thema handelt und die Kollegen meistens schon recht genau wissen worum es gehen könnte, ist die Agenda mit einigen Details angereichert meist auch schon genug. Wichtig ist, dass klar hervor geht, welche Frage geklärt oder welcher Sachverhalt bearbeitet werden soll.

Die Uhrzeit und Dauer des Meetings sind natürlich auch wichtig. Man sollte bereits im Vorfeld die Terminkalender der Beteiligten überprüfen, damit es hier nicht zu Terminüberschneidungen kommt. Wenn möglich sorgt auch eine gewisse Vorlaufzeit dafür, dass die Kollegen sich eventuell den Termin freischaufeln können.

Während des Meetings

Okay, die Vorbereitungen sind also getroffen. Die Kollegen nehmen an dem Meeting teil und es beginnt. Was ist nun zu beachten? Als erstes sollte der Meeting-Leiter natürlich noch einmal in eigenen Worten erklären worum es in dem Meeting geht und was aus seiner Sicht die zu erzielenden Ergebnisse sind. Anschließend sollte er die Sicht der Beteiligten einholen, die eventuell noch etwas zu dieser Zielsetzung beitragen können. Wichtig ist,´dass die Veranstaltung der Diskussion und Lösungsfindung zwischen den Teilnehmern dienen soll. Es ist an dieser Stelle also meist wenig ratsam

Eventuell ist es auch so, dass nicht alle Meeting-Teilnehmer die gleiche Relevanz haben. So kann es durchaus sein, dass einige Kollegen nur für Teilbereiche der Aufgabenstellung benötigt werden. Diese Teilbereiche sollte man dann natürlich nach vorne verschieben um die Arbeitszeit der Kollegen möglichst wenig mit dem Meeting zu belasten. Ist ihre Aufgabe erledigt, können diese Kollegen dann wieder zu ihrer eigentlichen Arbeit zurückkehren.

Wichtig ist dabei, dass alle getroffenen Entscheidungen, alle Aufgaben und alle Unklarheiten, die in diesem Meeting auftreten auch protokolliert werden. Während eines Meetings ist es oft so, dass viele Aussagen getroffen und oftmals auch schnelle Entscheidungen getroffen werden. Teilweise auch unter der Annahme, dass jeder diese Aufgabe verstanden, akzeptiert und für sich irgendwie notiert oder gespeichert hat. Dabei sind jedoch nicht alle Entscheidungen für alle Mitarbeiter gleich wichtig und manche Kollegen merken sich eventuell eine Entscheidung nicht, da diese aus ihrer aktuellen Situation nichts mit ihnen zu tun hat. Erst wesentlich später wird dieser Aspekt – vielleicht aufgrund eines Rollenwechsels oder aufgrund einer falschen Einschätzung des Kollegen – wieder interessant und relevant. Aus genau diesem Grund ist es wichtig, dass es während eines Meetings einen Protokollführer gibt, der alle neuen Entscheidungen, Fragen und Aussagen notiert. Das kann über einen PC, Clipboard, Block oder sonst einem Medium geschehen. Zu diesem Zeitpunkt ist möglichst leichte Handhabung wichtiger als Struktur!

Hat ein Kollege seine Aufgaben in einem Meeting erfüllt – bspw. muss der Programmierer nicht für Design-Fragen bleiben. Hier reicht später eine Zusammenfassung – sollte man seine Aufgaben und die mit ihm gewonnen Erkenntnisse noch einmal kurz zusammenfassen, sodass alle Parteien eine ähnliche Vorstellung davon haben. Aufgrund der subjektiven Wahrnehmung der Teilnehmer ist eine identische Vorstellung eines Sachverhalts meist nicht möglich und auch an dieser Stelle lassen sich Unklarheiten nur reduzieren, nicht jedoch ausschließen. Ist diese Zusammenfassung erfolgt, sollte man den Kollegen auch von dem Rest des Meetings freistellen. Oftmals werden Kollegen von Anfang bis Ende in einem Meeting gehalten, obwohl sie nur einen sehr speziellen Aspekt betreuen. Dies führt zu Frust über das Meeting bei dem Kollegen und verschlingt unnötig die kostbare Projektzeit. Eine Zusammenfassung der wichtigsten Themen im Nachgang wird später noch genauer beleuchtet und dient diesen Kollegen als Verständnisbasis des restlichen Meetings.

Während des gesamten Meetings hat der Meeting-Leiter vor allem eine Aufgabe. Er koordiniert die Teilnehmer und sorgt dafür, dass die Diskussionen in den richtigen Bahnen verläuft. Sobald ein Teilnehmer zu ausschweifend wird oder sich zu sehr in Details verstrickt, sollte der Meeting-Leiter diesen Kollegen freundlich aber bestimmt zurück zum eigentlichen Thema führen. Schnell verlieren sich die Teilnehmer sonst in Diskussionen, bei denen wieder nur ein Teil der Teilnehmer wirklich etwas zu sagen hat, oder das eigentliche Thema wird nicht bearbeitet und bleibt liegen. Natürlich kann dies bei einem wichtigeren Thema durchaus sinnvoll sein, sofern es auch hier wieder dokumentiert wird. Wichtig ist jedoch wie gesagt, dass der Meeting-Leiter die Sorge dafür trägt, dass der eigentliche Fokus des Meetings nicht aus den Augen verloren wird.

Nähert sich das Meeting dem Ende sollte der Meeting-Leiter noch einmal die getroffenen Vereinbarungen, Entscheidungen, offenen Fragen etc. zusammenfassen, sodass jeder noch einmal überprüfen kann, ob auch alle für ihn relevanten Ergebnisse vertreten sind oder er noch etwas anmerken, hinzufügen oder klarstellen möchte. Dies ist auch dann wichtig, wenn das Meeting sich als zu kurz herausgestellt hat. In diesem Fall sollten bereits die wichtigsten Punkte für die unmittelbare Zukunft geklärt sein. Die Zwischenergebnisse werden noch einmal zusammengefasst und die Punkte für den Folgetermin besprochen.

Da die Kollegen in aller Regel Folgetermine oder reguläre Aufgaben haben, sollte das Ende des Termins stets eingehalten werden. In Ausnahmen kann der Meeting-Leiter die Kollegen fragen, ob sie mit einer Verlängerung des Termins einverstanden wären. In diesem Fall sollte jedoch auch geprüft werden, ob der gebuchte Raum noch frei ist.

Nach dem Meeting

Ist das Meeting abgeschlossen, sollte der Meeting-Leiter die erarbeiteten Erkenntnisse verarbeiten und ablegen. Zum einen sollte er die zuvor mündliche Zusammenfassung nun noch einmal schriftlich an alle Teilnehmer versenden. Zum einen ist dies eine Gedächtnisstütze für die Kollegen, zum anderen haben eventuell Kollegen das Meeting vorzeitig verlassen.

Gibt es zu diesem Meeting außerdem noch Stakeholder, also Leute, die an den Ergebnissen interessiert sind ohne direkt Mitsprache zu haben, können auch diese eine Zusammenfassung erhalten. Diese ist meist verkürzt gegenüber der internen Zusammenfassung, da dieser Personenkreis deutlich weniger in der Materie und meist nur an den eigentlichen Ergebnissen interessiert ist. Dafür kann es notwendig werden, weitere Erklärungen in die Zusammenfassung einzubinden. Zum Beispiel für spezielle Sachverhalte oder Fachbegriffe.

Alle erarbeiteten Ergebnisse müssen schließlich noch auffindbar abgelegt werden. Das kann zum Beispiel in einem speziellen Projekt- oder Themenraum sein. Der Link sollte ebenfalls an die Zusammenfassung – zumindest bei den beteiligen Kollegen – angehangen werden.

Tut das Not, dass da so viel Arbeit reingesteckt wird?

Jetzt kann ich schon hören, wie einige sich insgeheim fragen, ob das alles Not tut. Das kann man doch auch viel schneller machen und so hat man ja einen Riesenaufwand! Ja, den Aufwand will ich nicht leugnen. Trotzdem ist das aus meiner Sicht die richtige Vorgehensweise, wenn man ein Meeting zu einem wichtigen, verbindlichen Thema machen will. Die Frage, die ich mir ehr stelle ist, warum ich ein Meeting aufsetzen will, wenn  ich keine verbindlichen Aussagen haben möchte. In diesem Fall könnte ich mich schließlich auch mit den Kollegen beim Mittag oder auf einen Kaffee treffen.

Ein Meeting hat für mich immer einen offiziellen Charakter und sollte auch so gelebt werden. Es muss eine Hürde geben ein Meeting einzuberufen, da man sonst nur noch in solchen Veranstaltungen hängt. Typische Beispiele für ein Meeting sind aus meiner Sicht die Meilensteinplanung, Eskalationsmeetings, Phasenabschlussmeetings oder die Scrum-Meetings. Und ja, selbst bei dem Daily Scrum gibt es diese Form. Wir haben einen festen Teilnehmerkreis, jeder berichtet möglichst flott was er geleistet hat, was er vor hat und was ihn hindert. Und diese Erkenntnisse werden dann schriftlich im Sprint-Backlog und der Impediments-Liste erfasst. Eine Zusammenfassung kann hier entfallen, da die Liste für jeden zugänglich ist und es bekannt ist, dass die Ergebnisse hier abgelegt sind.

Von daher meine Bitte, überlegt euch ob ihr ein Meeting benötigt. Und wenn, dann führt es so aus, dass auch in ein paar Wochen noch klar ist, was besprochen wurde und wo ich die Ergebnisse finden kann.

Zusammenfassung

Vor dem Meeting:

  • wähle einen Titel der möglichst treffend ist
  • lade nur ein, wer wirklich notwendig ist
  • mache ggf. mehrere Meetings mit unterschiedlichen Teilnehmern
  • schreibe eine Agenda zum Meeting
  • verlinke, wenn notwendig, auf weiterführende Informationen und Projekträume
  • fasse die konkreten Anforderungen verständlich zusammen
  • wähle eine Zeit, in der die Personen zeit haben oder kläre mit verhinderten Personen, ob sie den Termin zwischenschieben können

Während dem Meeting:

  • Fasse den aktuellen Stand anfangs zusammen
  • Fasse die konkreten Aufgaben und Fragestellungen zusammen
  • Es ist eine Diskussionsrunde. Verzichte auf PowerPoints und Monologe
  • Lass die Teilnehmer notwendige Ergänzungen machen
  • Behandele zuerst die Themen, bei denen Kollegen vorzeitig das Meeting verlassen können
  • Notiere jede Entscheidung, Frage oder Erkenntnis mit
  • Fasse den aktuellen Stand auch am Ende des Termins zusammen
  • Vereinbare direkt einen Folgetermin, wenn dieser notwendig ist
  • Verlängere den Termin nur in Ausnahmen und mit Zustimmung der Beteiligten

Nach dem Meeting:

  • Eine Meeting-Zusammenfassung mit den wichtigsten Ergebnissen und Entscheidungen wird an alle Teilnehmer versendet
  • Erarbeitete Ergebnisse werden auffindbar abgelegt
  • Eine verkürzte Zusammenfassung kann eventuell an Stakeholder versendet werden, sofern sinnvoll

Wie erstelle ich ein Lastenheft?

Wieder ein Thema aus dem Alltag. Ich wurde zu einem Kunden bestellt um dort mit ihm zusammen Lastenhefte für verschiedene Projekte zu erstellen. Das hat mich zu der Frage geführt, was macht eigentlich ein gutes Lastenheft aus und wie könnte mein Beratungsanteil darin aussehen? Es ist ja so, dass der Kunde seine Anforderungen am besten kennt. Er hat eine Idee für ein neues Produkt oder eine neue Funktion im Kopf und ich kann ihm nur helfen das Ganze in die richtige Form zu bringen und ihn darauf hinweisen, welche Informationen er benötigt. Aus dieser Herangehensweise heraus habe ich eine PowerPoint erstellt, welche die aus meiner Sicht wichtigsten Aspekte in Fragenform beinhaltet. Die wichtigsten Aspekte daraus möchte ich gerne mit euch teilen.

Die Kernaspekte können in 9 Kapitel gegliedert werden:

  1. AusgangssituationWas hat den Kunden dazu bewogen ein Projektvorhaben zu starten? Was ist das Problem, wie wurde es früher behoben und welcher Mehrwert entsteht mit der neuen Lösung. Ach ja, und natürlich passt die Projektidee zum Gesamtkonzept des Unternehmens
  2. ZielsetzungWie soll das Ergebnis aussehen und was werden die Akzeptanzkriterien sein? Welche Messwerkzeuge werden zur Prüfung eingesetzt? Welche Ressourcen benötigen wir und bis wann muss es fertig sein?
  3. ProdukteinsatzWie sieht die Umgebung aus mit Tools, Patchständen, Konfigurationen etc. Sind wir in der Cloud oder benötigen wir mobile devices? Und an wen richten wir uns? Eine kleine Expertengruppe oder ehr alle Mitarbeiter des Unternehmens?
  4. Funktionale AnforderungenDie Fachlichen Anforderungen sind das wichtigste für den Kunden und das am schwierigsten beschreibbare für uns. Was genau will der Kunde mit seinem Projekt erreichen? Wie viele Einzelanforderungen können wir herauskitzeln und wie werden sie SMART? (Siehe Ende des Beitrages)
  5. Nichtfunktionale AnforderungenHier geht es um Änderbarkeit, Flexibilität, Skalierbarkeit, Performance, Sichtbarkeit, Sicherheit, Zuverlässigkeit und Bedienbarkeit der Lösung. Also alles Faktoren, die für die eigentlichen Anforderungen unerheblich sind, jedoch ausschlaggebend für die Akzeptanz der Software.
  6. LieferumfangWas wird als Bestandteil des Ergebnisses für dieses Projekt erwartet und auch, was wird nicht erwartet? Gibt es Dinge, die aus anderer Quelle kommen?
  7. Phasenplanung und MeilensteineDas Umfasst die Planung. Wie lange soll das Projekt gehen sowohl in Zeiteinheiten als auch Projekteinheiten. Gibt es einen zwingenden Termin für das Projekt? Gibt es Abhängigkeiten zwischen einzelnen Projektteilen und einen kritischen Pfad? Wie geht es mit Schulungen und GoLive weiter? Und natürlich was ist in den jeweiligen Meilensteinen genau abzuliefern?
  8. Offene PunkteWas sind die noch offenen Fragen? Wer ist für die Klärung verantwortlich und wer ist Entscheidungsträger? Gibt es einen allgemeinen Entscheidungsprozess innerhalb des Projektes und wie sieht es mit den Veto-Rechten der Stakeholdern aus?
  9. Abnahmekriterien und QualitätsanforderungenIm Prinzip schon in der Zielsetzung genannt, wird hier noch einmal ganz konkret die Erwartungshaltung geklärt. Was muss passieren, damit das Projekt als Erfolg gewertet wird? Wie sind die Berichtswege und Eskalationswege. Wie sehen die konkreten Qualitätsansprüche an das Projekt aus und wie setzen wir diese um? Gibt es Applikationen mit denen die Qualität in diesem Projekt zwingend nachgewiesen werden muss?

Und zum Schluss noch, was ist eigentlich das Smart-Kriterium? Eine Anforderung ist SMART, wenn:

•        Spezifisch           Ziele müssen eindeutig und präzise definiert sein
•        Messbar               Ziele müssen anhand von Parametern prüfbar sein
•        Akzeptiert           Ziele müssen von den Empfängern akzeptiert werden
•        Realistisch          Ziele müssen möglich sein
•        Terminiert          Ziele müssen mit einer klare Terminvorgabe versehen sein