reading

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.

Projektcontrolling in der IT

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 · heidi.heilmann@augustinum.net

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

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.

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.

Inhaltsübersicht

Inhaltsverzeichnis

1 Einleitung

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

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.

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).

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.

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:

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).

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.

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:

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.

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.

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.

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

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?

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.

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.

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.

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.

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.

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.

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.

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.

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:

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:

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?

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.

• 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

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.

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

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

A	Abkürzungsverzeichnis
B	Symbolverzeichnis
C	Literatur
	Stichwortverzeichnis

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