Direkt zum Hauptbereich

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?


Kommentare

Beliebte Posts aus diesem Blog

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

"Denn sie wissen nicht was sie tun ...! Freigeben und teilen in OneDrive und SharePoint und per E-Mail

Neuerdings können Sie bei Ihren E-Mails entscheiden, ob Sie den Anhang als Datei (Kopie) anhängen wollen oder einen Link senden. Doch was kann dieser Link? Wie sicher ist er? Wer kann was damit tun? Lesen Sie hier was sinnvoll ist und was weniger.