Business Analyse versus Projektmanagement
Kennen Sie auch die derzeitige Diskussion über Business Analyse versus Projektmanagement? In vielen Firmen scheint es Unsicherheiten zu geben, welche Aufgaben ein Business Analyst und welche ein Projektmanager übernimmt. Wer ist wofür verantwortlich? Wo macht eine Trennung zwischen den Rollen und Aufgaben Sinn und wo ist die Zusammenarbeit besonders sinnvoll?
Business Analyse und Projektmanagement – ein Blick in die Vergangenheit
Die Business Analyse und die Rolle des Business Analysten haben sich in den letzten Jahren stark gewandelt. In den neunziger Jahren hatten Business Analysten gerne einen Volkswirtsschaftsabschluss, mindestens aber einen betriebswirtswirtschaftlichen Background und waren häufig in Banken beschäftigt. Ihre Aufgabe bestand darin, zu bestimmen, wann ein Geschäft – sprich ein Business – sinnvoll wäre. Welche Faktoren spielten für den Erfolg eine Rolle, wie war dieser Erfolg sicherzustellen und zu messen? Und heute?
Auch heute muss der Business Analyst eine Art Radar für Geschäfte haben. Er berät die Unternehmensführung, blickt über den Tellerrand der Gegenwart hinaus, entdeckt Märkte und Chancen. Er interagiert aber auch mit Stakeholdern, erörtert Anforderungen und bildet die Schnittstelle zum Kunden. Dabei gibt es vermehrt direkte Überschneidungen mit der Rolle des Projektmanagers (und des Systems Analysten, des Requirements Engineers oder des Anforderungsanalytikers).
Auch der Projektmanager ist maßgeblich für den Erfolg des Unternehmens verantwortlich, zumal sich das Arbeiten in Projekten für sehr viele Unternehmen als die bevorzugte Art der Zusammenarbeit erwiesen hat. Linienorganisationen definieren zwar eine strukturelle Zugehörigkeit, die notwendige interdisziplinäre Zusammenarbeit von Experten aus unterschiedlichsten Bereichen mit verschiedensten Fähigkeiten mündet jedoch regelmäßig in Projekten.
Ein Projektmanager ist somit nicht mehr nur “Herr über seinesgleichen”, sondern Kapitän, Navigator, Motivator und auch “Kommunikator zwischen den Welten”. Und diese Welten existieren nicht nur firmenintern, sondern selbstredend auch extern im Zusammenspiel mit Auftraggebern, Lieferanten und Stakeholdern. Somit sind beide Rollen für den Erfolg des Unternehmens sehr wichtig und die Frage nach den jeweiligen Aufgaben steht im Raum.
Unterschiedliche Aufgaben, oder doch nicht?
Die Aufgaben eines Business Analysten und eines Projektleiters lassen sich nicht eindeutig und allgemein gültig für alle Projekte, Projektarten, Firmen und Branchen definieren. Ein Projektmanager könnte beispielsweise für den Erfolg eines Projekts verantwortlich und der Business Analyst in bestimmten Projektphasen für die Anforderungsanalyse oder die Abstimmung der Anforderungen zuständig sein. Oder aber der Business Analyst definiert die Rahmenbedingungen des Geschäfts und die Umsetzung wird mit einem Projekt unter der Führung des Projektmanagers angestrebt.
Wie könnte also eine sinnvolle Aufgabenteilung aussehen? Der Schlüssel könnte in der Konzentration des Business Analysten auf dem Produkt, auf der Lösung oder kurz dem “Was” liegen, während sich der Projektmanager um den Prozess der Erstellung und somit um das “Wie” kümmert. Das “Was” determiniert dabei das “Wie”, so dass der Business Analyst im Vergleich zum Projektmanager ein etwas weiteres Spektrum abdeckt.
Das ist an sich auch nicht verwunderlich, denn der Projektmanager kann normalerweise erst agieren, wenn es ein Projekt gibt. Der Business Analyst hingegen kann im Rahmen eines Projektes, aber auch außerhalb eines Projekts, aktiv werden. So könnte er strategische Entscheidungen vorbereiten oder treffen, die dann zu neuen Projekten führen. Diese dann unter Berücksichtigung gegebener Randbedingungen wie Zeit, Budget und Ressourcen umzusetzen, läge dann wieder in der Verantwortung des Projektmanagers.
Mit einem solchen Verständnis ergibt sich folgende Aufteilung zwischen Business Analyst und Projektmanager:
Business Analyse und Projektmanagement in der Praxis
Und wie gestaltet sich die Zusammenarbeit in der Praxis? Theoretisch ist die Abgrenzung zwischen Business Analyse und Projektmanagement bis ins kleinste definiert, aber praktisch ist die Handhabung von Unternehmen zu Unternehmen, von Projekt zu Projekt unterschiedlich. Häufig gibt es weder pure Business Analyse oder pures Projektmanagement, sondern eine Art Hybriden aus beiden Teilen. Dieser Hybrid lässt sich als Chance verstehen, wenn die verschiedenen Blickwinkel der Business Analyse und des Projektmanagements kombiniert werden. Oder auch als Risiko, nämlich wenn beide Rollen von einer Person eingenommen und der natürliche Interessenkonflikt zwischen strategischer und operativer Ausrichtung nicht berücksichtigt wird. So lässt sich zwar kurzfristig auch Geld sparen, allerdings steigt im Gegenzug direkt die Aufgaben- und Arbeitslast des konkreten Mitarbeiters.
Darüber hinaus entwickelt sich auch ein Wettbewerb zwischen den Rollen bzw. Vertretern der jeweiligen Richtung. Sätze wie “Ich bin Business Analyst und benötige keinen Projektmanager” oder “Ich bin Projektmanager und brauche keinen Business Analysten, der mir sagt, wie ich arbeiten soll.” sind häufiger zu hören. Auch auf Konferenzen ist deutlich zu sehen, dass sich Business Analysten verstärkt im Requirements Engineering und Testing sehen. Es entsteht leicht der Eindruck, dass die Unternehmenswelt ohne Business Analysten nur schwer bestehen kann.
Bei der strategischen Ausrichtung eines Unternehmens, bei der Beratung der Geschäftsführung, beim Erkennen von Märkten und Chancen ist dies bestimmt auch der Fall. Bei der konkreten Umsetzung in der Projektarbeit, bei der Entwicklung von Produkten oder Software gibt es allerdings auch schon verschiedene Rollen, die sich mit der Anforderungserhebung, -verwaltung und -abstimmung beschäftigen, so dass sich Unternehmen fragen sollten, ob eine Adaption der gelebten Rollen tatsächlich erstrebenswert ist.
Fazit
Es macht durchaus Sinn, sich innerhalb von Organisationen Gedanken um die Verteilung von Aufgaben und Verantwortlichkeiten zu machen. Die Ergebnisse werden dabei je nach Unternehmen unterschiedlich ausfallen. Dies liegt schon alleine an unterschiedlichen Prozessen und vorhandenen Rollen. Eventuell entwickeln Sie Software mit dem V-Modell XT und kennen daher einen Anforderungsanalytiker, dessen Aufgabengebiet sich deutlich mit dem eines Business Analysten überschneiden könnte. Oder Sie nutzen die Projektmanagement-Methodik PRINCE2 – und der Projektmanager ist für die Erstellung des Business Case verantwortlich. Vielleicht haben Sie auch ein Projektantragswesen etabliert und müssen kaufmännische Kennzahlen erbringen, noch bevor das tatsächliche Projekt starten könnte. Die Erstellung eines Business Cases wäre somit keine Aufgabe des Projektleiters; dieser müsste sich “lediglich” um die operative Zielerreichung kümmern.
Ein weiterer Grund ist der Tatsache geschuldet, dass Menschen unterschiedlich sind. Keine zwei Business Analysten und keine zwei Projektmanager sind tatsächlich gleich. Idealerweise besitzen Mitarbeiter auch rollenübergreifend ein gemeinsames Aufgabenverständnis.
Mitarbeiter haben aber auch unterschiedliche Erfahrungen und Fähigkeiten. So können Sie also leicht definieren, dass ein Business Analyst a, b und c und ein Projektmanager d, e und f tut, das hilft aber nur eingeschränkt, wenn beispielsweise der Business Analyst gar nicht in der Lage ist, c zu tun. Eine Definition wäre somit als Ausgangslage zu verstehen, müsste dann aber im Zuge des anstehenden Vorhabens, eines Geschäfts oder eines Projekts im Detail erörtert werden. Dies erzeugt natürlich mehr Aufwand, vermeidet aber auch Missverständnisse, doppelte Arbeiten und fehlende Ergebnisse. So läge der Fokus liegt nicht mehr auf den einzelnen Titeln, sondern im gemeinsamen Miteinander, im Teamwork und im tatsächlichen Ergebnis.
Business Analyse UND Projektmanagement lautet also das Fazit.
Hinweise:
Weitere Ausführungen zum Thema finden Sie unter anderem im PMI “Practitioners Guide for Business Analysis” unter den “Collaboration Points”.
Lesenswert sind darüber hinaus auch folgende Bücher:
Business Analysis und Requirements Engineering, Produkte und Prozesse nachhaltig verbessern, Peter Hruschka, Carl Hanser Verlag München
Business Analyse, einfach und effektiv, Inge Hanschke, Gunnar Giesinger, Daniel Goetze, Carl Hanser Verlag München
Basiswissen Business-Analyse, Probleme lösen, Chancen nutzen, Ingrid Gerstbach, Peter Gerstbach, Redline Verlag
Auf einen Nenner gebracht: Der PL will ein schönes Projekt haben, der BA ein schönes Produkt.
Und was nützt dem Unternehmen mehr?
Sind Terminplan, Lieferobjekte und WBS wichtiger, als Funktionalität, Usability und Prozesse? Oder weshalb steht der PL weiter oben in der Entscheidungskette?
Ein Blick in die Zukunft
Ich teile viele Einschätzungen von Michael Schenkel über die heutigen Schwierigkeiten, die beiden Rollen zu definieren. Für die (ferne) Zukunft sehe ich aber einige deutliche Trends<. (1) Projektleiter sind für den Erfolg von Projekten zuständig, also für die Zielerreichung in Time und in Budget. Unsere Welt wird immer schnelllebiger und Projekte, die früher Jahre dauerten, sollen heute (zumindest nach SCRUM) jeden Monat sinnvolle (potentiell auslieferbare) Produkte erzeugen, die das "Business" unterstützen. In vielen Branchen - auch wenn nicht nach SCRUM gearbeitet wird - müssen Projekte 2 bis 4 bis 6 mal im Jahr etwas sinnvolles liefern. Projektleiter sind daher per se "Kurzfristdenker", denn sie werden nach dem kurzfristigen Projekterfolg beurteilt. (2) Business Analysts sollten Mittel- bis Langfristdenker sein. Sie sollten die heutigen Geschäftsprozesse und -objekte verstehen, sollten Verbesserungspotential aufzeigen und dann dafür sorgen, dass diese Verbesserungspotentiale in gezielten Projekten Schritt für Schritt erreicht werden. Wenn Business Analysts gut sind, dann haben Sie "Ihr Business" im Griff: sie haben Modelle der Geschäftsprozesse, anhand derer Wertschöpfungszahlen in den einzelnen Geschäftsschritten ermittelt werden können und (ehrgeizige) Ziele zur Verbesserung der Wertschöpfung oder zur Erneuerung und zum Ausbau des Geschäfts entdeckt werden. (3) Die "Dritten im Bunde" wurden im Blog nicht erwähnt: nämlich System-/Software-Architekten: Sie sind verantwortlich, dass Business-Ideen dem State-Of-The-Art gemäß und auch gemäß längerfristiger Qualitätsziele des Unternehmens umgesetzt werden. Der (traurige) Zustand in vielen Branchen heute: Projektleiter sind angesehen, übermächtig, und die klaren Autoritäten. Business Analysts, Requirements Engineers, Architekten u.a. sind deren Erfüllungsgehilfen. Dabei schaffen doch sowohl Business Analysts wie auch Architekten langfristige Werte für das Unternehmen (Assets, wiederverwendbare Prozesse und wiederverwendbare Lösungen), wohingegen Projektleiter "nur" für die kurzfristige Erreichung der Projektziele zuständig sind.
Mich erinnert die Aussage: ‘Das “Was” determiniert dabei das “Wie”’ von Herrn Schenkel an die Clausewitz’sche Definitionen von Strategie und Taktik (Carl von Clausewitz: Vom Kriege).
In der Zusammenfassung vertrete ich die Meinung, dass der Business Analyst eine Stabsfunktion auf Vorstand- oder Geschäftsleitungsebene ist und der Projektleiter auf der operativen Leitungsebene angesiedelt ist.
Dazu ein quantitatives Hilfsargument: Es gibt normalerweise mehrere Projektleiter aber nur einen Business Analyst im Unternehmen.
In Antwort auf Hr. Schwarze:
Wir unterscheiden in unserem Buch zwischen der strategischen und der operativen Business Analyse. Die strategische Business Analyse (Definition des Unternehmensbedarf, Finden von Lösungsansätzen, in dem Kontext diesen Artikels ‘bevor’ ein Projekt überhaupt beginnt) ist da definitiv meistens in einer Stabstelle angesiedelt. Die operative Business Analyse passiert aber in den Projekten.
Das bedeutet aber auch: Zumindest genauso viele BAs wie PMs. Und bei größeren Unternehmen reicht auch in der Stabstelle nicht eine Person aus. Das kann und muss dann auch ein ganzes Team sein!
Ein spannender Artikel! Ich finde vor allem den Bezug zur Praxis ganz interessant: In der Praxis ist derzeit nicht immer eine wirklich strenge Unterscheidung der beiden Rollen – BA und PM – gegeben. Oft wird diese hybrid durch eine Person wahrgenommen.
Die Rolle des Projektmanagers hat sich in den letzten 20 Jahren gut in Unternehmen etabliert – mit dem nachteiligen Effekt, dass sich fast jede erfahrene Person, die nicht direkt in der Linie tätig ist, sondern in Projekten, Projektmanager nennt – auch wenn diese Person gar nicht als Hauptaufgabe das Managen von Projekten übernimmt.
Aus dieser Situation sehe ich die folgenden Trends für die nächsten Jahre:
1) Business Analysten werden vermehrt in der strategischen und konzeptionellen Phase eingesetzt werden – noch bevor es überhaupt ein Projekt gibt, das es zu managen gilt. Denn hier sind ganz andere Methoden gefragt, als die klassischen PM-Literatur anbietet. Vielmehr wird es dann darum gehen, den tatsächlichen Unternehmensbedarf zu definieren und passende Lösungsansätze zu finden.
2) In Projekten werden Business Analysten weiterhin die inhaltlichen Anforderungen erheben und kommunizieren, ev. im Zusammenspiel oder auch in Personalunion mit Requirements Engineers, wenn es um technische Systeme geht. Aber weiterhin liegt es in der Verantwortung der Projektmanager, das Team qualifiziert zu formen und zu führen. Business Analysten unterstützen die Kommunikation mit den Stakeholdern auf der inhaltlichen Ebene erheblich und stellen sicher, dass die Unternehmensstrategie und der Unternehmensbedarf im “ganz normalen Projektwahnsinn” nicht vergessen wird.
Damit 1+2 möglich sind, ist im Unternehmen selber, aber auch bei den Projektmanagern ein Umdenken notwendig, so wie es Peter Hruschka auch beschrieben hat: Projektmanager sollten sich auf die Führung im Projekt konzentrieren, die inhaltliche Definition aber den BAs und bei techn. Systemen die Lösungsdefinition den Architekten übergeben, damit diese einen langfristigen Erfolg sicherstellen können.
eine Bitte an alle:
Bitte geben Sie bei Ihren Kommentaren an, welche Projekte Sie meinen die Sie kommentieren :
– Inhouse IT-Projekte
– Externe IT-Projekte
– Sanierungs-, Change Mgmt.- oder Organisationsprojekte
– Anlagenprojekte
Ich habe bei meinem Kommentar ‘klassische’ Anlagenprojekte gemeint.
Guten Tag, unser Arbeitskreis ist bei seinen Diskussionen auch zu ganz ähnlichen Ergebnissen gekommen: Der Requirements Engineer zielt auf möglichst gute Ergebnisse, der Projektleiter auf einen möglichst guten Prozess ab. Daraus entsteht natürlich Konfliktpotenzial, aber es ist sehr wichtig, dass beide Ziele kompetent vertreten werden. Insbesondere müssen die Beteiligten sich bewusst sein, dass es so ist. Dann können Sie mit diesem Unterschied konstruktiv umgehen und auch die jeweiligen Zuständigkeiten entsprechend festlegen. Eine völlig überschneidungsfreie Aufteilung von Aufgaben ist allerdings unmöglich. Beide Rollen werden darum immer viel miteinander kommunizieren müssen und auch mit den anderen Rollen.
Noch mehr Hinweise darüber, wie die beiden Rollen innerhalb eines Projektes zusammenarbeiten könnten und unserer Meinung nach zusammenarbeiten sollten, finden Sie in unserem Buch bei Springer mit dem Titel “Requirements Engineering und Projektmanagement”: http://www.springer.com/gp/book/9783642294310
Viele Grüße,
Andrea Herrmann
Die Aussage auf Google+ spricht mich ja direkt an, weshalb ich mich hier gerne nochmals zu Wort melde :-)
Bei der Frage, ob der Projektleiter tatsächlich in der Entscheidungskette weiter oben steht, erinnerte ich mich spontan an folgenden Spruch, der unter uns RE/BA immer wieder die Runde macht: Kennst du den Unterschied zwischen einem Zitronenfalter und einem Projektleiter? Es gibt keinen, oder hast du schon mal einen Zitronenfalter Zitronen falten gesehen?
Interessanterweise besuche ich gerade eine Scrum-Weiterbildung und wir hatten gerade die Rollen im klassischen Projektmanagement im Vergleich zu Scrum. Und da habe ich mich natürlich gefragt, was passieren würde, wenn man im klassischen PM analoge Scrum-Rollen einführen würde, also jemand der sich vor allem um das Produkt und die Finanzen (Product Owner) und jemand der sich in erster Linie um Termine und die Projekt-Hygiene (BTW: Das ist m.E. ein Faktor der oft/immer stark vernachlässigt wird, aber zu den stärksten Erfolgsfaktoren zählt) kümmert (nennen ihn mal Project Master). Damit wäre der Project Master zwar derjenige, der organisatorisch zwar etwas weiter oben stehen würde. Er würde die Meetings im Steuerungsausschuss leiten, die Kommunikation machen und wäre der Timekeeper. Auf der anderen Seite wäre der Product Owner derjenige, der über Sein oder Nichtsein einer Produkt-Anforderung entscheiden kann, da er der Budgetkeeper ist. Okay, den klassischen Projektleiter gäbe es damit nicht mehr…
Ich habe den Eindruck, dass sich die Business Analyse als solches derzeit erst oder wieder neu definiert. Einerseits finde ich es überraschend, denn das Businesses analysiert werden – idealerweise vor, während und nach den Businesses – müsste an sich Basis jeglichen beruflichen Handelns sein. Andererseits gibt es genügend Überschneidungen mit vorhandenen Rollen in Organisationen (Projektleiter, Requirement Engineers, Systemanalytiker, etc.) und das führt mich zu der Überlegung, wie sich eigentlich die Zukunft des Projektmanagements gestalten wird. Wird der Projektleiter evtl. in 10 Jahren verschwinden? Brauchen wir dann noch ein Projektmanagement oder geht es zumindest in zahlreichen Branchen in der Produktentwicklung auf? Fragen über Fragen …
Sind Projekte nicht zu unterschiedlich (siehe Kommentar von Ulrich Schwarze), als dass wir in streng getrennten „Gewerken“ denken dürfen, wie es am Bau üblich ist? Haben wir es nicht eher mit „Disziplinen“ zu tun, die alle mehrere Aufgabenbereiche umfassen, die sich überschneiden, wobei der Schwerpunkt in jeder Disziplin unterschiedlich gesetzt wird? Projektmanagement und Business Analyse wären dann nicht die einzigen Disziplinen, bei denen es Überschneidungen gibt. Prozessmanagement und Change Management kämen z.B. auch noch dazu.
Michael Schenkel weist darauf hin, dass es immer auf den einzelnen Menschen ankommt. Und ich denke, darum geht es auch. Wir brauchen keine Schubladen, die voneinander abgrenzen. Wenn wir Business Analyse und Projektmanagement als Satz von Fähigkeiten von Menschen sehen, dann sind Überschneidungen kein Problem, sondern erlauben in Projekten die vorhandenen Ressourcen optimal zu nutzen und zu kombinieren.