Die Quelle ist nicht ganz klar (dazu Wikiquote), aber diese Regel wird oft zitiert und ihre Gültigkeit nie bezweifelt. Auch ich will dem nicht widersprechen, allerdings eine ergänzende Regel aufstellen: Only a fool works without a tool.

Die Frage ist allerdings, welche Tools man wählt und welche Auswirkung die Wahl von Tools auf das Ergebnis haben.

In einem meiner ersten Softwareprojekte hatte der Auftraggeber, ein großes deutsches Versicherungsunternehmen, gerade ein neues Vorgehensmodell für IT-Projekte definiert. Es bestand in einer Abfolge von Formularen, die zu befüllen waren. Rasch stellte sich heraus, dass diese Vorgaben für unser konkretes Projekt nicht zielführend waren. Als wir allerdings vorschlugen, entsprechende Anpassungen vorzunehmen, war der Projektleiter des Kunden strikt dagegen. Wir beantworteten also weiterhin teilweise sinnlose Fragen und ließen wichtige Fragen unbeantwortet. Das Werkzeug, nämlich eine Folge von strukturierten Spezifikationsdokumenten, bestimmte den Inhalt unserer Arbeit. Die eigentliche Aufgabe, nämlich die Vorgaben für ein neues Bestandsführungssystem dieser Versicherung zu erarbeiten, trat immer mehr in den Hintergrund. Das Werkzeug hatte sich verselbständigt. Ich wurde aus dem Projekt bald wegen meiner dauernden Aufmüpfigkeit entfernt und war auch erleichtert. Jahre später hörte ich, dass das Projekt gestoppt und der Projektleiter gekündigt worden waren.

Was habe ich daraus für meine späteren Projekte gelernt?

Keinesfalls, dass die Verwendung von Werkzeugen per se schädlich ist. Allerdings doch ein starkes Misstrauen gegen Vorgehensmodelle und damit verbundene Methoden und Werkzeuge. Man muss immer wieder die Frage stellen, ob diese bei der Arbeit an der eigentlichen Aufgabe unterstützen oder von dieser ablenken.

Nach vielen Jahren Erfahrung kann ich sagen, dass die in der Anforderungsdefinition am häufigsten angewandten Werkzeuge Word, Excel und Powerpoint sind. Wenn es um Projektplanung und Projektcontrolling geht, ist das Excel. Warum? Es sind sehr flexible und leicht zu nutzende Werkzeuge, die man der jeweils gegebenen Aufgabe und Situation anpassen kann. Ihr Nachteil ist, dass man immer wieder auf der grünen Wiese beginnt und jedes Projekt anders vorgehen kann. Daher gibt es auch zahllose Templates mit unterschiedlich hohem Strukturierungs- und Reifegrad, die dann projektspezifisch angepasst werden.

Methoden und Werkzeuge für das Requirements-Engineering gibt es natürlich in großer Zahl, einen guten Überblick findet man hier. Viele leiden allerdings darunter, dass sie für Anwender schwer erlern- und handhabbar sind.

Gute Erfahrungen habe ich in mehreren Projekten mit JIRA gemacht. Die Einrichtung dieses Tools in einer Form, die sich auch für Anwender eignet, lohnt sich allerdings nur in größeren Projekten. Dort ist es aber Pflicht, in so ein Tool zu investieren, weil das Pflegen von Excel-Listen rasch ins Chaos führt.

Entscheidend ist es, den Übergang von Word und Excel zu einem spezifischen Tool nicht zu verpassen. Beginnt man irgendwie und hat man einiges an Inhalt bereits produziert, ist die Umstellung auf ein Werkzeug schwierig; man schleppt erfahrungsgemäß bis zum Abschluss des Projektes Altlasten mit. Daher gleich am Anfang über die Notwendigkeit und Sinnhaftigkeit eines spezifischen Tools nachzudenken und dieses von Anfang an einsetzen. Wenn das verabsäumt wurde, muss man bei einer späteren Umstellung genügend Aufwand dafür einplanen und braucht auch entsprechenden Nachdruck, dass die Umstellung gelingt.