Alle kennen es, die meisten wollen es ("eigentlich") - aber in den

Projekten fristet qualifiziertes Anforderungsmanagement häufig ein

Schattendasein.

Laut einer Untersuchung der FHS ST. Gallen von 2008 sind lediglich 25% der befragten Unternehmen mit ihrem Requirements Management zufrieden und das, obwohl IT-Vorhaben oft genug die Wünsche und Anforderungen ihrer Kunden nur teilweise oder nicht erfüllen.

Und als häufigste Ursache wird das unzulängliche Erheben, Dokumentieren, Prüfen und Verwalten von Anforderungen (= Requirements Management) gesehen.

Typische Indikatoren für die Vernachlässigung dieser IT-Strategie sind:

- der geringe eingeplante Aufwand in der Projektplanung

- eine wenig intensive Suche nach den Stakeholdern der Anforderungen

- der geringe Aufwand innerhalb des Projektes für diese Aufgabe

(häufig unter 10 %)

- Einsatz nicht adäquat ausgebildeten Personals für diese Aufgabe (wenn überhaupt)

- Endanwender werden nicht beteiligt.

Vielleicht liegt es an den "weichen" Faktoren, die für eine erfolgreiche Umsetzung des Anforderungsmanagements eminent wichtig sind:

Kommunikationsfähigkeit, soziale Kompetenz, funktionierende

Informationsflüsse und Meinungsaustausch.

Ändert letztlich nichts an der großen Bedeutung, die dem Requirements Management für den Projekterfolg zukommt.

Ein paar Kennzahlen:

83% der Anforderungsänderungen gehen auf sprachliche Unzulänglichkeiten zurück,

77% der Fälle sind bedingt durch Missverständnisse; 

Widersprüche, Redundanzen und inhaltliche Fehler sind da noch nicht drin (s. ebenda)! Das wirkt sich abgesehen von der Kundenzufriedenheit direkt auf die Kosten aus.

Ferner: Anforderungsanalysen auf solider Basis erlauben zuverlässigere Aufwandsschätzungen, erleichtern Investitionsentscheidungen, verbessern die vertragliche Basis von IT-Vorhaben. Dies trifft gerade auf Outsourcing-Projekte und komplexe Stakeholder-Verhältnisse zu.

Also kein Grund, das Requirements Engineering stiefmütterlich zu behandeln. Allerdings scheitert das Requirements Management in den Projekten oft am erheblichen Aufwand und der Komplexität der Tools, die sich auf dem Markt befinden.

Dennoch hilft eine bessere Kommunikation unter den Beteiligten, die erwähnten Missverständnisse und Fehler zu vermeiden und trägt so erheblich zum Projekterfolg bei.

Bei der Toolunterstützung gibt es allerdings noch etwas zu tun...

Herzlichst,

Ihr Dieter Grausdies

Immer mehr Softwareentwicklungsfirmen machen sich agilen Methoden zu Eigen und arbeiten nach dem agilen Manifest:

* Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen.

* Funktionsfähige Produkte haben Vorrang vor ausgedehnter Dokumentation.

* Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen.

* Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung.

Um das agile Manifest sinnvoll einsetzen zu können, sollte man aber auch die Grundgedanken dahinter verstehen, denn leider werden diese 4 Punkte auch gerne als Ausreden für "zu lockeres" Arbeiten missverstanden. So sollten diese Aussagen z.B. nicht als Ausschlusskriterium verstanden werden.

Wenn Menschen in einem Team zusammenarbeiten und interagieren, dann benötigen sie auch klare Basisprozesse, die die Zusammenarbeit regeln. Werkzeuge können hierbei helfen.

Komplett auf Dokumentation zu verzichten, kann man sich aus rechtlicher Sicht kaum leisten, anstatt seitenlanger Wälzer bevorzugt man allerdings das persönliche Gespräch, die daraus resultierenden Notizen können abgelegt werden.

Das offene, klärende Gespräch und der gute Kontakt zum Kunden sind ausdrücklich gewünscht in agilen Projekten, aber die eigene rechtliche wie finanzielle Absicherung darf dadurch nicht vernachlässigt werden.

Zusätzlich darf das Ende eines Projektes nicht aus denn Augen verloren werden vor lauter Änderungen am Produkt.

Wer nie zum Ziel kommt, kann nicht abschließen und auch nichts Neues beginnen.

Herzlichst,

Ihr Robert Bullinger

Solution Architect REST ASSURED! Processes