Projektcontrolling 2.0 – weniger ist mehr

Wenn große Projekte in Schieflage geraden, ist der Ruf nach „mehr Transparenz“ nicht weit. Manch einer mag sich dabei an den Film „Didi der Doppelgänger (1984)“ erinnern, in dem das ahnungslose Double auch noch so kritischen Besprechungs-Situationen stets mit einem ernst vorgetragenen: „Ich brauche mehr Details“ entkommen konnte. Das führt zu der Frage: Welche Transparenz fehlt denn wirklich?

Schließlich verfügen gerade größere Organisationen heutzutage bereits über komplexe kaufmännische Systeme, die Unmengen an Detail-Informationen bis hin zur Einzelbuchung jederzeit transparent zur Analyse bereithalten. Daher ist wohl weniger von einem Transparenzproblem auszugehen, als vielmehr von einem Analyse- oder Verständnisproblem. Am Beispiel eines Röntgenbildes machen Röntgenstrahlen den Menschen zwar transparent, es bedarf aber erst einer medizinischen Ausbildung, um es verstehen, und die richtigen Schlüsse daraus ziehen zu können.

„Mehr Transparenz“ ist demnach weniger eine Frage von mehr Daten, mehr Kontrollen oder mehr Controlling, sondern vielmehr die eines wirkungsvolleren Controllings. Dies hat die 1. Wissenschaftliche Vereinigung Projektmanagement e. V. zum Thema ihrer diesjährigen Jahrestagung gemacht, die am 06.05.2015 in Berlin unter dem Motto „Projektcontrolling aus Sicht des Auftraggebers – Transparenz mit Verstand“ stand. Mit meinem Beitrag unternehme ich den Versuch, einen Rahmen für ein wirkungsvolleres Controlling abzustecken, mit dem in großen Projekten und Auftraggeber­organisationen künftig die tatsächlich benötigte Transparenz erzeugt werden kann.

Der Weg zu diesem Ziel beginnt mit einem Verständnis der Ausgangssituation. Bauherren, die Großprojekte durchführen, verfügen auf Unternehmensebene i. d. R. über kaufmännische Standardlösungen, sogenannten ERP[1]-Lösungen. Aus der Welt des Rechnungswesen kommend liegt ihr Fokus i. W. auf der kaufmännischen Prozessunterstützung unter Integration steuerlicher oder bilanzieller Aspekte. So naheliegend ihre Anwendung auch in Projekten erscheint, so ungeeignet sind sie für ein wirkungsvolles Projektcontrolling: Mit Budgets, Obligen, Zahlungen oder Konten lassen sich Kosten zwar rückwirkend analysieren, nicht aber Projekte vorausschauend steuern. Dazu bedarf es anerkannter Kompetenzen und normierter Methoden der Architekten, Ingenieure und Projektsteuerer, die in standardisierten kaufmännischen Unternehmenslösungen nicht enthalten sind.

Nachdem etwa Verträge und Rechnungen aus dem Projekt jedoch ohnehin auch in den kaufmännischen Systemen verarbeitet werden, besteht ein großes Bedürfnis, diese Daten trotzdem zu nutzen, anstatt redundante Systeme zu führen. Daher versuchen Integrationsanbieter, kaufmännische Projekt- und Unternehmenswelten systemtechnisch zusammenzuführen. Dabei entstehen komplexe System-Lösungen, die für sich schon schwer zu beherrschen sind. So mag die Möglichkeit des „kontierten Einkaufs“ z. B. verlockend klingen, jedoch setzt sie voraus, daß der Ersteller der Leitungsbeschreibung (Qualifikation: Architekt, Ingenieur) seine Leistungsverzeichnis-Positionen jeweils einzeln richtig kontiert (Qualifikation: Bilanzbuchhalter). Davon ist i. d. R. jedoch nicht auszugehen, wenngleich auch falsche Kontierungen eine beeindruckende Scheingenauigkeit suggerieren und so das gute Gefühl vermitteln, auf dem richtigen Weg unterwegs zu sein. Aber auch die Baupraxis kann unter solchen Integrationsansätzen leiden, wenn etwa aus Kostentragungs-Gründen eine zusammenhängende Leistung auf mehrere getrennte Bestellungen bzw. Verträge aufgeteilt werden muß. Wehe dem, der eine solche Bauleistung später leiten oder gar abrechnen muß.

Die „Bändigung“ solch komplexer Systeme bindet schnell sehr große Ressourcen und kann dabei ein regelrechtes Eigenleben entwickeln. Dabei wandelt es sich von einem dienenden Unterstützungssystem zunehmend hin zu einem datenhungrigen Kontrollsystem, von dessen kontinuierlicher „Fütterung“ der reibungslose Ablauf von Geschäftsprozessen abhängt. Wo früher noch eine Geschäftsführer-Unterschrift den Weg frei gemacht hat, ist das heute die Erfassung eines „bebuchbaren Kontierungs-Elementes“ im System durch einen Projekt-Controller. Damit ergibt sich folgendes Zwischen-Fazit:

  1. Wenn Projekte Transparenz-Defizite haben, dann deutet das eher auf falsche Informationen hin als auf zu wenige. Richtige Informationen sind dabei solche, die eine wirkungsvolle Steuerung von Bauprojekten ermöglichen. Alle darüber hinausgehenden Informationen belasten, indem sie den Blick auf das Wesentliche verstellen.
  2. Sachlogisch und methodisch kommen für die Steuerung von Bauprojekten benötigte Informationen aus der Welt der Architekten, Ingenieure und Projektsteuerer. Weil die Durchführung von Verträgen ein wesentlicher Bestandteil ihrer Leistung darstellt, besteht hier eine Schnittstelle zwischen der Unternehmens- bzw. Buchhaltungs-Welt und der Projektwelt.
  3. Die systemtechnische Verknüpfung dieser beiden Welten ist aufwendig und riskant. Dazu kommt, daß zusätzliche Unternehmens- bzw. Buchhaltungs-Daten für die eigentliche Steuerung von Bauprojekten nicht benötigt werden. Deshalb sind auch Mehrwert und Aufwands-/Nutzen- Verhältnis einer solchen Verknüpfung für ein wirkungsvolleres Projektcontrolling kritisch zu beurteilen.

Ein wirkungsvolles Projekt-Controlling zeichnet sich durch weniger, dafür aber umso geeignetere Informationen aus, die entsprechend ihrer Veranlassung auch aus der Projektwelt kommen, und deren Strukturen und Methoden folgen müssen. Dies schließt einen Wandel von der buchhalterisch geprägten Zahlen-Arithmetik hin zu Inhalten mit Kostenbezug ein. Wer nämlich Kostenexplosion beklagt, spricht ‑ kausal begründet ‑ meist über Leistungsexplosion. Und die wird auf der Kostenseite im Rechnungswesen erst sichtbar, wenn sie auf der Leistungs- bzw. Projektseite schon erbracht ist ‑ also wenn es schon zu spät ist.

Ex post können daran auch noch so viele Controller nichts ändern, weil sich Qualität nicht im Nachhinein in einen Sachverhalt „hineinprüfen“ läßt. Qualität muß vielmehr im ersten Anlauf erzeugt werden, was allerdings klare Anforderungen oder Ziele voraussetzt. Sie sind der Schlüssel für ein besseres Projektcontrolling, wie es auch in der DIN 69901-5 mit „Sicherstellung des Erreichens aller Projektziele durch Ist-Datenerfassung, Soll-Ist-Vergleich, Analy­se der Abweichungen, Bewertung …“ definiert ist. Dementsprechend sollte ein Projektcontrolling auch strikt den Bezie­hungen zwischen den Projektbeteiligten folgen, die kausal regelmäßig wie folgt aufgebaut sind:

  1. A beansprucht vereinbarungsgemäß von B eine definierte Leistung in Zeit, Kosten und Qualität
  2. A und B haben eine gemeinsame Interessenslage bezüglich der Erfüllung
  3. A fördert und unterstützt den Fortschritt, B leistet und berichtet ihn
  4. A überwacht den Fortschritt im Hinblick auf die Erreichung der geschuldeten Leistung (das eigentliche „Controlling“)

Dieses Muster ist auf alle Projektbeziehungen übertragbar, ob zwischen Bauherr und Architekt, zwischen Bank und Bauherr, oder zwischen Nutzer/Betreiber und Eigentümer. Weil jede dieser Projektbeziehungen ihre eigene Interessenslagen und Ziele hat, muß auch für jede Beziehung ein eigenes Controlling individuell maßgeschneidert werden. Das ist zwar aufwendig, kann aber auch nicht durch ein „Maximal-Controlling“ abgedeckt werden, das quasi als Vereinigungsmenge alle Informationsbedürfnisse abdeckt: Zum einen würden Verständlichkeit und Aussagekraft darunter leiden, und sei es nur durch eine „managementgerechte Nachverdichtung“ zu Ampel- oder Cockpitcharts. Zum anderen können die Ziele zwischen verschiedenen Projektbeziehungen variieren, wenn etwa der Architekt einem anderen Kostenziel verpflichtet ist als die Bank finanziert hat. Beim Controlling gilt deshalb besonders: „Viel hilft nicht viel“, hier geht Klasse vor Masse.

Strukturell ist das Controlling auf den spezifischen Informationsbedarf des Empfängers abzustimmen. Die Infor­ma­tionen sind empfängergerecht aufzubereiten und durchgängig in Form, Inhalt und Taktung regelmäßig zu berichten. Unwesentliches ist dabei von Wesentlichem zu unterscheiden, Verständlichkeit geht vor Vollständig­keit. Entscheidend ist eine klare Darstellung des jeweils gültigen SOLLs als Grundlage einer möglichst textlichen, graphischen und numerischen Gegenüberstellung des tatsächlichen IST. Ohne SOLL kann das Controlling nur einer unsteuerbaren Entwicklung hinterherschauen ‑ wie einer Sternschnuppe, bei der Wünsche aber meist nicht in Erfüllung gehen. Soweit der SOLL-IST-Vergleich konkretes Eingreifen des Berichtsempfängers erfordert, sind die notwendigen Aktionen unmißverständlich als delegierbare Handlungsempfehlungen zu formulieren. Ampel-Darstellungen sind nach Möglichkeit zu vermeiden; wo dies nicht möglich ist, müssen klare „Schaltregeln“ definiert werden, die nachprüfbare und reproduzierbare Darstellungen ermöglichen.

Das hat nicht zuletzt auch mit kulturellen Aspekten zu tun, die ein wesentlicher Bestandteil erfolgreichen Projektcontrollings sind: Der Berichts-Empfänger muß sich zwingend inhaltlich mit dem Bericht auseinandersetzen und ihn verstehen (wollen), wenn er seiner Rolle und Verantwortung gerecht werden möchte. Die Reduktion auf Ampel-Darstellungen o. ä. stehen dem entgegen und sind insofern eine unzulässige Vereinfachung, die den Bericht entwerten. Dem Wortsinn nach kann ein „Bericht“ im übrigen auch ein mündlicher Vortrag sein und ich plädiere stark dafür, ausgedruckte Berichte in gemeinsamen Terminen mündlich durchzusprechen. Dies dient nicht nur dem besseren Verständnis, es weckt auch das Interesse an Inhalten und fördert das Entstehen einer respekt- und vertrauensvollen Zusammenarbeit zwischen den Beteiligten. Und Vertrauen ist schon deshalb erforderlich, weil der Berichtende zu Gunsten der besseren Verständlichkeit nach eigenem Ermessen Wichtiges von Unwichtigem unterscheiden und weglassen muß. In einer solchen Arbeitsbeziehung können dann auch unvermeidbare Einzelabweichungen besser als ungefährlich erläutert werden, als dies eine „rote“ oder „grüne“ Ampel darstellen könnte.

Ein so konzipiertes Controlling ist mit eingangs beschriebenen Controlling-Systemen großer Organisationen nicht in Einklang zu bringen. Es ist daher anzuerkennen, daß ein wirkungsvolleres Projekt-Controlling redundante Parallel-Strukturen erfordert, die natürlich Schnittstellen zu Buchhaltungs- und Rechnungswesenprozessen des Bauherrn aufweisen. Dem Kaufmann mögen zwar die damit einhergehenden Abstimmungs- und Übertragungsaufwände widerstreben, dies ist aber eben der Preis für ein wirklich wirkungsvolles Controlling, das Leistungexplosionen erkennen hilft, bevor sie sich als Kostenexplosionen unwiderruflich materialisieren. Auch die „Transparenz-Ausrede“ ist dann hinfällig, wenn jeder Berichtsempfänger genau die Informationen erhält, die er „bestellt“ hat und nicht jene, die von einer zentralen Einheit als allgemeingültig notwendig eingeschätzt worden sind. Nicht zu unterschätzen ist bei redundanten Systemen schließlich auch die Chance, durch regelmäßige manuelle Abstimmung der Systeme Fehler zu entdecken, die sonst einfach nur automatisch fortgeschrieben worden wären.

Damit läßt sich dieser Beitrag wie folgt zusammenfassen:

  1. Wirkungsvolles Projektcontrolling ist die Wahrnehmung im Projekt bestehender fachlicher und inhaltlicher Sorgfaltspflichten und Obliegenheiten.
  2. Übergeordnete kaufmännische (Unternehmens- / ERP-) Systeme können diese Anforderungen weder numerisch, noch inhaltlich, noch prozessmäßig abdecken.
  3. Projektcontrolling und -systeme gehören in die ganzheitliche Verantwortung des Projektes. Schnittstellen zu ERP-Systemen verbessern die Qualität.
  4. Schriftliche Berichte müssen individualisiert und empfängergerecht aufgebaut sein und sind vom Berichtenden jeweils mündlich zu erläutern.

Ohne Kompetenz-, Aufrichtigkeits- und Vertrauens-Kultur und das (Selbst-) Verständnis des Controllers als Berater und „Navigator“ (und nicht als Kontrolleur) ist das beste Projektcontrolling zum Scheitern verurteilt.

 

[1] Enterprise Ressource Planning