Die Excel-Falle: Tools sind nicht alles, aber ohne sie ist alles nichts

„Wenn ein Hammer das einzige Werkzeug ist, hält man jedes Problem für einen Nagel.“ – Abraham Maslow

Jeden Tag wächst der Druck auf das Team: Die Etablierung des Prozessbereichs „Requirements Management“ ist eine der Maßnahmen, die im Rahmen der Prozessoptimierung durchgeführt werden soll. Das gesamte CMMI-Projekt ist straff geplant und muss bis Ende des Quartals abgeschlossen werden. Zuvor wurde das Unternehmen systematisch durchleuchtet, es wurden Effizienzlücken gefunden und analysiert. Die daraus resultierenden Arbeitspakete wurden definiert und geplant. Sämtliche Aufgaben sind sauber budgetiert worden: die CMMI-Berater, die zusätzlichen Aufwände der Projektmitarbeiter, die Zusammensetzung und Auslastung der Spezialisten-Arbeitsgruppen für jeden Prozessbereich.

Die endgültige Version der Prozessbeschreibung ist nun fertig. Sie wurde gereviewt und freigegeben. Alle Anforderungen von CMMI Maturity Level 2 wurden sauber beschrieben, vor allem die Traceability. Das CMMI-konforme Anforderungsmanagement setzt diese eindeutige Nachvollziehbarkeit zwischen verschiedenen Arbeitsergebnissen voraus. Das Verfahren wurde denkbar einfach gestaltet: Wenn ein Anforderungsmanager ein neues Feature erhält, trägt er dies in ein speziell vorbereitetes Excel-Sheet ein und gibt die Anforderungen an Projektplaner, Systemanalysten und Architekten weiter. Diese melden aktualisierte Plandaten und betroffene Komponentenkennungen dem Anforderungsmanager zurück, der sie in die passenden Spalten des Excel-Sheets einträgt und den Status der betroffenen Anforderungen anpasst. Das Excel-Sheet liegt auf einem gemeinsamen Laufwerk, jeder kann den aktuellen Status sehen. Den Schreibzugriff hat nur ein kleiner Benutzerkreis, unter anderem natürlich der Anforderungsmanager.

„Tools sind egal, nur der Prozess zählt“

lautet das vermeintliche Motto und die spontane Lösung scheint einfach und günstig: Der Entwurf eines simplen Excel-Sheets. Teure Tools und der Aufwand für ihre Einführung wurden eingespart. „Es ist völlig egal, mit welchem Tool wir arbeiten, der Prozess ist wichtig, nicht das Tool“ sagte der Chefberater. Und der muss es ja wissen.

Im Rahmen eines Pilotprojekts soll geprüft werden, wie sich dieses Konzept in der Praxis bewährt. Das pilotierende Teilprojekt steht – wie alle anderen – unter Volldampf. Gerade läuft die erste Phase der Anforderungsanalyse los. 230 neue Anforderungen fließen in das Excel-Sheet. Sie werden systematisch analysiert, geschätzt und geplant. Der Anforderungsmanager hat alle Hände voll zu tun: Tag ein Tag aus trägt er die per E-Mail einströmenden Angaben seiner „Kunden“ ein: Kommentare zu den Anforderungen, Statusänderungen, Plandaten, Bezeichnungen der betroffenen Systemkomponenten aus der Impact-Analyse.  Die ausgeklügelten Balken- und Tortendiagramme und Soll-Ist-Vergleiche sehen prächtig aus. Alles macht einen korrekten und professionellen Eindruck.

Der Pilot – das Teilprojekt, das den Prozessbereich „Anforderungsmanagement“ auf seine Praxistauglichkeit hin testen soll – nimmt an Fahrt auf, die Arbeitsbelastung erreicht die üblichen Grenzwerte. In der Hektik des Alltags wurden einige Anforderungen vergessen. Diese müssen schnell nachgezogen werden. Außerdem wurden einige Anforderungen als Dubletten erkannt und müssen nun zusammengelegt werden. Dabei stellt sich immer wieder heraus, dass die vermeintlichen Dubletten nun doch von verschiedenen Arbeitsannahmen ausgingen und in der Impact-Analyse nicht die gleichen Ergebnisse lieferten. Diese Anforderungen müssen aufgeteilt und zugleich miteinander verbunden werden. Das wird nun schnell über Nummernkreise und sprechende IDs realisiert.

„Warum lässt man uns nicht einfach arbeiten? Früher war alles einfacher…“

Bald wird klar, dass das Excel-Sheet nicht fehlerfrei ist. Der Anforderungsmanager hat nun 350 Einträge mit jeweils 35 Spalten, also insgesamt 12250 Einzeleinträge zu verwalten. Irren ist menschlich, der Prozess sieht dies aber nicht vor. Die eigene Sichtprüfung genügt bei der steigenden Datenmenge nicht mehr. Es wird mehr in die Qualitätssicherung des Excel-Sheets investiert. Wöchentliche Reviews, aufwendige Prüfskripte, ausgeklügelte Makros und Formeln sollen das Konzept stabilisieren. Dies gelingt nicht – der Anforderungsmanager, der nun gleichzeitig QS-Verantwortlicher, Scriptentwickler und Excel-Experte sein muss, macht immer mehr Überstunden. Stimmen werden laut, dass er seiner Aufgabe nicht gewachsen sei, dass die Ressourcenplanung fehlerhaft war. Man bräuchte offensichtlich mindestens zwei Anforderungsmanager, damit das Arbeitsaufkommen erledigt werden kann.

Das Management steht jetzt unter Erfolgsdruck. An einer Ressource soll es nicht scheitern. Es wird also ein weiterer Anforderungsmanager angeheuert. Mittlerweile arbeiten zwei Personen an einem Excel-Sheet. Was nun kommt, war zu erwarten: Unstimmigkeiten, Parallelaktivitäten, sich gegenseitig überschreibende Änderungen häufen sich. Excel-Sheets sind nun mal keine echten Mehrbenutzerwerkzeuge. Die Fehler werden durch weitere Reviews und Expertenbefragungen korrigiert. Die Projektmitarbeiter fangen an zu meutern. „Warum lässt man uns nicht einfach arbeiten, wir verwalten uns doch zu Tode. Früher war alles einfacher…“

Die ganze aus dem wahren Leben stammende Geschichte nimmt ihren vorbestimmten Lauf. Die Projektplaner, Architekten, Analytiker, Tester, Kunden – sie alle geraten in den Sog des Stresses. Die Frustration und das Chaos im Anforderungsmanagement erreichen gefährliche Ausmaße. Das CMMI-Projekt wird schließlich auf Eis gelegt, die Berater nach Hause geschickt. Ohne ein funktionierendes Anforderungsmanagement bleibt die angestrebte CMMI-Reifestufe unerreichbar. Das Optimierungsprojekt ist endgültig gescheitert.

Tools kosten Geld. Fehlende Tools kosten ein Vermögen.

Excel-Sheets sind für provisorische Lösungen oder einmalige Aktionen ausreichend. Für ein systematisches, professionelles Anforderungsmanagement in größeren Projekten ist das in der Regel kein guter Ansatz. Der anhaltende Spardruck und die weitverbreitete Excel-Gläubigkeit sind die eigentlichen Grundübel und eine häufige Ursache für das Scheitern vieler Prozessverbesserungsprojekte. Im Anforderungsmanagement benötigt man mehr als eine simple Tabellenkalkulation: ein Zustandsmodell, Zugriffsberechtigungskonzept, echte Multibenutzerfähigkeit, Baselining, ein Minimum an Ergonomie, integrierte Konsistenzprüfung u. v. m. Interessanterweise würde niemand auf die Idee kommen, ein CASE-Tool im Software-Design durch ein einfaches Malwerkzeug zu ersetzen, auch wenn sich damit vielleicht sogar schönere Bilder herstellen ließen. In anderen Prozessbereichen passiert dies dagegen häufiger: Mit Tabellenkalkulationen werden Projekte geplant, Risikoanalysen gemanagt, Fehler verwaltet, Testfälle geschrieben usw. Immer wieder scheint die Lösung im Ansatz trivial und endet trotzdem schließlich im Chaos.

Besonders schlimm ergeht es den Organisationen, die ihre gesamten Prozessmodelle mit Textbearbeitung und Tabellenkalkulation verwalten. „Write-Only“ nennt man häufig diese Dokumente. Ein „Write-Only“-Prozessmodell ist aber sinnlos und sogar gefährlich, da es den trügerischen Eindruck vermittelt, dass die Organisation reif und stabil sei. Das Geld, das am Tool gespart wurde, wird dann nicht selten für umfangreiche, manuelle Datenpflege und organisatorische Überzeugungsarbeit ausgegeben. IT-gestützte Qualitätssicherung lässt sich nicht durch ausgeklügelte Prozessdefinitionen ersetzen. Prozesse, die in Fehlerfällen Repressionen vorsehen, werden eben kaum Akzeptanz finden.

Tools müssen implementiert und integriert werden

Verschiedene Werkzeuge werden in unterschiedlichen Aufgabenbereichen benötigt: Projektplanung, Anforderungsmanagement, Systemarchitektur und -design, Qualitätssicherung usw. In Großprojekten werden Dutzende Spezialtools verwendet. Damit der Datenaustausch zwischen diesen Tools, z. B. eine konsistente Verbindung zwischen Anforderungen und dem Projektplan, nicht zu einer fehleranfälligen und aufwendigen Tipparbeit wird, müssen die Werkzeuge miteinander integriert werden. Diese Integration ist ein aufwendiges Unterfangen: Theoretisch muss jedes Tool mit allen anderen Tools interagieren, die Systeme haben verschiedene Schnittstellen, Prozesse mit ihren verschiedenen Sonderfällen müssen beachtet werden usw.

Die Erkenntnis, dass ohne eine vernünftig funktionierende, integrierte Tooling-Landschaft keine Organisation wirklich effektiv und effizient funktionieren kann, ist schon die „halbe Miete“. Wichtig ist ebenfalls die Einsicht, dass eine Tool-Einführung Geld kostet. Eine Einführung (Implementierung) neuer Tools ist im Kontext des Gesamtunternehmens „Prozessoptimierung“ ein ganz reguläres (Teil-)Projekt. Ressourcen und Zeit müssen bezahlt, organisiert und systematisch geplant werden. ROI-Berechnungen (Return On Investment) sind hier schwierig, doch die Erfahrung zeigt, dass ein Optimierungsprojekt ohne Tools eine wesentlich höhere Wahrscheinlichkeit eines Totalverlustes der dafür getätigten Investition aufweist, wenn die Tooling-Frage ignoriert wird.

Zusammenfassung und Empfehlung

Folgende Erkenntnisse sind richtungsweisend:

  • Ohne passende Werkzeuge ist eine Prozessoptimierung kaum nachhaltig durchführbar.
  • Richtig eingesetzte Werkzeuge steigern die Effizienz und – was vielleicht noch wichtiger ist – die Akzeptanz neuer Prozessabläufe im Betrieb.
  • Werkzeuge funktionieren selten „Out-of-the-Box“. Sie müssen angepasst, gescriptet, und ordentlich aufgesetzt werden.
  • Werkzeuge sind keine einsamen Inseln: Sie müssen integriert werden, damit ein effizienter Datenaustausch möglich ist.
  • Angemessen konfigurierte Werkzeuge sind ein besserer Garant für Prozesskonformität als alle Prozessbeschreibungen, Prozessmodelle und Audits zusammen. Prozesskonformität „durch Strafandrohung“ funktioniert nicht.
  • Eingesetzte Werkzeuge müssen CMMI-Anforderungen erfüllen (insbesondere in Bereichen wie Qualitätssicherung und Konfigurationsmanagement).
  • Excel ist kein Ersatz für spezialisierte Tools.

Bereits die erste Steigerung der Prozessqualität, die 2. CMMI-Reifestufe, setzt ein ordentliches Tooling voraus. Es gibt dazu keine Alternativen. Daher empfehlen wir:

  • Glauben Sie es nicht, wenn man Ihnen vormacht, Tools seien irrelevant, der Prozess allein sei wichtig.
  • Budgetieren Sie das Tooling korrekt. Toolingprojekte sind leider aufwendiger als man es wahrhaben möchte. Wenn Sie kein Geld für das Tooling haben, können Sie sich in der Regel gleich das ganze Prozessoptimierungsprojekt sparen.
  • Beauftragen Sie eine Tooling-Mannschaft, die wirklich Ahnung von CMMI hat, oder zumindest von einem erfahrenen CMMI-Berater geleitet wird.
  • Hinterfragen Sie alle „Excel“-Lösungen.
  • Wählen Sie Tools, die von Ihnen selbst oder vom Lieferanten zu einem fest vereinbarten (Stunden-)Preis den Bedürfnissen Ihrer neuen Prozesse angepasst werden kann.
  • Bei der Prozessdefinition erwarten Sie klare Hinweise, welche Werkzeuge wie und wo eingesetzt werden und wie sie miteinander integriert sind. Dies muss auf einer unteren (detaillierten) Prozessebene klar erkennbar sein.
  • Hören Sie auf Ihre Mitarbeiter. Wenn der neue Prozess „zu kompliziert“ ist, dann ist das wahrscheinlich ein Tooling-Problem.

Natürlich enthält dieser kurze Beitrag nur einen Auszug aus dem Werkzeugkasten eines Prozessberaters. Weitergehende Details würden den Rahmen dieses Kurzbeitrags sprengen. Darüber hinaus müssen Sie die obigen Empfehlungen selbständig angemessen gewichten: Jedes Projekt ist anders und benötigt andere Tools in unterschiedlichem Maße. Sie haben aber den Grundstein für den Erfolg Ihres CMMI-Projektes gelegt, wenn Sie das Thema systematisch zur Sprache bringen und sich nicht auf reine Prozessdefinition verlassen.

Roman Mildner
Über Roman Mildner 79 Artikel
Ich bin zertifizierter Projektmanager (PMP), Managementberater und Buchautor. Seit 1992 bin ich in der IT-Branche und seit 1998 als Managementberater tätig. Zu meinen Arbeitsschwerpunkten gehören Technologiestrategie und Prozessverbesserung, insbesondere im Bereich von Automotive SPICE. Weitere Details finden Sie hier.

2 Kommentare

  1. Danke, danke danke. Ich arbeite gerade u.a. an einer stichhaltigen Gegenargumentation zur These: „Tools sind egal, nur der Prozess zählt“, welche durch meine Führungskräfte vehement vertreten wird. Ich werde großflächig zitieren, allein schon, weil der Prophet im eigenen Lande bekanntermaßen nichts gilt. :o)

    Nochmals vielen, vielen Dank für die präzise und (trotzdem) sehr anschauliche Argumentation!

  2. Ich freue mich, helfen zu können! Ich möchte nur am Rande andeuten, dass ich natürlich ebenso wenig ein Anhänger der Idee bin, Tools seien „alles“. Prozess und Werkzeuge müssen eine Einheit bilden.

    Passende Werkzeuge machen einen guten Prozess überhaupt erst möglich. Man hört häufig, dass die Industrialisierung in der Softwareherstellung längst überfällig sei. Es sei dahingestellt, ob dieser Vergleich wirklich passt. Sollte er jedoch zutreffen, so ist zu bedenken, wie wichtig z.B. die richtigen Werkzeuge im Fahrzeugherstellungsprozess sind – ausgeklügelte Werkzeuge sind für die Ergebnisqualität unabdingbar.

    Es wird gelegentlich gern gewitzelt: „a fool with a tool is still a fool“. Von der manipulativen Natur dieses Sprüchleins abgesehen ist zu bedenken, dass Werkzeuge den Erfolg des Homo Sapiens überhaupt erst ermöglicht haben. Ein Mensch ohne Werkzeug ist bestenfalls ein philosophierender Primat…

Kommentare sind deaktiviert.