Das PM Camp 2011 (3.-5.11.2011) ist vorbei, und es war ein großer Erfolg. Ein ausführlicher Veranstaltungsbericht folgt noch.
Wie angekündigt bestand das Programm beim Camp jeweils vormittags aus vorbereiteten Inputs und Vorträgen, und am Nachmittag folgten die offenen Barcamp-Sessions. Ich habe wieder mal meine Thesen zum Integrierten Projektmanagement präsentiert, da mir gerade dieses Thema ein besonderes Anliegen ist.
Die anschließende Diskussion war durchaus (auch) kontrovers, was mich besonders gefreut hat. Denn derartige Konzeptideen können sich nur entwickeln, wenn sie kritisch geprüft, hinterfragt und auch zum Teil widerlegt werden.
Einige Thesen des IPM-Ansatzes möchte ich kurz erläutern (wenngleich es wohl sinnvoller wäre, bei Gelegenheit dazu mal eine umfangreichere Publikation zu verfassen).
- Es gibt sowohl in klassischen UND agilen Ansätzen gute Praktiken, Methoden und Prinzipien.
- PM ist nicht richtig oder falsch, sondern es funktioniert oder eben nicht. Das „Funktionieren“ hängt von vielen unterschiedlichen Faktoren ab (PM Anwendungsbereich und Kontext, beteiligte Menschen, spezifisches Projekt, Organisationskultur…).
- Richtiges und gutes PM ist in der Regel einfach und schlank sein, damit es funktioniert.
- Es gibt keine Patentrezepte. Das, was im einen Fall bestens funktioniert, kann im anderen Fall falsch sein.
- Integriertes Projektmanagement versucht, einen Orientierungsrahmen für relevantes PM Wissen zu geben.
- Horizontale Integration: Klassisches und agiles PM.
- Vertikale Integration: Menschen in Systemen.
- Die Inhalte und Grundlagen des IPM-Ansatzes sind nicht neu – lediglich die Konfiguration der Themen.
PPT-Folien
Screencast
Zusätzlich habe ich noch einen kleinen Screencast erstellt, um die einzelnen Folien kurz zu kommentieren.
Kritik
Nochmals: Das Modell zum Integrierten Projektmanagement hat den Charakter einer Diskussionsgrundlage. Ich freue mich über zustimmenden oder auch kritische Kommentare, Ergänzungen und Anregungen.
Bin gerade auf der Suche nach Input für die Integration von Scrum und IPMA. Hab z.B. IPMA-PM3 und agiles Projektmanagement gefunden. Dein Modell ist sogar allgemeiner gefaßt und trifft es schon ganz gut für mich. Bauchschmerzen habe ich immer noch mit Festpreisprojekten. Auf diese werden die Kunden erst dann verzichten, wenn sie gelernt haben, daß es sich hier in jedem PM-Kontext um eine Pseudo-Sicherheit handelt, weil die notwendige Präzision in der Voraussage als Problem bestehen bleibt. Mich würde interessieren, inwieweit Du über diesen Aspekt schon mal nachgedacht hast. Haben wir eine Möglichkeit, vielleicht eine „abgeschwächte“ Form des Festpreises über das Modell abzubilden, so daß wir Festpreis-Kunden auch die Agilität schmackhaft machen können? Es gibt ja z.B. die Idee von vorne herein zu sagen, wir versuchen mal, was für den Preis alles geht, aber lieber Kunde Du mußt Dich darauf einstellen, daß vielleicht nicht alles geht. Letztendlich also eine Flexibilität im Ergebnis vom Kunden abverlangt wird. Dafür hat er aber die Möglichkeit bis zum gewissen Grad Changes automatisch mit reinzubekommen, ohne aufwändiges Changemangement.
Hallo Hr. Eschen,
vielen Dank für Ihren Input!
Das Thema der Vertragsgestaltung ist tatsächlich ein „heißes“, doch ich denke, mit ein bisschen Hausverstand ist es recht einfach zu lösen. Wenn sich Auftraggeber endlich eingestehen würden, dass die meisten komplexen Projekte nicht ultimativ planbar sind, müssten sie eigentlich einsehen, dass auch die Vertragsgestaltung mittels Festpreis in der Regel schwachsinnig ist.
Es ist vollkommen klar, dass ein Auftraggeber Planungssicherheit braucht. Dann muss man aber beim Projektinhalt zumindest zwischen Muss- und Kann-/Soll-Kriterien unterscheiden (z.B. mittels MoSCoW).
Weiters ist für erfolgreiche Auftragsprojekte IMMER gegenseitiges Vertrauen der Vertragsparteien notwendig. Wenn dieses Vertrauen fehlt, werden Projekte so oder so schwierig (egal, für welche Form der Vertragsgestaltung man sich entscheidet).
Dass das Thema aber im Kern nicht so schwierig ist, hat beispielsweise Peter Stevens schon 2009 in seinem Beitrag „10 Contracts for your next Agile Software Project“ gezeigt. Denn auch in agilen Projekten sind klare und verbindliche Verträge möglich. Allerdings muss man ehrlich genug sein, dass viele Erkenntnisse erst während des Projektverlaufs entstehen werden.
Viele Grüße!
Stefan