In Wasserfallprojekten schätzt man Aufwände in der Regel vor oder gleich zu Beginn eines Projektes – dummerweise ist dies dann, wenn man noch am wenigsten über das Projekt weiss. Aber auch in einem agilen Projektvorgehen verwendet man häufig immer noch viel Zeit für die Aufwandschätzung – häufig in Form von «Story Points» zu Beginn einer Iteration. Doch welchen Mehrwert bringen uns Aufwandschätzungen, zumal die Praxis zeigt, dass Aufwandschätzungen chronisch falsch sind? Was ist mit den Auftraggebern, welche gerne wissen möchten, was die neue BI-Lösung denn jetzt kosten wird? Spätestens hier brauchen wir doch sicher eine Aufwandschätzung? Raphael Branger kennt dieses Spannungsfeld nur zu gut. Erfahren Sie mehr darüber, welche gutgemeinten Absichten hinter dem Wunsch nach Aufwandschätzungen stehen. Und seien Sie gespannt, welche Alternativen es gibt, diesen Bedürfnissen gerecht zu werden und gleichzeitig den Mehrwert einer BI-Lösung zu steigern.

1. Sinn und Unsinn von
Aufwandschätzungen in BI-Projekten
Zürich-Regensdorf, 20. November, 2017
Raphael Branger
Senior BI Solution Architect, IT-Logix AG

2. SINN UND UNSINN VON AUFWANDSCHÄTZUNGEN

3. AGENDA
Teil 1: Schätzen und Alternativen dazu
Teil 2: Was braucht es, damit die Alternativen funktionieren?
Vertikale Umsetzung als Grundlage für zuverlässige Prognosen
Agile Vertragsformen

4. BISHERIGE ERFAHRUNGEN MIT SCHÄTZUNGEN
Was sind Ihre Erfahrungen mit Schätzungen?

5. ERGEBNISVERSPRECHEN
Ein Ergebnisversprechen verbindet einen Soll-Zustand, meist verbunden mit einem Budget.
«Nur wenn Sie das Ergebnis mit der Sicherheit eines meisterlichen Handwerkers herstellen können, […] weil
sie das Selbe oder zumindest sehr Ähnliches schon oft getan haben, nur dann können Sie nämlich hinreichend
genau abschätzen, ob das zur Verfügung stehende Budget ausreicht.»
Ergebnisversprechen sind stark risikobehaftet, nicht gehalten zu werden.
Hans Muster
Projektteam
«Wir liefern die 10
Reports bis in sechs
Monaten zum Preis XY.»
In Anlehnung an http://ich-verspreche.org/versprechen/

6. VERHALTENSVERSPRECHEN
Ein Verhaltensversprechen verbindet eine Tätigkeit mit Ressourcen und oder drückt einen qualitativen Aspekt
der Tätigkeit – eine «Haltung» – aus.
«Gehen Sie Verhaltensversprechen nur ein, wenn Sie der Herr über Ihre Zeit sind.»
Wie aber kommt man zu «fünf Monate» und «zwei Entwickler»?
«Wir stellen für die
nächsten fünf Monate
zwei Entwickler Full-Time
zur Verfügung.»
Hans Muster
Projektteam
«Wir versprechen, die
angefallenen Aufwände
«true & fair»
abzurechnen.»
In Anlehnung an http://ich-verspreche.org/versprechen/

7. DEFINITIONEN (1/2)
Ziel (Target): Ein gewünschter Soll-Zustand, oft verknüpft mit einer Angabe, bis wann und oder mit wie viel
Aufwand dieser Zustand erreicht werden soll.
Ablösung bestehendes BI-System bis in ca. 6 Monaten
Plattform schaffen für zukünftige Anforderungen
Plan: «Vorstellung einer zukünftigen Handlungsabfolge».
Der Plan ist nicht ergebnisoffen sondern getrieben durch das zu erreichende Ziel.
Schätzungen sind ein zentraler Input für die Planungsaktivität, dürfen aber nicht mit dieser verwechselt
werden.
Projektstart
Inception-
Phase Transition-Phase
Anfrage
erhalten
Gewünschter
GoLive-Termin
April Mai Juni Juli Aug. Sep. Okt. Nov. Dez. Jan.
Construction-Phase

8. DEFINITIONEN (2/2)
Schätzung (Estimate):
Schätzen / Schätzung:
«(ohne exaktes Messen, nur auf Erfahrung gestützt)
näherungsweise bestimmen» (Duden)
Eine Schätzung ist ergebnisoffen!
Eine Schätzung ist subjektiv.
Eine gute Schätzung:
Wenn die Schätzung +- 25% der tatsächlichen
Werte beträgt, in 75% aller Fälle.
(Source: Conte, Dunsmore, and Shen 1986, in: Steve McConnell, Software
Estimation: Demystifying the Black Art)
600
750
450

9. EIN PAAR GESETZMÄSSIGKEITEN…
Hofstadters Gesetz:
Es dauert immer länger als man
denkt, selbst wenn man
“Hofstadters Gesetz”
berücksichtigt.
Parkinsons Gesetz:
Arbeit dehnt sich in genau dem
Mass aus, wie Zeit für ihre
Erledigung zur Verfügung steht
Murphys Gesetz:
Alles, was schiefgehen kann, wird
auch schiefgehen.

10. DAS PROBLEM UND DAS DRUMHERUM
Das Problem an sich
Man kann das Problem an sich schätzen.
Das «Drumherum» dominiert oftmals aber die realen Aufwände.
Das «Drumherum» lässt sich fast nur auf Basis von Vergangenheitswerten im gleichen Umfeld schätzen.

11. VERWECHSLUNGSGEFAHR!
Schätzungen sind keine Ergebnisversprechen.
Hans Muster
Projektteam
«Wir schätzen ungefähr
2 Wochen Aufwand pro
Bericht»
«Pro Bericht werden
2 Wochen benötigt.»

12. DER AUFWAND DER AUFWANDSCHÄTZUNG
Wer ist geeignet, Aufwände zu schätzen?
Jede Stunde, welche in Schätzarbeiten investiert wird, ist eine Stunde weniger, welche für die
Lösungsentwicklung genutzt werden kann.

13. FAZIT FÜR MICH:
«Schätzungen schaffen keinen direkten Mehrwert in Ihrem Prozess, darum wollen wir Wege finden,
den Schätzprozess zu reduzieren oder wo möglich ganz darauf zu verzichten.» (Vasco Duarte)

14. ES WAR EINMAL…
Projektstart
Inception-
Phase Transition-Phase
GoLive-Termin
Construction-Phase

15. BEDÜRFNISSE
Budget muss bewilligt werden – vor dem Projekt…
Bedürfnis nach Sicherheit, dass das Altsystem
rechtzeitig abgelöst werden kann.
Hans Muster
IT-Logix Operations
Welche Berater mit welchem Skillset müssen in
welchem Zeitraum zur Verfügung stehen?

16. BEDÜRFNISSE
Wie sind wir unterwegs?
Können wir die Deadline halten?
Hans Muster
April Mai Juni Juli Aug. Sep. Okt. Nov. Dez. Jan.
Anfrage
erhalten
Gewünschter
GoLive-Termin

17. BUDGETIERUNG (1/3)
Thema 1: Analysen zu Bestellungen:
6 Berichte + Datengrundlage  50%
Thema 2: Analysen zur Finanzbuchhaltung:
1 Bericht + Datengrundlage  10%
Thema 3: Analysen zur Produktion:
3 Berichte + Datengrundlage  40%
+
+
+
Projektstart
Inception-
Phase Transition-Phase
April Mai Juni Juli Aug. Sep. Okt. Nov. Dez. Jan.
Anfrage
erhalten
Gewünschter
GoLive-Termin
Construction-Phase 18 Wochen
Thema 1 T2 Thema 3
Der Fokus sollte auf der
Schätzung des Business-Nutzen
sein – welches Thema, welcher
Report hat welchen Wert für das
Unternehmen?  Priorisierung!

18. BUDGETIERUNG (2/3)
Teamzusammenstellung Variante 1
2 Entwickler
Teamzusammenstellung Variante 2
3 Entwickler
+
+ +
Was gibt uns die Sicherheit, dass wir das Altsystem firstgerecht ablösen können?
Bisherige Erfahrungswerte zur Bestimmung der initialen Teamgrösse
Ein agiles Vorgehen und das zugrundeliegende Handwerk, eine BI-Lösung in kleinen Inkrementen zu
bauen.
«Harte» Priorisierung der zu erstellenden Lieferobjekte

19. BUDGETIERUNG (3/3)
Ein Hilfsmittel für die Budgetierung:
Projekt T-Shirt-Grössen auf Basis der Daten aus bisherigen Projekten.
Parameter XS S M L XL XXL
Preis < 50k bis > 1M CHF
Anzahl Themen 1 2-3 2-3 3-4 5-6 6-8
Dauer Construction pro Thema 4 bis 8 Wochen
Anzahl Releases 1 1 2 2 3 3
Teamgrösse IT-Logix (Personen) 1 2 2-3 2-3 2-3 3-4
Teamgrösse Kunden (Personen) 1 1 1-2 2-3 2-3 2-3
Dedizierte Grobkonzept-Phase Nein Nein Nein Ja Ja Ja
Dauer Inception Phase in W. 0.5 1 1 2 2 2
Dauer Transition Phase in W. 0.5 1 2 3 3 3
Gesamtdauer in Monaten 1.5 3.0 4.5 8.5 13 17
…

20. ZWISCHENSTAND Die Budgetierung erfolgt kollaborativ
zwischen Auftraggeber und Auftragnehmer.
Es wird eine erste Priorisierung auf Basis
des Wertbeitrags der einzelnen
Lösungsbestandteile vorgenommen.
Eine agile Projektabwicklung stellt sicher,
dass diejenigen Lieferobjekte mit dem
grössten Businessnutzen zuerst bearbeitet
werden. Im Zweifelsfalle hat man lieber den
Spatz in der Hand als die Taube auf dem
Dach.
Als Auftragnehmer verspricht IT-Logix, die
geschätzte Anzahl Personen im
entsprechenden Zeitraum zur Verfügung zu
stellen.
?
Hans Muster
IT-Logix Operations

21. PROJEKTFORTSCHRITT
Projektstart
Inception-
Phase Transition-Phase
April Mai Juni Juli Aug. Sep. Okt. Nov. Dez. Jan.
Anfrage
erhalten
Gewünschter
GoLive-Termin
Construction-Phase
4 von 6 Berichten fertig 2 Berichte Trans.
Thema 1 T2 Thema 3
T2 Thema 3
Neuer,
geschätzter
GoLive-Termin
Trans.

22. PROJEKTFORTSCHRITT
Projektstart
Inception-
Phase Transition-Phase
April Mai Juni Juli Aug. Sep. Okt. Nov. Dez. Jan.
Anfrage
erhalten
Gewünschter
GoLive-Termin
Construction-Phase
4 von 6 Berichten fertig 2 Berichte Trans.
Thema 1 T2 Thema 3
T2 Thema 3
Neuer,
prognostizierter
GoLive-Termin
Daten zum bisherigen Fortschritt sollten wir nutzen, um den weiteren Projektverlauf zu prognostizieren.
Eine Definition des Begriffs «Prognose»:
Die Basis einer validen Prognose bilden Fakten, die oft mit formalisierten Methoden (Messungen, zeitlich
gegliederten Messreihen oder Simulationen) zur Erstellung von Datenmaterial erhoben werden. Auf diesen
Grundlagen können dann mit einer bestimmten Wahrscheinlichkeit Voraussagen gemacht und Entscheidungen
getroffen werden.
2.5 Wochen / Bericht 2 Berichte T2 Thema 3 Trans.
Trans.

23. ENTSCHEIDE!
Entscheid-Option 1
Ressourcen
& Kosten
Deadline &
Kosten
Umfang
10 Berichte mit
zugehöriger
Datengrundlage
Ende Oktober
Ende Dezember
3 Entwickler
Projektstart
Inception-
Phase Transition-Phase
April Mai Juni Juli Aug. Sep. Okt. Nov. Dez. Jan.
Anfrage
erhalten
Gewünschter
GoLive-Termin
Construction-Phase
2.5 Wochen / Bericht 2 Berichte T2 Thema 3 Trans.

24. ENTSCHEIDE!
Entscheid-Option 2
Ressourcen
& Kosten
Deadline &
Kosten
Umfang
10 Berichte mit
zugehöriger
Datengrundlage
Ende Oktober
2. Team für
Thema 3
Projektstart
Inception-
Phase Transition-Phase
April Mai Juni Juli Aug. Sep. Okt. Nov. Dez. Jan.
Anfrage
erhalten
Gewünschter
GoLive-Termin
Construction-Phase
2.5 Wochen / Bericht 2 Berichte T2
Thema 3
Trans.

25. ENTSCHEIDE!
Entscheid-Option 3a
Ressourcen
& Kosten
Deadline &
Kosten
Umfang
10 7 Berichte mit
zugehöriger Datengrundlage
(Thema 3 weglassen im
aktuellen Release)
Ende Oktober3 Entwickler
Projektstart
Inception-
Phase Transition-Phase
April Mai Juni Juli Aug. Sep. Okt. Nov. Dez. Jan.
Anfrage
erhalten
Gewünschter
GoLive-Termin
Construction-Phase
2.5 Wochen / Bericht 2 Berichte T2 Thema 3Trans.

26. ENTSCHEIDE!
Entscheid-Option 3b
Ressourcen
& Kosten
Deadline &
Kosten
Umfang
10 Berichte mit zugehöriger
Datengrundlage
(Design to Cost mit 1.3
Wochen / Bericht)
Ende Oktober3 Entwickler
Projektstart
Inception-
Phase Transition-Phase
April Mai Juni Juli Aug. Sep. Okt. Nov. Dez. Jan.
Anfrage
erhalten
Gewünschter
GoLive-Termin
Construction-Phase
2.5 Wochen / Bericht 2 Berichte T2 Thema 3 Trans.

27. ZWISCHENSTAND Die Budgetierung erfolgt kollaborativ
zwischen Auftraggeber und Auftragnehmer.
Es wird eine erste Priorisierung auf Basis
des Wertbeitrags der einzelnen
Lösungsbestandteile vorgenommen.
Eine agile Projektabwicklung stellt sicher,
dass diejenigen Lieferobjekte mit dem
grössten Businessnutzen zuerst bearbeitet
werden. Im Zweifelsfalle hat man lieber den
Spatz in der Hand als die Taube auf dem
Dach.
Als Auftragnehmer verspricht IT-Logix, die
geschätzte Anzahl Personen im
entsprechenden Zeitraum zur Verfügung zu
stellen.
Mittels einer Prognose können wir
bestimmen, wie wir auf Kurs sind und
Entscheidoptionen erarbeiten.
Hans Muster
IT-Logix Operations

28. VERTIKALE UMSETZUNG ALS GRUNDLAGE FÜR ZUVERLÄSSIGE
PROGNOSEN

29. ANFORDERUNGEN END 2 END UMSETZEN, UM PRIORISIEREN ZU KÖNNEN!
Bei welcher Herangehensweise wissen wir genauer, wie weit wir im Projekt fortgeschritten sind?
Erst eine vertikale Gliederung der Umsetzung (aka Features) erlaubt eine laufende (Re-) Priorisierung der
Anforderungen!
Thema 1 Thema 1
Feature 1 Feature 2 Feature 3
10%
40%
70%
100%
Kumulativer
Fortschritt
Kumulativer
Fortschritt
50% 61% 100%
Connectivity
DWH
Data Mart
BI App
0%
5%
25%
10%
40%
70%

30. VOM PROJEKT ZUM FEATURE
Der Projektumfang muss weiter heruntergebrochen werden – ohne sich aber um Details kümmern zu müssen.
Zeit
Produktvision = Umfang BI / DWH-Projekt
Release 1 (2-4 Monate) Release 1+n (2-4 Monate)
Inception Construction Transition
1 – n Themen
ConstructionConstructionConstruction
Incep-
tion
Tran-
sition
PRDFeature 1 Feature 2 Feature 3
Features haben eine a priori
maximale «Dauer» – z.B. 2
oder 3 Wochen. Warum?
Vereinfacht die Langfrist-
Prognose, ohne detaillierte
Anforderungen zu kennen.
Parkinsons Gesetz:
Arbeit dehnt sich in genau dem
Mass aus, wie Zeit für ihre
Erledigung zur Verfügung steht

31. VOM FEATURE ZUR USER STORY
Feature 1 User Stories
RTS = Runnable & Tested
Stories sind der
eigentliche Fortschritts-
Indikator in einem
Projekt!
User Stories haben eine a
priori maximale «Dauer» –
z.B. 1 oder 2 Tagen.
Warum?
Wir zwingen uns zu einem
häufigeren und kürzeren
Feedback-Zyklus.
Kurze User Stories sind die
Grundlage zur
Beantwortung der Frage,
ob der Projektfortschritt
(«Flow») wunschgemäss
läuft oder nicht.
BI Applikation
DWH
Connectivity
&
Infrastruktur
Layer
▪ Report mit monatlicher Darstellung
▪ Report mit wöchentlicher Darstellung
▪ Report mit variabler Kennzahlen-Selektion
▪ …
▪ 1 Faktentabelle mit Nicht-monetärer Kennzahl
(z.B. Menge) + Zeitdimension +
Produktdimension (ohne Hierarchie)
▪ Zusätzliche Kennzahl
▪ Produktdimension um Hierarchie erweitern
▪ …
▪ Setup Middleware
▪ Manueller Import
▪ Automatischer Import
▪ …
BI Applikations-Epics
DWH-Epics
Infrastruktur- und
Connectivity Epics

32. TESTEN DER USER STORY
Feature 1 User Stories
BI Applikation
DWH
Connectivity
&
Infrastruktur
Layer
▪ Direkt in der Applikation
▪ Abfrage in Excel
▪ Abfrage in Excel
▪ Abfrage in
SQL Server Mgt. Studio
BI Applikations-Epics
DWH-Epics
Infrastruktur- und
Connectivity Epics

33. EINKAUF UND VERKAUF

34. BEDÜRFNISSE
Hans Muster IT-Logix VerkaufEinkäufer
Werkvertrag
mit Festpreis!
Dienstleistungs-
vertrag mit Time
& Material!

35. TIME & MATERIALS
Release-basierte Vertragsgestaltung
Quartalsweise Releases
Budget und Prioritäten werden
quartalsweise angepasst.
Quelle & Copyright: Peter Stevens, http://www.scrum-breakfast.com/
Release 1 (2-4 Monate)
1 – n Themen
ConstructionConstructionConstruction
Incep-
tion
Tran-
sition

36. DER AGILE FESTPREIS nach Opelt, Gloger et. al.
Vereinbarung eines Motivationsmodells und eines
Kooperationsmodell.
Vereinbarung des Prozesses zur Scope- und
Aufwandsverwaltung.
Definition der Checkpoint-Phase und Definition des Riskshare.
 Nach Abschluss Checkpoint-Phase evtl.Anpassung
(Prognose!) und dann Fixieren des Festpreisrahmens.
Gemeinsame Gesamtschätzung der Aufwände, des
Implementierungsrisikos und des Business Values
 Erstellen eines indikativen Festpreisrahmens.
Spezifikation der Details eines Features bis auf Ebene User
Story.
Definition des Vertragsgegenstandes auf Ebene von Produkt-
oder Produktvision, Themen und Features.
Inhalt
Prozesse

37. ZUSAMMENFASSUNG

38. FOKUS AUF KONTINUIERLICHE WERTSCHÖPFUNG
Projektstart
Inception-
Phase Transition-Phase
April Mai Juni Juli Aug. Sep. Okt. Nov. Dez. Jan.
Anfrage
erhalten
Gewünschter
GoLive-Termin
Construction-Phase
Versprechen: Gemeinsames Committment zu Excellence und damit zu True & Fair View.
Schätzen: Welchen Wert schaffen wir durch die Lösung?
Budgetieren: Projekt T-Shirt-Grössen.
Agiles Projekt aufsetzen.
Agilen Vertrag abschliessen.
Prognostizieren: Fortschrittskontrolle mittels Prognose.
Priorisieren: Was ist die nächst wichtigste Sache, die es umzusetzen gilt.
Liefere statt Lafere: Fokus auf kontinuierliche Wertschöpfung.

39. Schätzen Sie noch oder
liefern Sie schon?
«Having a consistent rate of progress is more
important than estimating a project.»
«If you deliver real, measurable
customer/stakeholder value every 3 months
estimates are obsolete.»
Vasco Duarte
Raphael Branger
Senior Solution Architect / Partner
rbranger@it-logix.ch
Herzlichen Dank an das gesamte IT-Logix Team und
Vasco Duarte für die aktive Unterstützung bei der
Vorbereitung dieser Präsentation!
Follow us: @rbranger / @itlogixag
DE: http://blog.it-logix.ch/author/raphael-branger
EN: http://rbranger.wordpress.com