Mit zahlreichen Fußballanalogien und -weisheiten führt uns Alexander Ockl durch ein Praxisbeispiel der Geschäftprozessgestaltung zwischen IT und Fachbereich (Amazon Affilliate Link). Er wählt dabei eine Romanform, wie man sie z.B. von DeMarco´s PM-Klassiker „Der Termin“ (Amazon Affilliate Link) kennt. Neben dem Praxisbeispiel zieht sich die Geschichte eines Revierderbys (Achtung, Fußball!), wie ein roter Faden durch das Buch.

Die anfängliche Projektkrise und die auftauchenden Konflikte werden seziert. Alexander Ockl führt dabei in die Welt der Business Analyse und Geschäftsprozessmodelierung ein. Es wird der Bogen gespannt von Requirements Engineering, ARIS-Modellierung bis hin zu Projektmanagement-Methoden, Qualitätsmanagement und Reifegradmodellen.

Eine gelungene Einführung, die sich angenehm leicht liest, sofern man von der Überdosis Fußball nicht abgeschreckt wird.

Und indirekt liefert Ockl auch einen interessanten Beitrag zum Thema Projekterfolg/Scheitern von Projekten: Das ursprünglich initiierte Projekt scheitert grandios. Das Buch schildert dennoch eine Success Story, denn durch die erfolgreiche Analyse werden viel tiefergehende Veränderungen angestossen, aber hier wird Ockl übertrieben optimistisch:

Es ist gar nicht selbstverständliche, dass die tatsächlichen Probleme so klar identifiziert und auch angenommen werden. Zu guter letzt macht ein Bereichsleiter auch noch Karriere und wird zusätzlich Qualitätsbeauftragter. Das ist für Ockl eine Art Ritterschlag. Der Firmenchef träumt obendrein davon Qualitätsmanagement als Führungsinstrument zu nutzen. Hier verliert mich Ockl komplett. Eine solche Welt besteht wohl vor allem im Wunschdenken von Business Process Management-Anhängern.

Alexander Ockl
Das Spiel. Brennpunkt Geschäftsprozesse – IT und Betrieb in einer Mannschaft. Projektmanagement, Business Analyse und Geschäftsprozessmanagement in der Praxis
München 2010
Addison-Wesley
ISBN 978-3827329066 

Diesmal Ralf Westphal über „Agilität und Kultur“ im Interview mit Patrick Fritz. wie gewohnt hier eine Zusammenfassung:

Eine entsprechende Kultur ist die Voraussetzung, damit sich Agilität in einem Unternehmen durchsetzen kann. Ralf zitiert hierzu den Management-Guru Peter Drucker:

Culture eats strategy for breakfast.

Die Kultur spiegelt sich wieder im Umgang mit Zeit, Fehlern, Fokus und Arbeitsbedingungen.

Agilität hat eigentlich nichts mit SW-Entwicklung zu tun. Ralf meint vielmehr:

It´s a way of life.

Den ganzen Beitrag lesen…

Eine Zusammenfassung zum Thema Lessons Learned liefert Steffen Jung auf Green Light.

Lukas Pustina gibt Tipps zum Thema Logbuch.

Auch auf schlossBlog gab es hierzu schon zwei Beiträge:

• #06 Das gute alte Projekttagebuch/Logbuch
• #283 Projekttagebuch selbst gemacht

Und noch einmal Pawel Brodzinski, der sich mit einem Beitrag von Jennifer Bedell auf PMStudent zum Thema Testmanagement auseinander setzt: Testen kann auch ausufern, wenn der Scope des Projekts aus dem Auge verloren wird und weit über die ursprünglichen Projektauftrag hinaus getestet wird. Zurecht weist Pawel darafhin, dass die Erfüllung von Spezifikationen mitunter noch wenig über die tatsächliche Qualität des Ergebnisses aussagt. Auch wenn alle Anforderungen erfüllt sind, kann der Patient bereits tot sein. Der Test der Spec stelllt quasi den minimalen Testumfang dar,  aber um die Qualität sicherzustellen braucht es „mündige Tester“, die auch nach rechts und links schauen, aber mit Augenmaß, um nicht einfach den Projektauftrag beliebig zu erweitern und die Kosten aus dem Ruder laufen zu lassen.

Pawel Brodzinski bringt es auf den Punkt: Bei aller Methoden-Diskussion – letztlich zählt nur das Ergebnis und dessen Qualität, da sollte es keine Rolle spielen ob das mit agilen oder klassischen Methoden erreicht wurde. Auch die beste Methode ist bei fehlendem Qualitätsbewußtsein unzulänglich. Pfusch bleibt Pfusch!

Eigentlich ist diese Ur-Regel der IT trivial und selbstverständlich. Die Praxis sieht aber anders aus: Werner Kurzlechner berichtet in einem Artikel für das CIO-Magazin, wie Unternehmen selbst im Bereich Business Intelligence (BI) mit der Datenqualität schludern.
Ich plädiere hier auf: Weniger ist mehr! Es ist meist besser den Datentopf samt Auswertungen kleiner zu lassen, aber dafür die Qualität im Griff zu behalten, denn was nutzen die schönsten Auswertungen, wenn sie nicht valide sind?

Sebastian Preuss/ Seibert Media weist in einem lesenswerten Beitrag auf die Bedeutung des Debriefings im Testmanagement hin. Die Tester im User-Test sichern nicht nur die Qualität, wir sollten ihren Einfluss auf das Changemanagement auch nicht vergessen! Ihre Eindrücke und ihr Feedback landen früher oder später bei den Anwendern. Selbst wenn der Test schief lief, können sie bei den Anwendern für Verständnsi und Akzeptanz beitragen.

Mit dem Thema Testmanagement haben wir uns hier auch schon wiederholt auseinander gesetzt:

#195 Testmanagement in IT-Projekten
#187 Umgang mit Testfehlern
#156 Excel Toolset
#153 Your Unit Tests lies to you
#148 Testmanagement in IT-Projekten: Organisation und Ablauf
#145 „Effektives“ Testmanagement
#86 Gute Tester, schlechte Tester

Craig Brown von Better Projects hat eine Taxonomie für Requirements von Don Firesmith ausgegraben. Zugegeben, solche Übersichten sind immer etwas abstrakt und theoretisch, haben aber durchaus ihre Berechtigung, z.B. um einen Anforderungskatalog auf Vollständigkeit und Qualität hin zu überprüfen.

Je besser der Anforderungskatalog, umso überschaubarer werden die erforderlichen Änderungen (jedenfalls im Normalfall).

Natürlich wird es immer Änderungen geben, denn die Welt dreht sich immer weiter und wir wissen heute (hoffentlich) auch mehr als gestern. Paul Ritchie von Crossderry Blog weist darauf hin, dass bei Change Requests häufig eine der wichtigsten Fragen nicht gestellt wird, nämlich welche anderen Anforderungen/Changes möglicherweise auf der Strecke bleiben wenn ein bestimmter Change Request verabschiedet und realisiert wird. Sozusagen die Opportunitätskosten eines CRs.

Nur wer einen lückenlosen Vertrag abschließt und jede Änderung einvernehmlich mit seinem Vertragspartner klärt, erspart sich das Claim Management.
Aber ganz ehrlich: Existiert der lückenlose Vertrag?

Aus Walter Gregorc, Karl-Ludwig Weiner, Claim Management: Ein Leitfaden für Projektmanager und Projektteam, Erlangen 2005, S. 13 (Amazon Affiliate Link)