Direkt zum Hauptbereich

Projektaufwände schätzen

Wie viel muss man über eine unsichere Aufgabe (z. B. ein Projekt) vorher wissen, um dafür ein Angebot abzugeben? Wie viel Puffer muss ich aufschlagen? Eigentlich wissen wir oft mehr über diese unsichere Aufgabe als uns bewusst ist. Und dieses Wissen können wir für die Schätzung benutzen.
Anfang Juli 2015 fand das erste Mal die Konferenz "Agile Contracts" in München statt. Das war für mich eine gute Gelegenheit, anderen Beratern und Praktikern zuzuhören, wie sie mit dem Thema umgehen.

In den Gesprächen mit Kollegen und Besuchern fiel mir besonders oft auf, dass viele doch noch denken, dass man die Anforderungen für Projekte am Anfang gut erfassen kann. Die Denkweise ist folgende:
  • Um einen Auftrag zu bekommen, muss ich einen Preis nennen.
  • Um einen Preis zu nennen, muss ich wissen, welchen Aufwand ich habe.
  • Um den Aufwand abzuschätzen, muss ich wissen, wie viel Arbeit in dem Auftrag steckt.
  • Um nicht am Ende drauf zu zahlen, muss ich einen Puffer einplanen.
  • Damit der Kunde zufrieden ist, brauchen wir voher eine Liste, auf der steht, was er am Ende bekommt. Damit kann ich nachweisen, dass der Kunde genau das bekommen hat, was er bestellt hat.
Viele dieser Punkte nehmen wir als gegeben hin. Wir wissen aus Erfahrung, dass wir uns bei den Projektpreisen oft vertun. Bessere Planung hat uns nicht geholfen. Wie lösen wir also dieses Problem?

Ein guter Weg ist es, diese Annahmen einmal in Frage zu stellen. Ist der Kunde wirklich zufrieden, wenn ich ihm seine alte Anforderungsliste unter die Nase halte? Wenn nicht, liegt es an der Liste oder an anderen Dingen?

Die wichtige Annahme für diesen Beitrag ist die, dass ich den Aufwand ermitteln muss, bevor ich einen Preis nenne.

Die gleiche Annahme steht Nicht-Scrum-Teams im Weg, wenn sie ihre Arbeit schätzen müssen. Nun haben Scrum-Teams gelernt, dass sie mit relativem Schätzen sehr gut leben können. Dazu vergleicht das Team alle fachlichen Anforderungen untereinander. Wir nehmen eine Anforderung als Referenz und geben ihr willkürlich eine relative Aufwandsbewertung von 5 Punkten. Alle anderen Anforderungen werden nun nacheinander mit dieser Zahl verglichen. Im Februar 2014 habe ich schon darüber geschrieben /1/.

Das relative Schätzen funktioniert auf Aufgabenebene sehr gut. Es es ist ausreichend genau. Dadurch, dass es viele kleine Aufgaben gibt, gleichen sich Schätzfehler mit der Zeit wieder aus.

Das gleiche Prinzip können wir auch für Projekte nehmen. Wir können Daten aus der Vergangenheit nehmen und Aufwandspunkte vergeben. Dazu legen wir auch wieder eine Referenz fest: Welches Projekt steht für mittleren Aufwand? Wie stehen die anderen Projekte dazu im Vergleich?

Wenn wir vergangene Projekte betrachten, liegen uns Zahlen vor. Aber welche nehmen wir?
  • gebuchte bzw. in Rechnung gestellte Personentage oder die tatsächlich bekannte Zahl?
  • Personentage oder Kalenderzeit?
  • Interne und externe Kosten?
  • usw.
Die Werte aus der Vergangenheit helfen uns bei der Abschätzung. Zum Beispiel können Sie folgende Dinge sagen:
  • Aus der relevanten Klasse von Projekten war keines kürzer als X Tage.
  • Aus der relevanten Klasse von Projekten war keines länger als X Tage.
  • Durchschnittlich dauert diese Art von Projekten von X bis Y Tage mit einer Varianz von Z.
  • Der Fehler zwischen Vorhersage und tatsächlichen Werten beträgt von X bis Y Prozent.
Sie lernen aber noch mehr. Nehmen wir an, das Team stuft Projekt A aufwändiger als Projekt B an, obwohl in beiden die gleiche Anzahl an Personentagen abgerechnet wurde. Gemäß der Annahme von Ward und Daniel, dass Software nur einen Nutzen bringt, wenn sich Arbeitsweisen im Unternehmen ändern /2/, müsste es eine Rolle spielen, wie viele Anwender und Geschäftsprozesse von der neuen Software betroffen sind. Das bedeutet, dass in Projekt A mehr Anwender betroffen sein könnten als in Projekt B. Vielleicht ist auch die Zahl der Geschäftsprozesse unterschiedlich.

Die Art der Geschäftsprozesse müsste aus meiner Sicht ebenfalls eine Auswirkungen haben. Kernprozesse laufen häufiger ab. Da gibt es mehr Ausnahmen und damit mehr zu testen. Zudem sind die Anwender bei den Kernprozessen viel vorsichtiger, wenn es um Änderungen gibt.

Tatsächlich bestätigt die Literatur diese Annahmen. Chiara Francalanci vom Polytechnikum Mailand hat 2001 Projekte zur Einführung von SAP-R/3-System ausgewertet /3/. Darin schreibt sie zum Beispiel:
  • Die einzelnen Module haben eine größere Auswirkung auf den Gesamtaufwand als das Gesamtsystem /3, S. 41, linke Spalte, Absatz 3/. Das muss so sein, weil die Auswertung der Projekte auf Modulebene statistisch bessere Werte liefert. Wenn man nur den Gesamtaufwand betrachten würde, wäre die Streuung der Werte zu groß. Aber das ist so, weil es eben unterschiedliche Geschäftsprozesse sind. Wenn sie keine Rolle spielten, müssten Gesamtaufwand und Summe der Teilaufwänden von den gleichen Variablen abhängen. Das tun sie aber nicht.
  • Die Zahl der Anwender pro Modul spielt eine größere Rolle als die Gesamtzahl der Anwender /3, S. 41, rechte Spalte, Absatz 2/.
  • Bei den Kernprozessen ("mission critical work") bedeuten mehr Anwender auch mehr Nachprogrammieraufwand /3, gleiche Stelle/.
Relatives Schätzen auf Projektebene sollte funktionieren. Es ist besser, je mehr Projekte man als Vergleich heranziehen kann. Ich würde mindestens 5 Projekte als Vergleich heranziehen.

Um Projekte relativ zu schätzen, sollte das Team folgende Punkte berücksichtigen:

Aufwandstreiber:
  • Wie viele Anwender sollen mit der neuen Software ihre Arbeitsweise ändern?
  • Welche Geschäftsprozesse sind von der neuen Software betroffen? 
  • Sind dies Kernprozesse?
Unsicherheitstreiber (nach Shenhar/Dvir):
  • Hat der Kunde, haben die Anwender schon ein vergleichbares System im Einsatz?
  • Wie gut kennt sich das Team mit den Technologien aus, die im neuen Projekt zum Einsatz kommen sollen? Wie gut kannte es sich bei den Vergleichsprojekten damit aus?
  • Wie stark ist die Abhängigkeit von anderen Lieferanten oder Abteilungen?
  • Wie hoch ist der echte Zeitdruck?
Die Aufwandstreiber geben einen Hinweis auf die zu erwartende Anzahl der Personentage (im Vergleich zu den anderen Projekten). Die Unsicherheitstreiber geben einen Hinweis auf die Puffer, die ich wegen der Unsicherheit einplanen muss, um rechtzeitig fertig zu sein.

Letztendlich ermitteln Sie damit nicht die Kosten für das Projekt, sondern ein realistisches Budget, das der Kunde für sein Projekt einplanen sollte. Hinzu kommt für den Kunden der interne Aufwand. Für SAP-Projekte habe ich bei Zahrnt /4, S. 183/ das Verhältnis von 1 Beratertag zu 1,6 interne Tage gefunden. Das Projekt sollte dafür sorgen, den 2-3fachen Wert wieder einzuspielen. Rechnen wir das mal durch:
  • 25 Beratertage à 1.000 EUR (25.000 EUR)
  • 40 interne Tage à 500 EUR (20.000 EUR)
  • Summe: 45.000 EUR

Um zu bewerten, ob Ihr Preis von 25.000 EUR ein gutes Angebot ist, sollte sich der Kunde fragen, wie wahrscheinlich es ist, dass er nach dem Projekt 90 - 135 Tausend EUR in einer angemessenen Zeit einspielt.

Nutzen Sie doch mal die nächste Teamsitzung dazu, um Referenzklassen für Ihre Projekte bilden.

Sie wollen mehr über gute Projektarbeit lernen? Es gibt eine Übersichtsseite zum Thema Projektmanagement in diesem Blog. Dort finden Sie weitere Artikel, mit denen Sie sich in das Thema einlesen können.

Anmerkungen

  • /1/ Jan Fischbach: Wann sind Sie mit der Arbeit fertig? Wie man seine Abarbeitungsgeschwindigkeit (velocity) ermittelt?, Teamworkblog, erschienen am 01. Februar 2014, abrufbar unter http://www.teamworkblog.de/2014/02/wann-sind-sie-mit-der-arbeit-fertig-wie.html
  • /2/ Ward, John ; Daniel, Elizabeth: Benefits Management : Delivering Value from IS and IT Investments. 1. Auflage. New York: Wiley, 2006.
  • /3/ C. Francalanci. Predicting the implementation effort of ERP projects: empirical evidence on SAP/R3. Journal of Information Technology, 16:33–48, 2001.
  • /4/ Zahrnt, Christoph: IT-Projektverträge: Erfolgreiches Management. 1. Aufl.. Ort: dpunkt.Verlag, Heidelberg, 2009

Kommentare

Beliebte Posts aus diesem Blog

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.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Den passenden Job finden

Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

Die Microsoft Teams-Not-To-Do-Liste

Viele hoffen, dass es  für die Einrichtung von Microsoft Teams  den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

Agilität ist tot. Ausgerechnet jetzt?

Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

Wie beschreibt man einen Workshop für eine Konferenz?

Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

Gemeinsam eine Anwenderdokumentation erstellen

Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch machen?

Der Softwareeisberg, die Softwarepyramide - Wie sprechen wir über neue Software?

Software ist aus den Geschäftsprozessen vieler Unternehmen nicht mehr wegzudenken. Sie verwaltet Kunden- und Produktdaten. Sie automatisiert Abläufe und verhindert Fehler. Aber Software veraltet. Was machen wir, wenn wir Unternehmenssoftware erneuern müssen? Von den ersten Konzepten bis zum ersten Release ist es ein weiter Weg, mit vielen Entscheidungen. Wie sprechen wir über diese Entscheidungen?