Projektplanung 101: Fortschritt

»Pla­nung ersetzt Zufall durch Irr­tum.« soll Albert Ein­stein gesagt haben und Feld­mar­schall Hel­muth von Molt­ke mein­te dazu nüch­tern-rea­lis­tisch: »Kein Plan über­lebt die ers­te Feind­be­rüh­rung.« Ein Plan ist nur eine Richt­schnur, die Mess­lat­te mit der Abwei­chun­gen fest­ge­stellt wer­den. Der Plan muss des­halb regel­mä­ßig an der Rea­li­tät gemes­sen und kor­ri­giert wer­den. Nichts schlim­mer als ein ver­al­te­ter Plan, heu­chelt er doch trü­ge­ri­sche Sicher­heit, wo schon Blind­flug herrscht.

Handhabbarkeit von Beginn an

Die Qua­li­tät eines Plans und die Erfah­rung des Pla­nen­den zeigt sich beson­ders dar­an, wie leicht die Aktua­li­sie­rung fällt. In den vor­an­ge­gan­ge­nen Tei­len die­ser Serie wur­de auf die Hand­hab­bar­keit des Pla­nes bereits ein­ge­gan­gen. Arbeits­pa­ke­te soll­ten bei­spiels­wei­se nicht zu klein gewählt wer­den, weil ihre Aktua­li­sie­rung sonst sehr müh­sam wer­den kann. Selbst wenn es zunächst kei­nen Unter­schied im Ablauf macht, soll­ten logi­sche Abhän­gig­kei­ten expli­zit im Plan ein­ge­tra­gen wer­den, weil es bei einer spä­te­ren Ver­schie­bung einen Unter­schied machen könn­te. Ein gut aktua­li­sier­ba­rer mit­tel­mä­ßi­ger Plan ist bes­ser als ein schlecht aktua­li­sier­ba­rer per­fek­ter Plan.

Wer viel misst, misst viel Mist

Es steht außer Fra­ge, dass wir in der Lage sein müs­sen, Aus­kunft über den Zustand und den Fort­schritt des Pro­jekts zu geben. Aber wel­che Infor­ma­tio­nen soll­te man dazu regel­mä­ßig ein­sam­meln? Gän­gi­ge Pla­nungs­soft­ware ver­lei­tet uns dazu, je Arbeits­pa­ket den Fort­schritt in Pro­zent ein­zu­tra­gen. Das ist aber nicht ganz ungefährlich.

Betrach­ten wir die ein­fach schei­nen­de Fra­ge, was ein Fort­schritt von 20% bedeu­tet. Die Soft­ware und der Pro­jekt­lei­ter ver­ste­hen dar­un­ter meis­tens, dass 20% der Arbeit geleis­tet wur­den und noch 80% zu leis­ten sind. Der Bear­bei­ten­de ver­steht dar­un­ter aber oft, dass die Ergeb­nis­se zu 20% fer­tig gestellt sind. Lei­der ist das nicht immer iden­tisch. Ers­te­res macht eine Aus­sa­ge über den Auf­wand, letz­te­res über den durch den Auf­wand erziel­ten Gegen­wert. Oft gilt näm­lich das bekann­te Pare­to-Prin­zip: es besagt, dass 80% der Ergeb­nis­se mit 20% des Auf­wands erreicht wer­den, wäh­rend die rest­li­chen 20% der Ergeb­nis­se 80% des Auf­wands ver­ur­sa­chen. (vgl. Wiki­pe­dia)

Ein­fach nach dem Grad des Fort­schritts zu fra­gen birgt also die Gefahr eines Miss­ver­ständ­nis­ses, wenn man nicht expli­zit betont, dass das Ver­hält­nis von bereits geleis­te­ter zu ins­ge­samt zu leis­ten­der Arbeit gemeint ist.

Restaufwände

Statt­des­sen emp­fiehlt es sich also, nach dem Rest­auf­wand für das Arbeits­pa­ket zu fra­gen. Die bereits geleis­te­te Arbeit (Ist-Auf­wand) hat man in der Regel ohne­hin in irgend­ei­ner Art von Zeit­er­fas­sung ver­füg­bar und so ergibt sich der Fort­schritt dann auto­ma­tisch als Ver­hält­nis von Ist-Auf­wand zu der Sum­me von Ist- und Rest­auf­wand. Gleich­zei­tig hat man damit auch den Gesamt­auf­wand für die­ses Arbeits­pa­ket aktua­li­siert, denn es wird oft so sein, dass der geschätz­te Rest­auf­wand zusam­men mit dem Ist-Auf­wand nicht dem ursprüng­lich geschätz­ten Gesamt­auf­wand passt.

Neh­men wir an, wir ste­cken mit­ten in der Bear­bei­tung eines Arbeits­pa­kets »IT-Kon­zept erstel­len«. Der Auf­wand war mit vier Wochen geschätzt und der Kol­le­ge Mei­er arbei­tet nun seit zwei Wochen an die­sem Paket. In einer idea­len Welt müss­te das Paket zu 50% fer­tig gestellt sein. Mel­det der Kol­le­ge Mei­er nun aber einen Rest­auf­wand von drei Wochen, ist klar, dass einer­seits die ursprüng­li­che Schät­zung falsch und dass ande­rer­seits das Paket nun fünf Wochen dau­ern wird, weil der Kol­le­ge Mei­er allei­ne dar­an arbei­tet. Wir haben nun zwei Erkennt­nis­se gewon­nen: ers­tens hat das Paket »IT-Kon­zept erstel­len« einen Fort­schritts­grad von 40% und zwei­tens wird es eine Woche spä­ter fer­tig. Mit ent­spre­chen­den Aus­wir­kun­gen auf den Ter­min­plan oder das Über­stun­den­kon­to von Kol­le­gen Meier.

Der umge­kehr­te Fall, also dass eine Woche weni­ger als ursprüng­lich geschätzt benö­tigt wird, kommt lei­der in der Pra­xis nie vor. Hier gilt das ers­te Par­kin­son­sche Gesetz, wonach die Arbeit sich immer auf die zur Ver­fü­gung ste­hen­de Zeit ausdehnt.

Work expands so as to fill the time available for its completion.

C. North­cote Parkinson

90%-Syndrom

Gera­de weil man anfangs gefühlt gut vor­an­kommt (Pare­to-Prin­zip), wird der Rest­auf­wand zur Fer­tig­stel­lung ger­ne unter­schätzt und damit ein zu hoher Fort­schritt ermit­telt. Die­ses Phä­no­men wird ger­ne als 90%-Syndrom bezeich­net, weil recht schnell 90% erreicht wer­den um dann recht lan­ge auf die­sem Niveau zu verharren.

Miteinander reden

Auch wenn die Ermitt­lung des Fort­schritts prin­zi­pi­ell unscharf bleibt, ist die Zeit zur gemein­sa­men Aktua­li­sie­rung doch gut inves­tiert. Es wird näm­lich über den Plan, die lau­fen­den Akti­vi­tä­ten, Fort­schritt und Rest­auf­wän­de, Pro­ble­me und Abhän­gig­kei­ten gere­det. Die­se Kom­mu­ni­ka­ti­on anhand des Plans, macht den Plan zu einem gemein­sa­men, gibt Ori­en­tie­rung und Ziel. Dar­aus folgt, dass die Aktua­li­sie­rung des Plans im Dia­log erfol­gen soll­te, auch wenn das mehr Zeit erfor­dert. Von einem simp­len Ein­ho­len der benö­tig­ten Infor­ma­tio­nen über E‑Mail oder Pro­jekt­ma­nage­ment-Soft­ware ist eher abzuraten.

Fazit

Den Fort­schritt im Pro­jekt zu erfas­sen ist nicht ein­fach. Durch unge­eig­ne­te Wahl von Arbeits­pa­ke­ten und unklu­ges Vor­ge­hen bei der Erfas­sung wird es sogar noch schwie­ri­ger. Umge­kehrt ist das regel­mä­ßi­ge gemein­sa­me Durch­ge­hen des Plans ein aus­ge­zeich­ne­tes Mit­tel den Plan im Team zu verankern.

Bisher erschienene Teile der Serie »Projektplanung 101«

  1. Arbeits­pa­ke­te rich­tig schneiden
  2. Ver­knüp­fun­gen setzen
  3. Res­sour­cen zuteilen
  4. Mei­len­stei­ne setzen
  5. Fort­schritt mes­sen (die­ser Artikel)
  6. Plan opti­mie­ren
  7. Exkurs: Shu-Ha-Ri

Bild­nach­weis: Das Arti­kel­bild wur­de von Håvar og Solv­eig unter dem Titel „Ruler“ auf Flickr unter einer Crea­ti­ve Com­mons Lizenz (CC BY 2.0) ver­öf­fent­licht.

Share This Post

Von Marcus Raitner

Hi, ich bin Marcus. Ich bin der festen Überzeugung, dass Elefanten tanzen können. Daher begleite ich Organisationen auf ihrem Weg zu mehr Agilität. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibe ich seit 2010 in diesem Blog. Mehr über mich.

4 Kommentare

Immer sel­ber den Fort­schritt über­prü­fen , dann sehen wie es die Kol­le­gen sehen damit hält man das sub­jek­ti­ve rela­tiv klein

Aber wel­che Infor­ma­tio­nen soll­te man dazu regel­mä­ßig einsammeln?
– Kosten
– Zeit
– Qualität
– Risiken
– Res­sour­cen­be­zo­ge­ne Daten
– Scope (scope creep, hope creep, effort creep ;) )

Mir rei­chen die­se sechs Daten­quel­len, um eine inte­grier­te Leis­tungs­be­wer­tung zwi­schen ges­tern und heu­te zu machen sowie eine Pro­gno­se ab heu­te bis Pro­jek­ten­de zu erstellen.

Eine gute Fra­ge, auf die es min­des­tens so vie­le Ant­wor­ten gibt, wie Pro­jek­te, Pro­jekt­lei­ter und Orga­ni­sa­tio­nen. Mei­ne Erfah­rung bezieht sich größ­ten­teils auf Soft­ware-Ent­wick­lungs- oder ande­re IT-Pro­jek­te. Ziel ist es doch in Bezug auf die drei Dimen­sio­nen Kos­ten, Ter­min und Qua­li­tät den momen­ta­nen Stand­punkt zu bestim­men. In Bezug auf den ver­ein­bar­ten Scope, der sich im Lau­fe des Pro­jekts ja bekannt­lich ändert. Inso­fern ist die Basis, dass es immer eine aktu­el­le Auf­stel­lung des ver­ein­bar­ten oder noch zu ver­ein­ba­ren­den Umfangs gibt. Der Haupt­kos­ten­fak­tor ist bei mir fast immer die Arbeit der Mit­ar­bei­ter, also erhe­be ich immer Ist-Auf­wand und Rest-Auf­wand, damit ergibt sich einer­seits eine Aus­sa­ge über Kos­ten und Kos­ten­ab­wei­chung und ande­rer­seits über die Rest­auf­wän­de auch eine Aus­sa­ge über die Abwei­chung in der Zeit. In vie­len Fäl­len ist das schon ein guter Start und mehr oder weni­ger aus­rei­chend. Meist mes­se ich noch die Wert­schöp­fung in Form von fer­tig­ge­stell­ten Anfor­de­run­gen / User Sto­ries (ähn­lich einem Burn­down-Chart in Scrum). Die Qua­li­tät von Soft­ware zu mes­sen ist ein Kapi­tel für sich. Am liebs­ten ist mir ein Test­dri­ven-Deve­lo­p­ment, d.h. die Test­fäl­le ent­ste­hen als Teil der Spe­zi­fi­ka­ti­on vor der Imple­men­tie­rung und es wird sozu­sa­gen gegen die Test­fäl­le pro­gram­miert. Für Risi­ken soll­te man bei allem sen­si­bel sein, sie fest­hal­ten und sys­te­ma­tisch bearbeiten.

Schreibe einen Kommentar