DIE UNSCHÄRFE-RELATION

DER AUFWANDSCHÄTZUNG:

DEN PLANUNGSPROZESS

GESTALTEN

stecken. Statt den benötigten Aufwanddirekt zu bestimmen, wird ein andererIndikator als Stellvertreter für denAufwand geschätzt, da das Projektteamden Stellvertreter leichter schätzenkann als den Aufwand selbst. DerartigeSchätzmethoden werden deshalb auchals Proxy-basierte Schätzungen be -zeich net.

Einflussfaktoren wirken meist nicht auf dieGröße eines Schätzobjekts. Im obigenBeispiel bedeutet das: Nur weil Sie einehochwertigere Ausstattung wünschen, wirddie Eigentumswohnung nicht größer, trotz-dem aber teurer. Einflussfaktoren erhöhen(im besten Fall auch verringern) also meistden Aufwand und nicht notwendigerweisedie Größe. Eine Analyse und Schätzung derEinflussfaktoren sind damit erst nach derGrößenschätzung sinnvoll. Auch hier fin-den wir einen Unterschied zwischen Ein -fluss- und Risikofaktoren, denn für Risiko -faktoren muss dies nicht gelten. ZumBeispiel werden bei der Entwicklung vonsicherheitsrelevanten Systemen Komponen -ten gegebenenfalls redundant ausgelegt. Eswerden also – zusätzlich zum ursprünglichdefinierten Projektumfang – risikomindern-de Maßnahmen definiert (nämlich dieredundante Auslegung des Systems), die dieGröße des Systems erhöhen.

Einfacher ist es meist, anschließend ausden Aufwänden Kosten abzuleiten, umschließlich nach der Terminierung der not-wendigen Aktivitäten (Terminplan) Auf -wände bzw. die zugehörigen Kosten zeitlich

Aufwände richtig abzuschätzen, ist eine der großen Herausforderungen im Projektgeschäft.Sind die Schätzungen zu niedrig, zahlen Sie bei Festpreis-Projekten drauf. Sind Ihre Schätzun -gen zu hoch und Ihre Angebote damit zu teuer, erhalten Sie erst gar keinen Kundenauftrag undIhr Mitbewerber gewinnt. Ziel muss daher sein, die Schätzgenauigkeit zu erhöhen und gleichzei-tig den Aufwand effizient zu bestimmen. Doch dieses Problem gleicht allzu oft der Quadraturdes Kreises. Ist damit die Methode „Price to Win“ die einzig verbleibende? Wird also derAngebotswert vor allem mit Blick auf das Kundenbudget und die Wettbewerbssituationbestimmt und nur bedingt im Hinblick auf die tatsächlichen Kosten? Aber unabhängig davon,ob agile oder klassische Schätzmethodiken eingesetzt werden, sollten Sie sich über die Ein -flussfaktoren auf den Aufwand klar werden und diese in Ihre Schätzüberlegungen einbeziehen.

14 15

kann. Je nach identifiziertem Risikowerden gegebenenfalls bereits jetzterste risikomindernde Maßnahmen de -fi niert, die in der Schätzung zusätzlichzu berücksichtigen sind.

2. Im zweiten Schritt werden Schätz -objekte definiert. Typischerweisegeschieht dies auf der Basis des Projekt -strukturplans oder andere Projektele -mente (etwa Use-Cases, User-Storysund Testfälle). Der Aufwand zu einemSchätzobjekt leitet sich aus dessenGröße ab: So benötigt ein Team zumBeispiel X Personentage, weil Y Anfor -derungen oder Z Story-Points dahinter

Risiken und SchätzungWelche Einflussfaktoren auf die Schätzunggibt es und wie müssen diese im Schätz -prozess berücksichtigt werden? Genau ge -nommen muss zwischen Einflussfaktorenund Risikofaktoren unterschieden werden.Der Unterschied lässt sich am besten an fol-gendem Beispiel erläutern: Sie kaufen voneinem Bauträger eine Eigentumswohnungund haben die Wahl zwischen einer einfa-chen und einer hochwertigen Ausstattung.Die Ausstattungsvariante stellt damit einenKostentreiber dar (Einflussfaktor), der aberkein direkter Risikofaktor ist (bestenfallsindirekt für das Ihnen zur Verfügung ste-hende Budget). Ein Risikofaktor ist – inAbgrenzung zu einem Einflussfaktor –immer mit einer Wahrscheinlichkeit ver-bunden, mit der Zusatzaufwände oder -kosten entstehen können, aber nicht müs-sen. In der Praxis ist der Unterschied zwi-schen diesen beiden Arten von Faktorennur marginal, aber der Grund dafür, dass inAbbildung 1 sowohl ein entwicklungsbe-gleitendes Risikomanagement als auch eineAktivität zur Bewertung von Einflussfak -toren dargestellt ist.

Eine Schätzung läuft grob nach folgen-dem Muster ab:

1. Zunächst ist der Umfang der Schätzungzu definieren (in der Regel identisch mitdem Projektumfang). Risikofaktorenwären hier etwa die Unvollständigkeitoder Mehrdeutigkeit von Anforderun -en, während ein Einflussfaktor dasBedien konzept der Applikation sein

schwerpunk t

Dr. Jürgen Schmied

(Juergen.Schmied@methodpark.de)

ist Geschäftsführer und Senior Berater der

Method Park Consulting GmbH. Er berät Unter -

nehmen zu Projekt- und Prozess manage ment und

ist Autor zahlreicher Artikel und mehrerer

Fachbücher.

der au tor

Abb. 1: Typischer Schätz- undPlanungsprozess.

2/2013

zu planen (Kostenplan). Schätz- undPlanungs-Baselines sind notwendig und dieGrundlage, um im Projekt den Status mitder ursprünglichen Planung vergleichen zukönnen (Controlling). Ganz wesentlich istes, Folgendes zu verstehen:

■ Schätzung und Planung sind keine ein-malige Aufgaben des Projektleiters undseines Teams. Stattdessen ist dieseimmer dann anzupassen, wenn detail-lierte oder neue Informationen vorlie-gen.

■ Das Risikomanagement spielt nichtnur, wie oben beschrieben, bei derIdentifikation des Projektumfangs eineRolle, sondern letztlich bei allen darge-stellten Prozessschritten. Risiko -manage ment ist grundsätzlich einbeglei tender Bestandteil des Projekt -manage ments.

So schön klar der Schätzprozess auchstrukturiert ist – die methodische Durch -führung der Schätzung ist meist doch einBuch mit sieben Siegeln, wie die nachfol-genden Fragestellungen zeigen.

Die Unschärfen in derAufwandschätzungDie Frage aller Fragen im Projekt-Businessist wohl: „Was kostet mich die Ent -wicklung der Software mit der Funktio -nalität X?“ Der Kunde will ja schließlichnicht die Katze im Sack kaufen, sondernbereits am Anfang des Projekts wissen, waser für eine bestimmte Funktionalität bezah-len muss. Aber genau hier liegt bereits daserste Übel: Welche Funktionalität genauhat denn der Kunde gemeint? Ist er in derLage, das exakt zu spezifizieren?

Nehmen wir an, es gibt diesen Kunden,der seine Anforderungen bis ins Detailbeschreiben kann. Sind wir als Entwick -lungsteam dann in der Lage, ihm auf denCent genau zu sagen, was die Entwicklungkosten wird? Wir hätten zwar einenwesentlichen Unsicherheitsfaktor beseitigt(nämlich die vagen Anforderungen), trotz-dem hätten wir längst nicht alles im Griff.Genauso, wie in der Qualitätssicherungzwischen Produkt- und Prozessqualitätunterschieden wird, können wir zwischenUnsicherheiten im Produkt (Anfor -derungen) und Unsicherheiten im Prozessunterscheiden. Die zweite Frage lautet also:Wissen wir zu Projektbeginn bereits genau,wie unser projektspezifischer Entwick -lungs prozess ablaufen wird? Kennen wiralle Varianten im Ablauf? Und vor allem:

Wissen wir, welche Variante dann auch tat-sächlich durchgeführt wird? Wie wirkensich zeitliche Randbedingungen (z. B. „Biszur nächsten Messe muss das Produkt fer-tig sein“) und geografische Randbedin -gungen (z. B. „Wir arbeiten multinationalverteilt“) auf unseren Prozess aus?

Nehmen wir der Einfachheit halber an,wir würden bereits zu Projektbeginn wirk-lich jede durchzuführende Aktivität ken-nen. Wir kennen natürlich auch die Abfolgeder Aktivitäten bzw. deren Abhängigkeiten.Wir wissen, wie die Informationen zwi-schen allen Beteiligten fließen. Und es gehtnatürlich auch bei der Durchführung derProjektaktivitäten nichts schief. DieUnsicherheit im Prozessablauf soll alsogleich 0 sein. Aber jetzt sind wir doch end-lich in der Lage, dem Kunden genau zusagen, was ihn die Produktentwicklungkostet. Oder?

Es wäre doch zu schön gewesen, aber wirhaben das Projektteam vergessen, das dasProdukt entwickeln soll. Kennen wir schonzu Projektbeginn die Mitarbeiter unseresProjektteams? Wissen wir genau, wer wel-che Qualifikationen und Fähigkeiten mit-bringt, und können wir dies quantifizieren?Sind wir uns sicher, dass unser Projektteamauch über die gesamte Projektdauer gleichbleibt? Wissen wir mit Sicherheit, dass dievom Management und den einzelnenTeammitgliedern zu Beginn abgegebenenRessourcenzusagen über die Projektlaufzeiteingehalten werden und nicht plötzlich ein-zelne Personen für andere Aufgaben ganzoder teilweise abgezogen werden?

Aber nehmen wir wieder einmal verein-fachend an, wir würden im Paradies derRessourcen leben, wir hätten ein stabilesund erfahrenes Team, das keine Wünscheoffen lässt, und alle teambezogenen Risikenwären ausgeschlossen. Aber jetzt müsstenwir doch endlich in der Lage sein, demKunden auf Heller und Pfennig zu sagen,was ihn die Entwicklung tatsächlich kostenwird, oder?

Für eine genaue Schätzung fehlt uns lei-der immer noch eine wesentliche Einfluss-bzw. Unsicherheitsgröße. Jedes Produktwird auf Basis einer bestimmten Techno -logie und mit ausgewählten Werkzeugenentwickelt. Beherrschen wir diese Tech -nologien und Tools wirklich immer per-fekt? Führen wir neue Technologien undTools in unserem Projekt wirklich ohneReibungsverluste ein?

Jedes Projekt lässt sich über die Haupt -faktoren „Mensch“, „Prozesse“ und„Technologien“ beschreiben (siehe Abbil -dung 2). Das ist nicht neu und wird seitLangem sowohl im Projektmanagement alsauch in Qualitätsmodellen (z. B. imCapability Maturity Model Integration –CMMI) so verstanden: Um Projekte abwi -ckeln zu können, benötigt man Menschen,die unter Verwendung von TechnologienProdukte schaffen. Je größer das Projekt -team dabei ist, umso mehr wächst dieBedeutung von Spielregeln (Prozessen),deren Einhaltung die Effektivität undEffizienz von Projektteams unterstützt.Natürlich definiert der Kunde das zu ent-wickelnde Produkt maßgeblich über seineAnforderungen. Wenn man so möchte,lässt sich die Unschärfe in der Auf -wandschätzung als eine Funktion über dieUnschärfen aus Anforderungen, Prozessen,Team und Technologien ausdrücken:

Dabei sind diese Einflussfaktoren (bzw.Risikofaktoren) eher als eine Gruppe vonmehreren Faktoren zu verstehen, die sichdeutlich detaillierter betrachten lassen alsnur die bisher genannten vier Einzel fak -toren. Abbildung 3 zeigt beispielhaft eineAufzählung typischer Faktoren, die in dieGruppen „Anforderungen“, „Prozess“,„Team“ und „Technologie“ aufgeteilt sind.Naturgemäß kann diese Aufzählung nichtvollständig sein. Hinzu kommt der wichti-ge Parameter „Zeit“. Denn all diese Grö -ßen verändern sich typischerweise über dieProjektlaufzeit. Während zu Projektbeginndie Unschärfen aller Parameter sehr hochsind, betragen sie zu Projektende quasi 0.

Eingangs haben wir uns gefragt, ob dieSchätzung des Projektaufwandes effizientund effektiv durchführbar ist: Es bleibt eineFrage der Genauigkeit bzw. der Unschärfe.In der Praxis ist Aufwandschätzung letzt-lich mit dem Umgang mit Risiken gleichzu-setzen. Im Risikomanagement wird derBegriff „Risiko“ als eine ungewollte Situa -

schwerpunk t

Abb. 2: Dreiecksbeziehung: Mensch –Prozesse – Technologie.

■ Mangelndes Änderungsmanagement■ Ungenaue Projektzieldefinition bzw.

-abgrenzung■ Ungenaue bzw. fehlende Kommuni ka -

tion zwischen Auftraggeber und -neh mer

Im Umgang mit Unsicherheiten müssennicht nur die geschilderten Risikofaktoren(siehe Abbildung 3) selbst quantifiziert,sondern gegebenenfalls auch geeignete risi-komindernde Maßnahmen ergriffen undbei der Schätzung berücksichtigt werden.So sollen die Wahrscheinlichkeit und/oderAuswirkungen der Risikofaktoren vermin-

16 17

höhere Unsicherheit in den Projektzielenund Anforderungen vorhanden ist. DieseUnsicherheit verringert sich im weiterenProjektverlauf durch Erkenntnisgewinn (z.B. die Freigabe von Anforderungen,Erstellung der Architektur) und ist amProjektende komplett abgebaut. Diese ide-alisierte Darstellung wird allerdings in derPraxis durch weitere Effekte überlagert, dieeher das Gegenteil bewirken. Ein bekanntesBeispiel ist das Re quirements Creeping(schleichender Funk tionszuwachs), dasunter anderem von verschiedenen Faktorenunterstützt wird:

tion verstanden, die mit einer gewissenWahrscheinlichkeit eintreffen kann. Ge -nauso muss auch Aufwandschätzungbetrachtet werden: Als der Versuch, Risiko -faktoren (oben als Unsicherheiten darge-stellt) zu quantifizieren und schließlich denAufwand über ein Intervall von möglichenWerten einzugrenzen. Das Ergebnis einerSchätzung kann bestenfalls eine mehr oderweniger gute Annäherung an die Realitätsein, die sich auch im „Konus der Un -sicherheit“ ausdrückt (siehe Abbildung 4).Die grundsätzliche Idee hinter dieserDarstellung ist, dass zu Projektbeginn eine

schwerpunk t

Abb. 3: Beispiele für Einfluss- und Risikofaktoren.

Abb. 4: Konus der Unsicherheit.

2/2013

dert oder gar ganz vermieden werden. DerKonus existiert nun mal in Projekten undlässt sich nicht wegdiskutieren. Aber essollte sehr wohl ein Ziel sein, durch risiko-mindernde Maßnahmen den Konus mög-lichst rasch schmal werden zu lassen.

Dies ist ein Beispiel dafür, wie dieGestaltung des Entwicklungsprozessesselbst Einfluss auf den tatsächlichen Auf -wand hat: Je früher der Konus enger wird,umso weniger Unsicherheiten verbleibenund umso geringer ist die Wahrschein -lichkeit von Fehlentwicklungen und damitvon Mehraufwänden, die diese Fehlent -wicklungen wieder korrigieren sollen. Es istauch ein Beispiel dafür, dass spezialisierteSchätzmethoden ihre Grenzen haben.Wenn der Entwicklungsprozess selbst cha-otisch abläuft, helfen die besten Methodennichts. Daher sagt auch McConnell in sei-nem Buch über Aufwandschätzung: „Er -war ten Sie nicht, dass Sie Ihre Schätzungenin einem chaotischen Projekt durch bessereSchätzmethoden verbessern können! Besei -tigen Sie erst das Chaos in der Entwick -lung, bevor Sie die Schätzvorgehensweiseverbessern!“ (vgl. [McC06]).

Damit verbleibt eine zentrale Frage: Wiekönnen wir denn den Konus der Un -sicherheit möglichst rasch im Projekt -geschehen verschlanken? Denn das bedeu-tet gleichzeitig eine Minimierung derProjektrisiken und die Beherrschung derProjektaufwände und -kosten.

Unsicherheiten reduzierenBetrachtet man die Unschärferelation, wiesie oben beschrieben wurde, dann stellt sichzwangsläufig die Frage, wie sich dieUnsicherheiten in den folgenden vierFaktorengruppen einzeln reduzieren lassen.

Faktorengruppe „Anforderungen“Der Konus wird kleiner, wenn die Un -sicher heiten in den Anforderungen geringerwerden. Auch hier gilt das GrundprinzipGarbage-In-Garbage-Out: Eine Schätzungkann maximal so genau sein, wie dieAnforderungen genau spezifiziert sind. Dasbedeutet, die Verbindlichkeit der Anfor -derungen muss erhöht werden. Verbind -lichkeit erreichen wir zum Beispiel, indemAnforderungen mit Hilfe von Ab nahme -kriterien messbar und damit testbar spezifi-ziert werden. Anforderungen müssen einemReview unterzogen und von beidenParteien – Auftraggeber und Auftragneh -mer – freigegeben werden. Letzteres sollteerst nach einer Anforderungsvalidierung

erfolgen, um sicherzustellen, dass auch dierichtigen Anforderungen erfasst wurden.Um den Konus möglichst rasch zu verrin-gern, müssen Anforderungen nicht zwangs-läufig vollständig spezifiziert werden, selbstwenn dies theoretisch erstrebenswert wäre.Stattdessen werden in der Praxis häufig ite-rativ mehrere Anforderungs-Baselineserstellt und freigegeben. Die frühe Klärungund Freigabe der Anforderungen – auchwenn es sich nur um eine Teilmenge desGesamtumfangs handelt – ist in jedem Fallerstrebenswert und hilft, Unsicherheiten zuverringern.

Dem Requirements Creeping wird außereiner klaren Ziel- und Anforderungs -definition (freigegebene Anforderungen,die auch Abnahmekriterien umfassen) ambesten mit einem definierten Änderungs-management begegnet, das direkt abProjektbeginn konsequent umgesetzt wird.Für den Entwicklungsdienstleister ist es inder Praxis oft schwierig, einen Schlussstrichunter ein Projekt zu ziehen, etwa weil eskeine oder nur schwammige Abnahme -kriterien gibt oder weil die gesamteAbnahmeprozedur bis zum Schluss unge-klärt bleibt. Beide – die Abnahmevor -gehensweise und die dazugehörigen Ab -nah mekriterien – gehören frühzeitig, d. h.mit dem Projektvertrag fixiert. Ge nauso istauch das Änderungsmanagement zuProjekt beginn festzulegen. Es gibt vor, wiebei sich änderndem Projektumfang durchzusätzlich gewünschte Funktionalität oderbei Änderungswünschen des Kunden vorzu-gehen ist. Bei einem fehlenden Änderungs-management entwickelt der Auftrag geberschnell die Mentalität Value For Free. Dannist es meist schwer, dies wieder umzukehren.Durch ein systematisches und auch gelebtesÄnderungsmanagement entwickelt derKunde ein besseres Verständnis dafür, wasseine Änderungswünsche für Auswir kungenauf den Projektverlauf haben. Dieser Lern -effekt verbessert das Zusam menspiel zwi-schen Auftraggeber und -nehmer deutlich.

Faktorengruppe „Prozess“Ein Projekt oder Prozess wird durchge-führt, um ein bestimmtes Projekt- bzw.

Prozessziel zu erreichen. Lange Projektesind nicht vollständig ausplanbar. Damit istes auch schwierig vorherzusagen, ob dasProjekt wirklich in dem klassischen Pro -jekt management-Konfliktdreieck, beste-hend aus Termine – Kosten – Qualität,erreichbar ist. Unsicherheit im Erreichenvon Projekt- bzw. Prozessziel kann aberdadurch minimiert werden, dass zumindestder Nutzen maximiert wird, der mit demProjekt erreicht werden soll. Heutige agileAnsätze wie Scrum und Kanban basierenletztlich genau auf der konsequentenPriorisierung von Anforderungen bzw. derBetrachtung, welchen Nutzen (oft auch alsGeschäftswert bezeichnet) der Kunde/An -wen der/Auftraggeber durch die Anfor -derungsrealisierung erhält. Aber dasselbegilt nicht nur für agiles Projektmanagement– auch ältere iterative Prozessmodelle, wieetwa der Rational Unified Process (RUP),dachten bereits in diese Richtung:Iterationen sollen derartig geplant sein,dass sie Risiken minimieren.

Unsicherheiten im Schätzprozess werdenauch durch das „Gesetz der großenZahlen“ (vgl. z. B. [McC06]) minimiert.Dieses hilft dem Schätzer selbst dann, wenngrundsätzlich eine hohe Schätzun ge nauig -keit gegeben ist. Die Idee dabei ist: Einegroßes zu schätzendes Objekt – dies kannein ganzes Projekt, Teilprojekt oder auchnur ein Arbeitspaket sein – wird in vielekleinere Schätzobjekte zerlegt. Typischer -weise lässt sich eine große Aufgabe durchZerlegen in viele kleinere Aufgaben einfa-cher überblicken (entspricht dem Divide-And-Conquer in der Programmierung).Dadurch wird auch die Genauigkeit derSchätzung größer. Selbst wenn dieSchätzgenauigkeit pro Schätzobjekt stattbesser nur gleich bleiben sollte, hat dasüblicherweise trotzdem einen positivenEffekt auf die Schätzgenauigkeit: Ist etwadie Schätzgenauigkeit einer großenAufgabe 50 % (Abweichung plus oderminus 50 % um den Schätzwert) und zer-legt man diese große Aufgabe in zumBeispiel zehn kleinere Aufgaben, die wiede-rum jeweils eine Abweichung um 50 %nach oben oder unten haben, so wird die

schwerpunk t

OBJEKTspektrum ist eine Fachpublikation des Verlags:

SIGS DATACOM GmbH · Lindlaustraße 2c · 53842 TroisdorfTel.: 0 22 41 / 23 41-100 · Fax: 0 22 41 / 23 41-199 E-mail: info@sigs-datacom.dewww.objektspektrum.dewww.sigs.de/publications/aboservice.htm

18 19

gesamte Abweichung über alle zehnArbeits pakete geringer als 50 % ausfallen,da sich Schätzfehler nach oben mit Schätz -fehlern nach unten zumindest teilweise aus-gleichen.

Zusammenfassend ist zur Minimierungder Prozessunsicherheiten wichtig: WählenSie ein iteratives oder agiles Vorgehen.Brechen Sie damit große Projekte in kleine-re Teilprojekte, Iterationen oder Sprintsherunter. Definieren Sie hierfür Abnahme -kriterien und sammeln Sie am Ende einessolchen Projektabschnitts Feedback vonKunden oder Anwendern (Teilabnahmeoder Sprint-Review) sowie Rückmeldungenvom Team (Lessons Learned). Die Planungder Projektabschnitte erfolgt streng ge -schäftswertorientiert. Auf Probleme wäh-rend der Projektabwicklung gilt es schnellzu reagieren.

Faktorengruppe „Team“Auch hier können agile Prinzipien gut alsBeispiel dafür dienen, wie sich Unsicher -heiten hinsichtlich der eingesetzten Teamsminimieren lassen. Die Ressourcen-Un -sicherheit wird in Scrum dadurch adres-siert, dass Ressourcen eindeutig auf einProjekt ausgerichtet sein sollten. EinMitarbeiter arbeitet in einem Projekt mitund nicht in fünf (manchmal in der Praxissogar noch mehr). Unsicherheiten in derUnterkategorie „Erfahrung und Wissen“werden in Scrum durch vertikale statt hori-zontale Teams adressiert (Generalistenanstelle von Spezialisten). Im eXtremeProgramming (XP) werden diese Unsicher -heiten durch Praktiken wie beispielsweisePair Programming und Collective Owner -ship adressiert, um das vorhandene Wissenbesser im Team zu verteilen.

In diese Kategorie gehören aber aucheher menschliche oder soziale Phänomene,wie etwa der als Parkinsonsches Gesetzbekannte Sachverhalt: „Arbeit dehnt sichin genau dem Maß aus, wie Zeit für ihreErledigung zur Verfügung steht – und nichtin dem Maß, wie komplex sie tatsächlichist.“ Natürlich hat dieses Phänomen seineGrenzen. Das Phänomen an sich existiertjedoch und hat damit im Projektmanage -ment Auswirkungen auf den Umgang mitden so genannten Pufferzeiten. Üblicher-weise begegnet man der Schätzunge nauig -keit, indem zusätzliche Puffer eingeplantwerden. Allzu häufig argumentierenProjektmanager: „Ich weiß, dass ich oftX % zu niedrig schätze, also multipliziereich die Schätzungen mit diesem Faktor.“Doch genau das ist nach dem Parkin son -

schen Gesetz der falsche Ansatz. DieLösung wäre: Statt mit der Gießkanne beijedem Arbeitspaket X % pauschal alsPuffer einzuplanen, sollten diese realistischgeschätzt (und zeitlich eingeplant) werden.Zur Risikominderung kann dann zumBeispiel gegen Ende eines Release-Zyklusein zusätzliches Arbeitspaket eingeplantwerden, das als Puffer für alle Arbeits -pakete davor dient.

Aber auch das so genannte Studenten -syndrom, das Eliyahu Goldratt (vgl.[Gol97]) beschreibt, gehört in diese Kate -gorie von Faktoren, die vom Grund satz hernur teilweise etwas mit dem Schätz prozessan sich zu tun haben. Sie beeinflussenjedoch, wie sich der Projektverlauf gegen -über dem Plan tatsächlich entwickelt. Damitsind diese Faktoren Risikofaktoren für dasProjekt. Das Studentensyndrom bezeichnetein Verhalten, das (unangenehme) Aufga benverschiebt, anstatt sie zu erledigen. ImProjektgeschäft etwa werden zugesagteTermine nicht eingehalten und als Ursacheeine (scheinbar) schlechte Aufwand schät -zung oder unvorhergesehene (technische)Probleme gesehen. Bis zu einem gewissen(geringen) Grad ist das Studentensyndromsicherlich normal und menschlich. MancheMenschen neigen aber auch persönlichkeits-bedingt verstärkt zu einem derartigenVerhalten. Das Schlimme: Das „vor sich herSchieben“ bedeutet verstrichene, nicht ein-gehaltene Termine. Das verstärkt wiederumdas Gefühl, die ursprüngliche Aufgabe nichterledigen zu können. Dadurch baut sichunter Umständen innerlich Angst bis zueiner völligen Blockade auf. Daraus entstehtletztlich ein Teufelskreis, der mitSelbstdisziplin nur bedingt durchbrochenwerden kann. Meist liefert hier das bereitsangesprochene Zerlegen einer Aufgabe inviele kleine Arbeitsschritte die Lösung. Auchdie genaue Definition von Zielen und dar-aus abgeleiteten Aufgaben, verbunden miteiner prioritätsorientierten Vorgehens weisehelfen, erfolgreich zu sein. Für die agilenMethoden sei ergänzend erwähnt, dass die-ser Aspekt in den Daily-Scrum-Meetingsberücksichtigt ist. Die grundsätzliche Idee inScrum ist dabei, statt sich zum Beispiel ein-mal wöchentlich, jetzt täglich im Team abzu-stimmen. Dabei soll aber natürlich nicht derfünffache Bespre chungs aufwand entstehen.Vielmehr gilt es, sich in kurzen Meetingsabzustimmen (typischerweise 10 bis 15Minuten täglich). Im Vordergrund steht dieFokussierung auf die Aufgaben, die tagesak-tuell am wichtigsten sind. Aufgaben(-pake-te) sind hier auch typischerweise kürzer

geplant als im klassischen Projekt -management.

Faktorengruppe „Technologie“Hierunter sind nicht nur neue Technolo -gien, sondern auch der Umgang mit Archi -tekturen und deren Einflussfaktoren sowieEntwicklungswerkzeuge zu subsumieren.Teilweise ähneln die Lösungsansätze hier-für wieder sehr stark denen zum Faktor„Prozess“: Neue Tools und Technologienführt man beispielsweise durch einVorgehen ein wie Evaluierung – Selektion –Pilotierung – Rollout – Monitoring desTechnologie- oder Tool-Einsatzes. NeueProdukte und Architekturen baut mannach Rapid-Prototyping-Ansätzen auf (inXP die Praktiken „Simple Design“ und„Refactoring“). Auch hier gilt: Bei derAuswahl der umzusetzenden Anforderun -gen, Use-Cases oder User-Storys in eineArchitektur ist nicht nur auf eineMinimierung der Produktunsicherheiten zuachten (etwa durch Proof-of-Concept-Prototypen), sondern gleichzeitig auf eineMaximierung des hinter den Anfor derun -gen liegenden Geschäftswerts.

ZusammenfassungSchätzung und Risikomanagement sindnicht voneinander zu trennen und müssenzusammen betrachtet werden. Einfluss-und Risikofaktoren beeinflussen die Schät -zung erheblich und sorgen in der Konse -quenz dafür, dass der Konus derUnsicherheit sehr weit sein kann. OberstesZiel muss die frühzeitige Minimierung, alsodie Einengung des Konus sein. Diesgeschieht über die Beeinflussung derselbenFaktoren bzw. der Faktorengruppen Anfor -derungen, Prozess, Team und Technologie.Die (scheinbare) Ungenauigkeit der Schät -zung liegt aber nicht nur in der gegebenenUngenauigkeit der genannten Einzelfak -toren, sondern auch in psychologischenAspekten, die außerhalb des eigentlichenprojektbezogenen Schätzproblems liegenkönnen. ■

schwerpunk t

Literatur

[Coh05] M. Cohn, Agile Estimating and Plan -

ning, Prentice Hall 2005

[Gol97] E.M. Goldratt, Critical Chain, Gower

Publishing Ltd 1997

[McC06] S. McConnell, Software Estimation:

Demystifying the Black Art, Microsoft Press

2006