2 Für die Einschätzung der Projektsituation gibt es Hilfestellungen von Snowden und von Shenhar/ Dvir [4, 5]. PRINCE2 (PRojects IN a Controlled Environment) ist eine strukturierte Projektmanagementmethode. Ursprünglich wurde sie Mitte der 1970er-Jahre für IT-Projekte entwickelt. Seit 1996 ist sie als allgemeine Methode für alle Art von Projekten anerkannt. Hauptautor und treibende Kraft war bis 2008 Colin Bentley. Im April 2013 hat der bisherige Besitzer, das britische Cabinet Office, 51% Prozent der Anteile an das Unternehmen Capita verkauft (www.capita.co.uk/ news-and-opinion/ news/ 2013/ capita-selected-to-form-jv-ip-businesswith-cabinet-office.aspx). Über PRINCE2 ® Anzeige Führen Sie heute die richtigen Projekte durch und entscheiden Sie so über Ihren Unternehmenserfolg von morgen STRATEGIE • STRUKTUR • KULTUR Seminare für Projektmanager Themen • Multiprojektmanagement - Projekte und Portfolios systematisch managen 07.-08.07.2014, Berlin • Projektmanager/ -in - Im Spannungsfeld zwischen Mensch und Portfolio 13.-14.10.2014, Bad Nauheim T r a i n i n g Beratung & Anmeldung Heike Borschel (Buchung) Katja Zink (Produktmanagerin,Trainerin) Telefon 0641 98210-300 Weitere Termine unter: www.ibo.de/ projektmanagement-seminare ibo Beratung und Training GmbH Im Westpark 8 | D-35435 Wettenberg T: +49 641 98210-300 F: +49 641 98210-500 training@ibo.de | www.ibo.de Beratung | Software | Training | Verlag „Entschuldigung.“ Er stolziert zur Tür und wir hören ihn telefonieren. „So ein Mist“, flucht Siggi als er zurückkommt. „Hatten die anderen doch recht, dass es mit dem Auftrag nichts wird. Zu wenig Planungssicherheit und zu wenig Integration mit der bestehenden Unternehmenskultur, Überarbeitung bis kommenden Freitag - wie bei Ihnen.“ Philipp ist verwundert: „Wie jetzt? Sie haben den Auftrag auch nicht bekommen. Ich verstehe gar nichts mehr. Hat denn noch ein Dritter mit angeboten? “ Siggi legt sein Telefon wieder weg: „Nein, nein. Mein Ansprechpartner meinte, es gebe nur zwei Angebote. Wahrscheinlich Ihrs und meins. Und um auf Ihre Frage von vorhin zurückzukommen: Natürlich kann man mit Scrum große Produkte entwickeln. Es gibt genügend Beweise dafür. Viele erfolgreiche Softwareprodukte, aber auch Autos wurden schon agil entworfen. Ich bin sicher, dass agile Vorgehensweisen in Zukunft immer wichtiger werden, weil die klassischen Projektmanager mit ihrem Wasserfall-Latein am Ende sind.“ Philipps Augen blitzen. Er richtet sich auf und will gerade zu einer großen Scrum-Tirade ansetzen. Da mischt sich die Bedienung hinter dem Tresen in das Gespräch ein: „Ich kenne mich ja nicht mit dem aus, wovon Sie reden. Aber wie es scheint, würden Sie beide gern den Auftrag bei der NMB AG haben. Wenn Sie beide so kompetent sind, warum arbeiten Sie dann nicht zusammen? Projekt ist doch Projekt, oder? “ Überrascht blicken sich der PRINCE2-Berater und der Scrum-Coach an. „Nein, unmöglich“, antwortet Siggi als erster. „PRINCE2 und Scrum sind völlig unterschiedliche Arbeitsweisen und Methoden für völlig unterschiedliche Arten von Problemen.“ 2 Philipp nickt zustimmend. „Das denke ich auch. Scrum ist für Softwareentwicklung und mit PRINCE2 macht man richtige Projekte. Ich weiß gar nicht, wie das funktionieren soll.“ Philipp zieht seine Brieftasche aus dem Jackett. „Ich denke, ich gehe jetzt besser. Machen Sie mir bitte die Rechnung fertig.“ so einiges über PRINCE2 gehört. Aber ich schwöre eher auf Scrum und agiles Projektmanagement.“ „Ja, ich kenne auch andere Methoden. Und diese agilen Vorgehensmodelle werden immer beliebter. Das merke ich wohl“, entgegnet Philipp. „Glauben Sie denn wirklich, man könnte damit richtige, große Projekte leiten? Ich bin da doch sehr skeptisch.“ Der Scrum-Coach will gerade zu einer Antwort ansetzen, als Philipps Mobiltelefon vibriert. „Oh, mein Kunde.“ Philipp wischt siegessicher über den Bildschirm. „Ja, Philipp hier. … Hm … Ja.“ Er blickt auf eine tote Fliege auf dem Tresen. „Ach so … Also äh … Nein … Ja, verstehe … So nicht annehmbar. ... Ja, verstehe. ... Bis kommenden Freitag … Ja, Sie hören von mir. Okay, bis dann.“ Philipp steckt das Telefon ein und starrt ins Leere. „Keine Zusage? “ Siggi ist jetzt ein bisschen neugierig geworden. „Nein. Der Kunde findet, ich bin nicht ausreichend auf die Anforderungen und Bedürfnisse von Softwareteams eingegangen. Er hat ein Gegenangebot auf dem Tisch, das in dem Bereich viel konkreter und …“, Philipp räuspert sich, „vom Chef der Softwareentwicklung viel besser bewertet worden ist. Wenn ich möchte, kann ich bis Freitag nachbessern. Ich habe gar keine Ahnung, wie ich das machen soll.“ Philipp wird still. Dann richtet er sich auf und blickt Siggi direkt in die Augen: „Sagen Sie mal, warum sind Sie eigentlich hier. In dieses Dorf fährt man doch nicht ohne Grund.“ Der Scrum-Coach antwortet ohne Umschweife: „Ich habe heute bei der Neustädter Motoren- und Bremsen AG ein Angebot für die Begleitung eines IT-Projekts abgegeben. Da ich den Kunden noch nicht kannte, habe ich das Angebot persönlich abgegeben. Man hat mir aber vorher gesagt, dass meine Chancen nicht so gut stehen.“ „Moment mal“, unterbricht Philipp. „Ich habe auch bei der NMB AG mein Angebot abgegeben. Habe ich den Auftrag jetzt etwa wegen Ihres Gegenangebots nicht bekommen? “ „Nichts für ungut. Aber wie es scheint, glaubt der Kunde, dass eine agile Arbeitsweise besser zum Projekt passt. Scrum ist groß im Kommen.“ Siggi greift nach seinem Handy. PM_2-2014_1-68: Inhalt 28.03.2014 7: 47 Uhr Seite 45 Scrum ist ein Framework zur nachhaltigen Entwicklung komplexer Produkte. Es entstand Anfang der 1990er-Jahre und wurde überwiegend von Softwareentwicklungsteams benutzt. Die Autoren Ken Schwaber und Jeff Sutherland weisen immer wieder darauf hin, dass Scrum unabhängig von IT-Projekten ist. Im Juli 2013 wurde eine neue Version des Scrum Guides veröffentlicht (http: / / scrum.jeffsutherland.com/ 2013/ 06/ scrum-guide- 2013-is-here.html). Über Scrum 22 l projekt MA N A G E M E N T aktuell 2/ 2014 tion annehmen. Also nicht nur der Auftraggeber, sondern auch die Nutzer und die Lieferanten. Nun habe ich auch eine Frage. Erklären Sie mir bitte mal, wie Scrum mit Spezifikationen und dem Thema Qualität umgeht.“ Siggi erklärt: „Bei Scrum haben wir zwei Werkzeuge, ein Product Backlog und die Definition of Done. Die Definition of Done ist eine allgemeine Qualitätsprüfliste für alle Anforderungen. Das Product Backlog ist die einzige Liste mit Anforderungen, und zwar allen, die bis dahin bekannt sind. Meist sind sie in Form von User Storys beschrieben. Eine User Story ist unkompliziert und schnell erstellt.“ „Und wer erstellt diese User Storys? “, will Philipp genauer wissen. „Bei PRINCE2 gibt es ganz viele Rollen. Gibt es so etwas wie einen Benutzervertreter in Scrum? “ „In Scrum sind drei Rollen definiert. Eine davon ist der Product Owner, oder kurz PO: Er verwaltet das Product Backlog und entscheidet, welche Anforderungen als Nächstes umgesetzt werden. Der PO ist für den Return on Invest des Projekts zuständig.“ „Wie viele Product Owner kann es denn geben? “, will Philipp wissen. Siggi versteht die Frage nicht: „Eigentlich nur einen, aber ich bin mir nicht sicher, ob ich Ihre Frage richtig verstehe? “ „Nun ja, in meinen Projekten habe ich meist unterschiedliche Quellen von Anforderungen. Die passen natürlich nicht zusammen: Die Nutzer aus den Fachabteilungen, die primär mit dem neuen IT-System arbeiten, dann der Verantwortliche für den IT-Betrieb und natürlich das Entwicklerteam. Wen nehmen Sie jetzt als Product Owner? “ Siggi kommt die Situation nicht unbekannt vor: „Solche Konflikte gibt es in allen Projekten. Was ist der beste Weg, diese unterschiedlichen Sichtweisen aufzulösen? Bei Scrum haben wir bewusst nur einen Product Owner. Wenn es mehrere gibt, kommt es zu Widersprüchen, die das Team nicht auflösen kann. Das Team könnte nicht weiterarbeiten. Also muss sich der Product Owner um gute Anforderungen kümmern und diese mit allen betroffenen Parteien abstimmen. Darf ich noch einmal auf den Umgang von PRINCE2 mit Anforderungen zurückkommen? “, fragt Siggi. „Sie entwerfen, soweit das möglich ist, die Produktbeschreibungen und setzen die einzelnen Produkte entsprechend um. Was geschieht denn, wenn es bei der Umsetzung Probleme gibt? Ich denke da an das wichtige Thema Kommunikation.“ „Also beim Thema Kommunikation muss ein PRINCE2- Projektleiter auf andere Quellen zurückgreifen“, seufzt Philipp. „PRINCE2 sagt zur Kommunikation wenig Konkretes. Die Praktiker wissen aber genau, dass Kommunikation der Hebel im Projektmanagement ist. Als Projektleiter bediene ich mich da gerne bei anderen Methoden. Bei Scrum gibt es doch das Daily Stand-up, nicht wahr? Worauf muss ich denn da eigentlich achten? “ Siggi antwortet direkt: „Am wichtigsten ist nach meiner Erfahrung, dass man sich streng an die vereinbarten Regeln hält. Es gibt eine feste zeitliche Begrenzung, nämlich 15 Minuten. Das Daily Stand-up dient dazu, dass sich das Team synchronisiert und prüft, ob es seine Zwischenziele erreicht. Dazu beantwortet jeder drei Fragen: Was habe ich gestern fertig gemacht? Was will ich heute „Das verstehe ich nicht“, antwortet die Bedienung. „Sie haben doch für das gleiche Projekt ein Angebot abgegeben. Dann wollen Sie doch das gleiche Problem lösen, oder? “ Philipp steckt seine Brieftasche wieder ein. „Wissen Sie, in meinen Projekten höre ich ständig, dass irgendwas nicht gehen kann, und hinterher klappt es doch“, lenkt Siggi ein. „Jetzt betrifft mich diese Frage selbst. Das ist schon komisch. Aber vielleicht können wir für zwei Stunden unsere Ideologien beiseitelassen. Und wenn ich ehrlich bin, gibt es bei Scrum-Projekten einige Punkte, wo ich für neue Ideen dankbar wäre.“ Philipp ist skeptisch: „Ich tue mich schwer damit, aus meiner PRINCE2-Haut zu kommen. Ich glaube auch nicht, dass man Methoden ohne Weiteres kombinieren kann. Jede hat doch ihre innere Logik und ist über Jahre gewachsen. Da stecken so viele Erfahrungen drin. Aber gut, versuchen wir es.“ Beide bestellen ein neues Bier. Nach einem großen Schluck fängt Siggi an: „Was ist denn für Sie bei PRINCE2 so toll? “ Philipp überlegt. „Mir gefällt, dass PRINCE2 ergebnisorientiert und wirtschaftlich denkt. Mit der produktbasierten Planung ist viel klarer, was erreicht werden soll. Das ist vor allem am Anfang eines Projekts wichtig.“ „Ergebnisse und Wirtschaftlichkeit spielen auch bei Scrum eine große Rolle“, sagt Siggi. „Vielleicht ist das ein gemeinsamer Nenner. Gehen wir einen Schritt weiter: Erklären Sie doch mal, warum Ihrer Meinung nach PRINCE2 am Projektanfang so gut ist.“ „Eine Besonderheit bei PRINCE2 ist, dass wir Qualität als Produkteigenschaft auffassen, zum Beispiel unser Bier. Niemand trinkt gerne warmes Bier, oder? Da haben wir die Produkteigenschaft Temperatur. So ein Weizen sollte zwischen sieben und neun Grad haben. Das ist eine Eigenschaft, die wir in der Spezifikation festhalten und bei der Abnahme überprüfen können. Wenn wir das also vorher festmachen, gibt es danach keinen Diskussionsbedarf. Ob das ein Bier oder Software ist, macht im Prinzip keinen Unterschied. Wichtig ist im Projekt halt, dass es einmal festgelegt wird, und zwar für alle klar und verbindlich. Prost! “ Siggi ist mit der Antwort noch nicht zufrieden: „Ja, beim Bier ist das klar. Das ist ja ein bekanntes und standardisiertes Produkt. Wie funktioniert das bei sehr individuellen Softwarepaketen? Wissen Sie immer genau, auf welche Eigenschaften es uns ankommt? “ „Natürlich kennen wir am Anfang nur einen Teil der Anforderungen“, antwortet Philipp. „Solange das Projektziel klar ist, kann man die einzelnen Produktspezifikationen unmittelbar vor der nächsten Phase detaillieren. Wichtig ist, dass alle Seiten diese Produktspezifika- 46 WISSEN PM_2-2014_1-68: Inhalt 26.03.2014 11: 41 Uhr Seite 46 Damit erfolgreiche Projekte nicht auf Hoffnung basieren. Seminare für Projektmanager: «Agiles Projektmanagement für Innovationsvorhaben» vom 13. - 14. Mai 2014; «Project management I - Methodology and Tools» (engl.) vom 19. - 21. Mai 2014; «Strategisches Prozessmanagement ist Chefsache» vom 16. - 17. Juni 2014; «Projektmanagement II - Projektleitung und Teamführung» vom 25. - 27. Juni 2014. Details sowie weitere Themen finden Sie unter: www.bwi.ch Anzeige projekt MA N A G E M E N T aktuell 2/ 2014 l 47 Darauf erklärt Siggi: „Das kann man natürlich machen, eine Projektbewertung kann zum Beispiel als Produkt in den letzten Sprint aufgenommen werden. Scrum ist ja ein Prozess für das Team. Deshalb sagt Scrum nichts zum Projektabschluss. In der Praxis sehe ich häufig zwei Situationen. In der ersten Situation erstellt ein Lieferant für seinen Kunden ein Produkt zu einem bestimmten Termin. Die Leistung wird sprintweise geliefert oder verfeinert. Am Ende wird die Zusammenarbeit wie vorher vertraglich vereinbart beendet. Die andere Situation ist, dass das Team auch nach der ersten Entwicklung für das Produkt verantwortlich bleibt. Neben den Entwicklungsaufgaben muss es nun Zeit für Fehlerbehebung im Betrieb reservieren. Vielleicht wäre dieser PRINCE2-Prozess für den Projektabschluss eine gute Ergänzung für ein Scrum-Projekt? Wie läuft denn diese letzte Projektphase bei PRINCE2 in der Praxis? “ „Am Schluss wird es gerne hektisch“, antwortet der PRINCE2-Berater, „weil noch viele Leute Änderungswünsche durchsetzen wollen. Da helfen die festgelegten Test- und Abnahmekriterien. Wie ist denn das eigentlich bei Scrum? Der Product Owner vertritt ja alle Stakeholder. Was ist denn, wenn es ihm nicht gelingt, deren unterschiedliche Interessen unter einen Hut zu bringen? Also, die einen sind am Schluss zufrieden und die anderen nicht.“ „Das Schöne an Scrum ist, dass die betroffenen Parteien früh Feedback bekommen. Deswegen arbeiten wir mit sehr kleinen User Storys, damit man schon früh etwas zeigen kann“, sagt Siggi. „Wir wollen nicht monatelang warten. Der Product Owner sieht den aktuellen Stand nach jedem Sprint. Es steht im frei, jederzeit weitere betroffene Parteien zum Review oder zu einer eigenen System-Demo einzuladen. Entweder beendet man das Projekt oder es bekommt neue User Storys, mit denen es sich in die Richtung entwickelt, die für alle Beteiligten ein guter Kompromiss ist.“ Philipp überlegt: „Ich glaube, es gibt einen Weg, wie wir zusammenarbeiten können. Wir können unsere Methoden nicht einfach vermischen, aber sie haben ähnabschließen und was hindert mich daran, etwas fertigzustellen? Jegliche fachliche Diskussion und Abklärung muss außerhalb des Dailys stattfinden. Wenn Sie das beachten, dann können Sie ein Daily in jedem Umfeld nutzen.“ Philipp ist jetzt neugierig geworden: „Bei Scrum gibt es doch auch den Scrum Master. Was macht der eigentlich genau? “ „Der Scrum Master muss einfach sicherstellen, dass sich alle an die Spielregeln halten. Zudem räumt er Hindernisse aus dem Weg. Ich denke, dass jeder Projektleiter ein Auge auf diese Dinge hat“, erklärt Siggi. Philipp stimmt zu: „Ja klar, Spielregeln und erfolgreiche Kommunikation sind essenziell. Für einen PRINCE2- Projektmanager gehört das eher ins Tagesgeschäft der Teams, an die die Aufgaben via Teammanager delegiert werden. Die Teams werden als Lieferant gesehen, diese haben einen eigenen Vertreter im Lenkungsausschuss, den Lieferantenvertreter. Ich habe eine weitere Frage. Können Sie mir erklären, wie bei Scrum ein Projekt endet? Bei PRINCE2 gibt es innerhalb der letzten Projektphase einen eigenen Prozess für das Abschließen eines Projekts. Nachdem die Produkte entsprechend ihrer Spezifikation gebaut, getestet und abgenommen sind, werden diese an die Nutzer übergeben. Hat Scrum ähnliche Mechanismen für die erfolgreiche Übergabe an die Linie? “ Siggi antwortet: „Bei Scrum haben wir keinen Prozess für das Projektende. Der Product Owner entscheidet, wann er mit dem gelieferten Wert zufrieden ist. Wir arbeiten bei Scrum in sehr kurzen Phasen, den sogenannten Sprints. Die erstellten Produkte werden direkt im Sprint getestet und ausgeliefert. Wenn nun ein weiterer Sprint keinen zusätzlichen Nutzen mehr bringt, fängt der PO auch keinen neuen Sprint mehr an. Dann ist das Projekt zu Ende.“ Philipp ist erstaunt: „Gibt es denn keine formale Abnahme des Projekts oder so etwas wie eine Entlastung für die einzelnen Rollen, einen Übergang von Leistung zu Gewährleistung und eine Projektbewertung? “ PM_2-2014_1-68: Inhalt 26.03.2014 11: 41 Uhr Seite 47 Haftungsausschluss Die Inhalte dieser Zeitschrift werden von Verlag, Heraus geber und Autoren nach bestem Wissen und Gewissen erarbeitet und zusammengestellt. Eine rechtliche Gewähr für die Richtigkeit der einzelnen Angaben kann jedoch nicht übernommen werden. Gleiches gilt auch für die Websites, auf die verwiesen wird. Es wird betont, dass wir keinerlei Einfluss auf die Inhalte und Formulierungen dieser Seiten haben und auch keine Verantwortung für sie übernehmen. Grundsätzlich gelten die Wortlaute der Gesetzestexte und Richtlinien sowie die einschlägige Rechtsprechung. Jens Kö 22 l projekt MA N A G E M E N T aktuell 2/ 2014 [6] Ward, J./ Daniel, E.: Benefits Management : How to Increase the Business Value of Your IT Projects. New York 2012 Schlagwörter hybride Projektmanagementmodelle, Kombination von PM-Methoden, PRINCE2, Rollenverteilung bei der Kombination von PRINCE2 und Scrum, Scrum Kompetenzelemente der NCB 3.0 4.1.3 Projektanforderungen, 4.1.6 Projektorganisation, 4.1.15 Änderungen, 4.1.11 Projektphasen, Ablauf und Termine Autor Jürgen Lackinger, Dipl.-Ing., MBA, arbeitet seit mehr als 20 Jahren sowohl praktisch als auch theoretisch an Multiprojekt-, PMO- und Projektmanagementthemen. Der Schwerpunkt seiner Aufgaben liegt in IT-, Rollout- und Change-Projekten mit besonderer Berücksichtigung der Kommunikation und Abstimmung zwischen IT und Fachbereich (z. B. Anforderungsmanagement). Der Autor ist nach den vier wichtigsten PM-Standards (IPMA, PMI, PRINCE2, Scrum) zertifiziert und arbeitet als freiberuflicher Programm- und Projektmanager, PM-Consultant und PM-Trainer. Anschrift E-Mail: J.Lackinger@gmx.net Autor Jan Fischbach, Dipl.-Ing., ist Geschäftsführer und Berater der Organisationsberatung Common Sense Team GmbH in Karlsruhe. Er hat umfangreiche Projekterfahrungen in den Bereichen Informationstechnologie, Dienstleistungen und Medien gesammelt. Er hilft seinen Kunden dabei, passende Strukturen für das Projektmanagement zu schaffen. Besonderer Schwerpunkt ist das Erstellen von Projektprofilen. Der Autor ist Mitglied der GPM und nach PRINCE2, Scrum und Scaled Agile Framework zertifiziert. Anschrift E-Mail: J.Fischbach@commonsenseteam.de Blog: www.teamworkblog.de liche Prinzipien und sie haben Schnittstellen. Zusammen können wir mehr erreichen als getrennt.“ „Ja, von den Prinzipien passt es. Wir wollen Ergebnisse liefern und wir haben klare Rollen. Bei Scrum heißt es ‚inspect and adapt‘. Das können wir auch hier ausprobieren.“ Philipp hat eine Idee: „Sie interessieren sich doch vor allem für den Softwareteil. Warum übernehmen Sie nicht die Rolle des Scrum Masters für das Entwicklungsteam? Für mich sind Sie der Lieferantenvertreter des Entwicklungsteams. Ich kümmere mich um die restliche Organisation und sorge dafür, dass der Benutzervertreter die Aufgaben wahrnimmt, die Sie von einem Product Owner erwarten. Ich helfe ihm dabei, den Mehrwert zu formulieren, damit der Kunde einen soliden Business Case hat [6]. Außerdem möchte ich gern versuchen, die Anforderungen in Form von User Storys zu formulieren. Jetzt hätte ich mit Ihnen ja einen Experten, der mir dabei helfen kann. Was meinen Sie? “ Siggis Augen leuchten auf: „Ja, lassen Sie es uns ausprobieren. Sicherlich müssen wir uns die Details genauer ansehen. Aber ich glaube, das funktioniert. Wir bedienen so die Bedürfnisse der Softwareteams. Und wir haben klare Schnittstellen zum Rest der Organisation. Wenn wir im Projekt iterativ vorgehen, können wir auch schon früh Ergebnisse liefern und Risiken senken. Das würde dem Kunden sicher gefallen. Ich muss zugeben, dass ich an PRINCE2 viele agile Aspekte entdecke.“ Auch Philipp kann S™crum etwas abgewinnen: „Ich sehe jetzt, dass Scrum doch ziemlich strukturiert ist und wirtschaftlich denkt. Ich schlage vor, dass wir uns morgen unsere Angebote gemeinsam ansehen und daraus ein neues machen. Lassen Sie uns darauf anstoßen - Prost! “ ■ Literatur [1] Commerce, Office of Government: Erfolgreiche Projekte managen mit PRINCE2 ™ . The Stationery Office, London 2009 [2] Rubin, K. S.: Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston 2012 [3] Richards, K.: Agile project management: running PRINCE2 projects with DSDM Atern. The Stationery Office, London 2007 [4] Snowden, D./ Boone, J.: A Leader’s Framework for Decision Making. In: Harvard Business Review, November 2007, S. 69-76 [5] Shenhar, A. J./ Dvir, D.: Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation. Boston, Massachusetts 2007 48 WISSEN PM_2-2014_1-68: Inhalt 26.03.2014 11: 41 Uhr Seite 48 P riesberg berichtet aufgeregt von seinem neuen Auto. „Ich habe es heute vom Händler abgeholt und es fährt tatsächlich einwandfrei. Ich denke, dass ich die Werkstatt erst wieder in einem Jahr bei der ersten Inspektion sehen werde.“ Seine Miene verfinstert sich und er fährt fort: „Leider ist mein Logistikprojekt in der Probenverschickungsabteilung ein ziemliches Desaster. Ich bin sprichwörtlich mit dem neuen IT-Tool ständig in der Werkstatt. Wir haben offensichtlich einen falschen Arbeitsablauf der Probenverschickung erarbeitet. Eigentlich sollen die Proben jetzt mit dem neuen IT-Tool verschickt werden, aber es funktioniert nicht so recht. Jetzt frage ich mich, ob wir den Job nicht hätten besser machen können.“ Ehrlich wundert sich über das Mitteilungsbedürfnis seines Kollegen - das Projektergebnis belastet ihn tatsächlich. Er fragt: „Wie erfahren ist die Abteilung in Dingen wie Arbeitsprozesserfassung und IT-Unterstützung? “ Priesberg überlegt: „Nicht allzu sehr. Es wurde bislang mit ‚Papier und Bleistift‘ gearbeitet, die Mitarbeiter kennen die Arbeitsabläufe blind, ohne sie explizit zu nennen. Das Wissen darüber ist auf einige Köpfe verteilt, die sich die Bälle zuspielen.“ „Also sind praktische Erfahrungen mit IT-Systemen und das explizite Aufschreiben von Arbeitsabläufen für die beteiligten Personen unbekanntes Terrain“, resümiert Ehrlich. „So kann man es sagen. In den Workshops zur Erarbeitung der Prozesskette hatte ich zuletzt den Eindruck gewonnen, dass viel zu viel theoretisiert wird. Es ging am Ende nur noch um ,Was-wäre-wenn-Szenarien‘. Selbst Live-Tests des Systems in Teilgruppen konnten keine spürbare Verbesserung mehr bringen“, gibt Priesberg resigniert zu. „Und somit muss man hinaus in die Praxis. Das implementieren und ausrollen, was man als Anforderung ermittelt hat“, unterbricht ihn Ehrlich. „Dann aber startet man wissentlich mit etwas Falschem und Unvollständigem. Das geht doch nicht“, ruft Priesberg dazwischen. „Es ist bei einem IT-System, das für eine spezielle Abteilung entwickelt wurde, also einem Spezialprodukt, in der Regel anders, als mit deinem Wagen. Der konnte vor der ersten Serie ausgiebig getestet und als fertiges Produkt ausgeliefert werden, das Wissen dazu hat der Hersteller.“ Priesberg stutzt einige Zeit, sein Gesicht besteht aus lauter Fragezeichen. Ehrlich fährt fort: „Starte mit dem neuen Prozess im neuen IT-System. Jetzt haben die Mitarbeiter erstmalig etwas Konkretes. Erfasse alle Abweichungen vom tatsächlichen Prozess an einer zentralen Stelle. Daraus kannst du in wenigen Workshops die fehlenden Anforderungen effizient erarbeiten. Setze diese dann schrittweise um. Wichtig ist, dass du all das den Beteiligten klarmachst. Die meisten werden sich darüber wundern, mit einem offensichtlich unvollständigen Prozess zu starten, und darüber sogar pikiert sein.“ „Also geht man hier zu einer agilen Vorgehensweise über“, kommentiert Priesberg. „Ja, das stimmt. Man ist zu Beginn eines großen Projekts meist im ‚Wasserfallmodus‘, um die Anforderungen und die Arbeitsprozesse zu erfassen und anschließend zu implementieren. Schließlich muss man aber die Anpassungen am lebenden System vor Ort vornehmen. Wichtig ist es, den Zeitpunkt zu erkennen, wann man von einem Vorgehensmodell in das andere umschwenkt“, schließt Ehrlich ab. „Also ist es keine Schande, nicht alles sofort und umfänglich zu wissen? “, fragt Priesberg erstaunt. „Man kann nur so viel wissen, wie es möglich ist, zu explizieren. Und das hängt von dem Erfahrungshintergrund aller Beteiligten ab. Ist dieser hoch, dann kann viel an Wissen explizit erfasst werden, ist dieser niedrig, dann muss erst Wissen erarbeitet werden, und das geht nur am lebenden Objekt“, resümiert Ehrlich, „da können sich Projekte deutlich unterscheiden. Und man sollte den fehlenden Erfahrungshintergrund unbedingt in der Projektplanung berücksichtigen. Wenn Wissen aufgebaut werden muss, dauern die Projekte erfahrungsgemäß länger, bei größeren Risiken. Auch dies sollte offen mit allen Beteiligten kommuniziert werden.“ „Also sollte man nicht die Erwartungshaltung an ein Serienprodukt auf einen neu etablierten Prozess mit IT- Unterstützung übertragen“, resümiert Priesberg, der sich jetzt spürbar besser fühlt. ■ Autor Dr. Jens Köhler ist bei der BASF SE beschäftigt. Sein Spezialgebiet ist die Erforschung der Effizienz- und Effektivitätssteigerung von Projektteams durch die gezielte Steuerung über Soft Skills und Kommunikationsprozesse. Anschrift BASF SE, D-67056 Ludwigshafen, Jens.Koehler@basf.com Projektgeschichten und Fallstudien Kolumne „Ehrlich und Priesberg“ Lieber mit einem falschen Prozess starten als mit gar keinem Prozess Die Kolumne möchte mit unterhaltsamen Dialogen rund um das Thema „Mensch - Kommunikation, Verhalten, Entscheidung“ Denkanstöße für den PM-Alltag geben. Jens Köhler projekt MA N A G E M E N T aktuell 2/ 2014 l 49 PM_2-2014_1-68: Inhalt 26.03.2014 11: 41 Uhr Seite 49