Meist ist eine Schätzung von Entwicklungsaufwänden und vor allem Entwicklungskosten einfach eine Zahl, welche für die Planung gebraucht wird, d.h. als Grundlage von Entscheiden. Die Zahl kann gebraucht werden als Grundlage für eine Kostenrechnung, als Grundlage einer Time-to-Market Planung oder gar, um die Investition in die Produktentwicklung vor dem Verwaltungsrat oder Investoren zu rechtfertigen.
Leider hat diese eine Zahl eine Geschichte. Dieser Hintergrund wirkt sich auf das Vertrauen aus, welches man in die Zahl haben kann. Das Vertrauen hängt von zwei Faktoren ab:
Es wäre also angemessen, die Zahl mit einem Disclaimer zu versehen, der aussagt:
Wenn der Geschäftsleiter z.B. die erste, intuitiv optimistische Schätzung vom Produktmanagement-Workshop für seinen Business Case verwendet, dann kann er fast sicher sein, dass er mit einem um Faktoren höheren Budgetnachtrag nochmals eine Präsentation halten darf...
Daher lohnt es sich, vor der Verwendung des geschätzten Projektaufwandes in Entscheiden nachzufragen, woher die Schätzung kommt, wie sie entstanden ist und auf welchem Informationsstand sie beruht. Und es auch auszuhalten, wenn der neue Informationsstand eine Schätzung hervorbringt, bei der der Business Case nicht mehr so rosig aussieht. Wobei sich dann die Frage stellt, ob es nicht besser ist, dass jetzt eine realistischere Schätzung auf dem Tisch liegt als später eine massive Budgetüberschreitung?
Eine Schätzung ist immer mit Unsicherheit behaftet. Je weiter weg z.B. das Ende des abzuschätzenden Projektes liegt, desto grösser ist die Unsicherheit, d.h. die rechte Öffnung des Trichters. Was heisst das nun für die Planung? Einen Teil der Unsicherheit kann man mit systematischer Schätzung einfangen. Den Rest kann man einerseits in die Planung einbeziehen, andererseits kann man nach einiger Zeit eine neue Schätzung machen, welche dann genauer sein sollte.
Der Grund für diesen Trichter sind die Risiken, welche in jedem Projekt stecken:
Die Risiken, welche das Projekt beinhaltet, ergeben auch die Weite des Trichters in der Zukunft: je weniger Risiken ein Projekt birgt, desto genauer kann ich schätzen.
Viele Schätzungen beginnen ihr Leben als dahingeworfene Zahl an einer Sitzung, als erste Grössenordnung, meist mit grossem Optimismus. Diese Zahl sollte nicht als Versprechen für den Aufwand des Projektes genommen werden.
Wenn wir als Solcept wirklich ein Versprechen abgeben (z.B. wenn wir einen Fixpreis anbieten), dann treiben wir ziemlich viel Aufwand, um eine genügende Genauigkeit zu erreichen, z.B. führen wir eine System Design Phase durch und eine strukturierte Schätzung.
Wieso tun wir das? Weil wir damit die Risiken eingrenzen:
Wenn Sie am Anfang eines Projektes doch schon eine Schätzung haben möchten, dann führen wir eine Grobschätzung durch, basierend auf den gewünschten Funktionen oder Annahmen darüber und unseren Erfahrungswerten für Dokumentation, Test und Integration.
Nach der System Design Phase, in der eine Systemspezifikation und eine Systemarchitektur entstehen, können wir eine Projektschätzung durchführen, zumindest über den Teil, der schon klar ist. Diese ist bedeutend genauer. Jede nächste Phase kann dann so geschätzt werden, sobald der Umfang der Phase (d.h. die Anforderungen, welche das Produkt nach der Phase erfüllen soll) klar ist.
Es gibt verschiedene Gründe, wenn Schätzungen "nie" stimmen:
Wir finden, dass Sie nie ein Abschätzung (ob intern oder von externen Lieferanten) einfach als Zahl hinnehmen sollten. Hinterfragen Sie diese: ist es ein Wunsch, eine wirklich fundierte "bottom-up" Abschätzung oder eine politisierte Zahl?
Andreas Stucki
Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!
Projekte? Ideen? Fragen? Machen wir einen kostenlosen Erst-Workshop!
Keine Kommentare