Aufwandsschätzungen – Die Ausgangslage für erfolgreiche Projekte (Teil 2 / 2)

Im ersten Teil ging es um das Grundverständnis bei Aufwandsschätzungen. Der zweite Teil bezieht sich jetzt auf die Vorgehensweise zur Erstellung einer Aufwandsschätzung und welche alltagstauglichen Verfahren eingesetzt werden.

Vorgehensweise zur Aufwandsschätzung

Einer der ersten Schritte für die Aufwandsschätzung besteht darin, das Projekt in „handliche“ Arbeitspakete zu strukturieren. Die Aufteilung in Arbeitspakete kennt man auch unter dem Begriff Work Breakdown Structure (WBS).

Die gewählte Grösse der Arbeitspakete ist dabei noch relevant. Zu grosse Arbeitspakete lassen die Schätzungenauigkeit und das Risiko, dass etwas vergessen geht, steigen. Arbeitspakete welche grösser als 20 PT (Personentage) sind deuten darauf hin, dass diese zu gross gewählt wurden und eventuell weiter unterteilt werden sollten.

Im Gegenzug sind zu fein gewählte Arbeitspakete ebenfalls nicht das „Gelbe vom Ei“. Schnell entsteht bei zu granularen Arbeitspaketen ein hoher Aufwand zur Bearbeitung der Schätzung und es entstehen versteckte Puffer welche die Projektplanung verfälschen können. Man sollte also die Arbeitspaketgrösse bewusst wählen.

Ein weiterer wichtiger Punkt, welcher leider häufig ausser Acht gelassen wird, ist die Projektphase in welcher die Schätzung stattfindet. Dabei muss man wissen, dass die Schätzunsicherheit im Laufe des Projektfortschrittes naturgemäss abnimmt. Ist einem grob die Schätzunsicherheit bekannt, kann man in der Projektplanung dementsprechend mit klar kommunizierten Pufferzeiten reagieren.

Diese Schätzunsicherheit (oder der Verlauf der Schätzunsicherheiten im Projekt) wird auch als Cone of Uncertainty bezeichnet und stellt die Schätzunsicherheit bezogen auf den Projektverlauf grafisch dar.

Cone of Uncertainty

Cone of Uncertainty (Quelle: McConnell, Software Estimination, Seite 28)

Auf dieser Darstellung sieht man sehr schön, dass die Schätzunsicherheit nach der Phase Designerstellung sich stark verkleinert hat, es existieren zu diesem Zeitpunkt also bereits sehr viele detaillierte Informationen zum Projekt welche eine Überprüfung der durchgeführten Schätzungen für die Folgephasen durchaus Aussagekräftiger erscheinen lassen wird.

Eine kontinuierliche Überprüfung und ein Abgleich mit der Planung ist dadurch eine wichtige Projektmanagement Aufgabe.

(mehr …)

Aufwandsschätzungen – Die Ausgangslage für erfolgreiche Projekte (Teil 1 / 2)

Aufwandsschätzungen gehören zu unserem täglichen Brot und dienen als Start für potentielle Projektaufträge. In diesem Blogpost wird aufgezeigt, warum das Thema Aufwandsschätzung elementar wichtig ist und dies eine der Grundlagen für erfolgreiche Projekte bildet.

Eine sorgfältig durchgeführte Aufwandsschätzung bildet die Basis für eine seriöse Projektplanung. Eine gute, und damit ist eine möglichst realitätsnahe Aufwandsschätzung gemeint, kann den Projektpartnern unangenehme Budgetdiskussionen während der Projektlaufzeit ersparen. Zusätzlich wird die Qualität des Projektmanagements (Erstellung einer möglichst zuverlässigen Projektplanung) deutlich verbessert.

Zu hohe und unrealistische Schätzungen können dazu führen, dass ein Projekt nicht durchgeführt wird. Hingegen führen zu niedrige Schätzungen ziemlich sicher dazu, dass die Qualität leidet, der Termin nicht eingehalten werden kann und das Budget überzogen wird, Zustände die keiner der Projektpartner sich wünscht.

Warum werden überhaupt Schätzungen benötigt?

Diese Frage hört sich im ersten Moment relativ einleuchtend an. Geht es doch im Wesentlichen darum, herauszufinden wie viel Geld eine gewünschte Anforderung kostet.

Es geht aber noch um mehr:

  • Erst auf Basis einer Aufwandsschätzung kann eine Beurteilung zur Durchführbarkeit eines Projektes stattfinden. Dies betrifft den Kostenumfang, die benötigte Zeit, Terminplanung und Mitarbeiterplanung. Kurz gesagt bilden diese Informationen die Entscheidungsgrundlage ob ein Projekt durchgeführt wird oder nicht
  • Die Aufwandsschätzung dient der Preiskalkulation und Offert- / Angebotserstellung
  • Für die Projektplanung ist die Aufwandsschätzung das wichtigste Fundament. Beinhaltet eine Schätzung zu hohe Abweichungen von der Realität, kann die Projektplanung (Zeit, Kosten, Leistungen) nicht stimmen
  • Die Schätzung dient der Ressourcenplanung und ermöglicht dadurch die Erstellung einer Umsetzungsplanung
  • Zu guter Letzt bilden Aufwandsschätzungen die Grundlage um Priorisieren zu können. Also Entscheidungen treffen zu können, welches Projekt vorrangig umgesetzt werden soll

Social Business auf der JiveLive Tour

Foto von der JiveLive Tour.

Gestern nahm ich an der JiveLive Tour in Frankfurt am Main teil. Das Thema war Social Business und wurde vorgestellt mit Erfahrungsberichten von Jive Kunden sowie einer Live Demo des Produkts. Darüber hinaus bot die Veranstaltung eine gute Möglichkeit, Kontakte … Weiterlesen

Agile Migration

Vom Plan zum Projektbetrieb

Auch für Migrationsprojekte ist klassische Projektplanung mit Meilensteinen, Aktivitäten und deren Abhängigkeiten unerlässlich. Man sollte sich jedoch bewusst machen, dass hier ein neues System entwickelt wird, während das Alte noch läuft und Veränderungen unterworfen ist. Da i.d.R. das neue System … Weiterlesen

CMS-Migration – Das Projekt planen

Rollout-Strategie Big Bang, zweistufig

Content-Freeze und Code-Freeze Wie bei den meisten IT Projekten bestehen bei einem Migrationsprojekt ebenfalls viele Abhängigkeiten und Rahmenbedingungen, die eine sorgfältige Planung erfordern. Hinzu kommt jedoch, dass bei Live-Gang des neuen Systems ein Zeitraum entsteht, in welchem keine Änderungen an … Weiterlesen

Vortrag in Zürich: SEO-Projektmanagement

2011-12-16 12.03.13 pm

Am 06.12. konnte ich beim Internet-Briefing in Zürich die schlimmsten SEO-Fehler vorstellen und vier Ansätze und Methoden zeigen, die diese Fehler heilen. Im Folgenden findet sich eine kurze Zusammenfassung des Vortrags sowie der Foliensatz. Weiterlesen

Goldene Regeln des Projektmanagements

Jaja, es gibt sie wie Sand am Meer, die goldenen Regelen. Dies soll aber nicht Inhalt dieses Beitrags sein. Vielmehr geht es um die praxisnahe Darstellung der wichtigsten Dinge, die einem Projektleiter in der täglichen Arbeit begegnen. Diese habe ich ausführlich auf meinem Blog aufgeführt. Hier eine kurze Übersicht:

  • Sag mir, wie Dein Projekt anfängt und ich sage Dir, wie es aufhört.
  • Komplexität kann man nicht reduzieren, indem man vereinfacht, sondern nur, indem man versteht.
  • Projekte werden durch motivierte Menschen erfolgreich – daher behandle sie gut!
  • Eine pragmatische Vorgehensweise kann flexibel auf Projektänderungen reagieren.
  • Projektarbeit muss phasenübergreifend stattfinden.
  • Fit to Budget.
  • Organisation ist das halbe Leben – zielorientierte Organisation ist aber effizienter.
  • Papier ist zwar geduldig – aber auch beständig!

Ich freue mich auf eine rege Diskussion!

Workreporting 2.0 mit ReportNow

„Feierabend, alle Bugs behoben und alle Change Requests sind eingecheckt, der Zug nach Hause fährt in 5 Minuten – und schon wieder keine Zeit, die tägliche Projekt-Stundenerfassung zu erledigen. Morgen wird der Projektleiter erneut auf der Matte stehen und meine fehlenden Reports eintreiben, um die monatliche Verrechnung und das Projektreporting gegenüber dem Kunden zu erledigen. Das muss doch auch einfacher und schneller gehen!“

Genau das haben wir uns auch gesagt und kurzum eine Web-Applikation entwickelt, die folgende Bedürfnisse abdeckt:

  • Zeiterfassung komfortabler machen
    > Rasch & bequem
  • Unabhängigkeit fördern
    > Örtlich (mobil)
    > Software Client
  • Business
    > Alle Stunden lückenlos im Projektmanagement-Tool erfasst

Die entwickelte Applikation weist folgende Merkmale auf:

  • Browser-Applikation, für iPhone optimiert
  • Live Datenschnittstelle zu Projektmanagement-Tool
  • Geführte Auswahl von Kunden über deren Projekte, Tasks und Zeit zur Workreportbeschreibung
  • Visualisierung des persönlichen Tagestotals/-Soll
  • Länderübergreifend (CH/DE)
  • Ajax Technologie (keine Page Reloads)

Somit steht einer zeitnahen und mobilen Stundenerfassung nichts mehr im Wege.

Da es sich um eine interne Anwendung handelt, haben wir zur Veranschaulichung nachfolgenden Screencast vorbereitet.

ReportNow wurde im Rahmen des Namics.Lab 2009 im Team Andi in zwei Tagen entwickelt und erweitert die NOW-Familie um eine weitere Anwendung (vgl. RoomNOW).

Das Lab-Entwicklungteam bestand aus den Personen Markus Koller, Alexander Maier, Ben Roberts, Patrick Graf und Andri Stoffel.

Collaborative project management mit LiquidPlanner

Die Möglichkeiten von eCollaboration und Web 2.0 werden auch sehr häufig für die Abwicklung von Projekten genutzt (project collaboration), sei es als Anpassung einer Plattform wie Sharepoint oder Confluence oder als spezifische project collaboration Software wie z.B. projectInsight .

Im Bereich Projektmanagement werden diese Möglichkeiten noch sehr wenig genutzt bzw. es gibt sehr wenige Systeme, welche Collaborative Project Management oder Project Management 2.0 explizit unterstützen.

Systeme wie ProjectInsight bieten zwar webbasiertes Projektmanagement an, aber gehen noch von einem herkömmlichen Projektmanagement-Ansatz aus. In den verbreiteten project collaboration Plattformen wird das das eigentliche Projektmanagement auf einzelne Aspekte (z.B. dezentrale Kommunikation und Information oder dezentrale inhaltliche Abstimmung) reduziert.

LiquidPlanner ist hier eine erwähnenswerte Ausnahme.

Mit LiquidPlanner werden Projekte nicht zentral von einem Projektleiter geplant, sondern alle Teammitglieder tragen zur Planung bei. Sie können Tasks erfassen und anders anordnen, können Tasks kommentieren und ändern.
Für die Aufwandschätzung werden minimale und maximale Werte erfasst und die Termine werden aufgrund der Ressourcenverfügbarkeit und Priorität gerechnet, sofern keine Start- und Endtermine erfasst werden. Die Priorität wird aufgrund der Reihenfolge der Tasks berechnet.

Aufwandsch%C3%A4tzung.JPG

Liquidplanner kalkuliert auf dieser Basis die wahrscheinlichsten Aufwände und Termine, was in einem statisch korrektem Projektplan resultiert.
Sehr interessant finde ich, dass richtige Schätzungen abgegeben werden, d.h. Wertebereiche und keine Einzelzahlen.

Liquidplanner benutzt diese Werte und errechnet die Wahrscheinlichkeiten für das Einhalten dieser Schätzungen. Dabei wird davon ausgegangen, dass die Wahrscheinlichkeiten normalverteilt sind.

i-98a15fb660e838b32cce481df473f9aa-Normalverteilung.JPG

Leider kann diese Glockenkurve nicht verändert werden. In der Realität dürften die Wahrscheinlichkeiten eher eine schiefe Verteilung haben.

Kill the Messenger!

Remember the first time your son or daughter held a helium balloon in his hand? What happened? Sooner or later, that balloon got away and s/he was very unhappy, to say the least. One might even say, traumatized. Why? Because s/he lost the balloon? That’s certainly part of the answer, but it’s not the whole story — kids lose things all the time, without the emotional trauma of that first balloon.

That balloon’s flying away contradicted „years“ of experimental evidence (generally obtained using food from the kitchen table) that things always fall down. Always. Dependably. Reliably. Certainly. Despite this certainty, that balloon fell up. The world is not in order. And that is what was so disturbing.

So you have just started using Scrum to manage your first development project. You have 6 months to complete the project. The remaining effort on your project is estimated to be 600 Story Points (SP), which means you have to complete 100 Story Points per month. So far, so good.

Then your team executes its first Sprint and completes 50 Story Points. At this rate, it will take 12 months to finish the project ( 600 SP / 50 SP per Month = 12 Months). So you tell your boss you have a problem, you’re going to be 6 months late, on a six month project. What does you boss do?

  • Kill the messenger (what else?)
  • If that fails, blame the methodology (which is kind of the same thing).

Why is he reacting this way? For him, a balloon is falling up. Typically, early in a project, everyone is optimistic.Serious problems only become apparent later in the project, shortly before a major development milestone. So when a deadline problem escalates, it is serious and doesn’t leave much room to maneuver.

BTW — yes, I have had the pleasure of taking over a project in which the program manager had invested a large sum, only to be told shortly before the target date that it will cost another equally large sum to finish the project. Bad thing. No fun for anybody involved. And the program manager really only had two alternatives: Cough up the money or cancel the project. Either way, he had to explain it to his management (and is not going to look good in the process).

Come back to our Scrum example. Probably this program manager had never gotten such early warning that project was having problems. So how is he going to react? Exactly as he has been conditioned to through every other project that has been late, only more so, because if a warning occurs this early, something must be seriously wrong.

But wait! Only 1 month has gone by. The are still 5 months to go. You can react. You can identify the problem and make adjustments. Why is the development proceeding so slowly? Are there enough people? Are they the right people? Maybe you can reduce the scope and still achieve your business goals. Maybe your developers are being distracted by other tasks. There are a lot of ways to fix a project with over 80% of the time remaining.

Together with the Product Owner, the Scrum Master and other management can take action to correct the problem early and effectively.

Once management has learned that they have control, can react and can prevent disaster long before it occurs, they will no longer be tempted to kill the messenger. In fact, they will welcome the messenger and appreciate the methodology, because early warnings will ensure that management looks good when the project comes to a successful and timely conclusion.

Seite 2 von 3123