Projekt-Controlling

Projekt-Controlling

Was ist überhaupt ein Projekt? Nach DIN 69901 ist ein Projekt ein Vorhaben, auf das die folgenden Kriterien zutreffen:

1. Es ist einmalig, also kein ständig wiederkehrender Prozess, keine Routinetätigkeit.
2. Es birgt eine gewisse Komplexität (z.B. hoher Aufwand, bereichsübergreifend, mit Risiken behaftet).
3. Es hat eindeutige Zielvorgaben.

Da es in der Praxis firmenindividuelle Definitionen gibt, empfiehlt es sich, erst einmal zu klären, ob überhaupt ein Projekt vorliegt und wenn ja, welche Kategorie (Groß-, Mittel-, Kleinprojekte). Davon hängen dann ab die weiteren Parameter wie Projektorganisation, Reporting, Anzahl Meilensteine etc.

Eindeutige Zieldefinitionen sind wichtig!

Zeig´ mir, wie dein Projekt startet und ich sage dir, wie es endet. Im Unterschied zu Daueraufgaben ist ein Projekt irgendwann vorbei. Umso wichtiger ist es, beim Projektstart einen Punkt zu beschreiben, an dem die Aufgabe erledigt ist. Ein sauberer Projektabschluss kann nur unter der Voraussetzung eines richtig definierten Projektziels durchgeführt werden. Der (künftige) Projektleiter sollte mit dem Auftraggeber zunächst die inhaltlichen Ziele abstimmen. Von der inhaltlichen Ausgestaltung hängen dann die Parameter Termine und Kosten ab. Die Zieldefinition ist der Ausgangspunkt für die gesamte Projektplanung und schafft Sicherheit für alle Beteiligten: Der Auftraggeber weiß, was er bekommt, und der Projektleiter kennt seine Aktionsgrundlagen. Damit werden Missverständnisse beim Projektabschluss vermieden.

Man muss sich das vorstellen wie bei einer Wette. Der Auftraggeber sagt: Sie schaffen´s nicht! Der Projektleiter hält dagegen und muss später den Nachweis bringen, dass er es geschafft hat. Er sollte sich also gedanklich an das Projektende versetzen und die Situation beschreiben, wie sie dann sein sollte. Gerade hier gilt: Ziele dürfen nicht interpretierbar, sie müssen konkret messbar sein! Also nicht: Am 1.1. ist die Software XY eingeführt. Denn was heißt eingeführt? Ist sie auf dem Server eingespielt? Funktioniert sie fehlerfrei? Sind die User geschult?

Datei:ProjektcontrollingAbb1.JPG

Abbildung 1: Interdependenzen im Projektziel-Dreieck

Projektplanung

Projekte sind keine Serienarbeiten. Natürlich lassen sich einzelne Bauteile oder Arbeitspläne standardisieren. Aber insgesamt stellt jedes Projekt ein Abenteuer dar. Man arbeitet – zumindest teilweise – ins Ungewisse, das man nur grob umreißen kann. Gerade deshalb aber ist es wichtig, eine saubere Planung zu machen. In einem Bergbau-Unternehmen kam einmal der Spruch: Bei uns kann man nicht planen, vor der Hacke ist es dunkel! Die passende Antwort ist: Gerade dann, wenn es vor einem besonders dunkel ist, muss man sich überlegen, welcher Weg ans Ziel führt und was alles passieren könnte. Nicht dass man sich in der Dunkelheit verirrt und das Ziel verfehlt! Nur dort, wo alles regelmäßig läuft, braucht man keine Planung. Der Vergleich mit der Vergangenheit würde genügen.

Der erste Schritt ist, einen Projektstrukturplan aufzubauen, d.h. eine grafische Übersicht aller zum Erreichen des Projektziels notwendigen Tätigkeiten/Arbeitspakete. Der Projektstrukturplan kann objekt- oder prozessorientiert aufgebaut sein. Dabei ist zu beachten, dass für jedes Arbeitspaket genau ein Verantwortlicher definiert wird.

Abbildung 2: Projektstrukturplan – objektorientiert

Das Ziel des Projektstrukturplans ist es, möglichst alle Aktivitäten zu erfassen. Es wird aber noch keine Reihenfolge hergestellt. Die Unterteilung des Gesamtprojektes in Arbeitspakete hilft, die Komplexität zu reduzieren und Verdichtungsmöglichkeiten bei Terminen oder Kosten zu erkennen.

Auf Basis des Projektstrukturplans wird der Projektverlauf geplant. Dazu werden Meilensteine definiert. Meilensteine sind wichtige Ereignisse während des Projekts und markieren den Abschluss oder Beginn von wichtigen Projektschritten. Möglicherweise wird hier auch eine Entscheidung über den Abbruch oder den weiteren Verlauf eines Projektes gefällt.

Die Arbeitspakete aus dem Projektstrukturplan sind die Basis zur Aufwandsschätzung. Hier fließen ein der absolute Zeitbedarf (also wie lange es dauert, bis ein Paket bewältigt werden kann) und die Intensität in %, mit der ein Mitarbeiter diesen Aufwand erbringen kann (Urlaub, Schulungen, andere Tätigkeiten?).

Jede Schätzung basiert auf Annahmen und vor allem Erfahrungen. Deswegen ist es gerade im Projektgeschäft wichtig, eine Erfahrungssicherung zu betreiben. Folglich ist der Vorkalkulation eine Nachkalkulation gegenüber zu stellen. Dies nützt zwar (in der Regel) nichts mehr für den laufenden Auftrag, dient aber dem Lernprozess für künftige Auftragskalkulationen.

Nachdem die Arbeitspakete mit Dauer und Kosten versehen sind, gilt es aufzuzeigen, wie es mit der Dauer des Gesamtprojektes aussieht. Das geschieht mit Hilfe des Netzplans. In ihm werden die Arbeitspakete in eine sachlogische Reihenfolge gebracht (zuerst der Rohbau, dann das Dach). Hier zeigt sich, welche Tätigkeiten unabhängig voneinander (also zeitlich parallel) laufen können und welche ausschlaggebend sind für die Projektdauer („kritischer Pfad“). Das öffnet dem Projekt-Controller auch die Türe für Simulationsrechnungen („was wäre, wenn…“).

Besonders bei Großprojekten ist die Cashflow-Betrachtung wichtig. Aufbauend auf dem Netzplan wird der zeitliche Anfall der Auszahlungen geplant. Dies ist die Basis wiederum für die Verhandlungen mit dem Auftraggeber über projektbegleitende Anzahlungen. Ziel ist es, auftretende „Vorfinanzierungen“ zu erkennen und zu minimieren.

Letzter Schritt einer guten Projektplanung ist die Risikoanalyse. Wie bei Daueraufgaben auch sind Faktoren, die die Zielerreichung gefährden, zu identifizieren und zu bewerten hinsichtlich ihrer Eintrittswahrscheinlichkeit und ihrer potenziellen Schadenhöhe. Das muss Eingang finden in das Risiko-Management-System.

Projekt-Controlling-Formular

Ein gutes Reporting – das gilt auch für Projekte – muss ausgewogen sein in vier Perspektiven. Es gilt einerseits Vergangenheit und Zukunft, anderseits Zahlen und Text/Maßnahen zu integrieren. Wie das geht, zeigt die untenstehende Abbildung 3.

Abbildung 3: Projektstandsbericht im Formular „4 Fenster“

Im linken Teil ist die Analyse des Ist-Zustands zu sehen. Am schwierigsten ist sicherlich der Bearbeitungsstand oder Fertigstellungsgrad zu schätzen. Sicherlich wird man dafür auch die angefallenen Stunden als Anhaltspunkt nehmen. Aber es wäre falsch, einfach zu sagen, dass unser Projekt am 30.6. zu 40% fertig sein müsse, weil von 5000 vorkalkulierten Stunden inzwischen 2000 angefallen sind. Der Bearbeitungsstand ist nach dem Baufortschritt abzuschätzen. Das können nur die für die Arbeitspakete verantwortlichen Manager/Fachleute selber tun. Projekt-Controlling ist ein typischer Fall, der nur im Sinne des Self-Controlling zu lösen ist. Der Controller – und oft auch der Projektleiter – kann nicht prüfen, ob die gemachten Angaben stimmen. Aus dem Fertigstellungsgrad ergibt sich die Projekterwartungsrechnung, die ankündigt, wie viele Stunden noch nötig sein werden (need to complete).

Projekt-Controlling und IAS/IFRS

Projekt-Controlling hat in letzter Zeit auch durch die Internationalisierung der Rechnungslegung mehr Bedeutung bekommen. Das betrifft zum einen die Bilanzierung von Fertigungsaufträgen nach IAS 11. Unfertige Projekte – physische Güter gleichermaßen wie Dienstleistungen – sind nach der PoC-Methode („percentage of completion“) anzusetzen. Das heißt, der Gewinn (besser gesagt der Deckungsbeitrag) aus einem Projekt wird nicht erst am Ende realisiert, sondern es ist bereits am Bilanzstichtag eine Teilgewinnrealisierung nach dem Fertigstellungsgrad vorzunehmen. Dazu ist eine verlässliche Schätzung des Projektergebnisses nötig. Der Fertigstellungsgrad wird meist mit der Cost-to-Cost-Methode ermittelt (= Istkosten / voraussichtliche Gesamtkosten). Im Endergebnis führt das zu einem früheren, dafür aber weniger volatilen Gewinnausweis.

Der zweite Berührungspunkt des Projekt-Controllers mit der externen Rechnungslegung betrifft den Bilanzierung von Entwicklungskosten. Während nach HGB Entwicklungskosten sofort aufwandswirksam sind, gilt nach IAS 38 eine Ansatzpflicht, sofern gewisse Voraussetzungen gegeben sind. Dazu gehört der Nachweis der Art, wie der Vermögenswert einen voraussichtlichen künftigen wirtschaftlichen Nutzen erzielen wird. Der Controller muss also einen Businessplan erstellen. Zum anderen muss er dafür sorgen, dass im Rahmen seines ProjektControlling-Systems die Entwicklungskosten von den nicht aktivierungsfähigen Forschungskosten separiert (Meilenstein!) und natürlich zuverlässig ermittelt werden können. Das Kontierungselement, das der Controller einrichtet und betreut, ist also nicht mehr nur ein interner Kostensammler, der sowieso in der Ergebnisrechnung landet, sondern ist Basis für den bilanziellen Wertansatz der Entwicklungskosten und unterliegt der Kontrolle des Jahresabschlussprüfers.

Quelle

Controller Handbuch, 6. Auflage neu geschrieben, Verlag für ControllingWissen AG, Offenburg

Ersteinstellende Autoren

Albrecht Deyhle, Controller Akademie

Gerhard Radinger, Controller Akademie