Ein Leser-Feedback bestätigt mich in meiner Einschätzung:

Wir setzen seit einiger Zeit zur Verbesserung der Klarheit und Entwicklung der Fachanforderungen ein Tool ein, das sich sehr bewährt. Das ist m.E.

erheblich wichtiger, als ein Testtool, von dem ich – auch nach langen Jahren – je nach SW (die ja heute hochgradig konfigurierbar ist und de facto strukturbildende Wirkungen für Unternehmen und alle damit verbundenen Org-Einheiten hat) nur wenig halte. Es ist nichts schlimmer, als wenn die Fachbereiche nach langwierigen Prozessen der Definition der Fachanforderungen irgendwann selbst nicht mehr wissen, wer was wann und warum angefordert hat und ob und wie diese Anforderung von wem in Absprache mit wem wann geändert worden ist – was ist dann getestet worden – und wie bekomme ich meine Migrationsaufträge? Dann kann ich mir das Testen im Grunde komplett sparen.

In der aktuellen Ausgabe des Projektmagazins (Abodienst) findet sich ein Beitrag zum Thema Testmanagement in IT-Projekten. Als Autor des Artikels kann ich die Lektüre natürlich nur empfehlen…

Im ersten Teil  des Beitrags werden die Grundzüge des Testmanagements und der Testorganisation anhand der immer wiederkehrenden gemeinsamen Fragen skizziert, die vor der Durchführung eines Tests zu beantworten sind:

1. Wann wird getestet?
2. Was wird getestet?
3. Wie wird getestet?
4. Wer testet?
5. Womit und wo wird getestet? 

Teil 2 des Beitrags mit einem ausführlichen Excel-Template ist derzeit in der Schlußredaktion.

Travis Anderson hat einen lesenswerten Beitrag über den Einsatz von Activity Based Costing im Projektmanagement (Englisch) verfasst. Die Kostenzuordnung auf Aktivitäten orientiert sich dabei an der Work Breakdown Structure (WBS).

So wohl überlegt die Ausführungen sein mögen, habe ich dennoch meine Bauchschmerzen mit dem Einsatz solcher high sophisticated Methoden im Projektmanagement: Natürlich braucht PM Kostenüberwachung und Kostenschätzungen, je deaillierter die Modelle hierfür sind, desto größer wird allerdings auch der bürokratisch/administrative Aufwand. Je größer dieser Aufwand, umso mehr entfernt sich die Sicht von der Projektrealität. Die Administration will mit Zahlen gefüttert werden, also bekommt sie Zahlen. Nach meiner persönlichen Erfahrung finden sich die vermeintlich ausgefeiltesten PM-Methoden meist dort im Einsatz, wo von Projekten im engeren Sinn gar nicht mehr gesprochen werden kann, wo es eher um regelmäßige Tasks oder Aufgaben geht. Ein dynamisches Projektumfeld braucht hingegen eine gewisse „Hemdsärmligkeit“.

Stefan Hagen kann es nicht lassen und setzt mal wieder Malik in Bezug zu Projektmanagement.

Bin da ganz auf seiner Seite, wie diverse Beiträge auf schlossBlog zeigen:
#99 Malik
#10 Noch einmal zurück zu Malik
#04 Management-Werkzeuge
#03 Was heißt schon Management?

Die aktuelle GPM-Studie in Zusammenarbeit mit PA Consulting beschäftigt sich mit Erfolg und Scheitern von Projekten. Aus den zu erwartenden Aussagen hervorzuheben sind folgende Ergebnisse:

Kosten spielen als wesentliches Merkmal für den Erfolg nur eine untergeordnete Rolle

Wer hätte das gedacht… Die Erfolgskriterien für Projekte müssen wieder einmal neu definiert werden…

Und was wir schon immer wußten:

Die Position des Projektleiters, klare Ziele und Kommunikation beeinflussen den Erfolg eines Projektes am stärksten.

… fasst Tulca Ertüzün in einem Beitrag für die Computerwoche im Januar zusammen.

Und dahinter verbirgt sich natürlich mal wieder das magische Dreieck.

Matt Grommes läßt seine Leser in einer bemerkenswerten Artikelserie auf AgileSoftwareDevelopment.com an seinem ersten agilen Projekt mit SCRUM teilnehmen und berichtet über seine Erfahrungen (Englisch):

My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End of Our Project
Part 7: Adventures in Agile Testing
Part 8: 9 Things We Disliked (and Liked) about ScrumWorks
Part 9: Choosing A New Tool – VersionOne
Part 10: 5 Important Issues For Teams
Part 11: A Tale of Two Dark Clouds
Part 12: The Good, The Bad, and The Ugly – Our Retrospectives
Part 13: Reflecting on The Decline of Agile
Part 14: Did We Need A Coach? Does Anyone?
Series Review: So It’s Come To This – The Year In Review
Part 15: The Last Mile
Part 16: Go-Live – The Final Frontier

Lynn Haber philosophiert auf Project Manager Planet über das PMP Certification Game, Sinn und Nutzen einer Zertifierzierung gemäß dem PMI-Standard. Sie zitiert einige Untersuchungen/Umfragen und Experten. Ja, klar, kann eine Zertifizierung Nutzen haben, aber dann sind sich fast alle doch wieder einig, dass die Zertifizerierung nicht das entscheidende Kriterium bei der Auswahl eines PM sein sollte.

Am treffendsten finde ich die Aussagen von Ryan Alderman von Razorfish:

Still, Alderman doesn’t lend too much credibility to the PMP credential alone when hiring project managers. “It’s fine if a job candidate has it and a PMP can be a good project manager.“

But a great project manager, well that’s someone who masters both the art and science of project management. “Most project managers have the science piece down which is what the PMP certification is all about but the art of project management comes with rote experience such as understanding hidden agendas and hidden motivation,” said Alderman. A great project manager must know motivation techniques, how to build a high functioning team and have good intuition.

Stefan Hagen versucht Erfolgsfaktoren aus dem Sport auf Projektmanagement-Belange zu übertragen.

Lesenswert.

PM Hut via pjmb:  5 Tipps für den Umgang mit Projektsponsoren.