In der Projektanbahnung stoßen Projektleiter oft auf ein kleines Dilemma. Der pragmatische Sponsor hat nicht nur das nötige Budget, sondern oft auch schon eine konkrete Vorstellung von der Lösung. Diese soll jedoch eigentlich erst im Projekt erarbeitet werden. Wohl dem Projektleiter, der die gegebenen Ziele in eine Hierarchie überführt.
Quo vadis, Projektleiter?
Um in einem Projekt sagen zu können wo die Reise hingeht, empfiehlt es sich zunächst mal gewisse Anforderungen zu definieren, welche die Lösung erfüllen soll. Eine Anzahl dieser kommt oft schon vom Sponsor. Dazu können – müssen aber nicht – Restriktionen zu Zeit, Budget und Scope gehören. Diese Art von grundlegenden Projektzielen (erreiche X bis zum Termin Y mit einem Budget von Z) sind teils verbindlich, teils Leitlinien um eine grobe Richtung abzustecken.
Hinzu kommen zahlreiche Stakeholder aus dem Umfeld des Projekts, seien es Führungskräfte aus betroffenen Fachbereichen oder auch Mitglieder des Steering Committees. Diese haben oft auch schon konkrete Vorstellungen davon, was das Projekt erreichen soll. Hierbei dreht es sich oft um zeitliche Erwartungen, oder beispielsweise um einen bestimmten Länder-Scope für internationale Rollouts. Insbesondere diesen Kollegen wird man nur sehr vorsichtig widersprechen, aber man sollte tunlichst darauf achten die Konsequenzen aufzuzeigen die eine mögliche Entscheidung zur Folge hat.
Nicht zuletzt ist auch das Projektteam – eingeschlossen Ihrer Person als Projektleiter – vollgeladen mit Erwartungen an das Projektergebnis. Diese drehen sich oft eher um fachliche Eigenschaften der angestrebten Lösung. Die Vorgaben sind auf keinen Fall weniger wichtig zu nehmen als jene des Sponsors oder der Führungskräfte. Schließlich erleichtert Einigkeit an dieser Front später die Akzeptanz und die Motivation der Spezialisten ganz erheblich.
Doch was nun tun mit all diesen Ideen, Wünschen, Vorgaben und Hoffnungen?
Haben wir noch nie gemacht!
Wahlweise können Sie damit natürlich gar nichts tun. Sie ahnen sicher schon, dieser Blogbeitrag würde nicht existieren – oder sehr viel kürzer sein – wenn das meine Empfehlung wäre. Wenn Sie die Anforderungen vernachlässigen riskieren Sie einen ganzen Sack voller Probleme die Ihnen im schlimmsten Fall Ihr Projekt kaputt machen können.
- Unklare Zielvorstellungen .. es ist nicht – oder nicht für alle – klar wohin die Reise grundsätzlich geht
- Schlechte Qualität .. Anforderungen sind qualitativ schlecht beschrieben
- Hohe Komplexität .. Anforderungen sind gut beschrieben, aber zu komplex für den gesetzten Scope
- Veränderliche Anforderungen .. Veränderungen von Anforderungen geschieht ungeregelt (ja, Scope Creep, I’m looking at you!)
- Sprachbarrieren .. die Beschreibung der Anforderung passt inhaltlich, aber nicht sprachlich
- Informationsverlust .. durch unsaubere Methoden werden Anforderungen oder deren Teile nicht vollständig abgebildet
Ordnung in das Chaos
Um diese Punkte zu adressieren braucht es gar nicht viel – ein wenig organisatorisches Geschick reicht für die allermeisten Projekte aus, um die Anforderungen ausreichend klar abzustimmen. „Ausreichend klar“ deswegen, weil immer die Größenordnung im Auge behalten werden muss: für ein kleines, lokal begrenztes Web-Projekt werden Sie die Anforderungsdefinition (und ggf. die gesamte Projektmethodik) anders wählen als für ein internationales Projekt mit Dutzenden Projektmitgliedern. Eine abgestimmte (1) Dokumentation (2.) die in Inhalt und Umfang an der Projektgröße (3.) ausgerichtet ist, rettet hier schon viele Kinder vor dem Brunnen. Ein sauberes Change Management (4.) und wiederkehrende Review mit den Anforderern (5., 6.) erledigen dann den Rest.
Es ist grundsätzlich empfehlenswert die „Wünsche“ aus dem ersten Abschnitt zu sammeln, zu bewerten und in Abstimmung mit den funktionalen und administrativen Stakeholdern zu Anforderungen zu machen. Diese definieren dann den Scope der im Rahmen des Projekts adressiert werden soll. Dazu gehört das Bewerten und Priorisieren ebenso wie das Verwerfen von Anforderungen, weil sie möglicherweise anderen Komponenten des Projekts (Zeit, Budget, Scope) nicht entsprechen.
Das kann man je nach Kunde, Projektkomplexität und PM-Methode im Unternehmen nach IEEE610 sehr strukturiert tun, oder sehr pragmatisch mit selbst gebauten Excel-Listen. Bitte unterschätzen Sie jedoch nicht die Wichtigkeit dieses Schritts, denn daran bemisst sich der Projekterfolg, und auch die Akzeptanz durch Sponsor, Führungskräfte und Mitarbeiter.
Die Kategorien die Sie bilden sind für Sie frei wählbar. Ist es beispielsweise spannend, ob es sich um eine funktionale, technische oder legale Anforderung handelt? Oder ist eher wichtig, dass Sie eine Pflicht (must-have), einen Wunsch (if possible) oder eine Absicht (future need) darstellt? Stimmen Sie sich hier mit Sponsor und Team ab, wie weit Sie ins Detail gehen wollen.
Ja, und denn?
Mit den dokumentierten Anforderungen haben Sie ein mächtiges Werkzeug für alle folgenden Projektphasen in der Hand.
Sie gehen in das Lösungsdesign mit einer abgestimmten Sicht auf den Sollzustand. Sie können jeden besprochenen Prozess, jede Funktion, jede technische Lösung auf Ihre Abbildung der Anforderungen hin prüfen. So wissen Sie im Design stets ob Sie auf dem richtigen Weg sind.
Im Build und im Test kommt Ihnen das natürlich zu Gute. Haben Sie vorher sauber alle Anforderungen abgestimmt, werden Ihre Implementierer kein Problem haben das Lösungsdesign umzusetzen, und die Tester die gebaute Lösung viel schneller akzeptieren.
Das gilt nicht zuletzt natürlich auch für die Mitarbeiter nach dem Go-Live Ihrer Lösung. Durch frühzeitige Aufnahme der Anforderungen wussten Sie schon vorab worum es den beteiligten Bereichen geht, und es gibt weniger bis keine bösen Überraschungen nachdem Sie „geliefert“ haben.
Dabei wie immer viel Erfolg wünscht,
