Kostenlos

PROJEKTMANAGEMENT FÜR DEN MITTELSTAND

Effiziente Methoden, Techniken und Verhaltensweisen für KMUs
von Dipl.-Kfm. (FH) Michael Taube
Michael Taube
Drei Jahre schwelte in mir der Wunsch, ein eigenes Buch zu schreiben. In den letzten Monaten habe ich mir den Wunsch erfüllt.
Das Buch beschreibt meine Sicht auf Projektmanagement. Ich habe zusammengetragen, was mir sinnvoll erscheint, was ich empfehlen kann in der täglichen Arbeit – insbesondere für klein und mittelständische Unternehmen.
Ich hoffe, dass Ihnen das Buch in der täglichen Arbeit helfen wird – Ihnen neue Einsichten bescherrt oder einfach nur Spass macht!
Mein Buch ist in Gänze kostenlos – Lesen Sie es online oder laden Sie sich ein PDF herunter.
Sollten Ihnen mein Werk so gut gefallen, dass Sie es honorieren möchten, nutzen Sie bitte den “Spenden”-Button.

Inhalte des Buches für KMUs

Teil 1: Einführung​

Teil 2: Klassisches Projektmanagement​

Teil 3: Agiles Projektmanagement

Grundlagen des Projektmanagements/ Projektmanagementmethoden

Der Rote Faden des Projektmanagements/ Projektmanagementtools/ Zusammenarbeit in Teams

Grundlagen von Agilität/ Agile Frameworks/ Softwareerstellung mit Scrum/ Agile Tools & Techniken/ Zusammenarbeit in agilen Teams

Als Projektmanagement-Laie interessiere ich mich dennoch für diese Thematik und finde, Sie haben die wesentlichen Punkte gut zusammengefasst. Ich habe jedenfalls einen umfassenden Einblick gewinnen und mein Wissen ein wenig ausbauen können, was vermutlich auch Ihr Ziel war. Daher vielen Dank für den Einblick und die Mühen, die dahinter stehen!

Ana Michels, VDI Wissensforum GmbH

PROJEKTMANAGEMENT FÜR DEN MITTELSTAND

Effiziente Methoden, Techniken und Verhaltensweisen für KMUs von Dipl.-Kfm. (FH) Michael Taube Auflage 1

Effiziente Methoden, Techniken und Verhaltensweisen für KMUs

von Dipl.-Kfm. (FH) Michael Taube ( Auflage 1)

© 2020 von Dipl.-Kfm. (FH) Michael Taube – alle Rechte vorbehalten. Es ist nicht zulässig, Teile dieses Dokuments elektronisch oder in gedruckter Form zu reproduzieren, duplizieren oder zu übertragen. Die Aufzeichnung dieser Publikation ist strengstens untersagt. Die Grafiken wurden alle vom Autor selbst erstellt. Ausnahme Abbildung 21 basiert auf den Grafiken der Visual AGILExicon® von Innolution, LLC and Kenneth S. Rubin.

Vorwort

Projektmanagementbücher gibt es wie Sand am Meer, besonders seit agile Projektmanagement-methoden im Fokus des öffentlichen Interesses stehen. Dieses Buch richtet sich an Projektleiter*innen[1], die es mit Projekten zu tun haben, die klassisch oder agil abgearbeitet werden. Ich möchte Ihnen die wichtigsten Methodenvertreter vorstellen und abwägen, wann welche Methode zum Einsatz kommen sollte.

Das Buch soll keine Anleitung für das Bestehen irgendeines Zertifikats sein, im Gegenteil! Das Buch ist ein Leitfaden für kleine und mittelständische Unternehmen. Das Anwendungsziel ist es, Projekte methodenstark und effizient umzusetzen.

Mein Buch richtet sich an Anfänger des Projektmanagements sowie Anfänger in der Führung von Teams, aber auch erfahrene Projektmitarbeiter. Dabei ist es egal, ob Sie selbst die Führungskraft sind oder im Kern-(Projekt-)Team tätig sind.

Um nach dem Lesen und Durcharbeiten des Buches Fragen und Anregungen aufnehmen zu können, habe ich auf der Buch-Website ein Forum eingerichtet. Sie sind herzlich eingeladen, dort aktiv Ihre Fragen, Beispiele und Anmerkungen zu posten.

Dieses Buch erläutert dem Leser Themen wie

  • klassisches Projektmanagement,
  • agiles Projektmanagement sowie
  • Softwareeinsatz im Projekt und
  • die Entwicklung des Projektmanagementteams.


Die Anrede im Buch bleibt beim deutschen „Sie“, obwohl es, gerade in der Agilen Welt Sitte ist zu duzen.

Stellen Sie fest, dass etwas fehlt, falsch dargestellt ist oder Sie eine andere Meinung haben, zögern Sie bitte nicht mir zu schreiben. Es wird irgendwann eine 2. Auflage geben, an der Sie dann mitgewirkt haben!

Michael Taube, im Juni 2020

[1] Im Folgenden benutzte ich für alle Begriffe immer die männliche Schreibweise.

TEIL 1: EINFÜHRUNG

Um in einem wettbewerbsintensiven[1] Geschäftsumfeld einen Vorsprung zu erlangen, ist die Fähigkeit Projekte

  • „in time“ (termingerecht),
  • „in budget“ (im Rahmen einer genehmigten Geldmenge) und
  • in Übereinstimmung mit den strategischen Zielen des eigenen Unternehmens


durchzuführen, sicherzustellen. Für diese Aufgabe gibt es Projektleiter. Projektleiter[2] haben damit eine sehr komplexe Aufgabe, die organisatorische und analytische und vor allem soziale Fähigkeiten vereinen.

In diesem Abschnitt führe ich Sie durch die Grundlagen des Projektmanagements und erläutere, was es bedeutet, ein Projektleiter zu sein.

[1] Häufig agieren Unternehmen heute europa- oder sogar weltweit.

[2] Ich verwende den Begriff des Projektleiters vorzugsweise im Buch. Synonym kann und wird der Begriff des Projektmanager benutzt.

Kapitel 1: Grundlagen des Projektmanagements

Die im Titel gestellt Frage „Wie definieren Sie ein Projekt?“ werden Sie sehr unterschiedlich beantworten. Ich möchte eine für KMUs sinnvolle Definition bilden. Meine Zusammenfassung basiert auf drei unterschiedliche Definitionen des Begriffes „Projekt“.

Deutsche Institut für Normung (DIN)

Das DIN mit seinem Stammhaus in Berlin ist für Deutschland häufig das Gremium, dass Sie als erstes befragen sollten. Daher schauen wir uns die Definition eines Projektes in der DIN-Norm 69901-2:2009-01[1] an. Danach ist ein Projekt ein „…Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, z. B. Zielvorgabe, zeitliche, finanzielle, personelle und andere Begrenzungen, Abgrenzung gegenüber anderen Vorhaben, projektspezifische Organisation.“

In Deutschland gibt es mehrere Projektmanagement- oder besser Projektmanagervereine und
-verbände. Neben dem größten Verein, der Deutsche Gesellschaft für Projektmanagement e.V. (GPM)[2], gibt es noch ITEMO IT Education Management Organisation e.V. (ITEMO)[3], die IAPM International Association of Project Managers (IAPM)[4] und andere, internationale wie das Project Management Institute (PMI). Diese Vereinigungen müssen sich voneinander abheben, da sie von Mitgliederbeiträgen und Zertifizierungsgebühren leben. Deshalb erweitern, detaillieren und/ oder verbessern sie, die vom DIN vorgeschlagene Definition.

Deutsche Gesellschaft für Projektmanagement e.V. (GPM)

Nach GPM gibt es keine einheitliche Definition, aber ein allgemeines Verständnis darüber, was ein Projekt ist. Ein Projekt nach dieser Anschauung

  • ist einmalig bzw. neu,
  • ist zeitlich begrenzt (Start- und Endtermin sind bekannt),
  • setzt auf die interdisziplinäre Zusammenarbeit vor allem im Kernteam,
  • hat eine festgelegte Ergebnisverantwortung und eine eigene Organisation,
  • ist komplex (mehrere Schnittstellen),
  • hat eine Zielvorgabe (vereinbartes Ziel vor Beginn) und
  • unterliegt limitierten Ressourcen.


Project Management Institute (PMI)

Das Project Management Institute (PMI)[5] definiert ein Projekt als „vorübergehendes Bestreben, ein einzigartiges Produkt, eine Dienstleistung oder ein Ergebnis zu schaffen“.

In dieser Definition sind einige wichtige Dinge zu beachten:

  • Das Wort „vorübergehend“ bedeutet, dass Projekte einen definierten Anfang und ein definiertes Ende haben müssen. Dies bedeutet, dass jedes Projekt einen Zeitplan, einen Umfang und Ressourcen enthalten muss. Die Tatsache, dass es vorübergehend ist, bedeutet auch, dass es nicht Teil des laufenden Betriebes ist.
  • Der Zweck eines Projekts muss darin bestehen, „ein einzigartiges Produkt, eine Dienstleistung oder ein Ergebnis zu schaffen“. Das bedeutet, dass ein Projekt gestartet wird, um ein bestimmtes Ziel zu erreichen, das normalerweise außerhalb des Bereiches des typischen täglichen Geschäftsbetriebes liegt. Daraus folgt, dass das Projektteam möglicherweise Personen umfasst, die normalerweise nicht zusammenarbeiten und Ressourcen benötigt werden, die in der Regel nicht im täglichen Betrieb vorgehalten werden.


Trivialdefinition

Suchen wir uns doch einfach das Beste aus den Vorschlägen aus und definieren für uns:

Ein Projekt

  • hat eine komplexe, neuartige Aufgabenstellung,
  • braucht (messbare) Ziele & Ergebnisse,
  • ist zeitliche befristet (Anfang und Ende),
  • hat begrenzte Ressourcen (finanziell, personell, sachlich) und
  • wird durch ein Teams bearbeitet.


Über die Definition erkennen wir, dass Projekte keine Regelarbeit sind. Projekte werden nicht in der Linienorganisation[6] abgearbeitet, sondern stehen neben der normalen Hierarchie eines Unternehmens.

Projekte müssen auf Grund ihrer Besonderheit im Unternehmen anders gemanagt werden als Regelarbeit. Wie das geht, erfahren Sie im nächsten Abschnitt.

[1] [DIN 69901]

[2] [GPM]

[3] [ITEMO]

[4] [IAPM]

[5] Das PMI ist als lokale Vereine organisiert. Beispielhaft führe ich unter [PMI] den Link zum Berliner Verein aufgeführt.

[6] Linienorganisation: hierarchische Aufbau in Unternehmen

Die DIN 69901 definiert Projektmanagement als Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mittel für die Abwicklung eines Projekts.

In der Praxis ist Projektmanagement die Anwendung von Kenntnissen, Fähigkeiten, Werkzeugen und Techniken, um ein Projekt mit spezifischen Anforderungen abzuschließen. Es kommt darauf an,

  • die Aufgabe zu identifizieren,
  • einen Plan zur Umsetzung zu erstellen und
  • diesen Plan dann umzusetzen.

Das klingt einfach, ist es aber häufig nicht, da in jeder Phase des Prozesses viel Arbeit und manchmal auch viel Ärger steckt.

Exkurs: Historische Entwicklung des Projektmanagements

Manche Experten legen die Wurzeln des Projektmanagements in den Zeitraum von 5.000 Jahren – 3.000 v.u.Z bzw. bis zum Bau der ägyptischen Pyramiden oder der Chinesischen Mauer.

Die moderne Entwicklung des Projektmanagements begann im 19. Jahrhundert, als Eisenbahnunternehmen Tonnen von Rohstoffen kaufen mussten und Tausende von Menschen beschäftigten, um an der transkontinentalen, amerikanischen Eisenbahn zu arbeiten.

Zu Beginn des 20. Jahrhunderts wandte „Frederick Winslow Taylor“ (ein US-amerikanischer Ingenieur)[1] Konzepte des Projektmanagements auf den Arbeitstag an und entwickelte Strategien, um intelligenter zu arbeiten und Unwirtschaftlichkeit zu begegnen, anstatt zu fordern, dass Arbeiter härter und länger arbeiten müssen. „Henry Gantt“, ein Kollege von Taylor, nutzte Taylors Konzepte und verwendete Balken und Diagramme, um grafisch darzustellen, wann bestimmte Aufgaben zur Bearbeitung anstanden und abgeschlossen wurden (Gantt-Diagramm[2]) und schuf so eine neue Möglichkeit zur Visualisierung von Prozessen.

In den 40er- und 50er-Jahren des letzten Jahrhunderts wurden weitere, detailliertere Managementstrategien entwickelt, was schließlich zu standardisierten Prozessen wie der Methode der Netzplantechnik[3] mit dem Kritischen Pfad[4] führte.

Diese Methoden wurden branchenübergreifend immer beliebter und 1965 bzw. 1969 wurden die International Project Management Association (IPMA)[5] und das PMI gegründet. Im Jahr 2001 wurden die Methoden des agilen Projektmanagements durch die Erstellung des Agilen Manifests[6] verschriftlicht.

Aktuelle Bewegungen im Bereich Projektmanagement liegen bei der Anforderungserstellung mit Design Thinking und der Erweiterung der Wertschöpfungskette durch die Einbeziehung des IT-Betriebes (DevOps[7]).

[1] [WIKIPEDIA], Fredrick Winslow Taylor

[2] [WIKIPEDIA], Gantt-Diagramm: Das Gantt-Diagramm wird häufig auch GANTT-Diagramm geschrieben, obwohl es kein Akronym ist.

[3] [WIKIPEDIA], Netzplantechnik

[4] [INLOOX]

[5] [IPMA]

[6] [AM]

[7] Bei Interesse recherchieren Sie bitte selbst unter den genannten Begriffen. Das Angbot ist fast unbegrenzt.

Die fünf Prozessgruppen des klassischem, DIN-normierten Projektmanagements sind:

  • Initialisierungsphase
  • Definitionsphase
  • Planungsphase
  • Steuerungsphase
  • Abschlussphase


Die Steuerungsphase wird auch als „Umsetzungsphase“ oder „Realisierungsphase“ bezeichnet, was besser den Aspekt der Facharbeit im Projekt darstellt. Für dieses Buch bleibe ich bei den Bezeichnungen des DINs, da sie den Blickwinkel des Projektleiters zeigt.

Im agilen Bereich werden Projekte iterativ und inkrementell bearbeitet. Dies bedeutet, statt der sequenziellen Arbeit in Phasen wird ein kurzer Arbeitsprozess immer wiederholt und dabei das Produkt in kleinen Schritten erstellt.

Das Projektmanagement hilft Ihrer Organisation,

  • einen vorhersehbareren Projektplanungs- und Ausführungsprozess zu haben,
  • Projektbudgets[1], Zeitpläne und Richtlinien einzuhalten,
  • Probleme zu erkennen und zu eskalieren,
  • Risiken zu identifizieren und darauf zu reagieren, sowie
  • eine Verbesserung der Zusammenarbeit zwischen und innerhalb von Teams zu initiieren.


Dabei wird das Projektmanagement dafür sorgen, dass das Projekt effizienter wird; aber auch, dass Projekte beendet werden, die keinen relevanten Geschäftswert mehr haben.

[1] Budget ist eine genehmigte Geldmenge, die der Projektleiter verbrauchen darf.

Einfach gesagt: Projektleiter sind für die Planung, Ausführung, Steuerung und Beendigung von Projekten verantwortlich.

Allerdings ist das nur die Spitze des Projektmanagement-Eisbergs. Um Ihnen einen Einblick in den Aufgabenumfang zu geben, habe ich die wichtigsten zusammengestellt:

  • Erstellen des Projektplans
    Projektleiter sind dafür verantwortlich, den realistischsten Plan für ein Projekt festzulegen. Der Plan muss den Projektumfang, den Zeitplan und das Budget berücksichtigen.
  • Stakeholder und Ziele managen
    Der Umgang mit Stakeholdern[1] und die Ableitung der Ziele gehört zur schwierigsten, weil ungewohntesten Aufgabe für die Projektleitung. Die Aufgabe besteht darin, relevante Stakeholder zu eruieren und (in Gesprächen oder dokumentengesteuert) die Interessenslagen und Absichten mit dem Projekt zu klären.
  • Projektteam zusammenstellen
    Die Identifizierung des richtigen Teams ist entscheidend für den Projekterfolg. Jedes Projektteam variiert je nach Umfang eines Projektes. Das Team soll vor allem die Schwächen[2] des Projektmanagers ausgleichen[3].
  • Projektorganisation etablieren
    Projektmanager müssen ihrem Team (häufig „Kernteam“ genannt) eine klare Definition von Aufgaben und Zeitplänen für jeden Teil des Projekts zur Verfügung stellen. Obwohl jedes Teammitglied für seine eigenen Aufgaben verantwortlich ist, erfordern viele Aufgaben die Zusammenarbeit der Teammitglieder. Eine Unterscheidung von internen und externen Kernteammitglieder sollte nicht erfolgen.
  • Teamführung
    Teamführung ist vor allem ein Soft Skill – „Ding“.
    Dazu gehört das Führen des Kernteams, das Erkennen und Beseitigen von Hindernissen, das Behandeln von Meinungsverschiedenheiten, das Aufrechterhalten der Teammotivation sowie das Bereitstellen von Schulungen und Mentoring.
  • Budgetverwaltung
    Im Planungszeitraum werden die Kosten des Projektes kalkuliert und mit dem Budget verglichen. Wenn das Budget zu klein war, muss nachbeantragt werden. Ohne Genehmigung eines höheren Budgets[4], kann die Steuerungsphase nicht starten. Allerdings muss in der Umsetzungszeit darauf geachtet werden, dass Abweichungen vom Plan nicht zu höheren Kosten führen werden, falls doch, dass dann Nachträge beantragt werden.
  • Verwalten von Zeitplänen
    Wie beim Budget haben Projektmanager die Aufgabe, alles im Zeitplan zu halten. Dies erfordert die Planung realistischer Fristen, die durchgängige Kommunikation mit dem Kernteam sowie den Arbeitspaketverantwortlichen[5] und die Einhaltung eines detaillierten Zeitplans.
  • Übergabe des Projektgegenstandes
    Am Ende der Steuerungsphase wird der Projektgegenstand übergeben. Häufig wird damit auch das Ende des Projektes verbunden. Weit gefehlt: Danach muss der Projektmanager in der Abschlussphase einiges erledigen, u. a. – und vielleicht am wichtigsten – ist das Lernen aus den Erfahrungen im aktuellen Projekt.


In agilen Projekten sind die Aufgaben erheblich unterschiedlicher, zumal es gar keinen Projektmanager gibt. Ich werde Ihnen später mehr davon berichten.

[1] Stakeholder, aus dem engl. to hold a stake on something = Interesse an etwas (hier: Projekt) haben

[2] Auch Projektleiter wie andere Führungskräfte sind nur Menschen und können Schwächen haben.

[3] In KMUs kommt es allerdings auch vor, dass ein Projektleiter ohne Team seine Aufgaben erfüllen muss.

[4] Dasselbe gilt auch für die Zeit.

[5] Verantwortliche für die Planung und Umsetzung der Facharbeiten, arbeiten intensiv mit dem Kernteam zusammen

Der Titel eines Projektmanagers ist nicht geschützt. Es gibt keinen anerkannten IHK-Beruf „Projektmanager“[1]. Daher ist es auch nicht notwendig ein Zertifikat vorzuweisen, um sich als Projektmanager bezeichnen zu dürfen. Manche Arbeitgeber bevorzugen allerdings einen Zertifikatsnachweis, und Sie sollten selbst daran Interesse haben, um Ihren Stand am Arbeitsmarkt zu verbessern.

Es gibt eine Reihe von Verbänden, Vereinen und kommerziellen Anbietern, die Projektmanagement-Zertifizierungen vorbereiten.

Für den deutschsprachigen Raum sind die wichtigsten Zertifikate:

  • Klassisches Projektmanagement
    • Basiszertifikat im Projektmanagement (GPM)
    • IPMA® Level D – Certified Project Management Associate
    • Certified Project Manager (IAPM)
    • CERTIFIED ASSOCIATE IN PROJECT MANAGEMENT NACH PMI®
    • PRINCE2® Foundation / PRINCE2® Practitioner[2]
  • Agiles Projektmanagement
    • EXIN[3] Agile Scrum Foundation/ EXIN Agile Scrum Master/ EXIN Agile Product Owner
    • SCRUM Foundation Zertifizierung (TÜV Süd nach ITEMO)
    • org Professional Scrum Foundations™
    • Scrum Alliance Certified ScrumMaster®


Ich spreche an dieser Stelle keine Empfehlung aus, darf aber berichten, dass in der freien Wirtschaft kaum ein Mitarbeiter in der Personalabteilung, nicht mal die Mitarbeiter der Fachabteilungen, die Unterschiede kennen.

Sie sollten sich bei Ihrer Auswahl danach richten,

  • welches PM-System in Ihrem Unternehmen benutzt wird,
  • in welcher Sprache Sie die Prüfung ablegen wollen und
  • ob die Prüfung am PC oder schriftlich auf Papier durchgeführt werden soll.

Achten Sie ebenfalls darauf, dass Sie ein zeitlich unbegrenztes Zertifikat erwerben. Das wird Ihnen in der Zukunft Geld und Arbeitszeit ersparen.

Im nächsten Kapitel werde ich Ihnen unterschiedlichste Projektmanagementmethoden erläutern und dabei auf die Unterschiede zwischen dem klassisch-sequenziellen und dem agilen Arbeiten eingehen.

[1] Es gibt allerdings bei der IHK-Weiterbildungen zum Thema.

[2] PRINCE2 zählt neben PMBOK (Project Management Institute) und ICB (IPMA, GPM) zu den führenden Projektmanagementmethoden weltweit.

[3] EXIN, Scrum.org und Scrum Alliance sind die bekanntesten Zertifizierungsorganisationen im agilen Bereich.

Kapitel 2: Projektmanagementmethoden

Wie Sie bereits anhand der unterschiedlichen Zertifizierungsmöglichkeiten gesehen haben, gibt es eine fast endlose Zahl an Projektmanagementmethoden.

Grundsätzlich sind nur drei Bereiche zu unterscheiden:

  • Klassisches Projektmanagement
    • Um eine sequenzielle Abarbeitung eines Projektes zu gewährleisten, muss vor dem Projekt die Projektaufgabe bekannt sein. Damit ist es möglich, Pläne zu erstellen, Zeit und Kosten zu kalkulieren und Stakeholder und deren Ziele zu involvieren.
    • Änderungen in der Zeit der Umsetzung lassen sich schwer einarbeiten. Da im klassischen Projektmanagement die Planung zu Anfang steht, muss die gesamte Planung wieder geändert werden, sobald eine neue Anforderung ins Haus steht.
    • Durch eine eindeutige Zuordnung von Arbeiten zu Phasen, ist sichergestellt, dass auch keine Projektmanagementaufgabe übersehen oder gar vergessen wird.
  • Agiles Projektmanagement
    • Agile Projekte gehen davon aus, dass am Anfang eines Projektes noch nicht der komplette Wissensumfang über den Projektgegenstand bereitsteht.
    • Agile Projekte haben Methoden, um mit neuen oder veränderten Anforderungen umzugehen.
    • Und, und nun wird’s komisch - zumindest für uns Älteren-, das agile Umfeld propagiert, dass die Mitarbeiter Spaß bei der Arbeit haben sollen.
  • Hybride Ansätze
    • Hybrides Projektmanagement bezeichnet die Kombination von zwei oder mehr Projektmanagement-Systemen. Am häufigsten wird von Hybridem Projektmanagement gesprochen, wenn traditionelle und agile Methoden in einem Projekt kombiniert werden[1].
    • Es gibt bisher noch keine „echte“ Hybride Projektmanagementmethode, sondern nur der Versuch der Kombination.


Gemeinsam ist allen drei Bereichen, dass jede Methode eigene Prozesse und Werkzeuge hat.

Wenn Sie nach einer schnellen visuellen Anleitung zu gängigen Methoden suchen, finden Sie bei dem PM-Software-Anbieter Wrike Inc. eine interessante Infographik[2] oder Sie lesen in Ruhe weiter.

In den Teilen 2 und 3 des Buches gehe ich dezidiert auf einzelne Methoden ein. Im Moment sollte dieser Überblick zur Orientierung reichen.

[1] [PROJEKTMAGAZIN]

[2] [WRIKE]

In den folgenden Kapiteln kann ich Ihnen nicht alle Methoden vorstellen. Das würde den Rahmen des Buches sprengen. Ich werde eine Auswahl nach der Wichtigkeit der Methoden treffen.

Wasserfall-Projektmanagement-Methode

Wie planen Sie ein Projekt, egal ob beruflich oder privat? Sie werden die Aufgaben, die zu einem Ergebnis führen, ordnen und arbeiten Sie der Reihe nach ab.

Das entspricht dem Wasserfall-Modell – die grundlegende Methode zum Verwalten von Projekten. Eigentlich aus dem Bauwesen stammend, wurde sie für die IT-Branche, genauer für die Softwareentwicklung von „Herbert D. Benington“[1] im Jahre 1956 zum ersten Mal genannt. 1983 wurde die Methode überarbeitet.

 

Abbildung 1: Wasserfallmodell

Die Idee des Wasserfall-Modells: Eine Aufgabe muss abgeschlossen sein, bevor die nächste beginnt und ist damit eine ideale Methode für Projekte, die zu physischen Objekten wie Gebäuden oder Computern führen. Darüber hinaus können Projektpläne für zukünftige Verwendungen problemlos kopiert werden.

Beispiel Vorgehensmodell

In einem Fertigungsunternehmen werden Smart-TVs zusammengesetzt. Hier ist es nicht sinnvoll,

  • die Platine in das Gehäuse zu montieren,
  • danach die Stromversorgung auf die Platine zu löten und
  • dann das Kühlsystem zu montieren.


Evtl. ist dieser Weg sogar möglich, doch kompliziert und teuer.

Die Ingenieure werden den Fertigungsprozess so planen, dass alle Teile sequenziell zusammengebaut werden.

Die Stärke des Wasserfall-Modells besteht darin, dass jeder Schritt in der richtigen Reihenfolge vorgeplant wird. Die Aufgaben sind damit sehr einfach zu implementieren Aber Änderungen von Kundenbedürfnisse oder -anforderungen stören die Abfolge der Aufgaben, was die Verwaltung sehr schwierig macht.

Das Modell zeichnet sich durch Vorhersagbarkeit aus, ist jedoch nicht flexibel. Ein entscheidender Nachteil für die Softwareentwicklung ist der späte Einsatz des Testens sowie die einmalige Abnahme des Projektgegenstandes.

Critical Path Method (CPM)

Die Critical Path Method ist eine Projektmodellierungstechnik, die Ende der 1950er Jahre von „Morgan R. Walker“ von DuPont und „James E. Kelley Jr.“ von Remington Rand entwickelt wurde[2]. Sie basiert auf dem Konzept, dass es einige Aufgaben gibt, die erst starten können, wenn eine vorherige abgeschlossen wurde. Wenn Sie diese abhängigen Aufgaben von Anfang bis Ende aneinanderreihen, bekommen Sie den Kritischen Pfad des Projektes.

Durch das Fokussieren auf den Kritischen Pfad können Projektleiter Einsatzmittel priorisiert zuweisen, um die wichtigsten Aufgaben zu erledigen. Andere Aufgaben werden bei der Ressourcenverteilung später betrachtet. Gerade bei der oben bereits diskutierten Anforderungsänderung ist diese Methode besonders hilfreich.

In der Netzplantechnik[3] ist es möglich, mittels des Kritischen Pfades zudem die Projektlaufzeit zu errechnen.

DIN-Normen

Das Deutsche Institut für Normung hält mehrere Normen für die Projektbearbeitung bereit. Bereits erwähnt habe ich die DIN ISO 69001, darüber hinaus gibt es die 69000 sowie die 21500[4] aus dem Jahre 2012.

Die Vorteile der 69er Normenfamilie liegt in seiner generischen Ausrichtung. Im Grunde können Sie alle Projekte egal wie groß, lang, komplex oder wie verschieden der Inhalt des Projektes ist, bearbeiten.

Als Grundlage für eine Weiterbildung im Projektmanagement ist ein Training, dass sich auf diese Normen bezieht, sicher sinnvoll.

Die neue, europäisierte Norm DIN ISO 21500 nimmt die Weiterentwicklungen der letzten 20 Jahre auf und führt einige in Europa gängige Normen zusammen.

PRINCE2

PRINCE2 (engl.: Projects in Controlled Environments / Projekte in kontrollierten Umgebungen) ist eine Methode zur Verwaltung von Projekten, die von der britischen Regierung empfohlen und verwendet wird und sich durch einen produktbasierten Planungsansatz auszeichnet.

In PRINCE2 gehören Aktivitäten auf hoher Ebene wie die Übernahme der Verantwortung des Projekterfolges und die Bereitstellung von Ressourcen und Mitteln einem Lenkungsausschuss, während sich der Projektmanager um die täglichen Aktivitäten auf niedrigerer Ebene kümmert.

PRINCE2 ist schon „ein wenig“ agil, weil die Detailplanung jeder Phase erst zu Beginn der entsprechenden Phase erfolgt und nicht komplett vor dem Start der Facharbeit.

V-Modell XT

Das V-Modell XT ist ein flexibles Modell zum Planen und Durchführen von Systementwicklungsprojekten. Im Februar 2005 wurde das erste Release des V-Modells XT fertiggestellt und löste das V-Modell 97 ab. Der Zusatz “XT” steht dabei für “eXtreme Tailoring”.

Es unterstützt die Arbeit von Projekten, indem es Ergebnisse und Abläufe vorgibt, so dass zu keinem Zeitpunkt unnötige Arbeiten und möglichst auch keine Leerlaufzeiten entstehen. Zusätzlich regelt das V-Modell XT die Kommunikation zwischen Auftraggeber und Auftragnehmer, um Quellen für Missverständnisse zwischen den Beteiligten auszuschließen[5].

Das V-Modell XT finden Sie häufig als Prozessmodell in deutschen Verwaltungen.

PMBOK-Methode

PMBOK steht für Project Management Body of Knowledge[6]. Das PMBOK ist ein Leitfaden, der ca. alle vier Jahre vom Herausgeber, dem Project Management Institut überarbeitet wird. Der Leitfaden ist vom American National Standard Institute (ANSI) 1999 als Standard genehmigt worden. Er gilt weltweit als anerkanntes Referenz- und Nachschlagewerk für Projektmanagement.

Die erste Ausgabe des PMBOK erschien 1996, die derzeit gültige 6. Edition wurde am 06. September 2017 veröffentlicht.

Der Leitfaden ist branchenneutral, sowie industrie- und methodenunabhängig formuliert und lässt sich bei Projekten jeglicher Größe und Umfang anwenden. Er folgt der Idee, dass der Projektmanager individuell entscheidet, welche Inhalte er aus dem PMBOK für das konkrete Projekt nutzen möchte. Strukturiert ist das Werk in Wissensgebiete, Prozessgruppen und Prozesse sowie Beschreibungen von Inputs, Outputs und geeigneten Werkzeugen und Methoden[7].

Auch wenn hier eine Entscheidung des Projektmanagers erfolgt, welche Elemente er in einem speziellen Projekt nutzt, ist das PMBOK immer noch den traditionellen, sequenziellen Vorgehensmodellen zu zuordnen.

[1] [WIKIPEDIA], Wasserfallmodell

[2] [WIKIPEDIA], CPM

[3] Einen ausführlichen Beitrag zur Netzplantechnik finden Sie unter [SCHRÖDER]

[4] [DIN]

[5] [V-Modell XT]

[6] [PMBOK]

[7] [T2INFORMATIK]

Die neue Ausrichtung von (vor allem) Softwareprojekten in den 90er Jahren des letzten Jahrhunderts mündete in der Veröffentlichung des „Manifest für die Softwareentwicklung“ 2001. Darin haben 17 erfahrende Softwareprojektleiter mit vier Werten und zwölf Prinzipien ausgedrückt, wie sie Softwareprojekte verbessern wollen.

Die Ausgangssituation war, dass viele, erfahrende Projektmitarbeiter den Eindruck hatten, dass die aktuellen Projektmanagementmodelle mit den spezifischen Anforderungen von Softwareprojekten nicht mehr klarkamen.

Diese neuen Ansätze waren anfänglich für Softwareentwicklungsprojekte gedacht, finden sich aber heute in vielen Projekten anderer Branchen wieder.

Das Agile Manifesto lautet im Deutschen:

„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und andere dabei helfen.

Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

  • Individuen und Interaktionen mehr als Prozess und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als umfassende Dokumentation
  • Reagieren auf Veränderungen mehr als das Befolgen eines Plans


Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.“[1]

Abbildung 2: Auszug aus der Website “https://agilemanifesto.org/”

Im Manifest wurde damit eine bahnbrechende Denkweise für die Bereitstellung von Werten und die Zusammenarbeit mit Kunden beschrieben. Heutzutage bezieht sich der Begriff „Agilität“ auf diese Werte sowie auf die Frameworks, deren Implementierung sich auf das Agile Manifest beziehen (z. B. Scrum, Kanban, extreme Programmierung…).

Was haben alle agilen Frameworks gemeinsam? Zumeist handelt es sich nicht um komplette Projektmanagementsysteme. Daher wird von Frameworks, also Rahmenwerke gesprochen. Bei Scrum werden Sie dies später im Buch genau erkennen können.

Die Projektziele werden vom Kunden frühzeitig im Projekt klar definiert, während sich das endgültige Ergebnis im Verlauf des Projekts ändern kann. Das Projektteam arbeitet in iterativen Zyklen und bewertet die Arbeitsergebnisse immer am Ende jeder Iteration. Abhängig von den Ergebnissen dieser Bewertungen, kann das Ergebnis wieder geändert werden, um den Kundenanforderungen besser gerecht zu werden. Kontinuierliche Zusammenarbeit ist sowohl innerhalb der Mitglieder des Projektteams als auch mit den Projektbeteiligten (insbesondere dem Kunden) von entscheidender Bedeutung.

Scrum

Scrum ist das aktuell beliebteste agile Entwicklungsframework, da es relativ einfach zu lernen und zu implementieren ist. Es löst viele Probleme, mit denen Softwareentwickler zuvor zu kämpfen hatten, wie z. B. unangepasste Entwicklungszyklen, unflexible Projektpläne und verschobene Produktionspläne.

Scrum basiert auf den drei Säulen Rollen, Rituale und Artefakte und hat einige wenige Regeln. Der „Scrum Guide“, ein regelmäßig aktualisiertes Dokument von den Machern hinter Scrum „Jeff Sutherland“ und „Ken Schwaber“, besteht aus gut 20 Seiten und ist frei verfügbar[2].

Kanban

Kanban ist eine Methode in der Softwareentwicklung, bei der die Anzahl paralleler Arbeiten, der sog. Work-in-Progress (dt.: in Arbeit) begrenzt und kürzere Durchlaufzeiten erreicht werden sollen. Probleme, insbesondere Engpässe, sollen so schnell sichtbar gemacht werden können.

Kanban wurde von Toyota in den 1940er Jahren entwickelt und war ursprünglich ein visuelles Kartensystem[3] für die Fertigungsindustrie.

Extreme Programmierung (XP)

Extreme Programming (XP) ist eine Methode, die das Lösen einer Programmieraufgabe in den Vordergrund der Softwareentwicklung stellt. Dem formalisierten Vorgehen wird bei XP eine geringere Bedeutung zu gemessen. XP ist ein Vorgehensmodell, das sich den Anforderungen des Kunden in kleinen Schritten annähert.

XP zeichnet sich durch kurze Arbeitszeiträume, häufige Iterationen und ständige Zusammenarbeit mit Stakeholdern aus. Änderungen können im Gegensatz zu Scrum, innerhalb eines Sprints auftreten. Wenn die Arbeit an einer bestimmten Funktion oder Anforderung noch nicht begonnen hat, kann sie ausgetauscht und durch eine ähnliche Aufgabe ersetzt werden.

Im zweiten Teil des Buches werde ich Ihnen ein generisches Projektmanagementsystem erläutern. Dabei werden Sie die besten Ansätze lernen, unabhängig vom Zertifizierungssystem, um in einem mittelständischem Unternehmen Projekte effizient durchzuführen.

[1] [AM]

[2] [SCRUM GUIDE]: Die aktuelle Ausgabe wurde im November 2017 veröffentlicht.

[3] Kanban ist japanisch und bedeutet so viel wie „Karte“, „Tafel“ oder „Beleg“.

TEIL 2: KLASSISCHES PROJEKTMANAGEMENT

Es gibt unterschiedliche Ansätze, wie Projekte abzuarbeiten sind.

Als Projektleiter sollten wir uns einem Vorgehensmodell unterwerfen. Mit Sicherheit ist es kein Fehler, das DIN-Vorgehensmodell zu benutzen.

In der DIN-Norm 69901-2:2009-01 schlug das Deutsche Institut für Normung ein 5-phasiges Konstrukt als Vorgehensmodell für die Bearbeitung eines Projektes vor. Der Sinn war es, den Projektmitarbeitern eine klare Anweisung zu geben, welche Arbeitsschritte sie durchzuführen haben. Das soll ein bestimmtes Niveau (Güte) von Qualität in die Projektarbeit bringen.

Hilfreich ist das Vorgehensmodell vor allem für Anfänger oder Quereinsteiger, aber auch Projektleiter mit Erfahrung können daraus lernen. Der besondere Vorteil besteht darin, nichts zu vergessen und auch unangenehme Aufgaben zu erledigen.

Grundprinzip ist die sequenzielle Bearbeitung von Phasen (große Blöcke von Arbeit), was bedeutet, dass eine neue Phase erst dann begonnen werden darf, wenn alle Tätigkeiten der vorhergehenden Phase abgeschlossen wurden[1].

Auch wenn wir grundsätzlich vom Vorgehensmodell des DIN ausgehen, ist es sinnvoll sich über den Beginn des Projektes noch ein paar grundlegende Gedanken zu machen.

Wer will wissen, wann ein Projekt startet?

Es sind einerseits die Menschen, die das Projekt beauftragen bzw. jene, die es organisieren sollen, und es sind die, welche darin fachlich arbeiten. Ich hätte auch einfach schreiben können „alle“. Allerdings gehen unterschiedliche Kreise von unterschiedlichen Starts aus.

Wir Projektmitarbeiter brauchen einen klaren Blick auf die Arbeiten des Planens und Steuerns sowie der Auflösung des Projektes, weil die anderen Projektbeteiligten glauben, dass das Projekt nur die Facharbeit ist. Damit fängt für uns das Projekt sehr viel früher an als für die anderen Projektbeteiligten.

[1] Durch die Größe des Projektes wird die Intensität der Bearbeitung beeinflusst. Je größer ein Projekt ist, desto intensiver und länger muss ich einzelne Aufgaben erledigen.

Kapitel 3: Der Rote Faden des Projektmanagements

In meinem ersten Projektmanagement-Seminar, das ist bereits über 12 Jahre her, wurde mir der Rote Faden des Projektmanagements[1] vorgestellt. Die Idee ist die Visualisierung des Vorgehensmodells nach DIN. Bis heute ist dieser Rote Faden ein sinnvolles Denkmodell in klassischen Projekten.

Abbildung 3: Der Rote Faden des Projektmanagement

[1] Der Begriff des roten Fadens hat sich bei vielen Projektteams durchgesetzt. Das Bild eines roten Fadens soll helfen, den sequenziellen Ablauf eines Projektes zu verstehen. Begriffe wie „Rückrat des Projektes“ werden ebenfalls benutzt.

Im Kapitel 1.1 haben wir bereits definiert, was ein Projekt nach DIN ist. Damit entsteht in unserem Kopf eine gewisse Klarheit. Sie schützt uns davor Fehler zu machen, wenn wir unüberlegt losarbeiteten.

Erschwerend kommt hinzu, dass Sie auch mal ein Projekt bekommen, die Sie gar nicht überblicken können. Konsequenz: Ahnungslosigkeit und Unverständnis lassen das Projekt scheitern oder wie es allgemein gesagt wird: „Sage mir wie dein Projekt beginnt und ich sage dir, wie es endet“[1].

Aus diesen Überlegungen heraus ist es sinnvoll, vor der Projektbeauftragung festzustellen, was wir für ein Projekt vor der Nase haben. Dies ermitteln wir mittels sog. Dimensionen wie Projektgröße, Projektlänge, wer der Kunde ist, der Projektart und der Projektorganisation.

Sicher gibt es auch weitere Kriterien, aber wenn Sie diese fünf vor dem Projekt wissen, sind Sie gewappnet.

Betrachten wir die Dimensionen näher.

  • Projektgröße (klein, mittel, groß)’Nicht die absolute Größe des Budgets ist hier gemeint, sondern das Niveau. Je geringer das Budget desto übersichtlicher ist die Aufgabe.
  • Projektlänge (klein, mittel, groß)
    Es gibt keine verbindlich Einteilung, wann ein Projekt als z. B. „klein“ zu bezeichnen ist. Ich habe für mich die Einteilung gewählt: bis drei Monate (klein), bis sechs Monate (mittel) und darüber hinaus (groß).
  • Kundenprojekt (extern, intern)
    Basiert das Projekt auf einen Kundenwunsch? Kunde können von extern, aber auch von intern kommen. Obwohl diese Einteilung keine Rolle in der Bearbeitung des Projektes spielt, wird damit oft abgeleitet, dass externe Projekte wichtiger sind, weil sie von einem Kunden bezahlt werden.
  • Projektart
    Projekte werden nach dem Projektgegenstand eingeteilt: Wird eher eine Sachanlage gebaut (Investitionsprojekt) oder muss das Unternehmen umgebaut werden (Organisationsprojekt) oder haben wir ein Forschungs- und Entwicklungsprojekt vor uns?
  • Projektorganisation
    Es wird unterschieden, welche Weisungsbefugnis der Projektleiter hat und wie viel Zeit die Kernteammitglieder im Projekt arbeiten (Einfluss-, Matrixprojektorganisation, Autonome Projektorganisation).


Beispiel Lagerhalle

Beim Bau einer neuen Lagerhalle eines 35-Mann Betriebes in Brandenburg sieht die Bewertung folgendermaßen aus:

  • Projektgröße: groß
  • Projektlänge: mittel
  • Kundenprojekt: intern
  • Projektart: Investitionsprojekt
  • Projektorganisation: Matrix


Mit welchem Projekt sollten Sie als Anfänger beginnen? Ich empfehle immer meinen Schulungsteilnehmer als erstes einen Drucker zu kaufen. In der obigen Einteilung hieße das: kleine Projektgröße und –länge, internes Investitionsprojekt und eine Einflussorganisation. Zusammengefasst: es ist einfach, übersichtlich und wir werden weniger Fehler machen!

Die Initialisierungsphase kann über Jahre gehen und Millionen kosten. Nämlich dann, wenn das danach folgende Projekt die entsprechende Größe hat.

Darüber hinaus ist noch in Erweiterung des bisherigen Einzelprojektbezugs die Auswahl der Projektideen eines Unternehmens zu betrachten.

Die nachfolgenden Aufgaben für die Initialisierungsphase sind eine Sammlung von Aufgaben, die nicht immer und in jedem Projekt vorkommen:

  • Machbarkeitsstudie
  • Pflichten- und Lastenheft
  • Make-or-Buy.


Am Ende der Initialisierungsphase müssen alle Informationen vorhanden sein, damit eine Projektbeauftragung möglich ist.

Betrachten wir die Aufgaben näher.

Machbarkeitsstudie

Eine Machbarkeitsstudie ist manchmal die Grundlage für ein internes Projekt. Daher muss sie in der Initialisierungsphase erstellt werden. Man kann sich aber gut vorstellen, dass die Machbarkeitsstudie selbst so groß ist (z. B. für ein neues Automodell), dass sie als eigenes Projekt bearbeitet wird.

Pflichten- und Lastenheft

Soll ein Projekt auf einen Vertrag mit einem externen Kunden basieren, ist es wichtig, eine genaue Beschreibung des Vertrages zu haben. Dafür dienen Pflichten- und Lastenheft.

  • Lastenheft
    Im Lastenheft beschreibt der Kunde „was“ erstellt werden soll und „wofür“.
    Das Dokument kann in einer einfachen, muss aber vor allem in der Sprache des Kunden erstellt werden.
    Es ist durchaus möglich, manchmal sogar sinnvoll, dass ein Berater den Kunden bei der Erstellung des Dokuments hilft (natürlich gegen eine angemessene Aufwandsentschädigung). Nicht sinnvoll ist es, dass der mögliche Lieferant dies tut. Der Lieferant wird dem Kunden beschreiben, was er liefern möchte, nicht was der Kunde braucht.
  • Pflichtenheft
    Das Pflichtenheft ist der Realisierungsvorschlag des Auftragnehmers auf Grund des Lastenheftes.


Beide Dokumente werden bei der späteren Projektbeauftragung einen Teil der Rahmenbedingungen ausmachen.

Wenn das Pflichten- und Lastenheft abgestimmt sind, werden sie Bestandteil eines Vertrages. Durch Angebot und Annahme entsteht ein Vertrag zwischen dem Kunden (externes Unternehmen / Organisation) und dem liefernden Unternehmen.

Dieser Vertrag darf nicht mit der Projektbeauftragung verwechselt werden!

Make-or-Buy

Eigentlich stammt die Entscheidung die Software selbst zu erstellen oder einzukaufen aus den 1980er – 90er Jahren. Damals war Standardsoftware noch nicht so verbreitet wie heute. Nachdem aber immer mal wieder Seminarteilnehmern von dieser Entscheidung berichten, habe ich sie aufgenommen.

Manchmal ist es sinnvoll, nicht auf Standardsoftware zurückzugreifen; insbesondere dann, wenn Ihre Businessprozesse so besonders sind, dass Standards sie nicht abbilden können.

[1] Andere PM Sprüche finden Sie unter [PM SPRÜCHE]

Nach dem Roten Faden findet die Initialisierungsphase vor dem Projekt statt. Sie hat die Aufgabe, den Projektauftrag vorzubereiten. Mit dem Projektauftrag wird das Projekt gestartet.

Ich werde Ihnen in den nachfolgenden Phasen sämtlich Tätigkeiten aufzählen, die benötigt werden. Dabei unterscheide ich die Menge an Informationen nach der Bedeutung für das Projektmanagement.

Kernteam zusammenstellen

Das Kernteam sind die Mitarbeiter des Projektmanagers – die Mannschaft, die das Projekt vom ersten bis zum letzten Tag begleitet, alle Arbeiten planen und steuern werden.

Daher ist es notwendig sehr sorgsam die Auswahl der Mitarbeiter zu betreiben. Doch nach welchen Kriterien sollten wir das Kernteam zusammenstellen? Grundsätzlich ist es sinnvoller, erst sachliche Aspekte zu betrachten und dann soziale.

Der Projektleiter wird sich mehrere Rollen überlegen und diese Rollen beschreiben müssen: Tätigkeiten, Fähigkeiten und Befugnisse. Mit dieser Beschreibung geht der Projektleiter zu den entsprechenden Linienvorgesetzten und lässt sich die in Frage kommenden Mitarbeiter „zeigen“.

Gibt es die Chance, dass mehrere Mitarbeiter zur Auswahl stehen, sollte der Projektleiter dann nach sozialen Erwägungen entscheiden.

Beispiel Kernteam

Wir befinden uns in einem Marketingprojekt. Der Projektleiter braucht für sein Kernteam einen Mitarbeiter, der sich mit Facebook-Kampagnen auskennt. Es ist sinnvoll, diese Anforderung deutlich aufzustellen.

Sollte die Anforderung an einen Mitarbeiter nicht klar sein, wird der Linienvorgesetzte in der Marketingabteilung vermutlich denjenigen in das Projekt schicken, der entbehrlich ist.

Ob dieser Mitarbeiter seine Projektmanagementaufgaben erfüllen kann, ist fraglich.

Im Zuge der Mitarbeiterauswahl muss geklärt werden, in welcher Projektorganisationsform gearbeitet wird. Die Projektorganisation unterscheidet im Wesentlichen die Länge der Arbeitszeit der Kernteammitglieder und die Weisungsbefugnis des Projektleiters.

  • Autonome Projektorganisation
    Die Kernteammitglieder wie der Projektleiter arbeiten zu 100% im Projektmanagement. Der Projektleiter hat disziplinarische Weisungsbefugnis.
  • Matrix-Projektorganisation
    Die Kernteammitglieder arbeiten nur zu einem Prozentsatz kleiner 50% im Projektmanagement. Der Projektleiter hat fachliche Weisungsbefugnis.
  • Einfluss-Projektorganisation
    Die Kernteammitglieder arbeiten nur zu einem Prozentsatz weniger als 10% im Projektmanagement. Der Projektleiter hat keine Weisungsbefugnis. Er muss sein Team so führen, dass es mit ihm „freiwillig“ zusammenarbeiten will.


Für klein und mittelständische Unternehmen wird selten bis nie die autonome Projektorganisation sinnvoll sein. Diese Unternehmen haben zu wenige Mitarbeiter, um sie zu 100% in die Verwaltung von Projekten zu stecken. In Deutschland treffe ich am häufigsten die Matrixorganisation an.

Bei der Auswahl der Kernteammitglieder sollte der Projektleiter darauf achten, dass die Mitarbeiter die eigenen Schwächen ausgleichen. Prüfen Sie, was Sie können, und seien sie mutig auch zuzugeben, dass Sie Bereiche haben, die nicht Ihre Stärke sind. Selbstreflexion gehört zu den Stärken eines Projektleiters. Für die Auswahl nach sozialen Aspekten bieten sich einige Rollenmodelle an: Belbin[1], Quinn[2] oder das DISG persolog[3].

Regelkommunikation im Projekt

Ab dem ersten Tag eines Projektes muss der Projektleiter aus dem Projekt berichten. Anfänglich sind die Adressaten der Projektbeauftrager, die neuen Mitarbeiter und vielleicht ein externer Kunde. Im weiteren Verlauf des Projektes werden weitere Adressaten dazu kommen.

Schaffen Sie sich Templates an, um Ihre Berichte zu standardisieren. Der bekannteste Bericht ist der Projektstatusbericht. Er ist ein hochverdichteter, einseitiger Bericht und wird häufig mittels Ampeln oder Cockpit-Graphiken visualisiert.

Ein guter Projektleiter plant sein Berichtswesen von Anfang an. Damit ist gewährleistet, dass alle am Projekt interessierten Menschen genau die Informationen erhalten, die sie wünschen oder benötigen.

Im Berichtsplan werden

  • alle Interessierten aufgeführt,
  • die zu vermittelnden Informationen und
  • die Art der Übermittlung


geplant. Nutzen Sie dabei moderne Kommunikationswege. Persönliche Berichte kosten viel Zeit (Beispiel: Sie arbeiten in Berlin und müssen in München reporten).

Woher wissen Sie, welches die richtigen Informationen sind für einen bestimmten Menschen. Fragen Sie ihn, aber schlagen Sie ihm dabei einen Informationsumfang vor, den Sie bewältigen können.

Umfeldanalyse

Jetzt haben wir uns genug mit uns selbst beschäftigt, schauen wir uns das Umfeld unseres Projektes an.

Ein Projekt arbeitet nicht im luftleeren Raum. Es hat viele Schnittstellen zu anderen Akteuren. Akteure können Menschen sein, Organisationen, Gesetzte und Verordnungen oder das Wetter. Ich benutze absichtlich den Begriff Akteur, um eine gewisse Abstraktionshöhe in diesem Werkzeug zu erreichen.

Häufig konnte ich beobachten, dass sich Kernteams sehr schnell in Details verlieren und damit Dinge / Akteure übersehen.

Beispiel Hausbau

Sie errichten ein Einfamilienhaus und entdecken in der Umfeldanalyse, dass Sie Genehmigungen brauchen. Vermutlich fällt Ihnen sofort das Bauamt ein – oder sogar gleich Frau Müller vom Bauamt. Wenn Sie sich im weiteren Verlauf des Projektes auf diese Dame konzentrieren, übersehen Sie, dass Ihr Haus im Wasserschutzgebiet liegt oder eine Straßenanbindung notwendig ist.

Um nichts zu übersehen gestalten wir die Umfeldanalyse so, dass sie sehr abstrakte Umfelder findet: nicht das Bauamt, sondern die darüber liegende Gemeinde ist ein gutes Umfeld.

Nach dem Sammeln der Umfeldern teilen wir sie gleich auch in Kategorien ein:

  • Soziale und sachliche Umfeldfaktoren
    • Soziale Umfeldfaktoren sind die Menschen in unserem Projekt. Zur Unterscheidung zu den sachlichen Umfeldfaktoren sage ich immer, das sind die, denen die Projektleitung den Bauch streicheln kann.
    • Sachliche Umfeldfaktoren lassen sich in unterschiedliche Kategorien aufteilen: ökologische, technische, gesetzliche u.a.
  • Interne und externe Umfelder
    • Interne Umfeldfaktoren sind alle die, die zur Organisation des Projektleiters gehören (das eigene Unternehmen). Sie werden gerne, wie bei den Schildbürgern, übersehen.
    • Externe Umfeldfaktoren sind der Rest.

In welcher Verteilung die Umfeldfaktoren vorkommen, hängt völlig vom Projekt ab und ist nicht vorhersehbar. Scheuen Sie sich nicht, viele Umfelder zu finden. Die Umfeldanalyse ist eine Sammlung. Ob Sie später die richtigen Umfelder gefunden haben, wird sich in den folgenden Arbeitsschritten zeigen.

Soziale Umfeldfaktoren werden im Stakeholdermanagement und sachliche Umfeldfaktoren im Risikomanagement bearbeitet.

Stakeholdermanagement

Den Begriff Stakeholder werden Sie bereits gehört haben[4].

Lt. DIN-Norm 69901-1:2009 sind Stakeholder interessierte Parteien, und wie folgt definiert:

Stakeholder sind Personen oder Personengruppen, die

  • am Projekt beteiligt sind,
  • am Projektverlauf interessiert sind oder
  • vom Projektergebnis betroffen sind.


Jedes der größeren Projektmanagementwerkzeuge hat ein eigenes kleines Vorgehensmodell. Das ist beim Stakeholdermanagement auch so. Wir unterscheiden die Arbeitsschritte: Stakeholder ermitteln, Stakeholderinformationen sammeln und analysieren, Maßnahmen entwickeln und Monitoring.

  • Stakeholder ermitteln
    Beim Ermitteln, welche Stakeholder am Projekt beteiligt sind, nehmen wir die Umfeldanalyse in die Hand und gehen ins Detail.


Beispiel Stakeholderermittlung

Beim Bau eines Spielplatzes für eine Kita haben wir festgestellt, dass die Anrainer (die Bewohner rund um den zukünftigen Spielplatz) ein soziales Umfeld sind. Jetzt müssen wir überlegen, ob es ausreicht, die Anrainer als Personengruppe gemeinsam zu sehen oder ob es Einzelpersonen gibt, die anders denken als der Rest.

  • Sammeln Sie so viele Stakeholder wie möglich, nur wenn wir sie erkennen, können wir sie in die spätere Maßnahmenplanung einbeziehen.
  • Stakeholderinformationen sammeln und analysieren


In diesem Teil geht es darum zu bestimmen, welches Interesse die Stakeholder an unserem Projekt haben werden.

Wie bekomme ich die Informationen? Fragen Sie die Stakeholder! Bisher hat noch jeder Stakeholder eine vernünftige Auskunft gegeben, wenn ich vernünftig gefragt habe.

Allerdings benötigen wir viel Zeit (nicht unbedingt viel Arbeit) für diese Stufe des Projektmanagements. Oft müssen wir mit den Menschen persönlich sprechen, was Terminabsprachen und Reiserei bedeutet.

Mittels der Analyse stellen wir fest, wieviel Einfluss (manchmal wird auch „Macht“ gesagt) die Stakeholder auf unser Projekt haben. Einfluss bedeutet, dass der Stakeholder das Projekt stark verzögern oder gar stoppen kann. Allerdings muss nicht jeder auch den Wunsch haben seine Macht auszuüben (Einflusswille). Dafür gibt es Stakeholder, die keinen Einfluss haben, aber einen starken Willen am Projekt beteiligt zu sein. Auch dies müssen wir analysieren.

  • Maßnahmen entwickeln
    Stakeholdermaßnahmen sind teuer. Deshalb ist es sinnvoll, die Stakeholder einzuteilen, um die knappe Ressource Geld sinnvoll einzusetzen. Wir nutzen dazu das Stakeholderportfolio. Das Stakeholderportfolio ist ein 4-Quadranten-Diagramm mit den Achsen Einfluss und Einflusswille.

Durch die Clusterung der Stakeholder ergeben sich unterschiedliche Mengen an Stakeholder in den Quadranten I – IV. Je Quadrant sind unterschiedlich Maßnahmen vorgesehen.

Abbildung 4: Stakeholderportfolio mit Stakeholder (als A – K nummeriert)

  • Quadrant I
    informieren durch moderne Kommunikationsmittel
    Beispiel: Projekt-Website
  • Quadrant II
    persönliche Betreuung, ohne die Stakeholder in Entscheidungsaktivitäten zu involvieren
    Beispiel: Baustellenbesichtigungen
  • Quadrant III
    wir sehen Stakeholder als Partner im Projekt an und involvieren sie in unsere Entscheidungen
    Beispiel: Kaminabende im Adlon Hotel
  • Quadrant IV
    Umgang mit Stakeholdern erfordert Konfliktmanagement
    Beispiel: öffentliche Anhörung
  • Monitoring
    Während der Laufzeit des Projektes muss regelmäßig geprüft werden, ob die Maßnahmen die gewünschten Auswirkungen bei den Stakeholdern haben.


Risikomanagement

Auf Grund der Ableitung der sachlichen Umfelder aus der Umfeldanalyse, können wir mit dem Risikomanagement beginnen.

Viele Projektmanagementsysteme betreiben hier einen erheblichen Aufwand. Wichtig ist vor allem aus meiner Sicht überhaupt Risiken zu finden und ihre Auswirkungen zu akzeptieren. Berufsanfängern fällt dies auffällig oft schwer.

Das Risikomanagement ist eine strukturierte Aufgabe und hat mehrere Stufen:

  • Risiken analysieren
    Zuerst müssen wir die Risiken erkennen und benennen. Die Arbeit wird uns durch eine Einteilung in handhabbare Kategorien wie kaufmännische, technische, terminliche oder Ressourcenrisiken erleichtert.
  • Risikowerte berechnen
    Risiken lassen sich durch die Eintrittswahrscheinlichkeit (in %) und die Tragweite (in €), das ist die monetäre Auswirkung des Schadens, bewerten. Die Multiplikation beider Werte ergibt den Risikowert in Euro. Durch die Höhe jedes Risikowertes erkennen wir die auswirkungsreichsten Risiken des Projektes.


Beispiel Risikoermittlung

Beim Bau des o.g. Spielplatzes ergeben sich folgende Risiken:

Risiko                    

Tragweite in €

Eintrittswahr-scheinlichkeit %

Risikowert in €

Treibsand führt zum kompletten Austausch bis in 2 Meter Tiefe

2 Mio.

1

20.000

Fliegerbombe wird gefunden

50.000

5

2.500

Archäologische Funde behindern Fortgang für 3 Jahre

10.000

30

3.000

  • Maßnahmen planen
    Jedes Risiko hat genau eine Maßnahme, die am sinnvollsten ist. Um die richtige Maßnahme entwickeln zu können, bedienen wir uns des Risikoportfolios, dass genauso aussieht wie das Stakeholderportfolio, aber die Achsenbenennung Eintrittswahrscheinlichkeit und Tragweite hat.
  • Quadrant I
    Risikostrategie akzeptieren: keine Maßnahmen zur Risikoeindämmung
  • Quadrant II
    Risikostrategie übertragen: die hohe Tragweite wird mittels Versicherungen oder Verträge auf Dritte übertragen
  • Quadrant III
    Risikostrategie vermeiden: Eintrittswahrscheinlichkeit und Tragweite sind so hoch, dass wir den Risikoeintritt auf keinen Fall stattfinden lassen dürfen
  • Quadrant IV
    Risikostrategie vermindern: die Tragweite ist gering, aber die Eintrittswahrscheinlichkeit ist zu hoch, wir müssen sie vermindern

 

Abbildung 5: Risikoportfolio mit Beispiel-Risiken

  • Restrisiko bewerten
    Bei den Strategien „akzeptieren“ und „vermindern“ bleibt ein Rest an Risiko übrig. Dieser Rest kann uns Geld kosten. Das Restrisiko kann aber nicht beplant werden, da es ja nicht eintreten muss. Daher eröffnen wir eine Art Schattenkasse, Risikobudget genannt, das allerdings wie das normale Budget vom Projektbeauftrager genehmigt werden muss.

    Das Risikobudget muss immer gesondert ausgewiesen werden und darf nicht im Gesamtbudget abhandenkommen. Dieser Budgettopf kommt nur zur Anwendung, wenn die restlichen Risiken doch eintreten.
    Das Projektbudget sollte nicht mehr als 10% bis 15% des Gesamtbudgets betragen.

  • Maßnahmen einplanen
    Sobald wir die Strategie bestimmt haben und damit auch die passende Maßnahme, muss die Maßnahme geplant, budgetiert und in die Projektmanagementaktivitäten aufgenommen werden.


Zielsystem erstellen

Ein Ziel ist ein in der Zukunft gewünschter Zustand. Dieser Zustand muss erarbeitet werden und kostet damit Ressourcen, Zeit und damit Geld. Je genauer ich weiß, welchen Zustand wir uns erarbeiten müssen, desto besser kann ich meine Aktivitäten darauf abstimmen. Allerdings muss der Einsatz der Ressourcen effizient sein.

Die Ziele eines Projektes lassen sich in vier Kategorien einteilen:

  • die Ecken des magischen Dreiecks (Zeit, Kosten, Leistung) sowie
  • die sozialen Interessen der Stakeholder.


Diese Ziele müssen untersucht und vergleichbar gemacht werden.

Es gibt eine anerkannte Methode zur Beschreibung von Zielen: die SMART-Methode. Die SMART-Methode erfüllt den Anspruch, Ziele operationable zu machen.

SMART ist ein englischsprachiges Akronym:

Abbildung 6: Das Akronym SMART

Es werden häufig auch andere Begriffe verwendet und dann auch noch ins Deutsche übersetzt oder interpretiert[5].

In meiner Praxis hat sich die folgende Interpretation als hilfreich bewiesen:

  • S (engl.: specific): Das Ziel muss eindeutig beschrieben sein. Es dürfen keine Interpretations-spielräume bleiben.
  • M (engl.: measurable): Das Ziel muss gemessen werden können. Am einfachsten wird es, sich eine Gleichung vorzustellen. Links vom Gleichheitszeichen steht das Messkriterium und rechts der Wert, den er annehmen soll (Beispiel: Temperatur = 25°; Luftfeuchtigkeit <= 45%; Fenster > 6).
  • A (engl.: achievable): Das Ziel muss in der Projektlaufzeit erreicht werden. Danach ist der Projektleiter nicht mehr verantwortlich und kann nichts mehr zur Zielerreichung beitragen.
  • R (engl.: relevant): Das Ziel muss von hoher Bedeutung für das Projekt sein. Besonders Stakeholder bringen ihre Interessen am Projekt ein, bewerten diese aber öfters zu hoch. Unsere Aufgabe ist es, diese Interessen für das Gesamtprojekt zu bewerten.
  • T (engl.: timely): Der Zeitpunkt, an dem die Zielerreichung erstmals überprüft werden kann.


Ein Beispiel für ein „SMART“es Ziel finden Sie im Kapitel 10.4.

Die Interessen, welche die Überprüfung mit SMART bestehen (sie sind messbar, in der Projektlaufzeit erreichbar und von hoher Bedeutung) werden als Projektziele bezeichnet.

Projektziele sind die nach außen darstellbare Ziele, nach denen unser Projekterfolg am Ende bewertet werden wird. Damit alle Stakeholder ein gleiches Verständnis zu diesen Zielen haben, ist der Prozess inkl. der Veröffentlichung notwendig.

Phasenplan erstellen

Nachdem wir bereits viele Dinge erarbeitet haben, benötigen wir jetzt eine zeitliche Einteilung unseres Projektes. Der Phasenplan ist die grafische Darstellung einer sehr groben Abfolge von Aufgabenblöcken in Kombination mit Meilensteinen.

Eine Projektphase ist ein grober Abschnitt des Projektes, der sowohl inhaltlich wie zeitlich von anderen Abschnitten unterschieden werden kann[6]. Als erste Phase sollte immer mind. eine Projektmanagementphase vorhanden sein (Definitions- und Planungsphase oder eine zusammengefügte Phase). Das Projekt wird durch die Projektmanagementphase Abschlussphase beendet. Dazwischen liegen die fachorientierten Phasen des Projektes (Beispiele: Bauausführung, Herstellung, Einführung, Roll-out, Installation oder Service und Betreuung).

Fünf bis acht Phasen haben sich in der Praxis bewährt.

Ein Meilenstein ist ein Ereignis von besonderer Bedeutung[7]. Es gibt zwei Meilensteine, die immer benannt werden: der Projektstarttermin und der Projektendetermin. Meilensteine haben ein Datum (im Phasenplan sehr grob) und sind in Zielsprache formuliert. Zielsprache bedeutet, dass wir den Abschluss eines Ereignisses / Vorgangs heraushören können.

Nachdem wir Phasen und Meilensteine benannt haben, erstellen diese Graphik:

Abbildung 7: Phasenplan mit Phasen und Meilensteinen

Zum aktuellen Zeitpunkt sind seit Projektbeginn bestimmt einige Tage, manchmal auch Wochen vergangen. Trotzdem haben die Kernteammitglieder unterschiedliche Vorstellungen, wie das Projekt abgearbeitet wird. Mit der Erstellung des Phasenplans werden diese Vorstellungen vereinheitlicht.

Woher kommen die Unterschiede in der Vorstellung?

Die Menschen sind unterschiedlich ausgebildet / geschult und haben unterschiedlich viel Berufs-erfahrungen gesammelt – damit denken sie auch unterschiedlich. Manche können in rein sequenzieller Art Abläufe betrachten, andere denken (und tun) alles auf einmal. Genau die richtige Mischung macht es!

Beispiel Entwicklung eines Handys

Muss ich in meinem Projekt ein Handy entwickeln, kann ich mit dem Marketing beginnen, wenn ich die ersten Informationen dazu habe (einige technische Features + ein Bild vom Gehäuse), aber nicht sofort mit dem Entwicklungsstart.

Die Zusammenhänge werden im Phasenplan das erste Mal besprochen und geklärt und sind Grundlage für die Detaillierung während des 2. Teils – der Projektplanung.

In der nächsten Phase erkläre ich Ihnen die Werkzeuge, von denen Sie bisher vermutet haben, das sei Projektmanagement. Nehmen Sie sich aber in Ihren Planungen ausgiebig Zeit die vorgenannten Projektmanagementmaßnahmen durchzuarbeiten. Alles Folgende basiert auf dem aktuellen Wissensstand!

[1] [WIKIPEDIA], Belbin

[2] [QUINN], Quinn

[3] [PERSOLOG]

[4] Bitte verwechseln Sie Stakeholder nicht mit Shareholder; das sind Anteilseigentümer einer Aktiengesellschaft.

[5] [WIKIPEDIA], SMART

[6] [WIKIPEDIA], Projektphase

[7] [WIKIPEDIA], Meilenstein

In der Planungsphase setzen wir unser Wissen über das Projekt in Zeiten und Kosten um. Dabei fügen wir auch Informationen über die Facharbeit hinzu.

Haben Sie gemerkt? Wir haben uns zuerst nicht um Facharbeit, sondern um viele andere Aspekte des Projektes gekümmert. Und das ist auch gut so! In den meisten Fällen werden die Aspekte der Definitionsphase übersehen und am Ende wundern wir uns, warum keiner das Projekt als erfolgreich ansieht, obwohl wir doch so einen „schönen“ Projektgegenstand gebaut haben.

Projektstrukturplan erstellen

Der Projektstrukturplan (PSP) ist die grafische Darstellung aller Tätigkeiten im Projekt. Er wird als Baumstruktur dargestellt und ist häufig codiert.

Die hierarchischen Elemente eines PSP sind das Wurzelelement, die Teilaufgabe und das Arbeitspaket. Manchmal finden Sie auch die Bezeichnung „Teilprojekt“. Dieses Element kann man bei sehr großen Projekten einbinden, z. B. bei der Besiedlung des Mars (aber wer hat schon solche Projekte vor der Nase).

Die vorgenannten drei Elemente sind folgendermaßen definiert:

  • 1. Ebene des PSP: Wurzelelement
    Im Wurzelelement steht der Kurzname des Projektes und die Projektnummer
  • 2. Ebene des PSP: Teilaufgabe
    Die Teilaufgabe (TA) teilt Arbeitspakete (und andere Teilaufgaben) und hat selbst keine Tätigkeiten in sich Arbeitspaket
  • 2. Ebene des PSP: Arbeitspaket
    Ein Arbeitspaket (AP) ist ein Bündel guthandhabbarer Tätigkeiten, das leicht zu planen und zu steuern ist.
    Jedes Arbeitspaket wird durch einen Arbeitspaketverantwortlichen (APV) verantwortet. Dieser ist für die Planung und die spätere Umsetzung zuständig.
  • N. Ebene
    Am Ende jedes PSP Astes dürfen nur noch Arbeitspakete stehen.


Der PSP umfasst in der Regel 20 – 100 Arbeitspakete. Bei größeren Projekten ist es sinnvoll auch mehr Arbeitspakete zu benutzen. Wie viele Ebenen dabei benötigt werden, ist nicht vorherzusagen.

Abbildung 8: Projektstrukturplan mit alpha-numerischer Kodierung

 

 

Wurzelelement

 

 

 1. Ebene

 

 

 

 

2. Ebene

 

 

 

3.Ebene

Es gibt unterschiedliche Hilfestellungen, um einen PSP zu erstellen. Der PSP kann

  • nach den Teilen des Projektgegenstandes strukturiert werden,
  • nach den Funktionen oder
  • nach eigenen Kriterien.


Die einfachste und effizienteste Art ist die Phasenorientierung. Alle Phasen im Phasenplan werden weiter benutzt und in Teilaufgaben umbenannt.

Häufig werden Arbeitspakete sehr ähnliche Namen tragen. Um die Identifizierung der APs in einer Multi-Projekt-Umgebung zu erleichtern, sollten Projektstrukturpläne codiert werden. Die an den häufigsten verwendeten Codierungen sind die numerische und die alpha-numerische. Darüber hinaus gibt es noch die alphabetische, die dekadische und Mischformen von Codierungen.

Ab der Ebene 2 des PSP beginnt die Codierung.

  • Numerische Codierung
    Bei der rein numerischen Codierung werden die Elemente nur mit Ziffern versehen.

  • Alpha-numerische Codierung
    Es gibt unterschiedliche Arten der Umsetzung. Die einfachste und von mir verwendete, ist die Codierung mit Buchstaben auf der 2. Ebene. Danach wird weiter numerisch codiert.


Ablaufplanung mit Netzplan

Die Netzplantechnik ist eine recht alte Art, einen Projektablauf visuell darzustellen. Mit der DIN-Norm 69900 wurde auch die Netzplantechnik standardisiert.

Nach dieser Norm ist der Netzplan die graphische oder tabellarische Darstellung von Abläufen und deren Abhängigkeiten. Die Netzplantechnik fasst alle Verfahren zur Analyse, Planung, Steuerung und Überwachung von Abläufen zusammen, wobei Zeit, Kosten, etc. berücksichtigt werden können.

Heute wird die Netzplantechnik mittels Software abgebildet, daher werde ich in diesem Buch nicht zu intensiv auf die Möglichkeiten eingehen, die die Netzplantechnik bietet.

Abbildung 9:  Beispiel eines Netzplans

Ich möchte aber die beiden wichtigsten Aspekte darstellen.

  • Durchdenken des Projektes
    An manchen Stellen eins Projekts stehen wir da und wissen nicht, was als nächstes zu tun ist. Das gilt sowohl für den Teil des Projektmanagements wie für die Facharbeit.

    Den ersten Teil können wir getrost ausblenden, weil wir dafür jetzt eine Methode haben. Für die Facharbeit fehlt uns aber die genaue Kenntnis über die Zusammenhänge.

    Wenn wir uns aber die Mühe machen, vor dem Bau des Projektgegenstandes zu überlegen, in welcher Reihenfolge und mit welchen Abhängigkeiten einzelne Aufgaben zu erledigen sind, wird unser Projekt leichter durchschaubar und später leichter steuerbar.

  • Länge des Projektes
    Es ist sehr einfach, im Netzplan die Länge eines Projektes in Projekttage – das sind die Tage an denen gearbeitet wird – zu errechnen.

    Das erste Arbeitspaket ist nach seiner Dauer an einem bestimmten Projekttag fertig. Ein fünf Tage dauerndes Arbeitspaket ist auch am 5. Tag fertig. Da die Netzplantechnik auf volle Tage rechnet, kann diese Paket auch am Vormittag fertig sein, somit kann das folgende Arbeitspaket am gleichen Tag beginnen. Addieren Sie nun die Dauer, z. B. drei Tage, dann ergibt sich der Fertigstellungstag für dieses Arbeitspaket von acht.


Selbstverständlich berücksichtigt damit die Netzplantechnik nicht Wochenende, Feiertage oder technische Stillstandstage. Aber sie lässt eine realistische Prognose über die Gesamtlänge zu.

Einsatzmittelplanung

Sie wissen jetzt an welchem Projekttag, welche Arbeitspakete bearbeitet werden. Damit ist es an der Zeit, den Arbeitspaketen Ressourcen zu zuweisen. Wir kennen Personal- und Sachressourcen[1].

  • Personalressourcen
    Bei Personalressourcen handelt es sich um die Menschen, die in ihrem Projekt arbeiten – sowohl die Projektmanagementmitarbeiter als auch das Fachpersonal.

    Es ist hier insb. zu beachten, dass Sie zwar als Projektmanager diese Ressourcen einplanen können, aber nur die Linienverantwortlichen können die Ressourcen freigeben. Das gleiche gilt auch für Sachressourcen.

    Weiterhin geht es zu beachten, dass die Personalressourcen zu ihren tatsächlichen Kosten in das Projekt eingearbeitet werden. Bei internen Mitarbeitern bedeutet dies, dass wir rund 20% auf den Bruttolohn aufschlagen müssen.
  • Sachressourcen
    Bei Sachressourcen ist zu beachten, dass es nicht ausreicht, nur den Listenpreis als Kosten in das Projekt mit einzuplanen, sondern auch die damit verbundenen Bestell-, Liefer-, Lager- und Abrechnungskosten.


Es ist ebenfalls notwendig, dafür zu sorgen, dass die Sachmittel auch an der richtigen Stelle sind, wenn wir sie benötigen. Wenn Sie einen Kran benötigen, reicht es nicht aus, dass der Kran in 50 Meter Sichtweite steht, sondern er muss genau an der Stelle zur Verfügung sein, an der die Sachressource auch arbeiten soll.

Die Planung der Ressourcen ist meistens ein längeres Werk. Denn es kann ständig vorkommen, dass Arbeitspakete, die relativ spät im Projekt stattfinden sollen, bereits geplant sind, aber durch das Fehlen von Ressourcen in den vorgelagerten Arbeitstakten neu geplant werden müssen.

Zur Unterstützung insbesondere der Personalressourcen ist es sinnvoll die Personalabteilung mit einzuschalten.

Terminplanung mit GANTT

Die Terminplanung von Projekten wird zumeist mit dem sogenannten GANTT-Diagramm durchgeführt. „Thomas Gantt“[2] war ein US-amerikanischer Ingenieur, der diese Art der Visualisierung von Abläufen erfunden hat.

Ein GANTT-Diagramm ist ein Balkendiagramm, das die Arbeitspakete auf einen Kalender darstellt. Wir erhalten damit eine Visualisierung der Länge des Projektes. Dabei dürfen Sie nicht übersehen, dass die Balkenlänge sich durch Wochenende oder Feiertage verlängert. Es ist damit etwas Vorsicht geboten in der Betrachtung des GANTT-Diagramms.

Durch aktuelle Software lassen sich im Diagramm neben der reinen Terminplanung auch noch weitere Informationen zur Verfügung stellen. Wir erhalten Informationen,

  • welche Ressourcen, in welchen Arbeitspakten vertreten sind,
  • zu welchem Prozentzahlen sie arbeiten,
  • welche Kosten – aufgeteilt in Sach- und Personalkosten – zum Arbeitspaket gehören.


Sie können Arbeitspakete zu Teilaufgaben zusammenfassen und mittels sogenannter RollUps die Kosten berechnet lassen.

Aber Vorsicht: Überladen Sie die Graphik nicht, es ist weiterhin nur eine Terminplanung.

Abbildung 10: GANTT-Diagramm mit Beispiel-Arbeitspaketen

Kostenplanung

Die Kostenplanung ist im Projektmanagement im Grunde ein einfaches Geschäft. Aufgrund der Tatsache, dass wir in der Ressourcenplanung bereits alle Arbeitspakete mit den Ressourcen gefüllt haben und wir damit auch alle Kosten haben, müssen wir diese nur noch in unsere Software eintragen.

Exkurs Softwareeinsatz

Ein Wort zum Thema Software:

Auch wenn das Thema Softwareentwicklung in diesem Buch einen großen Anteil am Umfang einnimmt, bin ich eher kein Freund von Softwareeinsatz.

Ich habe beobachtet, dass in Unternehmen der Glaube herrscht, dass, eine Software zu haben und diese zu benutzen, auch bedeutet Projektmanagement installiert zu haben. Aus meiner eigenen schmerzlichen Erfahrung in meiner Anfängerzeit, darf ich Ihnen versichern, dem ist nicht so.

Software ist dumm und erspart uns nicht das eigene Denken!

Bitte benutzen Sie keine Software bis Sie den Netzplan erstellt haben.

Wenn wir aber in diesem Stadion unserer Planung Software benutzen, dann wird uns die Software automatisch eine Kostenplanung erstellen. Denn die Software ist mittlerweile so ausgereift, dass die einzelnen Kosten der Arbeitspakete summiert werden können und als Gesamtkosten, auch aufgeteilt in Sach- und Personalkosten, dargestellt werden kann.

Bei den Kosten ist zu beachten, dass wir selbstverständlich nicht selbst Rechnungen bezahlen und Löhne überweisen. Diese unterstützenden Prozesse werden weiterhin von der dafür verantwortlichen Abteilung durchgeführt. Was wir im Projektmanagement machen, ist eine Schattenbuchhaltung zu führen. Wir rechnen und kalkulieren genau die Kosten, die wir im Projekt verbrauchen.

Warum ist es so wichtig, dass wir die Kosten – und zwar sämtliche Kosten – auch die sogenannten EhDa-Kosten[3] berechnen?

Am Ende des Planungszeitraums – genauer gesagt der Planungsphase – haben wir Kosten und Zeit des Projektes kalkuliert. Es kommt häufig vor, dass diese beiden Werte sehr wenig mit den Werten der Projektbeauftragung zu tun haben. Ich denke, dies ist auch nachvollziehbar, da wir am Anfang eines Projektes lediglich grobe, geschätzte Werte in Ansatz bringen. Zum aktuellen Zeitpunkt haben wir aber eine viel bessere, weil genauere und kalkulierte Datenbasis.

Was mache ich nun damit?

Ich muss zum Projektbeauftrager gehen und für das Delta zu den Daten beim Projektstart einen Nachtrag stellen.

Jetzt kann ich auch die Frage beantworten, warum es so wichtig ist, kalkulierte Daten zu haben. Der Projektbeauftrager hat jetzt – erstmalig – folgende Möglichkeiten zu reagieren:

  • Der Projektbeauftrager genehmigt den Nachtrag und das Projekt wechselt in die Steuerungsphase.
  • Der Projektbeauftrager gibt das „HB Männchen“[4]. In diesem Fall können Sie mit ihren Kalkulationen dem Projektbeauftrager zeigen, dass Sie genau diesen Betrag / diese Zeit benötigen. Auch hier wird der Projektbeauftragter den Nachtrag genehmigen.
  • Der Projektbeauftrager lehnt den Nachtrag ab. Damit endet das Projekt oder es müssen sich neue Gedanken darüber gemacht werden, welchen Umfang das Projekt haben soll.


Was nicht geht, aber sehr häufig im Management von uns verlangt wird, ist mit der gleichen Menge Geld oder Zeit entweder eine höhere Qualität oder höhere Leistung zu erbringen oder eine Leistung zu erbringen, aber mit weniger Kosten oder in einer kürzeren Zeit[5].

Wenn der (optionale) Nachtrag genehmigt wurde, kann mit der Facharbeit begonnen werden. Dafür wechseln wir in die Steuerungsphase.

[1] Einsatzmittel und Ressourcen werden synonym genutzt.

[2] [GANTT]

[3] EhDa-Kosten sind Kosten die „eh“ „da“ sind, wie z. B. Kosten für Angestellte oder Räume.

[4] In den 60er und 70er Jahren des letzten Jahrhundert war das HB-Männchen eine Werbeikone für eine Zigarettenmarke, die gerne mal in die Luft gegangen ist.

[5] [ANGERMEIER]

Die Steuerungsphase ist für uns Projektmitarbeiter eine einfache Phase, denn unsere Aufgabe besteht „lediglich“ darin, den Plan zu überwachen. Denn wir können sicher sein, wenn es Abweichungen vom Plan gibt, gibt es sie nur an dieser Stelle, alles andere läuft wie geplant weiter.

Selbstverständlich ist diese Darstellung sehr vereinfacht, aber sie trifft den Kern.

Beispiel Segelturn nach New York

Wenn ein Segler von Berlin nach New York segeln möchte, würde er nicht die Segel hissen und loslegen, sondern er wird sich einen genauen Plan machen.

Der Plan berücksichtigt Winde, Strudel und das Bermuda-Dreieck. Aber in diesem Plan gehören auch Informationen über mitzunehmendes Wasser, Getränke, Essen und Kleidung. All das mit den richtigen Mengen an der richtigen Stelle deponiert, legt der Segler ab.

Nehmen wir an, er ist mitten auf dem Atlantik. Der Wind sollte heute von links kommen, aber er kommt von rechts. Wir haben eine Abweichung vom Plan.

Der Segler wird jetzt nicht sofort versuchen auf seinen geplanten Weg zurückzufinden, indem er z. B. den „Wasser-ADAC“ anruft und sich abschleppen lässt, sondern er wird sich überlegen, wie er trotz dieser Abweichung, das Ziel erreichen wird.

Dabei wird ihm egal sein, ob er auf seinen Weg Heute, Morgen oder erst in 10 Tagen zurückkommt. Wichtig ist ihm nur, dass er es mit geringen Aufwand schafft.

Wir haben im Projekt dieselbe Situation. Ich beobachte, dass in der Praxis, ein „Feuerwehr-Controlling“ betrieben wird. Wir rennen dorthin, wo es brennt oder wo zumindest der größte Rauch ist und machen irgendetwas, ohne über die Folgen nachzudenken. Das liegt daran, weil wir schon wieder auf dem Weg zur nächsten Brandstelle sind.

Warum handeln wir so?

Weil wir keinen Plan haben. Ab sofort haben wir einen Plan und wir gehen davon aus, dass dieser Plan funktioniert. Wenn jetzt eine Abweichung erfolgt, können wir sicher sein, dass der Rest des Projektes weiterläuft. Damit bekommen wir eine neue Ruhe, mit der wir überlegen können,

  • was läuft da schief,
  • warum läuft es schief und
  • wie können wir, ohne den Projekterfolg zu gefährden, agieren?


Projektcontrolling

Die vorgenannten Überlegungen machen das Projektcontrolling für uns zu einer einfachen Aufgabe.

Projektcontrolling teilt sich in zwei Hauptarbeitspunkte auf,

  • wir müssen regelmäßig den Zustand unseres Projektes überprüfen, um daraus z. B. Berichte erstellen zu können, und
  • wir müssen ständig die Abarbeitung des Planes steuern.


Die kontinuierliche Steuerung erfolgt über Meetings bzw. über die Begehung des Erstellungsortes. Dies meint: Wir besuchen z. B. die Baustelle oder die Dienstleister, die für uns arbeiten.

Stichtagsorientiert erstellen wir einen besonderen Bericht über den Zustand unseres Projektes.

Wir nutzen dazu die Idee des Controlling-Kreises[1], um regelmäßig valide Kennzahlen aus unserem Projekt zu bekommen. In der Graphik sehen Sie, dass zuerst bestimmte Kennzahlen des Projektes erhoben werden müssen. Die wichtigsten Kennzahlen sind

  • der Grad der Leistungserstellung in Prozent beziehungsweise Euro und
  • die verbrauchten Geldmittel.

 

Abbildung 11: Controlling-Kreis

Beides gegenübergestellt, lässt uns interpretieren, ob Einsatzmittelverbrauch und der Geldmittel-einsatz übereinstimmen.

Beispiel Ressourcenverbrauch

Wir sind ein Solo-Selbständiger Fliesenlegermeister und haben einen Auftrag innerhalb von 5 Tagen einen Fliesenboden zu legen.

Wir planen jeden Tag einen gleichen Anteil von 20% der Leistung zu erbringen. Damit haben wir am Montag 20%, am Dienstag 40%, am Mittwoch 60% usw. erbracht. Da unsere liquiden Mittel nicht so hoch sind, wollen wir jeden Tag im Baumarkt die entsprechende Tagesmenge an Fliesen und Kleber einkaufen. Somit haben wir hier auch kostenseitig am ersten Tag 20% der Kosten ausgegeben, am zweiten 40% und so weiter. Der Plan sieht gut aus!

Am ersten Tag lesen wir im Baumarkt, dass es ein Sonderangebot gibt: beim Kauf von drei Säcken Kleber und drei Einheiten Fliesen wird jeweils eine Einheit geschenkt. Selbstverständlich lassen wir uns dieses Angebot nicht entgehen.

Sehen wir uns jetzt den Verlauf von Kosten und Leistung an. Am Montag haben wir durch den Einkauf 40% der Kosten erbracht, aber nur 20% der Leistung. Wenn Sie sich vorstellen, dass Sie das Ihrem Projektbeauftrager berichten, können wir uns alle den Aufschrei vorstellen.

Am Dienstag haben Sie dann allerdings bei 40% der Leistung auch 40% der Kosten erbracht und sind somit wieder auf dem geplanten Pfad. Wenn Sie dies berichten, dann sind Ihre Stakeholder sehr zufrieden mit Ihnen.

Am Mittwoch sind wir bereits bei 60% der Leistung, haben aber durch den guten Einkauf weiterhin 40% der Kosten. Jetzt trägt man Sie auf Händen!

Am Donnerstag und am Freitag wird sich allerdings alles wieder relativieren, weil wir durch eine Preiserhöhung im Baumarkt am Freitag sowohl 100% der Leistung als auch 100% der Kosten haben.

An diesem Beispiel können Sie sehen, das nackte Zahlen einen falschen Eindruck Ihres Projekts machen können.

Wir müssen einen Statusbericht erstellen und dieser sollten immer – gerade bei Abweichungen – erklärt werden. Aber vor allem müssen die Abweichungen auch erklärbar sein!

Änderungsmanagement

Veränderungen gehören zum Standardgeschäft eines Projektes, und wir werden viele Veränderungen in unseren Projekten haben. Im klassischen Projektmanagement hat sich diese Disziplin sehr verbreitet, weil wir aufgrund von festgeschriebenen und damit unveränderlichen Dokumenten unsere Planung durchgeführt haben.

Methodisch ist es im Grunde nicht vorgesehen, dass Änderungen am Projektgegenstand erfolgen, leider schert sich die Praxis nicht um Methoden.

Es können unterschiedliche Änderung vorkommen:

  • im Vertragsrecht sowie
  • in den organisatorischen Gegebenheiten Ihres Projektes und
  • in der Konfiguration des Projektgegenstandes.


Wenn es zu Änderungen kommt, ist es notwendig, dass Sie diese Änderung nicht nur technisch bearbeiten und dokumentieren, sondern sich die Auswirkung auf das Projekt ansehen. Zum Teil ist es notwendig, dass wir die gesamte Projektplanung noch einmal neu aufziehen. Die damit verbundenen Änderungen können zu Nachträgen führen.

Diese Komplexität ist meines Erachtens der größte Schwachpunkt des klassischen, sequenziellen Projektmanagements.

[1] [DPA]

Nachdem der Projektgegenstand komplett erstellt ist, das bedeutet auch, die Dokumentation zum Projektgegenstand ist erstellt, können wir in die letzte Phase des Vorgehensmodells nach DIN eintreten.

Die Abschlussphase beginnt mit der Übergabe des Projektgegenstandes an den Projektbeauftrager.

Beachten Sie dabei, dass nicht Sie als Projektmanager den Projektgegenstand an den Kunden übergeben, denn Sie sind möglicherweise nicht für Ihr Unternehmen vertretungsberechtigt. Dieser Akt erfolgt durch den Geschäftsführer, Prokuristen oder eine andere benannte Person.

Da Übergabe in manchen Projekten mehrere Tage dauern kann (z. B. die Übergabe von großen industriellen Maschinen), werden beide Akte zeitgleich erfolgen. Kunde, Projektbeauftrager und der Projektmanager gehen zusammen um die Maschine herum.

Für unser Projekt ist die Abnahme des Projektgegenstandes deshalb wichtig, weil wir erst dann das Projekt abschließen können.

Sachlicher Projektabschluss

Im sachlichen Projektabschluss führen wir eine Nachkalkulation des Projektes durch.

Es wird geprüft, ob

  • alle Kosten den Arbeitspaketen zugeordnet sind, sowie
  • keine doppelte Buchung erfolgt sind.


Mit einer sauberen Aufarbeitung dieser betriebswirtschaftlichen Daten können wir Schlüsse ziehen, die uns helfen werden, im nächsten Projekt besser zu arbeiten.

Sozialer Projektabschluss

Im Teil des sozialen Projektabschlusses, kümmern wir uns um die Menschen des Projektes. Wir führen eine „lessons learned“-Sitzung durch – in diesem Meeting wollen wir unsere Erfahrungen aus dem Projekt aufarbeiten und für weitere Projekte lernen.

Dann sollte es ein Projektfest geben, als Dank und Abschluss des Projektes für das Kernteam, aber auch mit weiteren Stakeholdern zusammen. Da der Mensch Rituale braucht[1], ist es zudem notwendig, dass wir ritualisiert das Kernteam auflösen.

Über diese Vorgänge muss selbstverständlich eine Dokumentation erstellt und veröffentlicht werden. Wir geben damit anderen die Möglichkeit, aus unseren Erfahrungen zu lernen.

Das Ende des Projektes markiert die sogenannte Projektauflösung. Die Projektauflösung umfasst drei Arbeitsschritte:

  • Der Projektmanager wird von der Verantwortung des Projektes entlastet.
  • Die projektbezogenen Vereinbarungen im Kernteam werden aufgehoben.
  • Die Mitarbeiter werden in ihre alten Positionen zurückgeführt.


Damit ist Ihr Projekt beendet.

Im Kapitel über das klassische Projektmanagement habe ich Ihnen erläutert, mit welchem Vorgehensmodell Sie arbeiten sollten.

Der Rote Faden des DIN ist ein eingängiges, bewährtes System, dass Ihnen helfen wird, in Ihrem mittelständischen Unternehmen, effizient Projekte zu bearbeiten.

Die Dokumentation der Projektmanagementergebnisse können sehr einfach mit einer Textver-arbeitung erstellt werden. Selbst Grafiken lassen sich durch Templates gestalten und leicht einbinden.

Trotzdem finden Sie auf dem Markt diverse Projektmanagement-Software. Es stellt sich damit die Frage: ist es sinnvoll ein Projektmanagementtool zu benutzen und wenn ja welches?

Dieser Frage stellen wir uns im nächsten Kapitel.

[1] vgl. Tuckmann, Kapitel 5.6

Kapitel 4: Projektmanagementtools

In Kapitel 3 habe ich Ihnen meine Meinung zum Thema Softwareeinsatz in Projekten schon mitgeteilt. Ich halte den Einsatz von Software für gefährlich, aber natürlich auch für sinnvoll, wenn wir es richtig gestalten.

Seien Sie bitte immer bewusst, dass Software nicht für Sie denkt! Es kann aber die Arbeit Ihres Teams und Ihre Arbeit erleichtern.

Es gibt eine Vielzahl von Projektmanagement-Software auf dem Markt, aber die Auswahl der richtigen für Sie und Ihr Team ist entscheidend.

Bei der Bewertung der Optionen der Projektmanagement-Software, sollten Sie sich folgende Fragen stellen:

  • Wird mein Team die Software tatsächlich nutzen?
  • Können mehrere Abteilungen die Software verwenden?
  • Unterstützt die Software Transparenz und klare Kommunikation?
  • Ist das Programm flexibel?
  • Können Sie benutzerdefinierte Berichte erstellen?
  • Ermöglicht die Software einfach und sicher externe Kommunikation?
  • Integriert sich das Programm in andere Tools, die wir verwenden[1]?


Eines der wichtigsten Dinge, über die Sie nachdenken sollten, ist die langfristige Strategie bei der Auswahl Ihrer Software. Es erfordert Zeit und Ressourcen, Ihr Team mit einer Projektmanagement-Software vertraut zu machen. Sie möchten sicherstellen, dass Sie eine Software auswählen, die mit Ihrem Team wachsen und sich anpassen kann, ohne sie einzuschränken.

Am Ende geht es immer darum, durch Softwareeinsatz die Arbeit zu erleichtern, aber bitte beachten Sie: es arbeiten immer noch Menschen miteinander und der persönliche Kontakt ist auch im Projektmanagement einer der wichtigsten Aspekte.

Ich werde Ihnen keine bestimmten Softwareprodukte empfehlen, dafür ist der Markt zu groß und unübersichtlich. Ich habe Erfahrungen mit „MS-Project“[2], „pm-smart“ von Evoloso[3] und „Blue Ant“ von Proventis[4] gemacht. Aktuell benutze ich „Teams“ von Microsoft, die Videoplattform „Zoom“ und „Trello“. Am liebsten nehme ich aber mein Task-Board und hänge es an die Wand.

 

Abbildung 12: Task Board

[1] Diese Frage stellt sich häufig im agilen Umfeld. Dort gibt es mehr Solo-Tools und weniger Komplettsysteme.

[2] [MS PROJECT]

[3] [EVOLOSO]

[4] [PROVENTIS]

Kapitel 5: Zusammenarbeit in Teams

Die Zusammenarbeit zwischen dem Projektleiter und seinem Kernteam bzw. die Zusammenarbeit mit Stakeholdern, ist im klassischen Umfeld vom Ansatz her anders gelagert als im agilen. Daher habe ich mich entschlossen, beide Bereiche einzeln zu besprechen. Ein Kombination beider Ansätze ist möglich.

Ein wichtiges und häufig besprochenes Thema im Bereich der Soft Skills ist Führung. Was bedeutet Führung? Darüber können Sie sicher Tausende von Büchern lesen, darum werde ich es mir sehr einfach machen und sagen: Führung ist die Entscheidung, wer die Entscheidung hat.

Die Entscheidung kann entweder bei der Führungskraft – also in unserem Fall dem Projektleiter – oder beim Team liegen oder es gibt irgendetwas dazwischen.

Egal welche Führungsmethode Sie anwenden, sie muss immer vor allem als erstes zur Führungskraft passen. Sind Sie jemand, der sämtliche Entscheidung allein fällt, dann mag das vielleicht nicht unbedingt in unsere Zeit passen, aber es würde auch kaum sinnvoll sein, die Entscheidungen dann dem Team zu überlassen. Können Sie selbst nicht entscheiden, dann überlassen Sie auch die Entscheidungen dem Team.

Wie bekomme ich heraus, wie ich gerne führen würde und wer die Entscheidung haben sollte?

Rekapitulieren Sie Ihre eigene Führungserfahrung als Mitarbeiter. Wann haben Sie sich wohl gefühlt? Von wem wurden Sie gut geführt? Ist es Ihnen bereits damals wichtig gewesen, Entscheidungen selbst zu treffen? Aus diesem Fragen ergibt sich vermutlich ein bestimmtes Bild von Führung, dass Sie jetzt getrost auch als Führungskraft anwenden können.

Für mich ist es der richtige Weg, die (fast) alle Entscheidungen dem Team zu überlassen, wobei ich wie alle anderen Teammitglieder eine Stimme habe. In wenigen Fällen ist erlaubt, dass ich als Führungskraft Entscheidungen alleine treffe, die ich aber im Nachhinein vom Team „genehmigen“ lassen muss.

Egal für welche Art der Führung Sie sich entscheiden werden, seien Sie konsequent! Nur so können Ihre Mitarbeiter im Kernteam sinnvoll mit ihnen zusammenarbeiten.

Motivation ist vermutlich das am meisten missverstanden Thema im Bereich der Teamarbeit. Es wird häufig von der Motivation von Mitarbeitern gesprochen. Wir können schon per Definition nicht motivieren. Motivation ist der innere Antrieb etwas zu tun[1].

Das bedeutet: Wir können niemanden von außen motivieren, aber wir können ein Arbeitsumfeld schaffen, das Motivation bei den Mitarbeitern erzeugt. Einige Beispiele:

  • Wir können unseren Mitarbeitern vertrauen.
    Wir benutzen keine Kontrollmaßnahmen bei der Überprüfung oder Überwachung von Arbeitsaufträgen, sondern beschließen gemeinschaftlich Regelungen.


Beispiel Vertrauen in die Mitarbeiter
Das Team beschließt, dass jede Aufgabe mit einem Verantwortlichen und einer Frist versehen wird. Sollte der Termin nicht zur Erledigung der Aufgabe ausreichen, wird der Verantwortliche drei Tage vorher dem Projektleiter automatisch Bescheid geben.

Damit gewinnt das Team die Freiheit, regulierende Maßnahmen frühzeitig zu planen und umzusetzen

  • Wir können unsere Mitarbeiter fordern und fördern.
    Wir interessieren uns für die Ziele, aber auch für die Bedürfnisse und Probleme unserer Mitarbeiter. Wir unterstützen sie, indem wir ihre Fähigkeiten und Fertigkeiten fördern; wir setzen allerdings auch Maßstäbe für Arbeitsqualität.
  • Wir können eine tolerante Fehlerkultur schaffen.
    Wir akzeptieren, dass Menschen Fehler machen, und wir unsere Mitarbeiter nicht für Fehler bestrafen. Wir sollen unseren Mitarbeitern klarmachen, dass Fehler zum Geschäft gehören und wir an den Fehlern arbeiten werden, aber es zu keinen Sanktionen kommen wird.

[1] [WPGS]

Kommunikation geht immer schief. Wenn Sie mit diesem Grundansatz in die Welt gehen, können Sie an Ihrer eigenen Kommunikation arbeiten.

Natürlich ist der Satz sehr provokativ, daher möchte ich Ihnen erklären, was dahintersteckt. Das Problem an der Kommunikation ist, dass sie mindestens zwischen zwei Personen geschieht. Diese beiden Personen haben unterschiedliche Wertewelten. Das, was die eine im Gespräch sagt – und ich nehme jetzt sämtliche anderen Aspekte der Kommunikation ausdrücklich heraus – kommt bei der anderen häufig nicht so an, wie es gemeint ist.

Beispiel Kommunikation im Auto

Sicher kennen Sie das Beispiel mit der Ehefrau auf dem Beifahrersitz.

Die Ehefrau sagt: „Es ist grün“.

Die Aussage steht für eine völlig emotionslosfreie Information. Sie möchte nur ihrem Fahrer / Ehemann mitteilen, dass die Ampel gerade auf Grün gesprungen ist. Doch beim Ehemann und Fahrer wird dieser einfache Hinweis nicht mit dieser Aussage ankommen.

Vermutlich wird sie durch die Wertewelt des Ehemanns interpretiert und erhält folgende Interpretation: „Sie weiß alles besser“, „Sie nervt wieder“ oder „Sie macht immer diese Vorwürfe“.

Das gleiche passiert selbstverständlich in der Businesswelt und auch in Projekten. Dazu kommen noch andere Aspekte wie sie durch das Eisbergmodell[1] beschrieben wurden.

Für uns ist es notwendig zu erlernen, unsere eigenen Botschaften mit verbalen und nonverbalen Mittel zu unterstützen, damit sie bei unseren Gesprächspartner oder Zuhörern auch ankommt.

[1] Das Eisbergmodell beschreibt generell, dass immer nur ein kleiner Teil von „Etwas“ zu sehen ist und sich ein großer Teil versteckt unter der Oberfläche befindet. [WIKIPEDIA], Eisbergmodell

Das grundlegende Kommunikationsmodell stammt von Shannon und Weaver[1]. Es stellt klar, dass Kommunikation auf mehreren Ebenen stattfindet und immer aus Aktion und Reaktion besteht.

Es gibt selbstverständlich noch weitere kompliziertere Modelle, aber uns soll dieses für das Grundverständnis reichen.

Seien Sie sich in der Kommunikation immer bewusst, dass die Reaktion Ihres Gegenübers auf Ihr gesprochenes Wort verwirren kann. Der Gesprächspartner wird aufgrund der Interpretation Ihrer Worte und Ihres Verhaltens zu Schlüssen kommen, die eine Reaktion erzeugt. Sparen Sie nicht an Rückfragen, ob das Gesagte verstanden wird bzw. wie es verstanden wird. Drücken Sie aus, wenn die Antworten zu weit weg von Ihren Erwartungen sind.

Nur so erreichen Sie, dass Ihre Kommunikation zielführend bleibt.

Aktives zuhören

Sie als Zuhörer können auch dafür sorgen, dass Kommunikation richtig verstanden wird.

Hören Sie auf das Gesagte, und versuchen Sie die Botschaft unbeeinflusst von Ihrer Wertewelt zu akzeptieren. Stellen Sie Fragen, falls Ihnen die Botschaft sonderbar erscheint. Benutzen Sie dabei allerdings Formulierung wie „Ich glaube, ich habe das nicht verstanden“ oder „Bei mir ist folgendes angekommen, stimmt das so?“

Verbale und nonverbales Verhalten

Beide Seiten einer Kommunikation können durch verbales und nonverbales Verhalten ihre Botschaft unterstützen.

Seien Sie sich bewusst, dass Ihr Körper immer das macht, was Ihr Geist meint. Wenn Sie sagen „Ihr seid ein großartiges Team“ und es nicht so meinen, wird Ihr Körper eine Geste ausführen, die das Gegenteil ausdrückt.

Gewöhnen Sie sich an, beim Sprechen vor wichtigen Aussagen eine Pause zu machen, dem Gesprächspartner in die Augen zu sehen und ihre Hände ruhig zu halten. Wenn Sie die drei Tipps beherzigen, ist schon viel für eine gute Kommunikation geschafft.

[1] [WIKIPEDIA], Kommunikationsmodell

Konflikte sind bei der Zusammenarbeit in Projekten unvermeidlich. Sie sind emotional, manchmal dramatisch und oft anstrengend.

Sehr häufig werde ich von meinen Kunden auf das Thema Konfliktmanagement angesprochen. Es scheint keiner – weder privat noch im beruflichen Umfeld – mit Konflikten zurecht zu kommen. Dabei steckt hinter Konfliktmanagement nicht mehr als das Wissen um die Konfliktspirale und einer guten Gesprächsform.

Konfliktspirale

Die Konfliktspirale[1] sagt aus, dass Sie, wenn Sie einen Konflikt nicht lösen, Sie ihn huckepack zum nächsten Konflikt weitertragen. Wenn der Konflikt nicht gelöst wird, baut sich immer mehr auf Ihren Schultern auf.

Wenn der Konflikt sich irgendwann manifestiert, und das ist häufig bei einer Nichtigkeit wie „Fenster auf / Fenster zu“, dann kommt es zu einem lautstarken und manchmal handgreiflichen Vorfall. Das gilt es zu vermeiden.

Wir brauchen also eine Konfliktlösungsstrategie, um bereits den ersten Konflikt wieder aus der Welt schaffen zu können. Die am meisten akzeptierte Konfliktlösungsstrategie ist der Konsens.

Mit dem Konsens wird erreicht, dass wir nicht nur eine Lösung für das aktuelle Problem finden, sondern durch die Erarbeitung der Lösung es zu einer langanhaltenden und nachhaltigen Beziehung zwischen den Konfliktparteien kommt.

Abbildung 13: Konfliktspirale

Gesprächsform

Den Konsens können wir erreichen, indem wir eine Gesprächsform benutzen, die sich an der Mediation[2] angelehnt. Das Gespräch hat folgende Gliederung:

  • Abgrenzung des Gesprächsinhaltes,
  • unterbrechungsfreie Darstellung des Konfliktes aus Sicht der beiden Konfliktparteien,
  • gemeinsame Erarbeitung einer Lösung,
  • Dokumentation.


Was erreichen wir mit diesem Mediationsgespräch?

  • Wir sprechen nicht über „Weltfrieden“[3], sondern über genau den aktuellen Konflikt.
  • Durch eine unterbrechungsfreie Darstellung der beiden Seiten, kommt es zu einem erhöhten Verständnis für die Beweggründe, Ansichten und Emotionen des Gesprächspartners. Wenn ich verstehe, warum der andere so handelt wie er handelt, kann ich auch Verständnis dafür aufbringen.
  • Aufbauend auf dem gemeinsam geschaffenen, gegenseitigen Verständnis ist der Schritt zu einer gemeinsamen Lösung nicht mehr weit.
  • Damit andere aus unserer Situation lernen können, dokumentieren wir unser Gespräch (im Sinne des Datenschutzes neutralisiert).


Beispiel Konflikt im Büro

Zwei Kollegen, die im gleichen Büro sitzen, springen eines Tages auf, treffen sich am Fenster: Der eine will das Fenster wie so häufig aufreißen, der andere versucht, ihn daran zu hindern.

Wir haben den klassischen Bürokonflikt. Die Außenstehenden wundern sich, warum die beiden wie die Kesselflicker rumschreien vielleicht sogar pöbeln.

Ein Kollege spricht die beiden an und empfiehlt ein Mediationsgespräch. Der Kollege sitzt dabei und sorgt für den reibungslosen Ablauf.

Der aktuelle Konflikt ist Fenster auf Fenster zu. Beide Kontrahenten nehmen zu diesem Konflikt Stellung. Es stellt sich heraus, der eine Kollege muss das Fenster immer öffnen, weil er vor drei Jahren in einer Schneewehe gesteckt hat. Er war dort für zwei Tage verschüttet und hatte zum Ende extreme Atemnot. Der andere erklärt, dass er aufgrund eines sehr langsamen Stoffwechsels immer unter Kälte leidet.

Aufgrund des Verständnisses für die Lage des anderen beschließen beide, das Problem mit dem Tausch der Schreibtische zu lösen. Der Kollege, der die Luft braucht, bekommt den Schreibtisch direkt am Fenster. Der Kollege, dem immer kalt ist, wechselt an den Schreibtisch an der Heizung.

[1] [BERLINER TEAM]

[2] [MEDIATION]

[3] Weltfrieden ist eine von mir häufig benutzte Metapher für allgemeines, unkonkretes Drumrumreden.

Bevor die Projektarbeit formell beginnt, sollten Sie ein Projekt-Kickoff-Meeting abhalten, um die Teambildung zu unterstützen. Dies ist ein entscheidender erster Schritt, der den Ton für die folgende Arbeit angibt.

Kickoff-Meeting

Erfolgreiche Auftaktsitzungen erfordern Vorbereitung. Hier sind acht Schritte, um Ihr Kickoff-Meeting zu einem Erfolg zu machen:

  • Legen Sie eine Vision und die Ergebnisse fest
    Legen Sie ein gemeinsames Ziel für alle fest. Legen Sie fest, was bis wann erledigt werden muss.
  • Identifizieren Sie das Team und legen Sie die Rollen fest
    Wer macht was? Erstellen Sie eine Liste, in der detailliert aufgeführt ist, wer für was verantwortlich ist, und fügen Sie Kontaktinformationen für eine einfache Kommunikation hinzu.
  • Entwickeln Sie einen ersten Projektplan
    Stellen Sie Ihren anfänglichen Projektplan vor, aber bedenken Sie, dass sich die Details während der Diskussionen mit Ihrem Team beim Kickoff verschieben können. Sie sollten wissen, wie Sie das Projekt angehen wollen, aber flexibel sein.
  • Definieren Sie Erfolgskriterien
    Wie wird das Projekt gemessen werden? Was wird es erfolgreich machen? Legen Sie frühzeitig Erwartungen und Ziele fest.
  • Identifizieren Sie potenzielle Risiken und Engpässe
    Bereiten Sie das Team auf mögliche Hindernisse vor und sorgen Sie für einen Prozess, um diese schnell zu beseitigen, falls sie auftreten sollten.
  • Richten Sie eine Logistik für die Kommunikation im Team ein
    Was ist die bevorzugte Kommunikationsmethode? Wie können Statusmeldungen am besten bereitgestellt werden? Richten Sie einen Prozess ein (tägliche, wöchentliche Sitzungen) und legen Sie die Technologie dafür fest.
  • Wählen Sie einen Arbeitsprozess oder eine Projektmanagementmethode
    Legen Sie fest, welche Methoden und Rahmenbedingungen das Team befolgen wird, um Arbeitsstile und Erwartungen abzustimmen.
  • Entscheiden Sie, welche Werkzeuge Sie verwenden werden
    Stellen Sie sicher, dass jeder die Werkzeuge hat, die er zur Erfüllung seiner Aufgaben benötigt.


Eingebettet werden kann das Kickoff-Meeting in den Teamentwicklungsansatz von „Bruce W. Tuckman“[1].

Phasenmodell nach Tuckman

Das Phasenmodell von Tuckman besteht aus vier Phasen:

  • Forming
    Die Orientierungsphase ist die Phase, in der sich die Gruppenmitglieder kennenlernen. Sie ist geprägt von förmlicher Höflichkeit und Distanz. Es wird sich vorsichtig abgetastet, die Mitglieder sind noch sehr zurückhaltend.
  • Storming
    Die Kampfphase ist die Phase, in der die Mitglieder einen Platz im Team suchen. Bestimmt wird die Phase durch die Selbstdarstellung der Teammitglieder, den Kampf um (informelle) Führung, es werden Cliquen gebildet und Hierarchien entwickeln sich.
  • Norming
    Die Organisationsphase ist die Phase, in der Strukturen gebildet und Verabredungen getroffen werden. Wir schaffen ein erste „Wir“-Gefühl, geben uns Feedback und etablieren Arbeitsstandards.
  • Performing
    Die Integrationsphase ist die Phase, in der eine vertrauensvolle Zusammenarbeit etabliert wird. Wir haben Spaß an der Zusammenarbeit, wissen die Unterschiede der Teammitglieder zu schätzen und organisieren unsere Arbeit selbst.


Tuckman hat später eine fünfte Phase entwickelt: Adjourning. Die Ausstiegsphase beschreibt Auflösungsprozesse, die am Ende des Projektes durchgeführt werden.

[1] [TUCKMAN]

Meetings können eine wertvolle Zeit für die Zusammenarbeit, aber auch Zeiten völliger Unproduktivität sein.

Meeting sind unproduktiv, da wir in Besprechungen vor allem reden und Entschlüsse fassen, also nichts Wertiges schaffen. Meetings sind selbstverständlich notwendig, aber wir sollten die Zeit für Meetings kurzhalten.

Wenn Sie eine Besprechung planen, habe ich ein paar Tipps für Sie:

  • Erstellen Sie Agenda mit Zeiten.
  • Laden Sie nur Personen ein, die absolut notwendig sind. Sie verschwenden sonst die Zeit der Meetingteilnehmer und anderer Personen.
  • Protokollieren Sie jedes Meeting inkl. der Aufgabenverteilung (Name, Erfüllungsdatum) und versenden Sie das Protokoll zeitnah.


Wenn Sie statt eines Meetings einen Workshop durchführen, achten Sie darauf, dass Sie dort die Methoden auch richtig einsetzen.

Als Beispiel soll die Methode des Brainstorming dargestellt werden. Das Brainstorming[1], das viel Anklang findet, wird leider immer falsch durchgeführt. Brainstorming besteht aus drei Phasen:

  • Ideen erzeugen
    In dieser Phase sitzen die Workshopteilnehmer für eine festgelegte Zeit zusammen und machen sich Gedanken zu einer vorher gestellten Frage. Die Gedanken werden laut ausgesprochen und von einem Moderator unkommentiert an einer Wand notiert. Durch die Ideen anderer, fallen den Teilnehmern weitere Ideen ein – sie assoziieren.
  • Ideen clustern
    In der zweiten Phase werden die Ideen geordnet. Evtl. gibt es gleiche oder sehr ähnliche Ideen oder völlig unterschiedliche Gedanken, die alle unter einige wenige Oberbegriffe zusammengefasst werden.
  • Entscheidung finden
    Am Ende wird entschieden, welche Idee (oder welches Ideenbündel) die Frage am besten beantwortet. Mit der Beantwortung der Frage endet das Brainstorming.


Auf den vorhergehenden Seiten habe ich Ihnen aufgezeigt, dass die Zusammenarbeit mit dem Kernteam mindestens genauso wichtig ist wie die Beherrschung der Tools des Projektmanagements.

Ich empfinde es sogar für wichtiger diese „soften“ Aspekte eines Projektes zu beherrschen. Tools kann jeder lernen bzw. durch die Fähigkeiten seiner Kernteammitglieder abdecken – Führen müssen Sie immer selbst!

Klassisches Projektmanagement hat weiterhin seine Daseinsberechtigung. Es gibt Struktur und Verlässlichkeit und ist als Methode ausgereift. Und sequenziell geht immer; manchmal geht aber agil besser!

Exkurs: Die Top 5 der klassischen Projektmanagement Bücher

Sie könnten sich die Frage stellen, warum der Autor in seinem eigenen Buch Konkurrenz-Werke auflistet – eine berechtigte Frage!

Jedes Buch, das sich mit Projektmanagement beschäftigt, schaut auf die Thematik aus unterschiedlichen Perspektiven. Deshalb ist es sinnvoll, auch andere Bücher zum Thema zu lesen.

Ich habe Ihnen die fünf Bücher ausgewählt, die sich aus meiner Sicht und Erfahrung als sinnvolle Ergänzung zum aktuellen Wissensstand eignen.

Johannsen – Kramer – Kostal – Sadowicz

„Basiswissen für Softwareprojektmanager im klassischen und agilen Umfeld: Aus- und Weiterbildung zum ASQF® Certified Professional for Project Management (CPPM)“

ASIN: B071ZS7VSM

Auch wenn ich in meinem Buch nicht speziell auf Zertifizierungssysteme eingehen will, möchte ich aber dieses Buch empfehlen. Es ist das einzige Buch, dass ich kenne, das in einem Werk klassisches und agiles Umfeld zusammenbringt. Dieses Buch ist die Grundlage für die Weiterbildung zum ASQF Certified Professional for Project Management.

Walter Jakoby

„Projektmanagement für Ingenieure: Ein praxisnahes Lehrbuch für den systematischen Projekterfolg“

ASIN: B07JJTXDSH

Autor Jacobi, selbst Ingenieur, hat eine praxisnahe Einführung in Prozesse, Methoden und Tools für das Projektmanagement in den vorwiegend technischen Branchen wie Elektronik, Automation, Mechatronik, aber auch das Bauwesen geschrieben. Fallbeispiele aus realen Projekten dieser Branche veranschaulichen den praktischen Nutzen.

Burkhard Klose

„Projektabwicklung: Arbeitshilfen, Fallbeispiele und Checklisten im Projektmanagement“

ISBN-13: 978-3636031648

Schwerpunkt des Handbuches von Klose sind Arbeitshilfen für die Projektabwicklung in mittleren und kleinen Projekten. Das Handbuch schließt mit Hilfe von zahlreichen Checklisten, Formularen und Beispielen die Lücke zwischen Theorie sowie Praxis und dient als situationsbezogenes Nachschlagewerk direkt am Arbeitsplatz.

Hans-Dieter Litke

„Projektmanagement. Methoden, Techniken, Verhaltensweisen. Evolutionäres Projektmanagement“

ISBN-13: 978-3446226999

Die interessantesten Aspekte dieses Werks sind die betriebswirtschaftlichen Betrachtungen für Projekte und darüber hinaus finden Sie bei Liedtke Formulare für Ihre sequenziellen Projekte.

GPM

„Individual Competence Baseline, Version 4.0 (ICB4) – Bundle”

Ähnlich verhält es sich mit diesem Buch wie mit dem Zertifizierungsband der ASQF. Die GPM ist in Deutschland seit Jahrzehnten als Zertifizierungsgrundlage anerkannt. Auf insgesamt 800 Seiten wird klassisches Projektmanagement komplett und tiefgehend erläutert inklusive der Vorbereitung auf Zertifikate.

Im Teil 3 des Buches lege ich die Grundlagen für das Verständnis des agilen Projektmanagements. Wir greifen das Agile Manifest nochmal auf und Sie lernen die wichtigsten Vertreter von Agilität kennen.

[1] [Windolph]

TEIL 3: AGILES PROJEKTMANAGEMENT

Agile[1] (dt.: agil) ist ein Projektmanagement-Konzept, das entwickelt wurde, um Projektteams eine flexiblere und effizientere Möglichkeit zu bieten, Produkte schneller auf den Markt zu bringen. Die besondere Bedeutung von Agilität liegt in der Fähigkeit, schnell und einfach zu reagieren. Damit ermöglicht ein agiler Ansatz den Projektteams eine schnellere und einfachere Anpassung im Vergleich zu anderen Projektmethoden.

Viele der heutigen Projekte – insbesondere in der Softwareentwicklung – haben Variable, die mit einer traditionellen Projektmanagementmethode nicht angemessen behandelt werden können. In früheren Kapiteln des Buches habe ich Ihnen bereits angedeutet, dass es im klassischen Projektmanagement schwierig ist, Änderungen in das Projekt zu involvieren.

Die nächsten Seiten sollen Ihnen helfen, die Grundlagen der agilen Methodik zu verstehen. Sie sollen danach verinnerlicht haben, welche Projekte von einem agilen Ansatz profitieren und wie Projektteams erfolgreich umsetzen können.

[1] Agilität statt aus dem englisch-sprachigen Raum, viele Begriffe werden nicht übersetzt oder sie werden im Original benutzt. Da ich auch „schick“ sein will, tue ich es auch.

Kapitel 6: Grundlagen von Agilität

Über neue Projektmanagementansätze wurde bereits in den 80er und 90er Jahre des letzten Jahrhunderts diskutiert. Je nach Quelle lässt sich die Geschichte der agilen Methodik sogar bis in die 1960er Jahre zurückverfolgen. Dabei war nicht mal die Softwareentwicklung der Treiber, sondern die Industrie, die immer häufiger neue Produkte schnell auf den Markt bringen musste. Der Schmelztiegel, in dem alle Überlegungen münden, war das Agile Manifest für die Softwareentwicklung im Jahr 2001.

Dieses Manifest war das Ergebnis einer Klausurtagung in Utah, bei der sich eine Gruppe führender Softwareentwickler trafen, um Probleme der Branche und mögliche Lösungen zu diskutieren.

Im Agilen Manifest[1] wird die agile Methodik mittels vier Hauptpfeiler und zwölf Prinzipien zur Organisation von Softwareprojekten zusammengefasst. Es gibt 17 sog. Erstunterzeichner. Die Ideen wurden konsequenterweise als erstes in SW-Projekten ausprobiert bzw. interpretiert. Mittlerweile finden die Ideen so viel Anklang, dass sie auch in anderen Branchen zur Anwendung kommen.

Sehen wir uns das Agile Manifest näher an.

Der erste Satz des Manifests heißt „Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen“. Lassen Sie mich diesen Satz interpretieren.

Es geht nicht darum, die Projektwelt neu zu erfinden, sondern aufgrund des Erlernten und der Erfahrungen einen besseren Weg für die Durchführung von Projekten zu beschreiten.

Projekte beginnen immer mit Menschen, auch Softwareprojekte. Denn die Software wird weiterhin von den Menschen erstellt, getestet und dokumentiert. Als wichtiger Hinweis wie wir den Umgang mit unseren Kollegen gestalten wollen erkennen wir im Satzteil „…und anderen dabei helfen …“. Das Agile Manifest ist im Jahre 2001 erstellt worden und hat sich in einer Arbeitsumgebung entwickelt, indem Mitarbeiter ihre Arbeitsplätze vor allem deswegen erhalten konnten, weil sie Expertenwissen sammelten, das es zu hüten galt. Daher ist das Teilen von Wissen zu dem damaligen Zeitpunkt tatsächlich ein neuer Ansatz.

Der zweite Satz beginnt mit „Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:“ und es folgen vier Anstriche, die ich später erläutere. Ich möchte zuerst den letzten Satz widergeben: „Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.“ Dieser Satz ist deshalb wichtig, weil wir damit die vier Werte besser einordnen können. Bitte machen Sie nicht den Fehler zu sagen „links ist richtig“ und „rechts ist falsch“, sondern akzeptieren Sie, dass den klassischen Werten eines Projektes weitere Werte hinzugegeben werden.

Die vier Werte des Manifests für Agile Softwareentwicklung sind[2]:

  • Individuen und Interaktionen [schätzen wir] mehr als Prozesse und Werkzeuge
  • Funktionierende Software [schätzen wir] mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden [schätzen wir] mehr als Vertragsverhandlungen
  • Reaktion auf Veränderung [schätzen wir] mehr als das Befolgen eines Plans


Diese vier Werte sind bei weitem noch keine Arbeitsanweisung bzw. Umsetzungsanleitung. Dafür wurden u.a. Frameworks (dt. Rahmenwerke) wie Scrum, Kanban, Extreme Programmierung oder DSDM entwickelt.

[1] [AM]

[2] Die Worte [schätzen wir] sind von mir hinzugefügt worden, um die Lesbarkeit zu verbessern.

Den Machern des Agilen Manifests reichten die vier Werte nicht. Sie erweiterten das Manifest für Agile Softwareentwicklung mit zwölf agilen Prinzipien[1], die alle Projekte befolgen sollen.

  1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
  2. Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
  3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
  4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
  5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
  6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
  7. Funktionierende Software ist das wichtigste Fortschrittsmaß.
  8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
  9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
  10. Einfachheit (die Kunst, die Menge nicht getaner Arbeit zu maximieren) ist essenziell.
  11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
  12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.


Die Ausgestaltung dieser zwölf Prinzipien wird ebenfalls den Entwicklern der Frameworks überlassen. Später im Buch werden wir uns insbesondere mit Scrum als dem bekanntesten und beliebtesten Framework beschäftigen.

Betrachten wir aber vorerst ganz allgemein die Vorteile von agilen Projektmanagementmethoden.

[1] [AM]

Wir stellen uns als erstes die Frage, welche Organisation und Unternehmen haben die größten Vorteile von Agilität?

  • Jedes Projekt, das sich im Laufe der Zeit entwickelt oder zu Beginn keine klaren Vorgaben und Anforderungen hat.
  • Organisationen, die in sich schnell verändernden Umfeldern arbeiten.
  • Organisationen, die während der gesamten Projektlaufzeit eng mit ihrem Kunden zusammenarbeiten müssen.
  • Unternehmen, die einen Prototyp erstellen wollen, bevor sie das endgültige Projektergebnis aufbauen können.
  • Projekte, die ein schnelles Feedback der Beteiligten erfordern.


Es ist keine Frage der Größe eines Unternehmens, ob es Vorteile aus Agilität ziehen kann. Meiner Erfahrung nach sind gerade KMUs mit den genannten Aspekten vertraut.

Wenn Ihr Projekt einen der Aspekte erfüllt, werden Sie am stärksten von den Vorteilen profitieren können, aber natürlich finden auch andere Unternehmen Ihre Vorteile. Weitere wichtige Vorteile sind:

  • Kontinuierlicher Kundenkontakt
    Bei den traditionellen Projektmanagementmethoden stehen der Projektleiter und das Kernteam meist nur zu Beginn und am Ende des Projekts mit dem Kunden in Kontakt. D. h., wenn die Anforderungen oder Erwartungen des Kunden zu Beginn nicht vollständig erfasst wurden oder sich im Laufe der Projektdauer ändern, gestaltet sich die Bearbeitung als schwierig und aufwändig.

    Mit Agilität gibt es einen ständigen Kontakt mit dem Kunden während des gesamten Projektes. Wir stellen damit sicher, dass das Team auf dem richtigen Weg ist, damit das Endprodukt genauso wird, wie der Kunde es wünscht.
  • Fähigkeit zur Anpassung
    Mit Agilität können Änderungen mit minimalem Aufwand eingearbeitet werden, unabhängig davon, wie weit Ihr Team im Projekt fortgeschritten ist.
  • Schnellere Lieferung
    Agilität beinhaltet einen kontinuierlichen Entwicklungsansatz, der sicherstellt, dass das Team ständig funktionsfähige Produkte liefert. Früher musste der Kunde bis zum Ende des Projektes warten, um dann das Gesamtergebnis zu erhalten. Heute darf er eine funktionsfähige Version des Produkts in viel kürzeren Abständen, normalerweise quartalsweise, erwarten[1].
  • Geringeres Projektrisiko
    Da das Team regelmäßig Versionen des Produkts entwickelt und ausliefert – und damit frühzeitig Kundenfeedback erhalten wird – wird das Risiko eines Scheiterns des Projekts minimiert. Der schlimmste anzunehmende Unfall ist es, wenn die letzte Version nicht den Wünschen des Kunden entspricht und wir diesen (kleinen) Teil unserer gesamten Arbeit vergeblich getan haben.
  • Laufende Innovation
    Agilität unterstützt die Zusammenarbeit und die kontinuierliche Verbesserung, die beide zu Innovationen und zur Entwicklung neuer Produkte und Funktionen sowie zur Verbesserung unserer eigenen Prozesse führen können.

[1] Mittlerweile wird von SW-Auslieferungen mehrmals am Tag gesprochen, was aber zu Zeiten des Agilen Manifests noch utopisch war.

Trotz der vielen Vorteile von Agilität, ist die Methodik nicht für jedes Projekt oder jedes Unternehmen geeignet. Doch woher wissen Sie, wann Sie die agile Projektmanagementmethode nicht anwenden sollten?

Das sind vier Aspekte dafür, dass die agile Entwicklungsmethodik nicht die beste Option ist:

  • Ergebnisse der Projekte sind stabil und Anforderungen werden gut verstanden
    Agilität soll dazu beitragen, die Kosten für Änderungen und Unsicherheiten in einem Projekt zu reduzieren, indem es in iterative[1] Arbeitsphasen unterteilt wird. Wenn jedoch bereits sehr wenig Ungewissheit und geringe Änderungswünsche bestehen, dann ist der klassisch-sequenzielle Ansatz der richtige.
  • Projekt muss ein wiederholbares Ergebnis liefern
    In alle vorgenannte Definition eines Projektes wird auf die Einmaligkeit des Vorhabens abgestellt. Was aber, wenn ein Kunde Sie bittet, fünf identische Häuser zu bauen? Mit Hilfe von Agilität könnte dies zu fünf einzigartigen statt zu fünf identischen Häusern führen. Einer der Nachteile von Agilität ist, dass sie nicht auf Reproduzierbarkeit ausgelegt ist.
  • Kunde will Agilität nicht
    Ein agiles Projekt erfordert einen ständigen Kontakt mit dem Kunden. Allerdings haben einige Kunden nicht den Wunsch, sich jedem Projekt zu widmen. Wenn das Projekt als unwichtig, geringwertig oder risikoarm eingestuft wird, bevorzugen sie möglicherweise einen traditionelleren Ansatz, bei dem sie nur in Schlüsselphasen oder bei der Endlieferung einbezogen werden wollen.
  • Unternehmen ist für Agilität nicht bereit
    Wenn das Unternehmen oder das Projektteam noch nicht bereit für neue Methoden ist, kann der Versuch, den agilen Entwicklungszyklus zu übernehmen, ein Risiko für das Projekt darstellen.


Der letzte Punkt ist so wichtig, dass ich Ihnen fünf Indikatoren zeigen möchte, die Gründe dafür sein können, warum Unternehmen für Agilität nicht bereit sind.

  • Agilität wird nicht verstanden
    Wenn Projektteam und Unternehmen nicht in Agilität geschult sind oder kein solides Verständnis der Prinzipien, Praktiken und Rahmenbedingungen haben, können sie auch nicht bereit sein, Agilität zu verwenden.
  • Stakeholder sind resistent
    Ob es sich nun um den Projektbeauftrager[2] oder ein wichtiges Teammitglied handelt, wenn sich jemand der Einführung von Agilität widersetzt, wird die Einführung der Methode nicht erfolgreich sein.
  • Organisation kann die tägliche, persönliche Zusammenarbeit nicht unterstützen
    Wenn es erhebliche Hindernisse für die tägliche Kommunikation und persönliche Zusammenarbeit zwischen den Teammitgliedern gibt (z. B. arbeiten Teile des Teams in fernen Ländern), ist Agilität möglicherweise nicht der beste Ansatz[3].
  • Unternehmensstruktur kann funktionsübergreifende Teams nicht unterstützen
    In allen Projektmanagementsystemen wird funktions- bzw. abteilungsübergreifend gearbeitet. In agilen Projekten erfolgt diese Zusammenarbeit bereits vom ersten Tag an und bedarf daher noch stärker den Aspekt der übergreifenden Teambildung. Wenn im Unternehmen keine Bereitschaft besteht in dieser Form zusammenzuarbeiten, ist Agilität nicht einsetzbar.
  • Organisation erfordert eine umfangreiche Dokumentation
    Wenn Ihr Unternehmen eine umfangreiche Dokumentation und Testberichte (u.a. auf Grund von rechtlichen Vorgaben) benötigt, kann die Einführung von Agilität zu kostspielig sein. Eines der zwölf agilen Prinzipien basiert auf der Reduzierung von Dokumentation als Nachweismittel.

[1] Iteration beschreibt einen Prozess mehrfachen Wiederholens gleicher oder ähnlicher Handlungen zur Annäherung an eine Lösung oder ein bestimmtes Ziel.

[2] Bei Agilität wird häufig statt „Projektbeauftrager“ „Projektsponsor“ gesagt, was aber für mich im Deutschen keinen Sinn ergibt. Daher bleibe ich hier bei der klassischen Namensnennung.

[3] Mir ist bewusst, dass so die Praxis ist, aber „persönlich“ meint eine direkte Kommunikation ohne Technik.

Die agile Methode umreißt die besten Praktiken für die Organisation von Projekten, basierend die bereits erläuterten Werte und Prinzipien, die im Agilen Manifest dokumentiert sind.

Scrum ist vermutlich das bekannteste und das beliebteste Framework in der agilen Softwareentwicklung. Ich möchte Ihnen zunächst den Unterschied zwischen der agile Methode und Scrum darstellen.

Scrum wird als Framework beschrieben, das die Teamarbeit, die Verantwortlichkeit und den iterativen Fortschritt auf ein gut definiertes Ziel hin, betont. Mit anderen Worten: Scrum ist ein Rahmenwerk, das wir zur Umsetzung der agilen Werte und Prinzipien nutzen können.

Um den Unterschied von Agile und Scrum besser zu verstehen, können Sie sich Scrum als eine Richtlinie für die Anwendung des agilen Ansatzes im Projektmanagement vorstellen. Dazu bietet Scrum Rollen, Artefakte, Rituale und Regeln, die für die erfolgreiche Einführung der agilen Denkweise erforderlich sind.

Der Hauptunterschied zwischen Agile und Scrum ist: Agilität ist der Prozess, den wir aufbauen wollen, Scrum ist ein Werkzeug für seinen Erfolg. Es ist jedoch nicht das einzige Framework, das Sie zur Planung und Durchführung eines agilen Projekts einsetzen können.

Im Kapitel 7 werde ich Ihnen einen Überblick geben, welche die wichtigsten agilen Frameworks sind.

Davor stelle ich einige Überlegungen zu den Gemeinsamkeiten der Methoden an.

Kapitel 7: Agile Frameworks

Zu Beginn dieses Kapitels werden wir uns allgemein mit Frameworks beschäftigen. Ich stelle Ihnen einige wichtige und bekannte Frameworks vor.

Scrum gebe ich dann ein eigenes Kapitel, um diese Framework intensiver zu besprechen.

Ein Projektmanagement-Framework ist die Sammlung von Rollen, Werkzeugen, Aufgaben und Prozessen, die zur Organisation, Planung und Durchführung eines Projekts von der Initiierung bis zum Abschluss verwendet werden.

Einfacher ausgedrückt: ein Framework umfasst alles, was wir zur erfolgreichen Planung und Steuerung eines Projektes benötigen.

Ein Standardprojektmanagement-Framework kann in drei Hauptbereiche unterteilt werden:

  • Übersicht über den Projektlebenszyklus
    Ein wesentlicher Unterschied zwischen klassischen und agilen Methoden besteht darin, dass ihr Arbeitspensum unterschiedliche Lebenszyklen umfassen. Das Wasserfall-Modell umfasst beispielsweise die fünf Standardphasen Einleitung, Planung, Ausführung, Steuerung und Schließung.

    Bei einem agilen Projektrahmen hingegen wird wahrscheinlich ein modifizierter Lebenszyklus verwendet, um die flexible und iterative Natur von Agilität besser zu repräsentieren.
  • Vorlagen, Checklisten und andere Werkzeuge
    Das Projektframework enthält weiterhin Informationen, die wir für ein effektives Berichtswesen des Projekts benötigen. Dies kann von Empfehlungen zu Aufgaben, Aktivitäten und Ressourcen bis hin zum Entwurf von Projektdokumenten alles umfassen.
  • Prozesse und Aktivitäten
    Jedes Rahmenwerk skizziert leicht unterschiedliche Projektprozesse, die zu befolgen sind, was einer der Gründe dafür ist, dass manche Rahmenwerke für Projekte besser funktionieren als andere.


Eine „normale“ Aktivität, die in vielen agilen Rahmenwerken beschrieben wird, sind beispielsweise tägliche Meetings.

Der Zweck eines Projektmanagement-Frameworks besteht darin, einen klaren und konsistenten Rahmen für alle Projekte eines Unternehmens zu schaffen – einen Rahmen, der dazu beiträgt, eine zuverlässige und wiederholbare Durchführung von Projekten in allen Teams zu gewährleisten.

Frameworks wollen auch dazu beitragen, dass bewährte Praktiken zum Nutzen aller dokumentiert und gemeinsam genutzt werden. Sie helfen Unternehmen und sogar Branchen, gemeinsame Standards zu schaffen, so dass ein Bauprojekt eines Unternehmens dem eines anderen ähnlich ist.

Oft werden die Begriffe der Methodik und des Framework synonym benutzt. Gibt es aber vielleicht doch einen Unterschied zwischen beiden?

Eine Methodik beschreibt die Grundsätze, Werte und besten Praktiken des Projektmanagements, während ein Framework vorschreibt, wie diese zu befolgen sind. Mit anderen Worten, eine Methode sagt uns, was wir erreichen wollen, und ein Rahmenwerk konzentriert sich darauf, wie wir es erreichen können. Die Prinzipien der Agilität können uns z. B. sagen, dass es wichtig ist, auf Veränderungen zu reagieren. Diese Methoden sagt uns jedoch nicht, wie wir sicherstellen können, dass unsere Projekte gut auf Veränderungen reagieren können. Diese Informationen werden in einem Rahmenwerk wie Scrum dargelegt.

Allen agilen Rahmenwerken ist gemein, dass sie sich auf das Manifest der Agilen Softwareentwicklung beziehen.

Der agile Projektverlauf unterscheidet sich von klassischen Projektmanagementansätzen durch seine Betonung

  • der iterativen Entwicklung,
  • der Flexibilität,
  • des kontinuierlichen Feedbacks und
  • der Wertschätzung von Menschen.


Daher wird jedes agile Framework um diese Schlüsselwerte herum aufgebaut.

Jedes Rahmenwerk hat zwar seine einzigartigen Facetten, aber sie wurden so aufgebaut, dass die Grundlagen des Manifests befolgen und das der erfolgreiche Abschluss eines Projektes gewährleistet werden kann.

Agile Frameworks gelten als leichtgewichtig im Vergleich zu traditionellen Frameworks, da sie sich in der Regel darauf konzentrieren, die Dokumentation und die Regeln auf ein notwendiges Minimum zu beschränken. Dennoch sollte jeder agile Projektrahmen alle kritischen Projektprozesse und -phasen wie Initiierung, Planung usw. umfassen.

Scrum

Auf die Frage nach der populärsten agilen Methodik, wird die Mehrheit der Befragten wahrscheinlich mit dem Scrum-Framework antworten.

Scrum wurde in den 1990er Jahren entwickelt und basiert auf dem Artikel der Autoren „Hirotaka Takeuchi“ und „Ikujiro Nonaka“ der „Harvard Business Review“ mit dem Titel “The New New Product Development Game”[1].

Wie bei anderen agilen Frameworks, skizziert Scrum einen iterativen Ansatz für das Projektmanagement. Scrum schreibt vor, ein Projekt in Sprints aufzuschlüsseln, die normalerweise nur zwei bis max. vier Wochen dauern. Jeder Sprint soll mit der Fertigstellung einer praktikablen Version (Inkrement) enden.

Scrum wurde ursprünglich für die Softwareproduktion entworfen. Es ist jedoch flexibel genug, um für jedes komplexe Projekt in jeder Branche eingesetzt werden zu können. Es funktioniert jedoch am besten, wenn Ihr Projekt zu einem konkreten Produkt und nicht zu einer Dienstleistung führt.

Scrum wird als leicht und flexibel, aber als schwierig zu beherrschen angesehen. Sein Rahmenwerk basiert auf den drei Säulen Transparenz, Überprüfung und Anpassung.

IT-Kanban[2]

IT-Kanban ist ein visuelles Mittel zur Verwaltung von Projekten, dass die Sichtbarkeit von Arbeit betont. Ursprünglich als Produktionsprozesssteuerung in der Fertigungsindustrie konzipiert, hilft IT-Kanban den Teams bei der Ausführung der Just-in-Time-Produktion, indem es jedem ermöglicht, zu sehen, wo die Arbeit im Projekt ist und was als nächstes ansteht.

Das Kanban-Framework ähnelt in vielerlei Hinsicht Scrum. Unter anderem verwendet Kanban auch eine Tafel, um den Arbeitsfortschritt anzuzeigen und verfolgbar zu machen. Im Gegensatz zu Scrum verfolgt das Kanban-Board jedoch die gesamte Produktarbeit, teilt sie nicht in Sprints auf.

Einige der Stärken von IT-Kanban ist die Fähigkeit, Engpässe und Verschwendung zu erkennen und Wartezeit zu reduzieren.

Extreme Programmierung (XP)

Extreme Programming (XP) ist ein agiles Framework, das ursprünglich für agile Softwareentwicklungsprojekte entwickelt wurde. XP konzentriert sich auf die kontinuierliche Entwicklung und die Bereitstellung für den Kunden. Es verwendet ebenfalls Intervalle – Sprints genannt.

Das XP-Framework ist auf ingenieurwissenschaftliche Prinzipien ausgerichtet und umfasst zwölf unterstützende Prozesse, die für die Welt der Softwareentwicklung spezifisch sind:

  • Planspiel
  • Kleine Veröffentlichungen
  • Kunden-Akzeptanztests
  • Einfacher Entwurf
  • Paarweise Programmierung
  • Testgetriebene Entwicklung
  • Refactoring
  • Kontinuierliche Integration
  • Kollektives Code-Eigentum
  • Kodierungsstandards
  • Metapher
  • Nachhaltiges Tempo


Scrum hat viel gelernt von XP und integriert wesentliche Prinzipien.

Feature-Driven Development (FDD)

Feature-Driven Development wurde als schlanke Methode von „Jeff De Luca“[3] im Jahre 1997 definiert, um größere und zeitkritische Projekte mit einer Laufzeit über 15 Monaten und mehr als 50 Entwicklern durchzuführen.

FDD stellt den Feature-Begriff in den Mittelpunkt der Entwicklung, wobei jedes Feature einen Mehrwert für den Kunden darstellt. Die Entwicklung wird anhand eines Feature-Plans organisiert.

FDD definiert ein Prozess- und ein Rollenmodell, das gut mit existierenden klassischen Projektstrukturen harmonieren. Daher fällt es vielen Unternehmen leichter, FDD einzuführen als XP oder Scrum. Eine wichtige Rolle spielt der Chefarchitekt, der ständig den Überblick über die Gesamtarchitektur und die fachlichen Kernmodelle behält.

FDD ist ganz im Sinne der agilen Methoden sehr kompakt und wird auf nur 10 Seiten komplett beschreiben.

Entwicklungsmethode für dynamische Systeme (DSDM)

Die Methode zur Entwicklung dynamischer Systeme (DSDM) entstand 1994 aus der Notwendigkeit heraus, ein gemeinsames industrielles Rahmenwerk für eine schnelle Softwarebereitstellung zu schaffen. Wie Scrum, XP und FDD unterteilt das DSDM-Framework Projekte in kleinere Sprints.

Die bekannte MoSCoW-Methode[4], eine Priorisierungstechnik, wurde in DSDM entwickelt.

Der DSDM-Framework basiert auf acht Schlüsselprinzipien:

  • Konzentration auf den Geschäftsbedarf
  • Pünktliche Lieferung
  • Zusammenarbeiten
  • Keine Kompromisse bei der Qualität
  • Schrittweise auf einem festen Fundament aufbauen
  • Iterativ entwickeln
  • Kontinuierlich und klar kommunizieren
  • Kontrolle demonstrieren


Crystal

Crystal ist eine Familie von Softwareentwicklungsmethoden, die zu den agilen Methoden der Softwareentwicklung gerechnet wird. Die Mitglieder dieser Familie sind in der Regel mit Farben bezeichnet. Die einfachste Variante heißt Crystal Clear (dt. glasklar).

Jede Crystal-Methodik hat ihre eigene, spezielle Ausformulierung, die von unterschiedlichen Faktoren wie Teamgröße, Projektprioritäten oder Kritikalität des Projektes abhängen.

Lean Management

Während Lean oft ebenfalls als agiles Rahmenwerke bezeichnet wird, ist die Entwicklung von Lean eigentlich ein völlig separates Vorgehen. Ein Grund der Nennung könnte sein, dass viele gleichlautende Begriffe benutzt werden.

Lean Management bezeichnet die Gesamtheit der Denkprinzipien, Methoden und Verfahrensweisen zur effizienten Gestaltung der gesamten Wertschöpfungskette industrieller Güter.

Zu den Hauptprinzipien der Lean-Methodik gehören:

  • Beseitigung von Verschwendung
  • Qualität aufbauen
  • Wissen schaffen
  • Verpflichtung aufschieben
  • Schnell liefern
  • Menschen respektieren
  • Optimierung


Lean Management findet sich als Grundlage für DevOps[5] wieder, dass ein Verbesserung in den Prozessen der IT-Abteilung bringen soll.

Best Practices für die Wahl des richtigen Frameworks

Woher wissen Sie bei den vielen und beliebten agilen Ansätzen, aus denen Sie wählen können, welcher der richtige für Ihr Projekt ist?

Im Grunde gibt es nicht „den“ besten Rahmen, der für alle Projekte geeignet ist. Daher ist es wichtig, die Bedürfnisse Ihres individuellen Projekts und Ihres Teams zu bewerten, wenn Sie festlegen, welcher Rahmen verwendet werden soll.

Nachfolgend habe ich Ihnen sieben bewährte Verfahren für Projektmanager aufgelistet, die auf dem Organizational Project Management Maturity Model (OPM3)[6] des Project Management Institute und dem Leitfaden für die Umsetzung des organisatorischen Projektmanagements basieren.

  • Größe und den Umfang des Projekts
    Wenn es sich um ein großes, langwieriges Projekt handelt, kann es schwierig sein, kurze Iterationen durchzuführen.

    Ist der Projektumfang hingegen schwierig zu definieren und wird erwartet, dass er sich im Laufe der Zeit entwickelt, sind agile Ansätze wahrscheinlich besser geeignet als der traditionellere Rahmen.
  • Mehrwert des Projektes für die eigene Organisation
    Bevor Sie ein Projekt in Angriff nehmen, ist es wichtig, seinen Geschäftsfall und seinen Wert für die Organisation zu verstehen. Welche Vorteile bietet dieses Projekt für unser Unternehmen?
  • Mehrwert für den Kunden
    Verstehen Sie Ziele des Kunden und erwartete Ergebnisse und welche Prioritäten der Kunde für das Projekt aufstellt.
  • Zielsystem des Projektes klären
    Identifizieren Sie alle Projekttreiber, Ziele, Ergebnisse und Prioritäten, die durch unterschiedliche Methoden beeinflusst werden. Wenn das Ziel des Projekts darin besteht, es so kosteneffektiv[7] wie möglich durchzuführen, kann eine schlanke Methodik am effektivsten sein. Wenn ein Kunde eine ausführliche Programmdokumentation erwartet, könnte FDD am besten geeignet sein.
  • Methodenvergleich anstellen
    Erstellen Sie eine Liste der potenziellen Methoden und ordnen Sie ihre Eignung anhand der im letzten Schritt dargelegten Kriterien an.
  • Entscheidung selbst treffen
    Da Sie vermutlich derjenige in Ihrer Organisation sind, der die Frage nach der richtigen Methode am besten treffen kann, tun Sie es auch. Sie werden den Rahmen wählen, der die besten Ergebnisse mit dem geringsten Risiko liefern wird.
  • Entscheidung überprüfen
    Wenn Sie sich für ein Framework entschieden haben, beobachten Sie, ob er funktioniert. Wenn der gewählte Framework nicht die gewünschten Ergebnisse bietet, müssen Sie möglicherweise modifizieren oder sogar das Rahmenwerk ändern.


Im folgenden Kapitel werde ich besonders auf Scrum eingehen. Sie werden lernen, was Scrum ist und auf welchen Ideen Scrum basiert.

[1] [TAKEUCHI]

[2] Meist wird von Kanban gesprochen und nicht von IT-Kanban. Ich möchte damit klarstellen, dass unser Kanban die Adaption der industriellen Produktionsprozesssteuerung ist.

[3] [JeffDeLuca]

[4] [QWE WIKI]

[5] [DDA]

[6] [OPM]

[7] Ich muss zugeben, dass der Begriff als solcher völliger Nonsens ist. Ein Projekt kostet genau so viel wie es kosten muss, um es umzusetzen, aber Manager reden so.

Kapitel 8: Softwareerstellung mit Scrum

Wie bereits beschrieben wurde Scrum in den 80er Jahre das erste Mal erwähnt. Damals ging es noch um die Entwicklung von neuen Industrieprodukten. In den 90er Jahren haben dann Ken Schwaber und Jeff Sutherland die Idee übernommen und sie für die Softwareentwicklung adaptiert.

Das Ganze beschreiben die beiden im seit 2010 erscheinenden „Scrum Guide“[1]. Dieser wird ca. alle zwei Jahre aktualisiert.

Der ca. 22-seitige „Scrum Guide“ beginnt mit der Definition von Scrum:

„[Scrum ist ein] …Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit höchstmöglichem Wert auszuliefern.“

Weiter heißt es, dass Scrum weder ein Prozess noch eine Technik noch eine vollständige Methode ist. Vielmehr handelt es sich um ein Rahmenwerk, innerhalb dessen verschiedene Prozesse und Techniken zum Einsatz gebracht werden können.

Scrum ist laut „Scrum Guide“

  • leichtgewichtig,
  • einfach zu verstehen, aber
  • schwierig zu meistern.


Der Kern von Scrum ist ein kleines, lokales Team von Menschen, die sehr flexibel und anpassungsfähig sind. Das Team befolgt die Vorgaben des „Scrum Guide“ und kann immer, wenn dieser keine Vorgabe macht, die Prozesse selbst entwickeln.

Scrum basiert auf der Idee der empirische Prozesssteuerung (Empirie), was bedeutet, das Wissen aus Erfahrung gewonnen wird und Entscheidungen ausschließlich auf Basis des Bekannten getroffen werden. Um unsere Erfahrung möglichst schnell zu vergrößern, arbeiten wir mit einem iterativen Ansatz.

Es gibt drei Säulen, die die empirische Prozesssteuerung tragen: Transparenz (engl. tranparency), Überprüfung (engl. inspection) und Anpassung (engl. adaption).

  • Transparenz
    Alle Informationen in einem Projekt müssen für alle sichtbar sein. Das erfordert allerdings auch, dass diese Aspekte eines Projektes nach einem gemeinsamen Standard definiert werden. Wir müssen u. a. ein gemeinsames Verständnis von einem fertigen Stück Software[2] haben.
  • Überprüfung
    Wir müssen regelmäßig den Fortschritt des Projektes in Bezug auf die Erreichung der Ziele überprüfen. Allerdings sollten diese Maßnahmen nicht so häufig erfolgen, dass sie die Arbeit behindert. Den größten Nutzen können wir daraus ziehen, wenn die Überprüfung gewissenhaft durchgeführt und dort vorgenommen wird, wo die Arbeit erbracht wird.
  • Anpassung
    Wenn ein Prüfer – oder eine andere beteiligte Person des Projektes – feststellt, dass bestimmte Aspekte des Projektes von akzeptablen Grenzwerten abweicht und damit möglicherweise das Projektziel nicht mehr erreicht wird, muss nachgesteuert werden. Die Anpassung muss so schnell wie möglich vorgenommen werden.


Mit den sogenannten Scrum-Werten wie Selbstverpflichtung, Mut, Focus, Offenheit und Respekt, kann das Scrum-Team die o. g. Säulen leben. Darüber hinaus wird dadurch Vertrauen im Team gebildet.

Scrum basiert weiterhin auf Rollen, Artefakte, und Rituale, die ich nachfolgend erläutern werde. Für einen ersten Überblick betrachten Sie bitte diese Abbildung.

Abbildung 14: Überblick über das Framework Scrum

[1] Der Scrum Guide kann in Deutsch heruntergeladen werden. [SCRUM GUIDE]

[2] Ich werde im Folgenden immer von einem Softwareentwicklungsprojekt ausgehen.

Ein Scrum-Team besteht aus genau drei Rollen: Product Owner, Scrum Master und Entwicklungsteam. Scrum-Teams sind selbstorganisiert und interdisziplinär. Ein Scrum-Team besteht aus max. elf Personen.

Im nächsten Abschnitt beschreibe ich die Rollen und werde ihre Verantwortlichkeiten während eines Projektes erläutern.

  • Product Owner (PO)
    • Der Product Owner ist die Person im Projekt, die für die Vertretung der Kundeninteressen verantwortlich ist. Er wird als der Vertreter des Kunden im Projekt verstanden.
    • Der PO hat die Autorität zu sagen, was im Endprodukt enthalten sein wird. Dabei ist es seine Aufgabe, sicherzustellen, dass die Anforderungen, die Funktionalität und die Prioritäten des Produkts verstanden und erreicht werden.
    • Der Product Owner ist eine einzelne Person, kein Komitee, die meistens Vollzeit in dieser Rolle arbeitet.
    • Die Aufgaben des Product Owners sind:
      • Product Backlog-Einträge[1] klar zu formulieren,
      • Einträge im Product Backlog so zu sortieren, dass die Projektziele optimal erreicht werden können,
      • sicherzustellen, dass das Product Backlog sichtbar, transparent und für alle klar ist sowie zeigt, woran das Scrum-Team als nächstes arbeiten wird,
      • sicherzustellen, dass das Entwicklungsteam die Product Backlog-Einträge im erforderlichen Maße versteht[2], und die
      • Abnahme der geleisteten Arbeit des Entwicklungsteams.
    • Scrum Master (SM)
      • Der Scrum Master ist dafür verantwortlich, dass das Scrum-Projekt entsprechen dem „Scrum Guide“ umgesetzt wird. Der Scrum Master erreicht dies, indem er alle Beteiligten hilft, die Scrum-Theorien, -Praktiken, -Regeln und -Werte zu verstehen. Der Scrum Master unterstützt zudem alle Stakeholder, die mit dem Projekt in Verbindung stehen.
      • Der Scrum Master ist ein Moderator, der u.a. für die Organisation der täglichen Besprechungen, die Verbesserung der Teaminteraktionen und die Maximierung der Produktivität verantwortlich ist.
      • Die Aufgaben des Scrum Masters zur Unterstützung des Product Owners:
        • sicherstellen, dass Ziele, Umfang und Produkt von allen im Scrum-Team so gut wie möglich verstanden werden,
        • vermitteln von Techniken für eine effektive Verwaltung des Product Backlogs,
        • vermitteln eines Verständnisses für die Notwendigkeit klarer, prägnanter Product Backlog-Einträge,
        • schaffen eines Verständnisses für Produktplanung in einem empirischen Arbeitsumfeld,
        • sicherstellen, dass der Product Owner weiß, wie er das Product Backlog so anordnet, dass es den größten Wert erzeugt,
        • vermitteln des richtigen Verständnisses von Agilität und ihrer Anwendung und die
        • Unterstützung bei der Durchführung von Scrum-Ereignissen bei Bedarf oder auf Anfrage.
      • Die Aufgaben des Scrum Masters zur Unterstützung des Entwicklungsteams:
        • coachen des Entwicklungsteams hin zu Selbstorganisation und funktionsübergreifender Teamarbeit,
        • unterstützen des Entwicklungsteams bei der Schaffung hochwertiger Produkte,
        • beseitigen von Hindernissen, die das Entwicklungsteam aufhalten,
        • unterstützen bei der Durchführung von Scrum-Ereignissen bei Bedarf oder auf Anfrage,
        • coachen des Entwicklungsteams in Organisationen, in denen Scrum noch nicht vollständig angenommen und verstanden wird.
      • Darüber hinaus hat der Scrum Master, da er meist als 1/3-Stelle belastet ist, Aufgaben für die Organisationsentwicklung zu leisten:
        • leiten und coachen der Organisation bei der Einführung von Scrum,
        • planen von Scrum-Implementierungen innerhalb der Organisation,
        • unterstützen von Kollegen und Stakeholdern, Scrum und empirische Produktentwicklung zu verstehen und umzusetzen,
        • auslösen von Veränderungen zur Produktivitätssteigerung des Teams sowie die
        • Zusammenarbeit mit anderen Scrum Mastern, um die Effektivität von Scrum-Implementierungen innerhalb der Organisation zu verbessern[3].
      • Der Unterschied zwischen Projektmanager und Scrum Master besteht darin, dass die Definition des Scrum Master ausschließlich darauf ausgerichtet ist, ein dienender Führer (engl. servant leader[4]) zu sein.
      • Wenn der Scrum Master verstärkt für die Organisation arbeitet, wird er manchmal als Agile Coach bezeichnet.
    • Das Entwicklungsteam[5]
      • Im Entwicklungsteam sind alle Personen enthalten, die für das Design, die Produktion, das Testen und die Freigabe des Endprodukts erforderlich sind. Das Entwicklungsteam besteht aus Profis, die am Ende eines jeden Sprints ein fertiges Inkrement übergeben, welches potenziell (d.h. aber nicht, dass nach jeder Iteration tatsächlich ausgeliefert wird) auslieferbar ist.
      • Das Entwicklungsteam organisiert die Arbeit selbst und managt auch die eigenen Prozesse. Durch die Selbstorganisation wird die Effizienz des Teams verstärkt. Die optimale Größe des Teams ist „…klein genug, um flink zu bleiben und groß genug, um bedeutende Arbeit innerhalb eines Sprints erledigen zu können.“[6] In Zahlen bedeutet dies, dass das Entwicklungsteam eine ideale Größe von fünf – sieben Mitglieder hat.
      • Entwicklungsteams weisen folgende Eigenschaften auf:
        • Sie sind selbstorganisierend. Niemand sagt dem Entwicklungsteam, wie es aus dem Product Backlog potenziell auslieferbare Funktionalität erzeugen soll,
        • Entwicklungsteams sind interdisziplinär,
        • Scrum kennt für Mitglieder des Entwicklungsteams keine Titel oder Hierarchien, sie heißen alle Entwickler,
        • Einzelne Mitglieder des Entwicklungsteams können zwar spezialisierte Fähigkeiten oder Spezialgebiete haben, aber die Rechenschaftspflicht obliegt dem Team als Ganzes[7].

[1] Erklärung s. Kapitel 8.3

[2] [SCRUM GUIDE], Seite 6

[3] [SCRUM GUIDE], Seite 7 ff

[4] [WIKIPEDIA], Servant Leadership

[5] Synonym auch als Entwicklerteam und in Englisch als Developmentteam bezeichnet

[6] [SCRUM GUIDE], Seite 7

[7] [SCRUM GUIDE], Seite 7

In Scrum gibt es vorgeschriebene Ereignisse, sogenannte Rituale. Mit ihnen soll eine Regelmäßigkeit erzeugt, aber auch die Menge an Meetings reduziert werden. Scrum-Rituale sind befristet (engl. time-boxed); jedes Ritual hat eine maximale Dauer. Weichen Sie von den Zeitvorgaben ab, sowohl nach oben als auch nach unten, erfüllen die Meetings nicht die Scrum-konformen Ideen.

Die Hauptereignisse in Scrum sind die Iterationen. Sie werden Sprints genannt. Ein Regelsprint kann zwei bis vier Wochen lang sein. Es gibt aber auch Sondersprints von einer Woche. Wie lange die Regeliteration dauern soll wird vor dem Projekt oder beim Projektstart durch das Entwicklungsteam bestimmt. Es ist nicht sinnvoll, die Länge des Sprints während eines Projektes zu verändern.

Beispiel Scrum-Meeting

Ein mit Scrum neu startendes Team hat einen Product Owner, einen Scrum Master und sieben Entwicklungsteammitglieder.

Das Entwicklungsteam bestimmt, dass in diesem Projekt die Dauer des Sprints vier Wochen betragen soll. Auf den prozessbezogenen Hinweis des Scrum Masters, wann übergreifende Tests stattfinden sollen, beschließt das Entwicklerteam vor jeder Auslieferung einen gesonderten 1-wöchigen Sprint einzufügen.

Der Product Owner sitzt still bei dieser Besprechung dabei. Die Bestimmung von Sprintlängen gehört nicht zu seinem Aufgabenbereich.

Die immer gleichen Rituale des Sprints sind die Sprintplanung, die Daily Scrums, die Entwicklungsarbeit selbst so wie das Sprint Review Meeting und die Sprint Retrospektive.

Häufig wird diskutiert, ob Sprints abgebrochen werden können. Sprints dürfen nur abgebrochen werden, wenn das Sprintziel obsolet ist. Diese Entscheidung trifft ausschließlich der Product Owner. Ein Sprintabbruch stellt ein höchst seltenes Ereignis dar.

Betrachten wir die einzelnen Rituale.

  • Sprintplanungs-Meeting[1]
    • Im Meeting der Sprintplanung, das am ersten Tag eines jeden Sprints durchgeführt wird, wird die kommende Arbeit des Sprints geplant. Wir brauchen pro Sprint-Woche jeweils zwei Stunden Planung. Das bedeutet, dass bei einem vier Wochen Sprint, das Sprintplanungs-Meeting einen kompletten, acht-stündigen Tag dauert.
    • Der Scrum Master lädt zu diesem Meeting ein, moderiert das Ritual und sorgt dafür, dass die Teilnehmer fokussiert dem Thema des Meetings folgen.
    • Der Ablauf des Sprintplanungs-Meetings ist zweigeteilt. Zuerst beschreibt der Product Owner, was im Sprint erreicht werden soll und welche Product Backlog-Einträge diese Ideen unterstützen. Aufgrund von z. B. technischen Abhängigkeiten diskutiert das Entwicklungsteam, welche weiteren Aspekte für das Sprintziel aufgenommen werden sollten – gemeinsam wird dann das Ziel des Sprints[2]
    • Danach plant das Entwicklerteam eigenständig die Umsetzung und die damit verbundenen Arbeiten. Der Product Owner bleibt weiterhin im Meeting, um Fragen des Entwicklerteams zum besseren Verständnis der Arbeit beantworten zu können. Am Ende des Planungsmeetings sollte das Entwicklungsteam befähigt sein, Produkt Owner und Scrum Master zu schildern, wie es die Sprintziele umsetzen wird.
    • Basierend aus der Auswahl der Anforderung für den Sprint, wird das Entwicklungsteam schätzen, ob die Arbeit zu schaffen ist. Über das Thema „Schätzen“ diskutieren wir später im Buch.

 

Ab dem zweiten Tag des Sprints erfolgt die Umsetzung der Anforderungen durch das Entwicklerteam. Das tägliche Ritual dieses Umsetzungszeitraum heißt Daily Scrum.

  • Daily Scrum
    • Es wird erwartet, dass sich das Entwicklungsteam jeden Tag trifft. Diese Sitzungen werden Daily Scrum (manchmal Daily Stand-Up) genannt und dauern in der Regel nur 15 Minuten. Es ist das Meeting, indem sich die Entwicklungsteam-Mitglieder gegenseitig über den aktuellen Stand ihrer Arbeit informieren.
    • Der Scrum Master nimmt als Moderator teil, der Product Owner sollte mit dabei sein. Wobei hier besonders zu beachten ist, dass der Product Owner kein aktives Sprechrecht hat.
    • Die „berühmten“ drei Fragen, die das Entwicklerteam sich gegeneinander beantworten soll, sind:
      • Was habe ich gestern getan, dass dem Entwicklungsteam geholfen hat, das Sprintziel zu erreichen?
      • Was werde ich heute erledigen, um dem Entwicklungsteam zum Erreichen des Sprintziel zu helfen?
      • Sehe ich irgendein Hindernis, dass mich oder das Entwicklungsteam daran hindert, das Sprintziel zu erreichen?[3]
    • Sollte in der dritten Frage Aspekte auftauchen, die das Entwicklungsteam hemmt, effizient zu arbeiten, ist der Scrum Master aufgefordert diese Hemmnisse (engl. Impediments) im Impediment Backlog zu notieren. Es ist die Aufgabe des Scrum Masters die Hemmnisse beiseite zu räumen, im besten Fall bis zum nächsten Daily Scrum. Manchmal sind Hemmnisse so dramatisch, dass sie erst zum nächsten Sprint oder gar nächsten Projekt beseitigt werden können.
    • Der Daily Scrum soll insbesondere in der Anfangszeit eines Projektes oder in der Einführungszeit von Scrum immer am gleichen Ort und zur selben Zeit stattfinden.
  • Sprint Review
    • Zum Ende eines Sprints wird ein Sprint Review-Meeting abgehalten, um das Inkrement zu überprüfen und die Arbeit das Entwicklungsteams abzunehmen. In diesem Meeting beschäftigen sich das Scrum-Team und der Kunde gemeinsam mit den Ergebnissen des Sprints.
    • Der Kunde wird bewusst zu diesem Meeting eingeladen, damit er direkt und unverblümt Feedback geben kann. Außerdem fallen dem Kunden häufig neue Anforderungen ein, wenn er bereits fertige Arbeit präsentiert bekommt.
    • Bisher wurde das Sprint Review-Meeting vor allem als Abnahmemeeting verstanden. Der Product Owner hat die Arbeit des Entwicklungsteams während des Sprints abgenommen. Mittlerweile hat dieses Meeting aber auch andere Aufgaben, z. B. soll der Product Owner eine Vorhersage über aktuelle Liefertermine machen. Als Input für den nächsten Sprint wird auch im Review-Meeting über die nächsten Sprintziele gesprochen.
    • Das Meeting soll maximal 4 Stunden dauern, d. h. pro Sprint-Woche eine Stunde.
  • Sprint Restrospektive
    • Die Sprint Retrospektive als letztes Ritual eines jeden Sprints, bietet dem Scrum-Team die Gelegenheit, sich selbst zu überprüfen und Verbesserung für die kommenden Sprints zu beschließen.
    • Das Ritual dient zur Selbstreflektion des gesamten Teams.

Exkurs: Entwicklungsgeschwindigkeit (Velocity)

Die Entwicklungsgeschwindigkeit dokumentiert die Menge an Funktionalität[1], die am Ende des Sprints vom Product Owner abgenommenen wurde und wird in Story Points gemessen.

Ziel ist es eine konstante Entwicklungsgeschwindigkeit für das Team zu erreichen. Voraussetzung dafür ist, dass die zugesicherten Ressourcen auch tatsächlich zur Verfügung stehen. Es darf also z. B. nicht vorkommen, dass ein Entwicklungsteam-Mitglied für einen Tag in den Support berufen wird. Wenn dieses Teammitglied nicht im Projekt arbeitet kann und damit auch keine Anforderungen erledigen wird, wird dieser Mitarbeiter damit auch nicht in der Velocity aufgeführt. Eine konstante Entwicklungsgeschwindigkeit kann nicht erreicht werden.

Dabei ist zu beachten, dass teilweise fertiggestellte Arbeitsergebnisse nicht abgenommen werden und damit nicht zur Velocity zählen.

[1] Der Begriff der Funktionalität ist technischer als Anforderung. Er wird aber häufig benutzt, ähnlich wie Feature.

[1] Bei Scrum wird häufig der englische Begriff „Sprint Planning“ benutzt.

[2] Das Sprintziel ist der übergeordnete Zweck für den Sprint, der durch die Umsetzung bestimmter Product Backlog-Einträge erreicht wird.

[3] [SCRUM GUIDE], Seite 12

Scrum Artefakte repräsentieren die geleistete Arbeit bzw. den erstellten Wert. Sie dienen, um Transparenz und die Möglichkeit zur Überprüfung und Anpassung zu schaffen. Die Artefakte sind so definiert, dass sie auf sehr einfache und konzentrierte Art Informationen weitergeben.

  • Product Backlog
    • Das Product Backlog ist eine geordnete Liste von Aufgaben und Anforderungen, die in das Endprodukt aufgenommen werden müssen. Es ist die einzige Anforderungsquelle für alle Änderungen am Produkt. Es liegt in der Verantwortung des Product Owners, das Backlog zu erstellen und zu verwalten bzw. das Backlog zu aktualisieren.
    • Das Product Backlog ist niemals vollständig; es können jederzeit neue Anforderungen und Aufgaben hinzukommen. Wir sprechen von einem „lebenden“ Dokument.
    • Die einfachste Darstellung des Produkte Backlogs ist es eine Liste mit Moderatorenkarten, die Sie an eine Bürowand zu heften. Alternativ ist eine einfache „Excel“-Liste ausreichend[1].
    • Das Product Backlog wird vor dem Start das ersten Sprints mit allen Informationen, die bis dahin gesammelt worden sind, gefüllt. Das sog. Refinement (dt. Verfeinerung) erfolgt später jeweils ab der Mitte des aktuellen Sprints und muss vor dem ersten Tag des nächsten Sprints fertig sein.
    • Folgende Informationen sollten im Product Backlog enthalten sein:
      • Information zur Anforderung,
      • die Schätzung über die bevorstehende Arbeit und
      • Akzeptanzkriterien.
    • Das Product Backlog soll so geordnet sein, dass Einträge, die oben stehen als die für den nächsten Sprint besonders wichtigen Anforderung erkannt werden. Diese Beschreibungen müssen besonders detailliert sein, damit das Entwicklungsteam versteht, was der Kunde will.
    • Um das zu vereinfachen verwenden wir Epics (dt. Epik), User Stories (dt. Benutzergeschichten) und Themen.

Exkurs: Epics und User Story

Eine Benutzergeschichte ist (einfach ausgedrückt) etwas, das ein Benutzer, Anwender bzw. Stakeholder will. Es ist eine Beschreibung der Ergebnisse, die der Kunde wünscht.

Im Idealfall ist eine Benutzergeschichte klein genug, um in einen Sprint zu passen.

Mit dem User Story-Template wird die Kommunikation im Team einfacher. Wir stehen vor der Problematik, dass der Produkt Owner nicht die Sprache des Entwicklungsteam spricht[2], trotzdem muss das Entwicklungsteam die Anforderung verstehen.

Das User Story-Template sorgt für eine standardisierte, einfache Beschreibung einer Anforderung. Das Template verlangt drei Aussagen:

Abbildung 15: User Story-Template

Unter „Wer“ wird eine bestimmte Rolle verstanden. Das kann ein Software-Administrator, der Hausmeister oder ein Anwender; jemand, der später mit dem Produkt arbeiten wird.

Das „Was“ ist die Tätigkeit, die der Anwender ausführen möchte. Der Hausmeister möchte Licht anmachen in einem Raum. Damit sind das „Wer“ und das „Was“ beschrieben. Allerdings könnte es sein, dass in diesem Raum mehrere Beleuchtungskreise errichtet worden sind.

Daher stellt sich als nächstes die Frage, „Warum“ braucht der Hausmeister Licht? Der Hausmeister braucht Licht, um den gesamten Raum auszuleuchten. Wenn ein Dozent in einem Schulungsraum Licht macht, könnte er dagegen möglicherweise nur das Licht über seinen Trainerschreibtisch haben wollen.

Zusammengefasst heißt die User Story jetzt: „Der Hausmeister möchte Licht machen in einem Raum, um den gesamten Raum auszuleuchten“.

Im vorherigen Absatz habe ich beschrieben, dass ein Product Backlog-Eintrag mit Akzeptanzkriterien versehen sein kann. Um unsere User Story zu komplettieren, könnten wir das Akzeptanzkriterium „3000 Lumen und warmweiß“ hinzufügen. Damit weiß das Entwicklungsteam (in diesem Beispiel vermutlich Bauleute), welche Art von Leuchtmittel verbaut werden sollen.

Was aber, wenn eine Iteration acht Wochen dauern wird? Das bedeutet, dass die Benutzergeschichte zu groß ist, um sie in einem Sprint erfolgreich zu bewältigen. Daher nennen wir diese Anforderung eine große Benutzergeschichte bzw. Epik. Für Epen gibt es keine genaue Größenvorgabe, aber der Detaillierungsgrad ist gering. Epen befinden sich immer am unteren Ende des Product Backlogs.

Eine weitere wichtige Definition, die es zu verstehen gilt, sind Themen. Ein Thema ist eine Sammlung von Benutzergeschichten, die miteinander in Beziehung stehen oder leicht gruppiert werden können.

Story, Epik und Thema sind Begriffe, die viele agile Teams verwenden, um Diskussionen und Planungen über das Projekt zu vereinfachen. So kann es beispielsweise vorkommen, dass im Product Backlog eine Anforderung dokumentiert ist, die zu groß ist, um sie einem einzigen Sprint zuzuordnen. Werden diese als Epik bezeichnet, versteht jeder, dass es erst einmal aufgeschlüsselt werden muss, bevor die Umsetzung Teil eines Sprints werden kann.

Beispiel einer User Story

Beim Bau eines Eigenheims ist die Anforderung „Wir brauchen Licht im Haus“ ein Epic. Wird eine Anforderung verfeinert wie „Im Schlafzimmer brauche ich 2 Lampen über den Nachtschränkchen“, handelt es sich um eine User Story. Ein Thema ist nun das Sammeln der User Stories mit dem Inhalt „Wo werden Lampen gebraucht?“.

  • Sprint Backlog
    • Im Sprint Backlog finden wir die Anforderungen (wir sagen jetzt genauer die User Stories), die für den aktuellen Sprint vorgesehen sind. Das Sprint Backlog macht damit die gesamte Arbeit für das Team, aber auch für die Stakeholder sichtbar.
    • Um gut abschätzen zu können, wieviel User Stories wir in den Sprint Backlog aufnehmen können, muss die Arbeit geschätzt werden. Wir benutzen dazu das agile Schätzen mit der Fibonacci-Reihe.
    • Während des Sprints werden die Einträge der Sprint Backlogs abgearbeitet. Die Reihenfolge der Bearbeitung überlassen wir dem Entwicklungsteam. Wir können allerdings jeden Tag feststellen, wieviel Arbeit noch bis zum Sprintende verbleibt und damit abschätzen, ob wir unsere Sprintziele erreicht werden.
    • Manchmal kommt es sogar vor, dass wir schneller sind als unsere Planung vorgesehen hat, dann ist es möglich, durch Absprachen zwischen dem Entwicklungsteam und dem Product Owner weitere Anforderungen bzw. User Stories in den Sprint aufzunehmen.
    • Bitte beachten Sie allerdings, dass es keine Spontan-Tätigkeiten wie „Kannst du mal schnell …“ geben darf. Anforderungen an das Projekt dürfen nur über das Produkt Backlog in das Projekt aufgenommen werden.


Exkurs: Agiles Schätzen

Das Schätzen ist ein wichtiger Bestandteil des Projektmanagement, übrigens nicht nur agiler Projekte. Agiles Schätzen hat allerdings einige Besonderheiten, auf die wir eingehen werden.

Eine agile Schätzung basiert nicht nur auf den reinen Aufwand an Arbeit, der getan werden muss, sondern auf die Komplexität der Anforderung. Darum ist es so notwendig, dass unser Entwicklungsteam funktionsübergreifend (engl. crossfunctional) aufgestellt ist. Damit erhalten wir bei einer Programmieraufgabe nicht nur die Überlegung wie komplex das Codieren ist, sondern es fließen auch Überlegungen zum Thema Testen oder Dokumentation ein.

Solange nur eine Person eine Aufgabe bearbeitet, wäre eine Schätzung in Stunden relativ einfach. Durch die Zusammenarbeit des gesamten Teams an einer einzelnen User Story wird es schwieriger. Hier kommt das agile Schätzen zum Tragen.

Das agile Schätzen basiert auf einigen Grundprinzipien:

  • Geschwindigkeit
    Der Schätzvorgang selbst soll relativ schnell durchgeführt werden
  • Zusammenarbeit
    Agiles Schätzen basiert auf einer gemeinsamen Zusammenarbeit; das Team schätzt gemeinsam. Abweichungen bei der Schätzung sind vorteilhaft, weil sie möglicherweise Denkanstöße liefern.
  • Relatives schätzen
    Unsere Schätzungen fußen nicht auf einen absoluten Aufwand, sondern setzen die zu schätzende Aufgabe in Relation zu einem vorher bestimmten Referenzwert. Wenn wir wissen, wie lange die Referenz dauert, können wir vergleichen wie lange die zu schätzende Aufgabe dauern wird. Wobei es nicht wichtig ist, diese Schätzung auf Stunden- oder sogar auf Minutenbasis durchzuführen. Das unterscheidet Schätzung von Kalkulation.
  • Konstanz
    Die Komplexität der Anforderung verändert sich nicht zum Ende der Arbeit hin. Wir dürfen nicht den Fehler machen, falls die Zeit nicht reicht, Dinge zu vereinfachen.
  • Objektivität
    Es geht um die zu erledigende Aufgaben, nicht um die Menschen, die diese Aufgaben erfüllen.
  • Vertrauen in das Team
    Das Team wird bei der korrekten Anwendung der Methode die richtigen Schätzungen richtig durchführen.


Für Scrum hat sich das Planning Poker als die sinnvollste Methode für das agile Schätzen durchgesetzt. Tatsächlich benutzen wir Pokerkarten, auf den allerdings die Fibonacci-Folge[3] aufgedruckt ist. Die Fibonacci-Folge addiert immer die beiden vorhergehenden Zahlen, um die nächste Zahl der Folge darzustellen. Die Reihenfolge beim Planning Poker ergibt sich daher: 1, 2,3, 5, 8, 13. Das heißt wenn ich einen Aufwand von 13 habe, ist er 13-mal größer als bei einem Aufwand von 1.

Vielleicht können Sie sich vorstellen, dass diese Größenordnung nicht mehr zu einer User Story passt; daher habe ich die Reihe bei 13 abgebrochen. Wenn Sie einen Planning Poker-Kartensatz erwerben, werden darin auch noch andere, höhere Karten dabei sein.

Wie ist der Ablauf des Planning Pokers? Das Entwicklungsteam (und nur das Entwicklungsteam) arbeiten User Story für User Story ab, brechen häufig die User Stories in einzelne Task runter und schätzen dann die einzelnen Tasks. Das Aufbrechen der User Stories in kleinere Einheit ist deshalb sinnvoll, weil wir dann noch besser die Komplexität der einzelnen Anforderungen verstehen können.

Bevor die Schätzung für die einzelnen User Stories beziehungsweise Task beginnt, brauchen wir einen Referenzwert. Dieser Referenzwert wird basiert auf einer Aufgabe, die alle Teammitglieder durchschauen und schätzen können. Diese Aufgabe sollte so klein sein, dass sie mit dem Referenzwert 1 belegt werden kann.

Nachdem ein Referenzwert geschaffen ist, können wir mit unserer Schätzung der User Stories für den aktuellen Sprint fortfahren.

Jedes Entwicklungsteam-Mitglied hat einen Kartensatz und überlegt sich zur aktuellen User Story bzw. zum aktuellen Task, wie groß die Komplexität in Relation zum Referenzwert ist.

Jedes Entwicklungsteam-Mitglied legt verdeckt die Karte vor sich auf den Tisch. Wenn alle Mitglieder eine Entscheidung getroffen haben, werden die Karten umgedreht. Zumeist ergibt sich eine Zahlenwolke um einen bestimmten Wert herum. Es gibt aber auch immer wieder Ausreißer. Diese Ausreißer müssen ihre Gedanken als nächstes erklären, möglicherweise haben nämlich die anderen Mitglieder Dinge wie Arbeitsschritte, Materialien oder Personen übersehen. Mit dem neuen Erkenntnisstand wird eine nächste Runde eingeläutet. Die Schätzung wird so lange durchgeführt bis sie einen gemeinsam akzeptierten Wert ergibt.

Neben dem Planning Poker gibt es auch andere Methoden, die Sie in der Literatur finden werden. Gerne wird statt mit der Fibonacci-Reihe auch im T-Shirt Größen geschätzt. Der Vorteil hierbei ist es, das T-Shirts Größen eine sehr geläufige Größe in unserem Leben sind.

  • Inkrement
    • Das (Software-) Inkrement ist das Ergebnis aller fertigen User Stories in einem Sprint. Das Inkrement wächst von Sprint zu Sprit. Das Inkrement ist getestet und dokumentiert und potenziell auslieferbar.
  • Definition of Done
    • Die Definition of Done (dt. Vereinbarung über den Zustand „fertig“, DoD) ist ein Dokument, das am Anfang des Projektes erstellt wird.
    • Die DoD gibt ein gemeinsames Verständnis davon wieder, wann eine User Story bzw. ein Task als fertig zu bezeichnen ist. Es reicht nicht aus, dass die Software programmiert ist, sondern sie muss getestet und dokumentiert[4]
    • Im „Scrum Guide“ sind leider keine Anleitungngen dabei, die beschreiben wie getestet und wie dokumentiert werden musss. Im nächsten Kapitel werde ich Ihnen einige Tools an die Hand geben.
    • Bei der Einführung von Scrum wird die Definition of Done noch wenige Einträge beinhalten. Je länger Teams nach Scrum arbeiten, desto „fetter“ wird die Vereinbarung. Mögliche Einträge könnten sein:
      • Unit Tests sind durchgeführt
      • Dokumentation ist aktualisiert
      • Codekonventionen eingehalten
      • Stabile Code Basis ist geschaffen
      • Keine bekannten Fehler vorhanden
      • Von Kollegen durchgelesen
    • Task Board
      • Das Task Board ist eine einfache Methode, um den Projektfortschritt zu visualisieren. Es lässt sich an einer Wand montieren oder ist möglicherweise sogar eine Kartenwand.
      • Das Task Board hat drei Spalten: in Planung, in Arbeit und fertig. Am Anfang eines Sprints werden alle Task in die linke Spalte mit Post-its geklebt. Sobald ein Entwicklungsteam-Mitglied einen Task beginnt, klebt er diesen in die mittlere Spalte und ist er fertig, wird sie in die letzte Spalte weitergeleitet.

Abbildung 16: Task Board mit Tasks

  • Weitere Artefakte
    • Über die Arbeitsergebnisse des Review Meetings und der Retrospektive lässt sich der „Scrum Guide“ nicht aus. Für uns bedeutet das, dass wir als Ergebnisse dieser beiden Meetings „normale“ Protokolle erstellen.
    • Manchmal werden auch das Burndown-Chart und andere Graphiken als Scrum Artefakte bezeichnet.
    • Graphiken werden im Umfeld von Scrum sehr einfach gehalten, da sie zum Teil täglich aktualisiert werden müssen. Außerdem müssen diese öffentlich aushängenden Graphiken von allen gleich verstanden werden.
    • Burndown-Chart
      • Das am häufigsten benutzte Chart ist das Burndown-Chart. Es zeigt die verbleibende Menge an Arbeit – in Story Points ausgedrückt – im Sprint an.
      • Wird die Graphik skaliert, kann man das Verhältnis von Story Points, die in den Sprints erzielt wurden und dem Projektergebnis ablesen.

Abbildung 17: Burndown-Chart

  • Parkplatzdiagramm
    • Das Parkplatzdiagramm stellt den Bearbeitungszustand von Themen dar. Diese Form des Diagramm lässt sich bei der Kommunikation mit dem Kunden nutzen. Es werden keine Details transportiert, sondern der Gesamtzustand des Projektes.

Bild 18: Parkplatzdiagramm mit Beispiel-Themen

Beispiel: Referenzwert festlegen

In meinen Trainings mache ich folgende Übung. Ich habe eine Shoutbox (das ist ein Lautsprecher für PCs), der über USB-Port angeschlossen werden kann. Ich stelle die Frage, wie lange wird der Anschluss dieser Shoutbox dauern? Die Teilnehmer geben ihre Schätzung ab, weil sie ein bestimmtes Bild vor Augen haben, was jetzt passiert. Selbst dabei stellt sich heraus, dass die Teilnehmer sehr unterschiedliche Bilder vor Augen haben, die zuerst diskutiert werden müssen. Am Ende der Diskussion haben alle ein gemeinsames Bild und einigen sich auf eine Zeit von einer Minute. Mein nächstes Szenario ist dann der Anschluss eines Druckers an einem PC. Jetzt sollen die Teilnehmer schätzen, ob der Aufwand bzw. die Komplexität des Anschlusses eines Druckers gleich groß, kleiner oder größer als der Anschluss einer Shoutbox ist. Es folgen Aussagen wie „das geht genauso schnell, ist ja auch USB“ bis hin zu „das muss ja länger dauern, da wir noch Papier einlegen müssen“. Nachdem wir uns darüber geeinigt haben, ob es sich um ein Tintenstrahl- oder Laserdrucker handelt, wissen wir z. B. auch noch, dass wir Verbrauchsmaterialien hinzufügen müssen. Normalerweise ist sogar notwendig, sowohl Strom- als auch Kommunikationskabel per Hand anzuschließen.

Nachdem nun dieses Szenario für alle gleich ist, wird nochmals geschätzt. Im Vergleich zum Anschluss der Shoutbox mit dem Referenzwert 1, kommen jetzt die Teilnehmer auf Werte, die doppelt so hoch (vielleicht aber auch dreimal so hoch) sind.

[1] Wenn Sie an dieser Stelle schon beginnen über Software zur Unterstützung nachzudenken, gehen Sie bitte wieder auf den Anfang des Teil 3 zurück und schauen sich die Werte von Agile und Scrum nochmals an.

[2] Der Product Owner ist für den Businessteil verantwortlich und spricht damit eher in einer Business-Sprache.

[3] [WIKIPEDIA], Fibunacci-Folge

[4] [SCRUM GUIDE], Seite18

Sie haben sicherlich erkannt, das Scrum vor allem für kleine Projekte geeignet ist, die lokal organisiert sind, aus einem Team mit rund neun Personen besteht und die Kommunikation direkt Face-to-Face erfolgt.

Am Ende des „Scrum Guides“[1] steht folgendes:

„Die Rollen, Artefakte, Ereignisse und Regeln von Scrum sind unveränderlich. Es ist zwar möglich, nur Teile von Scrum einzusetzen – das Ergebnis ist dann aber nicht Scrum.“

Häufig sind Projekte aber größer als die, für die Scrum vor 20 Jahren entwickelt worden ist. Daher gibt es unterschiedliche Möglichkeiten, Scrum so zu skalieren, dass wir mit mehreren Teams arbeiten können. Die einfachste Skalierung ist die Einführung eines zweiten Scrum-Teams, das

  • einen eigenen Scrum Master und einen eigenen Product Owner hat,
  • weiterhin selbst organisiert und autark agiert,
  • ein gemeinsames Definition of Done mit dem ersten Team hat und
  • an einem gemeinsamen Product Backlog arbeitet.


Somit sind alle Teams selbständig agierend, brauchen aber ein Gremium, um die Aktivitäten der Teams zu organisieren. Dazu dient das Meeting Scrum-of-Scrum. Das Scrum-of-Scrum ist ein tägliches Meeting, in dem jeweils ein Vertreter der einzelnen Teams dabei ist. Die darin diskutierten Fragen sind denen des Daily Scrum sehr ähnlich, sind aber auf Teamebene angehoben.

Für normal große Projekte reicht diese Skalierung völlig aus. Werden Ihre Projekte größer, müssen Sie sich mit anderen auf Scrum aufbauenden Systemen auseinandersetzen. Die bekanntesten Methoden sind Large-Scale Scrum (LeSS)[2] und Scaled Agile Framework (SAFe)[3].

Exkurs: Agilität in bekannten Unternehmen

Agilität wird von einer wachsenden Zahl großer und kleiner Unternehmen in allen Branchen eingesetzt. Während die technischen Branchen immer noch der am häufigsten verwendete Industriezweig für Agilität ist, nutzen auch Unternehmen aus den Bereichen Finanzen, Dienstleistungen, Versicherungen, Regierung und vielen anderen Sektoren agile Methoden.

Zu den bekannteren Unternehmen, die agile Methode anwenden, gehören:

  • Amazon
    Eine Form von Agilität war bei Amazon bereits 1999 vorhanden, aber erst im Zeitraum von 2004–2009 erreichte die Organisation die weit verbreitete Einführung von Scrum.
  • Cisco
    Cisco, ein typischer Hardwarehersteller, hat Agilität im Jahr 2015 eingeführt, um Mängel zu reduzieren, Überstunden der Mitarbeiter zu verringern und die Lieferzeiten der Produkte zu verbessern.
  • Google
    Google ist eines der führenden Unternehmen, das Scrum einsetzt. Das Unternehmen hat viele Anwendungen wie „Gmail“, „Google Maps“, „Google Calendar“ usw., die alle regelmäßig aktualisiert werden müssen. Um die Aktualisierung, das Testen und die Veröffentlichung so vieler Produkte schnell und konsistent zu bewältigen, hat Google das Scrum-Framework übernommen.
  • Lego
    Lego hat bereits 2015 das agile Framework eingeführt, um die Kommunikation, den Fokus und die Produktivität zu verbessern. Es half ihnen, genauere Schätzungen zu erreichen, die Dokumentation zu reduzieren und effizienter zu werden.
  • Netflix
    Netflix ist ein großartiges Beispiel für eines der Unternehmen, die agile Projektmanagement nutzen, um innovativ zu bleiben und der Konkurrenz voraus zu sein. Netflix nutzt Agilität, um schnell und konsistent Inhalte für demografischen Gruppen bereitzustellen.
  • Microsoft
    Microsoft verwendet Agilität sowohl für kleine als auch für große Unternehmensprojekte. MS implementierte zunächst ein Agilitätsmodell in kleinem Maßstab und lernte dann, wie es für größere Projekte und Lösungen skaliert und modifiziert werden kann.
  • Spotify
    Spotify hat die agilen Softwareentwicklungspraktiken übernommen, um mit großen, gut etablierten Unternehmen wie Apple, Google und Amazon überhaupt konkurrieren zu können.

[1] [SCRUM GUIDE], Seite 19

[2] [LESS]

[3] [SAFe]

Kapitel 9: Agile Tools & Techniken

Im Kapitel 9 möchte ich Ihnen einige bewährte agile Werkzeuge und Techniken vorstellen. Die Reihe ist willkürlich und stellt keine Priorisierung hinsichtlich der Wichtigkeit da. Sie soll Ihnen helfen, das, was Sie bisher über das Agile Manifest und Scrum kennengelernt haben, in der Praxis anzuwenden.

Es gibt mehrere Ebenen, auf denen wir unsere Arbeit priorisieren müssen:

  • Sprint (was wir im nächsten Sprint arbeiten wollen) und
  • Release (was wir an den Kunden ausliefern wollen).


Da wir in Scrum vor allem gedanklich die Erstellung von Software begleiten, ist es möglich zu priorisieren, welche Softwarestückchen oder Features zuerst ausgeliefert werden sollen.

MoSCoW-Priorisierung

Die Priorisierung für die Releases eines Softwareprojektes erfolgt mit MoSCoW (M = Must, S= Should, Co = Could, W = Won´t).

Für eine gute Planung ist es wichtig, zu wissen, welche User Stories für den nächsten bzw. übernächsten Release (der sog. Planungshorizont) vorgesehen sind.

Mit MoSCoW unterscheiden wir die User Stories, die unbedingt im nächsten Release ausgeliefert werden müssen und die User Stories, die eine hohe Relevanz haben und ausgeliefert werden sollten. Der Rest eignet sich für eine spätere Auslieferung.

Die Graphik zeigt oberhalb der Linie die aktuelle wichtigen Anforderungen und darunter die weniger wichtigen. Mit diesem einfachen Tool halten wir sehr leicht die Releaseplanung unter Kontrolle und haben eine flexible Unterstützung in der Planung.

Abbildung 18: MoSCoW-Priorisierung

INVEST

Um leichter abschätzen zu können, wann wir welche User Story bearbeiten können, ist es sinnvoll, die User Stories so zu definieren, dass sie bestimmte Kriterien erfüllen. Neben der Priorisierung hilft uns INVEST später auch bei der Schätzung von User Stories bzw. Task.

INVEST ist ein Akronym und steht für die folgenden sechs Begriffe:

  • Independent (unabhängig)
    in beliebiger Reihenfolge (besser: nach Geschäftswert umsetzbar)
  • Negotiable (verhandelbar)
    Verhandlungsspielraum für die Sprintplanungssitzung, um maximale Produktivität zu erzielen
  • Valuable (nützlich)
    Der Nutzen muss klar erkennbar sein
  • Estimatable (schätzbar)
    Anforderungen sind so klar formuliert, dass der Aufwand schätzbar ist
  • Small (klein)
    Möglichst einheitlich kleine Anforderungen formulieren, die im Sprint fertiggestellt werden können
  • Testable (testbar)
    Messbare Akzeptanzkriterien sollten formuliert werden

Warum beschäftigen wir uns eigentlich mit Scrum bzw. mit der Veränderung unserer aktuellen Arbeitsprozesse?

Möglicherweise stellen wir fest, dass unsere Arbeitsprozesse nicht mehr das Ergebnis schaffen, das wir benötigen, um am Markt weiter zu bestehen.

ADAPT

Diese Ausgangssituation gibt uns die Möglichkeit darüber nachzudenken, was wir tun sollten. Dabei hilft uns das Werkzeug ADAPT[1].

ADAPT ist ein Akronym und steht für 5 englischsprachige Begriffe:

  • Awareness (Bewusstsein)
  • Desire (Verlangen, Gier)
  • Ability (Fähigkeit)
  • Promotion (Beförderung)
  • Transfer (Übertragung)


Die Abbildung zeigt Ihnen, dass die ersten drei Stufen Awareness, Desire und Ability sequenziell abgearbeitet werden. Promotion und Transfer sind hingegen Aufgaben, die über den kompletten Einführungszeitraum bestehen.

 

Abbildung 19: ADAPT

DEEP

Prioritäten werden nicht nur für die großen Releases gesetzt, sondern wir brauchen sie auch für die Anordnung der Anforderungen im Product Backlog.

DEEP ist im Zusammenhang mit dem Backlog sehr entscheidend und hilft Ihnen ein gutes Backlog zu erstellen. Wenn Ihre Anforderungen DEEP erfüllen, dann hat das Product Backlog eine gute Chance optimal für Scrum zu funktionieren.

Die Einträge im Product Backlog sollten sein:

  • Detailed Appropriately (entsprechend detailliert)
    Jeder Eintrag muss seiner Reihenfolge entsprechen detailliert genug beschrieben werden. Wobei User Stories, die im nächsten Sprint bearbeitet werden sollen, den höchsten Detaillierungsgrad haben.
  • Estimated (geschätzt)
    Alle Einträge sind geschätzt. Die Schätzung im Product Backlog ist noch sehr grob, lässt aber einen sinnvollen Grad für die Nennung von Lieferterminen zu.
  • Emergent[2] (zustande kommend)
    Ein Product Backlog ist keine Spezifikation, die einmal zu Beginn geschrieben wird und dann final ist. Das Product Backlog ist lebendig. Diese Emergenz ist auch gewünscht, denn wir wissen, dass Anforderungen, die über eine lange Zeit festgelegt werden, sich wieder ändern und neue Anforderungen hinzukommen werden.
  • Prioritized (priorisiert)
    Durch die Anordnung der User Stories und Epics priorisieren wir die Reihenfolge der Bearbeitung. Was oben in der Liste steht, wird zuerst umgesetzt.

[1] Interessanter Vortrag von Mike Cohn unter [COHN]

[2] Emergenz bezeichnet die Möglichkeit der Herausbildung von neuen Eigenschaften oder Strukturen eines Systems infolge des Zusammenspiels seiner Elemente.

Auch im agilen Umfeld ist das Projekt nicht nur einfach „da“, sondern es gibt jede Menge Vorarbeiten, die erledigt werden müssen.

Wir kümmern uns um ein Verständnis, was alles geplant werden muss und welche Tätigkeiten geleistet werden müssen, bevor wir das erste Mal das Product Backlog füllen können.

Planungszwiebel (Planning Onion)

Da wir nicht wie im klassischen Umfeld eine sequenzielle Denkweise haben, müssen wir uns ein anderes Modell viel unsere Planungsarbeiten definieren.

Abbildung 20: Planungszwiebel

Stellen Sie sich dafür bitte eine Zwiebel vor. Eine Zwiebel hat mehrere Schichten, die von innen nach außen gehen, dabei aber die darunterliegende Schicht voll umfassen.

Die drei inneren Schichten sind die Schichten, die wir mit Scrum planen:

  • die tägliche Arbeit,
  • die Sprints und
  • die Releases.


Diese drei Planungsebenen werden durch die Ebene des Produktes umschlossen. Bei dieser Ebene handelt es sich um die Planung des Gesamtproduktes, welches wir den Kunden ausliefern wollen. Mit dieser Planungsebene beschäftigen wir uns im nächsten Abschnitt.

Die Planungsebene des Produktes wird durch das Portfolio, die Gesamtheit aller Produkte, die im Unternehmen erzeugt werden, ummantelt. Die äußerste Ebene stellt die Ebene der Geschäftsstrategie da.

Jeder dieser Ebenen muss durch unterschiedliche Personen im Unternehmen geplant werden. Dabei ist es wichtig, dass die untere Ebene volle Kenntnis über die Ziele und Planungen der sie umgebenen Ebene hat.

Beispiel: Vorteil von Kenntnissen über Unternehmesnziele

In einem Unternehmen das Elektrogeräte produziert, ist es sinnvoll für den Produktmanager „Waschmaschinen“ zu wissen, dass das Unternehmen bald auf den asiatischen Markt anbieten will und dort andere Elektrostecker benötigt werden. Hätte er diese Information nicht aus der oberen Ebene, produziert er Waschmaschinen, die immer nur einen genormten Stecker haben. Mit der Information ist es jetzt möglich zu überlegen, den Maschinen für den asiatischen Markt einen Adapter beizulegen.

Von der Idee zum Product Backlog

Bevor wir das Product Backlog das erste Mal im Projekt befüllen können, müssen einige Vorarbeiten geleistet werden.

  • Idee und Vision
    Bevor es ins Detail geht, ist es sinnvoll, erst eine Idee niederzuschreiben. Wir wollen erreichen, eine erste Vorstellung über das zu produzierende Objekt zu haben.
  • Roadmap
    In einer Roadmap werden erste Zahlen, wie zum Beispiel Termine und Budget veröffentlicht. Wir sollten ca. fünf Unique Selling Points herausarbeiten, um unser Produkt klarer zu machen.
  • Produktkonzept
    Ein Produktkonzept enthält die wesentlichen Leistungsmerkmale und Zielgrößen der Produktidee. Sie sollte kurz und knapp sein, nur das Wesentliche enthalten und den Fokus auf den Mehrwert legen.

Abbildung 21: von der Idee zum Product Backlog

Bewusst sind diese Schritte sehr grob gehalten. Wir neigen dazu, uns in Details zu verlieren, bevor wir das große Ganze verstanden haben. Später im Product Backlog bzw. Sprint Backlog werden wir ausreichend über Details sprechen können.

In klassischen Software-Projekten wird häufig das Thema Testen als Teil einer eigenständigen Arbeitsgruppe nach der Programmierung angesehen. Das agile Testen will die sequenzielle Abarbeitung aufbrechen und das Testen als parallelen Prozess zur Programmierung etablieren.

Es ist damit nicht so sehr ein Werkzeug als ein Konzept.

Unter agilem Testen verstehen wir das Testen von Software im Rahmen eines agilen Entwicklungsprojekts. Testen in agilen Entwicklungsprojekten bedarf dabei vor allem eines Fokus auf die Unterstützung des Entwicklungsteams. Agiles Testen folgt den Prinzipien des agilen Manifests und wendet die agilen Prinzipien auf das Testen an[1].

Darüber hinaus gibt es auch Grundprinzipien des agilen Testens, um den Ansprüchen nach Geschwindigkeit und Vermeidung unnötiger Arbeit einerseits sowie Systematik und Vertrauenswürdigkeit andererseits gerecht zu werden.

  • Schnelles Feedback
    Neu entwickelter bzw. geänderter Programmcode muss noch vor dem Ausliefern getestet werden, das bedeutet, dass ein agiler Tester das Scrum-Team durch schnelles Feedback innerhalb der Iteration mit Informationen versorgen muss.
    Außerdem werden Tester bereits beim Sprintplanung-Meeting mit eingebunden.
    Um möglichst schnelles Feedback liefern zu können, setzen viele Scrum-Teams dabei auf eine Balance zwischen einem hohen Automatisierungsgrad und leichtgewichtigen manuellen Tests.
  • Hoher Automatisierungsgrad
    Um schnelle Reaktionsfähigkeit auf sich ändernde Anforderungen sowie das permanente Refactoring[2] von Programmcode zu unterstützen, müssen möglichst viele systematische Testfälle entworfen und automatisiert werden.
  • Geringer Overhead
    Der Aufwand für nicht unmittelbar operative Testaktivitäten (wie Test- und Fehlermanagement oder Dokumentation) muss so gering wie möglich gehalten werden.
  • Auflösung von Testrollen
    Den agilen Prinzipien folgend wird die Verantwortung für alle Testaktivitäten auf das gesamte Entwicklungsteam verteilt. Hierdurch verschwinden die Grenzen zwischen den klassischen Testrollen wie Testmanager, Testanalyst oder Tester. Es geht sogar so weit, dass die Grenzen zwischen Entwickler und Tester aufgelöst werden.
  • Auflösung von Teststufen
    Für eine sequenzielle Abfolge von Teststufen (z. B. Unit-, Integrations- und Systemtest), ist innerhalb der Regelzeit einer Iteration keine Zeit. Es werden Mikro-Testzyklen entwickelt, die ähnlich dem Sprint eine Iteration von Tests ermöglicht.
  • Enge Zusammenarbeit im Team
    Der Wunsch nach schnellem Feedback und die Übernahme der Verantwortung für das Testen durch das gesamte Entwicklungsteam bedingen eine enge Zusammenarbeit. Diese wird durch direkte Kommunikation sowie paarweise Zusammenarbeit erreicht.

 

Exkurs: Die Top 5 der agilen Bücher

Aufgrund der wachsenden Popularität der agilen Methode wurden in den letzten Jahren viele Bücher zu diesem Thema veröffentlicht. Derzeit sind weit über 3.000 Bücher bei „Amazon“ gelistet.

Hier sind die fünf Bücher, mit denen ich am liebsten arbeite:

Ken Schwaber, Jeff, Sutherland

„Scrum Guide“, dt., Version 2017https://www.Scrumguides.org/docs/Scrumguide/v2017/2017-Scrum-Guide-German.pdf

Der „Scrum Guide“ ist auch heute noch mein tägliches Arbeitszeug. Es gibt immer wieder etwas Neues zu entdecken bzw. zu interpretieren.

Roman Pichler

„Scrum – Agiles Projektmanagement erfolgreich einführen“

ISBN-13: 978-3898644785

Im deutschsprachigen Raum ist Roman Pichler der Autor über Scrum. Dieses von mir empfohlene Buch ist das Grundwerk zu einem Verständnis, wenn es um Scrum geht. Das Buch wendet sich an Einsteiger in Scrum und agiles Projektmanagement sowie fortgeschrittene Leser, die sich auch auf Zertifizierungen vorbereiten wollen.

Wolf – van Solingen – Rustenburg

„Die Kraft von Scrum: Inspiration zur revolutionärsten Projektmanagementmethode“

ISBN-13: 978-3864901645

Wenn es nicht immer das klassische Fachbuch sein soll, kann ich Ihnen noch dieses Buch empfehlen. Dieses außergewöhnliche Managementbuch vermittelt Ihnen in einem Erzählstil ein Verständnis der gängigen Denkweise im Allgemeinen und des Scrum-Ansatzes im Besonderen.

Kenneth S. Rubin

„Essential Scrum: Umfassendes Scrum-Wissen aus der Praxis“

ASIN: B00OVPZA0K

Wer es noch etwas ausführlicher braucht, greift zum Werk von Rubin. Sein Buch beschreibt das Wesen von Scrum, die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen zu entwickeln.

Johannsen – Kramer – Kostal – Sadowicz

„Basiswissen für Softwareprojektmanager im klassischen und agilen Umfeld: Aus- und Weiterbildung zum ASQF® Certified Professional for Project Management (CPPM)“

ASIN: B071ZS7VSM

An diesem Buch gefällt mir besonders, dass es klassisches Projektmanagement und agiles miteinander verbindet und konsequent an der jeweils richtigen Stelle einsetzt.

[1] [WIKIPEDIA], Agiles Testen

[2] Refactoring bezeichnet die manuelle oder automatisierte Strukturverbesserung von Programcode unter Beibehaltung des beobachtbaren Programmverhaltens.

Kapitel 10: Zusammenarbeit in agilen Teams

Viele Unternehmen verstehen unter der Einführung von Agilität, ein Projektteam zu bilden, es in einen eigenen Raum zu stecken und arbeiten zu lassen. Das reicht natürlich nicht.

Agilität ist nicht nur als Projektmethodik für Softwareprojekte zu verstehen, sondern wir müssen es als ganzheitlichen Ansatz für das gesamte Unternehmen interpretieren.

In diesem Abschnitt werden wir besprechen, dass es zu Widerständen im Unternehmen kommen kann und wie wir damit umgehen.

Um erfolgreich zu sein, muss das gesamte Umfeld des Unternehmens die Werte und Prinzipien von Agilität unterstützen.

Die vier Säulen von Agilität, die jede agile Umgebung unterstützen muss (vgl. Agiles Manifest), sind

  • Individuen und Interaktionen schätzen wir mehr als Prozesse und Werkzeuge
    Das Unternehmen muss die Menschen über die Standardprozesse stellen und bereit und offen sein, sich an die sich ändernden Bedürfnisse anzupassen.
  • Funktionierende Software schätzen wir mehr als umfassende Dokumentation
    Der Schwerpunkt muss auf der Erstellung von funktionierenden Projektergebnissen liegen. Das bedeutet, dass alle Unternehmensvertreter – inkl. der Geschäftsleitung – die Beseitigung unnötiger Dokumentation und die Verringerung der Anforderungen an Dokumentation unterstützen sollten, damit die Projektbeteiligten mehr Zeit für die Erstellung von Projektergebnissen aufwenden können.
  • Zusammenarbeit mit dem Kunden schätzen wir mehr als Vertragsverhandlungen
    Der Kunde muss als Teil des Teams verstanden werden und nicht als Gegner. Es ist entscheidend, dass eine offene Beziehung mit häufiger Kommunikation aufgebaut wird. Das Unternehmen muss bereit sein, Änderungen vorzunehmen, um den Kunden zu befriedigen, auch wenn das bedeutet, dass der ursprüngliche Vertrag geändert werden muss.
  • Reaktion auf Veränderung schätzen wir mehr als das Befolgen eines Plans
    Ein agiles Umfeld erfordert eine weit verbreitete Bereitschaft, flexibel zu sein und sich schnell an Veränderungen anzupassen.


Schlussendlich ist es so, dass Unternehmen mit agilen Umgebungen Veränderungen, Innovationen und Prozessverbesserungen in der Regel akzeptieren und fördern werden. Sie verstehen die agilen Rahmenbedingungen und unterstützen wichtige agile Praktiken, wie die Planung in Sprints und die Zusammenarbeit.

Allerdings kann es sein, dass die Mitarbeiter diesen Ideen nicht folgen wollen. Wie können wir also eine agile und kollaborative[1] Arbeitsumgebung schaffen?

In einer kollaborativen Arbeitsumgebung geht es nicht nur darum, unterstützende Werkzeuge, Prozesse und Arbeitsabläufe zu haben. Es geht vor allem darum, dass wir Menschen mit ihren unterschiedlicher Arbeitsstilen, persönlicher Zielen und kultureller Hintergründen zu einem Team mit gemeinsamen Zielen zusammenschweißen.

Eine kollaborative Arbeitsumgebung ist aber auch ein sicherer Raum, in dem sich jeder unterstützt fühlt und seine Meinung äußern kann.

Es gibt einige bewährte Praktiken, um unser Ziel, ein gemeinsam agierendes Team zu bilden, zu unterstützen. In unserer heutigen Zeit müssen wir dabei besonderes Augenmerk auf die multikulturelle und internationale Ausrichtung unseres Teams achten. Für viele Mitarbeiter erschwert dies die Akzeptanz bei der Einführung von Agilität.

  • Persönliches vor Arbeits-„dingen“
    Eine gute Arbeitsbeziehung gerade auch mit Kollegen und Kolleginnen aus uns eher fremden Kulturkreisen können wir forcieren, indem wir uns kennenlernen. Nehmen Sie sich Zeit mit Ihren Kollegen über Dinge zu sprechen, die nicht arbeits- oder projektbezogen sind.
    Zeigen Sie einfach Interesse; als Führungskraft sorgen Sie für die Gesprächsmöglichkeiten während der Arbeitszeit.
  • Lern- und Kommunikationsstile
    Einige Kulturen können direkter sein, während andere es vorziehen, im Hintergrund zu bleiben, bis sie nach ihrer Meinung gefragt werden. Lernen Sie die Vorlieben der einzelnen Teammitglieder kennen, damit Sie sich so effektiv wie möglich mit ihnen beschäftigen können.
    Die verschiedene Menschen im Team haben unterschiedliche Kommunikationsstile. Nur weil jemand nicht das Wort ergreift, heißt das nicht, dass er keine guten Ideen hat. Finden Sie Wege, um von allen ein Feedback zu erhalten, auch von denen, die vielleicht etwas introvertierter erscheinen.
  • Meetingkultur
    Heutzutage ist es schon schwer nach Meetings zeitnah ein Protokoll zu bekommen. Sie sollten das allerdings einführen und durchhalten und jedes Treffen protokollieren. Machen Sie dabei immer die Verantwortlichkeiten, Termine und die nächsten Schritte für alle Teammitglieder eindeutig verständlich. Das schafft nicht nur Klarheit bei den Aktionspunkten, sondern sorgt auch dafür, dass sich die Teammitglieder einbezogen und berücksichtigt fühlen.
  • Lockerheit
    Auch als Führungskraft schadet es nicht locker zu sein und Humor zu haben. Sie müssen nicht ständig über alles scherzen, aber die Aufhellung der Stimmung kann den Menschen helfen sich zu öffnen und die Arbeitsbeziehungen zu verbessern. Denken Sie aber daran, nicht jeder reagiert auf Humor in gleicher Weise!

[1] Kollaborativ bedeutet „zusammenarbeitend“, „gemeinsam“.

Jetzt, da das Projekt im Gange ist, ist es Ihre Aufgabe, auf Kurs zu halten und die Zusammenarbeit zu stärken. Der Motivationsredner „Brian Tracy“[1] sagt es am besten:

„Erfolgreiche Menschen sind einfach diejenigen mit erfolgreichen Gewohnheiten.“

Die Produktivitätsgewohnheiten Ihres Teams sind die magischen Zutaten für den Erfolg Ihres Projekts. Wenn Sie die richtigen Teamgewohnheiten haben, wird Ihr Team das Projekt termingerecht abschließen und ohne große Reibungsverluste zusammenarbeiten.

Selbst wenn Ihr Team jetzt nicht die richtigen Arbeitsgewohnheiten hat, können Sie ihm helfen, neue und produktivere Verhaltensweisen zu entwickeln. Gehen Sie mit Fingerspitzengefühl vor, Menschen sind ziemlich widerstandsfähig gegen Veränderungen.

Fünf Möglichkeiten, wie Sie dem Team beim Aufbau neuer Gewohnheiten helfen können, sind:

  • Gehen Sie mit gutem Beispiel voran
    Bestimmen Sie die Gewohnheit, die das Team praktizieren soll und leben Sie es vor. Seien Sie das Vorbild! Ihr Team wird Ihrem Beispiel folgen, wenn es die Vorteile dieser neuen Gewohnheit für die tägliche Arbeit sieht.
  • Finden Sie Ihre ersten Anwender
    Holen Sie sich Unterstützung von den enthusiastischen Teammitgliedern, die schnell neue Werkzeuge oder neue Verhaltensweisen annehmen und helfen können, diese an den Rest des Teams weiterzugeben.
  • Nutzen Sie kleine Siege, um große Siege zu erringen
    Kleine Siege können das Team motivieren, den Rest des Weges weiter zu gehen, auch wenn es zunächst schwierig erscheint. Feiern Sie jeden Fortschritt, auch wenn er noch so klein ist.
  • Schaffen Sie einen motivierenden Rahmen für Ihr Team
    Reine Argumentation wird nicht immer funktionieren, wenn nicht ein gewisses Maß an Emotionen dahintersteht. Geben Sie Ihrem Team Anreize, neue Gewohnheiten zu praktizieren. Lassen Sie es wie ein Spiel aussehen oder veranstalten Sie sogar kleine Wettbewerbe.
  • Vermischen Sie neue Gewohnheiten mit alten
    Es ist immer leichter, zu neuen Gewohnheiten überzugehen, wenn wir diese huckepack mit ältere, bestehende Verhaltensweisen überführen[2]. Dadurch fühlt sich die neue Gewohnheit vertrauter an und gewährleistet einen natürlicheren Übergang.

[1] [zegrzynskie]

[2] Ein funktionierendes Vorgehen, wie die Christianisierung des Nordens im Mittelalter beweist. Dort wurden die bisherigen Feiertage umgewidmet.

Es kann leicht passieren, dass die Projektleitung bei drohenden Terminen die besten Praktiken der Zusammenarbeit aus den Augen verliert, aber ihre Umsetzung während des gesamten Projekts wird dazu beitragen, die Leistung des Teams zu optimieren.

Stand-Up Meeting

Ein Hauptaugenmerk des agilen Ansatzes ist es, die Effizienz der Projektbeteiligten zu erhöhen. Meetings durchzuführen ist nicht effizient, denn dort werden keine Werte geschaffen. Natürlich sind Meetings notwendig, um Entscheidungen zu treffen, Informationen auszutauschen, auch um reporten zu können.

Um Meetingzeiten so kurz wie möglich zu halten, gibt es das Time-Boxing. Wir haben die Beschränkung der Meetingzeit bereits im Kapitel „Softwareerstellung mit Scrum“ kennengelernt.

Eine gute Idee zusätzlich zum Time-Boxing ist es, Meetings im Stehen abzuhalten. Selbstverständlich wird ein 8-Stunden-Meetings wie das Sprintplanungmeeting, nicht stehend absolviert. Doch wir haben bereits beim Daily Scrum gesehen, dass es möglich ist.

Nutzen Sie die Energie, die die Meetingteilnehmer im Stehen haben. Sie sind aufmerksamer, konzentrierter, werden nicht so viel reden (im Sinne: mein schönstes Urlaubserlebnis) und insgesamt schneller arbeiten.

Persönlicher Kontakt

Ich möchte kurz nochmal, weil es mir so wichtig ist, auf den persönlichen Kontakt zwischen Teammitgliedern eingehen. In Scrum haben wir schon festgestellt, dass die Teammitglieder lokal miteinander arbeiten. Das bedeutet im Grunde, dass sowohl das Entwicklungsteam als auch Produkt Owner und der Scrum Master in einem Büro arbeiten.

Der Vorteil dieser Lokalität ist es, dass wir sehr schnell und sehr einfach über den Schreibtisch hinweg mit unseren Teamkollegen reden können. Zumeist kann der persönliche Kontakt noch intensiviert werden, wenn wir die Möglichkeit nutzen z. B. gemeinsam in die Kantine zu gehen. Hier schließt sich wieder der Kreis, gerade in der Kantine wird sehr häufig auch über persönliche Dinge gesprochen. Befördern Sie die persönlichen Kontakte ihre Teammitglieder und natürlich auch mit Ihnen.

Konflikt schnell lösen

Über das Lösen von Konflikten haben wir schon im Abschnitt über das klassische Projektmanagement gesprochen. In diesem Abschnitt möchte ich Ihnen noch einiger Tipps mitgeben, damit Sie persönlich Konflikte (eigene wie fremde) lösen können.

  • Ruhig bleiben
    Es ist nicht leicht, seine Emotionen aus einem Konflikt herauszuhalten, aber ein rationaler Umgang mit einem Konflikt hilft langfristig.
  • Verbale und nonverbale Kommunikation
    Sorgen Sie immer dafür, dass das was Sie sprechen, auch durch Ihre nonverbale Kommunikation unterstützt wird. Der Körper zeigt was Sie meinen, egal was Sie sagen.
    Vermeiden Sie bei einem Konflikt mit Drohung und Anschuldigung zu arbeiten, halten Sie Ihre Sprache und Ihren Tonfall neutral. Es geht nicht darum, recht zu haben, sondern gemeinsam zu einer Konfliktlösung zu kommen.
  • Großzügig sein
    Denken Sie daran, dass die Lösung des Konflikts für die Arbeitsbeziehungen und damit Erfolg Ihres Teams, wichtiger ist als der „Sieg“ im Konflikt. Überzeugen Sie die Konfliktparteien, ihren Groll loszulassen sowie zu vergeben und vergessen.


Tipps für die Zusammenarbeit aus der Ferne und virtuelle Meetings

Die Zusammenarbeit mit Kollegen, die nicht lokal arbeiten, wird zunehmend üblich, wenn nicht sogar die Norm. Arbeitnehmer und Arbeitsplätze müssen sich anpassen, um entfernte Mitarbeiter aufzunehmen und die Zusammenarbeit zu fördern. Auch wenn dies gerade über Zeitzonen hinweg ein besonderes Problem darstellt.

  • Videokonferenzsystem
    Sorgen Sie für ein ständig eingeschaltetes Videokonferenzsystem, so dass entfernte Teammitglieder während der Arbeit jederzeit erreicht werden können.
  • Digitale Werkzeuge
    Verwenden Sie digitale Werkzeuge für die gemeinsame Nutzung. Eine effektive Zusammenarbeit erfordert die richtigen Werkzeuge und Technologien. Sie benötigen mindestens ein Echtzeit-Chat-Tool (z.B. das Videokonferenzsystem), ein Projektmanagement- / Aufgabenmanagement-Tool, ein Wissensdatenbank-Tool und ein Tool zur gemeinsamen Nutzung von Dateien. Diese Werkzeuge müssen nicht zwanghaft in einer Software vorhanden sein. Kombinieren Sie die Tools nach dem persönlichen Geschmack des Teams.

Bisher haben wir immer nur darüber gesprochen, was wir mit anderen machen können, um ein gutes Team zusammen zu bekommen und gute Arbeit zu verrichten. Wir sollten uns allerdings auch einige Gedanken darüber machen, wie wir zum Leben (beruflich wie privat), zu Veränderungen und ganz besonders zur Agilität stehen.

Ich möchte das in drei Abschnitten diskutieren: Ziele, Zeitmanagement und Selbstmanagement.

Ziele

Wenn wir von Zielen sprechen, meinen wir meist berufliche Ziele. In seltenen Fällen finden wir auch ein oder zwei persönliche Ziele. Das sind Dinge, die wir in unserem privaten Leben schaffen wollen[1]. Wir sollten beide Kategorien miteinander in Verbindung bringen, denn wenn ich mir privat ein Haus anschaffen möchte, muss ich vorher beruflichen Erfolg (zumindest im monetären Bereich) haben, um eine Grundlage für den Erwerb des Eigenheimes zu bilden.

Um Ziele einheitlich beschreiben zu können, haben wir bereits zuvor die SMART-Methode kennengelernt.

Wie Sie ein berufliches Ziel mit SMART beschreiben können, soll das Beispiel zeigen.

Beispiel: Lebensziel mit SMART

Eines meiner Ziele, ich war damals Mitte 30, war es bis zum 40. Geburtstag die Position eines Geschäftsführers zu bekommen. Mit SMART würde dieses Ziel folgendermaßen formuliert sein:

S = Geschäftsführerschaft bis zum 40. Geburtstag angetreten haben

M = a) Eintrag ins Handelsregister gleich ja > b) Alter kleiner gleich 40

A = ja, da es innerhalb meiner Lebenszeit ist

R = ja, sonst wäre es ja kein Ziel für mich

T = 25.4.2004

Welchen Vorteil hat diese konkrete Beschreibung eines Ziels für mich gehabt? Es ist so etwas wie eine Arbeitsaufforderung von extern etwas zu tun, also eine Handlungsanweisung. Ich musste z.B. dafür sorgen, dass der Geschäftsführer, der im Moment agiert, bis zum Erreichen meines 40. Geburtstages nicht mehr im Amt ist.

Wenn Sie sich keine Ziele nehmen oder setzen, werden Sie auch nicht konsequent auf diese Ziele hinarbeiten.

Zeitmanagement

Stress ist eine natürliche Reaktion auf Notsituationen, in denen das logische Denken zugunsten rudimentärer Verhaltensmuster (Flucht, Angriff oder Fatalismus) zurückgesetzt wird. Auslöser für Stress können eine Katastrophe, Probleme im persönlichen Umfeld, aber auch die Störung von Routinen sein.

Da wir im Projektmanagement – besonders im agilen – gar nicht so viele Routinen haben (der „Scrum Guide“ beschreibt einige), ist es sinnvoll uns selbst so zu organisieren, dass wir private wie berufliche Routinen ausbilden können.

Die erste Routine sollte immer sein, eine neu hinzukommende Anforderung oder Arbeit nach ihrer Dringlichkeit und Wichtigkeit einzuschätzen. Dazu bietet sich das Eisenhower-Prinzip[2] an. Ordnen Sie Ihre Aufgabe nach A, B, C und D.

Das Eisenhower-Prinzip beschreibt die Aufgaben folgendermaßen:

  • A-Aufgaben
    Diese Aufgaben sind so dringlich und wichtig, dass Sie diese selbst erfüllen müssen: Dazu ist es notwendig, alle anderen Aufgaben sofort beiseite zu schieben, um nur noch an dieser zu arbeiten bis sie erfolgreich gelöst ist.
  • B-Aufgaben
    B-Aufgaben sind zwar sehr wichtig stehen aber nicht sofort an. Wir haben damit die Möglichkeit diese Aufgaben zu beplanen Termine zu vergeben und manchmal sogar zu delegieren. Benutzen Sie dazu einen elektronischen Kalender, damit haben Sie die Möglichkeit, die Termine in sehr einfacher Art und Weise zu verschieben, wenn es notwendig ist.
  • C-Aufgabe
    Die C-Aufgaben müssen wir in zwei Kategorien unterteilen. Die eine Kategorie ist die eigene Bewertung der Aufgabe. Wenn ich mir ein Handy kaufen möchte, dann erscheint diese Aufgabe für mich sehr dringlich. Aber vermutlich wird die Welt nicht untergehen, wenn ich das Handy erst zwei bis drei Tage später kaufe. In der zweiten Kategorie wird die Dringlichkeit durch einen Vorgesetzten erzeugt.
    Es kann vorkommen, dass Ihr Manager in Ihr Büro stürmt und irgendeine Aufgabe von ihnen verlangt. Für die Manager ist es sehr wichtig, dass diese Aufgabe sofort erfüllt wird, so scheint es zumindest. Die Praxis hat allerdings gezeigt, dass diese scheinbare Dringlichkeit vor allem deswegen entsteht, weil der Vorgesetzte gerade daran gedacht hat.
    Fragen Sie Ihren Manager, wann er tatsächlich die Ergebnisse braucht.

    Wenn Sie selbst Manager sind, prüfen Sie sich immer wieder, ob der Anspruch der Dringlichkeit gerechtfertigt ist.
  • D-Aufgaben
    Aufgaben der Priorität D (weder wichtig noch dringlich) legen Sie auf den großen Stapel links unten. Wenn Sie zum Feierabend diesen Stapel in die Runde Ablage befördern, wird mit großer Wahrscheinlichkeit niemand merken, dass diese Aufgaben nie abgearbeitet worden sind.
    Sollte es doch später jemand merken, ist zumindest die Dringlichkeit nicht mehr gegeben.

Abbildung 22: Eisenhower-Prinzip

Um seinen Tagesaufgabe gerecht zu werden, ist es auch sinnvoll die eigene Leistungskurve zu beachten. Jeder Mensch hat eine ähnliche Leistungskurve, heute wird sie Biorhythmus genannt. Egal wann Sie aufstehen, Sie werden innerhalb von 2 – 3 Stunden Ihren Tageshöhepunkt erreichen; danach geht Ihr Leistungsvermögen zurück. Es wird am Nachmittag wieder eine leichte Spitze geben und dann fällt die Leistungskurve stark ab. Erforschen Sie für sich selbst, wann diese beiden Leistungsspitzen bei Ihnen erreicht werden. Organisieren Sie Ihre Arbeit so, dass die wichtigen Aufgaben in der Leistungsspitze abgearbeitet werden können.

Selbstmanagement

Früher wurde unser Arbeitsleben durch die Natur gesteuert. Es gab Jahreszeiten der Arbeit und des Ausruhen. Heute wird von uns verlangt, tagtäglich die gleiche Leistungsfähigkeit zu haben – das geht so weit, dass wir uns häufig Arbeit mit nach Hause bzw. sogar in den Urlaub nehmen.

Im Sinne der Agilität analysieren Sie Ihre Zeitaufwände, identifizieren Sie Störungen und priorisieren Sie Ihre Arbeit. In Scrum werden diese Dinge durch die Methode unterstützt, für den Rest Ihrer Arbeit, müssen Sie das selbst tun.

Der Aufbau von Zeitreserven ist in meinen Augen eine der wichtigsten Aufgaben im Bereich Selbstmanagement. In Scrum bekommen wir diese Zeitreserven dadurch, dass wir nicht auf Minuten oder Stunden planen, sondern in Story Points. Die Story Points geben Komplexität wieder und nicht genaue Zeit. So kann es sein, dass wir für die eine Anforderung etwas weniger Zeit brauchen, damit Zeit gewinnen und diese dann für andere Dinge sinnvoll nutzen können.

Um dies zumindest ein wenig abzubilden, empfehle ich die voreingestellte Meetingdauer in Ihrem digitalen Kalender etwas zu erhöhen. Meine Mindestzeit steht bei 30 Minuten. Selbst wenn ich weiß, dass eine Aufgabe (ein Meeting, ein Telefonat, etc.) kürzer wird, werden immer die 30 Minuten in den Kalender eingetragen. Somit schaffe ich mir Zeitreserven.

Im normalen Büroalltag werden wir häufiger die Problematik haben, dass wir Adhoc-Arbeiten auf den Schreibtisch bekommen. Um diese adäquat bearbeiten zu können, ist es sinnvoll, eine einfache Zeitregel zu beherrschen: die 60–20–20 oder auch 70–30 Regel.

Beide Regeln sagen dasselbe aus: Verplanen Sie 60 beziehungsweise 70% Ihres Tages und lassen sich die restliche Zeit offen, um reagieren zu können. Bei der ersten Regel wird diese offene Zeit noch unterschieden in solche, die gar nicht geplant wird, und jene, die für Kommunikation mit den Kollegen verbracht werden sollte.

[1] Ich betone das Privatleben so, weil viele meiner Seminarteilnehmer sich nie Gedanken über Privates machen. Zumindest können sie daraus keine Ziele ableiten.

[2] [LERNEN-HEUTE]

Fazit

Effizientes Projektmanagement in kleinen und mittelständischen Unternehmen ist möglich!

Allerdings ist es notwendig, ein Mindestmaß an Theorie und Anleitungen zu akzeptieren und einzusetzen.

Projektmanagement muss nicht neu erfunden werden. Es gibt genug schlaue Menschen, die das für Sie gemacht haben. Entdecken Sie für Ihr Unternehmen, für die Mitarbeiter und Kollegen und für sich selbst, die passende Methode: Es gilt, diese zu verstehen und dann konsequent umzusetzen.

Ich verspreche Ihnen, Ihre Projekte werden besser, die Ergebnisse „on point“ und das mit geringeren Kosten, zuverlässigeren Terminen und mit weniger Stress.

Wir leben in einer VUCA World! So wird es inzwischen an jeder Ecke verkündet. Doch was heißt da und welche Auswirkungen hat diese Situation auf unsere Planungen?

VUCA[1] ist ein Akronym für die englischen Begriffe

  • volatility (Unbeständigkeit),
  • uncertainty (Unsicherheit),
  • complexity (Komplexität) und
  • ambiguity (Mehrdeutigkeit).


Der Begriff beschreibt schwierige Rahmenbedingungen der Unternehmensführung. Er entstand in den 1990er Jahren am United States Army War College und diente zunächst dazu, die multilaterale Welt nach dem Ende des Kalten Krieges zu beschreiben. Später breitete der Begriff sich auch in andere Bereiche strategischer Führung und auf andere Arten von Organisationen aus, vom Bildungsbereich bis in die Wirtschaft.

[1] [WIKIPEDIA], VUCA Aktualisierungsdatum 18.05.2020)

Literaturverzeichnis

[AM]: Kent Beck u.a.; Homepage, http://agilemanifesto.org/ - Aktualisierungsdatum: 2001

[ANGERMEIER]: Angermeier, Dr. Georg, Magisches Dreieck; https://www.projektmagazin.de/glossarterm/magisches-dreieck - Abrufdatum: 12.05.2020

[BERLINER TEAM]: GRÄTSCH, Susanne, KNEBEL, Kassandra, Die Konfliktspirale: Wie Sie schnell Konflikte lösen; https://www.berlinerteam.de/magazin/die-konfliktspirale-wie-sie-schnell-konflikte-loesen/ - Aktualisierungsdatum: 07.06.2017

[COHN]: Cohn, Mike, ADAPTing to Agile; https://www.mountaingoatsoftware.com/presentations/adapting-to-agile - Abrufdatum: 10.06.2020.

[DDA]: Deutsche DevOps Akademie, Homepage; https://deutsche-devops-akademie.de - Aktualisierungsdatum: 08.05.2020

[DIN]: Deutsches Institut für Normung, ISO 21500 Leitlinien Projektmanagement; https://www.din.de/de/mitwirken/normenausschuesse/nqsz/normen/wdc-beuth:din21:165856882 - Abrufdatum: 09.05.2020

[DIN 69901]: Deutsches Institut für Normung, DIN 69901ff.; https://www.din.de/de/meta/suche/62730!search?query=69901- Abrufdatum: 08.06.2020

[DPA]: Deutsche Projekt Akademie, Projektkontrollingkreis; PM verstehen: Termin- und Kostensteuerung; https://deutsche-projekt-akademie.de/2019/07/pm-verstehen-termin-und-kostensteuerung/ - Aktualisierungsdatum: 30.07.2019

[EVOLOSO]: EVOLOSO Organisationssoftware & Consulting GmbH, Produkt-Homepage; https://www.pm-smart.com/de - Abrufdatum: 08.05.2020

[GANTT]: Gantt.com, Homepage; https://www.gantt.com/ge/ - Abrufdatum: 03.05.2020

[GPM]: Deutsche Gesellschaft für Projektmanagement e.v., Homepage; https://www.gpm-ipma.de/ - Abrufdatum: 22.06.2020

[IAPM]: International Association of Project Managers, Homepage; https://www.iapm.net/de/start/ -Abrufdatum: 21.06.2020

[INLOOX]: InLoox GmbH; https://www.inloox.de/projektmanagement-glossar/kritischer-pfad/ - Abrufdatum: 06.05.2020

[IPMA]: International Project Management Association: Homepage, https://www.ipma.world/ - Abrufdatum: 29.06.2020

[ITEMO]: IT Education Management Organization, Homepage; https://www.itemo.org/ - Abrufdatum: 24.06.2020

[JeffDeLuca]: LUCA, Jeff De, Homepage; http://www.jeffdeluca.com/ - Abrufdatum: 12.05.2020

[LERNEN-HEUTE]: MOCK, Uwe, Das Eisenhower-Prinzip; https://www.lernen-heute.de/selbstmanagement_eisenhower.html - Abrufdatum: 05.06.2020

[LESS]: The LeSS Company B.V., Homepage; https://less.works - Abrufdatum: 10.06.2020

[MEDIATION]: Mediation GmbH, Homepage; https://www.mediation.de/mediation - Abrufdatum: 17.05.2020

[MS PROJECT]: Microsoft Corporation, Produkt-Homepage; https://www.microsoft.com/de-de/microsoft-365/project/project-management-software?market=de - Abrufdatum: 08.05.2020

[OPM]: Organizational Project Management Maturity Model (OPM3), Homepage; https://www.projektmagazin.de/glossarterm/organizational-project-management-maturity-model - Abrufdatum: 10.06.2020

[PERSOLOG]: persolog GmbH, Das persolog® Persönlichkeits-Modell; https://www.persolog.de/das-persolog-persoenlichkeits-modell/ - Abrufdatum: 03.06.2020

[PMBOK]: Project Management Institute, Inc., PMBOK® Guide and Standards; https://www.pmi.org/pmbok-guide-standards - Abrufdatum: 09.05.2020

[PMI): Project Management Institute e.V., Homepage; des Berliner Vereins; https://www.pmi-berlin.org/ - Abrufdatum: 22.06.2020

[PM Sprüche]: Jungwirth, Kathrin, InLoox GmbH, 133 Zitate rund ums Projektmanagement; https://www.inloox.de/unternehmen/blog/artikel/133-zitate-rund-ums-projektmanagement/ - Aktualisierungsdatum: 19.02.2020

[PROJEKTMAGAZIN]: Angermeier, Dr. Georg, Hybrides Projektmanagement: https://www.projektmagazin.de/glossarterm/hybrides-projektmanagement - Abrufdatum: 08.05.2020

[PROVENTIS]: Produkt-Homepage, https://www.proventis.net/de/ - Abrufdatum: 08.05.2020

[QUINN]: Quinn Association, Homepage; https://www.quinnassociation.com/english/ - Abrufdatum: 03.06.2020

[QWE WIKI]: Moskau-Methode - MoSCoW method: https://de.qwe.wiki/wiki/MoSCoW_method - Aktualisierungsdatum: 21.06.2020

[SAFe]: SCALED AGILE INC, Homepage; https://www.scaledagileframework.com/ - Abrufdatum: 10.06.2020

[SCHRÖDER]: Schröder, Abel, Was ist Netzplantechnik und wofür brauche ich das?; https://axel-schroeder.de/was-ist-netzplantechnik-und-wofuer-brauche-ich-das-ein-grundlagenartikel/ - Abrufdatum: 09.05.2020

[SCRUM GUIDE]: ScrumGuides.org, Download-Seite des PDF; https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-German.pdf - Abrufdatum: 03.04.2020

[T2INFORMATIK]: t2informatik GmbH, Was ist das PMBOK und welche Wissensgebiete und Prozessgruppen beinhaltet es?; https://t2informatik.de/wissen-kompakt/pmbok/ - Abrufdatum: 09.05.2020

[TAKEUCHI]: Takeuchi, Hirotaka; Nonaka, Ikujiro: The New New Product Development Game; https://hbr.org/1986/01/the-new-new-product-development-game - Aktualisierungsdatum: Januar 1986

[TUCKMAN]: Heiner Diepenhorst, Tuckman Phasenmodell; https://teamentwicklung-lab.de/tuckman-phasenmodell - Abrufdatum: 17.05.2020

[V-Modell XT]: Der Beauftragte der Bundesregierung für Informationstechnik, Das V-Modell XT; https://www.cio.bund.de/Web/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html - Abrufdatum: 09.05.2020

[WIKIPEDIA] Agiles Testen: Wikipedia; https://de.wikipedia.org/wiki/Agiles_Testen - Aktualisierungsdatum: 02.05.2020

[WIKIPEDIA], Belbin: Wikipedia; https://de.wikipedia.org/wiki/Teamrolle - Aktualisierungsdatum: 23.10.2018

[WIKIPEDIA], CPM: Wikipedia; https://en.wikipedia.org/wiki/Critical_path_method - Aktualisierungsdatum: 08.05.2020

[WIKIPEDIA]: Gantt-Diagramm: Wikipedia; https://de.wikipedia.org/wiki/Gantt-Diagramm Aktualisierungsdatum: 19.02 2020

[WIKIPEDIA], Eisbergmodell: Wikipedia; https://de.wikipedia.org/wiki/Eisbergmodell - Aktualisierungsdatum: 21.01.2020

[WIKIPEDIA), Fibunacci-Folge: Wikipedia; https://de.wikipedia.org/wiki/Fibonacci-Folge - Aktualisierungsdatum: 14.06.2020

[WIKIPEDIA), Frederick Winslow Taylor: Wikipedia; https://de.wikipedia.org/wiki/Frederick_Winslow_Taylor - Aktualisierungsdatum: 14.04.2020

[WIKIPEDIA], Kommunikationsmodell: Wikipedia; https://de.wikipedia.org/wiki/Sender-Empf%C3%A4nger-Modell - Aktualisierungsdatum: 28.02.2020

[WIKIPEDIA], Meilenstein: Wikipedia; https://de.wikipedia.org/wiki/Meilenstein_(Projektmanagement) - Aktualisierungsdatum: 06.01.2020

[WIKIPEDIA], Netzplantechnik: Wikipedia; https://de.wikipedia.org/wiki/Netzplantechnik -Aktualisierungsdatum: 02.05.2020

[WIKIPEDIA], Projektphase: Wikipedia; https://de.wikipedia.org/wiki/Projektphase - Aktualisierungsdatum: 25.02.2019

[WIKIPEDIA], SMART: Wikipedia; https://de.wikipedia.org/wiki/SMART_(Projektmanagement) - Aktualisierungsdatum: 16.05.2020

[WIKIPEDIA], Servant Leadership: Wikipedia; https://de.wikipedia.org/wiki/Servant_Leadership - Aktualisierungsdatum: 08.08.2018

[WIKIPEDIA], Wasserfallmodell: Wikipedia; https://de.wikipedia.org/wiki/Wasserfallmodell -Aktualisierungsdatum: 08.05.2020

[WINDOLPH]: Windolph, Andrea: Die praktische Kurzanleitung zum erfolgreichen Brainstorming; https://projekte-leicht-gemacht.de/blog/pm-methoden-erklaert/brainstorming-regeln-ablauf/ - Abrufdatum: 10.05.2020

[WPGS]: Wirtschaftspsychologische Gesellschaft, 3. Motivation: Definition und Eigenschaften; https://wpgs.de/fachtexte/motivation/motivation-definition-und-eigenschaften/ - Abrufdatum: 10.05.2020

[WRIKE]: Bonnie, Emily, 16 Top Project Management Methodologies (Infographic); https://www.wrike.com/blog/a-crash-course-in-project-management-methodologies-infographic/ - Aktualisierungsdatum: 29.09.2018

[ZEGRZYNSKIE]: zegrzynskie.com, 30 motivierende Brian Tracy Zitate, die Ihr Leben verändern werden; https://zegrzynskie.com/30-motivierende-brian-tracy-zitate-die-ihr-leben-verandern-werden/ - Abrufdatum: 12.05.2020

Danksagung

Ich möchte mich für die inhaltliche Unterstützung bei meinen Kolleg*Innen Dipl.-Ing. Dirk Pinnow, Guido Schielke und Dipl.-Ing. Anke Thieme bedanken.

Für den formalen Aufbau danke ich vor allem Prof. Dr. Ralf Förster, der durch seine Erfahrung als Autor und Hochschulprofessor für eine veröffentlichbare Version sorgte sowie bei Dipl.-Ing. Doreen Fox.

Share on xing
XING
Share on linkedin
LinkedIn
Share on facebook
Facebook
Share on twitter
Twitter