Ausgewogene Matrix: Whitepaper

Dieses Whitepaper ist Teil unserer Sammlung "Aus der Praxis". Beschrieben werden die Herausforderungen, die sich bei der Implementierung von Enterprise Project Management (EPM) in einer Organisation mit einer Matrix-Projektmanagementumgebung ergeben.

Die Word-Version dieses Whitepapers können Sie unter Ausgewogene Matrix: Whitepaper herunterladen.

Weitere Whitepapers finden Sie unter "Aus der Praxis" – Whitepapers.

Ausgewogene Matrix: Whitepaper

In Projektmanagementkreisen sprechen wir häufig von einer Matrixmanagementumgebung. Matrixmanagement ist nichts Neues. In praktisch allen Hightech-Organisationen ist es de facto zum Managementstandard geworden.

Die Idee des Matrixmanagements stammt aus den Managament-Denkfabriken der frühen 1970er Jahre. J. R. Galbraith legte 1971 eine der ersten Veröffentlichungen über das Thema vor. Darin beschäftigt er sich mit der Frage, wir organisations- und funktionsbezogene Verantwortlichkeiten kombiniert werden können. Die zu dieser Zeit vorherrschende Managementumgebung war hierarchisch strukturiert.

Organisationen waren große „siloartige“ Konstruktionen, bestehend aus Abteilungen, die von gewichtigen Abteilungsleitern beherrscht wurden. Dieses Konzept funktioniert hervorragend bis zu dem Zeitpunkt, an dem mehrere Projekte abteilungsübergreifend zu erledigen sind. Der Begriff der „projektbezogenen“ Matrix wurde vor über 30 Jahren von Projektmanagern und Verbänden wie dem Project Management Institute geprägt.

In einer projektbezogenen Matrix wird neben der funktionalen Organisation eine zweite Linie gebildet. Diesem Teil der Organisation, der die Projekte verwaltet, wird eine gewisse Verantwortung übertragen. Das Ergebnis sind organisationsbezogene Abteilungen auf der einen Seite und Projektmanager, die Projekte oder Produkte liefern, auf der anderen Seite.

Abteilungen tragen Projektmanagementverantwortlichkeiten gemeinsam

Warum beschäftigen wir uns mit diesem Thema, wenn wir über Enterprise Project Management sprechen? Weil dieses Modell der Eckpfeiler praktisch jeder Implementierung der Microsoft EPM-Lösung ist. Wenn Sie heutzutage mit der Implementierung von Project Server befasst sind, werden Sie mit Sicherheit bei Ihren Reisen auf dieses Modell stoßen. Es gibt aber auch Ausnahmen vom Matrixmanagementmodell, auf die ich anschließend noch eingehen werde; hier möge der Hinweis genügen, dass es bei Technologieorganisationen nahezu universal ist.

Wenn wir nun mit der Implementierung einer Microsoft EPM-Lösung befasst sind, finden wir bei der Organisation eine dieser möglichen Situationen vor:

  1. Es gibt keine Matrix.

    Die Organisation basiert vollständig auf siloartigen Organisationseinheiten. Jeder Abteilungsleiter verwaltet seine Abteilung wie eine Niederlassung der übergeordneten Organisation. Budgets werden innerhalb der Abteilungen in hierarchischer Form kumuliert (denken Sie an ein Organigramm). Wird ein Projekt initiiert, erfolgt das innerhalb der jeweiligen Abteilung, selbst wenn Ressourcen aus anderen Abteilungen für die Ausführung des Projekts erforderlich sein sollten. Wenn die Abteilung, die das Projekt verwaltet, dieses nicht mit eigenen Ressourcen ausführen kann, verhandelt sie mit anderen Abteilungen über die Anforderung fremder Ressourcen.

    Das hört sich gar nicht so schlecht an, bis Sie versuchen, ein solches Projekt zu verwalten. Wenn fast jedes Projekt abteilungsübergreifende Ressourcen benötigt, ist es unmöglich, die Prioritäten zwischen den Gruppen herauszufiltern. Es gibt keinen Anreiz für die Abteilungsleiter, die Kontrolle über die Priorität der eigenen Ressourcen aufzugeben. Ihnen fällt gar nicht ein, diese Macht abzutreten. Daher wird jedes Projekt, das nicht innerhalb einer Abteilung abgeschlossen werden kann, darunter leiden.

    Wenn wir dann mit Führungskräften sprechen, die eine Ebene über den Abteilungsleitern angesiedelt sind, beklagen diese im Allgemeinen, dass sie keine Ressourcenkapazitätsplanung erhalten. Das ist logisch. Es gibt weder eine abteilungsübergreifende Struktur für das Sammeln der Informationen, die für die Ressourcenkapazitätsplanung erforderlich sind, noch gibt es Anreize für die einzelnen Abteilungsleiter, sich einer zentralen Zuweisung von Prioritäten unterzuordnen, die für eine solche Analyse erforderlich wäre.

    In dieser Situation ist es nur wahrscheinlich, dass wir nicht nur eins, sondern mehrere Projektbüros vorfinden, und zwar ein Büro pro Abteilung, die sehr wenig miteinander kooperieren.

    Eine Implementierung der Microsoft EPM-Lösung in diesem Szenario setzt einige Überlegungen über eine gleichzeitige Anpassung der Organisation voraus. Häufig werden wir von solchen Organisationen gebeten, das Unmögliche möglich zu machen. Mehrere hundert oder sogar tausend Benutzer sollen geschult und Project Server soll installiert werden. In ein paar Wochen soll die Lösung in die Produktion gehen. Da das Unternehmen ein zentrales Enterprise Project Management-System gekauft hat, erwartet man nun, dass sich die Organisation sofort entsprechend aufstellt und wie eine zentrale Matrixumgebung funktioniert. Eine teure Wunschvorstellung. Es lässt sich nicht vermeiden, mit der Geschäftsleitung darüber zu sprechen, wie die Organisation verändert werden muss. Das sind in der Regel keine guten Nachrichten für das Management, das gehofft hatte, dass der Kauf der Software als Beitrag der Geschäftsleitung für eine allseitige Veränderung ausgereicht hätte.

    Wir beginnen solche Projekte mit der Ausarbeitung von Plänen für ein zentrales Projektmanagementbüro und zentrale Projektmanagementprozeduren. Project Server wird langsam aus der Mitte heraus eingeführt. Es ist nicht ungewöhnlich, dass solche Projekte 12 bis 24 Monate dauern, bis schließlich die ganze Organisation involviert ist. Wir haben gerade nach einer Wartezeit von 2 1/2 Jahren, in denen das Unternehmen an seinem eigenen Projekt – der Erstellung einer projektbezogenen Matrixorganisation – gearbeitet hat, ein derartiges Projekt wieder neu gestartet.

  2. Es ist eine ausgewogene Matrix vorhanden.

    Schön, wenn das der Fall ist, leider aber ziemlich ungewöhnlich. Die Aufrechterhaltung einer ausgewogenen Matrix erfordert eine ständige Anpassung und Pflege. Wenn wir aber doch auf eine ausgewogene Matrix stoßen, finden wir wahrscheinlich auch eine Sammlung hochentwickelter Prozeduren, definierte Rollen und einen Prozess, der allen Beteiligten gut verständlich ist. Eine Implementierung der Microsoft EPM-Lösung in dieser Art Organisation ist ein wahrer Glücksfall.

  3. Es gibt eine Matrix, aber sie ist nicht ausgewogen.

    Das ist bei weitem das häufigste Szenario, das wir antreffen, und das ist einleuchtend. Das Matrixmodell birgt schon naturgemäß einige Konflikte. Daher finden wir häufig eine Matrix, die zugunsten der Abteilung verschoben ist (mit einer schwachen projektbezogenen Matrixorganisation), oder eine Matrix mit einer starken projektbezogenen Matrixorganisation und schwachen Abteilungsleiterfunktionen. Oder wir haben eine Matrix, die zugunsten einiger Abteilungen und einiger Projektmanager verschoben ist, während andere Abteilungen und Projektmanager in ihren Funktionen geschwächt sind (die weitaus problematischste Konstellation). Hierbei ist der Schwerpunkt in der Organisation kaum zu ermitteln.

    Die Implementierung der Microsoft EPM-Lösung in solchen Umgebungen erfordert sorgfältige Erkundungen und eine genaue Bestandsaufnahme. Wo wurden Prozesse etabliert, die erfolgreich sind? Wo war Prozessen kein Erfolg beschieden? Wer oder was arbeitet auf zentraler Projektmanagementebene, die wir für die Implementierung von Project Server nutzen können? Wer oder was arbeitet nicht auf dieser Ebene?

    Bei derartigen Implementierungen müssen wir sehr vorsichtig bei der Auswahl der Elemente der EPM-Lösung sein, die zuerst bereitgestellt werden sollen, aber auch bei der Auswahl der Zielgruppe. Eine phasenweise Implementierung ist bei derartigen Szenarien äußerst wichtig, da ein radikaler Ansatz hier fast nie zum Erfolg führt.

Die Herausforderungen einer Matrix

Für diejenigen, die in ihrem Leben nichts anderes als Organisationen mit Matrixstruktur kennengelernt haben, hat sich wahrscheinlich nie die Frage gestellt, ob das eine gute oder schlechte Struktur ist oder welche Stärken und Schwächen dieser Managementtyp hat. Bei einer Matrixorganisation gibt es ein grundlegendes Problem, das häufig nicht einmal hinterfragt wird: In einer Matrixstruktur sind Konflikte vorprogrammiert. Die Struktur enthält zwei gegensätzliche Kräfte: die Abteilungsleiter und die Projektmanager. Das würden wir so natürlich nie offen sagen, aber diese Tatsache wird allein schon bei der Betrachtung der Struktur offensichtlich.

Das Ziel des Abteilungsleiters ist es, die Mitarbeiter in seiner Abteilung zu führen. Er will sicherstellen, dass seine Leute produktive, gut ausgebildete und zufriedene Mitarbeiter sind. Würden wir die Organisation den Abteilungsleitern überlassen, hätten wir glückliche, gut geschulte Mitarbeiter, die arbeitsmäßig nicht überlastet und gut entlohnt werden, aber nicht sehr produktiv sind.

Das Ziel des Projektmanagers ist es, auf die Fertigstellung des Projekts zu achten. Er will einerseits sicherstellen, dass sein Projekt so schnell und kostengünstig wie möglich ausgeführt wird, andererseits muss er Umfang und Qualität, wie sie bei Projektbeginn definiert wurden, im Auge behalten. Würden wir die Organisation den Projektmanagern überlassen, wären zwar eine Reihe von Projekten schnell erledigt, aber es gäbe auch eine hohe Fluktuation beim Personal, das sich im Namen der Projektfertigstellung völlig verausgaben würde.

Daraus entstand die Idee der Matrixorganisation: Wird ein Konflikt zwischen diesen beiden Kräften erzeugt, wird sich die Organisation auf einer gesunden Ebene zwischen Produktivität und Mitarbeiterzufriedenheit einpendeln. Voraussetzung ist allerdings, dass das Kräfteverhältnis zwischen Abteilungsleitern und Projektmanagern in etwa ausgeglichen ist. Das Problem dabei ist, dass nicht alle Menschen gleich sind. Es wird immer Projektmanager geben, die mehr Erfahrung haben als andere, oder Abteilungsleiter, die fähiger sind als andere.

Durch diese Ungleichheit gerät die Matrix vom ersten Tag an aus dem Gleichgewicht. Schon allein das Wissen darum, dass eine ausgewogene Matrixorganisation die Ausnahme ist, reicht häufig aus, um projektbezogene Matrixorganisationen und funktionale Organisatoren zum Nachdenken über die nötige Ordnung anzuregen. Das kann durchaus etwas Gutes haben.

Eine perfekte Ausgewogenheit herzustellen, ist nicht so wichtig. Viel wichtiger ist der Versuch, festzustellen, wo es bei Projekten und Mitarbeitern der Organisation hakt. Die Tools, die eine Matrixumgebung braucht, um funktionieren zu können, sind immer gleich: Prozesse und Kommunikation. Ein gut ausgebildeter Implementierer kann die Prozesse und Prozeduren identifizieren, die das beinhalten, was für die Organisation wichtig ist.

Abschaffen der Matrix?

Nicht jeder ist ein Anhänger von Matrixorganisationen. In den letzten Jahren haben eine Reihe von Unternehmenslenkern den Gedanken geäußert, dass die Matrixorganisation vielleicht doch nicht die beste Lösung sei. „Wenn man das Personal in dedizierte Projektteams aufteilt“ so ihr Credo, „ist man glücklicher damit“. Oder auch: „Man muss Projekte so organisieren, dass sie innerhalb einer Abteilung abgewickelt werden können, und sie dann den Abteilungsleitern zuweisen.“ Weitere Ausführungen zu diesem Thema finden Sie in dem Artikel von Rob Enderle, der davon überzeugt ist, dass das Matrixmodell ausgedient hat.

In einer Reihe von Organisationen, die ich kürzlich aufgesucht habe, bin ich auf Matrixmodelle gestoßen, die sich in die ein oder andere Richtung verschoben hatten. Hier sah ich mich veranlasst, Empfehlungen in Bezug auf die Implementierung von Project Server und der Microsoft EPM-Lösung auszusprechen, die etwas anders lauten. Wenn es keine zentrale projektbezogene Matrixorganisation gibt, ist eine solche meine erste Empfehlung. Bei einigen Organisationen wurde mir schon gesagt, dass man Project Server nur zur Reduzierung der Lizenzierungskosten einsetzen wolle, aber nicht die Absicht zur Zusammenarbeit habe. Das macht natürlich wenig Sinn. Das ganze Konzept eines zentralen Enterprise Project Management-Systems ist darauf ausgerichtet, Daten für die Analyse und Anzeige zusammenzutragen, damit Projekte gemeinsam verwaltet werden können. Wenn Sie das nicht beabsichtigen, sollten Sie bei Ihren individuellen Desktop-Lizenzen bleiben.

In einigen Organisationen wurde das Matrixmodell durch eine Rückkehr zur siloartigen Denkweise ersetzt. So etwas kann bei einer massiven Veränderung der Unternehmensstruktur geschehen oder durch externe Impulse wie einen großen Umbruch der Weltwirtschaft ausgelöst werden. Unter Druck kämpfen einige Manager mit allen verfügbaren Mitteln ums Überleben. Unlängst habe ich in verschiedenen großen Organisationen Abteilungsleiter erlebt, die mit Erfolg die projektbezogene Matrixorganisation und darin ihr Personal als „redundante Projektressourcen“ beschrieben und ihren Einfluss geltend machten, um die Kontrolle wieder den Abteilungsleitern zu übertragen.

Das Resultat solcher Veränderungen kann genau das Gegenteil von dem bewirken, was beabsichtigt war. Um ehrlich zu sein: Für einen kurzen Zeitraum sinken die Kosten. Doch die Effizienzeinbußen bei den Mitarbeitern, deren Aufgabe es war, durch kürzere, preiswertere Projekte Effizienz zu erzeugen, lassen häufig nach einer Weile die Kosten wieder sprunghaft ansteigen. Bei großen Organisationen kann es Monate oder sogar ein oder zwei Jahre dauern, bevor sich diese Effekte bemerkbar machen. In der Zwischenzeit bricht die Matrixorganisation zusammen und ein Großteil der Leistungsfähigkeit von Project Server geht verloren.

In fortschrittlicheren Organisationen gewinnt die projektbezogene Matrixorganisation aufgrund ihrer Möglichkeiten wieder an Beachtung und Respekt. Angesichts der aktuellen wirtschaftlichen Herausforderungen kommt ihr vielleicht sogar eine neue Form der Berechtigung zu.

Wiederherstellen (oder Schaffen) der Ausgewogenheit

Nachfolgend ein paar Anregungen zum Nachdenken über die jeweils gegebene Matrix-Managementumgebung für diejenigen, die aktuell mit EPM-Implementierungen beschäftigt sind oder es in Zukunft sein werden:

Nehmen Sie zuerst die Prozesse und die Definition der Rollen auf jeder Linie der Matrix unter die Lupe. Achten Sie bei Gesprächen darauf, an welcher Stelle Prozesse die Organisation produktiver oder bürokratischer machen. Achten Sie bei den Rollen auf das klassische Problem „Verantwortung ohne Weisungsbefugnis“, über das so oft in Projektmanagementkreisen gesprochen wird.

Wenn Sie ganz neu beginnen, können Sie in der hierarchischen Struktur noch Prozesse finden, die übernommen werden können, und die sind Gold wert. Wenn Sie innerhalb einer Abteilung einen vorhandenen Prozess oder eine Prozedur finden, die vom ganzen Unternehmen übernommen werden könnte, sollten Sie die Quelle des Prozesses entsprechend würdigen. Damit schlagen Sie zwei Fliegen mit einer Klappe: 1. Sie haben einen Prozess in einer Abteilung, der nicht implementiert werden muss. Er wurde bereits angewendet. 2. Sie gewinnen möglicherweise einen engen Verbündeten in ihrem Bemühen, eine zweite Linie der Matrix zu erstellen, da der betreffende Abteilungsleiter deutlich sehen kann, dass sie nicht alles verwerfen, was bereits in den Abteilungen geleistet wurde.

Wenn Sie abteilungsübergreifende Prozesse erstellen müssen, denken Sie daran, die Leute mit ins Boot zu holen, die sich ausgeschlossen oder „entmachtet“ fühlen könnten. Beispiel: Neulich half ich einer Organisation, die einen abteilungsübergreifenden Kapazitätsplanungsprozess für die Ressourcen schaffen musste. Wie man sich vorstellen kann, waren die Abteilungsleiter nicht sehr erbaut von dieser Idee, da sie spürten, dass sie einige Instrumente zur Kontrolle ihrer Mitarbeiter verlieren würden. Ich empfahl die Bildung eines Portfolio-Lenkungsausschusses (unter Beteiligung dieser Abteilungsleiter), der die Projektprioritäten festlegen sollte. Dadurch hatten die Abteilungsleiter nicht das Gefühl, Befugnisse zu verlieren, sondern wurden Teil der neuen Zuständigkeitsstruktur für abteilungsübergreifende Entscheidungen. Durch diese Vorgehensweise, nämlich das Einbeziehen genau der Leute, die sonst opponieren würden, ließ sich ein ansonsten problematischer Aspekt einer EPM-Implementierung lösen.

Denken Sie schließlich auch daran, die Implementierung „transparent“ zu machen und die zentralen Prozesse ohne übermäßige Intervention durch die Arbeit mit Layern zu etablieren. Beispiel: Wir arbeiten an einem Projekt, bei dem die funktionale Matrixorganisation sehr stark ist. Die projektbezogene Matrixorganisation steckt noch in den Kinderschuhen. Das mühevolle Kämpfen gegen die Organisationsstruktur ist für sie nicht ideal. Wir haben empfohlen, die Ressourcenverwaltung fürs erste nicht bis zur individuellen Ebene auszudehnen. Die Organisation wird hingegen die Ressourcenverwaltung als zentralen Prozess implementieren, wobei eine sehr kleine Anzahl von Benutzern der projektbezogenen Matrixorganisation entweder direkt oder als Abgesandte der Abteilungen zugeteilt werden. Alle Ressourcen werden als „allgemein“ definiert, und fürs erste wird es nicht das Ziel sein, jeden Mitarbeiter bis zur individuellen Vorgangsebene zu planen. Stattdessen wird die projektbezogene Matrixorganisation mit einer Ressourcenkapazitätsplanung beginnen, die für die bevorstehenden Zeiträume den Ressourcenbedarf ermittelt und das Problem zur Lösung an die Abteilungsleiter übergibt. Wir gehen davon aus, dass die Abteilungsleiter mit der Zeit selbst eine Ausweitung der EPM-Implementierung fordern, um sich selbst die Arbeit mit der Verwaltung der Ressourcenkonflikte zu erleichtern.

Fazit

Mit ziemlicher Sicherheit werden Sie bei der Implementierung einer Enterprise Project Management-Lösung, sei es als Berater für andere oder in der eigenen Organisation, mit den Problemen und Herausforderungen der Matrixorganisation konfrontiert. Eine der größten Herausforderungen bei EPM und EPM-Systemen wie die Microsoft EPM-Lösung ist es, für eine ausgewogene Matrix zu sorgen. Denn nur so ist Ihnen der Erfolg sicher.

Informationen zum Autor

Chris Vandersluis ist der Präsident und Gründer von HMS Software, einem im kanadischen Montreal ansässigen Microsoft Certified Partner. Er hat einen Abschluss in Wirtschaftswissenschaften von der McGill University und mehr als 30 Jahre Erfahrung in der Automatisierung von Projektsteuerungssystemen. Er ist ein langjähriges Mitglied des PMI (Project Management Institute) und hat geholfen, die Ortsverbände der Microsoft Project-Benutzergruppen (MPUG) in Montreal, Toronto und Quebec zu gründen. Vandersluis hat Beiträge in Fortune, Heavy Construction News, im Magazin "Computing Canada" und im PMNetwork von PMI veröffentlicht. Darüber hinaus verfasst er regelmäßig die Leitartikel für Project Times. Er unterrichtet Projektmanagement für Fortgeschrittene an der McGill University und hält häufig Vorträge auf Veranstaltungen der Project Management Association in Nordamerika und weltweit. HMS Software ist der Herausgeber von TimeControl, einem projektorientierten Zeiterfassungssystem, und seit 1995 ein Microsoft Project Solution Partner.

Sie können Chris Vandersluis per E-Mail kontaktieren: chris.vandersluis@hms.ca

Wenn Sie weitere EPM-bezogene Artikel von Chris Vandersluis lesen möchten, besuchen Sie die EPM Guidance-Website von HMS (http://www.epmguidance.com/?page_id=39).

Teilen Facebook Facebook Twitter Twitter E-Mail E-Mail

War diese Information hilfreich?

Sehr gut. Noch anderes Feedback?

Was können wir verbessern?

Vielen Dank für Ihr Feedback!

×