Inhalt : Anforderungsmanagement

Mir begegnen immer wieder die Fragen:

• "Worin unterscheiden sich Projektmanagement und Anforderungsmanagement?" bzw. 
• "Machen Projektleiter und Business-Analyst nicht das Gleiche?"

Antwort(-versuche) zu Gemeinsamkeiten und Unterschieden von Projektmanagement und Business-Analyse (bzw. Requirements Engineering), zur unterschiedlichen Ausgestaltung der Rollen und deren Zusammenarbeit habe ich unter Projektmanagement vs. Business-Analyse zusammengefasst.

Meine persönliche Meinung ist, dass ein Business-Analyst etwas anderes ist als ein Requirements Engineer oder ein Projektmitarbeiter, der mit Anforderungsmanagement beschäftigt ist. Letzten Endes sind es aber alles nur Stellenbezeichnungen, die sich erst durch die zu verantwortenden Aktivitäten unterscheiden. Gerade im Mittelstand ist es nicht unüblich, dass ein Projektleiter mehrere Rollen einnimmt. Daraus können auch Konflikte resultieren (z.B. ein Projektleiter dessen Hauptziele die Lieferung in Time und in Budget sind, wird in seiner Rolle im Anforderungsmanagement vielleicht wichtige Anforderungen ignorieren, um das Projektziel nicht zu gefährden). 

"Gerade im Mittelstand ist es nicht unüblich, dass ein Projektleiter mehrere Rollen einnimmt."
Ich kenne es auch in größeren Häusern, wenn das Projekt selbst nicht zu groß ist. Im Blogartikel skizziere ich einige Vor- und Nachteile, wenn die Rollen sich in einer Person vereinigen. 

"Meine persönliche Meinung ist, dass ein Business-Analyst etwas anderes ist als ein Requirements Engineer oder ein Projektmitarbeiter, der mit Anforderungsmanagement beschäftigt ist."
Sehe ich auch so  
Es gibt Überschneidungen; aber auch Aufgabenfelder, die Business-Analysten zusätzlich übernehmen. Auch zu den Aufgaben der Business-Analyse gibt es einen Blogartikel.

"... In den meisten Projektmanagement Standards wird das Thema Anforderungsmanagement eher stiefmütterlich behandelt. Es stellt sich die Frage, ob Anforderungsmanagement - oder Requirements Engineering - überhaupt ein Teil vom Projektmanagement oder ob dieses Thema sinnvollerweise und bewusst nicht behandelt wird...."

Dies ist faktisch falsch! In "Kompetenzbasiertes Projektmanagement (PM3), ISBN 978-3-924841-40-9", das die Basis für die Zertifizierung der IPMA darstellt, sind 2 vollständige Kapitel im 1. Band dem Thema Projektanforderungen und Projektziele gewidmet. 

Dabei enthalten sind herangezogene und weiterführende Literatur und vor allem sämtliche Werke, die Du oben zitierst, aber auch noch weitere.

Auch das Thema Traceability von Anforderungen wird behandelt.

Es sind auch Referenzen auf den PMBook Guide und das V-Modell Anlage 1 enthalten, woraus ersichtlich wird, das auch die anderen Standards sich dem Thema widmen.

Bei der GPM gibt es zusätzlich die losen Blätter zum Projektmanagement mit wichtigen Aufsätzen zum Fach (mittlerweile mehr als 5700 Seiten Material). Auch darin sind Anforderungsmanagement, Änderungsmanagement und Zieldefinition ausgiebig enthalten.

Es wird darin auch auf den IEEE-Standard 830-1998 verwiesen "IEEE Recommended Practice for Software Requirements Practice Specifications" und auf die DIN 69901-5. 

Die Aussage ist so also nicht haltbar. Was sind Lasten- und Pflichtenhefte denn anderes als Anforderungsdokumentation? Da gibt es dann auch noch mal Dokumentation und Schulungen in Tonnen Gewicht.

Ich sage nicht, dass ein kein Material dazu gibt, aber den Verweis auf eine lose Blattsammlung oder einen IEEE Standard halte ich für nicht ausreichend. Als Grundlage meiner Aussagen habe ich die Standards PmBOK, ICB, Prince2 und DIN 69901 herangezogen, allerdings nicht das PM3-Werk. Der Artikel ist bewusst provokant formuliert. Warum? Weil die Reife des Projektmanagements über sog. Maturity Models (Reifegradmodelle) messbar wird, und das Anforderungsmanagement dabei nur minimal in die Berechnung eingeht, während doch dutzende Studien belegen, dass einer der Hauptgründe für das Scheitern von Projekten fehlerhafte, unvollständige oder sich ändernde Anforderungen sind. Vielleicht wird damit mein Beweggrund für den Artikel etwas klarer.

Das ändert aber nichts an den Curricula, die genau darauf in der Projektinitiierung und in der Projektsteuerung abzielen. Das wird thematisiert in Hinblick auf Ziele, Konfig-, Vertrags- und Änderungsmanagement und ist ausgiebig enthalten. 

Das PM3-Werk ist der neue aktuell gültige Standard der ICB3 in Deutschland und die Basis für die Zertifizierung. Sozusagen der Nachfolger für das Buch "ProjektManager". Er unterteilt auch in Basiswissen und vertieftes Wissen. Basiswissen Level d geht nur auf Ziele und Formulierung herunter, vertieftes Wissen Level C und höher geht dann explizit auf Anforderungsmanagement ein.

Die Standardwerke sind aber immer nur Nachschlagewerke und verweisen daher für die Praxis auf die Bücher von Hood, Rupp, Sommerville, und viele weitere ...

Ich habe auf Basis meines Bauprojektes auch das Thema Projektmanagement in Bau von Kundenseite erlebt und die ganzen Vorklärungen mit dem Architekten und den Handwerkern waren nichts anderes als Anforderungsmanagement pur. Darauf basieren dann die Claims bei nachträglichen Sonderwünschen oder die Nachlässe oder Mängelbeseitigungen  bei Fehlern (d.h. Nicht-Umsetzung der erfassten Anforderungen). Insofern ist das ausgiebig und umfassend in allen möglichen Branchen erörtert.

Ich habe mal ein Lastenheft von Airbus für einen Auftragnehmer eines Hochregallagers in Hamburg-Finkenwerder bezüglich IT-Anforderungen durchsehen und prüfen müssen und kann Dir nur sagen, dass eine solche Projektdokumentation wirklich jede Anforderung an den Auftragnehmer haarklein erfasst. Nichtfunktionale und funktionale Anforderungen für sämtliche möglichen Szenarien bezüglich Flugzeugbau und -wartung und zwar für alle Bereiche inklusive IT.

Da gibt es dann auch für jeden Punkt Malus-Regelungen für Nicht-Erfüllung. Dagegen sind IT-Projekte mehr als nur hemdsärmelig.

Natürlich enthalten die Standards auch das Anforderungsmanagement, das Problem sehe ich eher in der Anwendung in der Praxis.

Das Revolutionäre beispielsweise an Scrum ist der Product Owner, der ansprechbar ist und sich kümmert...

Diesen Anforderer wünscht sich jedes Projekt. Das Problem liegt aber darin, dass unabhängig davon wie detailliert die Anforderungen vorliegen, die Komplexität von Projekten uns trotzdem zur Korrektur und Anpassung zwingt. Wir haben i.d.R. nicht die Weitsicht um bereits vor Projektbeginn die Anforderungen vollständig aufstellen zu können.

Es geht nicht ohne Collaboration zwischen Auftraggeber und Kunde. Claimmanagement ist der gegenteilige Ansatz, statt auf vertrauensvolles Miteinander setzt man auf das Abstecken von Forderungen und Gegenforderungen. Eigentlich ziemlich perfide, aber manchmal unausweichbar.

In diesem Sinne ist das Anforderungsmanagement häufig tatsächlich stiefmütterlich aufgesetzt und behandelt.

Knapp zwei Jahre ist die letzte Diskussion her. In dieser Zeit hat sich meine persönliche Meinung noch verfestigt, dass Anforderungsmanagement einen höheren Stellenwert in Projektmanagement Standards verdient hätte. Mag man von der "Geld-Druckmaschine" PMI halten was man will, der Verband mit Sitz in den USA hat sich dem Thema nun mit einem eigenen Standard (Requirements Management Practice Standard) gewidmet. 

Weitere Infos:

Ich halte nichts davon, wenn Verbände, denen die Themen auf ihrem eigentlichen Fachgebiet ausgehen dann anfangen ihre Themen zu erweitern und sich anzumaßen auf den Gebieten anderer Handwerkszweige besserwisserisch Standards setzen zu müssen.

Wie kann man einen Practice Standard als Projektmanagementverband entwerfen, wenn es für das Gebiet schon sehr gute Standards gibt? Schuster bleib bei Deinen Leisten. Ich sehe darin Anmaßung. Was will denn das PMI eigenes entdeckt haben, das in den Tonnen Literatur zum Thema und in den Standards CMMI, SPICE (ISO 15504) und ISO 12207 nicht schon aufgeworfen wurde?

Genauso wenig, wie ich es begrüße, wenn die iSQI meint ein Projektmanagement Zertifikat vergeben zu müssen halte ich davon, wenn das PMI meint ein RE-Zertifikat zu vergeben und eigene Standards zu machen.

Was ist mit gesunden Menschenverstand? Muss ein Verband wirklich alles selbst breittreten oder reicht nicht die Referenz auf Querausbildungszweige und der Hinweis, dass man mit dem PM-Standard noch nicht alles durchdrungen hat.

Jeder PL macht bei uns zumindest eine Basis-Ausbildung in Requirements Engineering, aber natürlich auch auf anderen Gebieten.

Es ist doch Blödsinn in einem einzigen Standard die ganze Welt beschreiben zu wollen. Der eierlegende Wollmilchsau Best Practice Prozess, der von jedem Mitarbeiter im Unternehmen erst mal 20 Jahre studiert werden muss, damit er auch weiß, was er wann, wie hätte machen sollen ...

Manchmal lohnt auch ein Besuch auf Konferenzen! Gerade dieses Thema war auf dem letzten PM-Forum breit vertreten. Dabei war auch eine Vorstellung wie man mit Hilfe von Doors und Automatisierung Ausschreibungen und eigene Angebote systematisch scannt, um Erfahrungswerte und vorhandenes Wissen auf dem Gebiet internationaler Großausschreibungen wiederholbar nutzen zu können.

Es gibt übrigens in der GPM eine eigene Fachgruppe zum Thema Requirements Management, die auch ein Buch dazu verfasst hat: http://www.gpm-ipma.de/know_how/fach_und_projektgruppen/requirementsmanagement.html und deren Sprecherin interessante Vorträge dazu auf dem PM-Forum gehalten hat. Ich hatte einen hervorragenden Austausch mit ihr in der Pause über unsere Erfahrung mit der Verwendung von Rollenspielen und Impro-Theater in unserem Berufsumfeld. Nichts desto trotz braucht es m.E. das Buch eigentlich nicht, dahinter stecken immer nur Geschäftsmodelle des jeweiligen Verbandes.

Interessant kann es auch sein mal auf Konferenzen wie Sophist Days oder MID Insight zu gehen, um sich Anregungen zu holen. 

Schon im V-Modell 97 waren in den Modulen QS und KM dazu Regelungen und im neuen V-Modell XT sowieso. Ich nehme kein Fehlen in den vorhandenen Standards wahr. 

Die eigentliche Frage muss doch folgende sein:

Warum meinen alle Projektleiter oder Firmen, wenn sie ein Kurzkapitel über Requirements Management gelesen haben, das Gebiet selbst perfekt zu beherrschen und keine Spezialisten zu brauchen? Nach dem Lesen des Kapitels Vertragsmanagement verzichtet der PL doch auch nicht auf seine Hausjuristen, um die Verträge auszuarbeiten oder zu prüfen, bzw. der kleine Mittelständler zieht dazu seinen Anwalt zu rate.

Interessant wie viele Emotionen dieses Thema auslösen kann!

Für mich macht es durchaus Sinn, dass ein PM-Verband (egal welcher) sich mit den größten Faktoren für Projekt-Scheitern beschäftigt und ggf. eigene Best Practice Standards als Ergänzungsliteratur zu ausgewählten Themen anbietet - quasi aus den Tonnen Literatur das wichtigste extrahieren - so wie im Buch von Sommerville und Sawyer (1997) - "Requirements engineering. A good practice guide". Wenn dann noch auf die Schnittstellen zum etablierten PM Prozess eingegangen und ein möglichst konsistentes Vokabular verwendet, dann wäre das Ergebnis schon eine Bereicherung.

Am Schluss ist es doch nur noch ein zusätzliches Buch in dem See der Fachliteratur. Deswegen wird dann eine Organisation die das Thema geflissentlich bisher ignoriert hat, es trotzdem weiter tun. Die ganzen Analysen zum Scheitern von Projekten wegen Fehlern bei den Anforderungen sind doch schon alt und grau und es hat sich durch alle Literatur, Kurse und Organisationen nicht viel daran geändert.

Ein PL, den es interessiert denkt heute schon daran und ein PL den es nicht interessiert ignoriert auch heute schon alle Best Practices, die es schon gibt, da hilft ein weiterer auch nicht.