Qualität im Projekt

Drei wesent­li­che Dimen­sio­nen gibt es bekannt­lich im Pro­jekt­ma­nage­ment: Ter­mi­ne, Kos­ten und Ergeb­nis­se. Sie bil­den als das soge­nann­te magi­sche Drei­eck des Pro­jekt­ma­nage­ments die Rand­be­din­gun­gen des Pro­jekts: bis wann soll mit wel­chen Mit­tel­ein­satz was genau in wel­cher Qua­li­tät erreicht wer­den. Wäh­rend Ter­min und Kos­ten ein­fach mess­bar sind, brau­chen die Ergeb­nis­se zusätz­lich eine Defi­ni­ti­on der ange­streb­ten Qua­li­tät. In vie­len Pro­jek­ten wird genau das aber ger­ne ver­ges­sen oder impli­zit ange­nom­men, dass die Errei­chung der Ergeb­nis­se genau­so offen­sicht­lich und leicht mess­bar ist wie Ter­mi­ne und Kos­ten. Ein fol­gen­schwe­rer Fehler.

Nichts ist so dehn­bar wie der Begriff fer­tig. Wann ist ein Kon­zept fer­tig? Wann ein Soft­ware-Modul? Drei Mit­ar­bei­ter wer­den dar­auf min­des­tens vier ver­schie­de­ne Ant­wor­ten geben und kei­ne davon wird sich mit der Kun­den­er­war­tung decken. Was für den einen fer­tig ist, hält der ande­re maxi­mal für einen Pro­to­ty­pen. Ohne einen defi­nier­ten Qua­li­täts­be­griff für die jewei­li­gen Pro­jekt­er­geb­nis­se lässt sich die Ziel­er­rei­chung also weder bestim­men noch steuern.

Wer es ver­säumt zu Pro­jekt­be­ginn Klar­heit über die erwar­te­te Qua­li­tät zu schaf­fen, wird am Ende oft böse über­rascht. Ent­we­der ist der Kun­de unzu­frie­den mit der Qua­li­tät und for­dert Nach­bes­se­rung oder die Kos­ten unnö­tig aus dem Ruder gelau­fen für eine zu hohe Qua­li­tät. Als Pro­jekt­ma­na­ger möch­te ich die­se Risi­ken aber ger­ne mög­lichst früh erken­nen solan­ge ich noch vie­le Hand­lungs­op­tio­nen habe. Dazu brau­che ich Früh­warn­in­di­ka­to­ren und Mess­kri­te­ri­en für die Qua­li­tät der Projektergebnisse.

Gera­de in die­ser Fra­ge nach der Qua­li­tät im Pro­jekt bie­ten uns die agi­len Metho­den wie Scrum eini­ge Hil­fe­stel­lun­gen. Kern­ele­ment des agi­len Vor­ge­hens sind kur­ze Ite­ra­tio­nen in denen Tei­le des Pro­dukts (soge­nann­te Inkre­men­te) fer­tig umge­setzt und vor­ge­führt wer­den. Dadurch erkennt man sehr früh, ob die gelie­fer­te Qua­li­tät zur erwar­te­ten passt und kann ent­spre­chend reagie­ren. In den dabei geführ­ten Gesprä­chen mit dem Pro­duct-Owner und ande­ren Ver­tre­tern des Kun­den klärt sich zudem der Qua­li­täts­be­griff recht schnell und für das gan­ze Team nach­voll­zieh­bar. Dar­über hin­aus kennt Scrum die soge­nann­te Defi­ni­ti­on of Done (DoD) in der Kri­te­ri­en beschrie­ben sind anhand derer bewer­tet wird, wann ein Inkre­ment als fer­tig gilt.

tl;dr

Die Pro­jekt­er­geb­nis­se brau­chen zwin­gend einen defi­nier­ten Qua­li­täts­be­griff. Wer bewusst oder unbe­wusst annimmt, die erwar­te­te Qua­li­tät sei allen Betei­lig­ten ohne­hin klar, erlebt meist eine böse Über­ra­schung. Und das erst ganz am Ende mit nur noch weni­gen Hand­lungs­op­tio­nen. Von agi­len Vor­ge­hens­wei­sen kann man das häu­fi­ge Ein­ho­len von Feed­back zu Teil­ergeb­nis­sen ler­nen sowie das expli­zi­te Defi­nie­ren des Begriffs fertig.

Arti­kel­bild: mt 23 bei flickr.com (CC BY-SA 2.0)