Projektcontrolling in der IT - Martin Kütz - ebook

Projektcontrolling in der IT ebook

Martin Kütz

0,0

Opis

Erfolgreiche Projekte benötigen ein wirksames Projektcontrolling, das Initiierung, Planung, Kontrolle und aktive Steuerung sowie Evaluierung von Projektergebnissen verbindet und koordiniert. Dabei sind die vielfältigen Besonderheiten von IT-Projekten zu berücksichtigen. Bei der Steuerung von Projektportfolios bilden die Priorisierung der Projekte, fachliche Abhängigkeiten und die Vernetzung über gemeinsame Ressourcennutzung wesentliche Herausforderungen. Das Buch zeigt praxisgerechte Ansätze und Vorgehensweisen für das IT-Projektcontrolling. Viele Beispiele verdeutlichen Konzepte und Methoden.

Ebooka przeczytasz w aplikacjach Legimi na:

Androidzie
iOS
czytnikach certyfikowanych
przez Legimi
Windows
10
Windows
Phone

Liczba stron: 423

Odsłuch ebooka (TTS) dostepny w abonamencie „ebooki+audiobooki bez limitu” w aplikacjach Legimi na:

Androidzie
iOS



Projektcontrolling in der IT

Prof. Dr. Martin Kütz lehrt Wirtschaftsinformatik an der Hochschule Anhalt und ist geschäftsführender Gesellschafter des Beratungsunternehmens TESYCON GmbH. Er verbindet langjährige praktische Erfahrungen in IT-Management und IT-Beratung mit einem starken Interesse an theoretischen und methodischen Fragestellungen. Seine Erfahrungen gibt er in Lehrveranstaltungen, Beratungsprojekten, Veröffentlichungen, Vorträgen und Seminaren weiter. Er arbeitet aktiv in der Fachgruppe IT-Controlling der Gesellschaft für Informatik e.V. mit.

Martin Kütz

Projektcontrolling in der IT

Steuerung von Projekten und Projektportfolios

Martin Kütz

[email protected]

Lektorat: Christa Preisendanz & Vanessa Wittmer

Copy-Editing: Ursula Zimpfer, Herrenberg

Herstellung: Birgit Bäuerlein

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Fachliche Beratung und Herausgabe von dpunkt.büchern im Bereich Wirtschaftsinformatik: Prof. Dr. Heidi Heilmann · [email protected]

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Buch 978-3-89864-756-4

PDF 978-3-86491-084-5

ePub 978-3-86491-085-2

1. Auflage 2012

Copyright © 2012 dpunkt.verlag GmbH

Ringstraße 19 B

69115 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort

Soll man ein Buch über Projektcontrolling schreiben, wo man doch mit Büchern über Projektmanagement ganze Bibliotheken füllen könnte? Die Antwort lautet: Ja. Nicht nur, weil sonst dieses Vorwort nicht geschrieben werden könnte, sondern vor allem, weil das Teilgebiet des Controllings im Projekt- und Portfoliomanagement immer noch unzureichend ausgeleuchtet ist. Dieses Buch will dazu beitragen, diese Lücke zu schließen. Als Autor habe ich hier meine Beobachtungen, Erfahrungen und daraus abgeleitete Schlussfolgerungen niedergelegt. Das beinhaltet naturgemäß eine persönliche und zuweilen auch subjektive Sicht der Dinge. Sie als Leser müssen nun meinen Gedanken-»Wanderungen« folgen. Ich hoffe aber, dass ich als »Wanderführer« passabel bin und Sie für Ihr eigenes Projektcontrolling viele nützliche und nutzbare Hinweise finden. Wenn das gelingt, hat dieses Buch seinen Zweck erfüllt!

Als Autor arbeitet man zwar selbstständig, aber nur mithilfe und durch Mitwirkung anderer entsteht ein lesbares Buch. An dieser Stelle sei daher den Mitarbeitern des dpunkt.verlags für ihre Unterstützung dieses Buchprojektes herzlich gedankt, insbesondere Frau Christa Preisendanz für ihr geduldiges Drängen und Frau Prof. Dr. Heidi Heilmann für ihre fundierte und konstruktive Kritik. Ein weiteres Dankeschön gilt meiner Tochter Britta Kütz, deren Erfahrungen in der Wirtschaftsprüfung ich bei den Ausführungen zur Aktivierung von Projektaufwand nutzen konnte.

Und nun, liebe Leser, überlasse ich Ihnen dieses Buch zur Lektüre. Wenn Sie Anregungen für Verbesserungsmöglichkeiten haben, Fehler entdecken oder Fragen haben, dann würde ich mich über den Dialog mit Ihnen freuen.

Martin Kütz

Köthen, im Februar 2012

Inhaltsübersicht

1 Einleitung

2 Projekt und Portfolio

3 Projektorganisation

4 Projektcontrolling

5 Portfoliocontrolling

6 Fazit Projektcontrolling

Anhang

A Abkürzungsverzeichnis

B Symbolverzeichnis

C Literatur

Stichwortverzeichnis

Inhaltsverzeichnis

1

Einleitung

2

Projekt und Portfolio

2.1

Projektdefinition

2.2

Projektportfolio

2.3

Fragen des Controllings

2.4

Empfehlungen für die Praxis

3

Projektorganisation

3.1

Projektauftraggeber

3.2

Projektauftragnehmer

3.3

Projektinvestor

3.4

Projektlenkung

3.5

Projektleitung

3.6

Projektteam

3.7

Portfoliomanagement

3.8

Organisation des Projektcontrollings

3.9

Assoziierte Rollen

3.10

Fragen des Controllings

3.11

Empfehlungen für die Praxis

4

Projektcontrolling

4.1

Definition und Abgrenzung

4.2

Projektinitiierung

 

4.2.1 Fragen des Controllings

 

4.2.2 Empfehlungen für die Praxis

4.3

Rentabilität von Projekten

 

4.3.1 Daten der Projektbewertung

 

4.3.2 Aktivierung von Projektaufwand

 

4.3.3 Kennzahlen der Projektbewertung

 

4.3.4 Anschluss- und Erweiterungsprojekte

 

4.3.5 Kauf oder Miete

 

4.3.6 Steuereffekte

 

4.3.7 Projekte mit Optionen

 

4.3.8 Nicht finanzielle Nutzeffekte

 

4.3.9 Unsicherheit

 

4.3.10 Dynamische Investitionsrechnung

 

4.3.11 Fragen des Controllings

 

4.3.12 Empfehlungen für die Praxis

4.4

Projektplanung

 

4.4.1 Projektaufgabe

 

4.4.2 Projektstrukturplan

 

4.4.3 Ablaufplanung

 

4.4.4 Aufwandsplanung

 

4.4.5 Terminplanung

 

4.4.6 Finanzplanung

 

4.4.7 Abschluss der Projektplanung

 

4.4.8 Fragen des Controllings

 

4.4.9 Empfehlungen für die Praxis

4.5

Projektdurchführung

 

4.5.1 Aufwandssteuerung

 

4.5.2 Terminsteuerung

 

4.5.3 Qualitätssteuerung

 

4.5.4 Änderungssteuerung

 

4.5.5 Problemsteuerung

 

4.5.6 Risikosteuerung

 

4.5.7 Leistungssteuerung

 

4.5.8 Umsetzung der Projektsteuerung

 

4.5.9 Projektabbruch und Projektsanierung

 

4.5.10 Umplanungen

 

4.5.11 Fragen des Controllings

 

4.5.12 Empfehlungen für die Praxis

4.6

Projektabschluss

 

4.6.1 Fragen des Controllings

 

4.6.2 Empfehlungen für die Praxis

4.7

Projektevaluierung

 

4.7.1 Fragen des Controllings

 

4.7.2 Empfehlungen für die Praxis

5

Portfoliocontrolling

5.1

Projektbewertung

 

5.1.1 Kalkulationsspannen

 

5.1.2 Muss-Projekte

 

5.1.3 Verbundene Projekte

 

5.1.4 Fragen des Controllings

 

5.1.5 Empfehlungen für die Praxis

5.2

Aufbau eines Projektportfolios

 

5.2.1 Projektportfolio ohne Engpassressource

 

5.2.2 Projektportfolio mit Engpassressource

 

5.2.3 Periodenabgrenzung

5.3

Ablaufplanung im Portfolio

 

5.3.1 Standardisierte Planungseinheiten

 

5.3.2 Fragen des Controllings

 

5.3.3 Empfehlungen für die Praxis

5.4

Umsetzung der Portfoliosteuerung

 

5.4.1 Organisation der Portfoliosteuerung

 

5.4.2 Kennzahlen der Portfoliosteuerung

 

5.4.3 Fragen des Controllings

 

5.4.4 Empfehlungen für die Praxis

6

Fazit Projektcontrolling

Anhang

A

Abkürzungsverzeichnis

B

Symbolverzeichnis

C

Literatur

 

Stichwortverzeichnis

1 Einleitung

Steuerungsprozess

In diesem Buch geht es um das Controlling von Projekten und Projektportfolios im Umfeld der IT. Controlling wird dabei im wörtlichen Sinne als Steuerung verstanden und damit als Kernaufgabe des Projekt- und Portfoliomanagements betrachtet. Es geht also weniger darum, eine Art umfassende Stellenbeschreibung für einen Projektcontroller zu erstellen (den es in vielen IT-Projekten und IT-Organisationen gar nicht gibt), sondern darum, den Prozess der Steuerung im Projekt- und Portfolioumfeld der IT zu durchleuchten sowie Aufgaben, Rollen und korrespondierende Methoden zu diskutieren.

Projekt/Prozess/Portfolio

Im zweiten Kapitel dieses Buches werden die grundlegenden Begriffe des Projektes und des Projektportfolios definiert. Es wird eine Abgrenzung zwischen Projekten und Prozessen vorgenommen und herausgearbeitet, dass ein Prozess – überspitzt formuliert – einmal geplant wird und dann immer wieder ausgeführt werden kann, hingegen ein Projekt nur genau einmal ausgeführt wird, aber auch während der Ausführung mehrfach geplant und umgeplant werden muss. Das Projektportfolio wird als Gruppe von Projekten verstanden, die übergreifend zu planen und zu steuern sind. Insofern wird hier durchgängig nur von einer Portfoliosteuerung gesprochen, die die in der Praxis übliche oftmals eigenständig diskutierte Multiprojektsteuerung umfasst.

Organisatorische Fragen

Im dritten Kapitel werden organisatorische Fragen der Projekt- und Portfoliosteuerung behandelt. Hier geht es vor allem darum, die wesentlichen Rollen im Projektcontrolling zu benennen und ihr Zusammenspiel bei der Initiierung, Planung und Durchführung von Projekten sowie der übergreifenden Steuerung von Projektportfolios in IT-Anwenderorganisationen zu beleuchten, also solchen Organisationen, die IT zur Unterstützung ihres Kerngeschäftes und ihrer Geschäftsprozesse nutzen. Grundsätzlich können die hier vorgestellten Rollen jedoch auf andere Kontexte, also z.B. IT-Dienstleister, die ihr Geschäft in Projektform betreiben, ohne Schwierigkeiten übertragen werden.

Rollen

Ausgangspunkt der Überlegungen sind (natürlich) die Rollen des Projektauftraggebers und des Projektauftragnehmers. Hier wird jedoch pointiert noch eine dritte Rolle ins Spiel gebracht, nämlich die Rolle des Projektinvestors. Dahinter steht die für Anwenderorganisationen typische Situation, dass Auftraggeber von IT-Projekten (in der Regel Fachbereiche) und Auftragnehmer von IT-Projekten (in der Regel der IT-Bereich der Organisation) über die Durchführung von Projekten nicht alleine entscheiden dürfen, sondern die eigentliche Projektentscheidung von der obersten Leitung der Organisation bzw. einer von ihr beauftragten und autorisierten Stelle gefällt wird. Die eventuell ungewöhnlich erscheinende Bezeichnung »Projektinvestor« rührt daher, dass die Entscheidung für oder gegen ein IT-Projekt letztlich eine Entscheidung über die Verwendung des (knappen) verfügbaren Kapitals der Organisation ist. Die Rolle des Projektinvestors ermöglicht es zudem, viele Abläufe und Schwierigkeiten in der Projekt- und Portfoliosteuerung sehr klar und verständlich zu modellieren.

Organisation des Projektcontrollings

Neben der Beschreibung der verschiedenen Rollen und ihres Zusammenspiels vor, während und nach einem Projekt wird im dritten Kapitel auch die Frage diskutiert, wie Projektcontrolling organisatorisch zuzuordnen ist. Es wird schnell klar, dass eigentlich jede der beteiligten Rollen im Rahmen ihrer spezifischen Managementaufgaben auch ein geeignetes Controlling benötigt. Aus dem Wirtschaftlichkeitsprinzip ergibt sich dann jedoch die Überlegung, Controllingaufgaben im Projektcontrolling organisatorisch an einer Stelle zu bündeln und von dieser Stelle aus allen beteiligten Verantwortlichen entsprechende Controllingservices anzubieten. Wo man diese Allokation von Controllingaufgaben in der Aufbauorganisation vornehmen sollte, hängt jedoch von verschiedenen Rahmenbedingungen in der konkreten Organisation ab.

Aktivitäten des Projektcontrollings

Im vierten und umfangreichsten Kapitel des Buches wird das eigentliche Projektcontrolling behandelt. Hier geht es um Abläufe, Methoden und Werkzeuge. Das Buch folgt dabei den Phasen der Initiierung, Planung und Durchführung von Projekten, des Projektabschlusses und der nachlaufenden Projektevaluierung. Dieses vierte Kapitel weist einige Besonderheiten auf, die aus der hier eingenommenen spezifischen Sicht auf das Projektcontrolling resultieren.

Rentabilität

Erstens: Als wesentlicher Entscheidungsparameter für oder gegen eine Projektdurchführung wird die Rentabilität betrachtet, also die Vermehrung oder Verzinsung des eingesetzten Kapitals, d.h. des finanziellen Wertes der für das Projekt benötigten Ressourcen. Vor dem Hintergrund der in der Praxis weitgehend akzeptierten und etablierten wertorientierten Unternehmensführung ist die Rentabilität von Projekten das entscheidende Argument in der Durchführungsentscheidung.

Investitionsrechnung

Bei den vorgestellten Methoden der die Projektentscheidung vorbereitenden Investitionsrechnung wird bewusst »nur« auf die statische Investitionsrechnung zurückgegriffen, da man hier die Entscheidungsmechanismen besonders klar erkennen und verfolgen kann. Zudem sind die in der Investitionsrechnung für IT-Projekte berücksichtigten Zeitspannen in der Praxis (mit einer Betriebsphase von üblicherweise 36 Monaten) so knapp bemessen, dass die Diskontierungseffekte der dynamischen Investitionsrechnung die Projektentscheidung noch nicht wesentlich beeinflussen.

Nutzeffekte

Zweitens: Die für die Projektentscheidung wesentlichen Nutzeffekte eines Projektes werden als finanziell bzw. finanziell bewertbar angenommen. Der in der Praxis gebräuchlichen »Ausrede«, die Nutzeffekte von IT-Projekten seien nicht quantifizierbar und schon gar nicht finanziell bewertbar, wird hier bewusst nicht gefolgt. Im Gegenteil: Eine finanzielle Bewertung des Projektnutzens ist immer möglich; die Entscheidungstheorie stellt seit Langem geeignete Werkzeuge zur Verfügung. Das bedeutet allerdings nicht, dass eine solche finanzielle Bewertung des Projektnutzens einfach ist. Sie kann sich extrem schwierig gestalten.

Planung und Vorbereitung

Drittens: Die Unterkapitel über Initiierung, Rentabilität und Planung von IT-Projekten nehmen einen großen Raum ein. Dahinter steht die Erfahrung, dass Vorbereitung und Planung wesentliche Erfolgsfaktoren jedes Projektes darstellen. Projekte mit fundierter Durchführungsentscheidung und sorgfältiger Planung erweisen sich in der Durchführung bei Turbulenzen und Krisen als belastbarer und haben auch bei gravierenden Veränderungen und Umplanungen gute Chancen auf einen erfolgreichen Abschluss. In Analogie zu dem Aphorismus, dass nichts praktischer sei als eine gute Theorie, kann man für IT-Projekte konstatieren, dass nur gute Planung und Vorbereitung die erforderliche Flexibilität in der Durchführung sicherstellen können.

Projektdurchführung

Viertens: In der Steuerung der Projektdurchführung wird konsequent auf sieben Steuerungsdimensionen abgestellt. Die Steuerungsdimensionen »Leistung«, »Qualität«, »Aufwand« und »Termin« folgen dem bekannten »Teufelsquadrat des Projektmanagements«. Hinzu kommen hier die Dimensionen »Änderungen«, »Probleme« und »Risiken«. Damit lässt sich eine konsequente und klar strukturierte Durchführungssteuerung von IT-Projekten realisieren.

Projektsanierung/Projektabbruch

Fünftens: Explizit werden Projektsanierung und Projektabbruch behandelt. Beides sind Extremsituationen, aber gerade in solchen Situationen muss Projektcontrolling funktionieren und die erforderliche Managementunterstützung leisten können.

Projektevaluierung

Sechstens: Schließlich wird die Projektevaluierung diskutiert, also die nach Projektabschluss erforderlichen Aktivitäten des Controllings, um die aus dem Projekt resultierenden Folgekosten und Nutzeffekte zu erfassen und gegen die vor Projektbeginn dokumentierten Erwartungen bzw. Versprechungen der Projektinitiatoren abzugleichen. Die Evaluierung eines Projektes muss bereits in der Projektinitiierung angelegt werden; auch das ist ein Grund, warum in diesem Buch der Bereich der planerischen und vorbereitenden Aktivitäten eine gewisse Dominanz zeigt.

Portfoliocontrolling

Im fünften Kapitel wird das die einzelnen Projekte übergreifende Portfoliocontrolling diskutiert. Hier steht die Frage im Vordergrund, wie Portfolios von IT-Projekten entstehen und nach welchen Kriterien sie »optimiert« werden können. Die Diskussion führt zu dem Ergebnis, dass gerade im Portfoliomanagement die Denkweise des Timeboxing hilft, die unvermeidbare Komplexität zu begrenzen und zu beherrschen. Es wird ein Ansatz vorgestellt, mit dem die Zeit und die verfügbaren (Personal-)Ressourcen in standardisierten Einheiten, sogenannten Time & Capacity Container (TCC), dargestellt werden und so die Portfolioaufgabe in ihrer Komplexität deutlich reduzieren können. Natürlich müssen sich alle Projekte dann schon in der Planung an dem vorgegebenen zeitlichen Raster und der vorgegebenen Gruppierung der Ressourcen ausrichten.

Portfolioabwicklung

Für die Abwicklung eines IT-Projektportfolios kann man konsequent auf die Steuerungsdimensionen der einzelnen Projekte und damit auf deren Daten zurückgreifen. Jedoch muss die Portfoliosteuerung ergänzt werden um die Verfolgung des Kapitalbedarfs und Ressourcenbedarfs für das Portfolio insgesamt. Es ist zu beachten, dass ein bestimmtes, zur Verfügung stehendes Kapital möglichst gut durch Projekte ausgenutzt werden kann. Ebenso ist zu beachten, dass auch die benötigten (physischen) Ressourcen einerseits beschränkt sind und andererseits optimal ausgelastet werden müssen.

Fragen/Empfehlungen

Jedes Kapitel des Buches schließt mit einem Unterkapitel »Fragen des Controllings« und einem weiteren Unterkapitel »Empfehlungen für die Praxis«. Das erstgenannte Unterkapitel soll mit einer gewissen inhaltlichen Vollständigkeit alle Themen ansprechen, mit denen sich das Controlling im jeweils spezifischen Gebiet auseinandersetzen sollte. In den Empfehlungen werden bestimmte Erfahrungen und Beobachtungen dokumentiert; diese sind durchaus persönlich geprägt und folgen einer subjektiven Bewertung und Auswahl.

2 Projekt und Portfolio

Sollen Planung, Steuerung und Kontrolle von Projekten und Projektportfolios diskutiert werden, so geht es nicht um das Projektmanagement im Allgemeinen, sondern um diejenige Unterstützung des Projektmanagements, die man unter dem Begriff des Controllings zusammenfasst. Da es spezifische Steuerungsobjekte betrifft, nämlich IT-Projekte und Projektportfolios in der IT, muss zunächst geklärt werden, was ein Projekt ist. Dann sind verschiedene Kategorien von IT-Projekten zu diskutieren. Und schließlich ist zu beschreiben, wie aus Projekten Portfolios gebildet werden. Die daraus resultierenden Aufgaben des Projektcontrollings werden dann in Kapitel 4 dargestellt.

2.1 Projektdefinition

DIN 69901

Es ist üblich (vgl. [Schelle 2011]), in den Projektbegriff über die Norm DIN 69901 einzusteigen. Demnach ist ein Projekt »ein Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, z.B. Zielvorgabe, zeitliche, finanzielle, personelle und andere Begrenzungen, Abgrenzung gegenüber anderen Vorhaben, projektspezifische Organisation«.

Diese Definition signalisiert mit den Formulierungen »im Wesentlichen« und »z.B.«, dass sie einige, aber nicht alle konstituierenden Merkmale eines Projektes nennt. Sie deutet an, dass es weitere typische Merkmale von Projekten gibt, und zwar offenbar so viele, dass man sie nicht aufzählen konnte oder wollte. Außerdem besagt sie, dass nicht die einzelnen Merkmale ein Projekt ausmachen, sondern die jeweils einmalige Kombination dieser Merkmale. Ob man also ein Projekt vor sich hat, kann man nur dann feststellen, wenn man die »Einmaligkeit der Bedingungen in ihrer Gesamtheit« erkennt.

Merkmale eines Projektes

Gleichwohl macht es Sinn, die verschiedenen Merkmale, die ein Projekt ausmachen (können), im Einzelnen zu diskutieren. Die DIN 69901 und einschlägige Literatur (vgl. [Schelle 2011]) nennen die in Tabelle 2–1 aufgeführten Merkmale.

DIN 69901

Weitere Merkmale

Zielvorgabe

Zeitliche Begrenzungen

Finanzielle Begrenzungen

Personelle Begrenzungen

Projektspezifische Organisation

Aufgabenmäßige Bestimmung

Zeitliche Bestimmung

Einmaligkeit

Neuartigkeit

Komplexität

Aufgabenbezogenes Budget

Rechtliche und organisatorische Zuordnung

Interdisziplinarität

Außergewöhnlichkeit

Tab. 2–1 Konstituierende Merkmale von Projekten

Bei Durchsicht der Literatur (z.B. [Bea/Scheurer/Hesselmann 2008], [Kellner 2001], [Patzak/Rattay 2004], [Wischnewski 2001], [Stöger 2011]) und in Gesprächen mit erfahrenen Projektleitern trägt man schnell weitere Merkmale von Projekten zusammen, die sich in neun Bereiche zusammenfassen lassen (vgl. Tab. 2–2).

Bereich

Bezeichnung

Assoziierte Begriffe

1

Aufgabe und Ergebnis

Aufgabenmäßige Bestimmung/Zielvorgabe/Zieldefinition/Qualität der Arbeitsergebnisse/Strukturierung der Projektaufgabe

2

Einmaligkeit

Außergewöhnlichkeit/keine identische Wiederholung möglich/neuartige und unbekannte Probleme

3

Auswirkungen

Neuartigkeit/Veränderung der Auftraggeberorganisation/Längerfristige Auswirkungen

4

Größe und Komplexität

Komplexität/erhebliche Größe/erheblicher Planungs- und Steuerungsaufwand/komplexes Vorhaben mit verschiedenen Techniken und Methoden

5

Interdisziplinarität

Zusammenarbeit von Menschen unterschiedlicher Fachrichtungen und Arbeitsweisen/Zusammenarbeit von Menschen mit unterschiedlichen Kenntnissen und Erfahrungen, mit unterschiedlichen Sprech- und Denkgewohnheiten

6

Zeitlicher Rahmen

Zeitliche Begrenzungen/zeitliche Bestimmung/Termine/Meilensteine

7

Begrenzte reale und finanzielle Ressourcen

Finanzielle Begrenzungen/aufgabenbezogenes Budget (Investitionen, Kosten)/eigenes und beschränktes Budget/außergewöhnlicher Kapitalbedarf/gezielte Bereitstellung von Ressourcen/Personelle Begrenzungen/Bereitstellung von Arbeitsmitteln/Bereitstellung von Infrastruktur

8

Organisatorischer Rahmen

Projektspezifische Organisation/rechtlich-organisatorische Zuordnung/formalisierte Entscheidung über die Durchführung/Bestimmung des Nutzens bzw. der Sinnhaftigkeit/phasenartige Durchführung/Mitwirkung des Auftraggebers/unterschiedliche und abgrenzbare Aufgaben/förmlicher Abschluss/Kommunikation/Berichterstattung/Strukturierung

9

Risiken

Besondere Risiken/Möglichkeit des Abbruchs/Möglichkeit des Scheiterns/interne Risiken/externe Risiken

Tab. 2–2 Charakterisierende Merkmale von Projekten

Jedes Projekt ist gekennzeichnet durch eine spezifische Kombination dieser neun Merkmalsgruppen. Eine Betrachtung einzelner Merkmalsgruppen führt zu den nachfolgend skizzierten Herausforderungen für das Projektcontrolling.

Aufgabe und Ergebnis

Jedes Projekt muss ein Ziel haben. Entweder soll an seinem Ende ein Ergebnis vorliegen, das unabhängig vom Projekt weiter existiert und genutzt wird, oder es soll eine bestimmte Fragestellung beantwortet werden, die für die Organisation interessant und wertvoll ist.

Veränderliche Ziele

Ein Projektziel kann z.B. ein neues IT-System sein, ein geänderter Prozess in der IT-Organisation oder die Erkenntnis, dass eine bestimmte Technologie oder ein bestimmtes Produkt (noch) nicht für den Einsatz in der eigenen Organisation geeignet ist. Das Ziel mag zu Projektbeginn noch vage sein oder sich im Projektverlauf stark verändern; gerade die erhebliche und mehrfache Änderung der Zielsetzung ist typisch für Projekte – im Gegensatz zu Prozessen, deren Zielsetzung durch die Prozessdefinition vorgegeben ist.

Das Projektziel muss im Umfang, in seinen Merkmalen und deren Ausprägungen spezifiziert sein oder im Verlauf des Projektes spezifiziert werden. Die Erarbeitung des Projektziels erfordert einen erheblichen Aufwand und ist eine der wichtigsten Aufgaben des Projektmanagements.

Das Projektcontrolling muss sicherstellen, dass der Zielerreichungsgrad des Projektes kontinuierlich ermittelt werden kann, auch wenn sich die Zielsetzung des Projektes während der Projektdurchführung verändert.

Einmaligkeit

Projekte sind einmalig und werden nicht identisch wiederholt. Auch wenn sie gleiche Aufgabenstellungen behandeln, werden sie unter stets verschiedenen Rahmenbedingungen durchgeführt und weisen so die in der DIN 69901 genannte Einmaligkeit hinsichtlich der Gesamtheit ihrer Bedingungen auf. Damit stellen sie die einbezogenen Mitarbeiter immer wieder vor Herausforderungen, die man mit Routine und Erfahrung zwar besser meistern kann als ohne, aber in jedem Projekt verlaufen die Dinge anders als erwartet oder geplant und es gibt positive oder negative Überraschungen.

Auch bei Prozessen, insbesondere bei Serviceprozessen, gibt es erhebliche Schwankungen, aber diese Schwankungen spielen sich in einem durch die Prozessdefinition vorgegebenen Rahmen ab. Der Prozess kann nur das leisten, was im Rahmen seiner Definition angedacht ist. Ein Prozess ist stets Routine – für alle Beteiligten.

Singuläre Aufgabenstellung

Die Einmaligkeit eines Projektes wird klarer, wenn man sie vor dem Hintergrund zweier grundlegender Rollen diskutiert, der Rolle des Projektauftraggebers, der das Projektergebnis nutzen will, und der Rolle des Projektauftragnehmers, der das Projektergebnis liefern soll (vgl. Kap. 3). Beispiele von Projektergebnissen aus dem IT-Umfeld sind neue oder erweiterte Anwendungssysteme, der Aufbau eines neuen Rechenzentrums, modernisierte Arbeitsplatzsysteme oder der Betrieb eines Netzwerkes durch einen externen Dienstleister. Vor allem aus der Sicht des Auftraggebers ist das Projekt einmalig. Denn er will (oder muss) mithilfe des Projektes eine singuläre, nicht alltägliche Aufgabe bewältigen. Für den Auftragnehmer mag das Projekt einen gewissen Routinecharakter haben, für den Auftraggeber ist es in der Regel eine Ausnahmesituation.

Für das Projektcontrolling stellt die Einmaligkeit der Projekte eine erhebliche Herausforderung dar, denn sie erschwert die Vergleichbarkeit zwischen unterschiedlichen Projekten und erfordert die spezifische Anpassung der Steuerungsverfahren und -werkzeuge an jedes einzelne Projekt.

Organisationsveränderungen

Die meisten Projekte schaffen ein Ergebnis, das es in der Auftraggeberorganisation zuvor noch nicht gibt – sonst müsste man dieses Projekt nicht durchführen. Das Projektergebnis verändert die Organisation des Projektauftraggebers, und zwar nachhaltig und signifikant.

Prozesse hingegen spielen sich in einem stabilen Umfeld ab. Sie bewahren einen eingeschwungenen Zustand oder wollen ihn wiederherstellen. Und eine kontinuierliche Prozessverbesserung erfolgt aus dem laufenden Prozess heraus.

Beantwortung von Fragen

Andere Projekte beantworten Fragen, die für die Organisation von erheblicher Bedeutung sind. Das Ergebnis dieser Projekte ist die Antwort auf die gestellte Frage; sie führt zu Entscheidungen und beeinflusst so die zukünftige Entwicklung der Organisation nachhaltig.

Projektfolgen

Das Projektcontrolling hat die Aufgabe, die Projektfolgen über das Projektende hinaus zu evaluieren und festzustellen, ob der durch das Projektergebnis entstehende Nutzen und die aus dem Projekt heraus ggf. entstehenden Folgekosten den Erwartungen entsprechen, die der Projektauftraggeber vor Projektbeginn dokumentiert hatte.

Größe und Komplexität

Projekte weisen – relativ zur Organisation des Auftraggebers – eine bestimmte Größe und Komplexität auf. Der Projektauftraggeber kann diese Aufgabe nicht im Rahmen seiner normalen Abläufe und nicht mit seinen vorhandenen Ressourcen realisieren (das mag beim Projektauftragnehmer anders aussehen). Die Projektorganisation steht dementsprechend neben der Linienorganisation des Auftraggebers. Für die Organisation des Projektauftraggebers stellt das Projekt eine unter Umständen erhebliche (zusätzliche) Belastung dar – nicht nur finanziell, sondern auch durch die Beanspruchung von realen Ressourcen, insbesondere von Mitarbeitern, die sich aus den Mitwirkungspflichten des Projektauftraggebers ergeben.

Für das Projektcontrolling besteht in diesem Bereich die große Herausforderung, die für das Projektmanagement notwendige Transparenz bezüglich des Projektzustandes und des Projektfortschrittes herzustellen und aufrechtzuerhalten und so die Beherrschbarkeit des Projektes sicherzustellen.

Interdisziplinarität

Projekte erfordern die Zusammenarbeit unterschiedlicher Menschen, Kompetenzen, Ressourcen, Instanzen. Dass die angestrebten Ergebnisse nicht von der Auftraggeberorganisation alleine erreicht werden können, liegt daran, dass diese nicht die Kapazitäten und auch Kompetenzen hat, die erforderlich sind. Die Durchführung von Projekten stellt daher für alle Beteiligten eine erhebliche Herausforderung und sogar Belastung dar.

Interdisziplinäre Zusammenarbeit findet sich auch in Prozessen. Allerdings ist sie hier geregelt und für die Beteiligten Routine.

Eine wesentliche Aufgabenstellung für das Projektcontrolling besteht darin, zwischen allen am Projekt Beteiligten und vom Projekt Betroffenen die erforderliche Kommunikation zu sichern.

Zeitlicher Rahmen

Das Projektergebnis soll zu einem bestimmten Zeitpunkt verfügbar sein. Der Projektauftraggeber fordert also die Realisierung des Projektergebnisses in einem beschränkten zeitlichen Rahmen.

Auch Prozesse unterliegen zeitlichen Beschränkungen: Sie dürfen nicht beliebig lange laufen und müssen Termine einhalten. Die zeitliche Befristung ist also eine Restriktion, der sowohl Projekte als auch Prozesse unterworfen sind.

Gleichwohl ist die Unterstützung der Terminsteuerung eines Projektes eine der wichtigsten Aufgaben des Projektcontrollings. Je früher ein Projektergebnis zur Verfügung steht, desto eher kann es den erwarteten Nutzen generieren.

Begrenzte Ressourcen

Die Durchführung eines Projektes erfordert Ressourcen, z.B. geeignete Mitarbeiter, technische Komponenten, Software oder Räumlichkeiten. Der Projektauftraggeber muss diese Ressourcen bereitstellen und bezahlen. Das Projekt soll zudem das angestrebte Ergebnis »wirtschaftlich« erstellen. Der Projektauftraggeber wird also nicht bereit bzw. nicht in der Lage sein, über eine bestimmte Grenze hinaus Mittel für ein Projekt zur Verfügung zu stellen.

Außerdem kann der Fall eintreten, dass notwendige Ressourcen dann nicht verfügbar sind, wenn man sie im Projekt eigentlich benötigen würde, z.B. Mitarbeiter oder externe Experten mit einer bestimmten Qualifikation.

Die Einmaligkeit von Projekten zeigt sich auch in der spezifischen Kombination der benötigten und nur beschränkt verfügbaren Ressourcen. Das Projektcontrolling hat die elementare Aufgabe, den Einsatz der Ressourcen und der finanziellen Mittel im Projekt zu steuern.

Projektorganisation

Da das Projektergebnis nicht von der Regelorganisation des Auftraggebers erstellt werden kann, muss es außerhalb dieser Regelorganisation geschaffen werden, und dazu bedarf es einer spezifischen Projektorganisation. Diese entsteht mit der Initiierung des Projektes und löst sich zum Abschluss des Projektes wieder auf. Dann müssen die vom Auftraggeber in das Projekt gegebenen Ressourcen wieder in die Regelorganisation zurückgeführt werden. Auch müssen die vom Auftragnehmer beigestellten und jetzt wieder freien Ressourcen auf einen neuen Einsatz vorbereitet werden.

Projektorganisation und Linienorganisation

Die Projektorganisation steht neben der Linienorganisation und oftmals im Konflikt zu ihr. Das Spannungsverhältnis ergibt sich einerseits aus Ressourcenkonflikten, denn die in das Projekt eingebundenen Ressourcen des Auftraggebers stehen der Linienorganisation vorübergehend nicht (mehr) zur Verfügung. Andererseits betrachten Führungskräfte und Mitarbeiter der Linienorganisation das Projekt kritisch, da es für sie oftmals zu erheblichen Veränderungen führt.

Das Projektcontrolling muss das Projektmanagement bei Aufbau und Erhalt einer aufgabengerechten Organisation des Projektes unterstützen. Für jede Aufgabe im Projekt müssen Verantwortliche benannt werden.

Risiken

Die Einmaligkeit und Neuartigkeit von Projekten bringen es mit sich, dass ihre Entwicklung nicht sicher vorhergesagt werden kann. Es besteht die Gefahr, dass das Projektergebnis nicht bzw. nicht in der aktuellen Konstellation aller Bedingungen realisiert werden kann.

Projekte können sogar gestoppt oder abgebrochen werden. Die Gründe dafür können im Projekt selbst liegen, z.B., weil das angestrebte Projektziel technisch nicht realisierbar ist. Sie können aber auch aus dem Projektumfeld kommen, z.B. weil die Organisation des Projektauftraggebers das Ergebnis nicht mehr benötigt.

Risiken ergeben sich auch aus Größe und Komplexität der Aufgabe. Je größer oder komplexer Projekte sind, desto größer ist die Wahrscheinlichkeit, dass sie das geplante Ziel gar nicht oder nur unvollständig bzw. gegenüber der ursprünglichen Planung ein abweichendes Ziel erreichen. Das Projektcontrolling muss das Projektmanagement bei der Steuerung von Risiken unterstützen.

Vor dem Hintergrund dieser Projektcharakteristika ergibt sich die folgende Definition für Projekte:

Projekt

Ein Projekt ist eine strukturierte Abfolge von Aktivitäten, die von einer Organisation (dem Projektauftragnehmer) im Auftrage einer zweiten Organisation (des Projektauftraggebers) durchgeführt werden, um unter verschiedenen Randbedingungen, Einschränkungen oder Engpässen (insbesondere zeitlicher oder finanzieller Natur) eine Aufgaben- oder Fragestellung so zu bearbeiten, dass das aus dem Projekt entstehende Ergebnis für den Projektauftraggeber von Bedeutung ist und seinen Erwartungen entspricht.

Die Aufgabenstellung ist mindestens für den Projektauftraggeber einmalig. Ihre Durchführung muss spezifisch geplant werden und diese Planung muss in der Regel während des Projektverlaufs wiederholt angepasst und geändert werden. Es besteht ein erhebliches Ergebnis- oder Durchführungsrisiko.

Ergebniskategorien

Im Hinblick auf die Entscheidung, ob ein Projekt durchgeführt werden soll oder nicht, unterscheidet man zwischen

Projekten, deren Nutzen erst durch den nachfolgenden betrieblichen Einsatz des Projektergebnisses realisiert werden kann (Projekte mit Betriebsphase), und

Projekten, deren Nutzen bereits mit Vorlage des Projektergebnisses eintritt (Projekte ohne Betriebsphase).

Projekte mit Betriebsphase

Die erste Kategorie umfasst solche Projekte, die man gewöhnlich, wenn man über Projekte spricht, stillschweigend meint. Hier ist das erwartete oder zu erstellende Ergebnis (relativ) klar. Der Projektauftrag hat also etwa die Form: Realisiere ein System X mit den Eigenschaften a, b, c, … Der Nutzen des Projektes für die Organisation des Projektauftraggebers entsteht durch Einsatz des Projektergebnisses in der anschließenden Betriebsphase.

Projekte ohne Betriebsphase

Bei der zweiten Kategorie stellt sich die Sachlage anders dar. Hier ist zwar die Fragestellung klar, aber es ist nicht sicher, welches Ergebnis das Projekt liefern wird, wie also die Antwort auf die gestellte Frage lauten wird. Solche Projekte sind in der IT durchaus üblich. Man denke etwa an folgende Fragestellungen:

Ist es sinnvoll, in unserer Organisation das neue Betriebssystem X einzusetzen?

Welche Möglichkeiten gibt es, um die Leistungsfähigkeit unserer Organisation zu verbessern?

Zweifelsohne werden solche Fragestellungen in Projekten bearbeitet. Der Nutzen wird mit Ende des Projektes realisiert, weil eine offene Frage beantwortet worden ist. Schwierig ist es jedoch – im Verhältnis zu Zeit und Aufwand – den Nutzen der Antwort zu bewerten. Einen Wert hat die Beantwortung solcher Fragen allemal, aber wie groß dieser Wert für die Organisation ist, lässt sich objektiv kaum messen. Insofern stellen Projekte dieses Typs bei der Nutzenbewertung eine besondere Herausforderung für das Projektcontrolling dar (vgl. Abschnitt 4.3.7 und 5.1).

Projekt und Prozess

Eine Grenzziehung zwischen Projekten und Prozessen ist nicht immer einfach. Zwar laufen Prozesse in der Regelorganisation ab und Projekte werden in spezifischen, neben dieser Regelorganisation stehenden Projektorganisationen durchgeführt, aber ebenso wie Projekte sind auch Prozesse komplex, arbeiten interdisziplinär und unterliegen verschiedenen ressourcenbezogenen Begrenzungen sowie unterschiedlichen Risiken.

Planung und Ausführung

Worin besteht dann der Unterschied zwischen Projekten und Prozessen, wenn doch offenbar die Grenzen fließend sind? Nun, vielleicht am ehesten durch die Trennung von Planung und Ausführung. Ein Prozess wird einmal und unabhängig von einer konkreten Durchführung geplant und dann immer wieder im Rahmen der vorgedachten Pfade ausgeführt. Bei einem Projekt wird vor der Durchführung mindestens eine Planung durchgeführt und im laufenden Projekt wird mehrfach nachgeplant und umgeplant. Überspitzt könnte man sagen:

Steuerungssystem

Projekte zeichnen sich nicht nur durch eine aufwendige Planung aus, sondern benötigen darüber hinaus neben der zur jeweiligen Projektaufgabe passenden Organisation ein spezifisches Steuerungssystem. Bei Prozessen hingegen gibt es Steuerungssysteme, die unabhängig von der konkreten Prozessdurchführung sind.

Kennzahlen

Die Individualität eines Projektes lässt sich an seinen spezifischen Kennzahlen beobachten. Projektkennzahlen fokussieren auf das spezifische Projekt. Bei Prozessen hingegen interessiert weniger die einzelne Durchführung, sondern eher die Summe aller Durchführungen. Bei einem Projekt will man die Einhaltung oder Nichteinhaltung jedes einzelnen Termins wissen, bei Prozessen fragt man eher statistisch nach der »durchschnittlichen« Termineinhaltung. Bei Projekten fragt man nach dem spezifischen Ressourcenverbrauch, bei Prozessen nach dem gesamten Ressourcenverbrauch bzw. der Ausnutzung bereitgestellter Kapazität. Natürlich ist das eine unscharfe Abgrenzung, aber sie zeigt charakteristische Unterschiede.

Managementmethode

Im Zweifelsfalle ist das ein Projekt, was eine Organisation zum Projekt erklärt und was sie mit den Methoden des Projektmanagements steuert. So werden in der Praxis auch Routinetätigkeiten als Projekt geführt – man denke an die sogenannten Wartungsprojekte. Dabei handelt es sich eigentlich nicht um Projekte, denn es werden keine neuen Ergebnisse erstellt. Es sind aber auch keine Prozesse, da die klare vorgedachte Ablaufstruktur fehlt. Eher handelt es sich um reservierte Kapazitäten, die nach Bedarf abgerufen werden. Dass man solche Aktivitäten als Projekt deklariert, hat seine Ursache darin, dass die benötigten Ressourcen, z.B. Entwicklerkapazitäten, parallel auch für »echte« Projekte benötigt werden. Es bestehen also Konflikte beim Ressourceneinsatz und man möchte den Ressourcenverbrauch – wie bei einem Projekt – gezielt verfolgen.

Kleinprojekte

Andererseits werden in vielen Organisationen projektartige Aufgabenstellungen erst dann als Projekt etabliert, wenn der Aufwand eine gewisse Wertgrenze überschreitet. Dann muss die Realisierung der jeweiligen Aufgabe auf Grundlage einer (eventuell vereinfachten) Rentabilitätsbetrachtung (vgl. Abschnitt 4.3) entschieden werden. Liegt der erwartete Aufwand für die vorliegende Aufgabenstellung unter der vorgegebenen Wertgrenze, dann wird die Aufgabe durchgeführt, wenn der Auftraggeber (in der Regel der initiierende Fachbereich) bereit ist, den entstehenden Aufwand zu bezahlen (im Falle einer IT-Leistungsverrechnung) oder einer für ihn reservierten Kapazität an IT-Ressourcen zu entnehmen, und wenn dann die benötigten Ressourcen auch verfügbar sind.

Für das Projektcontrolling sind solche Kleinprojekte unter folgenden Aspekten von Interesse:

Eine förmliche Durchführungsentscheidung mittels (vereinfachter) Rentabilitätsbetrachtung muss erfolgen.

Ein hohes oder zunehmendes Volumen von Kleinprojekten bindet IT-Ressourcen, insbesondere Mitarbeiter, verknappt diese für die Durchführung »normaler« Projekte und muss daher über geeignete Auswahl- und Priorisierungsverfahren in das Portfoliocontrolling eingebunden werden.

Kleinprojekte sind in sich kaum oder nur in geringem Umfang strukturiert. Die Steuerung der Durchführung kann den jeweils Verantwortlichen vollständig überlassen werden und erfordert im Gegensatz zu »normalen« Projekten keine spezifischen, vorgegebenen Regelungen.

2.2 Projektportfolio

Gesamtheit von Projekten

In jeder Organisation werden in einer Planungsperiode (in der Regel ein Geschäftsjahr) mehrere Projekte durchgeführt. Neben den Einzelprojekten muss man dann auch die Gesamtheit dieser Projekte betrachten und übergreifend steuern. Warum?

Fachliche Abhängigkeiten

Viele Projekte benötigen die Ergebnisse anderer Projekte, damit sie durchgeführt werden können. Die sich daraus ergebenden Projektketten oder Projektnetze können auf der Zeitachse nur in der Reihenfolge dieser Abhängigkeiten durchgeführt werden, die beteiligten Projekte können also nicht in beliebiger Reihenfolge und nicht zu beliebigen Zeitpunkten durchgeführt werden.

Projektnetz

Solche Projektketten oder Projektnetze entstehen z.B. daraus, dass ein insgesamt zu komplexes und damit riskantes und ressourcenbindendes Projekt in mehrere kleinere Projekte untergliedert wird. So wird man z.B. den Aufbau eines unternehmensweiten Data Warehouse in ein Projekt zum Aufbau des zentralen Datenspeichers, mehrere Projekte zur Anbindung verschiedener operativer und datenliefernder Systeme und mehrere Projekte zum Aufbau unterschiedlicher Data Marts (vgl. [Grob/Reepmeyer/Bensberg 2004, S. 351-357]) unterteilen. Oder es kann zu einem vorhandenen Anwendungssystem verschiedene Änderungs- und Erweiterungsanforderungen geben, die aus technischen oder betriebswirtschaftlichen Gründen in einer bestimmten Reihenfolge abgewickelt werden müssen, insgesamt aber so umfangreich sind, dass die Zusammenfassung in einem Einzelprojekt nicht mehr sinnvoll ist.

Projektprogramm

Einen Sonderfall der Projektnetze stellen Projektprogramme dar. Auch hier tragen die Ergebnisse der Einzelprojekte zu einem übergeordneten Ziel bei und zwischen den Projekten des Programms bestehen verschiedene Abhängigkeiten. Jedoch greifen die Projekte auf unterschiedliche Ressourcen der übergeordneten Organisation zu (vgl. [Brabandt 2000]). Ein Beispiel eines Projektprogramms ist die Integration eines aufgekauften Unternehmens, die unterschiedlichste Projekte erfordert. Darunter gibt es IT-Projekte, aber auch verschiedene Nicht-IT-Projekte.

Superprojekt

Da die termingerechte Bereitstellung von Projektergebnissen von erheblicher wirtschaftlicher Bedeutung ist, müssen Projektnetze in ihrer Gesamtheit als übergreifendes Superprojekt betrachtet werden. Das gilt einerseits für die Durchführungsentscheidung, die natürlich über die Gesamtaufgabe zu erfolgen hat, und andererseits für die eigentliche Durchführung, die die Vorgänger-Nachfolger-Beziehungen im jeweiligen Projektnetz beachten muss.

Ressourcenbelegung

Auch inhaltlich unabhängige Projekte sind nicht so unabhängig voneinander, wie es auf den ersten Blick erscheint. Denn üblicherweise nutzen die verschiedenen Projekte dieselben Ressourcen: Mitarbeiter, Werkzeuge, technische Infrastrukturen, Räumlichkeiten usw. Die Kapazitäten dieser Ressourcen sind beschränkt. Also müssen Projekte auf der Zeitachse so geplant werden, dass die verfügbaren Ressourcen optimal (was immer das im Einzelnen bedeutet) auf die Projekte verteilt werden.

Dominoeffekte

Wird dann von laufenden Projekten eine Ressource länger benötigt als geplant, steht diese Ressource für das »nächste« Projekt nicht termingerecht zur Verfügung. Da dieses Projekt auf die Ressource warten muss, verspätet es sich daher und greift dann seinerseits verspätet auf andere Ressourcen zu, die den wiederum zeitlich nachfolgenden Projekten dann ebenfalls nicht termingerecht zur Verfügung stehen. Aus der gemeinsamen Nutzung von Ressourcen durch unterschiedliche Projekte ergeben sich also Dominoeffekte, sodass sich (im schlimmsten Fall) durch die verspätete Freigabe einer Ressource in einem einzigen Projekt Probleme für sämtliche nachfolgende Projekte ergeben können. Diese nicht fachlichen Abhängigkeiten können in der Praxis von größerer Bedeutung für das Projektcontrolling sein als die fachlichen Abhängigkeiten in Projektnetzen.

Portfoliomanagement

Die genannten Gründe führen dazu, dass das Projektcontrolling auch die Gesamtheit aller Projekte im Auge behalten muss. Die Gesamtheit aller Projekte, die gemeinsame Ressourcen nutzen müssen, bezeichnet man als Projektportfolio. Geht es um die Frage, welche Projekte durchgeführt werden sollen, so spricht man von Portfoliomanagement bzw. Portfoliosteuerung.

Multiprojektmanagement

Betrachtet man die bereits laufenden Projekte, so ist der Begriff Multiprojektmanagement bzw. Multiprojektsteuerung üblich.

Die unterschiedlichen Begriffe legen den Schluss nahe, man könne Planung und Durchführung von Projektgesamtheiten getrennt betrachten. Dieser Schluss ist falsch! Denn die Projektwelt ist nicht statisch – im Gegenteil. Das Portfolio verändert sich dynamisch, weil neue Projekte hinzukommen, bereits geplante Projekte wieder aus dem Portfolio genommen werden und abgeschlossene Projekte aus dem Portfolio herausfallen. Auch können Projekte aufgrund von Entwicklungen im Umfeld anders priorisiert werden und dadurch zu Umplanungen des Projektportfolios führen.

Portfoliosteuerung

Auch Veränderungen in den bereits laufenden Projekten haben Rückwirkungen bis in das Portfolio hinein. Man denke etwa an Verzögerungen, Änderungen der Projektaufgabe oder Projektabbrüche. All das führt zu Umplanungen im Portfolio. Insofern muss man die geplanten, aber noch nicht gestarteten Projekte und die bereits laufenden Projekte unter dem Aspekt der Steuerung als Einheit betrachten. Daher wird im Folgenden ausschließlich von Portfoliosteuerung gesprochen. Vor diesem Hintergrund wird das Projektportfolio wie folgt definiert:

Projektportfolio

Ein Projektportfolio ist eine Gruppe von Projekten, die innerhalb eines bestimmten Zeitraums durchzuführen sind und zwischen denen fachliche Abhängigkeiten oder Abhängigkeiten durch gemeinsame Ressourcennutzung bestehen. Diese Projektgruppe muss einer übergreifenden Planung und Steuerung unterworfen werden.

Natürlich kann es fachliche Abhängigkeiten auch zu Projekten außerhalb des Portfolios geben und die gemeinsam genutzten Ressourcen werden vom Portfolio möglicherweise nicht exklusiv genutzt. In einer Organisation können gleichzeitig auch mehrere Portfolios vorhanden sein, z.B. eigene Projektportfolios für spezifische Projektauftraggeber (Fachbereiche) oder für unterschiedliche Projektgrößen (etwa: Großprojekte, normale Projekte, Kleinprojekte).

2.3 Fragen des Controllings

Hinsichtlich der IT-Projekte und IT-Projektportfolios einer Organisation muss das IT-Controlling folgende Fragen stellen und mittels entsprechender Antworten Transparenz schaffen:

Ist klar definiert, was ein Projekt ist und was nicht?

Sind die Kriterien klar definiert, nach denen eine Aufgabenstellung als Projekt zu behandeln ist?

Ist für jedes Projekt bestimmt, ob es sich um ein Projekt mit Betriebsphase oder ein Projekt ohne Betriebsphase handelt?

Ist klar definiert, welche Projektportfolios geführt werden (sollen)?

Sind diese Definitionen und Regeln dokumentiert und allen Verantwortlichen bekannt? Werden sie von allen Betroffenen verstanden und akzeptiert?

Ist für jedes Projekt festgelegt, welchem Portfolio es zugeordnet ist? Ist umgekehrt bekannt und dokumentiert, welche Projekte zu einem bestimmten Portfolio gehören?

2.4 Empfehlungen für die Praxis

Legen Sie für Ihre Organisation klar und verbindlich fest, welche Aufgaben in Form von Projekten durchzuführen sind und welche Aufgaben im Rahmen der Regelorganisation (Prozessorganisation) bearbeitet werden müssen.

Mögliche Kriterien, die zur Definition eines Projektes führen, sind:

• Die Aufgabe erfordert die Mitwirkung von Personen aus unterschiedlichen Teilorganisationen (Unternehmensbereiche, Abteilungen usw.).

• Die Aufgabe führt zu wesentlichen und längerfristigen Veränderungen in der Regelorganisation.

• Die Aufgabenstellung hat innovativen Charakter, benötigt außergewöhnlich viel Kapital und bindet das eingesetzte Kapital längerfristig.

• Die Bewältigung der Aufgabe erfordert Wissen, Kompetenzen oder Qualifikationen, die in der Organisation nicht vorhanden sind.

• Die Bearbeitung der Aufgabe erfordert einen Ressourceneinsatz, der eine bestimmte (vorgegebene) Grenze überschreitet bzw. von der Regelorganisation nicht (mehr) geleistet werden kann.

Legen Sie insbesondere für das IT-Change-Management und das Anforderungsmanagement (Requirements Management) fest, welche Änderungen bzw. welche Anforderungen bei ihrer Umsetzung als Projekte zu behandeln sind.

Legen Sie für Ihre Projekte Größenklassen fest und definieren Sie zu jeder Größenklasse spezifische Anforderungen an Projektmanagement und Projektcontrolling. Sinnvoll sind zwei oder drei Größenklassen (Kleinprojekte/Projekte bzw. Kleinprojekte/Projekte/Großprojekte). Orientieren Sie sich bei der Definition der Größenklassen am erforderlichen Personalaufwand zur Durchführung der Projekte.

Stellen Sie für jedes Projekt sicher, welchem Portfolio es zugeordnet ist, falls Sie in Ihrer Organisation mehrere Projektportfolios führen.

3 Projektorganisation

Spezifische Organisation

Projekte müssen Aufgaben lösen, die von der Linienorganisation des Auftraggebers (Regelorganisation) nicht bewältigt werden können. Dazu wird für die Dauer des Projektes eine spezifische Organisation »neben der Linie« aufgebaut, die mit Abschluss des Projektes wieder aufgelöst wird. Auch die Steuerung eines Projektportfolios benötigt geeignete organisatorische Strukturen (vgl. [de Rooij 2008]); diese existieren im Gegensatz zur Organisation eines Projektes dauerhaft.

Projektrollen

Damit Projektorganisation und Portfolioorganisation erfolgreich arbeiten können, muss es Rollen und spezifische »Spielregeln« geben. Diese Regeln müssen von allen Beteiligten eingehalten werden.

Organisationsfelder

Wir unterscheiden erstens das Projektumfeld, das das Projekt auslöst, zum Projektabschluss die erarbeiteten Ergebnisse übernimmt und in der nachfolgenden Betriebsphase dafür verantwortlich ist, den erwarteten Nutzen des Projektes zu realisieren, zweitens die eigentliche Projektorganisation, die das Projekt durchführt, und drittens die Projektportfolioorganisation, die übergreifend die gesamte Projektarbeit koordiniert.

In Unternehmen oder der öffentlichen Verwaltung, die IT zur Unterstützung ihrer Geschäftsprozesse einsetzen, wird das Projektumfeld in der Regel durch die verschiedenen Fachbereiche repräsentiert. Die Projektorganisation, obgleich sie stets projektspezifisch aufgebaut wird, ist in vielen Fällen sehr eng mit dem IT-Bereich der Organisation assoziiert und die Portfolioorganisation für IT-Projekte findet man meistens ebenfalls in dem jeweiligen IT-Bereich.

Rollen im Projektumfeld

Die wichtigsten Rollen im Projektumfeld (vgl. Abb. 3–1) sind:

Projektauftraggeber

Projektauftragnehmer

Projektinvestor

Der Projektauftraggeber initiiert das Projekt. Er lässt sich vom (potenziellen) Projektauftragnehmer ein Angebot erstellen, beantragt das Projekt beim Projektinvestor, um die erforderlichen finanziellen Mittel für das Projekt zu erhalten, und erteilt im Falle der Genehmigung dem Projektauftragnehmer den Projektauftrag.

Der Projektauftraggeber wird in der Regel durch die Leitung desjenigen Fachbereiches repräsentiert, der mit dem Projektergebnis die eigene Teilorganisation oder die eigenen Prozesse verbessern möchte. In Organisationen mit eigenem IT-Bereich wird dessen Leitung den Projektauftragnehmer für IT-Projekte darstellen. Und schließlich wird der Projektinvestor in einem solchen Szenario durch die oberste Leitung der Organisation (Vorstand, Geschäftsführung, Behördenleitung usw.) oder einen von ihr benannten Vertreter repräsentiert.

Für IT-interne Projekte, z.B. die Modernisierung des Rechenzentrums, ist der IT-Bereich sowohl Projektauftraggeber als auch Projektauftragnehmer. Daraus ergibt sich ein Rollenkonflikt, den der Projektinvestor ggf. durch geeignete Kontrollmechanismen auffängt. Für übergreifende Aufgabenstellungen, z.B. die Einführung unternehmensweiter Anwendungen, wird die oberste Leitung auch zum Projektauftraggeber. Das kollidiert mit ihrer Rolle als Projektinvestor und muss ebenfalls durch geeignete Abläufe unter Kontrolle gehalten werden.

Abb. 3–1 Rollen im Projektumfeld

Rollen in der Projektorganisation

Die wichtigsten Rollen in der Projektorganisation (vgl. Abb. 3–2) sind:

Projektleitung

Projektteam

Projektlenkung

Ist das Projekt beauftragt, so führt die Projektleitung das Projekt und das Projektteam. Die Mitglieder des Projektteams berichten an die Projektleitung. Diese wiederum berichtet über den Fortschritt des Projektes an die Projektlenkung und fordert im Bedarfsfall ihre Entscheidungen. Die Projektlenkung ist ein Gremium, das aus hochrangigen Vertretern aus den Organisationen des Projektauftraggebers und des Projektauftragnehmers sowie Vertretern des Projektinvestors gebildet wird. Sind externe Partner an dem Projekt beteiligt, so entsenden auch sie ggf. hochrangige Vertreter in die Projektlenkung. Die Projektlenkung kann projektspezifisch oder projektübergreifend gebildet werden. Mitglieder der Projektleitung können nicht zugleich Mitglieder der Projektlenkung sein.

Die Projektleitung wird in der Regel durch die Person des Projektleiters wahrgenommen; bei großen Projekten kann es auch ein Projektleiterteam geben. Die Projektleitung für IT-Projekte wird in der Praxis meistens durch entsprechend qualifizierte Mitglieder der Organisation des Projektauftragnehmers, also von Mitarbeitern des IT-Bereiches, übernommen. Das muss aber nicht so sein. Auch externe Projektleiter, die nicht Mitarbeiter der Organisation sind, findet man in etlichen IT-Projekten. Das Gremium der Projektlenkung wird meistens als Projektlenkungsausschuss (PLA) bezeichnet.

Abb. 3–2 Rollen in der Projektorganisation

Rollen in der Portfolioorganisation

Die wichtigsten Rollen in der Portfolioorganisation (vgl. Abb. 3–3) sind:

Portfoliomanagement

Projektausschuss

Abb. 3–3 Rollen in der Portfolioorganisation

Aufgrund der Nutzung gleicher Ressourcen sind alle Projekte einem Projektportfolio zugeordnet. Die Projektleitung muss mit dem Portfoliomanagement die Zuordnung der benötigten Ressourcen abstimmen. Das Portfoliomanagement schlägt aus den Projekten, die sich mittels Projektantrag für eine Realisierung qualifiziert haben, dem Projektausschuss die am besten geeigneten Projekte vor und berichtet ihm über den Status des Projektportfolios. Der Projektausschuss priorisiert die vorgeschlagenen Projekte und entscheidet über die Aufnahme in das Projektportfolio.

Das Portfoliomanagement ist dauerhaft etabliert und damit Bestandteil der Regelorganisation. Für IT-Projekte ist es meistens dem IT-Bereich zugeordnet. Es gibt jedoch Unternehmen und andere Organisationen, die das Portfoliomanagement übergreifend über die gesamte Organisation, z.B. in Form eines Project Management Office (PMO; vgl. [Sandrino-Arndt/Thomas/Becker 2010]), etablieren. Der Projektausschuss ist ein Gremium, das aus der obersten Leitung der Organisation gebildet wird oder unmittelbar von ihr eingesetzt wird und sich aus hochrangigen Führungskräften der Organisation zusammensetzt.

Rollenbesetzung im Projektumfeld

Das Projektumfeld bildet die Regelorganisation, aus der heraus die Projekte entstehen. Diese stellt auch die Mitarbeiter, die in der Projektorganisation die benannten Rollen übernehmen. Die Besetzung der Rollen im Projekt mit Vertretern des Projektumfeldes zeigt Tabelle 3–1.

Tab. 3–1 Rollenbesetzung in der Projektorganisation

Rollenbesetzung in der Projektorganisation

Auch die Portfolioorganisation wird mit Vertretern der Regelorganisation besetzt. Die Besetzung der Rollen zeigt Tabelle 3–2.

 

Projektausschuss

Portfoliomanagement

Projektinvestor

Vertreter der obersten Leitung der Gesamtorganisation

Üblicherweise nicht vertreten

Projektauftraggeber

(Ausgewählte) Vertreter der obersten Leitung der Auftraggeberorganisation

Üblicherweise nicht vertreten

Projektauftragnehmer

Vertreter der obersten Leitung der Auftragnehmerorganisation

Geeigneter Mitarbeiter derAuftragnehmerorganisation

Tab. 3–2 Rollenbesetzung in der Portfolioorganisation

3.1 Projektauftraggeber

Projektinitiierung

Der Projektauftraggeber ist der Initiator des Projektes. Er will in seinem Verantwortungsbereich aus dem Projektergebnis Nutzen ziehen und muss die für das Projekt erforderlichen Mittel beschaffen. Gegenüber dem Projektinvestor (repräsentiert durch die oberste Leitung der Organisation) muss er das Projekt verantworten!

Nutzenversprechen

Bei Initiierung des Projektes muss er begründen, warum dieses Projekt für die Organisation sinnvoll ist. Er muss den erforderlichen Projektaufwand rechtfertigen, die aus dem Projekt resultierenden Folgekosten erklären und insbesondere die durch das Projekt und sein Ergebnis entstehenden Nutzeffekte begründen. Auch muss er auf die Interdependenzen zwischen Projektaufwand, Folgekosten und zu realisierenden Nutzeffekte hinweisen, ggf. Durchführungsalternativen des Projektes aufzeigen und eine Empfehlung für die »beste« Projektalternative aussprechen. So könnte es z.B. sinnvoll sein, einen höheren Projektaufwand zu akzeptieren, da dies zu niedrigeren Folgekosten oder höheren Nutzeffekten führen kann. In Anwenderorganisationen ist der Projektauftraggeber üblicherweise der Leiter eines Fachbereiches. Bei internen Projekten des IT-Bereiches ist dies ein Verantwortlicher aus dem IT-Bereich; in den meisten Fällen wird es sich um den Leiter des IT-Bereiches handeln.

Nutzenevaluierung

Da man sich durch ein Projekt, das zu (erheblichem) Aufwand führt, Nutzen und Vorteile für die Organisation erhofft, muss der Projektauftraggeber nach Abschluss des Projektes den sich dann tatsächlich ergebenden Nutzen, insbesondere aber Abweichungen des tatsächlich eintretenden Nutzens gegenüber dem in der Projektinitiierung dokumentierten Nutzenversprechen, verantworten.

Projektaufgabe spezifizieren

Darüber hinaus hat der Auftraggeber grundlegende Aufgaben im Hinblick auf das eigentliche Projekt. Vor Beginn des Projektes muss er die Projektaufgabe spezifizieren, also beschreiben und kommunizieren, was er von dem Projektauftragnehmer erwartet. Das ist unter Umständen schwierig, weil nicht klar ist, was genau das Ergebnis sein wird. Die Zielfindung kann auch eine vom Projekt zu erbringende Leistung sein. In jedem Falle muss der Projektauftraggeber aktiv in der Zielfindung mitarbeiten.

Projektergebnis übernehmen

Mit Abschluss des Projektes muss der Auftraggeber das Projektergebnis übernehmen und den Projektauftragnehmer entlasten, also bestätigen, dass die Projektaufgabe gelöst ist und das Projekt beendet werden kann. Dann können die gebundenen Ressourcen freigegeben und in anderen Projekten eingesetzt werden.

Mitwirkungspflichten

Während des Projektes bestehen für den Projektauftraggeber umfangreiche Mitwirkungspflichten. Daher muss er Mitglied der Projektlenkung sein! Er muss den Projektauftragnehmer bei der Durchführung des Projektes aktiv unterstützen, dessen Fragen beantworten und insbesondere bei der Qualitätssicherung der Projektergebnisse mitwirken.

Bereitstellung von Ressourcen

Nicht zuletzt muss der Auftraggeber aus seiner Organisation personelle Ressourcen für das Projekt bereitstellen, also Mitarbeiter, die entsprechendes Fachwissen in das Projekt einbringen. Die Bereitstellung der erforderlichen Kapazität und Expertise aus der Auftraggeberorganisation ist wesentlicher Erfolgsfaktor für Projekte. Geschieht sie nicht oder nur unzureichend, so ist der Projekterfolg gefährdet – Defizite im Projektergebnis, in der Termin- und der Budgeteinhaltung sind die üblichen Folgen.

3.2 Projektauftragnehmer

Lösungsvorschläge

Der Projektauftragnehmer, in der Regel vertreten durch die Leitung des IT-Bereiches der Organisation, möglicherweise aber auch durch eine externe Organisation (z.B. IT-Dienstleister, Beratungsunternehmen) unterbreitet dem Projektauftraggeber im Rahmen der Initiierung des Projektes geeignete Lösungsvorschläge und kalkuliert die erforderlichen realen und finanziellen Aufwände. In dieser Phase wird der Projektauftragnehmer durch einen speziellen Beauftragten oder den zukünftigen Projektleiter vertreten.

Verantwortung

Der Projektauftragnehmer hat in der Phase der Projektinitiierung eine große Verantwortung. Er ist fachkundiger Berater des Projektauftraggebers und muss Alternativen im Hinblick auf die zu lösende Aufgabenstellung erkennen, bewerten und priorisieren können. Seine Pflicht ist es vor allem, sämtliche relevanten Lösungsalternativen zu erkennen und im Hinblick auf die Aufgabenstellung möglichst neutral, also sowohl im Sinne des Projektauftraggebers als auch im Sinne des Projektinvestors, zu bewerten.

Darüber hinaus werden Projektaufwand und IT-seitige Folgekosten wesentlich durch das Votum des Projektauftraggebers bestimmt. Hier trägt er die entscheidende (Mit-)Verantwortung für den Erfolg des Projektes. Projektauftraggeber und Projektinvestor müssen sich auf ihn verlassen können.

Als verantwortungsvoller Lösungsanbieter muss der Projektauftragnehmer seinem (potenziellen) Auftraggeber unter Umständen empfehlen, das eigentliche Vorhaben zunächst zurückzustellen und im Rahmen eines Vorprojektes die Aufgabenstellung und mögliche Lösungsansätze vertiefend zu untersuchen. Idealerweise sind Projektauftraggeber, also die Fachbereiche einer Organisation, und Projektauftragnehmer, also der IT-Bereich der Organisation, in einem dauerhaften Dialog und können solche Fragen klären, bevor die eigentliche Projektinitiierung beginnt. Am Anfang einer Projektinitiierung sollte also eine konkrete Projektidee stehen, die bereits intensiv geprüft, diskutiert und evaluiert wurde.

Projektleiter

Wird der Projektauftrag erteilt, dann setzt der Projektauftragnehmer einen Projektleiter ein, der die Verantwortung für das Projektergebnis übernimmt. Während des Projektes entsendet der Projektauftragnehmer einen Vertreter in die Projektlenkung.

Aufgaben in der Projektlenkung

Auf der Ebene der Projektlenkung müssen sich Projektauftraggeber und Projektauftragnehmer kontinuierlich austauschen. Gegenüber der Projektleitung sind sie nicht zur Passivität »verdammt«. Im Gegenteil, sie können und müssen ggf. als Projektlenkung gemeinsam und aktiv auf das Projekt und die Projektleitung einwirken.

Aufgaben in der Betriebsphase

Denkt man bei dem Projektauftragnehmer an den IT-Bereich der Organisation, so hat dieser Bereich nicht nur Projektaufgaben, sondern wird in der Regel auch das sich aus dem Projekt ergebende IT-System nachfolgend betreiben. Er ist also nicht nur Dienstleister in der Projektphase, sondern auch in der nachfolgenden Betriebsphase. Damit trägt er Verantwortung für die Evaluierung der Folgekosten, wenn auch nur für die IT-seitigen. Die Erfahrungen aus der Betriebsphase nach bereits abgeschlossenen Projekten muss er für die Initiierung und Planung neuer IT-Projekte nutzen.

3.3 Projektinvestor

Kapital bereitstellen

Der Projektinvestor wird durch einen Vertreter der obersten Leitung der Organisation repräsentiert. In der Regel handelt es sich um ein Mitglied des Vorstandes, der Geschäftsführung, der Behördenleitung usw. oder eine von ihr benannte hochrangige Führungskraft oder ein von ihr eingesetztes Gremium aus hochrangigen Führungskräften der Organisation (in Form eines IT-, Projekt- oder Investitionsausschusses). Der Projektinvestor muss das für das Projekt benötigte Kapital zur Verfügung stellen bzw. für den Einsatz in diesem Projekt freigeben. Unter dem Kapital sind hier einerseits diejenigen finanziellen Mittel zu verstehen, die man zur Durchführung des Projektes unmittelbar benötigt, z.B. für den Kauf von Hardware, Software oder die Bezahlung externer Berater, andererseits aber auch der finanzielle Gegenwert der Arbeitszeit von Mitarbeitern und Nutzung vorhandener Sachmittel, die im Projekt eingesetzt werden sollen, aber alternativ auch für andere Zwecke genutzt werden könnten.

Projektantrag

Das benötigte Kapital wird der Projektinvestor jedoch nur dann bereitstellen bzw. zum Projekteinsatz freigeben, wenn er umfassend über das Projekt informiert wird (in Form eines Projektantrages oder eines sogenannten »Business Case«) und er auf Basis dieser Informationen zu der Überzeugung gelangt, dass das Projekt zu einer für ihn interessanten Verzinsung (Rendite) des eingesetzten Kapitals führt.

Projekte auswählen

Da das verfügbare Kapital beschränkt ist, wird der Projektinvestor nicht alle Projekte finanzieren können, sondern nur die für ihn wichtigsten und rentabelsten Projekte.

Rentabilität

Als zentraler Maßstab für die Wichtigkeit oder Attraktivität eines IT-Projektes wird in diesem Buch die Rentabilität auf das im Projekt eingesetzte Kapital gewählt, denn die Projektbewertung erfolgt mit den Mitteln der Investitionsrechnung und diese stellt die aus einem Projekt heraus entstehenden Liquiditätsüberschüsse in Relation zum eingesetzten Kapital dar. Sie beantwortet also die Frage, ob ein Projekt schlussendlich, also im Verlauf der Betriebsphase, zu einer Vermögenszunahme der Organisation führt. Dass Rentabilität ein besserer und strengerer Maßstab zur Projektbewertung ist als die Wirtschaftlichkeit, der Quotient aus (finanziell bewertetem) Nutzen und Kosten, erkennt man schmerzlich anhand der Tatsache, dass wirtschaftliche Investitionen immer wieder nicht getätigt werden können, weil das dazu benötigte Kapital nicht verfügbar ist bzw. vom Projektinvestor nicht zur Verfügung gestellt wird.

Mindestrendite

Finden sich in der eigenen Organisation keine geeigneten Investitionsmöglichkeiten, wird die oberste Leitung das Kapital am externen Kapitalmarkt anlegen. Umgekehrt bedeutet das, dass eine Anlage des verfügbaren Kapitals in der eigenen Organisation zu einer Rendite führen muss, die mindestens der am Kapitalmarkt erzielbaren Rendite entsprechen muss.

Projekte begleiten

Während der Durchführung wird der Projektinvestor das Projekt über die Projektlenkung begleiten. Nach Projektabschluss wird er in der Betriebsphase die sich aus dem Projekt ergebenden Folgekosten und Nutzeffekte evaluieren lassen.

3.4 Projektlenkung

Projektlenkungsausschuss

Wird ein Projekt genehmigt, in das Portfolio aufgenommen und dann gestartet, dann wird es von der Projektlenkung begleitet. Dabei handelt es sich üblicherweise um ein Gremium (Projektlenkungsausschuss (PLA)), in dem Vertreter des Projektinvestors, des Projektauftraggebers und des Projektauftragnehmers vertreten sind (vgl. [Ruf/Fittkau 2008, S. 94-97]). Der Projektlenkungsausschuss ist Eskalationsinstanz, oberste Entscheidungsinstanz und Kontrollinstanz für ein Projekt. Werden im Projekt externe Dienstleister eingesetzt, so sind oftmals auch hochrangige Vertreter des externen Dienstleisters in der Projektlenkung vertreten – insbesondere dann, wenn sie die Hauptlast in der Projektdurchführung übernommen haben oder für wesentliche Teilergebnisse des Projektes verantwortlich sind.

Änderungen und Abbruch eines Projektes

Der Projektlenkungsausschuss entscheidet darüber, ob Änderungsanträge in das Projekt übernommen werden, vor allem aber darüber, ob das Projekt abgebrochen oder weitergeführt werden soll. Man kann den Lenkungsausschuss als diejenige Instanz charakterisieren, die das Recht oder Privileg des Projektabbruchs hat. Natürlich wird der Lenkungsausschuss nicht über jeden Änderungsantrag einzeln entscheiden. Da bei IT-Projekten stets von einer gewissen Dynamik und einem daraus resultierenden Änderungsvolumen auszugehen ist, wird man einem Projekt in der Regel ein bestimmtes Änderungsbudget zuordnen, für dessen Nutzung und Verwendung die Projektleitung verantwortlich ist. Der Lenkungsausschuss wird über einzelne Änderungsanträge nur dann beraten und entscheiden, wenn das (finanzielle) Volumen des Änderungsantrages eine bestimmte Größenordnung überschreitet. Ergänzend wird sich der Lenkungsausschuss von der Projektleitung regelmäßig über den Ausschöpfungsgrad des Änderungsbudgets berichten lassen.

Arbeitsweise der Projektlenkung

Der Lenkungsausschuss wird regelmäßig zu vorab festgelegten Terminen zusammentreten und sich von der Projektleitung über Stand und Fortschritt des Projektes berichten lassen. So nimmt er seine Kontrollaufgabe