Grundsätzlich ist ein Projekt immer mit Kosten verbunden. Da es in wirtschaftlich denkenden Organisationen und auch gemeinnützigen Unternehmen, öffentlichen Einrichtungen oder Vereinen um Kosten und teilweise deren Nutzen/Ertrag geht, ist ein Projekt auch abhängig von ihren Kosten. Daher kommt es extrem selten vor, dass ein Projekt ohne Kostenschätzung gestartet wird.
Es gibt Vorprojekte oder Pilotprojekte, die eine Machbarkeit prüfen. Diese sind aber eher kleine Projekte, die mit der Vorgehensweise "Ausgangslage, Anforderung und Lösungsansatz" gut angegangen werden können. Hier wird oft für interne Themen ein Kontingent freigegeben, dass bis es aufgebraucht ist, genutzt werden kann und dann wird entschieden, ob und wenn ja, wie es weiter geht.
In grösseren Projekten, oder bei externer Vergabe eines Pilotprojekts muss also sehr oft der Aufwand geschätzt werden.
In den Phasen eines Projekts kann immer konkreter geschätzt werden. Das heisst umgekehrt, dass am Anfang eines Projekts die Schätzung sehr vage, oder grob ist und noch nicht für alle Schritte vorhanden ist.
- Im Projekt SetUp kann maximal ein Kontingent für die ersten konzeptionellen Phasen oder das Gesamtprojekt definiert werden. Es hat aber keine inhaltlichen Begründungen. Oftmals wird ein Kontingent aus Erfahrung angegeben, das später mit mehr Informationen bestätigt oder aktualisiert wird. Eine belastbare Schätzung ist hier noch nicht möglich.
- Nach dem IST verstehen sind die Prozesse und deren Verbesserungsanforderungen klarere und das Kontingent kann mit dem neuen Wissen angepasst werden. Eine belastbare Schätzung ist hier noch nicht möglich.
- Nach dem Soll definieren ist das Zielbild formuliert. Hier kann ein erstes Budget mit Kostentreibern und einer recht hohen Varianz erstellt werden. Eine belastbare Schätzung ist hier bedingt mit einem grösseren Risiko-Aufschlag möglich.
- Nach dem Übersetzen in Systeme ist je nachdem, wie genau diese Phase durchgeführt wird, eine mehr oder weniger genaue Schätzung möglich. Hier sind die Use-Cases mit ihren Abläufen formuliert und es können Bottom-Up die Anforderungen in den Systemen auch hier noch grob bewertet und geschätzt werden. Zudem muss ein Risiko-Aufschlag auch hier berücksichtigt werden. Ist kein Risiko.-Aufschlag gewünscht, muss das Projekt in der Umsetzung als ein Wasserfall Projekt realisiert werden, und das Lösungs-Konzept alle geforderten Schritte und deren Funktionalität beinhalten. Davon wird in der aktuellen Arbeitswelt aber immer mehr Abstand genommen und die Umsetzung so agil wie möglich gestaltet. Der Nachteil liegt genau hier in der nicht klaren Schätzung.
- In der Phase Umsetzung von Grob nach Fein sollten keine neuen Aufwände entstehen. Es kann aber sein, dass neue Anforderungen während der Projektlaufzeit oder neue Erkenntnisse bei der Umsetzung aufkommen, die berücksichtigt werden sollten. Auch kann es sein, dass eine Umsetzung doch komplexer ist, als initial geplant und der Aufschlag für agile Arbeit nicht ausreicht. Auch hier sollte es Spielraum geben, wenn sich ein Mehraufwand nicht mit einem Minderaufwand aus einem anderen Bereich ausgleicht. Kommen neue Themen dazu, oder sind Themen komplexer, sollte Änderungsanfragen für das Budget vorgenommen werden.
- Bei der Integration und dem Anwenden sollte es keine Änderungen oder Erweiterungen geben, die Auswirkungen auf das Budget haben. Daher sollte auch ein Änderungs-Stopp in der Phase Umsetzung von Grob nach Fein festgelegt werden.