“Wir haben doch nur ein kleines Budget, da können wir doch nicht noch eine langwierige Analyse und Spezifikation machen!”

Was ist zu tun, wenn der Kunde solche Sätze spricht?

Er hat Recht. Langwierig muss die Analyse der Anforderungen auch nicht sein. Aber folgende Fragen müssen immer beantwortet und dokumentiert werden:

1. Was sind die zentralen Geschäftsziele des Projektes?
2. Welche Kernfunktionalität muss das System haben, damit diese Ziele erreicht werden können?

Oft reicht für die Beantwortung dieser beiden Fragen ein Workhop von wenigen Stunden, das Ergebnis kann auf einer A4-Seite stehen. Aber alle Seiten halten damit ein Dokument in der Hand, an dem der Projekterfolg gemessen werden kann.

IT-Service-Management wird meist in großen Dimensionen gesehen und wird mit mächtigen Tools in Form gebracht. Man kann auch ITSM intern nutzen, da ja auch z.B. der eigene Mailserver ein Service ist, wo dann die anderen Mitarbeiter quasi die Kunden sind. Diese Betrachtungsweise ist auch dann gerade für KMUs interessant.

Es muss ja nicht sein, dass man das ganze Unternehmen in einen ständig gepflegten ITSM-konformen Ablauf presst, aber alleine das man mal hingeht und die diversen Systeme/Tätigkeiten eines Unternehmens als Service umdefiniert und mal aus dieser Sichtweise prüft, ob vorhandene Handlungs-, Kommunikations- und Sicherheitsmassnahmen ausreichend sind oder ob mit einem geringen Mehraufwand Risikosituationen besser, schneller und günstiger zu meistern sind.

Also “ständig gepflegt” eher in dem Sinne, dass man z.B. halb-/vierteljährlich einfach mal den Ist-Zustand betrachtet und daraus mögliche Verbesserungen ableitet.

Wikipedia: http://de.wikipedia.org/wiki/IT-Service-Management

Immer wieder sind Business-Analysten und Software-Architekten unter Druck: Ihre Arbeit verzögert den beginn der Programmierarbeiten und scheint damit auch den Termin der Produktivsetzung einer Software zu gefährden. Der Projektmanager und der Kunde sind oft der Meinung, die Anforderungen seien nun allen genug klar, die optimale Systemarchitektur hinreichend genau entworfen, man solle doch endlich mit der Implementierung beginnen.

Es ist nicht immer falsch, auf einen zügigen Abschluss der Konzeptionsphase eines Projektes zu drängen. Allen beteiligten muss aber klar sein, dass das Risiko für Fehlentwicklungen umso großer ist, desto weniger ausgereift die Analyse- und Designdokumente bei Beginn der Implementierung sind.

Die Frage ist, wieviel Risiko das Projekt verträgt. Das ist von verschiedenen Faktoren abhängig. Manche Projekte, die nicht den Kernbereich der Geschäftsprozesse betreffen, und bei denen eine kurzfristige Verschiebung des Produktivstarts oder eine Kostenüberschreitung nicht für das Kerngeschäft des Unternehmens kritisch ist, vertragen ein höheres Risiko, bei anderen muss das Risiko jeder Planungsabweichung extrem minimiert werden.

Nur die nüchterne Risikoabwägung kann zur Festlegung des richtigen Konzeptionsaufwandes führen.

Gerade hörte ich es wieder in einem Projekt: “Es wäre sicher gut, wenn wir alle Anforderungen so weit spezifizieren würden, dass keine Fragen mehr offen sind. Leider fehlt uns dazu die Zeit.”

Dieser Gedanke führt immer wieder dazu, dass am Schluss Überhaupt keine vernünftige Anforderungsspezifikation entsteht. Aber er ist auch deshalb falsch, weil es nicht darauf ankommt, Anforderungen so weit wie möglich, sondern so weit wie nötig zu beschreiben.

Die Kosteneinsparung für nachträgliche Fehlerbehebung ist dem Aufwand für die Spezifikation umgekehrt proportional, während der Mehraufwand für immer genauere Spezifikationen natürlich linear mit dem Umfang der Spezifikation wächst. Optimal ist, die Summe aus den Kosten für die Spezifikation und denen für die nachträgliche Fehlerbehebung zu minimieren. Dieses Minimum liegt natürlich nicht da, wo der maximale Aufwand für die Anforderungsbeschreibung getrieben wird. Wichtig ist jedoch, dass man sich – abhängig vom Umfang und von der Komplexität der Lösung sowie vom Vorwissen und der Verfügbarkeit aller Beteiligten, mit der Frage beschäftigt, wo das Optimum des Umfangs der Spezifikation liegt. Dann ist für den Projekterfolg schon viel getan.