Skip to main content

Ich arbeite seit geraumer Zeit im Projektmanagement (ich werde hier keine genauen Zahlen nennen, aber ich bin dabei, seit iPhones in den Augen von Steve Jobs ein entfernter Glanz waren und Facebook war The Facebook….).

Eine Sache, von der Projektmanager und insbesondere digitale Projektmanager schon immer besessen waren, ist die Methodik. Aber Methoden sind eine wichtige Sache in der Welt des Projektmanagements. Warum richten wir alles, was wir tun, um sie herum – und sind sie wirklich so wichtig?

In diesem Artikel werde ich mir ansehen, was die Kernmethoden des digitalen Projektmanagements sind, die du wählen solltest und ob es eine andere Lösung gibt.

Zusammenfassend werde ich mich diesen Themen zuwenden:

  1. Was sind die “Projektmanagement-Methoden”?
  2. Welche Methodik sollte ich in meinem Projekt anwenden?
  3. “Ich möchte zu Agile wechseln, aber es ist einfach zu schwer umzusetzen.”
  4. “Garantiert eine Methodik den Erfolg des Projekts?”
Agile vs Waterfall

1. Was versteht man unter “Projektmanagement-Methoden”?

Was ist also eine Methodik (abgesehen davon, dass es sich um ein wirklich langweiliges Wort handelt)? Es ist ein Rahmenwerk der Prozesse, die an deinem Projekt beteiligt sind. Es ist auch dein Management. Dazu gehören in der Regel Kernaufgaben wie die Einleitung, Planung, Durchführung, Überwachung und der Abschluss des Projekts.

Es gibt eine Vielzahl von Projektmanagement-Methoden, aus denen du wählen kannst. Es gibt die traditionelleren, linearen, wie den bekannten Wasserfall. Dann gibt es noch das Agile Framework mit verschiedenen Zweigen: Scrum, Kanban und Lean zum Beispiel. Es gibt Critical Chain Management und das aufregend klingende Benefits Realisation Management. Extreme Programming, Prince2, das Adaptive Project Framework – die Liste geht weiter.

Ich werde mich auf die beiden großen Gewinner konzentrieren, die immer wieder auftauchen, wenn es um digitales Projektmanagement geht. Tritt vor den Bösewicht der DPM-Welt, den Wasserfall. In der anderen Ecke, Agile – die “Silberkugel”, die “Zauberformel”. Schließlich ist Agile das Beste, oder?

Is agile methodology the best?

“Agile ist das beste, oder?”

Nicht unbedingt. Beide Methoden haben Vorteile, und bei beiden gibt es Projekte, die besser auf diese zugeschnitten sind. Lass uns also einen tieferen Blick auf jede einzelne dieser Methoden werfen.

Agile vs Wasserfall: Die Prinzipien

Grundprinzipien von Wasserfall

Erfassung von Anforderungen im Vorfeld:

Entwickler und Kunden sind sich darüber einig, was zu Beginn des Entwicklungslebenszyklus umgesetzt wird. Dies kann die Planung und Gestaltung übersichtlicher machen. Der Fortschritt lässt sich leichter nachvollziehen, da der gesamte Umfang der Arbeiten im Voraus bekannt ist. Eine gute technische Dokumentation ist Teil der Ergebnisse und es ist einfacher für neue Programmierer, sich während der Wartungsphase auf den neuesten Stand zu bringen.

Arbeit, die in Phasen nacheinander abgeschlossen wurde:

Jede Phase beginnt im Allgemeinen mit dem Ende der vorherigen Phase. Während der gesamten Entwicklung können verschiedene Mitglieder des Teams mitwirken oder andere Arbeiten durchführen. Beispielsweise können Tester während der Codierung Testskripte aus der Dokumentation der Anforderungen erstellen.
Der Ansatz ist sehr strukturiert und es kann einfacher sein, den Fortschritt mit klar definierten Meilensteinen zu messen und am Anfang besser zu planen.

Der Test wird nach Abschluss der Entwicklung durchgeführt:

Das Testen ist einfacher zu planen und durchzuführen. Dies kann unter Berücksichtigung der im Pflichtenheft definierten Szenarien am Ende der Entwicklungsphase erfolgen.

Kunden oder Stakeholder müssen nicht intensiv einbezogen werden:

Mit Ausnahme von Überprüfungen, Genehmigungen und Statusbesprechungen ist eine Kundenpräsenz nach der Anforderungsphase nicht unbedingt erforderlich.

Clients or stakeholders don’t need to be heavily involved:

Except for reviews, approvals, and status meetings, a customer presence is not strictly needed after the requirements phase.

Mehr über Wasserfall | Wasserfall Projektmanagement-Tools | Der IT-Projektmanager: Wie man Wasserfallprojekte managt

Grundprinzipien von Scrum

Im Jahr 2001 versammelte sich eine Gruppe von Entwicklern und erarbeitete das so genannte Agile Manifest. Es beschreibt die vier Werte, die sie als Grundlage für diese Art der Entwicklungsarbeit sahen. Mit diesen 200 Wörtern haben sie das Antlitz der Softwareentwicklung ziemlich stark verändert und massive Industrien hervorgebracht.

Während Agile das Framework ist, ist Scrum der Ansatz, der Agile verwendet. Wie du sehen wirst, machen viele der Rahmenbedingungen und die Besonderheiten von Scrum Sinn, wenn du an digitale Projekte denkst.

Individuen und Interaktionen in Bezug auf Prozesse und Tools:

Erstens konzentriert es sich auf Individuen und Interaktionen in Bezug auf Prozesse und Werkzeuge. Kommunikation ist der Schlüssel, nicht die Prozesse, die dein Projekt leiten. Innerhalb von Scrum bedeutet dies das selbstorganisierende, funktionsübergreifende Team.

Sign up for our emails and be the first to see helpful how-tos, insider tips and tricks, and a collection of templates and tools.

Sign up for our emails and be the first to see helpful how-tos, insider tips and tricks, and a collection of templates and tools.

  • Hidden
  • By submitting this form, you agree to receive our newsletter and occasional emails related to The Digital Project Manager. For more details, please review our Privacy Policy. We're protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
  • This field is for validation purposes and should be left unchanged.

Funktionierende Software über umfassende Dokumentation:

Es wird ein starker Fokus darauf gelegt, versandfähige Produkte schneller zu erhalten, anstatt viel Zeit damit zu verbringen, Anforderungen zu formulieren. In Scrum werden zeitgesteuerte Arbeitssprints am Ende eines jeden Sprints mit einem versandfähigen Produkt durchgeführt.

Kundenzusammenarbeit über Vertragsverhandlungen:

Agile Werte spezifizieren die Zusammenarbeit mit dem Kunden oder dem Auftraggeber. Dabei wird an allen Stellen mit dem Auftraggeber zusammengearbeitet, wobei er während des gesamten Prozesses stark involviert ist. Scrum setzt auf eine konsistente und regelmäßige Kundenbindung.

Reaktion auf die Umstellung nach einem Plan:

Anstatt Veränderungen als Feind zu sehen, ist es für das Agile Framework von zentraler Bedeutung, in der Lage zu sein, Veränderungen als eine gute Sache zu sehen und darauf zu reagieren. Scrum hat ständig sich ändernde Anforderungen und Veränderungen werden angegangen.

All diese Dinge machen wirklich Sinn, wenn es um digitale Inhalte geht. Kommunikation im Team, schnelles Arbeiten, Einbeziehung des Kunden. Und – wenn digital eine sich ständig verändernde Umgebung ist – schnell auf Veränderungen reagieren zu können.

Mehr über Scrum | Mehr über AgileAgile tools | Scrum: eine atemberaubend kurze und agile Einführung

zurück zur Zusammenfassung

2. Welche Methodik sollte ich für mein Projekt anwenden?

Was sollte deine Entscheidung darüber beeinflussen, welche Methodik du für ein Projekt anwenden sollst? Bis du nicht weißt, was das Projekt und andere Einflussfaktoren sind, wirst du nicht in der Lage sein zu entscheiden, welche am besten geeignet ist. Einige (oder alle) dieser Faktoren sollten bei der Betrachtung von Methoden berücksichtigt werden:

  • Umfang des Projekts
  • Dauer
  • Komplexität
  • Organisatorische Faktoren
  • Kunden oder Stakeholder, extern und intern.

Für welche Projekte kann Wasserfall geeignet sein?

Wasserfallprojekte sind:

  • Projekte, bei denen du mit anderen Organisationen oder externen Mitarbeitern zusammenarbeitest.
  • Projekte mit festem Umfang, Zeit und Budget
  • Kleinere, klar definierte und einfachere Projekte
  • Projekte mit einem nicht anwesenden Kunden.

Für welche Projekte kann Agile in Frage kommen?

Agile Projekte sind:

  • Projekte, bei denen deine Organisation für den gesamten Prozess verantwortlich ist.
  • Projekte mit Spielraum für sich ändernde Anforderungen
  • Größere, undefinierte, komplexe Projekte
  • Projekte mit einem beteiligten Kunden.

Aber berücksichtigen Unternehmen wirklich alle diese Faktoren? Was oder wer entscheidet eigentlich über einen Prozess? Möglicherweise ist die Hauptsache, die eine gewählte Methodik beeinflusst, die bestehenden Prozesse. Die aktuellen Prozesse deines Unternehmens bestimmen in der Regel, wie du dein Projekt führst. Egal um welches Projekt es sich handelt. Es ist der klassische Grundsatz. Da jedes Projekt unterschiedliche Anforderungen hat und sich die Einflussfaktoren sehr stark unterscheiden können, ist dies nicht der beste Weg, um jedes Projekt in deiner Firma durchzuführen.

Wie verwende ich diese Methoden überhaupt?

Den theoretischen Unterschied zwischen Agile und Waterfall zu kennen ist eine Sache. Aber wie setzen wir als Projektmanager diese Methoden ein, um den Nutzen für unsere internen Teams und unsere Kunden zu maximieren?

Erfahre in unserem Online-Kurs, wie du einen strategischen Ansatz für diese Methoden in der realen Welt anwenden kannst. Mit einem relevanten, praxisnahen und fachlich geleiteten Training wirst du zu einem wichtigen Wissensträger für deine Teams und Kunden. Dadurch kannst du dich sicher durch die Prüfungen im Projektmanagement navigieren.

Learn more

Na komm schon, was ist nun besser?

Bisher meinte ich, dass beide Methoden, die ich vorgestellt habe, eigenständige Vorteile haben. Aber wenn wir in einer idealen Welt leben, passt der Agile Ansatz eher zu rein digitalen Projekten. Alle Prinzipien scheinen in die digitale Landschaft zu passen, wo ändernde Bedürfnisse und Veränderungen in sämtlichen Projekten vorhanden sind. Ich möchte im Folgenden einen Blick auf einige der wichtigsten Vorteile werfen.

Regelmäßige Durchläufe

Regelmäßige Wiederholungen der Arbeit, zu denen auch die Prüfung und Überprüfung durch die Beteiligten alle zwei Wochen (z.B. jeder Sprint) gehört, tragen wirklich dazu bei, ein Projekt auf Kurs zu halten.

Vor einigen Jahren leitete ich ein Projekt, bei dem wir nach dem Wasserfallprinzip gearbeitet haben. Das Ganze wurde von einer anderen Agentur entworfen und konzipiert. Wir hatten damals noch keine Staging-Site dafür eingerichtet, so dass der Entwickler nur lokal auf seiner Maschine arbeitete (erster Fehler). Wir hatten regelmäßige Aufholjagden und die Dinge schienen gut zu laufen. Allerdings haben wir erst nach der ersten QS ein funktionierendes Produkt auf dem Staging gesehen. An dieser Stelle haben wir festgestellt, dass große Teile unvollendet waren und das CMS nicht korrekt und spezifikationsgerecht aufgebaut wurde. Wenn wir regelmäßige Iterationen des Entwurfs eines versandfähigen Produkts gehabt hätten, hätten wir das wahrscheinlich vermeiden können. Es gibt viel mehr Exposition gegenüber dem Produkt während des gesamten Projekts.

Denke an zwei der Meetings, die du in Scrum hast: die Review – also die Überprüfung des Entwurfs am Ende des Sprints. Außerdem auch die Retrospektive – die Überprüfung der im Sprint abgeschlossenen Arbeiten. Diese sind deine Frühwarnsignale für alles, was aus der Bahn gerät.

Kundenbeteiligung

Es gab eine IT- und Software-Projektüberprüfung über einen Zeitraum von fünf Jahren. Diese wurde als Chaos-Manifest bezeichnet und im Jahr 2013 veröffentlicht. Es stellte sich heraus, dass der größte Faktor für den Projekterfolg ein engagierter Hauptsponsor oder Produkteigentümer war. Wenn der Kunde an der Gestaltung der Anforderungen während des Projekts beteiligt ist, wie z.B. an der Überprüfung der Arbeit und der Definition von Prioritäten, bedeutet das, dass er weniger Gefahr läuft, plötzlich Überraschungen zu erleben. Es werden ständig Geschäfts- und Benutzeranforderungen in den Prozess eingebracht.

In einem Projekt, an dem ich vor etwa fünf Jahren gearbeitet habe, war der Kunde nicht viel beteiligt. Wir hatten einen wöchentlichen Check-in. Alles, was der Kunde aber wollte, war ein wöchentlicher Statusbericht. Der wöchentliche Statusbericht sollte ihm montags zugestellt werden. Wir haben versucht, den Kunden stärker in die eigentlichen UX-Meetings und -Definitionen einzubeziehen, aber er war zu sehr mit einem anderen Projekt beschäftigt. Wir kamen zur Wireframe-Präsentation und deren erstes Kommentar? “Diese Wireframes sehen zu traurig aus.” Ja, im Ernst. Ich habe ein Projekt mit “traurigen” Wireframes geleitet. Ja… ein trauriges Gesicht. :(

Sad Wireframes

“Diese Wireframes sind sooo traurig…”

Abgesehen von einem Mangel an Verständnis für den Zweck der Wireframes hatten sie ihre Anforderungen an den Prozess nicht richtig einfließen lassen und waren nicht an der Entwicklung der Idee beteiligt. Also mussten wir einige Wochen des Projekts auf Eis legen und verschwenden.

Zusammenarbeit im Team

Anstatt dass die UX an der Definition eines Projekts arbeitet, die Übergabe an das Design, die Übergabe an die Entwicklung, mit allen in ihren eigenen Silogebieten – kannst du viele Probleme durch das Team vermeiden, das während des Projekts zusammenarbeitet. Wie du aus dem Projekt erkennen kannst, über das ich zuvor gesprochen habe, hat der Entwickler isolierter gearbeitet. Wenn es früher mehr Zusammenarbeit gegeben hätte, hätte es gegen Ende keine Überraschungen geben können.

Entwicklung der Anforderungen

Dies ist einer der entscheidenden Vorteile von Agile Frameworks und Scrum. Man akzeptiert und bewältigt Veränderungen viel besser. Veränderte Rahmenbedingungen und Anforderungen bringen das Projekt nicht in eine Krise. Tatsächlich ist dies das Ziel der Sprintüberprüfung und des Sprintplanungsmeetings. Ziel ist es, herauszufinden, welche Änderungen erforderlich sind. Bei lineareren Projekten werden die Pläne Monate vor der Entwicklung ausgearbeitet und auf der Grundlage von damals allgemein groben Schätzungen erstellt – und dann in Stein gemeißelt.

Seien wir ehrlich, lineare Projektpläne funktionieren einfach nicht

Wo deine Anforderungen zu Beginn festgelegt werden und die Ergebnisse und Zeitpläne Monate im Voraus ausgearbeitet werden – was geschieht dann? Die Dinge ändern sich. Das führt zu Projektverzögerungen, da alles neu skizziert und definiert werden muss.

“Über einen Zeitraum von 5 Jahren überzogen durchschnittlich 53% der Projekte das Budget und 76% die Zeit.”
Das Chaos-Manifest, 2013

Wenn wir ein Beispiel für eine Agentur nehmen, die durchschnittlich 50 Projekte pro Jahr durchführt, dann sind das über 25 Projekte, bei denen das Budget überschritten wird. Außerdem sind es 37 Projekte (von 50!), die das Zeitfenster überschreiten. Etwas funktioniert offensichtlich nicht.

Hier ist ein großartiges Beispiel:

Example of an agency which project plans run over on costs and time

Wenn ich einen linearen Projektplan erstelle, geschieht dies in der Regel. Das ist mein Zeitplan-Ordner – hast du so etwas schon mal gesehen? Etwas am Projekt ändert sich, also änderst du den Plan. Dann möchte der Kunde etwas zum Umfang hinzufügen. Also gehen wir noch einmal an die Sache ran. Für dieses Projekt habe ich 10 Versionen erstellt. (Und ja, ich weiß auch, dass ich einen Archivordner brauche….)

Ich kann mich eigentlich nicht erinnern, wann ich das letzte Mal bei einem traditionelleren linearen Projekt den Projektplan nicht mindestens zweimal während des Projektverlaufs ändern musste. Das liegt daran, dass sich Projekte ändern. Kunden ändern sich. Der Benutzer muss sich ändern. Technologische Veränderungen. Die Digitaltechnik verändert sich ständig. Agile Frameworks haben daher in der Regel bessere Möglichkeiten, auf Veränderungen zu reagieren. Tatsächlich wird es angenommen, anstatt es als einen großen Schlag für das Projekt zu sehen.

zurück zur Zusammenfassung

3. Ich möchte zu Agile wechseln, aber es ist einfach zu schwer zu implementieren”.

Es ist jedoch nicht immer einfach, Agile Ansätze vollständig oder sofort in ein Unternehmen zu implementieren. Wie wir gesehen haben, gibt es viele Faktoren, die bei der Implementierung eines Prozesses eine Rolle spielen. Agile Ansätze passen nicht immer gut in Agenturen, in denen Kunden einen festen Umfang, ein festes Budget und einen festen Zeitplan im Voraus wünschen. Also, triff den Hybriden. Ja, ihr habt wahrscheinlich alle schon mal den schmutzigen Begriff gehört, Wagile…

Agile methodology like waterfall

Als ich meinen Vortrag zu diesem Thema für die Deliver Conf im Januar letzten Jahres recherchierte, habe ich mir den Begriff Wagile angesehen und bin auf einige Artikel dieses Entwicklers gestoßen. Das ist mein liebstes, sehr vernichtendes Zitat:

– “WAgile steht, wie wir alle wissen, für “Waterfall-Agile” und ist der Gipfel dysfunktionaler Entwicklungsmethoden. Ja, Leute: Buchstäblich Tausende von Projekten sind auf dem WAgile Weg gescheitert.
Jason Gorman

Er schrieb dies 2008 um die Zeit, in der der Begriff geprägt wurde. Und trotz der übertriebenen Aufregung kann ich verstehen, was er damit meint. Viele Menschen missbrauchen den Begriff Agile. Ich habe gesehen, wie viele Unternehmen ein Projekt als agil eingestuft haben, weil sie zum Beispiel täglich ein Stand-up-Meeting abhalten.

Was ist ein Hybrid?

Ein Wasserfall- oder lineares Projekt folgt den wichtigsten Schritten in der Reihenfolge: Erkennen, Festlegen, Erstellen, Testen und Bereitstellen am Ende.

Waterfall methodology stages

Was ich oft in Unternehmen mit dem Namen Agile beobachtet habe, ist folgendes:

"Agile" as a linear methodology

Allein die Aufteilung der Entwicklung in zweiwöchige Sprints und das tägliche Aufholen bedeutet nicht, dass man “agil” ist. Wenn du diesem linearen Prozess der Entdeckung, Definition im Voraus, dann dem sequentiellen Aufbau und Testen folgst – dann ist das immer noch ein lineares Projekt. Alle Anforderungen werden zu Beginn definiert. Das ist es, was du in jeder Entwicklungsphase durchführst.

In einem wirklich agilen Projekt wird der Prozess mit jeder Phase, die in den Iterationen enthalten ist, eher so aussehen:

Agile vs Waterfall - The true Agile process stages

Angesichts der Schwierigkeiten bei der Implementierung von Agile ist ein nahtloser Übergang zu Agile Distribution für viele Unternehmen sehr schwierig. So viel Kundenbeteiligung, ein allgemeines Unverständnis, die Frage, wie UX hineinpasst, vielleicht eine frühere Beziehung zu einem Kunden. Es gibt viele Faktoren, die die Umsetzung schwierig machen.

Einfacher zu implementieren ist ein schrittweiser Übergang zur Übernahme von Agile Prinzipien und Scrum-Prozess, z.B. durch den Einsatz eines Hybrids. Ich weiß, dass dies ziemlich umstritten sein kann (und die agilen Puristen verärgern könnte), aber für mich scheint mir ein Hybrid eine realistischere Lösung zu sein, zumindest während der Übergangsphase.

So könnte also der Ablauf aussehen:

Agile vs Waterfall - The Hybrid Methodology stages

Wie man einen Hybrid implementiert

Du arbeitest also in einem Unternehmen, das den lineareren Arbeitsweisen folgt. Du denkst aber, dass Projekte von einem agilen Ansatz profitieren würden. Wie kannst du deinem Unternehmen helfen, dies durch eine eher hybride Lösung zu erreichen?

Lets use Hybrid Methodology - Agile and Scrum

“Ja, ich sagte, lass uns einen Hybrid benutzen.”

1. Kundenbeteiligung

Ideal: Ein befähigter, verfügbarer Produktverantwortlicher. 
Ein Kernproblem ist tendenziell die Einbeziehung des Kunden oder Stakeholders als Produktverantwortlicher. Diese müssen intensiv beteiligt sein. Das könnte dir schwer fallen, wenn sie an anderen Projekten beteiligt sind. Auch daran sind sie oft nicht gewöhnt. Sie erwarten oft, dass sie dir die Arbeit geben und dann von dir einmal in der Woche in einem Statusbericht hören, wie es läuft.

Hybrid: Helfe dabei, die Lücke zwischen Stakeholder und Team zu schließen.Bei einem Projekt, an dem ich gearbeitet habe, haben wir geholfen, diese Lücke zu schließen. Wir fungierten als Produktverantwortlicher, brachten den Kunden jedoch dazu, sich bereit zu erklären, an den Kernsitzungen (wie den Reviews und der Planung) teilzunehmen. Wir stellten sicher, dass er in jeder Phase an der Festlegung und Definition der Anforderungen beteiligt war.

2. Zusammenarbeit im Team

Ideal: Ein funktionsübergreifendes, engagiertes Team
Es kann schwierig sein, ein funktionsübergreifendes Team zu finden, das sich dem Projekt widmet. Dies kann besonders in kleineren Organisationen zutreffen, in denen viele Projekte laufen und von denen erwartet wird, dass die Teammitglieder an mehr als einem Projekt arbeiten.

Hybrid: Die Teammitglieder sind während des gesamten Prozesses involviert.
Achte darauf, dass zumindest die Teammitglieder zusammenarbeiten und kooperieren. Wenn du Projektmitglieder nicht Vollzeit für jeden Sprint buchen kannst, versuche sicherzustellen, dass sie in regelmäßige Diskussionen mit dem Entwicklungsteam und den täglichen Stand ups, der Planung und Überprüfung einbezogen werden. Ein Team, das miteinander spricht, kann dem Projekt zum Erfolg verhelfen.

3. Kontinuierliche Planung

Ideal: Planungsanforderungen pro Sprint
Das Umdenken des Kunden oder Stakeholders ist ebenfalls entscheidend, damit die Anforderungen nicht zu Beginn des Projekts in einer strengen Funktionalitätsbeschreibung festgelegt werden, an die man im Laufe eines Projekts gebunden ist. Aber Kunden und Stakeholder haben oft Angst davor. Man will wissen, was man bekommt, wenn man das Budget unterschreibt.

Hybrid: Etwas Vorausplanung, aber die Detailplanung dem Sprint überlassen

Sieh dir an, ob du die Projektanforderungen im Voraus locker gestalten kannst. Überlasse aber die Detailplanung den Sprints. Leg nicht zunächst alle Leistungen fest, damit du auf Veränderungen reagieren kannst. Betreue den Kunden, um den Einstieg in diesen Planungsansatz zu erhalten. Schildere die positiven Aspekte der Reaktion auf Veränderungen während des gesamten Projekts.

4. Entwerfe, was benötigt wird

Ideal: Design innerhalb jedes Sprints
Wie passt das Design dazu? Das Ideal wäre, dies in jedem Sprint auszuführen, so dass nur das entworfen wird, was für jede Iteration der Arbeit notwendig ist.

Hybrid: Design im letzten verantwortlichen Moment
Das Design sollte im letzten verantwortlichen Moment erfolgen. Statt einer ganzen Reihe von Upfront-Design, das Anforderungen frühzeitig definiert, entwirfst du, was du brauchst, so spät wie möglich. Dadurch wird vermieden, unnötige Elemente zu entwerfen, die am Ende nicht einmal verwendet werden. Dies geht wiederum auf die Zusammenarbeit zurück und veranlasst Designer, Entwickler und alle am Projekt Beteiligten, gemeinsam an einem Sprint oder einer zeitgesteuerten Arbeitsphase zu arbeiten.

Den Übergang erfolgreich gestalten

Hilfe holen

Nutze Schulungen, Mentoren und Coaching, um die Vorteile eines anderen Ansatzes zu ergründen. Das gilt für dich, dein Team und vor allem für deinen Kunden.

Management-Buy-in einholen

Kein Prozess wird sich ohne Management Buy-In ändern. Achte darauf, dass du die Vorteile und den Ansatz für die Einführung darlegst. Wenn du einen konkreten Plan vorlegen kannst, wie Kunden und Interessengruppen an Bord gebracht werden, wird dies den Übergang erheblich erleichtern.

Bleibe realistisch

Wenn die Dinge nicht funktionieren, gibt es keine Ausreden. Agile ist iterativ. Deine Umsetzung des Prozesses sollte es auch sein. Regelmäßige Überprüfungen, wie es läuft, bedeuten, dass Probleme schneller aufgegriffen und gelöst werden können.

Anstatt Ausreden dafür zu finden, wie es läuft, “oh, wir implementieren einen neuen Prozess, der Probleme mit sich bringt”, präsentieren wir Aktionspläne, wie man das Problem lösen und vorantreiben kann. Wenn du versagst, versagd schnell und mach weiter.

Häufige Fehler, auf die man achten sollte

Bei der Definition deines eigenen Hybridprozesses gibt es einige gängige Fehler, auf die du achten solltest.

Kein Prozess oder Struktur

Anstatt etwas zu befolgen, machst du das genaue Gegenteil und hast überhaupt nichts Konkretes definiert. Das Projekt wird zu einem Chaos, weil es keine Möglichkeit gibt, überhaupt zu arbeiten.

Menschen im Team, die verschiedene Dinge tun.

Wenn deine Teammitglieder nicht wirklich wissen, wie sie arbeiten sollen, könnten sie anfangen, sich auf eine Tangente zu begeben und sich nicht darauf konzentrieren, was sie tun sollen.

Die Prozesse um des Prozesses willen

Das ist wirklich wichtig: Setze keine Prozesse um des Prozesses willen ein. Füge keine unnötige Dokumentation hinzu, nur weil wegen. Achte darauf, dass der Prozess so effizient wie möglich abläuft, egal welche Methodik du befolgst.

Einheitslösung für alle Konzepte

Vorsicht vor dem Ansatz der Einheitslösung: die Meinung, dass, weil etwas einmal erfolgreich war, es für alles funktionieren wird. Achte darauf, dass du an jedes Projekt als seine eigene Instanz denken musst. Es muss ein Zusammenhalt in den Prozessen innerhalb einer Unternehmensgruppe bestehen. Allerdings ist jedes Projekt für sich genommen unterschiedlich und muss als solches behandelt werden.

zurück zur Zusammenfassung

4. The final question: does a methodology guarantee project success?

A lot of people are so obsessed with particular methodologies, they think if they use one of them it’s going to mean the project is automatically successful. I believe however, that project success from a PM perspective is based on skills, the so-called ‘hard’ and ‘soft’ skills. I don’t really like these terms, so use ‘practical’ and ‘personal’. Practical skills are the hard skills, the concrete, learned things. Personal are the soft skills, more ingrained and coming from how you are rather than what you do. I’m going to break them down a little further.

4. Die letzte Frage: Garantiert eine bestimmte Methodik den Projekterfolg?

Viele Leute sind sehr von bestimmten Methoden besessen. Sie denken, wenn sie eine von ihnen verwenden, wird das Projekt automatisch ein Erfolg. Ich glaube jedoch, dass der Projekterfolg aus PM-Perspektive auf Fähigkeiten basiert, den sogenannten “harten” und “weichen” Fähigkeiten. Ich mag diese Begriffe nicht wirklich, also benutze ‘praktisch’ und ‘persönlich’. Praktische Fähigkeiten sind die harten Fähigkeiten, die konkreten, erlernten Dinge. Persönlich sind die Soft Skills, die tiefer verwurzelt sind und von der Art und Weise kommen, wie man ist und nicht von dem, was man tut. Ich werde sie noch ein wenig weiter untergliedern.

Persönlich

  • Kommunikation – Ermöglicht Zusammenarbeit und Transparenz
  • Führung – Motivation und Anleitung
  • Flexibilität – Veränderungen zulassen und darauf reagieren
  • Problemlöser – Lösungen finden

Praktisch

  • Zeit- und Kostenschätzung
  • Technische Kenntnisse
  • Risikobeurteilung
  • Projektablauf

Und da ist es, im letzten Punkt – die Methodik, der Rahmen oder die Prozesse, die auf das Projekt folgen. Es ist also wirklich nur ein Teil des Ganzen, was ein erfolgreiches Projektmanagement und erfolgreiche Projekte ausmacht.

Tatsächlich habe ich mit meinem Personalchef gesprochen, als ich meinen ersten Vortrag zu diesem Thema geschrieben habe. Ich habe ihr von dieser Aufteilung erzählt, als wir daran arbeiteten, ein Mentoring-Programm für unsere Trainees für Projektmanagement einzurichten. Sie sagte, dass die Einstellung von Personen, die die persönlichen Fähigkeiten an den Tag legen, viel wichtiger ist als diejenigen, die die praktischen Fähigkeiten vorweisen. Dies gilt insbesondere für Personen, die in die Branche einsteigen. Im Allgemeinen können Menschen die praktischen Fähigkeiten erlernen und wie man sie in Projekten umsetzt, sofern sie lernwillig sind. Aber die persönlichen Fähigkeiten sind stärker verankert und entscheidend für den Erfolg als PM.

Was ziehen wir daraus? Fokussiere dich auf das, was wirklich zählt – Kommunikation, Führung, Flexibilität und Problemlösung.

Lass dich relevant, praxisnah und fachspezifisch schulen

Schau dir diesen Überblick über unseren kommenden Mastering Digital Project Management Online Kurs an – nimm Expertenunterricht, um zufriedene Teams zu führen und hochwertige Projekte in der digitalen Welt zu realisieren.

Graphic Of Online Training Course

Mehr erfahren

Was denkst du darüber?

Also, was darf es sein? Agile vs. Wasserfall oder Wagile? Kann eine hybride Methodik eine gute Alternative beim Übergang zu agil sein? Welche Erfahrungen und Erfolge (oder Misserfolge) hast du mit Wasserfall-, agilen oder wagilen Projekten? Nimm an dem Gespräch unten teil und teile deine Gedanken.

By Suzanna Haworth

Suze Haworth ist freiberufliche Senior Digital Projektmanagerin in London. Sie hat über 10 Jahre Erfahrung in der Agenturbranche, hat sich von Anfang an im Account Management durchgesetzt, bevor sie das Licht erblickt hat und ihre wahre Berufung zum Projektmanagement erkannt hat. Sie leitet derzeit Teams in den Bereichen Digital- und Web-Buildings aller Art, von sozialen Kampagnen und digitalen Medien bis hin zu großen und komplexen Websites. Suze hat Projekte für Kunden wie BBC, WaterAid, Channel 4, Esso, Lipton Tea, SEAT und Mozilla betreut, um nur einige zu nennen. Sie ist zertifizierter ScrumMaster, Referentin regelmäßiger Konferenzen und veröffentlicht auch Online-Blogs. Wenn sie nicht gerade digitale Dinge verwaltet und darüber redet (und zahlreiche Google-Tabellen erstellt), genießt sie es, ihre Leidenschaft für Berge und Kaffee zu befriedigen.