Die 7 W-Fragen im Anforderungsmanagement

Nachdem es nun einige Zeit ruhig war auf meinem Blog, melde ich mich nun wieder mit einem Evergreen für Softwareprojekte zurück.

Hintergründe der Kundenanforderung

Der Kunde hat eine Idee. Er hat einen Bedarf für eine neue Softwarelösung erkannt oder möchte eine bestehende Software ablösen. Z.B. weil die Lizenzen für die aktuelle Version auslaufen oder die Plattform als ganzes abgeschafft werden soll.

Je nachdem woher er kommt fallen beide Szenarien schon einmal unterschiedlich aus. Hat der Kunde nur eine diffuse Vorstellung wie „Ich würde gerne meine Personalplanung und Urlaubsverwaltung automatisieren.“,  dann ist er in der eigentlichen Umsetzung noch nicht festgelegt und muss hier ggf. sogar Stück für Stück an die technologische Plattform mit ihren Möglichkeiten und Grenzen herangeführt werden.

Möglichkeit Zwei ist, dass er diese Software bereits kennt und nutzt. Er würde allerdings gerne eine neue, moderne Umsetzung haben. Entweder, weil die alte Plattform strategisch abgelöst wird, oder weil er selbst von der alten genervt ist. Im Fall einer strategischen Entscheidung ist dies wiederum schwieriger, da er eventuell gar nicht wechseln will und man zusätzlich noch gegen Widerstände ankämpfen muss. Möchte er selbst den Wechsel, fällt auch die Beratung leichter. In beiden Fällen ist die Situation hier, dass der Kunde bereits seine Software kennt und er entsprechende Vorstellungen und Erwarutungshaltungen hat. Er wird davon ausgehen, dass die neue Applikation im Prinzip ein besserer Klon der Altsoftware ist. Besser deshalb, weil er ja jetzt die Möglichkeit hat, neue Funktionalitäten einbauen zu lassen, die er schon immer haben wollte.

Doch selbst bei einem Neusystem wird der Kunde nicht unvoreingenommen an die Sache herangehen. So wird er heutzutage natürlich mit einem Smartphone arbeiten und kennt die schicken – oder auch mal weniger gelungenen – Apps aus dem jeweiligen Store. Vielleicht ist er sogar ein Apple-User und ist es entsprechend gewohnt alles möglichst unkompliziert zu haben. Ein guter Vorsatz. Allerdings ist eine Vereinfachung oft schwerer zu erreichen als alles zu übernehmen. Und das bedeutet entsprechende Mehrkosten.

Was die W-Fragen sind und ihr Mehrwert

Und schon sind wir voll im Thema. Wie bringen wir die Anforderungen des Kunden zu Papier? Wie unterscheiden wir „Must Have“ von „Nice To Have“? Wie bringen wir die Designanforderungen des Kunden und die User Experience im Preis unter? Was ist überhaupt der Preis / Aufwand den wir dafür aufrufen können und sollten? Und ist unser Ansprechpartner denn eigentlich die richtige Ansprechperson für das Thema?

Für genau diese Themen entlehnen wir eine Technik, die bereits vielerorts eingesetzt wird und sich über viele Jahre bewährt hat. Wer bereits einmal die Rettungsdienste angerufen hat, oder von seinen Eltern darüber aufgeklärt wurde, dem werden die W Fragen ein Begriff sein. „Was ist passiert?  Wo ist es passiert? Wie viele Verletzte gibt es? Wer war beteiligt?“ Später wird man dann noch fragen, „Wie ist es passiert? Was war der Auslöser“ etc. Wir sehen, die W-Fragen sind eine effektive Methode schnell an zielgerichtete Informationen zu gelangen. Eine Technik, die übrigens auch im Journalismus oftmals erfolgreich eingesetzt wird. Wenn es also für die Experten der Informationsbeschaffung und Verarbeitung hilfreich ist, wieso dann nicht auch für unsere Anforderungsanalyse?

Diese Technik liegt übrigens auch den User Stories zugrunde, ist dort allerdings weniger detailliert.
„Als <ROLLE> möchte ich <ANFORDERUNG> um zu erreichen, dass <NUTZEN>„.
Dahinter stecken die Fragen Wer, Was und Warum. Diese 3 Fragen bilden auch tatsächlich den Kern unseres Modells. Doch sind sie meist nur ausreichend, wenn es bereits ausreichend Fachwissen gibt und der Projektleiter / Anforderungsmanager / Entwickler weiß, wie er das im Interesse des Kunden umsetzen kann, sodass es sich harmonisch in das Gesamtbild einfügt. Vielleicht kennt der neue Benutzer die Standardfunktionen meiner Plattform oder vielleicht erwartet er eine App. Wie wichtig ist ein stimmiges Design? Ist es für intern oder extern? Diese Fragen werden in einer User Story  nicht oder nur zufällig erfasst und umrissen. Meist benötigt man dennoch ein Rahmenwerk, welches die Umgebungsparameter erfasst und definiert. Genau hier greift das Modell der W-Fragen und erweitert die User Stories und reichert sie mit weiteren Infromationen an.

Die W-Fragen im Detail

Nun aber genug Geplänkel. Welche W-Fragen wollen wir nutzen und was erreichen wir dadurch? Fangen wir mit den Klassikern der User Story an.

Was möchten Sie tun?
Hier geht es darum den konkreten Anwendungsfall zu beschreiben. Der Kunde wird etwas sagen wie „Ich möchte einen Knopf zum Drucken haben.“ Damit ist in diesem einfachen Fall zwar impliziert was er möchte, doch es ist keine Antwort auf die Frage, was er tun möchte. Er hätte auch antworten können „Ich möchte das Gelbe Formular„. Möchte er wirklich das Formular? Oder ist damit nicht etwas anderes impliziert? Hier gilt es nachzufragen. Was genau möchten Sie tun? Oder um zur Zweiten Frage zu kommen:

Wozu möchten Sie das?
Die Frage bezieht sich auf das Was. Wir versuchen damit den Kunden zum Nachdenken anzuregen. Wozu möchten Sie das Gelbe Formular? Wir fragen hier also nach dem Zweck. Im Fall wird herauskommen, dass er eigentlich einen Passierschein A38 benötigt um eine andere Aufgabe zu lösen. Diese Aufgabe hat eine Abhängigkeit zu unserer aktuellen User Story. Aha!

Das Gleiche hätte auch beim Drucken herauskommen können. Wozu genau möchten Sie das Dokument ausdrucken? Vielleicht möchte er es archivieren oder genehmigen lassen? In beiden Fällen könnte man auch eine papierlose Alternative anbieten, welche den Prozess innerhalb der Software hält. Nur, weil er es bisher so gemacht hat, heißt das ja nicht, dass dies auch für die aktuelle Lösung der beste Weg ist. Wir sehen, schon diese beiden Fragen bringen uns wesentlich näher an das eigentliche Geschehen.

Wer tut das?
Die nächste Frage ist wieder ein Klassiker. Wer ist die handelnde Person oder Gruppe? Ist es der Manager? Oder ist es vielleicht ein Mitarbeiter im Außendienst? Vielleicht sogar ein Externer? Die Definition der Person bringt uns auch direkt die besonderen Eigenschaften des Handelnden. Der Manager ist also der Linienvorgesetzt. Sehr gut, damit kann man vielleicht schon etwas automatisieren. Der Außendienstmitarbeiter hat keinen direkten VPN Zugang, sondern muss sich Anmelden. Dann wissen wir, dass wir eine entsprechende offene Schnittstelle nach Außen brauchen. Ggf. sogar mit entsprechenden Sicherheitsmaßnahmen. Die nächste Frage schließt sich daran an.

Wie tut er das?
Was beim Außendienstler vielleicht noch intuitiv erfasst werden kann, gibt durch die Frage nach dem Wie Gewissheit. Der Außendienstler macht das beispielsweise über sein Smartphone. Entsprechend brauchen wir also eine Webseite, die mit der Darstellung auf dem Handy kompatibel ist. Oder er benötigt sogar eine App, damit gewisse Sicherheitsmechanismen auf dem Firmengerät umgesetzt werden können.

Wann passiert das?
Diese Frage gibt Rückschlüsse auf Abhängigkeiten und eventuelle wiederkehrende Ereignisse. Das Drucken der Seite passiert, wenn die Genehmigung über den digitalen Weg fehlgeschlagen ist. Ah! Das ist interessant. Hier kann man direkt die anderen Fragen wieder aufgreifen. Wieso ist es fehlgeschlagen, wie kann man es umgehen, etc. Aber in diesem Fall ergibt sich, dass es sich um einen digitalen Archivierungsprozess handelt und wenn dieser nicht funktioniert, gibt es die Handlungsanweisung das Dokument auf Papier auszudrucken und abzuheften. Eine Lösung könnte sein, dass wir das Wann verändern. Wenn der Archivierungsdienst fehlschlägt, weil er z.B. gerade gewartet wird, dann versuchen wir es nach X Minuten/Stunden erneut.

Wo passiert das?
Die Frage nach dem Ort kann wieder vielschichtig sein. An welcher Stelle soll dieser Druckknopf sein? Gibt es eventuell eine Bedingung dafür? „Wenn das Archivieren fehlgeschlagen ist, dann soll der Knopf oben Rechts erscheinen“ Oder viel plastischer, wo soll denn ausgedruckt werden? Wieder aha! Es gibt also einen Drucker in einem speziell gesicherten Archivierungsraum, in dem diese Dokumente zwischengelagert werden. Und dieser ist nur über eine ganz spezielle Schnittstelle erreichbar. Gut, wieder etwas, dass wir berücksichtigen müssen.

Wieso machen Sie es so?
Und schließlich die Ketzerfrage. Wieso gerade so? Gibt es einen zwingenden Grund dafür? Oder könnten wir es eventuell smarter gestalten? Wieso möchten Sie umbedingt, dass das Dokument per sofort und sicher archiviert ist? Vielleicht kommt heraus, dass alle paar Minuten ein Lösch-Job über fertige Dokumente läuft, da es hierfür eine gewisse rechtliche Anforderung gibt? Wäre es dann aber nicht viel sicherer, wenn der Lösch-Job den Status „Archiviert“ abfragt? Und wenn das archivieren fehlschlägt, könnte er das Dokument in einen geschützten, Bereich verschieben, auf dem es keiner einsehen kann. Dieser ist zwar kein Archiv im rechtlichen Sinne, kann jedoch als Zwischenstation genutzt werden, bis die Archivschnittstelle wieder läuft. Vielleicht ist es ja sogar sinnvoll, eine zweite, unabhängige Archivierungsfunktion zu nutzen, die in dasselbe Archiv geht? Wenn die Anforderung ein PDF-A an Ort X ist, dann könnte das ja auch durch eine andere Software bewerkstelligt werden, sofern die erste in Wartung ist. Oder wie wäre es mit zwei unabhängigen Servern, die den Dienst betreiben und nacheinander gewartet werden?

Zusammenfassung und Fazit

Wir sehen bereits anhand dieses einfachen Beispiels, welche Macht und welcher Nutzen in den W-Fragen steckt, und wie sie die User Story erweitern. In unserem Beispiel war die User Story „Als Außendienstmitarbeiter möchte ich etwas drucken können, um die Daten immer sicher abzulegen.“ Aus dieser Story haben wir durch die 7 Fragen, die natürlich auch mehrfach und mit unterschiedlicher Formulierung genutzt werden, sehr viel mehr herausgeholt. Wir wissen, es geht darum, dass ein Dokument immer verlustsicher vor einem Lösch-Job archiviert werden muss. Dieser Job ist wichtig, damit kein anderer auf dieses Dokument zugreifen kann, da es sich um eine rechtliche Anforderung handelt. Der Außendienstler muss in der Lage sein dieses Dokument auch von außen über sein Smartphone zu archivieren. Entsprechend benötigen wir eine Schnittstelle, die noch dazu abgesichert sein muss, da das Formular ja nicht in fremde Hände geraten darf. Und schließlich haben wir noch das bewährte Vorgehen hinterfragt und eine Alternative zum Ausdrucken angeboten, die nun vom Kunden bewertet wird.

Natürlich ist diese Arbeit sehr aufwendig. Wenn wir sie für jede einzelne User Story durchführen, haben wir alleine in der Anforderungsermittlung sehr viel zu tun. Doch es lohnt sich. Denn je klarer eine Anforderung ist, desto genauer können wir abschätzen, was eigentlich zu tun ist. Was dem Kunden hier wirklich wichtig ist und wo wir vielleicht nur Schleifen am Nachthemd haben. Wenn wir diesen kritischen Pfad einer Anforderung ermitteln, können wir auch leichter die Umsetzungszeit, die Testaufwände (gemessen auch an der Kritikalität) und damit schlussendlich die Kosten ermitteln. Außerdem können wir dem Kunden genau erklären was wir vorhaben und wie die Kosten zustande kommen. Die Glaskugel, mit der wir Aufwände abschätzen wird damit um vieles klarer und das Risiko für beide Seiten kleiner. Die Tiefe der Fragen und die Zeit, die wir dafür aufwenden, hängen dann natürlich wieder davon ab, wie kritisch das jeweilige Thema ist und wie der Rahmen für das Gesamtprojekt ist.

SharePoint Customizations – wann nutze ich welches (DEV)-Modell?

Ein Kollege von mir ist auf einen exzellentes Webcast von „SharePoint Patterns & Practices“ gestoßen, dass ich euch nicht vorenthalten möchte. In dem 48 minütigen Beitrag geht es darum, welche Art der Entwicklung wann Sinn ergibt. Dabei werden folgende Typen betrachtet:

  • SharePoint Farm / Sandbox solutions – WSPs
  • SharePoint add-in model
  • Single page apps / externally hosted apps
  • SharePoint Framework

Die Betrachtung richtet sich dabei nach den Kriterien Wirtschaftlichkeit, Flexibilität, Zukunftssicherheit und O365 Fähigkeit.

Das Video habe ich euch direkt eingebunden. Den kompletten Beitrag findet ihr hier: SharePoint PnP Webcast – SharePoint Customizations – When to use which model?

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.

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 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?

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