Sinnvolles Glossar

ZA209 - Wie du ein sinnvolles Glossar anlegst und verwaltest

05.09.2023 22 Minuten



On Air in dieser Episode

avatar
Björn Schorre

Zusammenfassung

In der heutigen Episode spreche ich über das Glossar eines Projektes. Mir ist es gerade in einem aktuellen Projekt passiert, dass ich gefragt wurde, wozu so ein Glossar den gut sei. Man würde doch schon wissen, was die Abkürzungen bedeuten.

Daher möchte ich einmal im Podcast darauf eingehen, warum ich immer beim Einstieg in ein Projekt ein Glossar anfange. Egal ob es ein Glossar vom Projektteam schon gibt oder nicht. Aus meiner Sicht hilft Dir so ein Glossar ungemein – zu Anfang, um für Dich Begriffe zu klären und später, um diese Begriffe anderen weiterzugeben.

Hör in meinen Podcast rein, denn das sind nicht die einzigen Gründe, warum ein Glossar wichtig ist.

 

###############

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

 

###############

Brauchst Du Unterstützung bei der Erstellung eines Lastenheftes oder hast eine Frage dazu, dann findest Du meine Email in den Shownotes. Klicke darauf oder kopiere sie in Dein Emailprogramm und schicke mir eine Mail und wir sprechen darüber.

Dann kannst Du Dir in meinem Online-Kalender auch gerne direkt einen Termin buchen: https://kalender.bjoernschorre.de

 

###############

P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest es auf der Verlagsseite von tredition

 

Bild zu Rollen im RE

Die Rollen im Anforderungsmanagement

Neben den Anforderungsdokumenten haben wir auch noch die verschiedenen Rollen bei der Erstellung von Spezifikationen.

Auf der einen Seite haben wir den Kunden, der in seinem Lastenheft ein Problem beschreibt, das er gelöst haben will. Zusätzlich haben wir die Interessensgruppen, die ebenfalls ein Problem beschreiben, das sie allgemeingültig gelöst haben wollen.

Auf der anderen Seite haben wir das Projektteam mit jemandem, der sich mit dem ganzen Thema Requirements Engineering beschäftigt und versucht, überhaupt das Problem zu begreifen. Dann gibt es jemanden, der sich mit dem ganzen Systemdesign beschäftigt. Das ist jemand, der versucht, aus den Anforderungen eine Lösung zu definieren. Und dann haben wir einen Projektmanager, der halt in diesem ganzen Kontext noch versucht, das Team zum Erfolg zu führen.

Das zusammen ist genau die Schnittstelle, und wir sehen auch da: Auf der einen Seite liegen die Lastenhefte und auf der anderen Seite die Pflichtenhefte nach der klassischen Beschreibung.

Rollen im Anforderungsmanagement

Rollen im Anforderungsmanagement

Am Ende bilden die Rollen auch die Arbeitsergebnisse ab. Ein Requirements Engineer wird also die Anforderungsspezifikation (SRS) erschaffen. Ein Systemdesigner oder ein Systemarchitekt wird die Architekturspezifikation (SAS) schreiben, und der Projektmanager beschreibt in der Regel in seinem Projekthandbuch all die nichttechnischen Anforderungen an ein System.

Je komplexer Systeme werden oder je dynamischer ihre Funktion ist, desto wichtiger wird es, sich intensiv mit diesen Dokumenten und Spezifikationen zu beschäftigen. Ein System, das einen relativ einfachen Aufbau hat und auch keine großartige Dynamik besitzt, muss nicht in aller epischer Breite sämtliche oben beschriebenen Spezifikationen besitzen, wenn eigentlich klar ist, was wichtig ist. Das bedeutet aber, sie nicht komplett wegzulassen, sondern mit Sinn und Verstand nur das, was gebraucht wird, umzusetzen.

Je komplexer ein System wird oder gar je mehr Unterlieferanten dabei sind, also je mehr Menschen auch in diesem Projekt eingebunden sind, desto wichtiger werden Spezifikationen. Denn Spezifikationen sind am Ende nichts anderes als eine Dokumentation von Wissen.

Requirements-Engineering mit Word und Excel

Immer wieder melden sich Leser, die in ihren Unternehmen die nötigen Anforderungen und Spezifikationen für Projekte schaffen, aber kein Requirements-Engineering-Werkzeug haben. Entsprechend versuchen sie, mit Word und Excel zu arbeiten, was nicht immer einfach ist – und weswegen ich die nächsten Beiträge diesem Thema widmen möchte.

Ich werde im Folgenden die vielen Fragen aufgreifen, die sich um Requirements Engineering mit Word und Excel drehen.

Viele, gerade kleine und mittelständische Firmen haben für ihre Projekte oftmals keine aufwändigen und großen Requirements-Engineering-Tools, wie man sie aus komplexen Projekten kennt.

Diese Tools sind in der Regel recht teuer, oft sehr vielschichtig und relativ komplex zu bedienen. Also nutzen viele Unternehmen – beinahe „traditionell“ – die Word- oder auch Excel-Werkzeuge.

Hinzu kommt häufig, dass die fachliche Ausbildung in Sachen Requirements Engineering fehlt: Viele wissen schlicht nicht, was es bedeutet und wie relevant es ist. Entsprechend nehmen sie einfach das, was sie haben – in der Regel Microsoft Office – und versuchen, ihre Requirements damit zusammenzubauen.

Das Ziel dieser Episoden ist es, euch das nötige KnowHow und viele Tipps zu vermitteln, um eure Spezifikationen mit Word zu handhaben. Zunächst habe ich ein paar Begriffsklärungen und ein wenig Hintergrundwissen für Leser, die die vorangegangenen Beiträge noch nicht kennen.

Tiger and Turtle, Duisburg

ZA208 - Agilität im Systems-Engineering

25.07.2023 46 Minuten



On Air in dieser Episode

avatar
Björn Schorre
avatar
Thaddäus Dorsch

Zusammenfassung

In dieser Folge tauchen wir in die Welt der Systemtechnik ein und untersuchen die Einbeziehung von Agilität in den Prozess. Mein heutiger Gast ist Dr. Thaddäus Dorsch, ein Experte auf dem Gebiet des Systems-Engineering und der agilen Methoden. Wir erfahren etwas über die Kernkonzepte des Systems-Engineering, wie Agilität eine entscheidende Rolle spielt, Best-Practice-Benchmarks für die Implementierung von Agilem Systems Engineering und die wichtigsten Erfolgsfaktoren, damit es effektiv funktioniert.

Das agile Manifest der Software-Entwicklung: https://agilemanifesto.org/iso/de/manifesto.html (bitte zuerst lesen)

Link auf das agile Manifest der System-Entwicklung: https://www.agile-systems-engineering.com/

###############

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

 

###############

Du brauchst Hilfe bei der Definition der Anforderungen an Dein Produkt?

Dann kannst Du Dir in meinem Online-Kalender gerne einen Termin buchen: https://kalender.bjoernschorre.de

 

###############

P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest es auf der Verlagsseite von tredition

 

Wie detailliert soll ich Anforderungen beschreiben?

In Pflichtenheften für komplexe Systeme ergibt es mit Sicherheit keinen Sinn, die letzten Controller-PINs oder den Variablennamen im Quellcode zu beschreiben.  Wichtig ist, dass ich das, was ich konzeptionell erwarte, z.B. ein Geschwindigkeitssignal in einer gewissen Auflösung in einem gewissen Wertebereich, beschreibe.  Wie das Software-Team das unten auf deren Ebene in seine Spezifikation und in seine Lösung umsetzt und dass da irgendwelche Coding-Styleguides berücksichtigt werden usw. usw., das werde ich oben auf Systemebene schon gar nicht beschreiben.

Das tue ich schlicht aus dem Grund, dass ich dem Team auch einen Lösungsraum bereithalte, mit dem es arbeiten kann. Das macht es gerade dann besonders schwierig, und das ist häufig auch meine Erfahrung, wenn Kunden versuchen, im Pseudocode im Lastenheft Funktionen zu beschreiben. Dann bin ich auf der Systemebene immer gefordert, davon wieder zu abstrahieren, um klar zu verstehen, was will der Kunde eigentlich will. In der Regel nehme ich dann SysML, um ein Verhalten als Diagramm darzustellen. Ein Pseudocode im Lastenheft geht nämlich schon fast bis zu Variablennamen herunter. Damit ist es a) schwer verständlich und b) schränkt es den Lösungsraum auf 0 ein.

Das mag zwar ganz nett sein, aber wir haben immer bei komplexen Systemen das Problem, dass wir zwischen verschiedenen Lösungsmöglichkeiten abwägen müssen. Wenn ich keinen Handlungsspielraum mehr habe, werde ich an der Stelle dermaßen fixiert, dass ich möglicherweise das gesamte System überhaupt nicht lösungs- und zielorientiert umsetzen kann. Bei all diesen Spezifikationen gilt für einen pragmatischen Einsatz: Je einfacher ein System und je weniger Anforderungen vorhanden sind, desto weniger müssen Sie sich mit komplexen Spezifikationsstrukturen herumschlagen.
Bei manchen reicht aus meiner Erfahrung heraus die Architekturspezifikation (SAS) völlig aus. Man soll in Verbindung mit dem System Footprint auf der Lastenheftebene (= Kundenebene = „Wünsch-dir-was“ des Kunden oder Produktmanagements) einfach pragmatisch bleiben.

Wichtig: Weglassen heißt nicht komplett weglassen, sondern nur, das, was sie mit Sinn und Verstand als nutzlos nicht brauchen. Aber definitiv lassen sie nicht diese gesamte Ebene weg, sonst kommen sie in Situationen, dass sie nachher nicht mehr nachvollziehen können, was sie da eigentlich wollten, und der Kunde nicht das Gewünschte bekommt.

Was ist ein Pflichtenheft?

Wie immer gibt es wunderschöne Normen, und gemäß der DIN 69901-5 enthält das Lastenheft „die vom Auftraggeber festgelegte Gesamtheit der Anforderung an die Lieferung und Leistungen eines Auftragnehmers innerhalb eines Auftrags“. So kann man es bezeichnen. Ich würde einfach das Ganze mal ein bisschen pragmatischer sehen: Das Lastenheft beschreibt in der Regel, womit und wofür etwas gemacht werden soll. Mit anderen Worten, es ist am Ende des Tages das „Wünsch-dir-was“ des Kunden aus seiner Sicht.

Aber auch über das Pflichtenheft sagt die DIN 69901-5 etwas: „die vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes“.  Schön, oder einfacher gesagt, das Pflichtenheft beschreibt, wie und womit etwas realisiert wird. Das ist dann die Antwort auf das Lastenheft des Kunden. Er schreibt sein Wünsch-dir-was, und im Pflichtenheft schreibe ich, wie ich das Problem verstanden habe und was ich davon umsetzen kann.

Ich habe ja einigen Episoden schon darüber referiert. Mir gefallen aus der heutigen Sicht die Begriffe „Lastenheft“ und „Pflichtenheft“ nicht mehr. Sie sind aus meiner Sicht zu allgemein. Wir müssen es gerade bei komplexeren Projekten detaillierter und differenzierter sehen. Und gerade beim Thema Systempflichtenhefte gibt es eben zwei Dokumente, die zusammen das Bild eines Pflichtenhefts ergeben. Auf der einen Seite das Dokument Systemanforderungsspezifikation (SRS), also die Beschreibung des Problembereichs. Das Ziel dieses Dokuments ist, die definierten Kundenanforderungen in einen Satz von technischen Systemanforderungen zu übertragen, die das System begleiten.

Dann gibt es noch ein zweites Dokument, die Systemarchitekturspezifikation (SAS). Das ist eigentlich der Lösungsbereich. Hier beschreibe ich, wie ich die Lösung entwerfen will, denn hier entstehen nochmals andere Anforderungen. Nicht alle Systemanforderungen werde ich erfassen, sondern ich muss mir auch auf der Architekturseite Gedanken über die Vollständigkeit der Anforderung machen. Das Ziel dieses Dokumentes ist die Identifikation, welche Anforderungen, welche Komponenten dann welchen Elementen des Systems zugeordnet werden müssen.

Diese beiden Dokumente sind zusammen ist eigentlich das, was im allgemeinen Sprachgebrauch Pflichtenheft genannt wird. Als Systemingenieur rede ich natürlich auch von dem Systempflichtenheft oder Systemspezifikationen, das heißt, beide Dokumente sind konzeptionell gehalten.

Aus der Praxis für die Praxis

 

Lastenheft vs. Pflichtenheft – Die verschiedenen Ebenen von Spezifikationen

Wie können Projekte pragmatisch mit Lastenheft und Pflichtenheft umgehen? Ein Thema, das zurzeit eine Menge Leute beschäftigt und bei dem wir einige Zusammenhänge besprechen müssen, um später die Umsetzung besser zu verstehen.

Ein Aspekt, der in diesem ganzen Zusammenhang mit Lastenheften und Pflichtenheften mitspielt: Es gibt Spezifikationen auf verschiedenen Ebenen. Ich erkläre ganz bewusst ein paar neue Begriffe, weil Lastenheft und Pflichtenheft aus meiner Sicht heraus alte Begriffe sind und damit zu allgemein für diese Herausforderung. Weiterlesen

ZA207 - Lastenheft Rütteltest

24.05.2023 17 Minuten



On Air in dieser Episode

avatar
Björn Schorre

Zusammenfassung

Aus vielerlei Gründen ist es notwendig, ein Lastenheft-Review durchzuführen. Dazu gehört zum Beispiel, dass der Autor die Qualität überprüft haben will, um vor der Weitergabe des Dokuments sicher zu sein. Daneben werden Reviews aber auch zu Zwecken der Qualitätssicherung eingesetzt. Und zu guter Letzt ist es notwendig ein Review durchzuführen, weil es der Prozess so vorsieht.

Je nach Anwendungsfall gibt es verschiedene Methoden und Techniken, die eingesetzt werden können. Welche das sind und was ich Dir mit meinem Lastenheft Rütteltest als Service anbiete, erfährst Du in dieser Podcast-Episode.

Mein Vorgehen zum Lastenheft Rütteltest habe ich hier zusätzlich dokumentiert: https://lastenhefterstellen.de/vorgehen-lhreview/?utm_source=zukunftsarchitekten-podcast.de&utm_medium=podcast&utm_campaign=zap207

 

###############

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

 

###############

Du brauchst Hilfe bei der Definition der Anforderungen an Dein Produkt?

Dann kannst Du Dir in meinem Online-Kalender gerne einen Termin buchen: https://kalender.bjoernschorre.de

 

###############

P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest es auf der Verlagsseite von tredition

 

Interview Setup

ZA205 - Vom Lebenszyklusmodell zum PEP - Unterstützung durch ein digitales Prozessmodell

11.04.2023 32 Minuten



On Air in dieser Episode

avatar
Björn Schorre
avatar
Alexander Efremoff

Zusammenfassung

Das digitale Prozessmodell hat Alexander Efremoff auf seinen Reisen mit dem Zug durch Deutschland realisiert. Warum er es für sinnvoll hielt, das Prozessmodell zu digitalisieren hat er auch in diesem kurzen Video erklärt. Basis für die Umsetzung waren die Prozesse des Lebenszyklusmodells der ISO 15288.
Im Interview erzählt Alexander von seiner Begeisterung für das Prozessmodell. Außerdem verrät er, wie Du das Prozessmodell nutzen kannst, um auf der Basis von Best Practices Deinen PEP entwerfen kannst.

Du findest das Prozessmodell auf den Seiten der GfSE. Es ist frei in der Nutzung: https://www.gfse.de/prozessmodell

Das Prozessmodell ist auch in der englischen Version auf den Seiten der INCOSE zu finden:

 

Wenn Du Dich mit Alexander Efremoff vernetzen willst, dann kannst Du dies auf seinem LinkedIn-Profil tun.

 

###############

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

###############

Du brauchst Hilfe bei der Definition der Anforderungen an Dein Produkt?

Dann kannst Du Dir in meinem Online-Kalender gerne einen Termin buchen: https://kalender.bjoernschorre.de

###############

P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest auf der Verlagsseite von tredition

Effektive Aufwandsschätzung für komplexe Projekte

Releaseplanung und Aufwandsschätzung ist eine der Kernaufgaben des Systemingenieurs. Die Projektmanager benötigen die Zahlen des Systemingenieurs. Aber viele hochspezialisierte Entwicklungsingenieure scheuen sich, dazu etwas zu sagen. Somit ist die Aufwandsschätzung und die Releaseplanung die Schnittstelle zwischen Systemingenieur und Projektmanager.

Die hier beschriebene Vorgehensweise habe ich 2004 entwickelt, da ich als Troubleshooter immer wieder in den Meetings gefragt wurde: “Und, Herr Pfingsten, wie lange benötigen wir für den dafür?”. Mir ist zu dieser Zeit das Buch “Bärentango” von Tom DeMarco in die Hände gefallen, in der er eine Methode über Risikomanagement beschreibt. Sofort war mir klar: Wenn ich ein paar Punkte anpasse, kann ich die Vorgehensweise auch für die Aufwandsschätzung nutzen.

Das erste Mal habe ich auf dem PM-Forum 2006 in Hannover über meine Vorgehensweise zur Aufwandsschätzung einen Vortrag gehalten.

Warum ist Aufwandsschätzung so schwierig?

Der Manager fragt den Entwickler, wie viel Aufwand er für die Lösung benötigt. Der Entwickler antwortet “Etwa 300 bis 500 Stunden”. Welcher Wert wird nun genommen? Klar: 150 Stunden!

Aber warum? Oft wissen die Manager, dass die Entwickler eine Reserve einplanen, die  aus Sicht des Managers aber oft zu hoch ist. Also teilt er die Aussage des Entwicklers durch zwei. Das Verhalten versteht der Entwickler sofort und wird seine Aussagen zukünftig mit zwei multiplizieren. Keine sinnvolle Vorgehensweise!

Zusätzlich sind Aufwandsschätzungen unpräzise. Das hat weitere Gründe:

  1. Extremer Zeitdruck
    In der Regel werden Schätzungen immer unter extremen Zeitdruck abgegeben – „Ich brauche eine Aussage in den nächsten zwei Stunden.“
  2. Abhängig von der Erfahrung
    Wenn ich einen absoluten Spezialisten mit zwanzig Jahren Erfahrung frage, werde ich definitiv eine andere Aussage erhalten, als von einem Hochschulabsolventen.
  3. Die Wahrheit der Zahl
    Anforderungen sind oft verbal beschrieben und damit interpretierbar. Das kennen wir und gehen damit um. Wenn ich etwas als rosa bezeichne, ist das für meine Tochter auch gerne violett, pink, lila oder so.
    Wenn wir aber über Zahlen reden, passiert in unserem Kopf ein fataler Kurzschluss: Zahlen sind nicht interpretierbar. Das bedeutet, wenn ich 100 Stunden sage, dann ist das für den Gegenüber auch 100 Stunden, nicht 99 Stunden und nicht 101 Stunden. Aber das führt dazu, das unser Kopf dummerweise zu uns sagt, das ist wahr. Egal wie falsch die 100 Stunden sind.
  4. Ungenauigkeit über die Zeit
    Es gibt einen Punkt, in dem der echte Aufwand mit der Schätzung übereinstimmt! Das ist beim Abschluss des Projektes, relativ gesehen = 1. Vorher gibt es immer eine Unsicherheit. Je weiter wir bei einem Projekt am Anfang stehen, umso größer ist die Unsicherheit. Eine Studie von Tom DeMarco aus den 80er-Jahren hat folgendes ergeben: Zu Beginn eines Projektes liegen die Schätzungen 400% über den Aufwand oder betragen 25% vom wirklich benötigten Aufwand:

 

Wie können wir besser schätzen?

Es gibt einige Anforderungen, die bei effektiven Aufwandsschätzungen wichtig sind:

  1. Effizient und nicht komplex
  2. Effektiv, aber nicht schlampig
  3. Nachvollziehbar und nicht individuell
  4. Ausgewogen und keine einseitige Sicht
  5. Verlässlich und nicht fehlerbehaftet

Was benötigt eine gute Aufwandsschätzung?

Aufwandsschätzung ist nicht einfach. Es gibt aber einige Faktoren aus der Praxis, die eine gute Aufwandsschätzung beschreiben:

  1. Entkoppelung der Ergebnisse
    Wir müssen die Ergebnisse von der Quelle entkoppeln. Das bedeutet, wir benötigen einen Faktor, mit dem wir die Erfahrung des Entwicklers berücksichtigen können.
  2. Unsicherheit einplanen
    Wir müssen die Möglichkeit haben, zu der Zahl eine Unsicherheit mit anzugeben. Zum Beispiel 300 Stunden Aufwand mit einer Wahrscheinlichkeit von 80%, dass wir es damit schaffen.
  3. Einfache Vorgehensweise
    Die Vorgehensweise muss einfach und für jeden nachvollziehbar sein. Ich habe verschiedentlich Methoden ausprobiert, und wenn mich nach fünf Minuten alle nur noch komisch angeschaut haben, dann war die Methode nicht einfach.
  4. Nachvollziehbar nach Monaten
    Aufwandsschätzungen sind oft ein Puzzlestück vor einer größeren Entscheidung. Und Entscheidungen brauchen Zeit. Bei Angeboten können bis zu sechs Monate vergehen, bis ein Auftrag fixiert ist. Die handelnden Personen sind aber dann schon in anderen Projekten verschwunden, und das neue Projektteam muss deren Schätzungen nach Monaten nachvollziehen können.

Wie können wir besser schätzen?

Der erste Schritt ist, die Unsicherheit zu benennen. Dazu frage ich zunächst drei Informationen bei den Entwicklern ab:

  1. Der Nano-Prozent-Wert
    Wie viel Aufwand brauchst du, wenn alles super läuft? Wenn kein Server abrauscht, kein Kunde dauernd anruft, wenn alles perfekt ist. Hier erhalte ich eine Aussage in Stunden (wichtig: Aufwand, nicht Dauer!). Relativ gesehen ist die Wahrscheinlichkeit „null“, damit das Problem zu lösen.
  2. Der erwartete Wert
    Was glaubst du – ohne mal zwei durch zwei – wird der Aufwand sein (wichtig: Aufwand nicht Dauer!)? Aus Sicht des Entwicklers ist die Wahrscheinlichkeit, relativ gesehen, „eins“, das Problem zu lösen.
  3. Der Unsicherheitsfaktor
    Wie viel Berufserfahrung hast du? Wie gut kennst du dich mit der Materie aus? Hier bilde ich einen Faktor zwischen 1 und 10. Eins bedeutet, ich kann den Kollegen nachts aus dem Bett zerren und er kann mir die Lösung runterbeten. Zehn bedeutet, er hat einen fragenden Blick und hält mich für einen komischen Typen.
  4. Der maximale Wert
    Den maximalen Wert errechne ich aus dem Nano-Prozent-Wert multipliziert mit dem Unsicherheitsfaktor.

Diese Informationen kann ich im folgenden Bild darstellen:

Kumulative Ansicht

Hier sehen wir nun eine vereinfachte Verteilung. Diese können wir integrieren und erhalten die sogenannte kumulative Sicht:

 Absolute Ansicht

Inhaltlich haben wir die gleiche Aussage wie vorher. Wir haben nur von einer relativen in eine absolute Aussage gewechselt. Relativ gesehen haben wir bei 350 Stunden eine Wahrscheinlichkeit von 0%, dass wir eine Lösung schaffen. Das haben wir absolut gesehen auch. Relativ gesehen haben wir ebenfalls eine Wahrscheinlichkeit von 0%, dass wir 1000 Stunden benötigen. Absolut gesehen bedeutet es, dass wir mit 1000 Stunden zu 100% klar kommen.

Jetzt können wir den nächsten Schritt unternehmen und die absolute Wahrscheinlichkeit auf 80% setzen. Damit erhalten wir einen Aufwand von 650 Stunden bei 80% Wahrscheinlichkeit es zu schaffen.

Ergebnis mit Wahrscheinlichkeit

Nun haben wir eine Aussage über den Aufwand mit einer zusätzlichen Information, wie wahrscheinlich es ist, mit den Aufwand zurecht zu kommen. Durch diese Vorgehensweise können wir nun besseren Schätzungsaussagen abgeben:

  1. „Wir schaffen es“ (80% Wahrscheinlichkeit oder mehr).
  2. „Wir können einen Versuch wagen(60% – 80% Wahrscheinlichkeit).
  3. „Wir haben eine 50/50 Chance“ (50% Wahrscheinlichkeit).
  4. „Wir haben absolut keine Chance, es zu schaffen“ (Weniger als 50%).

Zusammengefasst sind die Schritte:

  1. Schätze den optimistischen und den erwarteten Aufwand.
  2. Definiere den Unsicherheitsfaktor (1…..10).
  3. Kalkuliere den pessimistischen Aufwand.
  4. Übertrage die kumulative Sicht in die absolute Sicht.
  5. Definiere die gewünschte Wahrscheinlichkeit und lies den Aufwand ab.

Das Ergebnis

Damit haben wir eine einfache Vorgehensweise, um Aufwände zu schätzen und mit der Aussage eine Wahrscheinlichkeit zu verknüpfen. Wenn wir das für jedes einzelne Arbeitspaket durchführen, können wir die Aufwände zusammenrechnen und den Durchschnitt der Wahrscheinlichkeiten bilden. Somit haben wir für ein gesamtes Projekt die Abschätzung geschaffen. Nebenbei haben wir die Argumentation, was eine Reduktion der Aufwände bedeuten würde: die Reduktion der Wahrscheinlichkeit. Meine Erfahrung ist, dass Manager dann aufmerksam werden. Sie sind jetzt mit Verantwortlich, wenn die Aufwände so gekürzt werden, dass die Wahrscheinlichkeit zum Beispiel auf 20% sinkt. 

Auch die Dokumentation fällt wesentlich leichter. Wir brauchen nur noch zwei Informationen dokumentieren:

  • Warum haben wir den Unsicherheitsfaktor (1 …. 10) gewählt?
  • Warum haben wir die Wahrscheinlichkeit (0% – 100%) gewählt?

Die anderen Informationen sind durch die Entwickler gegeben worden.

Oft ergeben die Schätzungen mit dieser Vorgehensweise eine viel höheres Ergebnis als bisher. Was logisch ist, denn klassische Projekte verdoppeln oder dreifachen gerne mal ihr Budget. Aber wir können mit der Vorgehensweise auch bewusst auf Lücke setzen! Wir können bei einzelnen Arbeitspaketen die Wahrscheinlichkeit auf bis zu 50% absenken und den Aufwand definiert reduzieren. Damit wissen wir sofort, welche Arbeitspakete ein Risiko darstellen.

Der Ausblick

Mit dieser Form der Aufwandsschätzung habe ich nun die Grundlage geschaffen, für die Entwicklungsprojekte die Kosten abzuschätzen. Der nächste Schritt ist die darauf aufbauende Releaseplanung. Ich habe das in einem weiteren Tutorial zusammengefasst: Nachvollziehbare Releaseplanung für komplexe Systeme