Der Anforderungsingenieur im Kontext des Projektmanagements!
Für den Anforderungsingenieur existieren mehrere Namen.
Der PmBok Guide 6th führt explizit auf S. 132 eine neue Rolle ein, den Geschäftsanalysten (GA). Synonym können aber auch die folgenden Bezeichnungen verwendet werden:
- Business Analyst (BA)
- Anforderungsingenieur
- Systemanalytiker
- Requirements Engineer
- Berater
Folgende Akronyme oder Bezeichnungen werden in diesem Podcast benutzt:
PMI = Project Management Institute aus den USA
PMP = Project Management Professional Zertifizierung
PmBok Guide = 600 Seiten Unterlage für die PMP Zertifizierung, enthält 13 Wissensgebiete die sich über 5 Prozessgruppen und 49 Prozesse verteilen.
Agile Alliance = Die Agile Alliance ist eine gemeinnützige Gesellschaft, die die Konzepte der Agile-Softwareentwicklung fördern will.
PMI sieht den Fokus des Geschäftsanalysten oder Anforderungsingenieurs auf dem Anforderungsmanagement (AM). Anforderungsmanagement gab es natürlich immer schon …und auch im PmBok Guide gab es das immer schon…zumindest kenne ich den PmBok Guide seit der Version 3th und bis heute findet man das Anforderungsmanagement im Kapitel Inhalts- und Umfangsmanagement, im englischen auch als Scope Management bezeichnet. Für das Anforderungsmanagement existierte auch schon von je her ein Anforderungsmanagementplan, also ein „Plan the Plan“ Plan, der auf der Metaebene beschreibt, wie das Scope Management im Projekt durchgeführt wird. Nach PMI lag die Verantwortung des Anforderungsmanagements bisher immer beim Projektmanager. Da wird sich auch nichts dran ändern, nur das jetzt die Rolle des Anforderungsingenieurs dem Projektleiter kooperativ zuarbeitet.
Die Notwendigkeit dieser Rolle dürfte klar sei: Aufgrund der zunehmenden Komplexität in Projekten, zeichnet sich ab, dass die Projektmanager das Anforderungsmanagement nicht mehr in dem Ausmaß supporten können, wie es ein robustes Anforderungsmanagement erfordert.
Warum überhaupt Anforderungsmanagement?
Als erfahrener PM werden Sie sich diese Frage selbst beantworten können. Aber ich möchte in diesem Kontext auf die EN ISO 9000:2000 verweisen. Zitat:
„Qualität ist der Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt.“
Also „Inhärent“ bedeutet so viel wie „innewohnend“. Wenn Sie einen Mercedes besitzen oder auch nicht, aber sie durften bspw. mal die Tür eines Mercedes zufallen lassen – is ja auch schon was -, werden Sie eine innewohnende Qualität wahrnehmen. Das Geräusch, die Leichtigkeit des Zufallens und das Schließen des Schlossmechanismus, ergeben in Summe diese Inhärenz, diese Wahrnehmung inhärenter Merkmale.
Übrigens …by the way…Qualität wird in Abhängigkeit des kulturellen Hintergrunds sehr unterschiedlich wahrgenommen:
Der Deutsche fragt: Ist das Auto ausgereift?
Der Italiener fragt: Ist das Auto schön?
Der Japaner fragt: Hat das Auto viele Funktionen?
Der Türke fragt: Ist das Auto kollisons-erprobt?
Wenn Sie mal durch Istanbul gefahren sind, wissen Sie was ich meine. Im Vergleich zu Istanbul, ist der Verkehr in Rom und Barcelona als kinderfreundlich einzustufen.
Kommen wir zurück zu den Anforderungen. Ich denke wir gehen konform mit der Aussage, dass das Erfüllen von funktionalen und nicht funktionalen Anforderungen als wichtigstes Kriterium für den Erfolg eines Projekts zu identifizieren ist – das wissen heute schon kleine Jungs auf der Straße oder besser, bei der Arbeit mit dem eigenen Laptop .
Anforderungen an das Projektmanagement, bspw. Zeit- und Kostenziele, stellen auch sehr wichtige Anforderungen dar, lassen sich aber i.d.R. immer noch durch eine gute Kommunikation mit dem Kunden anpassen, wobei fehlende oder abweichende Ergebnisse bezogen auf die funktionalen oder auch nicht funktionale Anforderungen, mit ziemlicher Sicherheit zur Unzufriedenheit des Kunden führen und häufig dann sogar zu justiziablen Ereignissen, die meistens auch die Kundenbindung auflösen.
Falls Sie die PMP Prüfung machen wollen, sollten Sie sich vor diesem Hintergrund – also der Kundenbindung – mit den unterschiedlichen Rechtssystemen der USA und Europas auseinandersetzen. Wenn wir hier über ein Paragraphenrecht, dem Civil Law verfügen, muss man in den USA mit dem Common Law rechnen, einem Fallrecht. Bezogen auf die Kundenbindung, kommt es da bei justiziablen Ereignissen zu anderen Ergebnissen als in Deutschland oder Österreich.
An dieser Stelle könne wir erstmal konstatieren: Um die Stimme des Kunden – also die Voice of Customer – in immer komplexeren Projekten stärker in den Fokus zu rücken, wird die Rolle eines Anforderungsingenieurs immer wichtiger.
Welchen Aufgabenbereich deckt ein Anforderungsingenieur ab?
Wenn man diese Frage beantworten will, muss man dies über die gesamte Zeitachse eines Projekts hinweg beantworten, angefangen beim Vertrieb. Einerseits gilt es proaktiv Projekte zu akquirieren, meistens geht es auch darum Ausschreibungen zu gewinnen. Vertriebsmitarbeiter sind nur halbwegs adäquate Ansprechpartner, wenn es darum geht, auch inhaltlich zum Thema „funktionale Produktanforderungen“ argumentativ tätig zu werden, und sind meistens vollkommen semiprofessionell unterwegs. Von daher kommt es auch oft zu Konflikten zwischen Vertrieb und Projektmanager, da der Vertrieb zu blauäugig die einen oder anderen Anforderungen akzeptiert, bspw. Termine setzt, die dann das eigentliche Projektteam stark unter Druck setzen.
Während der Vertrieb mit dem Auftrag in der Tasche an den Projektleiter das Projekt übergibt, fängt dagegen die Arbeit eines Anforderungsingenieurs erst richtig an. Er ist während des gesamten Projektlebenszyklus Kooperationspartner des Projektmanagers. In der Regel wird der Anforderungsingenieur auch nicht nur für ein Projekt zuständig sein. Er wird auf der Portfolio Ebene mehrere Projektleiter bedienen.
Während des Projektlebenszyklus ist er für das Konfigurationsmanagement zuständig, dass sich in die drei Bereiche gliedert: K-Identifizierung, K-Buchführung und K- Auditierung, um zu prüfen, ob die K-Buchführung on Track ist. Wer PRINCE2 zertifiziert ist, kennt eventuell die Rolle des Konfigurations-Buchhalters.
Anhängig am KM ist die Tracebility, also die Rückverfolgbarkeit von CRs über Anforderungen, Verantwortliche und Ausführende sowie Auswirkungen auf andere Elemente des Gesamtsystems.
Falls Sie Aktien in der Fleischbranche haben, sollte der Begriff Rückverfolgbarkeit für Sie nicht neu sein.
Darüber hinaus gilt für den AI das Kommunizieren und Verhandeln der CRs gegenüber dem Kunden. Erfahren PM wissen, dass der Kunde nicht selten dazu neigt ein fällige CR als Spezifikationsverfeinerung zu interpretieren, die nichts kostet.
Ein ganz anderer Bereich ist das Projektcontrolling. Als untergeordneter Bereich des Earned Value Managements kann der AI wertvolle Daten im Rahmen des Technical Performance Management liefern. Der Fertigstellungsgrad, der den Earned Value bestimmt, kann über das Tracking der Anforderungen über Key Performance Parameters (KPP) robuster bestimmt werden und damit auch signifikantere Prognosen für den weiteren Verlauf eines Projekts ermöglichen. Die KPPs werden vom AI in Zusammenarbeit mit dem Projektmanager geplant und im Verlauf des Projekts reported, um den Fertigstellungsgrad Aussage freudiger zu bestimmen.
Obwohl bis hierher nicht alle Aufgaben eines AIs genannt worden sind, dürfte schon deutlich werden, dass die Rolle eines AIs im Projekt sehr viel Sinn machen kann.
Welche Fähigkeiten und Fertigkeiten sollte ein Anforderungsingenieur mitbringen?
Da es primär um die Anforderungen an das Produkt geht, benötigt er natürlich ein erhebliches Fachwissen aus der jeweiligen Domäne. Gleichwertig daneben stehen Kompetenzen auf dem kommunikativen Sektor. Er muss in der Lage sein, mit der Kundenseite eine konstruktive Verhandlungsplattform zu betreiben. Dabei sollte er fähig sein, seine Verhandlungen eher altruistisch als persuasiv zu führen. Altruistische Kommunikation wird durch einen familiären und euphonischen Duktus gekennzeichnet und nicht durch eine dominante überzeugende Diktion. Schließlich zielt so ziemlich jedes Projekt auf eine strategische Kundenbindung ab. Auch gilt es im Kontext von aufkommenden CRs, eine gedeihliche Atmosphäre zu erhalten, die ein gemeinsames committen angehender CRs für beide Seiten erträglich halten.
Ein Anforderungsingenieur wird auch mit dem Phänomen der „Emergenz“ Erfahrungen gesammelt haben. Salopp übersetzt bedeutet Emergenz, mehr als die Summe des Ganzen. Gerade in der Softwareentwicklung kommt es häufig im Zusammenspiel diverser Funktionalitäten zu Ergebnissen, die so nicht vorhersehbar waren. Auch der Wissenszugewinn oder gemäß PmBok Guide der Scope Creep, also schleichende Scope Zuwächse, werden im Erfahrungsschatz des Anforderungsingenieurs hilfreich sein, dem Kunden antizipierend Vorschläge zu unterbreiten, wie zu erwartende CRs präventiv zur Zufriedenheit aller finanziert werden können. So kann der Anforderungsingenieur auf Basis ähnlicher Projekte schon eine durchschnittliche Budgetgröße fokussieren, mit der im geplanten Projekt zu rechnen ist. Kommt es nicht dazu, wird sich der Kunde freuen, kommt es dazu, wird ein Commitment einfacher umzusetzen sein.
Da es aber auch Anforderungen an das Projektmanagement gibt, bspw. die Parameter des magischen Dreiecks (PMI = Sechseck), muss der Anforderungsingenieur auch diese Schnittstellen kooperativ mit dem Projektleiter managen können. Anforderungen des Produkts korrelieren natürlich intensiv mit den Anforderungen des Projektmanagements.
Sie können sich sicherlich vorstellen, dass ein Vertriebler ohne diesen Erfahrungsschatz oder auch ein Projektmanager, der nur sehr selten einen Projektvertrag unter Dach und Fach bringt und die funktionalen Anforderungen häufig nicht so stringent auf dem Schirm hat, keinenfalls die Routine und Erfahrung mit einbringen kann, Anforderungen an das Projekt äquivalent zu einem „Anforderungsingenieur im ständigen Einsatz“ zu supporten.
Quintessenz
Gerade in Unternehmen die über Projektportfolios verfügen, wird er Einsatz eines Anforderungsingenieurs zu erheblichen positiven Effekten führen. Nicht zuletzt, weil ein Anforderungsingenieur auch die Lernkurve im Kontext von Anforderungsmanagement optimal supporten kann. Wenn er dann noch in der Lage ist, seinen Erfahrungsschatz in Trainings für Projektmitarbeiter zu transferieren, kann dies einen enormen Leistungsschub bedeuten. Denn, Anforderungsmanagement ist Sache alle Projektbeteiligten!
Die PMP Zertifizierung bietet eine qualifizierte Ausbildung zum professionellen Projektmanager. Jetzt auch mit einer zusätzlichen Zertifizierung als add on im agilen Bereich. PMI und Agile Alliance bieten für diese Zertifizierung den “Praxisleitfaden Agilität”. Im Vergleich zu den üblichen Frameworks im agilen Umfeld, erhalten Sie mit diesen beiden Zertifizierungen ein Fundament über 13 Wissensgebiete und den agilen Kontext dazu.
Unsere nächsten Termine zur PMP Zertifizierungsvorbereitung finden Sie unter dem folgenden Link:
Hören Sie den Podcast finden Sie einen Link zu unseren PMP Seminaren unter dem Register Info.
Renee Ossowski, PMP