Hand auf’s Herz: Wie viele Excel-Tabellen gibt es in euren Projekten? Ein paar Anregungen gefällig: Liste offener Punkte, Product-Backlog, Anforderungsliste, Controlling, Projektplan, Risikoliste. Diese Aufzählung ließe sich beinahe endlos fortsetzen. Jede noch so kleine Nische des Projektmanagements hat irgendjemand irgendwann schon einmal mit Excel ausgefüllt. Oft quick & dirty, manchmal aber auch extrem aufwändig und kompliziert. Fast macht es den Eindruck als sei Projektmanagement ohne Excel möglich, aber sinnlos. Einer der Gründe für den flächendeckenden Einsatz von Excel ist aber die falsche Vorgehensweise vieler Unternehmen indem sie überstürzt Projektmanagement-Werkzeuge einführen ohne zuerst die dahinter stehende Methodik verinnerlicht zu haben.
pro•ject man•ag•er [ˈprɒʤekt ‚mænɪʤəʳ] (n): A sophisticated device for turning coffee into spreadsheets.
— Marcus Raitner (@marcusraitner) August 19, 2013
Natürlich wüssten wir es besser. Die Vielzahl an teilweise hochintegrierter Projektmanagement-Software (siehe Liste auf openPM) spricht Bände. Dennoch kommt in der Praxis, jedenfalls in meiner Praxis, doch immer wieder und fast ausschließlich Excel zum Einsatz. Einzige Ausnahme ist oft nur der Projektplan in MS Project, Merlin (Affiliate-Link) & Co. – allerdings meist nur als Fassade, um sich den Anstrich der Professionalität zu geben. Ein methodisch sauberer und sinnvoller Einsatz (wie in der Serie Projektplanung 101 ausführlich beschrieben) ist eher selten anzutreffen, in den allermeisten Fällen werden MS Project, Merlin & Co. genutzt wie Excel: Keine Verknüpfungen, dafür feste Anfangs- und Endzeiten und die Balken einfach an die gewünschte Position schieben. So muss Technik!
A fool with a tool is still a fool.
Amerikanisches Sprichwort
Es gibt Ausnahmen. Ich kenne eine Reihe hochprofessioneller Projektmanager, die MS Project, Merlin & Co. sinnvoll und richtig einsetzen und in der Lage sind die richtigen Werkzeuge für das jeweilige Projekt richtig anzuwenden. Inklusive Excel. Der Unterschied liegt nämlich nicht im Werkzeug, sondern in der Herangehensweise. Das Werkzeug steht ganz am Ende. Am Anfang steht die Frage nach der Strategie und der Methodik: Wo stehen wir? Wo wollen wir hin? Wie gehen wir vor? Und was brauchen wir dafür im Projekt? Nehmen wir an, ein Softwareprojekt umfasst eine größere Menge von relativ kleinen und im Wesentlichen unabhängigen Anforderungen, die irgendwann aufkommen, bewertet und diskutiert, umgesetzt, getestet und ausgeliefert werden müssen. Hierfür einen Ablaufplan zu verwalten wäre offensichtlich ohne jeden Mehrwert, würde aber erheblichen Aufwand generieren, eine Liste der Anforderungen reicht völlig. Bei genauerer Betrachtung würde sich sogar ein webbasiertes Werkzeug zur Verwaltung von Anforderungen (oder ein Bugtracking-Tool) anbieten, weil dort die Diskussion in Form von Kommentaren mit dem jeweiligen Eintrag verbunden ist. Verwaltet man die Liste in Excel findet die Diskussion an anderer Stelle statt, beispielsweise in E‑Mails, und lässt sich bei Bedarf nicht mehr oder nicht effizient auffinden.
Was für die Auswahl der Werkzeuge im Projekt im Kleinen gilt, nämlich zuerst Strategie, dann die passende Methode, dann das konkrete Werkzeug dazu, gilt auch für die Unternehmen im Großen und insbesondere für die Ausbildung der Mitarbeiter. Viele Unternehmen machen es aber genau anders herum: Aus Gründen der Standardisierung (und weil die falschen Menschen miteinander Golf spielen) wird ein Werkzeug für alle verpflichtend eingeführt und geschult. Dass wir in der Praxis so viel Excel sehen und MS Project, Merlin & Co wie Excel verwendet werden, zeigt deutlich, dass das Werkzeug ohne Methodik nichts bewirkt und höchstens Frust und Aufwand erzeugt. Es bleibt dann alles beim Alten: intern wird wie eh und je mit Excel gearbeitet und dann um der Form Genüge zu tun mehr oder weniger fleißig in das neue Standardwerkzeug übertragen.
proj•ect man•age•ment of•fice |ˈpräjˌekt manijmənt ˈôfis| (n): Men who stare at spreadsheets. #chiefexcelofficer
— Marcus Raitner (@marcusraitner) August 22, 2013
Projektmanagement ist nie eine Frage des Werkzeugs. Ein erfahrener Projektmanager kommt auch mit Excel zurecht und einem unerfahrenen helfen auch die besten Werkzeuge nicht. Werkzeuge bringen nur dann einen Nutzen, wenn sie zur Strategie und Methodik passen.
Foto: Das Artikelbild wurde von zzpza unter dem Titel „Tools“ auf Flickr unter einer Creative Commons CC BY 2.0 Lizenz veröffentlicht.
4 Kommentare
Hallo Herr Raitner,
guter Artikel. Vielen Dank für den Impuls. Er bestätigt mich in meiner Meinung. Das PM-Tool muss so konzipiert sein, dass es allen Mitarbeiter/-innen im Projekt einen Mehrwert bringt. Das bedeutet, zunächst steht das PM Vorgehen (Projektphasen, Projektauftrag usw.). Das muss ich können. Und dann erst stellt sich die Frage nach dem Tool.
Alle „fertigen“ Tools bieten ein PM Vorgehen „out of the box“ an. Bei einem falschem (?) Ansatz besteht das Risiko, dass der fachliche Prozess (PM Vorgehen) an das Tool angepasst wird. Und spätestens da sind wir wieder bei Excel. Die Mitarbeiter/-innen merken das schnell. Der fachlich notwendige Prozess (die Realität) wird dann via Excel abgebildet und das Tool (wie die Golfpieler es so wollen :-) halt dann auch gepflegt und als Overhead wahrgenommen. Gut das es ein Projekt Office gibt :-).
Schönen Feiertag wünscht
Erwin Zauner
Vielen Dank Herr Zauner für Ihre Zustimmung und Ergänzungen. Es zeigt mir, dass nicht nur ich diese Missstände wahrnehme.
Wir haben bei Optimal Systems inzwischen ganz gute Ergebnisse mit Smartsheet erzielt. Quasi ein Excel in der Cloud, wo auch die Möglichkeit der Gant-Darstellung gegeben ist. Wichtigster Punkt ist allerdings die gemeinsame Nutzung mit Kunden, um genau die Diskussionen dort zu führen, wo ich dran arbeite, eben nicht via E‑Mail.
VG Martin Bartonitz
Ja, so gemeinsam an einem Sheet zu arbeiten, bringt schon Mal richtig viel. GoogleDocs kann das ja auch. Nehmen wir viel für openPM und PM Camp her.