Manfred Brandstätter präsentiert Projektmanagementstudie auf EURAM 2013

Ich präsentierte heute auf der diesjährigen Conference of the European Academy of Management (EURAM) in Istanbul unter dem Titel "Substainable Project Communications" die Ergebnisse einer Studie die ich zusammen mit meinem Kollegen Prof. (FH) Dr. Marcus Stumpf am betriebswirtschaftlichen Studiengang der FH-Salzburg durchgeführt hatte. 

"Das Scheitern von Unternehmensprojekten ist wesentlich auf die mangelhafte – und damit auch inkonsistente Kommunikation innerhalb und außerhalb der Projektorganisation zurückzuführen. Das Konzept der Integrierten Kommunikation, das in der Literatur als Prinzip der Nachhaltigkeitskommunikation diskutiert wird, liefert Ansatzpunkte, um bestimmte Herausforderungen der Projektkommunikation besser bewältigen zu können. Ausgehend von bereits empirisch ermittelten Erfolgsfaktoren Integrierter Kommunikation (vgl. Stumpf 2005) wurde daher in dieser Studie deren Übertragbarkeit auf die Projektkommunikation sowie deren Anteil am Projekterfolg am Beispiel von studentischen Hochschulprojekten des Studiengangs Betriebswirtschaft an der Fachhochschule Salzburg empirisch überprüft sowie konkrete Handlungsempfehlungen für eine nachhaltige Projektkommunikation abgeleitet."

Die Details zum EURAM 2013 Programm: http://www.euramfullpaper.org/program/

Design Thinking

... ist eine Kreativitäts- im Speziellen eine Problemlösungsmethode. 

Die Methode Design Thinking (DT) beschreibt weniger das Objekt, das es zu designen gilt, als vielmehr die Art und Weise, so wie Designer an eine Aufgabe herangehen. Die Methode ist auch weniger eine theoretische Herangehensweise, wie vielleicht der Begriff "Thinking" vermuten lässt, sondern liefert vielmehr „handfeste“ Ergebnisse und lässt Lösungen anhand von Prototypen begreifen, betrachten und erfühlen.

Die Komponenten

DT bezeichnet eine spezielle, teambasierte Vorgehensweise in Problemlösungen, die sich am Designprozess orientiert. Dabei legt dieser Designprozess wert auf: Empathie für den Endanwender Neuformulierung und differenzierte Betrachtung von Problemstellungen Kombination verschiedener Sichtweisen  Gestaltung verschiedener Lösungsideen und Entwicklung von Prototypen.

Die Kernaspekte in der Verwendung von DT ist eine Kombination verschiedener Ansätze:

Iterative Herangehensweise interdisziplänre Besetzung des Kreativitätsteams hoher Grad an Visualierung entlang des gesamten Kreativitätsprozesses ausreichend dimensionierte Räumlichkeiten sowie Materialen für das Besprechen Arbeiten, Visualisieren, Bau von Prototypen und Simmulationen Kombination aus konvergentem(zusammenfassenden) und divergenten (auseinanderstrebenden) Denken und Arbeiten Kombination aus Analyse und Synthese einfaches Regelwerk, jedoch disziplinierte Anwendung Zeitdruck als Methode in gewissen Abschnitten des DT-Prozesses angewendet, generiert Lösungsvielfalt und erzeugt zusätzlich die Wirkung eines „Flow-Gefühls“ bei den Beteiligten.

Der Design Thinking Prozess ist ein Menschen-zentrierter Ansatz aus Methoden und Werkzeugen, der Ansätze aus den Bereichen Design und Visualisierung mit Kenntnissen über Technologien und Wirtschaft kombiniert. Dabei nutzt man diesen iterativen Prozess um die versteckten Bedürfnisse von Nutzern heraus zu finden und sie mit der technischen Machbarkeit und wirtschaftlicher Rentabilität abzustimmen. Die Resultate sind für den Anwender wünschenswerte sowie benutzbare, technologisch machbare bzw. funktionsfähige und für den Erzeuger rentable Produkte, Services und/oder Problemlösungen (siehe dazu Abb. 1).

Abb. 1: Die Verbindung im DT-Prozess von Mensch, Technologie und Geschäft

Die Historie

Entwickelt wurde DT an der Stanfort University. Die Breitenwirkung von DT und der massive Einzug in Lehre und Wirtschaft, wurde speziell durch das gezielte Aufgreifen der Methode durch den SAP-Mitbegründer, Hasso Plattner erreicht. Dieser gründete Design Schulen, sogenannte D-schools, mit Ableger auch im deutschsprachigen Raum, der HPI-School for Design in Potsdam (www.hpi-uni-potsdam.de). 

Geprägt wurde DT durch die konsequente Anwendung und Vermarktung bekannter Vertreter der Creative Industry, wie zB die US-amerikanische Innovationsagentur IDEO (www.ideo.com). 

Die Anwendung

DT wird immer öfter für Anforderungen ausserhalb des herkömmlichen Bereichs von Designern - die Gestaltung von Objekten - angewendet. Anforderungen sind vielmehr komplexe Aufgabenstellungen, wie zB die Reduzierung des aufwändigen Handlings von Retourgeld im Handel, Bewältigung der Vielzahl illegaler Einwanderer in Italien, die Reduzierung der Jugendarbeitslosenrate in Spanien oder die Reduzierung der Sterblichkeitsrate von Frühgeborenen in Entwicklungs- und Schwellenländern.

In meinen Projekten verwende ich DT hauptsächlich als Methode zur Identifizierung und lösung komplexer Anforderungen. Der Charme in der Verwendung der Methode DT besteht für mich darin, dass dabei in einer spielerischen Art & Weise, in Form schneller Durchläufe, fertige Ergebnisse in Form von Prototypen erzeugt werden. Ein durch DT erzeugter Prototyp ist in meinem Projekten zumeist eine Kombination aus Hardware, Software und Prozessen bzw. Services. 

Ein Beispiel dazu: In einem hochbrisanten Hardware Entwicklungsprojekt - Konstruktion und Bau eines Zutrittsterminals für den Behördenbereich - warteten im Sommer 2009, 100.000 Stück Elektronikleiterplatten und einige Millionen elektronische Bauteile auf die in Kürze anlaufende Produktion. Der kurzfristige Ausfall des Lieferanten eines der Kernkomponenten, löste dabei Krisenstimmung aus. Der Lieferverzug hätte eine saftige Pönalzahlung zur Folge gehabt. Der (nur eintägige) Lösungsprozess in der Methode DT erbrachten mehrere - auch kaufmännisch sehr gut vertretbare - Lösungen zutage. Zum Einsatz kam dann folgende Lösungsvariante. Mittels „Reverse-Engineering“ wurde die Funktionalität des fehlenden Bauteils einfach anhand diskreter Bauteile in Form eines Prototypen nachgebaut und auf einer sogenannten Huckepackplatine aufgebracht. Als Hardware-Lösung wurde diese Huckepackplatine auf den schon bestehenden Bohrungen des ursprünglichen Bauteils aufgesetzt. Ebenso wurde im Rahmen des DT-Prozesses ein dafür adaptierter Produktionsprozess gestaltet, der nicht nur konzipiert sondern auch simmuliert und mit allen Beteiligten im Vorfeld trainiert werden konnte.

Die Funktionsweise

Die HPI School of Design Thinking lehrt den Design-Thinking-Prozess in sechs Schritten: Diese gliedern sich in zwei Abschnitte (Problemzone und Lösungszone) und sechs Prozessschritte. Diese 6 Prozesschritte sind iterativ miteinander verbunden. Es ist wichtig, zu verstehen, dass es stetig zu Rückkopplungen zu vorherigen Prozessschritten komen kann (und soll) und keineswegs ein linearer Ablauf der einzelnen Prozessschritte beabsichtigt ist.

1 - Verstehen: Hier geht es darum, das Problem an sich und dessen Umfeld ausreichend zu erfassen, um ein generelles Verständnis zu entwickeln. In diesem ersten Schritt wird die Aufgabenstellung beschrieben. Dieser Schritt bildet die Grundlage für den gesamten Design-Thinking-Prozess.

2 - Beobachten: Die Phase des Beobachtens spielt im Design-Thinking-Prozess eine sehr wichtige Rolle. Hier geht es darum durch sogenannte Insights (Einsichten) Empathie für die Zielgruppe zu generieren, um so Lösungen, möglichst entsprechend deren Bedürfnisse, zu gestalten. Zum Einstieg ist es wichtig zu lernen, seinen Blick in alle Richtungen zu lenken (360-Grad-Sicht) und qualitative Forschung (Analyse) anstelle von quantitativer Forschung zu bevorzugen

3 - Standpunkt definieren: Hier geht es darum „die gesammelten Erkenntnisse auszuwerten, zu interpretieren und zu gewichten. Die Mitglieder des Teams kommen zusammen um über die jeweiligen Erlebnisse während der Beobachtungsphase zu erzählen. So kann auf einer gemeinsamen Wissensbasis entschieden werden, ob noch mehr Informationen gesammelt werden müssen, um von der Betrachtung des Problemraums zur Betrachtung des Lösungsraums überzugehen. Aus der Vielzahl an Einsichten und Betrachtungsweisen, die während des Beobachtens erfasst wurden, werden nun einige wenige selektiert. Es geht nun darum, in einem Prozess der Synthese, Muster zu erkennen und Thesen über Zusammenhänge aufzustellen. Das Team versucht nun einen gemeinsamen Standpunkt zu definieren, indem konkrete Beobachtungen abstrahiert werden. Eine Methode „ist der Entwurf einer idealtypischen, fiktiven Person, die sogenannte Persona für die die Innovation entwickelt werden soll.

4 - Ideen definieren: Bei diesem Schritt kommt es darauf an, in kurzer Zeit, eine Vielzahl an Ideen zu generieren. Ganz nach dem Motto „Quantität vor Qualität“ werden möglichst viele Lösungsideen generiert. Verschiedene Kreativitätstechniken, wie beispielsweise die bewährte Brainstorming-Methode, stehen hierfür zur Verfügung. Zunächst werden Ideen lediglich gesammelt und noch nicht bewertet oder diskutiert.

5 - Selektieren/Prototyp bauen: Im Design Thinking Prozess sollen Ideen durch den Einsatz von Prototypen verfeinert werden. Aussagen, über die Realisierbarkeit einer Idee, sollen nicht auf der Basis von spekulativen Annahmen gemacht, sondern mit Hilfe von Prototypen getestet werden. Hier wird aus der Vielzahl an Lösungsideen ein Muster ausgewählt und in Form eines Prototyps weiter verfolgt. Während des Prototypings setzt sich das Design-Thinking-Team ganz konkret mit einer Lösungsidee auseinander und gewinnt dadurch neue Erkenntnisse über die Idee. Die Lösungsidee (Synthese) wird im Problemraum erprobt, um Fehler möglichst früh zu erkennen. Bei den Prototypen handelt es sich nicht um aufwendige, teure Konstrukte, es geht vielmehr darum, Ideen möglichst früh sichtbar und kommunizierbar zu machen, damit Anwender sie testen können oder zumindest in der Lage sind, ein Feedback zu geben. Prototypen können die Gestalt von Modellen, Storyboards, Rollenspielen oder auch Diagrammen annehmen. Es geht darum Ideen für die spätere Zielgruppe sichtbar und erlebbar zu machen.

6 - Testen/Verfeinern: Gemeinsam mit der späteren Zielgruppe, werden Lösungen nun im Problemraum erprobt. Das Design-Thinking-Team beobachtet die Nutzer beim Umgang mit dem Prototyp und schließt so auf die Stärken und Schwächen einer Idee. Die Erkenntnisse, die sich aus der Test-Phase ergeben, sind sehr wichtig für die weitere Entwicklung der Lösung. Der Prototyp wird auf Erfüllung der Lösungsaspekte (siehe Standpunkt der Persona im Pkt. 4), bzw. auf die generelle Problemstellung (siehe Pkt. 1). Entspricht der Prototyp als vollwertiges Lösungsmodell in Bezug auf die ursprünglichen Anforderungen, folgt zumeist die Freigabe für eine produktionstechnische Umsetzung. 

Abb.2: Die sechs Phasen des DT-Prozesses

Weiterführende Literatur

Brown, Tim; Katz, Barry (2009): Change by design. How design thinking can transform organizations and inspire innovation. New York: Harper Collins.

Brown, Tim (2010): „From Design to Design Thinking“ in: University of Michigan School of Art & Design: Penny Stamps Distinguished Speaker Series. 08.04.2010. Online verfügbar unter http://www.youtube.com/watch?v=lGOTwFvkfhU, zuletzt geprüft am 13.06.2013.

Brown, Tim (2006): „Innovation Through Design Thinking“ in: MIT Sloan School of Management: Dean´s Innovative Leader Series., 16.03.2006. Online verfügbar unter: http://mitworld.mit.edu/video/357/, zuletzt geprüft am 13.06.2013.

Erbeldinger, Juergen; Ramge, Thomas (2013): Durch die Decke denken. Design Thinking in der Praxis. München: Redline-Verlag,

Geschka, Horst; Lantelme, Gudrun (2005): „Problemlösungsstrategien“ in: Marion A. Weissenberger-Eibl und Sonja Bidmon (Hg.): Gestaltung von Innovationssystemen. Konzepte - Instrumente - Erfolgsmuster. Kassel: Cactus-Group-Verlag, S. 309–328.

Methoden zur Planung und Umsetzungssteuerung von temporären Aufgaben

Grundsätzlich

In der Betrachtung von temporären Aufgabenstellungen unterscheiden wir im traditionellen Projektmanagement grundsätzlich:

• Einzelaufgaben - geringe Komplexität, Dauer bis max. 3 Monaten.
• Kleinprojekte - geringe bis mittlere  Komplexität, Dauer bis max. 6 Monaten .
• Projekte - mittlere bis grosse Komplexität, Dauer bis zu 12 Monaten.
• Programme - sehr grosse Komplexität, bestehend aus verschiedenen Projekten mit gemeinsamer Zielsetzung, Dauer bis zu mehreren Jahren.

Unabhängig von den neuen agilen Managementmethoden in der Planung und Umsetzung von temporären Aufgaben, hat die oben beschriebene Aufstellung nach wie vor ihre Berechtigung. Denn die Methoden rund um Scrum & Co. sind nicht die „Eier-legenden-Woll-und-Milch-Schweine“ die für jede temporäre Aufgabenstellung geeignet sind.

Mit dem Aufkommen von agilen Organisationsmethoden sind aber eben auch neue Betrachtungsweisen dazugekommen. Diese werde ich nachfolgend kurz ausformulieren.

Software Entwicklung

In der Software Entwicklung unterscheiden wir mittlerweile unterschiedliche Szenarien:

Szenario A - Software-Entwicklung  mit eindeutig definierten  Anforderungen, einem stabilen Projektumfeld und geringer Änderungsrate  (Änderungsrate von unter 30%). Dabei sind traditionelle Projekt Mgmt. Methoden, kombiniert mit Software-Engineering Methoden wie zB Wasserfall- oder V-Modell und auch Prototyping passend.

Szenario B1 - Software-Entwicklung  mit unklar formulierten Anforderungen, einem volatilen Projektumfeld und einer hohen Änderungsrate  (Änderungsrate von über 30%). Scrum hat sich hierfür als die ideale Methode in den letzten 7 Jahren etabliert. Voraussetzung dabei ist jedoch, dass die Teammitglieder nur in diesem einem Projekt, jedoch nur in geringem Ausmass (max. 20% ihrer Arbeitszeit) andere Tätigkeiten (zB Software Wartungsarbeiten) durchführen. 

Szenario B2 - Der Unterschied liegt darin, dass Mitarbeiter in verschiedenen Projektteams mitarbeiten und/oder Software Wartungsarbeiten bzw. Hotline-Dienste durchführen müssen. Hierbei stösst Scrum vom Koordinierungsaufwand her betrachtet, an seine Grenzen. Für diese Art hat sich in den letzten Jahren eine neue agile Methode, mit der Bezeichnung Kanban, etabliert. Dabei werden die Aufgaben, User Stories, oder Tasks ebenfalls auf Pinwänden angebracht um damit die aktuelle Arbeitsleistung und –belastung der Mitarbeiter zu visualisieren. Angelehnt an Kanban-Boards in der Industrie, werden  neben dem aktuellen Status von Aktivitäten, Engpässe sichtbar und daher besser steuerbar.

Hardware Entwicklung 

In diesem Entwicklungsbereich sind die Ergebnisziele zumeist eindeutig definierbar. Daher ist das traditionelle Projektmanagement in diesem Entwicklungsbereich die bessere Methode für Planung und Umsetzungssteuerung. Einfache und wenige Änderungsanforderungen können in dieser Methode mittels Change Request Mgmt. gut bewältigt werden.

In der Hardware Entwicklung (HW-Entwicklung) ist das vom agilen Projektmanagement bekannte „iterative“ Ausliefern von Teilergebnissen (Produktinkrementen) nur schwierig machbar.  Ebenso verursacht oftmals das Zuliefern von Bauteilen Verzögerung, die über die maximale Sprintdauer von 20 Tagen hinausgeht. Damit können fundamentale Anforderung von Scrum nicht erfüllt werden. 

Bei einer hohen Wahrscheinlichkeit von Änderungen während des HW-Entwicklung ist auch eine Kombination von traditionellem Projektmanagement und Scrum (zB Daily Scrum, Verwendung von Reviews und Retrospectives bei Meilensteinabnahmen) gut kombinierbar.

Service Aufträge, Hotline-Aktivitäten

Für Produktwartung oder Aktivitäten an Service- oder Hotlines, sind Visualisierungs Boards, wie zB Kanban Boards sehr gut geeignet. Damit ist es mit einfachen Mitteln möglich, einen Überblick des aktuellen Prozesses zu haben, für jeden Prozessschritt das „Work-in-Progresss Limit“ festzuhalten  um damit eventuelle Engpässe besser identifizieren und beheben zu können. 

Forschung

In der Forschung - schwerpunktmässig in der Grundlagenforschung - sind die Ergebnisziele am Projektbeginn zumeist nicht eindeutig definierbar. Es ist schwierig, an dieser Stelle ein passendes Werkzeug (Methode) zur Planung und Umsetzungssteuerung zu definieren. Ich persönlich habe gute Erfahrung in F&E-Projekten (Pharma und Nahrungsmittelindustrie) mit „meilensteingesteuerten Scrumprojekten“ gemacht. Dabei wird ein F&E Projekt in der Kombination aus traditionellem Projektmanagement und Scrum geplant und durchgeführt. Kanban Boards können in einer „gemischten Umgebung“ neben den Sprint Backlog Boards helfen, die aktuellen Aktivitäten zu visualisieren.

Produktentwicklung

Szenario A - In der Produktentwicklung ist zumeist ein definiertes Ergebnisziel am Projektbeginn vorhanden.  Daher ist - ähnlich wie in der Vorgehensweise bei der HW-Entwicklung - die Verwendung der traditionellen Projektmanagement Methode mit möglicher Kombination zu agilen Methoden sinnvoll.

Szenario B - Bei Produktentwicklungsprojekten, mit einem hohen Problemlösungsanteil, also in Projekten wo im Vorfeld der Produktentwicklung, erst einmal das Problem eindeutig identifiziert werden muss, Lösungsvarianten ausgearbeitet werden, Prototypen entwickelt und getestet werden, sind iterative Methoden, wie zB Design Thinking sinnvoll. Vor der eigentlichen Produktentwicklung wird für dieses Teilprojekt einer Prototypenentwicklung und –testphase immer öfters ein Problemlösungsprojekt vorgeschalten und mittels der Methode Design Thinking iterativ umgesetzt. 

Abb. 1: Übersicht der Methoden zur Planung und Umsetzungssteuerung von temporären Aufgaben

Details zu den einzelnen beschriebenen agilen Methoden neben Scrum werden in den weiteren Weblogs noch ausführlich beschrieben werden.

Für weiterführende Fragen stehe ich Ihnen gerne zur Verfügung und freue mich über Ihre Kommentare zu diesem Artikel.

Weiterführende Literatur

Gloger, B. (2008): Scrum. Produkte zuverlässig und schnell entwickeln, München.

Design Thinking-HPI: http://www.hpi.uni-potsdam.de/d-school/home.html (Abgefragt: 16. Mai 2013)

Deign Thinking-IDEO: http://www.ideo.com/about (Abgefragt: 16. Mai 2013)

Leopold, K./Kaltenegger, S. (2012) Kanban in der IT. Eine Kultur der kontinuierlichen Verbesserung schaffen, München.

Oesterreich, B./Weiss, C. (2008): APM - Agiles Projektmanagement. Erfolgreiches Timeboxing für IT-Projekte, Heidelberg.

Pichler, R. (2008): Scrum. Agiles Projektmanagement erfolgreich einsetzen, Heidelberg.

Preissing, W. (2008): Visual Thinking. Probleme lösen mit der Faktorenfeldmethode, München.

Project Management Institute (2004): A Guide of the Project Management Body of Knowledge, 3. Aufl., Washington.

Agile Enterprise Transition

... oder, die Transformation von Unternehmen in Richtung einer agilen Organisation.

Grundsätzlich

Ein Wandlungsprozess in einer Unternehmensorganisation kann durch unterschiedliche Umstände ausgelöst werden.  Zwei Gruppen von Auslösefaktoren, die extern oder die intern motivierten Faktoren, begegnen uns dabei.

Bei den extern motivierten Faktoren sind dies zumeist:

• Marktveränderungen (zB Kunden orientieren sich beispielhaft in Ihrer Kaufentscheidung bei Nahrungsmitteln immer öfter an der Nachvollziehbarkeit der Zulieferkette und lösen daher eine Änderung in Richtung des eigenen Einkaufsmanagements aus), 
• Veränderungen bedingt durch Regeländerungen (zB gesetzliche Rahmenbedingungen im Bereich der Automobilindustrie zwingen die OEMs zu Rückgewinnungsmassnahmen von Rohstoffen und lösen daher ebenso eine Änderung in Richtung des eigenen Einkaufsmanagements aus), 
• Technologieänderungen (zB hat die Firma Blackberry durch den grossen Erfolg des Apple Iphones mit einer massive Änderung ihres  Produktportfolios, gepaart mit einer Organisationsneugestaltung reagieren müssen), oder 
• Kundenvorgaben (zB verordnete das Unternehmen Redbull seinen Logistikpartnern vor wenigen Jahren kurzfristig eine neuer Art des Supply Chain Managements).

Von internen Auslösefaktoren sprechen wir bei:

• Restrukturierungsmassnahmen (zB Trennung oder Zusammenführung von Unternehmensteilen) ausgelöst durch operative bzw. strategische Aspekte (zB Kostendruck, Änderungen bedingt durch Beteiligungen), 
• Optimierungen in der Ablauf- und/oder Aufbauorganisation, oder aber auch durch das 
• Aufgreifen von Modeströmungen (zB externer Berater "verordnet" die Einführung eines CRM- Systems).

Startsituation und Zielsetzung

Als Zielsetzung jedes Änderungsprojektes muss es sein, das Unternehmen produktiver zu machen und die Menschen in den Mittelpunkt zu stellen, damit diese mit Spass und Stolz auf die eigene Arbeit ans Werk gehen. 

Der erste Aspekt steht in den Ergebniszielen und war auch immer Vorgabe in meinen Projekten. Der zweite Aspekt begegnete mir als Vorgabe jedoch selten, gehört aber in agilen Transition Projekten aus meiner Sicht zum "must have"!

Folgende drei unterschiedliche Startsituationen sind mir im Rahmen meiner Umsetzungsprojekte begegnet:

• Top-Down Einführung - das ist der Idealfall, denn dabei war stets von Beginn an der Rückhalt des Managements gesichert. Die Vorteile dabei sind und waren: Ein klarer Auftrag und eindeutiges Mandat, Ressourcenbeschaffung geht einfacher und schneller vonstatten, sowie die aktive Unterstützung in allen Belangen ist "vorprogrammiert".
• Bottom-up Einführung - die am häufigsten begegnete Situationen, dass Scrum von "unten aus" betrieben wird. Zumeist hat ein erfahrener Entwicklungsleiter die Initiative ergriffen, ein Pilotprojekt als Anlassfall gestartet und die Folgeprojekte unter Duldung des Topmanagements weitergeführt. Der Vorteil liegt in der breiten Akzeptanz und Motivation bei den Mitarbeitern. Der Nachteil liegt darin, dass sobald die Projekte über die Grenzen der eigenen Abteilung hinausgehen, Organisationsänderungen nur sehr schwer machbar sind. 
• Virale Einführung - Scrum wird unentdeckt in Abteilungen eingeführt und Dank des "Normativen durch das Faktische", schleichend und unerkannt im gesamten Unternehmen verbreitet. Da eine Entdeckung jedoch langfristig sicher, zumeist mit grossem Ärger verbunden ist und die Überlebenschancen einer solchen Einführung gering sind, sollten Sie von einer derartigen Implementierung Abstand nehmen.

Abb: 1: Orientierung in der Startsituation und Richtungsauswahl in einem Transitionsprojekt

Neben der Orientierung, welche Startsituation, den Wandlungsprozess ausgelöst hat, ist natürlich die Zielsetzung massgeblich. Folgende Ergebnis-Ziele können wir nach Wandlungsprozessen - im Kontext zu Scrum - grundsätzlich erreichen:

• Bedarfsfall-Scrum - Scrum wird jeweils im Bedarfsfall eingesetzt, jedoch ohne eine entsprechende Unterstützung wie zB durch ein Scrum-Office (oder Scrum Software Studio) 
• Oberflächen-Scrum - Scrum wird vom Management verordnet, jedoch ohne tiegreifende Änderungen auslösen zu wollen. Es werden dabei oftmals nur Teilaspekte von Scrum verwendet (zB Daily Scrum) und  die Projekte grossteils noch in der traditionellen Methode abgewickelt.
• Scrum Office - dabei werden in einem eigenen Unternehmensbereich (Scrum Office) Methodenwissen rund um Scrum gebündelt und Metriken aufgebaut die zur ständigen Verbesserung von Scrum im Unternehmen führen.  Alle Projekte im Unternehmen werden im Scrum Office aus gestartet und geschlossen. Bei der Etablierung eines Scrum Office ist es nicht das Ziel eine tiefgreifende Änderung in Richtung einer Agilisierung des gesamten Unternehmens zu erzeugen.
• Full-Scrum - ist ein Wandlungsprozess, an dem am Ende die gesamte Unternehmensorganisation erfasst wird. Scrum wird auf breiter Front im gesamten Unternehmen etabliert und nachhaltig verankert. Scrum durchdringt alle Prozesse des Unternehmens.

Abb. 2: Zielsetzung von Transitionsprojekten 

Organisation des Änderungsprojektes

Egal wie der Weg des Wandlungsprozesses aussieht und ausgesehen hat, ich habe mich inhaltlich stets am "8-Stufen Modell für Organisationsveränderungen nach Kotter" orientiert und als zeitlichen Rahmen, Scrum verwendet. 

Jede dieser Phasen im "Kotter-Modell" müssen linear durchlaufen werden, um ein Änderungsprojekt nachhaltig erfolgreich abschliessen zu können. Das bedeutet, dass Sie zB nicht die achte Phase vor der ersten abschliessen können. Meist sind jedoch mehrere Phasen gleichzeitig aktiv. Das sollte Sie auch nicht irritieren. Als Überblick habe ich das „Kotter-Modell“ nachfolgend kurz skizziert und aufgelistet:

1. „Establishing a sense of urgency“ (Ein Gefühl für die Dringlichkeit erzeugen)

• Untersuchen von aktuellen und zukünftigen Marktchancen.
• Identifizierung potenzieller Krisen um diese auch anzusprechen.
• Daraus resultierende Chancen erkennen und diskutieren.
• Dringlichkeit für alle Beteiligten spürbar machen.
• Sorgen dafür, dass das Führungsteam die Dringlichkeit verspürt und danach handelt. Ansonsten sind alle nachgelagerten Kommunikationsmassnahmen wertlos.
• Klärung der Fragen: Warum soll das Unternehmen agil gestaltet werden oder warum soll Scrum eingeführt werden? Was geschieht, wen nichts passiert?

2. „Creating the guiding Coalition“ (Aufbauen eines Führungsteams)

• Zusammenstellung eines Führungsteams (maximal 9 Personen) mit entsprechender Durchsetzungskraft im Wandlungsprozess (Geschäftsführer oder sonstige Führungskraft mit hierarchischer Macht, Experten für die Kernprozese, Scrum-Veteran, alle Personen die sie im Änderungsprojekt unterstützen können.
• Aufbau einer gemeinsamen Sichtweise der aktuellen Situation (Starten Sie mit der Erstellung des Transition Backlogs).

3. „Development a vision and strategy“ (Entwicklung einer Vision der Veränderung und Entwicklung einer Veränderungsstrategie)

• Schaffung einer richtungsweisenden Vision.
• Verwendungen von jeglichen Visualisierungswerkzeugen (Brownpaper, Flipcharts, Pinwänden) helfen in der Visionsarbeit.
• Entwicklung einer Strategie für die Umsetzung der Vision (spätestens hier sind das sind schon die ersten Epics und Stories im Transition Backlog)
• Die Vision muss maximal in fünf Minuten kommunizierbar sein.

4. „Communicating the change vision“ (Kommunikation der Vison auf breiter Basis)

• Nutzung jeder Möglichkeit und jedes Anlasses um die Vision und die Strategie zu kommunizieren, ständig, bestmöglich täglich kommunizieren.
• Einfachheit in der Kommunikation (keine Fremdwörter verwenden).
• Verwendung von sprachlichen und wirklichen Bildern.
• Vor-BILD-haftes Rollenverhalten, des Führungsteams, dass der Mitarbeitererwartung in dieser neuen Situation entspricht.

5. „Empowering broad-based action“ (Befähigung zur Initierung großräumiger Aktivitäten)

• Veränderung von Strukturen, die die Veränderungsvision beinträchtigen könnte (speziell mögliche Hemmnisse bei den Vorgesetzten abbauen).
• Beseitigung von Hindernissen (Misstrauen abbauen, mangelnde Fähigkeiten mit Schulungen kompensieren, an der Einstellungen und der Motivation der Mitarbeiter arbeiten).
• Förderung von „konfliktfähiger“ Kultur.
• Ermutigung zu ungewöhnlichen Ideen, Aktivitäten und Handlungen.

6. „Generating short-term wins“ (Sicherstellung von kurzfristigen Gewinnen)

• Planen von kleinen sichtbaren Erfolgen (zB ein kleines bis mittleres Scrum Pilotprojekt).
• Sichtbarmachung und Kommunikation dieser „quick wins“ (nach spätestens 6 Monaten sollten Sie einen Erfolg vorweisen können)
• Anerkennung und Auszeichung der involvieren Führungskräfte und Mitarbeiter.

7. „Consolidating gains and producing more change“ (Sicherung der erreichten Ziele und Schaffung weiterer Veränderung) 

• Die wachsende Akzeptanz für weitere Veränderungsprojekte nutzen.
• Förderung von Mitarbeitern, die eine Veränderung vorantreiben.
• Die Verantwortung und das Engagement der Veränderung verlagert sich immer mehr von den Führungskräften zu den Mitarbeitern.

8. „Anchoring new aproaches in the culture“ (Verankerung der erreichten Veränderung)

• Dauerhafte Fixierung der Veränderungen in der Organisation (Kultur, Normen, Werte), die am Ende des Wandlungsprozesses erreicht wurden.

Der Wandlungsprozess, als Scrum Projekt gestartet, verwendet in diesen Fällen als Product Backlog ein sogenanntes „Transition Backlog“. Jeder Sprint liefert dabei etwas "Fertiges" aus. Zumeist sind aus dem Tranistion Projekt heraus neue Teilprojekte (zb ein Scrum Pilotprojekt, oder ein Schulungsprojekt) gestartet worden. Ein Beispiel für ein Tranistion Backlog Items ist: "Die Arbeitsfähigkeit für Scrum Projekte ist im gesamten Unternehmen vorhanden". 

Als Product Owner habe ich zumeist jene Personen rekrutieren können, die das grösste Interesse an der Einführung von Scrum sowie die grösste Motivation dazu hatten. 

Als Scrummaster wurde ein erfahrener Scrummaster des eigenen Unternehmens ausgesucht. Öfters war dies auch ein zukünftiger Scrummaster, der von mir in seiner Rolle in den ersten Sprints begleitet wurde. Das Team bestehend aus 3-9 intern anerkannten und gut vernetzten Personen  wurde aus allen wichtigen Personengruppen des Unternehmens rekrutiert (siehe dazu Stufe 1 bis 2 nach Kotter). 

Abb. 3: Transiation Projekt als Scrum Projekt organisiert

Fallbeispiel

Nachfolgend sind die Lernpunkte eines Änderungsprojektes am Beispiel eines   Dienstleistungsanbieter im Bereich Telekommunikation kurz und knapp beschrieben.

Die Ausgangssituation

Ausgelöst wurde der Change - intern motiviert - durch das Bedürfnis, die Vielzahl der überwiegend erfolgreich abgeschlossenen Scrum-Projekte als Beispiel für die Gestaltung einer neue Projektorganisation im gesamten Unternehmen zu nehmen und Scrum als unternehmensweite Methode zu etablieren. Andererseits sollte der Change dazu dienen, das gesamte Unternehmen flexibler und agiler zu organisieren. 

Scrum wurde als Projektmanagement Methode im Jahre 2008 gestartet, und schrittweise durch die unterschiedlichen Software Abteilungen ins Unternehmen eingebracht. Die Ausgangssituation war 2012 daher ein Bottom-up Ansatz, kombiniert mit einer empfohlenen Top-Down Einführungsstrategie, vom Führungskreis des Unternehmens vorgegeben. 

Als Zielsetzung dieses Wandlungsprojektes war eine Full-Scrum Einführung in die gesamte Organisation geplant. Das Zwischenziel war die Etablierung eines Scrum-Office im Bereich der Service- und Software Entwicklung und des Produktmanagements. Das Zwischenziel wurde nach ca. 9 Monaten Projektdauer erfolgreich erreicht und gefeiert. 

Momentan wird an der schrittweisen Etablierung von Scrum in allen Unternehmensbereichen und der Durchdringung in alle Kernprozesse des Telekommunikationsanbieters gearbeitet. Am Ende des Projektes sollte jeder Unternehmensbereich, im strategischen sowie im operativen Bereich der Unternehmensführung, Scrum und weitere agile Werkzeuge  verwenden, Metriken für sich entwickeln und sich daran selbstständig weiter verbessern können. Das Scrum Office als zentrale Institution wird in dieser Situation dann nicht mehr notwendig sein und wird mit einer hohen Wahrscheinlichkeit wieder aufgelöst werden.

Die Lernpunkte

Als Lernpunkte aus dem Fallbeispiel sind die Do´s und die Dont´s in Bezug auf Gesamtorganisation sowie betroffene Abteilungen aufgelistet und sollen damit die Erfolgs- bzw. Misserfolgsfaktoren der abgeschlossenen Projektphase kurz veranschaulichen.

1) Gesamte Organisation

Do´s

• Klares Ziel: Warum mache ich/wir das?
• Langer Atem (Derartige Projekte sind eher Programme und dauern oftmals länger als 12 Monate)
• Rahmen schaffen (inhaltlich, zeitlich, organisatorisch, kostenmässig) kleine Schritte gehen, Selbstorganisation einführen und fördern
• Transparenz zur Verbesserung nutzen
• Es wurden gesamte Abteilung(en) umgestellt
• Die gesamte Organisation (im Moment nur der Teilbereich Produktentwicklung und Produktmanagement) wurde mit Scrum „agilisiert“
• Das Management-Commitment ist von Beginn bis zum Ende des Prozesses vorhanden gewesen
• Geduld in allen Phasen des Prozesses
• die Bilder der Änderungsvision „von oben“ vorleben
• Lernen wichtiger als Abstrafen
• Play-2-win
• Kulturwandel oftmals (aber nicht immer) nötig
• Selbstorganisation braucht Feedback in beide Richtungen
• Evolutionär (always run a changing system)
• Selbstorganisation des Teams fördern und dies auch beachten
• klaren Rahmen erarbeiten (einfache Regeln, inkl. eigenes Budget für zB Incentives)
• Kommunikation fördern (zB Kaffee Ecken ausbauen, Spielecken mit zB Tischfussball aufbauen)
• Unschärfen und Differenzen fördern

Dont´s 

• Das Management kommt nur zum „kritisieren“ in/nach schwierigen Situationen
• Technische Defizite sind hoch (aber keiner will es frühzeitig einsehen)
• Transparenz schafft Angst
• Schaffung von agilen Inseln
• Desinteresse des Managements kann für das Projekt „tödlich“ sein
• Assoziationen: Agilität bedeutet nur „Teamkram“; mit Agilität löst man alle Probleme schlagartig
• Klassisches Change Management (Ziele, Stufen, Deadlines). Die Gefahr dabei ist, das die 2. und 3. Führungsebene sich auf das Management der KPI´s (Key Performance Indikatoren) zurückzieht
• Lineares Denken
• Ressourcen managen wollen
• Bedeutung, Macht, Kontrolle (Auswirkung: Beschneidung der Änderungskommunikation)
• Einführung von Oberflächen-Scrum („Wasch mir den Pelz, aber mach mich nicht nass“)

2) Produktmanagement

Do´s

• Gutes Produktmanagement aufbauen und stärken
• Klare Produktvision bei jedem Produkt erzeugen
• Entscheidungen/Prioritäten in der Produktentwicklung werden nach dem jeweiligen Wert für den Kunden UND der Firma getroffen
• Realistische Ziele

Dont´s 

• Verwalter von Produkten und Produktideen anstatt Product Owner
• Ein Druck von allen Seiten (innen und aussen) auf das Produktmanagement
• Druck wird unreflektiert auf Produktentwicklung weitergegeben
• Schwäche in der Organisation zu Prioritäten und Umpriorisierungen
• Agilität ist das „Spielzeug der Software Entwicklung“

3) Produktentwicklung

Do´s

• Wenn überhaupt, Gruppenincentives (Zielsetzung immer eine Ebene höher als persönlich oder alleine erreichbar)
• Kennzahlen abschaffen/ersetzen (Planeinhaltung ist kein sinnvolles Ziel, Wert und Nutzen erzeugen jedoch schon)
• Zufriedenheitsindex erstellen

Dont´s 

• Lineares Kontrolldenken
• Effizienz mit Effektivität verwechseln
• Planeinhaltung um jeden Preis
• Incentives auf metrische Ziele 
• Management und Verwaltung by KPI´s

Für weiterführende Fragen stehe ich Ihnen gerne zur Verfügung und freue mich über Ihre Kommentare zu diesem Artikel.

Weiterführende Literatur

Brandstätter, M./ Gölzner/H., Siems, F. (2006): Diversifizierte Kommunikation auf Basis des Event Life Cycle. Eine interdisziplinäre Betrachtung für die Stakeholder Netzwerkpartner, Mitarbeiter und Kunden. In: Proceedings of VI. Interdisziplinäres Symposium „Europäische Kulturen in der Wirtschaftskommunikation (EUKO 2006)”, Turku, S. 24-25.

Capra, F. (2002): Verborgene Zusammenhänge, Bern.

Doppler, K./Lauterburg, C. (2005): Change Management. Den Unternehmenswandel gestalten, 11. Aufl., Frankfurt a. Main.

Gloger, B. (2008): Scrum. Produkte zuverlässig und schnell entwickeln, München.

Kostka, C./Mönch, A. (2001): Change Management. 7 Methoden für die Gestaltung von Veränderungsprozessen, München.

Kotter, J., P. (1996): Leading Change, Boston.

Laube, T./Schwandner, O. (2006): Technologie-Roadmapping-basierte Vorgehensweise zur Unterstützung des Technologietransfers in kmU. In Gausemeier, J. (Hrsg.): Vorschau und Technologieplanung. 2. Symposium für Vorschau und Technologieplanung Heinz Nixdorf Institut, 9. und 10. Nov. 2006, Schloss Neuhardenberg, Paderborn.

McK Wissen 08 (2008): Von der Amöbe lernen, http://www.brandeins-wissen.de/Downloads/McK/mck08_10.pdf, (Abfrage: 18.03.2008).

Morgan, G. (2002): Bilder der Organisation, 3. Aufl., Stuttgart.

Oesterreich, B./Weiss, C. (2008): APM - Agiles Projektmanagement. Erfolgreiches Timeboxing für IT-Projekte, Heidelberg.

Peters, T., J./Waterman, R., H. (2003): Auf der Suche nach Spitzenleistungen. Was man von den bestgeführten US-Unternehmen lernen kann, Heidelberg. 

Pichler, R. (2008): Scrum. Agiles Projektmanagement erfolgreich einsetzen, Heidelberg.

Preissing, W. (2008): Visual Thinking. Probleme lösen mit der Faktorenfeldmethode, München.

Project Management Institute (2004): A Guide of the Project Management Body of Knowledge, 3. Aufl., Washington.

Pugh, D., S. (1981): The Aston Program of Research. Retrospect and Prospect, in Van de Ven A., H./Joyce, W., F. (Hrsg.), Perspectives on Organization Design and Behavior, New York, S. 135-166.

Reiß, M. (1997): Optimierung des Wandels, in Reiß, M. (Hrsg.): Handbuch für Change Management. Programme, Projekte und Prozesse, Stuttgart, S. 123-144.

Robbins, P. (2001): Organisation der Unternehmung, 9. Aufl., München.

Scholl, W. (2004): Grundkonzepte der Organisation,  in H. Schuler (Hrsg.), Lehrbuch der Organisationspsychologie, 3. Aufl., Bern, S. 515-556.

Stolzenberg, K./Heberle, K. (2006): Change Management. Veränderungsprozesse erfolgreich gestalten - Mitarbeiter mobilisieren, Heidelberg.

Senge, P. (2003): Die fünfte Disziplin, 9. Aufl., Stuttgart.

Takeuchi, H./Nonaka, I. (1986): The New Product Development Game. Stop running the race and start rugby. In: Harvard Business Review. Jan-Feb 1986, Harvard, S. 137-146.

Von Rosenstiel, L./Dierkes, M./Steger, U. (1993): Unternehmenskultur in Theorie und Praxis: Konzepte Aus Ökonomie, Psychologie und Ethnologie, Frankfurt a. Main.

Von Rosenstiel, L. (2003): Grundlagen der Organisationspsychologie, Stuttgart.

Weick, K. (1995): Der Prozess des Organisierens, Frankfurt a. Main.

Einführung von Scrum in die Unternehmensorganisation

Scrum ist ein Vorgehensmodell für Planung und Umsetzungssteuerung von Projekten, das vorwiegend in der Software-Entwicklung eingesetzt wird. Darüber hinaus begegnet mir Scrum aber immer mehr als Planungs- und Umsetzungswerkzeug in anderen Branchen, speziell überall dort, wo Forschung und Entwicklungsarbeit geleistet wird. In der Pharmaindustrie genauso, wie in der Automobilindustrie, Medienbranche und Nahrungsmittelindustrie hat Scrum neben den hauseignen IT- Abteilungen, in den F&E Labors Einzug gefunden.

Im Vordergrund von Scrum stehen Teamwork, regelmäßige und zyklische Lieferungen funktionierender Produkte bzw. Teilprodukte (Inkremente), enge Zusammenarbeit mit dem (internen bzw. externen) Kunden, arbeiten in fest definierten Zeitrahmen (engl. „timebox“) sowie die Fähigkeit schnell auf Änderungen (engl. „Change Requests“) zu reagieren.

Was bietet Scrum? 

Scrum setzt auf ein selbstorganisiertes (Software-) Entwicklerteam, das sich ohne einen Projektleiter organisiert und strukturiert. Damit das Entwicklerteam in Ruhe und ohne Störungen (Software-) Produkte entwickeln kann und darf, gibt es einen Scrum Master. Damit dieser Entwicklungsprozess (engl. Scrum Flow) eingehalten und auch kontinuierlich verbessert wird, tritt der Scrum Master zusätzlich als Bindeglied zwischen dem Entwicklungsteam und dem Product Owner auf und stellt dadurch die ergebnisorientierte „Lieferung“ von funktionierenden Produkten sicher. Durch seine schützende, ordnende und vermittelnde Rolle ist der Scrum Master einer der wichtigsten Change Agents in einem Unternehmen. Seine Rolle ist speziell in der Einführungsphase von Scrum in der Unternehmensorganisation von grosser Wichtigkeit.  Während er im Rahmen der laufenden Projektarbeit schwerpunktmässig als "Zeremonienmeister" für das Einhalten der Regeln und Rituale verantwortlich ist und als Abstimmungspartner zwischen Team und Product Owner fungiert, ist seine Tätigkeit in der Einführungsphase mehr die eines "Missionars" für die Methode. Dabei schafft er die notwendige Vertrauensbasis für die Methode Scrum beim Management und den Linienorganen des Unternehmens, berät den Product Owner in seiner neuen Rolle als  Autor von User Stories (im Gegensatz zu herkömmlichen Spezifikationsdokumenten) und steht dem gesamten Unternehmen als Ansprechpartner in allen Fragen der Methode Scrum zur Verfügung.

Meiner Meinung nach, bekleidet der Product Owner gegenüber dem Scrum Master in funktionierenden Organisationen die wichtigere Rolle. Das exakte "Schneiden" von Epics und User Stories sowie die schrittweise Gestaltung und ständige Kommunikation des Big Pictures eines entstehenden Produktes in iterativen Schritten, ist ein Erfolgsfaktor. In der Einführungsphase jedoch, liegt die Hauptverantwortung im Gelingen dieses Vorhabens in jedem Fall beim Scrum Master.

Wo liegen die Vorteile von Scrum?

Scrum besitzt seine unumstrittenen Stärken in hochkomplexen Projekten in Kombination mit meistens nicht eindeutig definierbaren oder volatilen Ergebnisszielen. Dies sowohl in kleinen Teams (5 - 9 Mitarbeitern) wie auch in mittleren und grossen Teams (bis zu 200 Mitarbeitern), auf einem oder mehreren Standorten verteilt. In Projekten mit eindeutig definierbaren und nicht ändernden Ergebniszielen ist zumeist die traditionelle Projektmanagementmethode nach PMI oder IPMA die idealere Methode.

Ist Scrum auch für Ihr Unternehmen geeignet? 

Scrum formuliert die Rechte und Pflichten des Entwicklerteams, des Product Owners sowie des Scrum Masters. Desweiteren basiert Scrum auf einen schlanken, flexibel anpassbaren und gut strukturierten (Software-) Entwicklungsprozess. Scrum ist eine sehr leistungsfähige Methodik um hoch effizient und hoch effektiv die Ergebnisziele eines Projektes zu erreichen. Jedoch erfordert der Einsatz von Scrum hohe Voraussetzungen in der Unternehmensorganisation: 

• Autonomie in der Umsetzung - das Team setzt eigenverantwortlich die Funktionen des Produktes um. Es ist in der Methode kein Projektleiter der klassischen Ausprägung vorgesehen, der Leistung, Termin und Kosten überwacht.
• Vertrauen des Managements in Richtung einer autonomen Umsetzung von Produkten durch ein Team ohne Vorhandensein einer Befehls- und Kontrollinstanz.
• Vertrauen des Teams in der Anwendbarkeit der Methode.
• Vertrauen des Product Owners in die Methode, speziell in der Autonomie der Methode.
• Offenheit - tägliche gelebte Offenheit in den Daily Scrum Meetings.

Agilitäts-Selbstcheck

Mit nachfolgendem Test fällt es leichter einzuschätzen, ob Ihre Organisation vom Einsatz agiler Methoden, wie zB von Scrum profitieren kann und ob die Voraussetzungen dafür gegeben sind. Dieser Agilitäts-Selbsttest entstand im Rahmen einer Forschungsarbeit zum Thema Projekterfolg in Zusammenarbeit mit der Fachhochschule Salzburg, im Studiengang Betriebswirtschaft und wurde von mir als Teilergebnis daraus konzipiert  (vgl. Brandstätter/Stumpf, 2012).

Der Selbsttest dauert in der Umsetzung ca. 15 Minuten und gibt Ihnen die Möglichkeit einer ersten Standortbestimmung zum Thema Agilität Ihres Unternehmens oder Unternehmensbereiches. Der Selbsttest ist in 3 Module (A bis C) unterteilt. In Modul A ermitteln Sie die Agilität im eigenen Unternehmen (Unternehmensbereich). In Modul B wird der Bedarf für den Einsatz von agilen Managementmethoden ermittelt. Dabei wird in B1 der Bedarf im Tagesgeschäft und in B2 der Bedarf im Projekteinsatz ausgewiesen. Abschließend geht es in Modul C um die Ermittlung der notwendigen Voraussetzungen Ihres Unternehmens (Unternehmensbereiches) in Hinblick auf den Einsatz von agilen Managementmethoden.

Geben Sie im nachfolgenden Selbsttest bei den aufgeführten Aussagen jeweils den Grad Ihrer Zustimmung an: 3 Punkte für Zustimmung, 2 Punkte für teilweise Zustimmung, einen Punkt bei Nicht-Zustimmung. Danach summieren Sie Ihre Punkte.

A - Die Agilität im eigenen Unternehmen bzw. Unternehmensbereich

1. Ein hoher Anteil an initiierten Aktivitäten bzw. Projekten wird erfolgreich abgeschlossen.

2. Unsere Aktivitäten bzw. Projekte unterliegen einer großen Wandlung.

3. Die Mitarbeiter inkl. Führungskräfte haben die notwendige Kompetenz zur Lösung von unerwarteten Anforderungen.

4. Die Mitarbeiter inkl. Führungskräfte haben den Entscheidungsspielraum zur selbsttätigen Lösung von unerwarteten Anforderungen.

5. Die Mitarbeiter inkl. Führungskräfte haben einen einfachen und schnellen Zugang zu allen formellen und informellen Informationen.

6. Unser tägliches Umfeld im Markt ist volatil und dadurch ständigen Schwankungen und Änderungen unterworfen.

7. Das Unternehmen besitzt mit sehr gut vernetzten Führungskräften und Mitarbeitern gute Sensoren in den jeweiligen Zielmärkten.

8. Die Mitarbeiter inkl. Führungskräfte kennen die eigenen "key earning drivers" des eigenen Unternehmens.

Ist die Summe höher als 16, ist die Agilität in Ihrem Unternehmen (Unternehmensbereich) stark ausgeprägt. Es reagiert rasch auf notwendige Änderungen. Änderungen erzeugen keine Irritationen in der Belegschaft. 

Liegt das Ergebnis höher als 8, befindet sich Ihr Unternehmen auf dem Weg in Richtung einer agilen Organisation.

Ergebnisse unter 8 deuten darauf hin, dass Ihr Unternehmen (Unternehmensbereich) starr organisiert und/oder stark formalisiert ist, sowie auf notwendige Änderungen langsam reagiert.

B1 - Bedarf an agilen Managementmethoden im Tagesgeschäft

9. Das Management Ihrer Unternehmensaktivitäten ist komplex und kompliziert.

10. Der Bedarf an schneller Reaktion auf Kundenanfragen im Kerngeschäft ist steigend.

11. Die Zufriedenheit der internen und externen Kunden Ihrer Produkte bzw. Services sinkt.

12. Die Anzahl der Änderungen in der Ablauf- und Aufbauorganisation steigen tendenziell an.

13. Die Anzahl von internen Projekten steigt tendenziell an.

Ist das Ergebnis höher als 10, ist der Bedarf für den Einsatz agiler Methoden im Tagesgeschäft ausgeprägt. In diesem Fall empfiehlt sich ein schneller Einstieg mit agilen Methoden und die Durchführung entsprechender Trainings.

Liegt das Ergebnis höher als 5, ist für den Einsatz agiler Methoden ein möglicher Bedarf gegeben.

Bei Ergebnissen unter 5, besteht mit hoher Wahrscheinlichkeit kein Bedarf für den Einsatz von agilen Managementmethoden im Tagesgeschäft Ihres Unternehmens (Unternehmensbereichs).

B2 - Bedarf an agilen Managementmethoden für Projektvorhaben

14. Die Erfolgsrate von Aktivitäten und Projekten ist rückläufig.

15. Die Komplexität der Projektvorhaben (Aktivitäten) steigt tendenziell.

16. Die Anzahl der Projektvorhaben (Aktivitäten) steigt tendenziell.

17. Unsere abgeschlossenen Aktivitäten und Projekte besitzen eine durchschnittliche Änderungrate von mehr als 30%.

18. Die durchschnittliche Anzahl an Mitarbeitern in meinen Vorhaben (Projekten und Aktivitäten) steigt tendenziell.

Ist das Ergebnis höher als 10, ist der Bedarf für den Einsatz agiler Methoden in Projekten ausgeprägt. In diesem Fall empfiehlt sich ein schneller Einstieg mit agilen Methoden und die Durchführung entsprechender Trainings.

Liegt das Ergebnis höher als 5, ist für den Einsatz agiler Methoden ein möglicher Bedarf gegeben.

Bei Ergebnissen unter 5, besteht mit hoher Wahrscheinlichkeit kein Bedarf für den Einsatz von agilen Managementmethoden in Projekten Ihres Unternehmens (Unternehmensbereichs).

C - Voraussetzungen für den Einsatz von agilen Managementmethoden für Tagesgeschäft bzw. Projektvorhaben

19. In der Organisation Ihres Verantwortungsbereichs existiert eine hohe Vertrauenskultur.

20. .... und es existiert eine ausgeprägt offene Fehlerkultur.

21. In der Organisation Ihres Verantwortungsbereichs besteht eine Verbindlichkeit zu autonomen Teams.

22. Das jeweilige Projektteam (Fachteam) wird nach den notwendigen Fähigkeiten und Begabungen individuell zusammengestellt.

23. In Ihrer Organisation existiert Knowhow bzw. Erfahrung im Einsatz von agilen Managementmethoden.

24. Ihre Mitarbeiter weisen eine hohe Projektverfügbarkeit auf.

Ist das Ergebnis höher als 12, sind die Voraussetzungen für den Einsatz von agilen Methoden in Ihrem Unternehmen ausgeprägt vorhanden.

Liegt das Ergebnis höher als 6, liegt eine bedingte Voraussetzung in Ihrem Unternehmen vor. Haben Sie darüber hinaus aber einen hohen Bedarf im Einsatz von agilen Methoden (siehe Pkt. B und/oder C), so sollten Sie dabei notwendige Bewusstseinsbildung und Ausbildung in der Organisation mittelfristig aufbauen.

Ein Ergebnis unter 6 bedeutet eine geringe bis keine Voraussetzungen für den Einsatz von agilen Methoden. Haben Sie darüber hinaus aber einen hohen Bedarf im Einsatz von agilen Methoden (siehe Pkt. B und/oder C), deutet dies darauf hin, dass Sie ehest möglich eine Verbesserung diesbez. mittels Bewusstseinsbildung und Ausbildung in der Organisation in Richtung Agilität herbeiführen sollten.

Für weiterführende Fragen stehe ich Ihnen gerne zur Verfügung und freue mich über Ihre Kommentare zu diesem Artikel.

Weiterführende Literatur:

Brandstätter, M., Stumpf, M. (2012): Nachhaltigkeit im Projektmanagement – Bedeutung der Integrierten Kommunikation in der Innen- und Außendarstellung von Projekten. In: Umwelt-, Wirtschaftsforum, Heft 3-4/2012, S. 217-221. Springer-Verlag, Heidelberg.

Gloger, B. (2008): Scrum. Produkte zuverlässig und schnell entwickeln, München.

Pichler, R. (2008): Scrum. Agiles Projektmanagement erfolgreich einsetzen, Heidelberg.

Takeuchi, H./Nonaka, I. (1986): The New Product Development Game. Stop Running The Race And Start Rugby. In: Harvard Business Review. Jan-Feb 1986, S. 137-146, Boston.

Wirdemann, R. (2009): Scrum mit User Stories, München, Wien.

Witte, E. (1973): Organisation für Innovationsentscheidungen. Das Promotorenmodell. Schriften der Kommission für wirtschaftlichen und sozialen Wandel, Band 2, Göttingen.

Witte, E./Hauschildt, J./Grün, O. (1989): Innovative Entscheidungsprozesse: die Ergebnisse des Projektes "Columbus", Tübingen.

Wojda, F. (2000): Innovative Organisationsformen. Neue Entwicklungen in der Unternehmensorganisation, Stuttgart.

Womack, J., P./Jones, D., T. (1996): Lean Thinking, Auf dem Weg zum perfekten Unternehmen, 1. Aufl., München.