eJournals PROJEKTMANAGEMENT AKTUELL 28/1

PROJEKTMANAGEMENT AKTUELL
pm
2941-0878
2941-0886
UVK Verlag Tübingen
11
2017
281 Gesellschaft für Projektmanagement

Das Projekt, das sich selbst erfand

11
2017
Oliver Steeger
Projektaufträge brauchen eine klare Zieldefinition. Diese Grundregel ist in jedem PM-Lehrbuch nachzulesen. Soweit die Theorie. Ein Team der Swisscom bewies, dass man auch ohne klare Zielspezifikation erfolgreich ein Projekt durchführen kann. Seine „Story“: Das Schweizer Telekommunikationsunternehmen brauchte dringend ein neues Rechenzentrum. Doch statt sofort zu bauen, stellte das Unternehmen die Geschäftsstrategie für seine Data Center auf den Prüfstand. Die alles beherrschende Frage: Wie kann das Unternehmen künftig mit seinen Data Centern noch profitabler arbeiten? Und welche Art von Infrastruktur braucht es wirklich? „Schauen Sie mal, was wir wirklich brauchen“ - dies war 2009 der Projektauftrag an Programmleiter Beat Straub. Aus diesem Keim entwickelte er ein Programm mit Strategieprojekten, Organisationsprojekten, Changeprojekten, IT-Projekten und Bauprojekten. Die Assessoren des Deutschen Project Excellence Awards waren im vergangenen Jahr tief beeindruckt von dieser enormen Leistung; das Programm der Swisscom wurde mit dem Deutschen Project Excellence Award prämiert. Im Interview berichtet Beat Straub und erklärt, wie sich dieses Programm unter dem Namen „SCOUT“ quasi am eigenen Schopf aus dem Sumpf zog und sich dabei selbst erfand.
pm2810003
Projektaufträge brauchen eine klare Zieldefinition. Diese Grundregel ist in jedem PM- Lehrbuch nachzulesen. Soweit die Theorie. Ein Team der Swisscom bewies, dass man auch ohne klare Zielspezifikation erfolgreich ein Projekt durchführen kann. Seine „Story“: Das Schweizer Telekommunikationsunternehmen brauchte dringend ein neues Rechenzentrum. Doch statt sofort zu bauen, stellte das Unternehmen die Geschäftsstrategie für seine Data Center auf den Prüfstand. Die alles beherrschende Frage: Wie kann das Unternehmen künftig mit seinen Data Centern noch profitabler arbeiten? Und welche Art von Infrastruktur braucht es wirklich? „Schauen Sie Team von Swisscom ist Preisträger beim Deutschen Project Excellence Award Das Projekt, das sich selbst erfand Autor: Oliver Steeger Foto: Swisscom Beat Straub Beat Straub (55), Dipl.-Elektroingenieur, startete seine Laufbahn in der Präzisionsmaschinenindustrie im Bereich mechatronische Forschung und Entwicklung. Nach 13 Jahren wechselte er in den Bereich Luftfahrt und leitete fünf Jahre lang mehrere große nationale und internationale Entwicklungs- und Migrationsprojekte unter anderem in den USA und Südafrika. In den nächsten zehn Jahren folgten als Programmleiter weitere bereichsübergreifende Programme für die Swisscom IT-Services AG und die Swisscom (Schweiz) AG. Er erwarb sein PM-Wissen bei der IPMA und hält das IPMA Level- Asowie das IPMA Level-B-Zertifikat. Darüber hinaus ist er Assessor für IPMA-Zertifizierungen und war Programmleiter SCOUT, Preisträger des Deutschen Project Excellence Awards 2016. Foto: Swisscom mal, was wir wirklich brauchen“ - dies war 2009 der Projektauftrag an Programmleiter Beat Straub. Aus diesem Keim entwickelte er ein Programm mit Strategieprojekten, Organisationsprojekten, Changeprojekten, IT- Projekten und Bauprojekten. Die Assessoren des Deutschen Project Excellence Awards waren im vergangenen Jahr tief beeindruckt von dieser enormen Leistung; das Programm der Swisscom wurde mit dem Deutschen Project Excellence Award prämiert. Im Interview berichtet Beat Straub und erklärt, wie sich dieses Programm unter dem Namen „SCOUT“ quasi am eigenen Schopf aus dem Sumpf zog und sich dabei selbst erfand. projektManagementaktuell | AUSGABE 1.2017 REPORT 03 Herr Straub, da dürfte es auch hartgesottenen Projektmanagern die Schweißperlen auf die Stirn treiben, wenn Sie von den Anfängen Ihres Projekts erzählen. Sie sind ohne präzise Zielbestimmung, ohne Anforderungskatalog gestartet. Sie hatten keine Spezifikationen in der Hand, eigentlich nur einen Auftrag aus zwei, drei Sätzen. Solch einen Ausgangspunkt halten viele Projektmanager für ein Himmelfahrtskommando. Beat Straub: Vielleicht machen wir uns zunächst diese Ausgangslage deutlicher. Unser Unternehmen brauchte aus Sicht des Betriebs dringend ein neues Data Center, möglichst sofort, möglichst doppelt so groß wie die Bestehenden. Die dafür nötigen Investitionen lagen aber weit außerhalb unseres Betriebsbudgets. Unser CEO von Swisscom IT-Services AG rief mich zu sich … ehemals in staatlicher Hand wie etwa in Deutschland die Telekom … Richtig. Nach der Teilprivatisierung von Swisscom - der Bund hält noch immer gut 50 Prozent des Aktienkapitals - beschloss die Geschäftsleitung, die IT-Sparte eigenständig weiterzuführen. So entstand die Swisscom IT Services AG, die notabene vor zwei Jahren wieder in Swisscom integriert wurde. Die Swisscom IT Services hatte anfangs Swisscom als größten Kunden. Sie sollte allerdings wirtschaftlich auf eigenen Füßen stehen, und so hat die Swisscom IT Services auf dem Drittmarkt verschiedene Bank- und Industriekunden akquiriert. Von Swisscom hatte unser Unternehmen mit der Abspaltung mehrere Data Center quasi geerbt und zu diesem Zeitpunkt eines bereits erneuert. Mit den neuen Kunden kamen weitere Data Center hinzu - von einzelnen Räumen bis hin zu größeren Data Centern, die von uns betrieben wurden. Was ich hier grob beschrieben habe, war die Ausgangslage: Ein buntes Sammelsurium von Data Centern. Dies ging einige Zeit gut. Im Jahr 2009 aber trat die Betriebsorganisation unseres Unternehmens an unseren CEO heran: Die Data Center sind alt und voll. Wir brauchen dringend neue und qualitativ bessere Kapazität, ein neues Data Center. Sonst können wir die versprochene Qualität der Services nicht aufrechterhalten und keine neuen Kunden akquirieren. Augenblick! IT-Fachleute behalten in solchen Fällen einen kühlen Kopf: Es findet sich irgend- und bat mich zu prüfen, was man da machen kann. Einerseits wollte er nicht in etwas investieren, das außerhalb unseres Kerngeschäfts - dem IT-Outsourcing - lag. Andererseits musste dringend gehandelt werden. Der CEO gab mir den Auftrag zu schauen, wie dies möglich ist und welche Strategien geeignet sind. Bezeichnenderweise haben wir das Programm „SCOUT“ genannt. Es ging darum, Wege zu erkunden. Aber Sie haben Recht. Wir starteten ohne konkrete Zielvorgaben. Aus diesem „Schauen-Sie-mal“-Auftrag wurde am Ende ein sich über sieben Jahre erstreckendes Programm, das Ihr Unternehmen strategisch mitgestaltet hat. Ihr Team hat unter anderem bestehende Datenzentren geschlossen und ein völlig neues Rechenzentrum errichtet, das nicht nur IT-technisch zukunftsweisend ist, sondern beispielsweise auch umwelttechnisch weltweit neue Maßstäbe setzt. In Ihrem Programm waren Bauprojekte, IT-Projekte, Organisationsprojekte und strategische Projekte zusammengefasst. Diese rasante Entwicklung dürfte auch Experten erstaunen. Meine Frage: Wie konnte aus diesem kleinen „Schauen-Sie-mal“-Auftrag ein solch großes Programm werden? Für eine Antwort möchte ich etwas weiter ausholen und von unserem Unternehmen Swisscom AG berichten. Swisscom ist vergleichsweise groß, sie beschäftigt rund 19.000 Mitarbeiter - der größte Telekommunikationsanbieter in der Schweiz … Auch ein Eyecatcher - das Farbkonzept für Notfälle; Foto: Swisscom projektManagementaktuell | AUSGABE 1.2017 04 REPORT festzulegen. Wir befassten uns mit Demand und Capacity Management. Wir ermittelten Zahlen, entwickelten Modelle und erarbeiteten Prognosen, welche Kapazität wir in Zukunft wann und wo und in welcher Qualität brauchen. Aus diesen Zahlen leiteten wir das Programm ab und kamen zu dem Schluss, die gesamte IT in Zukunft nur noch in zwei modernen Data Centern zu betreiben und alle anderen Data Center zu schließen. Wir beschlossen, nur ein bestehendes Data Center zu behalten. Wir legten fest, dass ein neues Data Center gebaut werden muss und welche alten Data Center in welcher Reihenfolge migriert und geschlossen werden. Wir beschäftigten uns auf dieser Basis mit dem bereichsübergreifenden Risikomanagement für das Ganze. Aber zu Ihrer Eingangsfrage: Zu Beginn unseres Programms vor sieben Jahren wussten wir noch nichts von einem Neubau, von Migrationen und Schließungen und anderem. Was waren die großen Herausforderungen bei Ihrem Programm? Offen gesagt, dass der Tag nur 24 Stunden hat (lacht). Das war häufig das Hauptproblem. Also eine enorme Arbeitslast? Ja. Was die inhaltlichen Herausforderungen betrifft: Sie lagen in der Hauptsache beim Business Case. Letztlich ging es um Kostenoptimierung. Das Topmanagement hat uns im Grunde mitgeteilt: Wir sollten beim Betrieb der Data Center Kosten in einer gewissen Höhe reduzieren. Dies war der Kern - und die Herausforderung. nicht genau weiß, in welche Richtung man marschieren soll? Ich arbeitete mit meinem Team Szenarien und Varianten aus. Wir entwickelten alternative Szenarien, spiegelten sie gegeneinander und diskutierten sie mit den Verantwortlichen. Wir zeigten die Konsequenzen aus den Szenarien auf und ermittelten die Abhängigkeiten. Immer wieder befragten wir das Steering Board: Wollt Ihr die eine Variante oder die andere? So konnten wir schrittweise die Ziele schärfer fassen. „MEHRSPURIGES DENKEN“ ESSENZIELL Entscheidend war also das quasi mehrspurige Denken? Ja, mit Sicherheit. Dafür brauchen Sie natürlich die richtigen Mitarbeitenden. Wer nur bei klarem Start- und Endtermin bei klar definierten Zielen und festem Rahmen gut arbeiten kann, der eignet sich für solch ein Programm womöglich nicht. Meine Mitarbeiter mussten mit Unsicherheiten umgehen und trotz aller Unwägbarkeiten motiviert vorangehen. Wir alle mussten aushalten, dass der Weg vor uns selten klar bestimmt war. Um dies mit einem Bild zu beschreiben - Sie haben wie Münchhausen Ihr Projekt quasi am eigenen Schopf aus dem Sumpf gezogen … Richtig. Wir wussten nicht, was auf uns zukommt. Bis 2010 haben wir strategisch gearbeitet. Es ging darum, die Data Center-Strategie wo dann doch noch Kapazität. Selten sind die Racks und Server so randvoll, dass gar nichts mehr geht. Genau dies war dann auch eine der ersten Aufgaben in unserem Programm. Wir haben die Auslastung in diesem Sammelsurium von Data Centern genau geprüft. Das Unternehmen hatte zu diesem Zeitpunkt nicht wirklich den Überblick, wo was läuft und wie viel Kapazität noch frei ist. ÜBERBLICK ÜBER KAPAZITÄT UND AUSLASTUNG Was danach? Wir stellten eine Data Center-Strategie auf die Beine und erarbeiteten gemeinsam mit den Stakeholdern, wohin die Swisscom IT Services sich mit ihrer Data Center-Grundinfrastruktur strategisch entwickeln will, welche Qualität sie erbringen, welche Kunden sie als Zielgruppe suchen und welche Kunden sie wo managen will … Sind solche strategisches Überlegungen nicht Aufgabe des Topmanagements - statt eines Projekts? Diese Aufgaben übertrug uns das Topmanagement und beschrieb uns den Handlungsspielraum. Kehren wir bitte nochmals zur Eingangsfrage zurück: Ihnen fehlten anfangs greifbare Ziele. Wie kann man ein Projekt - oder wie in Ihrem Fall: ein Programm - aufsetzen, wenn man Das „Kühlsystem“; Foto: Swisscom projektManagementaktuell | AUSGABE 1.2017 REPORT 05 projektManagementaktuell | AUSGABE 1.2017 06 REPORT mindestens zwei Data Centern gespeichert haben. Vor dem Umzug können wir die Datenbestände auf den jeweiligen Servern so konsolidieren, dass sie überall absolut gleich sind. Dann wird der zu migrierende Server vom Netz genommen, neu aufgebaut oder umgezogen. Natürlich, während des Umzugs hängt alles am verbliebenen Server. Wir stehen während der Migration sicherheitstechnisch quasi auf einem Bein, das ist richtig. Deshalb brauchen wir einen erfahrenen Projektleiter, eine akribisch genaue Planung, möglichst kurze Unterbrüche, ein gutes Sicherheitsmanagement und natürlich die Bewilligung des Kunden für jede einzelne Migration. Sie haben einen Teil Ihres Programms beschrieben - den Workstream Migration. Sprechen wir bitte über den gesamten Aufbau Ihres Programms. Wie waren die anderen Workstreams gestaltet? Es handelte sich im Wesentlichen um sechs Workstreams. Der erste Workstream ging zeitlich voran; er hatte die Entwicklung eines wirklich umfassenden Capacity Managements auf Stufe der Data Center zur Aufgabe. Im zweiten Workstream ging es um die Frage, was mit den bestehenden Data Centern gemacht wird. Bauen wir neu? Verwenden wir die alten Center weiter? Der dritte Workstream hatte das Thema Server- und Datenmigration zum Inhalt. Im vierten Workstream haben wir ein völlig neues Data Center entwickelt und realisiert. Die Workstreams fünf und sechs beinhalteten die Entwicklung und die mussten wir klarmachen, dass es strategisch keinen Sinn ergibt, sofort zu bauen. Bevor wir weiter über Ihr Projektmanagement sprechen, gestatten Sie mir bitte eine technische Frage: Nimmt man neue Data Center in Betrieb, so müssen bestehende Daten dorthin „umziehen“. Dies nennt sich in der IT-Fachsprache Migration. Die Swisscom hat beispielsweise viele Banken als Kunden, also besonders stark auf Datensicherheit bedachte Unternehmen. Wie wird solch eine Datenmigration sicher abgewickelt? Die Server- und Datenmigration war ein zentrales Projekt oder ein „Workstream“, wie wir sagen, in unserem Programm. In diesem Workstream migrierten wir Tausende von Servern und einige Petabytes an Daten, teils mit starken potenziellen Auswirkungen. Stellen Sie sich nur vor, wenn die Geldautomaten einer Bank nach einer Migration nicht mehr erreichbar wären! Da darf nichts ausfallen. Hinsichtlich der Ausfallzeiten sind die Kundenverträge zudem sehr streng; ein oder zwei Minuten Ausfall können bereits massiv ins Geld gehen. DIE KUNST DER DATENMIGRATION Wie geht man vor bei der Migration? Bei der Migration können wir häufig den Vorteil nutzen, dass etwa Bankkunden ihre Daten in KOMPLEXITÄT - IN JEDER HINSICHT Ihr Projekt war technisch breit aufgestellt, verschiedene Disziplinen kamen zusammen. Vermutlich ebenfalls eine Herausforderung? Damit sprechen Sie die geforderte Breite des Themas an. Ich brauchte natürlich Mitarbeitende mit der Fähigkeit zum bereichsübergreifenden Denken. In dieser Phase musste ich leider auch Mitarbeitende auswechseln, weil sie der Belastung nicht standhielten oder nicht alle Themen gedanklich unter einen Hut bringen konnten. Also technische Komplexität? Nicht nur. Die Komplexität reichte weit über das Technische hinaus. Sie erstreckte sich beispielsweise auf das Stakeholdermanagement, dieses war schwierig und sehr komplex. Bedenken Sie: Unsere IT-Spezialisten hatten betriebliche Probleme mit den Data Centern. Es wurde eng auf den Servern und in den Racks, es kam bereits zu Ausfällen. Die Kollegen wollten sofort und schnell bauen - und nicht erst ein strategisches Projekt aufsetzen. Ich will damit sagen: Es gab gute Gründe für die Widerstände gegen unseren Plan, zunächst alles auf den Prüfstand zu stellen. Bei diesen Widerständen setzten wir im Stakeholdermanagement an. Wir mussten in unserem Unternehmen in kurzer Zeit alle ins Boot holen - und zwar top-down. Zunächst die C-Ebene, also CEO, CFO und andere. Danach die Bereichsleiter. Allen IT-Anlagen in Reih und Glied; Foto: Swisscom REPORT 7 projektManagementaktuell | AUSGABE 1.2017 Kompetenz für Fach- und Führungskräfte Zukunftsgestaltung für Unternehmen Durch passgenaue Lösungen und einzigartige Services erleichtert die Haufe Akademie die Zukunftsgestaltung von Unternehmen und die kontinuierliche Kompetenzerweiterung von Fach- und Führungskräften. www.haufe-akademie.de Profitieren Sie von topaktuellen Veranstaltungen zu Projektmanagement, Prozessmanagement und Change Management: • Praxisorientierte Seminare und Trainings • Intensive Qualifizierungsprogramme • Zertifizierte Lehrgänge • Hochwertige e-Trainings zum Direkteinstieg • Veranstaltungen zur Qualifizierung und Zertifizierung nach PMI ® , IPMA, PRINCE2 ® und Scrum (nach scrum.org) Ausführliche Informationen zu allen Themen und Veranstaltungen finden Sie unter www.haufe-akademie.de/ projekte-prozesse-change Damit ein Rädchen ins andere greift! Die Serverräume sind technologisch up to date; Foto: Swisscom projektManagementaktuell | AUSGABE 1.2017 08 REPORT von der Hochschule kamen; sie wollten nicht nach dem klassischen Wasserfallprinzip entwickeln. Sie wollten hoch greifen und agil arbeiten - oftmals ohne selbst genau zu wissen, wohin die Reise geht und um was es sich dabei handelt. Ich habe dies akzeptiert … … ohne dabei Bauchschmerzen zu spüren? Bei einigen Methoden hatte ich anfangs meine Bedenken. Aber ich lernte sehr schnell, dass meine Mitarbeitenden ihre Resultate in Termin und Budget erreichen. Was sollte ich da ändern? Dies ergibt keinen Sinn! Die Teams sind mächtig stolz darauf, dass sie so arbeiten dürfen, wie sie es für richtig halten. Sie wollen mir beweisen, dass sie Recht haben und die richtige Vorgehensweise gewählt haben. Sie sind damit hochmotiviert, angespornt durch diese Freiheit und die Eigenverantwortung, mit der sie ihre Resultate erbringen. Ich konnte sie mit dieser Wahlfreiheit quasi beim eigenen Ehrgeiz packen. Die Schweiz ist bekanntlich regional vielfältig. Spielt auch die schweizerische Grundhaltung eine Rolle, diese Freiheit weitestgehend zu ermöglichen? Projektmanagement. Verschiedene Ansätze existieren nebeneinander - und dies noch in jeweils unterschiedlichen Ausprägungen. NEBENEINANDER VON VERSCHIEDENEN PM-ANSÄTZEN? Mit Verlaub - ich bin mir nicht sicher, dass Verfechter einer einheitlichen Methodik dieses Argument gelten lassen. Man will ja gerade dieses Nebeneinander von Ansätzen harmonisieren. Richtig! Aber warum soll es falsch sein, die Teams mit den Methoden arbeiten zu lassen, die sie kennen und die sie für richtig halten? Ich habe meinen Projektleitern zu 99 Prozent Freiheit bei der Wahl der Methoden gegeben. Dies ist viel, das weiß ich. Unsere Bauprojekte wurden beispielsweise klassisch gemanagt. Beim Start unseres Programms hatten wir indes mit agilen Methoden Berührung, später noch viel mehr bei der Entwicklung der neuen Data Center-Netzwerkarchitektur. In diesem Workstream setzten wir primär junge Leute ein, die zum Teil direkt Umsetzung einer neuen Netzwerkarchitektur und den Rückbau alter Center. Viele Programmleiter achten darauf, dass in ihrem Programm ein einheitliches Projektmanagement verwendet wird. Dies vereinfacht beispielsweise die Ausrichtung der Projekte, die Kommunikation zwischen den Projekten oder das Controlling des Programms. Für Ihr Programm haben Sie einen gegensätzlichen Ansatz gewählt: Sie haben jedem Team die Freiheit gelassen, die Methoden zu wählen, die es für sinnvoll hielt - sowohl von der Art der Methoden als auch vom Umfang des Einsatzes her. So arbeitete ein Team mit klassischen Ansätzen, ein anderes mit agilen Methoden und Sie selbst haben für das Programmmanagement noch einen anderen Ansatz gewählt. Wie kam es zu der Entscheidung, diese Vielfalt im Programm zuzulassen? Sie kann ja zu babylonischem Sprachgewirr führen. An den verschiedenen Standorten unseres Unternehmens trifft man auf unterschiedlichste Kulturen, Sprachen und regionale Mentalitäten; auch hinsichtlich des Projektmanagements. So finden Sie bei der Swisscom kein einheitliches Das Zutrittssystem; Foto: Swisscom projektManagementaktuell | AUSGABE 1.2017 REPORT 09 Sie soll beispielsweise 30 Zentimeter dick sein, eine Höhe von 2,60 Meter haben und aus einer bestimmten Ziegelart gebaut werden. Bei Use Cases indes beschreiben wir nicht eine zu erfüllende Spezifikation, sondern wir erklären die Funktionalität. Für welchen Zweck wird die Mauer gebraucht? Was soll sie „leisten“, welche Funktion erfüllen? Dann können die Mitarbeiter selbstständig eine Lösung erarbeiten. Am Ende entwickeln sie eine Mauer, die vielleicht dünner als 30 Zentimeter ist, aus einem anderen Baustoff gefertigt wird - und darüber hinaus deutlich preiswerter. „GRUNDWÄHRUNG“ FÜR DAS GESAMTBILD Sie geben also das Ziel vor, nicht den Weg dorthin? Genauer gesagt: Nicht eine Spezifikation, sondern die erforderliche Funktionalität. Alles andere überlassen wir dem Team. Sie setzen auf dessen Erfindungsgabe? Ja, richtig! Durch Use Cases können völlig neue Lösungsansätze entstehen. Diesen Weg der beschreibenden Art finde ich sehr spannend; man geht bei der Entwicklung nicht vorschnell in die Lösung. Dadurch werden Innovationen möglich! bringen - quasi die verschiedenen Währungen miteinander zu verrechnen? Dafür brauchen Sie eine Art übergeordnete „Grundwährung“, in die umgerechnet wird. Eine Methode, mit der Sie die Informationen aus den Projekten vergleichbar machen und in Beziehung setzen können. Vermutlich, ja. Was tun? Offen gesagt, in diesem Punkt haben auch wir Lehrgeld bezahlen müssen. Einige Teams konnten oder wollten ihren präzisen Status nicht benennen. Sie wollten nicht einmal genau beschreiben, was sie gerade entwickeln. Sie wollten von Sprint zu Sprint weiterkommen und das Ziel offen lassen. Da gab es natürlich heftige Diskussionen. Wir haben daraufhin die Sprache unserer Zieldefinition näher betrachtet und diese Schwierigkeiten durch eine einheitliche Sprache gelöst. Konkret: Wir beschrieben Ziele beispielsweise durch Use Cases. Diese Use Cases waren quasi die gemeinsame Währung. Use Cases - was darf ich mir darunter vorstellen? Mit Use Cases konnten wir die Ziele auf neue Weise für alle Methoden präzise und „hart“ formulieren. Ein Beispiel: Beim Bau wird eine Mauer gebraucht. Man kann das Ziel des Mauerbaus beschreiben, indem man die Mauer spezifiziert. Ja, natürlich! Bei meiner Herangehensweise handelt es sich um einen gut schweizerischen Approach. Wir lernen schon sehr früh, mit verschiedenen Kulturen und Sprachen umzugehen. In unserem Land wird ja französisch, italienisch, deutsch und romanisch gesprochen, daher einigten wir uns oft auf Englisch; die Mentalität kann sich regional massiv unterscheiden. Bei all dieser Freiheit - solch ein Programm muss vermutlich straff geführt werden … Da haben Sie Recht. Bei den Resultaten hatten meine Projektmanager wenig Spielraum. Wir definierten gemeinsam klare Synchronisationspunkte, die erreicht werden mussten. Anhand dieser Punkte konnten wir jederzeit sehen, wie es im Programm vorangeht. Diese Synchronisation stelle ich mir wegen der Methodenvielfalt schwierig vor. Das eine Team arbeitet agil, das andere nach dem Wasserfallmodell, ein drittes mit hybriden Ansätzen. Gestatten Sie mir, dies mit verschiedenen Währungen zu vergleichen. In Ihrem Projekt waren quasi verschiedene Währungen in Umlauf, etwa beim Reporting des Status. Das eine Team meldet, es befindet sich im dritten Scrum-Sprint. Das andere Team meldet, es habe einen Fortschritt von 37 Prozent erreicht. Wie gelang es Ihnen, diese unterschiedlichen Informationen zu einem stimmigen Gesamtbild zusammenzu- Die hybride Kühlung mit „Umweltbonus“; Foto: Swisscom projektManagementaktuell | AUSGABE 1.2017 10 REPORT holdern. Nach dem Festlegen der Zielvorgabe beginnen die Teams zu arbeiten. Ich erwarte dabei, dass sich die Teams umgehend melden, wenn sie erkennen, dass sie auf dem eingeschlagenen Weg nicht weiterkommen oder nur schon nicht weiterkommen könnten. Dafür ist offene Gesprächskultur nötig. Richtig! Nicht nur offene Gesprächskultur, sondern auch eine Kultur, die Fehler zulässt. Die Teams dürfen sich verrennen. Sie dürfen Fehler machen und lernen. Selbstverständlich sollten sich Fehler nicht wiederholen, aber dies ist eben der Drahtseilakt der Führung, zwischen laufenlassen und korrigierend eingreifen. Die Führung muss die Balance halten zwischen Vertrauen, Kontrolle und gelegentlicher Härte. Härte? Ja, Härte. Ich musste einige Male entscheiden, dass ein eingeschlagener, innovativer Weg nicht weiterverfolgt wird, weil er nicht mehr ins Gesamtkonzept passte - obwohl er am Ende vielleicht zum Ziel geführt hätte, vielleicht sogar zu einer besseren Lösung, aber leider zu spät. Bei einigen Use Cases haben wir bewusst zwei oder mehr Teams parallel Lösungsvarianten erarbeiten lassen. Wir machten den Teams dabei deutlich: Ihr verfolgt Variante A, ein anderes Team verfolgt Variante B. An einem festgesetzten Tag entscheiden wir, welchen Lösungsansatz wir wählen und weiter verfolgen. trieb mehr, wir arbeiten ausschließlich mit Schwungmassen als Energiespeicher. Nochmals zu unserem Ausgangspunkt: Wie ermöglichen Use Cases ein einheitliches Ziel- Controlling über verschiedene PM-Methoden hinweg? Wie ist der „Währungsumrechner“ gestaltet, von dem wir eben sprachen? Die Teams melden ihren Fortschritt immer bezogen auf die vereinbarten Use Cases. Sie können etwa melden: Wir haben 60 Prozent der beschriebenen Funktionalität erreicht, mit unseren Kosten liegen wir bei 85 Prozent und der Terminplan bleibt unverändert. Die dahinterliegende Methode spielt dabei keine Rolle, und sie beeinflusst diese Zahlen nicht. Diese Art von Harmonisierung der Zieldefinition ist ein großer Vorteil. Für wichtig halte ich, dass man mit dieser Arbeitsweise sehr schnell zu neuen und innovativen Lösungen kommt. Dies passiert aber nur, wenn man den Teams auch den entsprechenden Freiraum gibt. Ich persönlich finde diesen Weg interessant und herausfordernd. REIFE FEHLERKULTUR Herausfordernd - inwiefern? Heraus insbesondere aus Sicht der Führung. Die Führung mit Use Cases setzt viel Vertrauen voraus, übrigens auf allen Seiten, nicht nur vom Projektmanager, sondern auch von allen Stake- Das Beispiel mit der Mauer ist einfach. Wie haben Sie durch Use Cases konkret innovatives Potenzial entfalten können? Wir benötigten im neuen Data Center Räume für Rechner in einer bestimmten Größe und für eine bestimmte technische Leistung. Solche Räume müssen gekühlt werden. Normalerweise legt man in der Spezifizierung auch die Leistung der Klimaanlage fest; fast automatisch werden strombetriebene Klimageräte eingeplant. Wir aber haben genau dies in unserem Use Case offengehalten. Der Use Case beschrieb: Wir haben es in diesem Raum mit einer Rechnerleistung in einem bestimmten Bereich zu tun und dafür brauchen wir eine Kühlung. Das Team sollte prüfen, wie sich dies bewerkstelligen lässt. „USE CASES“ ENTFALTEN POTENZIAL Die Bauingenieure kamen mit völlig neuen Ansätzen … Nicht mit völlig neuen Ansätzen, doch sie haben Bekanntes für unseren Zweck innovativ adaptiert, sodass wir heute für die Kühlung keine aktiven Kühlgeräte mehr benötigen. Wir bunkern im Keller unseres neuesten Data Centers knapp zwei Millionen Liter Regenwasser, mit welchem wir an heißen Tagen unsere Anlage kühlen, natürlich indirekt (lacht). Bei uns gibt es auch keine Bleibatterien und Säuren für den Notbe- Der Maschinenraum - noch leer; Foto: Swisscom REPORT 11 projektManagementaktuell | AUSGABE 1.2017 Bei dieser Vorgehensweise sind Zielkonflikte kaum zu vermeiden. Wie sind Sie mit diesen Konflikten umgegangen? Bei Zielkonflikten fragten wir uns: Wie sieht es mit dem gesamten Szenario aus, ist es im Grundsatz akzeptiert? Dann die Frage: Handelt es sich bei Zielkonflikten um Versäumnisse bei der Planung? Oder sind es neue Erkenntnisse, die zu Veränderungen führen? Danach haben wir das klassische Änderungsmanagement - oder Changemanagement - eingesetzt. Auf diese Weise haben wir nicht nur Zielkonflikte bearbeitet, sondern alle Veränderungen im Projekt. Die Welt drehte sich ja weiter in den Jahren zwischen 2009 und 2016. Das heißt, es gab einigen Gegenwind unterwegs? Klar, das lässt sich bei dieser Zeitspanne nicht vermeiden. Beispielsweise wurde unser Unternehmen in dieser Zeit wieder in die Swisscom integriert, also quasi „zurückgeholt“. Solche Veränderungen in der Organisation haben signifikanten Einfluss auf das Programm. Wir mussten ermitteln, welchen Einfluss solche Ereignisse auf unsere Ziele und unsere Vorgehensweise hatten. Passte noch alles zueinander? Wenn nein, wie sollten, konnten und mussten wir reagieren? Ein Programm ist zwar wie ein großer Tanker, doch im Gegensatz zu einem Tanker muss es schnell den Kurs ändern können. Entscheidend bei alledem ist: Das Steering Board muss diese Kursän- Dies erzeugt Frustration bei denen, die in diesem „Wettstreit“ unterliegen. Wie kann man dann trotz dieser Enttäuschung die Motivation aufrechterhalten? Sie sagen es richtig, diese Vorgehensweise hat den Charakter eines Wettrennens - und bei jedem Wettrennen gibt es Gewinner und Verlierer, dies ist nun einmal so. Entscheidend ist dabei Transparenz. Die Teams müssen wissen, dass es sich um ein Wettrennen handelt und dass sie gewinnen oder verlieren können - auch, wenn ihre Arbeit maßgeblich beiträgt zur Lösungsfindung. Wie haben Sie Vorsorge getroffen, dass der „Verlierer“ nicht frustriert ist und die Lust an der Projektarbeit verliert? Den Frust können Sie nicht beiseiteschieben oder schönreden. Er ist einfach da. In unserem Programm begleitete ich die Teams jeweils durch diesen Frust und gab ihnen neue Herausforderungen und Ziele. Zudem versuchten wir, so früh wie möglich zwischen den Varianten zu entscheiden - damit aus dem Wettstreit kein Überzeugungskampf wurde. Danach haben wir die Mitarbeiter sofort wieder ins Projekt integriert und sie weiterlaufen lassen. Im Übrigen feierten wir die „Siegesfeier“ mit allen Beteiligten und alle bekamen die gleiche Erfolgsprämie. Ich möchte nochmals den Startpunkt Ihres Programms zum Thema machen. Wir haben festgehalten, dass Sie ohne genaue Ziele und Spezifikationen ins Projekt gestartet sind. Sie haben Szenarien entwickelt und zur Entscheidung vorgelegt. Was mir noch nicht klar ist - wie sind Sie zu den Szenarien gekommen? Wir wählten einen klassischen Strategieansatz. Wie bereits gesagt, die Vorgabe war im Grunde die Senkung von Kosten, was dazu führte, dass wir alle Varianten auf die Kosten reduzierten und so miteinander vergleichen konnten. Zentral war daher die Frage: Wo stehen wir mit den Kosten heute und wo will unser CEO in fünf oder in zehn Jahren mit den Kosten stehen? KLASSISCHER STRATEGIEANSATZ Daraus ergab sich vermutlich ein „Delta“, eine Lücke zwischen Ist- und Soll-Zustand … Ja, und wir überlegten uns, wie wir dieses Delta schließen können. Was können und müssen wir tun, um die Kosten zu senken? Wie müsste der Betrieb gestaltet sein, damit zukünftig überhaupt in dem geforderten Kostenrahmen gearbeitet werden kann? Daraus leiteten wir die unterschiedlichen Szenarien ab - und haben das Steering Board darüber laufend entscheiden lassen. Mit diesen Entscheidungen verfeinerten wir die Varianten nach und nach. Auf diese Weise gelangten wir zu präzisen Spezifikationen für unser Vorhaben. Das Modell des neuen Data Centers; Foto: Swisscom projektManagementaktuell | AUSGABE 1.2017 12 REPORT Komplexität vereinfachen, eine für Stakeholder nachvollziehbare Methodik, Kardinaltugenden wie Transparenz, Offenheit und Wahrhaftigkeit - auf diese Weise kann man also das Steering Board aktivieren und „führen“? Als Instrument für diese „Führung“, wie Sie sagen, habe ich primär das Risikomanagement verwendet. Risikomanagement war überhaupt ein zentrales Führungsinstrument in meinem Programm. Wie kann man mit Risikomanagement führen? Ein aktives Risikomanagement hilft früh zu erkennen, was ein Projekt oder Programm vom Kurs abbringen könnte. Dies kann z. B. eine technische Veränderung sein, das Verhalten von Personen oder Gruppen, eine Veränderung in der Umgebung oder ein organisatorischer Wandel. Die Frage ist dann: Welche Auswirkung hat die Veränderung? Und: Wie bringen wir das Vorhaben wieder zurück auf Kurs? Und: Wer kann was tun? Mit Risikomanagement kann man also „Handlungsbedarf“ anzeigen, wie dies neudeutsch heißt? Nach zum Teil intensiven Diskussionen stand hinter jedem Risiko namentlich ein Mitglied des Steering Boards. Durch diese Verknüpfung von Risiko und Personen machte ich Mitglieder des Steering Boards von Beteiligten zu Mitstreitern. Das Risikomanagement weist die Mitglieder darauf hin, tätig zu werden, das Programm aktiv zu unterstützen und Aufgaben in der Linienorganisation umzusetzen. Augenblick, bitte! Sie haben Ihre Methode auch unter dem Gesichtspunkt ausgewählt, wie Ihr Steering Board mit dieser Methode zurechtkommt? Ja, ich habe mich mit meiner Methode stark dem Steering Board und anderen Stakeholdern angepasst. Ich wollte nicht nur zeigen, was wir im Programm machen, sondern auch wie wir es machen. Diese Transparenz baut Vertrauen auf. Also habe ich dem Steering Board die Methode erklärt und mit ihm abgeglichen. RISIKOMANAGEMENT ALS FÜHRUNGSINSTRUMENT Moment! Viele Projektmanager wählen ihre Methodik allein nach den Anforderungen des Projekts aus … Jede Methode hat ihre Vorzüge und Nachteile. Für mich ist die Methodik keine Glaubenssache. Mich interessieren die Menschen weit mehr als die Methodik, die verwendet wird oder verwendet werden sollte. Mir ist es deshalb sehr wichtig, dass meine Stakeholder verstehen, wie ich mein Programm manage und wann sie was zu welchen Kosten und in welcher Qualität bekommen. Insofern habe ich dies bei der Methodenwahl berücksichtigt. Ist diese Methode verständlich? Hilft sie mir, meine Vorgehensweise verständlich zu machen? Denn nur durch die Transparenz bringen Stakeholder Verständnis und Vertrauen auf, auch wenn die Arbeiten mal nicht so laufen wie sie laufen sollten. derungen mittragen und der Linienorganisation vermitteln. Dies alles setzt voraus, dass das Steering Board aktiv am Projekt mitwirkt. Aus vielen anderen Projekten weiß man: Einige Steering Boards und Entscheider kommen ihren Aufgaben nicht ausreichend nach. Entscheidungen bleiben aus, dies lähmt das Projekt und führt zu Problemen. Wie haben Sie das Steering Board an sich gebunden und aktiviert? Zwei Punkte dazu: Zum einen müssen das Programm, die Vorgehensweise und die Statusberichte nachvollziehbar sein. Zum anderen muss Verbindlichkeit im Steering Board gewährleistet sein. AKTIVES STEERING BOARD Beginnen wir mit dem ersten Punkt, der nachvollziehbaren Kommunikation. Ihr Programm war fachlich und methodisch extrem komplex. Wie haben Sie diese Komplexität beim Dialog mit dem Board reduziert? Nach meiner Beobachtung tragen viele Programmleiter die Komplexität ihres Vorhabens ungefiltert zum Steering Board. Dies halte ich als nicht zielführend, denn dies überfordert die Mitglieder dieses Gremiums. Ich benutzte daher eine für das Steering Board zugeschnittene, nachvollziehbare Methode, um das Programm zu steuern. Mir ist dabei wichtig: Der Ansatz muss für das Steering Board verständlich sein. „SCOUT“ im Urteil der Assessoren Die Assessoren des Deutschen Project Excellence Awards waren beeindruckt von dem herausragenden Programm der Swisscom. Sie hoben drei Glanzleistungen besonders hervor. „Projektmanagement als Führungsinstrument“: Projektmanagement wurde als Führungsinstrument verstanden und dafür konsequent eingesetzt. Der Fokus ging dabei über die Programmgrenzen hinaus. Beteiligte Kollegen wurden aus einem eigens dafür vorgesehenen Budget weiterentwickelt, wovon langfristig auch die Stammorganisation profitiert. „Agil und Klassisch“: Agile und klassische Methoden wurden klug kombiniert und sinnstiftend eingesetzt. Dabei wurde Flexibilität bei den Methoden gezielt ermöglicht, um herauszufinden, was wirklich Mehrwert schafft. „Führungskräfte“: Die Führungskräfte haben in diesem Projekt ihre Vorbildrolle aktiv mit Herz und Seele gelebt. Mit einer gesunden Kombination aus Sturheit, Zielfokus und Wendigkeit wurde das Programm SCOUT aktiv gestaltet, um Chancen zu erkennen und zu ergreifen. Eine außergewöhnliche Kundenzufriedenheit belegt den Erfolg. Stakeholdermanagement live - eine Führung auf der Baustelle; Foto: Swisscom REPORT 13 projektManagementaktuell | AUSGABE 1.2017 Sehr gut sogar. Niemand im Board will vor seinen Kollegen zugeben, dass er seine Hausaufgaben nicht erledigt hat. Um bei Ihrem Beispiel zu bleiben: Im nächsten Steering Board wird die für Personalfragen zuständige Person von ihren Kollegen gefragt, ob sie Personal gemäß Protokoll bereitgestellt hat. Falls Entscheidungen ausblieben oder Aufgaben unerledigt blieben, dann gab es im Board lebhafte Diskussionen. So ähnlich kann man auch Mitarbeiter führen: Indem man ihre Arbeit und ihr Verhalten durch Risikomanagement analysiert und ihnen die Konsequenzen aufzeigt. Man kann auf diese Weise verdeutlichen, was passiert, wenn z. B. PM-Methoden nicht konsequent genug angewendet werden. INTENSIVES STAKEHOLDER- MANAGEMENT Das Risikomanagement war ein wesentliches Instrument bei Ihrer Programmleitung. Ein anderes wichtiges Instrument war, wie Sie ausführten, das Stakeholdermanagement … Programmleiter bitten Sie also nicht um mehr Personal, Sie lassen das Risikomanagement für sich sprechen? Im gewissen Sinne, ja. Und das funktioniert? Konkret: Im Steering Board werden die Ergebnisse des Risikomanagements besprochen. Ein willkürliches Beispiel: Es drohen personelle Engpässe, das Board erkennt diese Gefahr. Und ein Mitglied, das für Personalfragen zuständig ist, wird damit zur Aktivität aufgefordert. Als Strippenziehen im Projekt - nicht nur die Verkabelung der Server war hoch komplex. Foto: Swisscom projektManagementaktuell | AUSGABE 1.2017 14 REPORT Brücke zum Risikomanagement schlagen. Die Stakeholder werden dabei mit Risiken verknüpft. Danach wird überlegt, welche Maßnahmen aus den Erkenntnissen abzuleiten sind. ARBEIT MIT DER „STAKEHOLDER MAP“ Beispielsweise: Skeptiker des Projekts könnten mächtiger werden ... Genau. Was ist dann zu tun? Wie kann man diesem Risiko begegnen? Und: Wie kann etwa das Steering Board eingreifen? Mit der Stakeholder Map und dem Risikomanagement konnte ich das Board gut aktivieren. Es hat diese Vorgehensweise schnell verstanden. Und da es an der Planung mitgearbeitet hat, unterstützte es anschließend auch die Umsetzung. Ich möchte am Ende noch über ein weiteres Führungsthema mit Ihnen sprechen - und zwar eines, für das es kaum Werkzeuge gibt. Es geht um Ihre Rolle als Programmleiter. Wir haben immer wieder die Werte anklingen lassen, die Ihrem Handeln zugrunde lagen - bspw. Offenheit, Transparenz, Wertschätzung, ein hohes dann haben Sie eine gute Übersicht über Ihre aktuelle Situation bei den Stakeholdern. Klingt einfach … Ist so - die Methode ist einfach. Natürlich können Sie noch einen Schritt weiter gehen. Nehmen Sie das gleiche Bild mit den gleichen Kriterien und den gleichen Stakeholdern und überlegen sich, in welche Richtung Sie die einzelnen Stakeholder in Zukunft entwickeln möchten. Wo möchten Sie die Stakeholder haben? In welche Richtung soll es dabei gehen? Wie soll die Stakeholder Map in Zukunft aussehen? Sie kleben die Zettel mit den Stakeholdern also dorthin, wo Sie sie gerne haben möchten. Dann habe ich eine Map zum Ist-Zustand beim Stakeholdermanagement und eine zum Soll- Zustand. Richtig! Anschließend überlegen Sie, wie Sie die Stakeholder von A nach B bewegen, also vom Ist-Zustand zum Soll-Zustand. Sie entwickeln Maßnahmen dafür. Wie Sie es eben gesagt haben, die Methode ist leicht nachvollziehbar. Sie können die Map jederzeit etwa auch mit ihrem Team und dem Steering Board besprechen. Und von der Stakeholder Map können Sie sogar eine SCOUT hatte viele Stakeholder: innerhalb des Unternehmens, innerhalb des Konzerns, bei den Kunden oder mit Blick auf die Bauprojekte auch bei öffentlichen Stellen. Das Stakeholdermanagement war uns deshalb wichtig, es lag bei mir als Programmleiter; wir haben die Stakeholder-Akte immer wieder zur Hand genommen und Veränderungen in der Stakeholder Map verfolgt. Welche Stakeholder sind noch wesentlich? Welche sind neu hinzugekommen? Wie haben sich die Stakeholder bewegt, welche sind gewichtiger geworden, welche unwichtiger, welche unwichtiger aber trotzdem zu bearbeiten? Sie sprechen von einer „Stakeholder Map“ - um was handelt es sich dabei? Ich habe in den letzten Jahren ein Werkzeug für das Stakeholdermanagement entwickelt, die „grafische Stakeholder Map“. Mit ihr kann man Stakeholder einfach managen und entwickeln. Da bin ich gespannt. Wie gehen Sie vor bei der Arbeit mit der Stakeholder Map? Es handelt sich um ein grafisches Instrument. Stellen Sie sich einen Kreis mit Segmenten vor. Und dann definieren Sie Kriterien für Stakeholder. Es gibt wichtige und weniger wichtige Stakeholder; einige haben Einfluss und sind Meinungsmacher, andere sind noch völlig unentschlossen. Hat man auf diese Weise vier bis sechs für das Projekt bedeutsame Kriterien definiert, kann man die Stakeholder auf dieser Map gut positionieren. Konkret: Man schreibt den Stakeholder auf einen Klebezettel und bringt ihn im betreffenden Kreissegment an. Er wird damit einer bestimmten Eigenschaft zugeordnet. Nun kann man noch mehr festlegen: Beispielsweise je weiter ein Stakeholder im Zentrum dieses Kreises steht, desto wichtiger ist die Eigenschaft. Je weiter draußen, desto unwichtiger. Haben Sie alle Stakeholder auf diesem Kreis angeordnet, Für Projekte, die den Ton angeben Bewerben Sie sich bis zum 30. April 2017 beim Deutschen Project Excellence Award 2017 unter www.gpm-ipma.de/ DPEA Baubeginn an kalten Tagen: erste Vorbereitungen für den Neubau des Data Centers; Foto: Swisscom REPORT 15 projektManagementaktuell | AUSGABE 1.2017 Das klingt selbstverständlich … Nein, das ist bei einer Zeitstrecke von sieben Jahren überhaupt nicht selbstverständlich. Mitarbeitende so zu motivieren, dass sie auch eine Extrameile gehen, ist nicht einfach. Zwischendurch gab es auch bei uns immer wieder mal Durststrecken, dies gehört dazu; vielleicht kann man sich irgendwann auch einmal nicht mehr sehen. Trotzdem haben wir gemeinsam beispielsweise auch tiefgreifende Reorganisationen in unserem Unternehmen durchgestanden. MOTIVATION ÜBER SIEBEN JAHRE Eine Reorganisation mitten im Projekt? Ja, kleinere und größere Reorganisationen gab es einige und da stand je nach Ausmaß auch für meine Mitarbeitenden persönlich einiges auf dem Spiel. Oftmals konnte ich sie ein Stück weit über das Steering Board schützen. Anhand des Risikomanagements zeigte ich die Konsequenzen für den Fall auf, dass Mitarbeitende abgezogen oder noch schlimmer abgebaut würden. So konnten einige Mitarbeitende in SCOUT im Windschatten der Reorganisation arbeiten. Sie hatten insofern Glück, es blieb ruhig um ihren Arbeitsplatz. Also ein Geben und Nehmen? Ja, immer! Und genau deshalb können Sie sich sicherlich vorstellen, wie dankbar ich meinem Team nach sieben gemeinsamen Jahren für die großartige Leistung und Unterstützung bin.  Maß an Freiheit bei gleichzeitiger Verantwortung. Solche Werte werden im Team nur gelebt, wenn sie vorgelebt werden. Inwieweit waren Sie persönliches Vorbild bei Ihrem Programm? Die Vorbildfunktion, die Sie beschreiben, ist meiner Einschätzung nach zentral. Trete ich nicht authentisch und glaubwürdig auf, ist diese Art von Führung nicht möglich, wie ich sie Ihnen beschrieben habe. Die Authentizität ist also ein wesentlicher Erfolgsfaktor - und das betrifft nicht nur mich als Programmleiter, sondern alle Projektleiter, letztlich alle Mitarbeitenden. Jeder sollte dem anderen Vorbild sein. Was die Führungskräfte betrifft: Sie müssen im Team präsent sein. Wir hatten Großraumbüros an verschiedenen Standorten; ich war immer bei den Mitarbeitenden, nicht nur Tür an Tür, sondern mittendrin. Wir haben hart gearbeitet, sind aber auch gemeinsam essen gegangen, haben in Kaffeepausen zusammengesessen, Feste gefeiert. Und natürlich auch dann, wenn es im Programm nicht so gut lief. Ihr Programm hat sich über sieben Jahre erstreckt. Wie hält man seine Mitarbeiter über eine so lange Zeit motiviert? Leistungen dieser Art kommen nur mit einem hoch engagierten und motivierten Team zustande. Wir hatten rund 50 Personen im engeren Team, je nach Phase waren zwischen zehn und fünfzehn Personen in der Leitung. Entscheidend ist, dass all diese Menschen arbeiten wollen und nicht müssen, und zwar so, dass sie jederzeit gerne ins Büro kommen. REPORT 11 Anzeige PM-aktuell_2-2015_Inhalt_01-60.indd 11 27.03.2015 10: 39: 31 Uhr