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)

Teile diesen Beitrag

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.

Schreibe einen Kommentar