Projekte dauern oft länger, sie sind zu teuer oder bieten nicht die versprochene Qualität. Insbesondere junge Führungskräfte, die sogenannten Digital Natives, haben sich daher vom traditionellen Projektmanagement verabschiedet und setzen auf Geschwindigkeit, Vernetztheit und Mobilität.
Als Digital Natives werden zumeist die Personen bezeichnet, die von Kindheit an den Umgang mit digitalen Medien gewöhnt sind. Mittlerweile prägt ein grosser Teil dieser Generation die heute Arbeitswelt und fordert eine Modernisierung traditioneller Arbeitsformen. Die bei digital Natives häufig vorzufindende Lebenseinstellung, herkömmlichen Statussymbole wie Eigenheim, Autos etc. einer mit hoher Flexibilität und Spontanität einhergehenden Selbstverwirklichung vorzuziehen, geben ebenfalls Anlass, Modell und Konzepte der Arbeitswelt hinsichtlich ihrer Langlebigkeit zu hinterfragen. Des Weiteren streben jüngerer Menschen immer mehr dazu, ihr Privatleben und ihre Arbeit möglichst wenig zu trennen, um sich so die nötigen Freiräume für einen ausgewogenen und ihren Wünschen entsprechenden Alltag zu schaffen. Das Motto «Sharing is Caring» rundet die Lebenseinstellung vieler Digital Natives ab und wird durch den ständigen Einsatz digitaler Medien verstärkt.
Betrachtet man die Auswirklungen dieses Generationenwechsels im Kontext von Projekten, stellt sich die Frage, ob herkömmliche, klassische Projektmanagementmethoden, Digital Natives gerecht werden.
Flexible Arbeitsweise trifft auf starre Hierarchien
Gemäss Hanisch (2011) sind die häufigsten Gründe für das Scheitern von Projekten u. a. strukturelle Probleme, Machtkämpfe, Komplexität, Ressourcenmangel, Methodenfetischismus, Kommunikation und Führung. Einige diese Ursachen lassen sich durchaus in der Arbeitsweise von Digital Natives begründen. Die herkömmliche klassische Projektmanagement-Methode setzt u. a. auf starke Termin- und Kostenvereinbarungen sowie starre Projektorganisationsstrukturen, die mit dem Lebensstil vieler Digital Natives nicht immer vereinbar sind. Wenig flexible Strukturen, starre Hierarchien, ein starkes methodengetriebenes Projektvorgehen und ein enger Führungsstil widersprechen der offenen, flexiblen und spontanen Arbeitsweise vieler Digital Natives.
Betrachtet man die Arbeitsweise von Digital Natives weiter, lässt sich schlussfolgern, dass Digital Natives mit Ihrer Arbeitseinstellung durchaus dazu beitragen können, Projekte zukünftig seltener scheitern zu lassen. Insbesondere komplexe Projekte, die weniger zeitgesteuert, sondern stärker von Spontanität und Kreativität getrieben werden, könnten so zu grösserem Erfolg führen. Ebenso besteht die Annahme, dass Projektmitarbeitende, die virtuell an für sie und den Projekterfolg geeigneten Orten und Zeiten arbeiten, zu besseren Projektleistungen beitragen können. Des Weiteren ist ein offener, ehrlicher und freundschaftlicher Umgang innerhalb des Projektteams elementar, sowie Projektleitenden, die ihrem Team die notwendige Selbstführung und Feedbackmöglichkeiten sicherstellen.
Neu ist dieser Ansatz nicht und wird bereits durch das agile Manifest in zahlreichen Unternehmen gelebt. Hierbei zeigt sich, dass Projektmanagement als Methode nicht überflüssig wird, sondern in wesentlichen Teilen auf den modernen Zeitgeist angepasst werden muss, um Projekte erfolgreich führen zu können.
https://www.societybyte.swiss/wp-content/uploads/2019/11/iStock-1181468939_ret.jpg8161284Katinka Weissenfeldhttps://www.societybyte.swiss/wp-content/uploads/2023/05/logo-societybyte-DE.webpKatinka Weissenfeld2019-11-18 11:06:332019-12-03 14:26:57Digital Natives – das Ende des Projektmanagements?
Ähnliche Beiträge
Es wurden leider keine ähnlichen Beiträge gefunden.
Die Digitalkonferenz Connecta der Schweizerischen Post ist am Dienstag mit über 300 Teilnehmenden und über 90 Referierenden aus 12 Ländern erfolgreich über die Bühne gegangen. Die Connecta versammelt jährlich Expertinnen und Experten rund um die Digitalisierung zum Erfahrungsaustausch und Know-how-Transfer. Auch die Berner Fachhochschule war mit vier ExpertInnen der Departemente Wirtschaft sowie Technik und Informatik prominent vertreten.
Eines machte die diesjährige Connecta deutlich: Trotz Digitalisierung ist der persönliche Austausch offenbar immer noch sehr gefragt. Über 90 Referentinnen und Referenten präsentierten in gut besuchten Plenarveranstaltungen und Workshops Trends, Entwicklungen und Erfahrungen aus dem weiten Feld der Digitalisierung. Dabei ging es längst nicht mehr nur um den Onlinehandel – den die Schweizerische Post bei der Lancierung der Connecta vor drei Jahren ins Zentrum gerückt hatte. Fake Science, Cybersecurity oder Mensch-Maschine-Interaktionen sind nur einige der Themen, die an der Tagung in Bern aufgegriffen wurden.
Es muss nicht immer «big data» sein
Kim Tokarski, Leiter Weiterbildung an der BFH Wirtschaft, wandte sich zu Beginn seiner Session zum Thema «Datenbasierte Dienstleistungswirtschaft» mit einer Frage ans Publikum: «Wie entscheiden Sie? Nach welchen Vorgaben und Mustern?» Schnell wurde klar, dass viele Entscheidungen intuitiv fallen – nicht zuletzt aufgrund von Zeitmangel. Eine Grundlage für Entscheidungsfindung ist aber immer auch die Datenanalyse. «Hier herrscht oft die Meinung, dass diese Analyse teuer und zeitaufwändig ist», sagte Tokarski. «Das stimmt aber heute nicht mehr so absolut.» Anhand verschiedener Beispiele zeigte er auf, wie mit einfachen, zielgruppenspezifischen Applikationen Mehrwert geschaffen werden kann. So hat ein Mitarbeiter von Tokarski ein Dashboard für einen Studiengang gebaut, mittels dem Studierende sich ihren Wunschstudienplan zusammenstellen können und sofort sehen, ob es Zeitüberschneidungen zwischen einzelnen Veranstaltungen gibt. «Das zu bauen, hat eine Stunde gedauert», erklärte er. «Aber das Departement Wirtschaft hat drei Jahre darauf gewartet.» Sein Fazit: small is beautiful. «Manchmal reichen ganz simple Sachen, um was zu verbessern. Damit schafft man Kundenzufriedenheit.» Und er ermutigte sein Publikum auch, eine allfällige Scheu vor Datenlösungen abzulegen. «Wir hatten bei uns schon Leute, die noch nie was mit IT zu tun hatten. Nach zwei Tagen konnten sie ein einfaches Dashboard bauen.»
Schützenswerte Privatsphäre
Wenn es um Daten geht, ist die Frage nach der Sicherheit nicht weit weg. Dieser Frage widmete sich Eric Dubuis, Leiter der Abteilung Informatik und des Research Institute for Security in the Information Society (RISIS) an der BFH Technik und Informatik. «Die Privatsphäre ist Teil der IT-Sicherheit», betonte er. «Und wir dürfen diesbezüglich nicht kapitulieren.» Seine Botschaft: «Datensicherheit und Privatsphäre unter einen Hut zu bringen, ist zwar manchmal schwierig, aber machbar», sagte er. Wie das funktionieren könnte, zeigte er anhand des öffentlichen Verkehrs. Heute können alle noch selber entscheiden, ob sie ihr Ticket an einem Automaten anonym beziehen oder Applikationen wie fairtiq oder lezzgo nutzen und den jeweiligen Anbietern damit automatisch personalisierte Informationen zu ihrem jeweiligen Aufenthaltsort preisgeben. Künftig – so Dubuis Prognose – ist die Nutzung des öffentlichen Verkehrs vielleicht nur noch mit dem Smartphone möglich. «Wir haben deshalb nach Lösungen gesucht, die den Anbietern das personalisierte Tracking der Nutzerinnen und Nutzern nicht erlaubt.» Die BFH-Forschenden sind fündig geworden, und zwar mit der Kombination zweier Informatik-Bausteine, nämlich der Gruppensignatur und der homomorphen Verschlüsselung. Damit kann zwar ermittelt werden, welche Dienstleistungen ein Pendler bezogen hat, nicht aber zu welchem Zeitpunkt er sich wo aufgehalten hat. Das Tracking würde also entpersonalisiert. Sein Fazit: «Um die positiven Seiten der Digitalisierung ausnützen zu können, braucht es oft neue Lösungsansätze.»
Vernetzte Städte
Neue Lösungsansätze sind auch gefragt, wenn es um die Stadt der Zukunft geht. Wohin uns die digitale Transformation führt, zeigte Stephan Haller vom Institut Public Sector Transformation der BFH Wirtschaft in seinem Workshop «Auf dem Weg zur digitalen Stadt» auf. Haller hat unter anderem an einem europäisch-japanischen Forschungsprojekt zu «smart cities» mitgearbeitet. «Wenn von ,smart cities› die Rede ist, gibt es zwei Visionen», sagte er zu Beginn seiner Präsentation. «In der einen ist alles grün und friedlich, alle sind happy. Auf der anderen Seite steht die Totalüberwachung des Bürgers, ein Strafsystem für Fehlverhalten – da will ja niemand wirklich hin.» Es gehe vielmehr darum, die Lebensqualität zu erhöhen. «Deshalb ist es nicht nur ein Technologie-Thema», so Haller. «Die Technologie dient lediglich der Unterstützung.» Die digtale Transformation betreffe zwar die ganze Gesellschaft, aber gerade in den Städten mit ihrer zunehmenden Bevölkerung manifestierten sich viele Herausforderungen zuerst, so etwa die Umweltbelastung und der Ressourcenverbrauch. Deshalb richtet sich das Interesse der Forschung auch auf die Städte. In der Schweiz seien heute zwar viele Städte auf dem Weg zu einer «smart city», blieben aber oft in einzelnen Pilotprojekten hängen. «Wir müssen dahin kommen, dass wir voneinander lernen», sagte er. «Und zwar auch bezüglich technischer Lösungen. Damit werden die Kommunen weniger abhängig von Technologiegiganten.» Diesen Vernetzungsgedanken bilden verschiedene internationale und nationale Plattformen ab – in der Schweiz etwa der «smart city hub». Zu Hallers Bedauern sind in der letzteren bis jetzt nur Deutschschweizer Städte vertreten. Dafür laufen Bestrebungen, das Monitoring zu verbessern, also abzubilden, was in Bezug auf die «smart city» schon erreicht wurde. «Werkzeuge dafür sind in der Entwicklung», so Haller.
Wie Digital Natives arbeiten
Eine Bevölkerungsgruppe dürfte besonders involviert im Aufbau der «Stadt der Zukunft» sein: Die «Digital Natives». Sie standen im Zentrum von Katinka Weissenfelds Präsentation. Die BFH-Dozentin für Projektmanagement stellte die Frage ob die nach 1980 geborenen das Ende des Projektmanagements eingeläutet haben. Um das zu illustrieren, stellte sie in einem fiktiven Beispiel zwei Mitarbeitende eines Unternehmens nebeneinander, eine junge Frau und einen älteren Mann. In diesem Beispiel zeigte sich rasch, welche Probleme auftreten können, wenn die zwei Generationen aufeinandertreffen. «Digital Natives erwarten von der Arbeit, dass sie Spass macht und sinnstiftend ist. Sie arbeiten schnell, ortsunabhängig und kommunizieren direkt», so Weissenfeld. Multi-Tasking sei wichtig, ebenso ständige Erreichbarkeit feste Arbeitszeiten gibt es nicht. Viele Projekte hingegen seien durch starre Strukturen, klare Hierarchien, vorgegebene Prozesse und Budgetpläne sowie Methodenfetischismus geprägt. «Hier finden sich die Digital Natives nicht wieder», betonte Weissenfeld.
Digital Natives orientierten sich vielmehr an den Leitsätzen des «agilen Manifests» (das aus der Informatik stammt). Sie lauten:
Das Individuum steht über Prozessen.
Das System ist zentral.
Das Kundenwohl steht über dem Vertragsabschluss, das heisst, die Arbeit kann auch schon anfangen, wenn ein Vertrag noch nicht abgeschlossen ist.
Und schliesslich: Veränderung ist erwünscht.
Ist also das klassische Projektmanagement ein Relikt vergangener Zeiten? Weissenfeld beantwortete diese Frage diplomatisch: «Nein, Digital Natives stehen nicht für das Ende des Projektmanagements sondern für den Aufbruch in ein agiles Projektmanagement.»
https://www.societybyte.swiss/wp-content/uploads/2019/10/Connecta19_Keynote-scaled.jpg12801920Astrid Tomczakhttps://www.societybyte.swiss/wp-content/uploads/2023/05/logo-societybyte-DE.webpAstrid Tomczak2019-10-24 10:16:282019-10-24 10:33:35Von Digital Natives und datenbasierten Dienstleistungen – BFH-Forschende an der Connecta 2019
Ähnliche Beiträge
Es wurden leider keine ähnlichen Beiträge gefunden.
Im Projekt-Management stehen die Projekt-Organisation und die Organisation der Abläufe im Vordergrund. Abgrenzung und Abstimmung mit anderen Lösungen und Vorhaben sind für einen Erfolg ebenso wesentlich; hier können Architektur-Methoden nachhaltig unterstützen.
Einleitung
Im klassischen Projekt-Management gehört es zur Initialisierungsphase eines Projekts, dass der Kontext evaluiert und Anforderungen erhoben werden. Der Fokus auf einzelne Projekte ist insbesondere in grossen Organisationen wenig nachhaltig, einerseits, weil gewisse Grundlagen immer wieder abgeklärt werden, andererseits, weil kaum projektübergreifend gemeinsame Anforderungen erkannt werden. Dadurch entstehen Insellösungen, die gerade so weit reichen, wie das nähere Umfeld des Projekts einbezogen wurde.
Um die verschiedenen Projekte und die dabei entstehenden Anwendungen in einem Unternehmen aufeinander abzustimmen, sind Methoden der Unternehmensarchitektur (um Missverständnisse zu vermeiden oft mit „Enterprise Architecture“ bezeichnet) geeignet. Damit können Anforderungen für ein Portfolio von Lösungen projekt-übergreifend bearbeitet werden, sodass die jeweiligen Realisierungen für sich fokussiert und Interaktionen zwischen Anwendungen gut identifiziert und spezifiziert sind. Damit leisten Architektur-Methoden einen essentiellen Beitrag für eine nachhaltige Steuerung von Projekten und für die Realisierung übergreifender, langlebiger Lösungen.
Wozu Architektur?
Die IT-Architektur befasst sich mit Software-Systemen, die aus verschiedenen miteinander kommunizierenden Software-Komponenten bestehen. Diese Umgebungen werden ständig verändert und neuen Bedürfnissen, Anforderungen und auch Technologien angepasst. Methoden der IT-Architektur unterstützen diese Veränderungen, dabei dienen sie den Strategien des Unternehmens und leisten damit einen wertvollen Beitrag zur Erreichung der Unternehmensziele.
Eine IT-Architektur beschreibt die grundsätzliche Organisation eines IT-Systems, sie definiert, spezifiziert und beschreibt das IT-System mit seinen Komponenten sowie deren Beziehungen und Abhängigkeiten. Architektur-Entscheide bezüglich Funktionalität, Systeme und Produkte sind ein wichtiger Aspekt, weil einmal getroffene Entscheide später nicht mehr leicht geändert werden können, ja oft praktisch unveränderbar sind. Weiter sind Anforderungen und Einschränkungen zu berücksichtigen, womit Aspekte wie Machbarkeit, Kosten und Risiken ebenfalls im Rahmen der Architektur betrachtet werden.
Hauptaufgabe des Architekten ist Business und IT in Einklang zu bringen und die unterschiedlichen Sichten dieser beiden Seiten zu überbrücken. Dabei helfen Methoden der IT-Architektur wesentlich, die Komplexität der Gegebenheiten durch Abstraktion und Eliminieren von Details zu reduzieren. Das führt zu Darstellungen und Sichten, die besser diskutierbar sind und damit zu Lösungsansätzen, die die Komplexität adäquat abbilden.
In Kürze trägt die IT-Architektur dazu bei, dass die richtigen Dinge adäquat und korrekt ausgeführt werden (in amerikanischer Kürze: „doing the right things right“; diese Aussage ist eine Variante von Peter Druckers „Efficiency is doing things right; effectiveness is doing the right things.“).
Ohne Scope geht es nicht!
Ein wesentlicher Aspekt, um die „richtigen Dinge“ zu tun ist die Abgrenzung der einzelnen Anwendungen und damit insbesondere der Projekte. Die IT-Architektur bestimmt für jede Anwendung und jedes System den Scope zusammen mit dem Kontext. Mit dem Scope wird definiert, was von einem System, einer Anwendung und damit von einem Projekt gelöst wird und was nicht. Dies schliesst ein, dass die Interaktionen mit den benachbarten Systemen, Anwendungen etc. identifiziert und beschreiben werden. Dabei ist eine Portfolio-Sicht massgebend, die anzeigt, wo welche Anforderungen erfüllt werden.
Erfahrungen vieler Projekte zeigen, dass ohne eine klare Bestimmung des Scope und ohne entsprechende Identifikation der Schnittstellen zu benachbarten Lösungen und damit Projekte rasch in die Irre gehen können. Es genügt dabei nicht, in einer Liste die Inhalte aufzuzeigen, es muss entsprechend sichtbar gemacht werden. Eine grafische Darstellung, von verschiedenen Architektur-Methoden als «Kontext-Diagramm» bezeichnet, illustriert solche Zusammenhänge.
Aus der Perspektive der Unternehmensarchitektur wird entschieden, welches System bzw. welches Projekt entsprechende Aufgaben übernimmt. So kann das Management eines Portfolios von Informatik-Lösungen auf eine nachhaltige Grundlage gestellt werden. Die Steuerung über die Unternehmensarchitektur fokussiert die einzelnen Vorhaben und sorgt für eine nachhaltige Abstimmung der Lösungen. Damit können Architektur-Methoden aktiv zu einer adäquaten Definition des Scopes der einzelnen Vorhaben beitragen.
Architektur-Übersichten
Im Rahmen der IT-Architektur werden verschiedene Sichten eingesetzt (so wie ein Gebäude auch mit verschiedenen Ansichten dargestellt wird). Die Darstellung des Scope und des Kontexts ist somit eine Sicht, sie wird ergänzt durch eine Übersicht der verschiedenen Komponenten einer Anwendung bzw. eines Systems. Dabei wird u.a. auch erkannt, wenn verschiedenen Lösungen dieselbe Grundlage (z.B. Kommunikation oder Datenbank) verwenden.
Eine Architektur-Übersicht zeigt die innere Struktur einer Lösung, einer Anwendung bzw. eines Systems auf und benennt die wesentlichen Bausteine bzw. Komponenten. Eine solche Übersicht zeigt auch die wesentlichen Schnittstellen zu anderen Anwendungen auf. Eine grafische Darstellung, von verschiedenen Architektur-Methoden als «Architektur-Übersicht-Diagramm» bezeichnet, illustriert solche Zusammenhänge.
Aus einer Unternehmenssicht ist dabei zentral, dass damit Insel-Lösungen verhindert werden und keine Doppelspurigkeiten aufgebaut werden. Eine systematische Darstellung der Architektur-Übersichten verhindert, dass Anwendungsteile mehrfach realisiert werden oder Basis-Software mehrfach beschafft wird; dabei hilft wiederum eine Portfolio-Perspektive.
Heutige Technologien und eine Service-Orientierte Architektur (SOA) unterstützen Interaktionen zwischen Anwendungen und Systemen wesentlich. Dabei stellen Services einer Anwendung deren Information und Funktionalität einem grösseren Kreis von Nutzern zur Verfügung. Auf der einen Seite werden Services mit entsprechenden Schnittstellen (Web-Services, APIs) angeboten, die von einer anderen Seite aufgerufen werden können. So können viele Nutzer auf Services eines Anbieters zugreifen. Architektur-Methoden unterstützen den Aufbau und das Management eines Services-Portfolios.
Schlussfolgerungen
IT-Architektur kann Projekte und Entwicklungsprogramme nachhaltig bei der Steuerung der Vorhaben unterstützen. Sie liefert Inhalte und stellt Zusammenhänge dar. Deshalb sollten Projekte nicht ohne eine Architektur-Perspektive unternommen werden.
https://www.societybyte.swiss/wp-content/uploads/2018/05/iStock-895781648_ret-scaled.jpg12621920Hans-Peter Hoidnhttps://www.societybyte.swiss/wp-content/uploads/2023/05/logo-societybyte-DE.webpHans-Peter Hoidn2018-05-29 12:12:392018-05-29 12:12:39Ohne Architektur kann es kein nachhaltiges Projekt-Management geben
Ähnliche Beiträge
Es wurden leider keine ähnlichen Beiträge gefunden.
«Agile or waterfall, that is the question». Abgegriffener geht’s nimmer, aber viel zu viele Diskussionen drehen sich nach wie vor um diesen Spruch. Allein, die blosse Polarisierung bringt uns nicht wirklich weiter. Was aber, wenn wir einen echten Lernprozess durchliefen und zu zwei banalen Erkenntnissen kämen: 1. Es kommt drauf an und 2. Zusammen ginge es besser.
Kennen Sie Monty Pythons epochales Werk «The Meaning of Life»? Die berühmte Szene in einer grauen, düsteren Strasse in Bradford, Yorkshire? Auf der einen Seite der Strasse wohnen die C (die Coolen), ein buntes, agiles und furchtbar fruchtbares Volk, das sich vehement und singend gegen die Verschwendung wehrt und auf der anderen Seite der Strasse leben die P (die Planer)[2]: langweilige, graue Figuren, mehr oder weniger unfruchtbar, und ohnehin nichts verschwendend.
Genau dieses Bild befällt mich immer auf subversive Weise, wenn wieder irgendwo die Diskussion um die Vorzüge und Nachteile von agilen gegenüber traditionellen Projektmanagement-Methoden losbricht.
Während allerdings die Polarisierung der C und P bei Monty witzig und humorvoll (zugegeben als tiefschwarzer britischer Humor) daherkommt, ist dieselbe Polarisierung von Agilen und Wasserfällen dumpf, humorlos und (sorry Monty, diesmal gehört das Wort mir) absurd.
Entsorgung von Schwachsinn tut not (I): Das Wasserfallmodell ist nicht
Genauso wie die amerikanische Regierung 2003 der ganzen Welt weismachte, dass Saddam Hussein über Massenvernichtungsmittel verfügt haben soll, bis sie den Krieg herbeigeschwatzt hatten, reden uns die ganz Agilen schon viel länger ein, dass die zu verdammende Methode die ‘Wasserfallmethode’ sei. Sie haben bis heute nicht verstanden, dass der erste, der die angebliche ‘Wasserfallmethode’ beschrieb[3], a) das Wort ‘Wasserfall’ in seinem Papier nie erwähnte, b) festhielt, dass er die Umsetzung eines solchen Verfahrens als ‘… risky and invites failure’ beurteilte und c) folglich nicht lineare, sondern iterative Methoden propagierte. An guten Feindbildern muss man nur lange genug festhalten, dann werden sie wahr und der Krieg kann beginnen. Sprechen wir deshalb besser von traditionellen oder iterativen Methoden, statt von Wasserfall und ähnlichem Schwachsinn.
Entsorgung von Schwachsinn tut not (II): Wahr und falsch sind auch nicht
Jeff Sutherland, der wohl bekannteste Missionar von SCRUM (und ehemaliger Kampfpilot in Vietnam, was vielleicht das Eine oder das Andere erklärt), der populärsten agilen Methode, lässt sich in seinem Buch ‘SCRUM: The Art of Doing Twice the Work in Half the Time’ (2014) über Gantt-Charts, den Balkendiagrammen also, mit welchen ‘Wasserfallprojekte’ gerne beschrieben werden, aus: «The only problem with them is that they are always, always wrong». Zwei Seiten später sagt Sutherland über ‘seine’ Methode: «Now it is the only way proven to help projects like these…”. Sutherland hat recht, nur geht der Dreh andersrum! Mit einer Projektmanagementmethode kann man Modelle von Vorhaben bilden und dass Modelle allesamt falsch sind, hat der berühmte George Box schon 1978 festgehalten: «All models are wrong, but some are useful».
Und umgekehrt wäre ja überhaupt nie ein Projekt gelungen, bevor SCRUM erfunden war.
Also lassen wir die rhetorischen Kraftmeiereien (Draufhauen statt Denken) und wenden uns der Lösung des Problems zu. Denn längst nicht alles, was die Menschen mit traditionellen Methoden hergestellt haben und immer noch herstellen, war/ist ein Desaster und längst nicht alles, was die Menschen mit agilen Methoden bauen, ist das Himmelreich.
Es wird schon so sein, dass die Traditionellen allzu lange ihre Methoden vom Hundertsten ins Tausendste verfeinert, erweitert und ergänzt haben und dabei übersehen oder verschlafen haben, dass sich der Fokus längst von Projekt per se hin zum Kunden und zum Produkt bewegt hat. Bis 2001 mit dem Agilen Manifest[4] eine pointierte, aber wohldurchdachte Richtungskorrektur eingeleitet wurde. Und es wird wohl auch so sein, dass vor allem die hard-core Agilen die konservativeren Teile (die Werte auf der ‘rechten Seite’) des Agilen Manifests gleich am Stück über Bord warfen und fortan jede Schraube mit dem Hammer einzuschlagen gedachten. Das unablässige und streng getaktete Streben nach dem Minimum (sic!) Viable Product produziert allerdings meist später mit viel Geld zu behebende Technische Schulden, obwohl der vorerwähnte Scrum-Papst Jeff Sutherland in seinem Buch dem Thema ‘Waste is a crime’ ein ganzes Kapitel widmet und darin in einem Abschnitt festhält ‘Do it right the first time’! Was sich in der einen Situation als durchaus logisch darstellt, erweist sich einen Moment später als Widerspruch.
Und zweifellos hat es in der Vergangenheit häufig zu lange gedauert, bis man einem sich abzeichnenden Misserfolg den Stecker gezogen hat, aber genauso fraglich ist es, wann das ‘Fail fast, fail often, fail forward’-Mantra nur eine dummdreiste Ausrede ist oder ein Vorhaben tatsächlich vorwärtsbringt.
Es trifft einmal mehr zu, was fast immer zutrifft: Es kommt drauf an!
Nicht einmal bei Socken gilt «One size fits all», wie kann man dann bei Projektmethoden solche oder ähnliche Erwartungen haben? Es kommt eben drauf an, welches Problem es zu lösen gilt und welches die dafür am besten geeignete Methode ist. Und wir tun gut daran, von den verschiedenen Methoden zu lernen, sie in geschickter und nutzbringender Weise zu kombinieren und zu nutzen.
Einigkeit herrscht mittlerweile darüber, dass prinzipiengeleitete Kollaboration besser funktioniert als wenn starre Regelwerke Teams in Ketten legen. Das führt uns direkt zu einigen Fundamentalprinzipien des Projektmanagements:
Tailoring So nannte man früher einmal das Prinzip des Anpassens der Prozesse und Werkzeuge an das zu lösende Problem. Tailoring ist aktueller denn je! Immer. Überall. Bei den Traditionellen und bei den Agilen.
Planung (die Lieblingszielscheibe der militant Agilen…)
Egal wie sehr wir mit einem Projekt unbekanntes Terrain betreten, wie wenig wir und unser Kunde zu Beginn eines Projekts wissen, wie unvollständig der Product Backlog ist und wie sehr wir uns auf Kundenwünsche einlassen wollen, wir kommen um ein Minimum an Planung nicht herum. Lars Vollmer hat das treffend beschrieben; «… Aber andererseits gibt es dennoch keinen Grund, Planung gering zu schätzen. Es ist nämlich so: Es gibt in jeder Zukunft einen bekannten und einen unbekannten Teil. Für den bekannten können Sie planen, für den unbekannten müssen Sie sich gut vorbereiten. Die Klugheit besteht darin, das eine vom anderen zu unterscheiden…»[5]Das Problem, dass sich Traditionelle oft der Überplanung hingeben und Agile notorisch unterplanen, ist bekannt und lässt sich lösen: durch Austausch und Zusammenarbeit der beiden Lager.
Schätzungen Wie wir’s auch drehen, wir kommen um angemessene Schätzungen (Aufwände, Kosten, Zeitdauern) nicht herum, wir brauchen Schätzungen und kontinuierlich verbesserte Schätzungen, um eine halbwegs vertrauenswürdige Planung hinzukriegen. Ausschliesslich relative Schätzungen (à la Planning Poker) helfen nur bedingt, spätestens wenn der Kunde eine ‘Hausnummer’ will, um zu wissen, wie tief und wann er in seine Tasche greifen muss, sind auch absolute Grössenordnungen gefragt.
Zusammenarbeit Zugegeben, vor allem die Traditionellen haben sich zu oft und zu sehr nur auf Kosten, Termine und Umfang des Projekts konzentriert und sich zu wenig um den Kunden, sein Bedürfnis und das dereinstige Produkt gekümmert. Obwohl alle haargenau wissen, dass die intensive Zusammenarbeit, der direkte und dauernde Austausch und ebenso die dauernden Rückmeldungen (bidirektional!) für den Projekterfolg und für die daraus entstehenden Produkte und Werte massgebliche Schlüsselfaktoren sind.
Projekt vs Produkt Noch heute ist bei vielen Traditionellen fest verdrahtet, dass der Projekterfolg im Vordergrund steht und alles, was danach folgt (Produkt, dessen Akzeptanz, Betriebs- und Wartungskosten etc.), von sekundärer Bedeutung ist. Diese Haltung ist in mehrerlei Hinsicht schlicht falsch. Was nützt mir ein hervorragend abgewickeltes Projekt, wenn der Markt das entstandene Produkt nicht zur Kenntnis nimmt, nicht akzeptiert, nicht kauft oder dieses nicht erfolgreich betrieben werden kann? Ford Edsel (1957) und die Suchmaschine Alta Vista (1995) sind nur zwei bekannte Beispiele für solche Dramen. Es braucht mehr für den Erfolg, viel mehr. Das Verständnis für eine entsprechend ausgebaute Zielhierarchie ist vorhanden, sie gilt für die Agilen wie für die Traditionellen.
Time-to-market Keine Frage, der Druck und die Geschwindigkeiten, rasch Innovationen umzusetzen und auf den Markt zu bringen, hat in den letzten Jahren massiv zugenommen. Oft sind wenige Tage bis Wochen Vorsprung auf die liebe Konkurrenz matchentscheidend. Da kann es durchaus sein, dass agile Verfahren helfen, den Wettlauf mit der Zeit zu gewinnen. Aber: nicht immer ist Time-to-market das entscheidende oder gar das einzige Erfolgskriterium. Gerade wenn man besser als die etablierte Konkurrenz (neudeutsch: disruptieren) sein will, gelten ganz andere Massstäbe und Faktoren wie bessere Qualität, besseres Kundenerlebnis, besseres Marketing, höhere Profitabilität etc. Hätte sich die Handelsplattform Siroop mehr Zeit genommen, einen besseren Namen zu suchen, bessere Werbung zu machen, besseres Marketing zu betreiben, hätte sie sich vielleicht gegen die etablierten Plattformen durchsetzen können, aber offensichtlich hat man sich die Zeit für ein besseres Produkt nicht genommen. Interessant wird auch sein, wie der Fall Tesla ausgehen wird. Es ist zwar cool, wenn man als Europäer seinen Tesla irgendwo in den USA per Handy öffnen kann, aber noch cooler wäre es, wenn das Auto auch wie ein Auto nach den Regeln des Gewerbes gebaut wäre.
Kleine Projekte Verschiedene Untersuchungen haben gezeigt, dass die sequentielle (wasserfall-mässige?!) Abwicklung von kleineren Projekten gegenüber der monolithischen Durchführung von Megaprojekten massive Vorteile aufweist, dies sowohl bei der Projektentwicklung, bei der Stabilität des Vorhabens, bei Wartung und Unterstützung des späteren Produkts. In diesem Punkt sind die Agilen klar im Vorteil, die kleinteilige Entwicklung ist ihr Standard. Umgekehrt fragt man sich natürlich, weshalb trotz deutlich geringeren Erfolgschancen, immer wieder Megaprojekte bis hin zum Typus Mission Impossible in Auftrag gegeben werden. Das Prinzip der kleinen Projekte gilt genauso für Agile wie für Traditionelle.
Das Team Das Zitat «Culture eats strategy for breakfast» wird Peter Drucker zugeschrieben. Unabhängig davon, ob Drucker dies tatsächlich gesagt hat, ist nachvollziehbar, dass gutes Teamwork enorm weit trägt und umgekehrt ein dysfunktionales Team ein Projekt rasch und zuverlässig an die Wand fahren kann. Damit sind wir beim allerwichtigsten Faktor für den Projekterfolg und wie schon zuvor illustriert, gelten auch die Prinzipien guter Teams sowohl für die Agilen wie für die Traditionellen.Wenn es nämlich gelingt, Teams zu schweissen, die verstehen, worum es im Kern bei einem Projekt geht, ohne dass man den einzelnen Teammitgliedern sagen muss, was sie zu tun haben, die sich also selber organisieren, die voneinander und füreinander lernen, die sich an gemeinsam festgelegte Prinzipien halten, dann ist die allerwichtigste Bedingung für den Projekterfolg erfüllt.
Also zurück zum Tailoring, das in diesem Fall auch gerne Cherry-Picking genannt werden darf
Lasst uns doch agile und traditionelle Techniken und Methoden gezielt immer dort einsetzen, wo sie uns am meisten nützen und helfen. In der Tendenz sind das agile Methoden, wenn wir die unbekannten Teile der Zukunft erschliessen müssen und traditionelle Techniken, wenn wir bereits mehr über die Zukunft wissen.
Und zurück zu Monty
Zum Schluss der Strassenszene bewegen sich die C und die P zusammen singend über die triste Bradforder Strasse in eine bessere Zukunft.
Allerdings trennen sich kurz danach unsere Wege von jenen von Monty Python. Während es bei «The Meaning of Life» zunehmend absurder zu und her geht, begeben wir uns friedlich und gemeinsam auf die Strasse des «Meaningful Life Cycle».
[1] Visionär wie die Truppe war, hat sie sich bereits 1969 mit Python befasst, also gut 20 Jahre bevor man das Potential von Python für Datenauswertungen erkannt hat…
[2] Eigentlich heissen sie anders, aber ich will mich jetzt nicht auch noch aufs religiöse und/oder politische Glatteis begeben.
[3] Winston P. Royce; Managing the Development of Large Software Systems; IEEE Wescon, 1970
[4]Manifesto for Agile Software Development: We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
[5] Lars Vollmer; Wie sich Menschen organisieren, wenn ihnen keiner sagt, was sie tun sollen; Gorus Certified Publications; 2. Auflage, 2018
https://www.societybyte.swiss/wp-content/uploads/2018/05/shutterstock_731443525-scaled.jpg12801920Ernst Menethttps://www.societybyte.swiss/wp-content/uploads/2023/05/logo-societybyte-DE.webpErnst Menet2018-05-25 12:25:222018-05-29 11:47:02Warum die Agilen mit Wasserfällen nicht klarkommen (und umgekehrt) und warum sie miteinander Frieden schliessen sollten
Ähnliche Beiträge
Es wurden leider keine ähnlichen Beiträge gefunden.
«Hans hatte sieben Jahre bei seinem Herrn gedient, da sprach er zu ihm ‹Herr, meine Zeit ist herum, nun wollte ich gerne wieder heim zu meiner Mutter, gebt mir meinen Lohn.’»
So beginnt das Märchen «Hans im Glück» der Gebrüder Grimm. Hans (wir nennen ihn mit Nachnamen HERMES), der seinem Herrn sieben Jahre gute Dienste geleistet hat, erhält dafür schliesslich so viel Gold, dass er davon ein feudales Leben aufbauen kann. Mit diesem grossartigen Budget und seinem Ziel – die Heimkehr zur Mutter – vor Augen, beginnt er die erste Phase seines Projekts: er wandert mit dem Gold in Richtung seiner Heimat. Motiviert und voller Ideen gestartet, wird sein Weg schon bald beschwerlicher: das Gold drückt auf seine Schulter, der Weg bis zum Ziel ist doch länger und schwerer als gedacht. Wie soll er es bloss schaffen, mit dieser Last in kurzer Zeit bis in seine Heimat zu kommen? Während er noch über dieses Problem grübelt, sieht er – ohne es zu wissen – bereits die Lösung herangaloppieren: ein Reiter auf seinem Pferd. Als dieser bemerkt, dass Hans einen grossen Klumpen Gold bei sich hat, schlägt er einen Tausch vor: das Pferd gegen das Gold. Hans HERMES merkt, dass er dadurch die grosse Last der ersten Etappe weggeben kann, und willigt ein.
Beschwingt startet er zur nächsten Projektphase, das Ziel weiterhin vor Augen, wenn auch mit vermindertem Budget. Er fühlt sich wieder motiviert, das Hindernis auf seinem Weg zum Ziel ist aus dem Weg geräumt, er hat ein Problem nachhaltig gelöst: die Last ist weg, den langen Weg wird er nun reitend viel schneller schaffen! Auf diese altbewährte Methode vertrauend, läuft es in der neuen Phase seines Projekts wirklich gut. Leider hat er nicht damit gerechnet, dass diese Art der Fortbewegung vielleicht auch zu schnell werden kann: er kann das Pferd kaum bändigen, das Projekt wird ihm zu sportlich und er möchte abspringen… Da kommt ihm der Bauer sehr gelegen, der eine Milchkuh mit sich führt. Hans HERMES bringt seinen Neid zum Ausdruck, wie nachhaltig doch solch eine schöne Milchkuh ist, die einem viele Jahre Milch gibt und schliesslich auch noch Fleisch bringt. Nach Abwägen der Vor- und Nachteile – der Bauer freut sich schon über diesen tollen Handel – tauscht Hans sein schickes Pferd gegen die alte Kuh. Sehr zum Erstaunen von Hans HERMES läuft der Bauer kopfschüttelnd weg. Hans spürt, wie er seinem Ziel durch diesen klugen Tausch näherkommt: egal, was auf dem Weg passiert, er hat sich abgesichert, hat eine Kuh dabei, deren Milch ihn tränken und sättigen kann. Er hat also auch die nächste Hürde gemeistert, auch wenn sich das Budget wieder geschmälert hat.
So geht es in seinem Projekt weiter: die Kuh – die übrigens zu alt zum Milchgeben war – wird gegen ein Schwein getauscht, dieses wiederum gegen eine Gans, die dann einem Wetzstein weichen muss. Und jedes Mal merkt Hans, dass er sich besser fühlt, eine Last weniger auf ihm lastet, er seinem Ziel näherkommt und glücklicher wird. Der Wetzstein – der ihm ein arbeitsames Leben bringen soll – wird kurz vor dem Ziel plötzlich immer schwerer: sollte das Projekt so kurz vor dem Abschluss scheitern? Hans HERMES legt eine Pause ein, denkt über seine Arbeit (task) und die Belastung (force) nach. Die letzten Meter seines Weges hat er nur im Schneckentempo zurückgelegt! Wie soll er in der noch verbleibenden Zeit das Ziel erreichen? Er setzt sich an einen Brunnen und probiert zu trinken. Dabei stösst er aus Versehen den Wetzstein in den Brunnen. Nun ist sein gesamtes Budget weg, aber wie durch ein Wunder sieht Hans nun das Ziel vor Augen: das Problem der Belastung ist aus dem Weg geräumt, er kann fröhlich und frei nach Hause laufen. «So glücklich wie ich, gibt es keinen Menschen unter der Sonne» ruft er, während Hans HERMES das Haus seiner Mutter erreicht.
Und die Moral von der Geschicht? Mit dem Denken von (Hans) HERMES erreicht man sein Ziel mit dem gegebenen Budget. Egal, wie unlogisch das Lösen mancher Probleme im Projekt scheint, Nachhaltigkeit erreicht HERMES manchmal auch durch die aussergewöhnlichen Wege. Wichtig ist nur, dass man an sich selbst, sein Projekt und seine Ziele glaubt!
Und wenn Sie trotzdem noch Unterstützung im Projektmanagement brauchen, können Sie sich gerne bei einem unserer HERMES5-Kurse anmelden oder uns um Rat fragen!
Das Departement Wirtschaft der Berner Fachhochschule bietet laufend HERMES-Kurse an. ist die Projektmanagementmethode für Informatik, Dienstleistung, Service und Geschäftsorganisationen und wurde von der Schweizerischen Bundesverwaltung entwickelt. Die Methode steht als offener Standard vom Verein eCH jedem zur Verfügung.
Wie wir wissen, gibt es Dutzende von PM-Methoden, über sie alle wird leidlich gestritten, weil sie zu kompliziert, zu simpel, viel zu umfangreich oder einfach nur unmöglich, unpassend und unbrauchbar sind. Nach 10 Jahren Entwicklungs- und Erprobungszeit kommt jetzt auch noch die EU-Kommission um die Ecke und stellt ihre neue Methode PM2 anlässlich einer 2-tägigen Konferenz in Brüssel vor. Da fragt man sich, ob PM2 nun eher ein Beitrag zum Problem oder ein Beitrag zur Lösung ist.
Noch eine Methode mehr?
Die Zahl bekannter PM-Methoden ist Legion, hier eine höchst unvollständige Liste:
APM 6
BGW
HERMES 5
IPMA ICB 4.0
ISO 21500
Kanban
Kepner-Tregoe
MoV – Management of Value
MSP – Managing Successful Programmes
PMBoK 6th Ed.
PRINCE2
SCRUM
V-Modell XT 2.0
etc.
Dazu kommen unzählige Separat- und Spezial-Methoden für Risikomanagement, Portfoliomanagement etc., ganz zu schweigen von branchenspezifischen Vorgehensweisen.
Nun also hat die EU-Kommission mit PM2 (ausgesprochen «PM squared»), oder besser gesagt Open PM2 publiziert. Da darf man schon mal fragen, was das soll? Allerdings, ohne genauer hinzuschauen, wird man’s nicht rausfinden.
Woher kommt PM2?
Die EU besteht aus 17 Organisationen, 45 Behörden und über 30’000 Mitarbeitenden, diese geben im Zeitraum von 2014 – 2020 rund € 959 Mia aus, 6% davon für Administration, die übrigen 900 Milliarden werden in verschiedenste Programme investiert. 20% dieser Mittel verwaltet die EU-Kommission direkt, die anderen 80% werden durch rund 100 weitere Organisationen verwendet. Dass sich die EU-Kommission unter diesen Umständen Gedanken zu Effizienz und Standardisierung Gedanken macht, ja Gedanken machen muss, versteht sich von selbst.
Vor diesem Hintergrund hat die EU-Kommission 2007 die Entwicklung der Methode in Auftrag gegeben. Die Version 1 wurde anhand typischer IT-Projekte geprüft, die Version 2.0 wurde Kommissionsintern eingesetzt und die Version 2.5 fand in weiteren EU-Organisationen, namentlich bei den Finanzinstitutionen wie der EZB Anwendung, bis schliesslich die Version 3, bzw. Open PM2 1.0 Anfang Februar 2018 anlässlich der ersten Open PM2-Konferenz in Brüssel einem breiteren Publikum vorgestellt wurde.
Was ist PM2?
In den Worten der EU-Kommission: “PM2 is a Project Management Methodology developed and supported by the European Commission. The purpose of PM2 is to enable project teams to manage projects in an effective and efficient manner for the purpose of delivering solutions and benefits to their Organisations and Stakeholders”.
Und in den Worten des Autors dieses Beitrags: «PM2 ist eine schlanke, aber dennoch gut dokumentierte, moderne, intelligent konstruierte End-to-end PM-Methode». Folgender Nutzen soll die Methode auszeichnen:
Schlank? Der PM2 User Guide hat auf 137 Seiten Platz, die Methode selbst ist auf 73 Seiten dokumentiert und illustriert («alles andere ist Beilage», also Anhänge). Auch wenn man die Gefahr läuft, Äpfel mit Birnen zu vergleichen, PM2s Dokumentation ist deutlich schlanker als jene anderer Methoden (HERMES 5.1: 180 Seiten; PMBoK 6th Edition: 980 Seiten (inkl. Agile Practice Guide); IPMA ICB 4.0: 432 Seiten (inkl. Programm- und Portfolio-Management); V-Modell XT 2.0: 500 Seiten (V 1.4: 932 Seiten)). Natürlich muss kürzer nicht besser sein, aber mit Sicherheit ist ‘kürzer’ intellektuell besser in den Griff zu bekommen.
Ergänzend zum kurzen und knackigen User Guide stellt PM2, wie andere Methoden auch, dem Anwender eine ganze Menge an sinnvollen Hilfsmitteln zur Verfügung, wie zum Beispiel eine Sammlung von 32 Vorlagen für sämtliche Artefakte der Methode, einen sehr umfangreichen Study Case, der dem oft gehörten Ruf nach praktischen Beispielen nachkommt. Anhand des Study Case werden zwei Dinge der Methode sehr schön illustriert: 1. der Umgang mit den Templates und 2. das Tailoring der Methode.
Intelligent konstruiert?
Die Autoren waren sich nicht zu schade, für diverse Elemente von PM2 Anleihen bei anderen Methoden zu machen, statt zwanghaft bewährte Konzepte anders zu beschreiben oder zu bezeichnen. So entspricht zum Beispiel das Phasenkonzept von PM2 recht genau dem Prozessgruppenkonzept von PMBoK, wobei uns PM2 allerdings die recht anspruchsvolle und in der Praxis weniger hilfreiche ‘Prozessordnung und -hierarchie’ von PMBoK erspart. Das Rollenmodell ist klassisch und das Zusammenspiel der Rollen/Governance für die Ergebnisse mit der ebenfalls klassischen RAM (Responsibility Assignment Matrix) bzw. RACI-Matrix beschrieben.
Namentlich von PRINCE2 hat PM2 die umfassende Sicht über den ganzen Lebenszyklus eines Systems oder Ergebnisses übernommen (Business Case als Kern des Projekts, Fokus weg von der einseitigen Projektsicht hin zu Wertorientierung und Nutzen der Projektergebnisse).
Wie zum Beispiel HERMES 5 definiert auch PM2 keine Werkzeuge als Bestandteile der Methode selber, sondern überlässt diese dem Anwender, bietet aber mit dem PM2-Guide «Tools und Techniques» einen Überblick über 35 populäre PM-Werkzeuge, dazu gehören unter anderem PESTEL-Analyse, Critical Path Method, Earned Value Management, Balanced Scorecard Methode etc. Und bei jedem dieser Werkzeuge sind eine Handvoll Links angegeben, die auf weiterführende Unterlagen verweisen.
Modern?
PM2 ist, wie viele andere klassische Methoden planend/predictive (böse Mäuler sagen «Wasserfall»), Methoden, ausgelegt:
verfügt aber sowohl in prozessualer wie in organisatorischer Hinsicht über wohldefinierte Anschlusspunkte zu agilen Vorgehensweisen:
Wie aus obigem Schema für die PM2-Organisation hervorgeht, bestehen nicht nur Anschlusspunkte für agile Verfahren und deren Organisation, sondern die Organisation ist a priori auf eine enge Zusammenarbeit mit dem Business/Fachseite/ Kunden einerseits und der Projektentwicklung andererseits ausgelegt.
End-to-end?
PM2 ist eine vollständige PM-Methode und hat entlang der Zeitachse nicht alleine das Projekt im Fokus, sondern den ganzen Produktzyklus.
Die Methode ist nicht nur horizontal vollständig, sondern auch vertikal, also von der Projekt-Governance über den (Projekt-) Lebenszyklus und die Projektprozesse bis hin zu den Artefakten.
PM2 umfasst und beschreibt essentielle Mindsets für Projektmitarbeitende:
Was nun?
Open PM2 ist eine nützliche und wohldurchdachte Projektmanagement-Methode, sie ist innerhalb der EU-Kommission und -Organisationen gut erprobt, sie offen und kostenfrei für jedermann verfügbar (die Ausbildungen und die Zertifizierungen stehen zurzeit erst EU-Angestellten zur Verfügung). Open PM2 soll weiter geöffnet werden, inklusive des Ausbildungs- und Zertifikationsprogramms.
Machen Sie sich ein Bild, es wird nicht zu Ihrem Schaden sein.
Ich kann mir beispielsweise den praktischen Einsatz der Methode in einem Kontext, der sich noch nicht auf eine Methode kapriziert hat und wo keine allzu steile Lernkurve verkraftet werden kann, sehr wohl vorstellen und nicht zuletzt bin ich überzeugt, dass sich die derzeitig vorliegende Dokumentation sehr wohl auch als Lehrmittel für angehende Projektleiterinnen und Projektleiter eignet.
https://www.societybyte.swiss/wp-content/uploads/2018/04/shutterstock_706715482.jpg7091000Ernst Menethttps://www.societybyte.swiss/wp-content/uploads/2023/05/logo-societybyte-DE.webpErnst Menet2018-05-01 08:05:382018-04-27 12:48:08Frage an Radio Eriwan: «Benötigt die Welt eine weitere Projektmanagement-Methode?». Antwort von Radio Eriwan: «Im Prinzip vielleicht doch (nicht)!»
Wir können Cookies anfordern, die auf Ihrem Gerät eingestellt werden. Wir verwenden Cookies, um uns mitzuteilen, wenn Sie unsere Websites besuchen, wie Sie mit uns interagieren, Ihre Nutzererfahrung verbessern und Ihre Beziehung zu unserer Website anpassen.
Klicken Sie auf die verschiedenen Kategorienüberschriften, um mehr zu erfahren. Sie können auch einige Ihrer Einstellungen ändern. Beachten Sie, dass das Blockieren einiger Arten von Cookies Auswirkungen auf Ihre Erfahrung auf unseren Websites und auf die Dienste haben kann, die wir anbieten können.
Wichtige Website Cookies
These cookies are strictly necessary to provide you with services available through our website and to use some of its features.
Because these cookies are strictly necessary to deliver the website, refusing them will have impact how our site functions. You always can block or delete cookies by changing your browser settings and force blocking all cookies on this website. But this will always prompt you to accept/refuse cookies when revisiting our site.
We fully respect if you want to refuse cookies but to avoid asking you again and again kindly allow us to store a cookie for that. You are free to opt out any time or opt in for other cookies to get a better experience. If you refuse cookies we will remove all set cookies in our domain.
We provide you with a list of stored cookies on your computer in our domain so you can check what we stored. Due to security reasons we are not able to show or modify cookies from other domains. You can check these in your browser security settings.
Google Analytics Cookies
These cookies collect information that is used either in aggregate form to help us understand how our website is being used or how effective our marketing campaigns are, or to help us customize our website and application for you in order to enhance your experience.
If you do not want that we track your visit to our site you can disable tracking in your browser here:
Andere externe Dienste
We also use different external services like Google Webfonts, Google Maps, and external Video providers. Since these providers may collect personal data like your IP address we allow you to block them here. Please be aware that this might heavily reduce the functionality and appearance of our site. Changes will take effect once you reload the page.
Google Webfont Settings:
Google Map Settings:
Google reCaptcha Settings:
Vimeo and Youtube video embeds:
Other cookies
The following cookies are also needed - You can choose if you want to allow them:
Create PDF
ist die Projektmanagementmethode für Informatik, Dienstleistung, Service und Geschäftsorganisationen und wurde von der Schweizerischen Bundesverwaltung entwickelt. Die Methode steht als offener Standard vom Verein eCH jedem zur Verfügung.
Schlank?
Der PM2 User Guide hat auf 137 Seiten Platz, die Methode selbst ist auf 73 Seiten dokumentiert und illustriert («alles andere ist Beilage», also Anhänge). Auch wenn man die Gefahr läuft, Äpfel mit Birnen zu vergleichen, PM2s Dokumentation ist deutlich schlanker als jene anderer Methoden (HERMES 5.1: 180 Seiten; PMBoK 6th Edition: 980 Seiten (inkl. Agile Practice Guide); IPMA ICB 4.0: 432 Seiten (inkl. Programm- und Portfolio-Management); V-Modell XT 2.0: 500 Seiten (V 1.4: 932 Seiten)). Natürlich muss kürzer nicht besser sein, aber mit Sicherheit ist ‘kürzer’ intellektuell besser in den Griff zu bekommen.
Namentlich von PRINCE2 hat PM2 die umfassende Sicht über den ganzen Lebenszyklus eines Systems oder Ergebnisses übernommen (Business Case als Kern des Projekts, Fokus weg von der einseitigen Projektsicht hin zu Wertorientierung und Nutzen der Projektergebnisse).
Wie aus obigem Schema für die PM2-Organisation hervorgeht, bestehen nicht nur Anschlusspunkte für agile Verfahren und deren Organisation, sondern die Organisation ist a priori auf eine enge Zusammenarbeit mit dem Business/Fachseite/ Kunden einerseits und der Projektentwicklung andererseits ausgelegt.
Beiträge als RSS