Aufsetzen eines neuen Projektes - 4 Vorschläge um die größten Nachteile zu vermeiden

Als Dienstleistungsunternehmen ist es täglich Brot sich mit Kundenanforderungen, neuen Projekten und Kundenanfragen auseinanderzusetzen. Häufig ist es so, daß sich der Kunde mit einer Projektidee, einem Problem an den Dienstleister wendet und dieses gelöst haben will. Er braucht auch früh einen Indikator, was ihn das Ganze kosten würde bzw. wann das Projekt denn fertig sein wird. Er muss ja das Budget bereit stellen, Stakeholder Management betreiben und wissen, ab wann er einen Nutzen aus dem Projekt ziehen kann.

Ansatz für das Schätzen: das Expertenteam

Ein häufig gewählter Ansatz um die Frage nach dem "Wieviel" und "Bis Wann" mit dem Kunden zu klären, ist das Expertenteam: Ein Team von 2-3 Fachexperten des Dienstleisters setzen sich mit dem Kunden zusammen:

• Sie "klopfen" Anforderungen ab, 
• Schätzen (grob) den Aufwand, und 
• Entwerfen eine erste Lösungsskizze. 
• Vielleicht wird sogar der eine oder andere Prototyp entwickelt. 
• Annahmen werden bei der Abschätzung dokumentiert. 
• Ein Projektplan wird erstellt. 
• Phasen und Arbeitspakete werden abgeschätzt und ein Meilensteinplan mit Gantt-Chart gezeichnet.

Zum Schluss wird noch errechnet, wieviele Personen man braucht um die Arbeitspakete abzuarbeiten. Als Ergebnis kann man einen Budget- und Zeitrahmen definieren. 

Dieser wird nochmal mit dem Kunden durchgesprochen. Ggfs. erfolgen noch Anpassungen an den Annahmen. Ein Werkvertrag wird aufgesetzt und nach der Vertragsunterschrift wird das Projekt inkl. Abschätzung an ein anderes  Projektteam übergeben. 

Es kann losgehen! Das neue Projektteam fängt an zu arbeiten. Das Expertenteam kann sich um die nächste Anfrage kümmern.

Expertenteam schätzt während der Vor-Projektphase;
Nach Vertragsunterschrift erfolgt die Übergabe an Projektteam

Erfahrungen

Auf den ersten Blick ist der Expertenteam Ansatz goldrichtig! Der Kunde bekommt einen Vertrag, der ihm anscheinend liefert was er haben will. Er kann das Budget bereitstellen. Er weiss auch, wann das Projekt beendet sein wird. Ideale Welt!

Aus meiner Erfahrung kann dieser Ansatz bei einfachen Projekten sehr wohl funktionieren. Man sollte sich aber der Nachteile bewusst sein, die dieser Ansatz bei komplexen Projekten mit sich bringt:

Nachteil 1: Kundenanforderungen - Doppelt und dreifach erklären

Der Kunde hat seine Anforderungen bereits dem Expertenteam mitgeteilt: Er hat diese erläutert, er hat Beispiele ausgearbeitet, er hat dem Dienstleister Formulare und Gegenstände gezeigt, die seine Problemstellung untermauern.

Problem: Wenn jetzt nach der Vertragsunterschrift das Expertenteam das Projekt mitsamt seiner „Abschätzung“ und seinem „Werkvertrag“ an ein neues Projektteam zur Entwicklung übergibt, die das Ganze „nur noch umsetzen müssen“, dann muss der Kunde diesem neuen Projektteam wieder alles von vorne erzählen.

Egal wie ausgefeilt ein Übergabeprozeß vom Expertenteam an das neue Projektteam auch aussehen mag: Er wird meines Erachtens nie ganz das Wissen übermitteln übergeben können, welches sich das Projektteam angeeignet hätte, wenn es von Anfang an mit dabei gewesen wäre.

Nachteil 2: Erkenntnisse aus Prototypen-Bau - Nichts wie weg damit!

Vom Expertenteam werden (sofern Zeit und Budget es erlauben) Anforderungen vom Kunden „prototypisch“ umgesetzt. Dieses Umsetzen ist gut! Es hat das Ziel Unsicherheiten in Bezug auf Anforderungen zu klären oder zu verdeutlichen. Der Kunde gewinnt schneller einen Eindruck, wie eine Lösung für sein Problem aussehen könnte. Das Expertenteam gewinnt Sicherheit bei der Frage der technischen Machbarkeit.

Prototypen sind allerdings keine fertige Software. Sie werden erstellt um Erkenntnisse zu gewinnen. Danach werden sie nicht mehr benutzt. Daher sollen sie auch möglichst einfach und schnell zu erstellen sein.

Problem: Bei der Übergabe des Projektes vom Expertenteam an ein neues Projektteam werden die Erkenntnisse und die Erfahrungen nicht weitergegeben! 

• Weiss das neue Projektteam, warum der Prototyp entwickelt worden ist? 
• Welches Risiko sollte durch den Bau des Prototypen verringert werden? 
• Welchen Erkenntnisgewinn hat der Prototyp gebracht? 
• Welche Erfahrung wurde damit gewonnen? 
• Wie hat sich das im Aufwand und Projektumfang widergespiegelt?

Nachteil 3: Schätzung versus Zusage!

Das Expertenteam hat geschätzt. Es glaubt, unter bestimmten, explizit genannten oder implizit vorgenommenen Annahmen, dass sich das Projekt mit X Personentagen Aufwand realisieren lassen könnte. Daraus wurde ein Werkvertrag verhandelt. 

Vielleicht hat der Dienstleister (nach einem erfolgten Risikozuschlag) noch einen Fixpreis angeboten und dem Kunden damit den Projekterfolg zu einem bestimmten Zeitpunkt Y zugesichert (unter Angaben von Annahmen, etc. natürlich). 

Der Kunde richtet sein Budget daraufhin ein (er kennt ja jetzt die Kosten). Er richtet auch seine Aktivitäten nach dem Zeitpunkt Y aus (Mitarbeiterschulungen, interne/externe Kommunikation, organisatorisches Change-Management). Es gab ja eine „Experten-Schätzung“. Wenn die es nicht wissen, wer dann?

Problem: Das Expertenteam hat nach bestem Wissen geschätzt. Unsicherheiten können sich aber im gesamten Projektverlauf manifestieren (neue Details bei Anforderungen treten plötzlich auf, technische Schwierigkeiten bei der Umsetzung an die man nicht gedacht habt, Komplexität bei Abstimmung mit anderen Systemen; erhöhter Zeitdruck). 

• Damit können auch die Kosten X überschritten werden. 
• Der Zeitpunkt Y kann also auch nicht garantiert werden. 

Wenn diese Herausforderungen auftreten, hat das Expertenteam das Projekt schon längst übergeben. Ein neues Projektteam kämpft dann mit den Schwierigkeiten und schimpft auf die „falsche“ Schätzung, die das Expertenteam abgegeben hat.

Nachteil 4: Das Projektteam - ungeeignet um das Projekt umzusetzen? 

Das Expertenteam hat seine Arbeit gemacht: Der Vertrag ist unterschrieben. Nun muss „nur noch" das neue Projektteam das Projekt innerhalb der Zeit- und Budgetvorgaben umsetzen. Klingt einfach, oder?

Problem: Das Projektteam war nicht von Anfang an beteiligt! Es wurde nicht gefragt, was sie schätzen würden. Es bekommt ein Budget und einen Zeitrahmen „vorgesetzt“, den es jetzt auch gefälligst zu erfüllen habe. 

Der Kunde beruft sich auf das Expertenteam („Ihre Experten hatten das ja so geschätzt!“). Unerfahrenheit des Teams und/oder sich manifestierende Projektrisiken können aber dem Projektteam das Leben schwer machen. Vielleicht ist das Team auch gerade neu aufgesetzt worden? 

Allein um sich „abzusichern“, wird das Projektteam auf kleinste Änderungswünsche vom Kunden in Anforderungen oder Änderungen von ursprünglichen Annahmen achten. Diese werden dann vom Projektteam abgelehnt oder ein „Change Request“ wird verlangt. Das verschlingt Energie und frustriert das Projektteam. 

Auch der Kunde ist schnell frustriert: Detailänderungen in seinen Anforderungen kann er vielleicht erst während des Projektes erläutern. Was für das Projektteam ein Change Request ist, ist für den Kunden eine Verfeinerung des Projektumfanges! Konflikte zwischen Kunden und Projektteam sind so schon vorbestimmt.

Nachteil 5: Big-Bang Projekt-Team

Wenn das Expertenteam schätzt, dass es zum Zeitpunkt Y eine Entwicklung liefern soll, die X Tage Aufwand bedeutet kann es schnell dazu führen, dass man sofort ein neues Projektteam aufbaut, welches mehrere Dutzend Personen umfasst.

Problem: Dieser Big-Bang ist meines Erachtens fatal:

• Wie koordinieren sich die Entwickler? 
• Welche Rolle spielt der Einzelne? 
• Wie werden Erfahrungen weitergegeben? 
• Was trägt der oder die Einzelne bei?
• Was ist wichtig, was unwichtig?

Diese Teamfindungsphasen sind essentiell und können nicht übersprungen werden. Bei einem Big-Bang Projekt-Team wird aufgrund des Zeitdrucks suggeriert, dass ein großes Team sofort „produktiv“ sei. Das ist leider nicht der Fall. Dazu sind wir zu menschlich.

Vorschläge zur Verbesserung

Vorschlag 1: Übergabe vom Experten -Team an ein neues Projektteam vermeiden

Statt das Projekt zu übergeben, setzt das Expertenteam dieses Projekt selbst um. Es bildet sozusagen das (initiale) Projektteam. Im Laufe des Projektes kann es dann sukzessive erweitert werden um ggfs. fehlendes Know-How und/oder Kapazitäten zu ergänzen.

Erwarteter Nutzen

• Damit müssten die Kundenanforderungen nur einmal erklärt werden. 
• Erfahrung und persönliche Erkenntnisse aus dem Prototypenbau kann man nur begrenzt weitergeben. Wenn das Expertenteam das Projekt selber umsetzt kann dieses Wissen an neue Teammitgliedern implizit weitergegeben werden. Erkenntnisgewinne aus dem Prototypenbau werden weitergereicht.
• Das ursprüngliche Team ist motiviert das Projekt auch umzusetzen. Es kennt die Historie mit dem Kunden bzgl. Anforderungen und Annahmen.
• Neue Teammitglieder im Projektteam wären nicht frustriert, weil sie externe Vorgaben umsetzen müssten. Sie wären Teil eines Ganzen.
• Statt eines Bing-Bang Projekt Teams könnte man das Experten-Team im Laufe der Zeit skalieren.

Vorschlag 1: Das Experten-Team führt das Projekt auch durch. Es wird ggfs. durch neue Teammitglieder ergänzt

Vorschlag 2: Gestehen Sie sich ein: Projekte sind unsicher - Sie können auch scheitern

Man sollte sich eingestehen, dass Projekte auch scheitern können (wenn das Projektziel nicht mehr erreicht werden kann). Sie finden im unsicheren Raum unter hohem Risiko statt. Eine initiale Schätzung kann fundamental von den nachträglichen festgestellten Kosten abweichen (Cone of Uncertainty Nasa-Studie). Dies liegt aber nicht an einer „falschen“ Schätzung zu Beginn sondern von den immanenten Unsicherheiten in einem Projekt.

Vorschlag 3: Gemeinsame Zwischenziele von Dienstleister / Kunde, die innerhalb kurzer Zeiträume erreicht werden sollen

Kunde und Dienstleister sollten sich Zwischenziele setzen, die innerhalb kurzer Zeiträume (weniger Monate) erreicht werden sollen. Dabei fokussieren sich Dienstleister und Kunde gemeinsam auf die Anforderungen, die bis dahin erreicht werden sollen und auch (wahrscheinlich) erreicht werden können. Eine Anpassung der nächsten Zwischenziele erfolgt dann wieder gemeinsam, nachdem man transparent gemacht hat, wo man steht: 

• Brauchen wir mehr Leute?
• Passt der Aufwand? 
• Können wir das Gesamtziel des Projektes noch erreichen? 
• Müssen wir das Ziel anpassen aufgrund neuer Erkenntnisse, Anforderungen? 
• Stimmt der Zeitpunkt Y noch? 

Dies ist harte Arbeit, da man leicht der Versuchung erliegen kann einen „Schuldigen“ zu suchen, wenn Anpassungen vorgenommen werden müssen. Das artet dann auch schnell in einer „Change Request“-Orgie aus: Der Dienstleister möchte sich absichern, dass jede Änderung in Annahmen oder Anforderung auch bezahlt wird. Der Kunde auf der anderen Seite möchte einen größtmöglichen Nutzen haben und sucht die Schuld beim Dienstleister.

Vorschlag 4: Starte mit einem kleinen Team und skaliere nur dann wenn notwendig und wenn das Team eine stabile Phase zur Teamfindung gehabt hat

Starte mit einem kleinen Team. Lass es über einen kurzen Zeitraum (wenige Monate() zusammenarbeiten, ohne dass Teamänderungen erfolgen. Diese Stabilität ist wichtig für die Teamfindungsphasen. Erst nach diesem Ablauf, sollte man neue Personen hinzufügen und das Team ggfs. in 2 neue Teams teilen. Dabei gilt dann für beide neue Teams, dass sie aus „alten“ und „neuen“ Teammitglieder bestehen. 

Vorschlag 3 und 4: Setze Zwischenziele alle 3 Monate. In der Phase bleibt das Team stabil. Wenn nötig erfolgt dann die Anpassung durch neue Teammitglieder.

Zusammenfassung

Ich hoffe, daß ich ein paar Denkanstöße habe geben können, wie komplexe Projekte besser aufgesetzt  werden können. Was ist Eure Erfahrung? Könnt Ihr die Beobachtungen bestätigen? Was wurde ggfs. von Eurer Seite unternommen?