Schlagwort: Projektleitung

Projekte in der Krise VI

Veröffentlicht in Realisierung, WartungKommentar hinterlassen

Die Übernahme von internen Fremdprojekten

Nachdem wir uns im letzten Beitrag damit beschäftigt haben, was alles bei externen Fremdprojekten schiefgehen kann, kommen wir nun zu den internen. Wo der Unterschied ist? Nun, zum einen sind die Kollegen meist noch greifbar. Zum anderen spielt hier aber auch ein gutes Stück Politik mit hinein und die Gefahr einem Kollegen auf die Füße zu treten.

Das Szenario

Gehen wir von folgendem Szenario aus. Eine Abteilung innerhalb des Unternehmens hat seit einigen Jahren bereits einen SharePoint im Einsatz. Es gibt jemanden, der sich recht gut damit auskennt. Das meiste hat er sich autodidaktisch beigebracht und auch für viele Probleme seiner Kollegen eine schnelle Lösung gefunden. Nicht immer ganz sauber, aber immer so, dass es weitergeholfen hat. Nun ist er jedoch an einem Punkt angelangt, indem die weitere Pflege dieser Plattform sich zeitlich nicht mehr mit seinen anderen Aufgaben vereinbaren lässt. Also soll die Site Collection (sprich die Webseite, auf der die Lösung betrieben wird) nun in die Obhut der internen IT übergeben werden. Wir als externe Consultants werden genau von dieser IT-Abteilung als Ratgeber mit dazu gezogen.

Die Herausforderung

Nun beginnt die eigentliche Aufgabe. Denn oft sind solche Projekte nur sehr schwer zu administrieren und zu erweitern. Wieso? Nunja, derjenige, der bisher den SharePoint erweitert und die Änderungen vorgenommen hat war kein IT-Spezialist, sondern ist in diese Rolle hineingewachsen. Für unser Beispiel war es ein Mitarbeiter der Buchhaltung und hat kleinere Tools und Lösungen für ebenjene Abteilung erstellt. Das Problem dabei ist jedoch, dass ihm damit auch das Handwerkszeug eines IT-Spezialisten fehlt. Das bedeutet, dass in der Regel alle Änderungen „mal schnell“ durchgeführt wurden und damit nichts dokumentiert wurde. Es gibt also keine Architekturübersicht, Anforderungsdokumente, Änderungshistorie oder dergleichen. Alles, was man vermutlich hat sind ein paar Änderungswünsche oder Fehlerbeschreibungen von der Abteilung.

Gut, immerhin ist der Kollege, der das Tool erstellt hat, noch verfügbar. Doch er hat diese Anwendung über Jahre erstellt und weiß selbst nicht mehr genau, wo er was nun gemacht hat. Das war ja schließlich auch der Grund wieso er es letztlich abgegeben hat. Denn all dies wird ihm zu viel und es würde die Abteilung inzwischen billiger kommen, wenn es durch den IT-Support betreut wird, als wenn man einen weiteren Kollegen ausschließlich für diese Seite beschäftigen würde. Das Problem des Beraters und der IT-Abteilung hier ist offensichtlich. Man muss versuchen möglichst viel Informationen abzugreifen und durch möglichst gezielte Fragen der Erinnerung des Abteilungskollegen auf die Sprünge helfen. Doch man sollte unter allen Umständen vermeiden den Kollegen zu sehr vor den Kopf zu stoßen oder seine Arbeit zu hart zu kritisieren. Das würde für Verdruss auf beiden Seiten sorgen und im Notfall zieht der Kollege die Reißleine und beschränkt seine Zusammenarbeit nur noch auf das Nötigste

Die Herangehensweise

Tatsächlich weiß der Kollege in der Regel selbst, dass er hier nicht das Gelbe vom Ei produziert hat. Schließlich kommt er selbst nicht mehr damit zurecht. Daher sollte man versuchen eine positive Art zu dem Kollegen zu finden. Ja, das Projekt ist nicht gut, aber die Aufgabe ist nun einmal gestellt und nun gilt es erst einmal eine Bestandsaufnahme zu machen. Anschließend muss man dann entscheiden wie es weitergeht. Wichtig ist vor allem, dass man hier nicht in schlechte Stimmung verfällt. Nur allzu leicht kann dies passieren, wenn man das Projekt zu nah an sich heran lässt oder es mit dem gewohnten Maßstab vergleicht. Entscheidend ist tatsächlich hier, dass man sich klar macht, dass es ein Hobbyprojekt war und der Kollege es gut gemeint hat. Nur mit dieser Einstellung kann man ein solches Projekt stemmen ohne sich selbst zu verschleißen.

Okay, wir gehen also positiv an die Sache heran (Tschakka!). Also machen wir als erstes mal eine Bestandsaufnahme um herauszufinden was überhaupt möglich ist. Welche Version ist im Einsatz, welche Features sind aktiviert, welche Third-Party-Tools finden Verwendung und wo hatte der Kollege welche Rechte. Mit diesen Fragen lässt sich das Tätigkeitsfeld erst einmal einschränken. Anschließend schauen wir uns die Probleme an, die mit der Anwendung gemeldet wurden. All diese Informationen erfassen wir jetzt natürlich sauber in unsere ALM Tool (z.B. dem TFS oder VSTS), damit die Erkenntnisse künftig sauber dokumentiert an einem Ort abgelegt sind.

Nachdem wir nun das Gefühl haben, dass wir zumindest die Rahmenparameter kennen und uns auch die Anwendung schon einmal angeschaut haben, reden wir mit dem Kollegen. Welche Probleme hat er mit seiner Anwendung behoben, an welche Änderungen kann er sich noch erinnern, wo sind die Knackpunkte an denen er gescheitert ist. Ich denke, in einem positiven (!) Gespräch kann man etwa 70-80 % der Applikation in Erfahrung bringen und die häufigsten Anwendungsfälle identifizieren. Natürlich schreiben wir auch hier wieder alles mit was wir erfahren und bringen es anschließend in eine geeignete Form, sodass wir auch künftig damit arbeiten können.

Gut, damit sollten wir jetzt zumindest schon einmal die wesentlichen Rahmendaten kennen. Wir wissen über die Technologie, die groben Strukturen der Applikation, die Probleme und auch über den Wissensstand des Kollegen bescheid. Daraus können wir also schon einmal herleiten, was er vermutlich getan hat und wozu er einfach nicht in der Lage war. Wenn wir dieses Wissen nun mit der Applikation und den aufgetretenen Problemen abgleichen können wir vielleicht schon das meiste identifizieren und benennen.

Die Übernahme

Der nächste Punkt ist dann der eigentlich Entscheidende. Ist das Projekt geeignet um die Probleme zu lösen, die es aktuell gibt und ist es möglich das Projekt auch in Zukunft sauber zu warten? Wenn nicht, macht es Sinn das Projekt neu aufzusetzen? Das wäre auch dann sinnvoll, wenn es ausreichend Änderungsvorschläge und Verbesserungspotenzial gibt, damit die Abteilung einen echten Mehrwert von der Weiterentwicklung hat. Gibt es dafür entsprechendes Budget und die Bereitschaft, dann ist dieser Weg zu bevorzugen. In der Regel ist es jedoch so, dass genau dieses Budget eben fehlt. Deshalb hat der Kollege ja angefangen alles in Eigenregie umzusetzen. Also was jetzt?

Die Lösung ist ähnlich wie auch bei externen Projekten. Man muss eine Kostenaufstellung machen. Dazu sollte man sich fragen, welche Laufzeit für das Projekt erwartet werden kann. Sind solche Zahlen nicht lieferbar würde ich von einer geschätzten Laufzeit von 5 Jahren ausgehen. Denn in der Regel wird eine Plattform innerhalb dieser Zeit durch ihren Nachfolger abgelöst und auch ansonsten ist der Zeitraum groß genug um zu zeigen wie groß die Initialen und die Folgekosten sind. Nun stellt man also die Initialen Kosten für die Übernahme bzw. für die Neuerstellung und den Betrieb für die nächsten Jahre gegenüber. Man nennt die Risiken bewertet diese mit Multiplikatoren. Am Ende werden 2 Zahlen herauskommen. Welche Kosten entstehen für die Übernahme bzw. Neuentwicklung des Projektes im vermuteten Zeitraum. Natürlich gibt es dort immer etwas Spielraum und die Zahlen sind nicht final. Dennoch bieten sie einen guten Einblick mit welcher Größenordnung gerechnet werden muss.

Ist diese Zahl weit jenseits der erwarteten und veranschlagten Kosten für das Projekt sollte man auch als IT-Abteilung bereit sein ein Projekt abzulehnen oder zumindest an die nächste Instanz zu eskalieren. Was passiert, wenn es zur Eskalation kommt, darüber werden wir uns in einem anderen Beitrag unterhalten.

Mehr zum Thema?

Projekte in der Krise IV

Veröffentlicht in Allgemein, Qualitätssicherung, Realisierung2 Kommentare

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 I

Veröffentlicht in AngebotsphaseKommentar hinterlassen

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

Veröffentlicht in Qualitätssicherung, RealisierungKommentar hinterlassen

Ü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

Veröffentlicht in Projektende, Qualitätssicherung, ReleaseKommentar hinterlassen

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 ​

Veröffentlicht in Angebotsphase, Konzeption, QualitätssicherungKommentar hinterlassen

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?

Wie erstelle ich ein Lastenheft?

Veröffentlicht in AngebotsphaseKommentar hinterlassen

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

Projekt Kick-Off

Veröffentlicht in RealisierungKommentar hinterlassen

Was ein Kick-Off Meeting erreichen sollte

Eine Frage aus dem Daily Business. Was muss ein Kick-Off Meeting erreichen? Oder besser gefragt, was kann ein Kick-Off Meeting erreichen? Meine Meinung dazu.

Ich weiß, dass PRINCE2 normalerweise keine Kick-Off Veranstaltung kennt. Dennoch sehe ich es als eine essentielle und notwendige Veranstaltung. Vor allem dann, wenn das Projektteam nicht in der immer gleichen Aufteilung unterwegs ist. Kann man also darauf verzichten, wenn man Beispielsweise ein Scrum-Team hat und dieses Team dann immer wieder in der gleichen Rollenverteilung auf neue Projekte losgelassen wird? Selbst da würde ich ungern darauf verzichten. Denn dieses Meeting bietet allen Projektbeteiligten die Möglichkeit sich gegeneinander kennen zu lernen und einen ersten Eindruck zu gewinnen. Außerdem wird in diesem Meeting das Verständnis der einzelnen Aufgaben, die fachlichen Hintergründe, die Personen und Rollen geschaffen. Sowohl für das Projektteam, als auch den Auftraggeber.

Somit ist aus meiner Sicht das Kick-Off lebensnotwendig für einen Projekterfolg. Und zwar nicht als Monolog des Projektleiters, sondern als kollegialer und positiver Austausch, bei dem der Projektleiter der Moderator ist. Ein Kick-Off sollte meiner Meinung nach folgende Ziele haben:

Das Projektziel sollte klar kommuniziert sein.
„Am Tag X müssen wir Y fertig haben, damit der Kunde damit Z erreicht. Der Milestone A ist dabei von essentieller Wichtigkeit, da er die Kernkomponente darstellt.“ Das Projektziel und die Gründe des Kunden für dieses Ziel schaffen ein Verständnis für das Projekt und jeder Einzelne kann dann beurteilen, an welcher Stelle eventuell etwas zurückgestellt werden kann, um am Tag X die notwendigen Komponenten bereit zu haben. Nacharbeiten sind normal, dürfen aber nicht das Ziel des Kunden behindern. Und im Notfall muss man ein Provisorium einrichten, um dem Kunden das Ziel zu ermöglichen. Wobei hier Vorsicht geboten ist, denn nichts hält länger als ein Provisorium!

Klare Definition der Verantwortlichkeiten der einzelnen Projektmitglieder
Welche Aufgaben hat jemand zu erfüllen und welche nicht? Im Gespräch mit verschiedenen Beteiligten eines bestimmten Projektes ist mir hier ein Paradebeispiel aufgefallen. In diesem Projekt gab es einen Beteiligten. Er wurde vom Projektleiter als Softwarearchitekt gesehen. Dies wurde aber scheinbar nicht offen genug kommuniziert, oder die damit verbundenen Verantwortlichkeiten waren nicht klar. Denn der Betroffene selbst hat sich als technischer Ansprechpartner für den Kunden und Vermittler zu den Entwicklern wahrgenommen. Davon, dass er für die Konzeption der Architektur und deren Überprüfen verantwortlich war, wusste er jedenfalls nichts. Derartige Unklarheiten müssen direkt im Kick-Off beseitigt werden, indem sich jeder Projektmitarbeiter in eigenen Worten auf sein Ziel und seine Aufgaben commited. Dies sollte für spätere Nachvollziehbarkeit oder Projektmitglieder, die später in das Projekt kommen, auch schriftlich fixiert werden.

Konkrete Vermittlung der Milestones, der Aufgaben und der Definition of Done
Wann muss welches Ziel erreicht werden? Welche Aufgaben müssen dafür realisiert werden und wann können sie als erledigt betrachtet werden? Und auch, wer wird wann welche Aufgabe angehen und voraussichtlich abschließen können? Wo ist der kritische Pfad der Applikation und wie können wir ggf. Ausfallsicherheit für einzelne Personen schaffen? Oder haben wir eine Möglichkeit den kritischen Pfad mit einer zusätzlichen Person zu entlasten? Wenn diese Themen klar und transparent sind, ist es dem Team möglich ein Gesamtverständnis zu erhalten und bei Bedarf den Kollegen hilfreich beiseite zu stehen.

Welche Methoden nutzen wir technologisch und organisatorisch. 
Darüber habe ich bereits an anderen Stellen viel gesprochen und möchte hier nicht detailliert auf die Methoden eingehen, da es ansonsten den Rahmen sprengen würde. Als Keywords seien Scrum vs. V-Modell, Unit-Tests & User Acceptance Tests, Azure DevOps und Continues Integration genannt.

Welche Schwierigkeiten gibt es noch?
Commitment auf die Probleme, einen Verantwortlichen und mögliche Lösungsansätze. Alles was zu dem Kick-Off noch nicht klar ist oder Probleme die noch nicht behoben sind, müssen in einer Liste erfasst und mit einem Verantwortlichen versehen werden. Auch ein Termin für die Bearbeitung ist notwendig.

Das sind aus meiner Sicht die wichtigsten Erkenntnisse eines Projekt-Kick-Offs. Das Kick-Off sollte übrigens auch mit dem Kunden stattfinden, sodass er weiß was getan wird und sich abgeholt fühlt. Ich bin ein Freund der offenen Kommunikation mit dem Kunden. Schließlich sitzt auf der anderen Seite auch nur ein Mensch und wir sollten mit ihm arbeiten, statt gegen ihn. Wenn es Probleme gibt, kommunizieren wir sie. Dann hat der Kunde die Möglichkeit darauf zu reagieren. Schlimmer wird es, wenn er davon überrascht wird oder anfangen wird Dinge zu faken. Holt den Kunden mit ins Boot und lasst ihn die Entscheidungen mittragen. Das nimmt den Druck aus der Sache und eventuell hat auch der Kunde noch eine Idee zur Lösung.

Mehr zum Thema?

End of Life – Eine Applikation wird abgelöst

Veröffentlicht in ProjektendeKommentar hinterlassen

Es gibt weitere Phasen im Leben einer Applikation, welche von dem aktuellen Entwurf von Application Lifecycle Management nicht beachtet werden, da es für das eigentliche Produkt nicht relevant ist. Dennoch sollten sie in einem ganzheitlichen Ansatz beachtet werden. Es geht um die Stilllegung der Applikation. Jede Applikation wird früher oder später abgeschaltet werden. Sei es, weil sich die Anforderungen des Kunden verändert haben, oder weil das zugrundeliegende Framework nicht mehr gewartet wird. Als Berater sollten wir auch diese Phase im Auge behalten, da sie auch vom Kunden oft übersehen wird und dennoch einen enormen Mehrwert bieten kann.

Natürlich könnten wir jetzt sagen, was haben wir damit zu tun? Wenn die Applikation nicht mehr gepflegt werden kann, dann haben wir auch keinen Auftrag mehr. So zuletzt oft gesehen mit IBM und Lotus Notes. Die bestehende Software wird abgeschaltet und durch eine komplett neue Technologie mit neuen Beratungsunternehmen ausgetauscht. Doch das muss ja nicht sein. Was wäre zum Beispiel, wenn wir eine Farmsolution aus SharePoint 2010 künftig in die O365-Cloud transferieren sollen? Und zwar nicht einfach 1:1, sondern angepasst auf den aktuellen Stand der Technik. Mit neuen Sozialen Features und Gruppenräumen? Nun, in diesem Fall wäre es sicherlich gut, wenn wir möglichst einfach die Geschäftsdaten transferieren könnten.

Auf die Einstellung kommt es an!

Oftmals wird ein Migrationsprojekt verharmlost und nur selten dem ALM-Prozessen unterworfen. Schließlich handelt es ich ja nur um eine Einmalaktion und muss nicht ständig gewartet und verbessert werden. Es handelt sich also um ein schnelles Projekt ohne besondere Herausforderungen an die Qualität und Wartbarkeit. In der Regel ist das Gegenteil der Fall! Eine Migration sieht sich mit Daten aus dem kompletten Lebenszyklus der Applikation konfrontiert. Je nachdem wie gut die Applikation gewartet wurde, kann es also durchaus Daten geben, die nur zu einem bestimmten Zeitpunkt gültig waren und nun gar nicht mehr in die aktuelle Informationsarchitektur passen, oder neu aufbereitet werden müssen. Dem Projektteam sollte dieser Umstand klar sein und im Idealfall sollten möglichst viele Beteiligte des Lebenszyklus der Applikation konsultiert werden um auf derartige Fallen vorbereitet zu sein. Natürlich ist auch an dieser Stelle eine saubere Dokumentation Gold wert, da viele Dokumente erst zu diesem späten Stadium wieder wirklich relevant werden und bis zu diesem Zeitpunkt scheinbar viel unnütze Arbeit in diese Strukturen gesteckt wurde.

 Vorarbeiten im ALM-Prozess

Damit es möglich ist, eine Applikation möglichst problemlos abzuschalten, muss die Gesamt- und insbesondere die Informationsarchitektur der Lösung gut durchdacht und – auch hier wieder – dokumentiert werden. Dies ist besonders wichtig, da die Verantwortlichen der Lösung mit einer gewissen Wahrscheinlichkeit bei Abschaltung nicht mehr bei der Firma oder für diese Applikation arbeiten und Ihr Wissen nach dem Abschluss des Projektes wahrscheinlich auch nicht mehr weitergegeben wurde. Aus diesem Grund ist es essentiell Dokumente zu haben, woraus ersichtlich wird, wie die Daten in Verbindung stehen, wo sie abgelegt sind und wie diese möglichst einfach herausgezogen werden können.

Im Idealfall gibt es bereits Schnittstellen um diese Daten abzugreifen, oder sie werden im Rahmen der Applikationsentwicklung eingerichtet. Solche Schnittstellen sind nicht nur für das Ende der Applikation hilfreich, sondern helfen auch dabei das Programm in die Systemlandschaft zu integrieren und Informationen auch in anderen Applikationen zu verwenden. SharePoint bietet dieses Schnittstellen bereits Out-Of-The-Box. Wichtig ist nur, dass auch die neu hinzugefügten Applikationen und ihre Datenhaltung diese Schnittstellen nutzen können, oder neue Schnittstellen implementiert und dokumentiert werden.

Die Transfervorbereitung

In der Transferphase geht es hauptsächlich um einen Aspekt, der dieser auch den Namen geben. Wie bekomme ich die bestehenden Geschäftsdaten am besten aus meiner Alt-Applikation um die Applikation verlustfrei abschalten zu können?

Hier kommen meist Third Party Migrationstools zum Einsatz, welche die Daten aus einer Applikation heraus holen und in eine andere hinein schieben können. Der Architekt der Alt-Applikation sollte wie oben erwähnt bereits in der Konzeptionsphase des ALM darauf zu achten, dass dieser Weg möglichst einfach ist. Für SharePoint gibt es bereits gute Migrationstools. Im Idealfall setzt auch die Applikation auf dem SharePoint Standard auf, oder stellt wie oben erwähnt bereits geeignete Schnittstellen für die Datenmigration bereit.

Ziel ist es demnach, dass in der Transferphase alle Vorbereitungen getroffen werden, um die Daten aus dem Altsystem in das neue System überführen zu können. Zu den Liefergegenständen dieser Phase gehören Vorgehensbeschreibungen, Migrationsskripte und -tools und Rollback-Szenarien. Beteiligt sind an dieser Phase meistens das alte und das neue Operations-Team, sowie die alte und neue Wartungsmannschaft der Zulieferer. Im Idealfall sind auch die Architekten beider Lösungen noch greifbar. Erforderlich sind meist auch der Architekt und die Entwicklungsmannschaft der neuen Lösung. Diese Phase sollte wie aus dem ALM gewohnt auch den Dokumentations- und Qualitätsrichtlinien entsprechen. 

Die Stilllegung und das neue Go Live

Die Stilllegungsphase ist der kritische Teil einer Migration. Hier wird das alte System ab- und das neue System live geschaltet. Wie genau findet dieser Prozess nun statt und wie kommen die Daten nun wirklich in das System?

Wichtig ist zu beachten, dass die meisten Applikationen eine gewisse Kritikalität für den Kunden haben und daher die Übergangsphase möglichst reibungslos ablaufen muss. Dafür gibt es zwei Ansätze. Der erste ist die Abschaltung des Altsystems, der Transfer der Daten und die Anschaltung des neuen Systems. Meistens ist jedoch die Transferzeit zu lang, sodass es eine Zeitspanne gibt, in der ein Parallelbetrieb beider Applikationen stattfindet. In diesem Fall gibt es meist auch nicht nur einen einzelnen Datentransfer, sondern die Daten werden mehrfach vom Altsystem in das Neusystem repliziert. Dabei muss besonders darauf geachtet werden, dass es zu jedem Zeitpunkt nur einen Single Point of Truth gibt – also neue Daten immer nur in einem System erfasst werden können. Dies sorgt dafür, dass es später nicht zu unvorhersehbaren Zuständen kommt und die einen Nutzer bereits Informationen im Neusystem, andere im Altsystem für die gleichen Datensätze erfassen.

Die Migration findet nun nach den vorher definierten Prozessen statt. Obwohl dieser Teil sehr wichtig für den Erfolg ist, gibt es dazu wenig zu erklären. Sämtliche Prozesse wurden im Vorfeld bereits definiert und werden nun abgehandelt. Da Migrationen so gut wie nie komplett glatt laufen, sollten in dieser Phase nach Möglichkeit alle Beteiligten der Transferphase greifbar sein um somit möglichst agil auf neue Anforderungen reagieren zu können. Wichtig ist nur, dass alle aufgetretenen Probleme und spontanen Änderungen ebenfalls sauber dokumentiert und festgehalten werden, sodass die Migrationsprozesse sauber nachvollzogen werden können.

Am Ende der Phase gibt es zwei mögliche Zustände. Entweder die  Migration ist erfolgreich durchgelaufen und es gibt nun ein neues System. In diesem Fall greift wieder der normale ALM Prozess und das Team der neuen Applikation kann in die Betriebs- und Optimierungsphase übergehen. Ist die Migration fehlgeschlagen, muss das Rollback-Szenario ausgeführt werden, sodass das Altsystem weiterhin das führende System ist. In diesem Fall muss erneut in die Transferphase übergegangen werden und die aufgetretenen Fehler müssen analysiert, dokumentiert und beseitigt werden.