28.01.2008: Im Zusammenhang mit der Einführung oder Modernisierung der Informationstechnik tauchen immer wieder Meldungen auf, dass sich Projekte verzögern, erheblich verteuern oder sogar scheitern. Beispielhaft sei an die Einführung der Autobahn-Maut für LKWs erinnert, die erst mit erheblicher Verzögerung eingeführt werden konnte und großes öffentliches Interesse hervorrief, und das Satellitennavigationssystem Galileo (1).

Ein Überblick über das Projektmanagement und die Softwareprojekte.
 

Ein Projekt ist ein einmaliges, zielorientiertes und befristetes Vorhaben. Darin unterscheidet es sich von einem Programm, das ein langfristiges Ziel verfolgt, zu dessen Erreichen einzelne Projekte aufgelegt werden.

Am Anfang des Projekts steht die Entscheidung über das Ziel, das erreicht werden soll. Bevor das Projekt aufgelegt wird, sollen in aller Regel die Varianten wegen der Zielerreichung bewertet, die Kosten und der Personaleinsatz kalkuliert werden. Der Auftraggeber steht insoweit in der Pflicht, die erforderlichen Mittel zu beschaffen und zur Verfügung zu stellen.

Die nächsten Fragen gelten der Art und Weise, wie das Projekt durchgeführt werden soll. In welchem Umfang können eigene Mitarbeiter eingespannt werden, wie werden deren sonstigen Aufgaben verteilt und welche Hilfe von Dritten muss angeworben und eingekauft werden? (2)

Sodann müssen die allgemeinen Verantwortlichkeiten, Aufgaben und Entscheidungskompetenzen geregelt werden. Im Allgemeinen wird dazu ein Projektauftrag entwickelt, der das Ziel des Projekts und die Aufgaben der Projektleitung sowie die des Auftraggebers definiert. Der Projektauftrag soll verbindlich sein und möglichst nicht mehr geändert werden.
 

 
Die Projektleitung muss klare Anweisungen bekommen, was von ihr verlangt wird und welche Mittel ihr dazu zur Verfügung stehen. Wegen der Projektarbeit muss sie eigene Gestaltungsfreiräume haben, in die auch nicht eingegriffen werden darf. Umgekehrt ist die Projektleitung zur Offenheit und Ehrlichkeit wegen des Projektstandes verpflichtet. Ergeben sich Probleme, müssen sie notfalls zusammen mit dem Auftraggeber gelöst werden.

Die Mechanismen für das Projektmanagement im Zusammenhang mit großen technologischen Projekten werden schon lange erprobt und gehen im Wesentlichen auf militärische, Flugzeugbau- und informationstechnische Erfahrungen zurück (3).

Die Literatur über das Projektmanagement und den mit ihm gemachten Erfahrungen ist fast unüberschaubar (4). Seine Instrumente sind der Projektplan, die Festlegung von Meilensteinen, die als Zwischenschritte erreicht werden sollen, das Risikomanagement und der regelmäßige Projektbericht, der den Auftraggeber über den Fortschritt, über Verzögerungen, Risiken und Ressourcentreue (Personal, Kosten) unterrichtet. Je nach Umfang des Projekts müssen ein Pflichtenheft aufgelegt, das die Einzelheiten des Projektauftrages ausführt, und ein gesondertes Controlling eingerichtet werden. Für die innere Organisation müssen bedarfsgerechte Ablaufpläne (kritische Kette), Informations- und Kommunikationsstrukturen und schließlich detaillierte Arbeitsaufträge bestimmt werden.
 

 
Ein Großteil der Fehler werden zu Projektbeginn gemacht. Als klassisch zu nennen sind zu optimistische Kostenansätze (5), unrealistische Zeitvorgaben, unklare oder wechselnde Projektziele und unerfüllbare Anforderungen an das Personal.

Je nach Umfang des Projektes benötigt es eine interne und arbeitsteilige Struktur zur Koordination, Informationsverteilung, Kommunikation und Steuerung. In aller Regel bedarf es eines Projektbüros als zentraler Anlaufpunkt für alle Beteiligten.

Arbeitsteilige Strukturen müssen dabei miteinander verzahnt werden, um widersprechende Arbeitsergebnisse zu vermeiden. Arbeitsgruppen neigen dazu, nur das eigene Arbeitsfeld im Rahmen des einzelnen Arbeitsauftrages zu betrachten, ohne die anderen zu beachten. Die Vermittlung wegen der Schnittstellen ist eine zentrale Aufgabe der Projektleitung.
 

 
Je komplexer das Projekt ist, desto mehr muss es das Informations- und Wissensmanagement fördern. Informationen, die zwar verfügbar, aber unter einer Vielzahl von anderen Informationen kaum erkennbar sind, bleiben ungenutzt und ineffektiv.

Wegen der Portionierung von Arbeitsaufträgen muss das Projektmanagement feinfühlig sein. Je nach Vorwissen und Können der Mitarbeiter müssen die Vorgaben mehr oder weniger abstrakt oder kleinschrittig sein und besonders bei Abhängigkeiten zwischen verschiedenen Arbeitsgruppen zeitlich und sachlich genau geplant werden (kritische Kette).

Nahezu tödlich für ein Projekt sind Schönfärbereien und Verdrängungen in Bezug auf den Ressourcen- und Zeitplan. Die wenigsten Projekte verfügen über Puffer wegen der Geldmittel und (fast immer) unvermeidbarer Verzögerungen.
 

 
Arbeitnehmer haben eine festgelegte Arbeitszeit, Anspruch auf Urlaub und können erkranken. Diese Aspekte bleiben bei euphorischen technischen Planungen meist unbedacht und rächen sich später (6).

Das Projekt lebt von seiner Akzeptanz. Technische Projekte sind meistens auch mit einschneidenden organisatorischen Änderungen verbunden. Insoweit sind verschiedene Zielgruppen zu betrachten: Motivation der Projektmitarbeiter, Unterrichtung und Förderung der übrigen Mitarbeiter, die mit dem geplanten Produkt umgehen sollen, gegenseitige Unterstützung zwischen Auftraggeber und Projektleitung und schließlich Förderung der Projektziele gegenüber Dritten (Kunden, Unternehmensleitung, normierende und zustimmungsberechtigte Einrichtungen).

Besonders kritisch sind solche Projekte, die tief in die Organisation und die Arbeitsumfelder eingreifen. Sie greifen Gewohnheiten und Privilegien an und müssen deshalb werbend und motivierend unterstützt werden, um vermeidbaren Widerständen zu begegnen (7). Hier ist vor Allem der Auftraggeber gefordert, seinen Einfluss im Interesse seines Projekts zu nutzen und zum Erfolg beizutragen, werbend und nötigenfalls mit Nachdruck.
 

 
Technische Projekte neigen in großen und komplexen Organisationen dazu, sensibel ausbalancierte Strukturen und Prozesse zu vernichten. Das mag berechtigt und gewollt sein, fördert aber den Widerstand und die Reibungsverluste. Wichtig ist es deshalb, dass am Anfang vom Auftraggeber klargestellt wird, welche Ziele er vom Projekt verlangt. Spätere Machtstreite, Zugeständnisse und faule Kompromisse erhöhen die Frustration und die Widerstände bei der Realisierung.

In besonderer Pflicht ist der Auftraggeber für den Umgang mit außen Stehenden, die eigene Interessen haben oder Abläufe durch Vorgaben steuern können. Im Einzelfall müssen sie gewonnen und geworben werden, wobei der Auftraggebers aus dem Projekt unterstützt werden muss.
 

 
IT-Projekte scheinen besonders sensibel zu sein, wenn sie mit grundlegenden Unternehmenszielen (Kosteneinsparung, strategische Ausrichtung, Outsourcing) verbunden sind. Das ist besonders der Fall, wenn es um die Realisierung anerkannter Methoden des IT-Managements geht (9), die immer mit strengen Prozessen und Neuerungen wie dem Service Desk sowie der Standardisierung der eingesetzten Hard- und Software verbunden sind. Diese Projekte haben auch einen besonderen Personalbedarf, weil sie - mit unterschiedlicher, zeitlich verteilter Gewichtung - Menschen in der Planung, also in der eigentlichen Projektarbeit, im Rollout der neuen Technik und in ihrem allmählich beginnenden Betrieb benötigen.

Im Zusammenhang mit IT-Projekten scheint es auch die meisten Verständigungsprobleme zu geben. IT-Fachleute neigen dazu, nicht nur (unvermeidliche) Fachworte in englischer Sprache zu verwenden, sondern gleich auch alle übrigen Arbeitsprozesse, Handlungen und Werkzeuge darin auszudrücken, obwohl sich einfache und bekannte Sachen dahinter verbergen.

Besonders in der Planungsphase eines Projekts und bei der Vereinbarung der vertraglichen Pflichten, wenn Entwicklungsaufträge an Dritte vergeben werden sollen, muss das Augenmerk auf klare Definitionen und präzise Absprachen gerichtet werden. Dasselbe gilt bei der Verlagerung von Betriebsaufgaben nach Maßgabe verbindlicher Leistungsbeschreibungen (11).
 

Strategisch relevant ist die IT (8)

wenn es um die Verfügbarkeit/Zuverlässigkeit geschäftskritischer Anwendungen geht,

wenn es um Security geht,

wenn es um gesetzlich vorgeschriebene und bei Mißbrauch strafbewehrte IT-Aufgaben geht (Datenschutz, Sabanes Oxley, ...),

wenn es (im öffentlichen Bereich) um „hoheitliche Aufgaben“ geht,

wenn es um Großinvestitionen/-projekte und IT-Architekturen geht,

wenn sich nachhaltige Wettbewerbsvorteile erzielen lassen.

 

Zehn Gründe, warum IT-Verträge scheitern (10)

1. Falsche Sparsamkeit

2. Zu viele Köche verderben den Brei

3. Nur an die Gegenwart denken

4. Sich unter Zeitdruck setzen lassen

5. Stillhalteabkommen

6. Compliance nicht im Blick

7. SLAs mit untauglichen Parametern

8. Fehlendes Eskalations-Management

9. Kein Blick zurück

10. Wirtschaftliche Effizienz wird nicht geprüft!

 

 
Von zentraler Bedeutung für jedes Softwareprojekt ist das Pflichtenheft. In ihm beschreibt der Auftraggeber die Anforderungen, deren Erfüllung er von dem fertigen Produkt erwartet. Darüber hinaus muss er die Besonderheiten der betrieblichen Umgebung definieren, also besondere Anforderungen des Datenschutzes, die unverzichtbare Technik (z.B. im Hinblick auf Fach- und Datenbankanwendungen) und nur ausnahmsweise auch die besonderen Anforderungen an die Werkzeuge, die beim Einsatz angewandt werden sollen (z.B. bestimmte Produkte, wegen der langfristige Verträge bestehen, Open Source oder Programme, die aus Sicherheitsgründen nicht verwendet werden dürfen).

Performance, Sicherheit und Bedienungsfreundlichkeit sind die geschuldeten Leistungen des Entwicklers, ohne dass darüber ein Wort verloren werden muss. Wegen besonders aufwändiger Leistungsmerkmale können spezielle Abreden getroffen werden, z.B. wegen laststarker Prozesse zur Unterstützung des Berichtswesens oder des Controllings, die zwar benötigt, aber nur gelegentlich eingesetzt werden. Wegen der üblichen Arbeitsabläufe muss der Entwickler hingegen eine zügige Bearbeitung garantieren.

Im Rahmen der Verhandlungen und Abstimmungen zum Pflichtenheft hat auch der Entwickler eine Beratungspflicht. Sein Wissen ist gefragt, um über wirtschaftlich unvertretbare Aufwände und schlanke Alternativen aufzuklären (12).
 

 
Darüber hinaus muss der Auftraggeber und Kunde auch Testdaten, Testpersonal und besonderes Fachpersonal zur Verfügung stellen, um die Funktionstüchtigkeit der entwickelten Software zu prüfen oder bei unklaren Vorgaben im Pflichtenheft die fachlich und rechtlich optimale Lösung zu finden.

Alle Unklarheiten und Nachlässigkeiten im Pflichtenheft führen zum Streit über die geschuldete Leistung und wegen der Changes, also in aller Regel kostenträchtigen Änderungen an der Auftragsbeschreibung.

Die Diskussionen um das Outsourcing und wegen der ITIL-gerechten IT-Organisation haben den Eindruck entstehen lassen, das Wissen über den Einsatz der Informationstechnik lasse sich vollständig auslagern. Das ist falsch. Standardberatungen und der Betrieb üblicher (Büro-) Software lässt sich sicherlich im großen Maßstab organisieren und davon Behörden und Unternehmen entlasten. Die rechtlichen Anforderungen an den Betrieb und vor Allem an der Sicherheit der Datenverarbeitung werden hingegen immer strenger und verlangen nach einem allgemeinen IT-Grundwissen, das ganz überwiegend von den Mitarbeitern eingebracht werden kann, die hier auch handwerkliche Erfahrungen gemacht haben.

Genau dieses Wissen wird bei den Verhandlungen über Pflichtenhefte und SLAs benötigt, wenn man sich als Auftraggeber nicht hilflos in die Hand eines Dritten begeben will. Es wird auch benötigt, wenn Anwenderfragen aufkommen, die sowohl die Fachlichkeit wie auch die Programmanwendung betreffen ( fachliche Gefahrenquellen).
 

 
Der Auslöser für diesen Beitrag ist ein Artikel von Jürgen Beckers in tecchannel (13). Er beschäftigt sich als Rechtsanwalt mit der Frage, wie ein Software-Projekt wieder zum Laufen gebracht werden kann, wenn sich die Vertragspartner heillos verstritten und verbissen haben.

Seine Vorschläge kommen eigentlich zu spät und unter optimalen Bedingungen hätte die Eskalation vermieden werden können. Optimale Bedingungen gibt es hingegen nie.

Seine Vorschläge zeigen umso mehr, wie wichtig es ist, mit gutem KnowHow auf beiden Seiten zu verhandeln, um Lücken, Zweifel und Fallen zu vermeiden.

Damit bewahrheitet sich, dass auch auf der Seite des Auftraggebers kompetentes Wissen stehen muss, das Schluderichkeiten erkennt und ein wissender Verhandlungspartner ist.
  

 

In fünf Schritten zur Projektsanierung

Bestandsaufnahme wegen der Gründe des Projektstillstands

angemessen zurückhaltende, aber nötigenfalls knallharte Eskalation gegenüber dem Vertragspartner, also nicht gegenüber den ausführenden Entwicklern, sondern der Geschäftsleitung als Vertragspartner

Entwicklung eines Maßnahmenplans mit Meilensteinen und Erfolgskriterien

Aktualisierung des Projektplans und Anpassung der Verträge an die gemeinsam beschlossenen Änderungen

Überwachung des Projektfortschritts und der getroffenen Vereinbarungen

 
Alle Verwaltungs- und Justizbereiche haben besondere Gefahrenquellen, die nach einer spezifischen Datensicherheit und Beratungsqualität verlangen.

Kein Richter ist so gefährdet wie der Familienrichter, der mit enttäuschten und aufgebrachten Scheidungspartnern zu tun hat. In Ermittlungsverfahren wegen Rauschgifthandels mischt sich auf der Seite der Beschuldigten das große Geld mit einer besonderen Gewaltbereitschaft. Im Zusammenhang mit der Lagerung von atomaren Abfällen entscheiden die Verwaltungsgerichte über Demonstrationsrouten und -beschränkungen. Jeder Aufgabenbereich wird seine besonderen Gefahrenquellen benennen können.

Links wird eine Geschichte erzählt, die so oder in einem anderen Zusammenhang geschehen kann, wenn die fachlichen Beratungen und Kontrollmechanismen bei den Fachanwendungen außer Acht gelassen werden.

Beispiele aus anderen Fachbereichen lassen sich beliebig ersinnen.
 

 
(1) Toll Collect soll zwei Milliarden Schadenersatz zahlen, Spiegel online 05.12.2007
LKW-Maut: Mehr Geld für Toll Collect, Heise online 09.02.2006
Marcus Hammerschmitt, Orbitale Machtspiele. Galileo wird teurer, und China will sich auch positionieren, Telepolis 29.01.2008

(2) Consulting: Beraterphrasen kosten nichts, tecchannel 27.04.2006

(3) Niels Boeing, Systemmanagement im alten Ägypten, Technology Review 02.04.2007
Ralf Blittkowsky, Langzeitarchivierung industrieller IT-Prozesse, Telepolis 06.02.2004
Günter Stauch, Sechs Millionen Teile, Technology Review 28.09.2005

(4) Einführungen (Beispiele):
Harry Zingel, Grundzüge des Projektmanagements, Zingel 2005
Harry Zingel, Grundzüge der Projektorganisation, Zingel 2001 (ZIP-Datei)

(5) Gordon Bolduan, "Kultur der Fehlinformation". Interview mit Bent Flyvbjerg, Technology Review 11.01.2008

(6) Michael Schweizer, "Hilfe, mein Chef ist unfähig", tecchannel 08.05.2007
 

 
(7) Jeder fünfte Mitarbeiter ist ein Totalausfall, tecchannel 24.11.2005

(8) Robert Goecke, Was ist an der IT noch strategisch? segma 06.03.2005, S. 7

(9) International anerkannte Prozesssteuerung aus Großbritannien: Information Technology Infrastructure Library - ITIL

(10) Ralph Treitz, Zehn Gründe, warum IT-Verträge scheitern, Computerwoche 18.09.2007

(11) Am bekanntesten sind die Service Level Agreements - SLA, in denen die geschuldeten Dienste, Reaktionszeiten und Informationspflichten geregelt werden.

(12) Frank Koch, IT-Verträge: Wie man Fußangeln vermeidet, Computerwoche 20.03.2006

(13) Jürgen Beckers, IT-Projekte vor dem Scheitern bewahren, tecchannel 28.01.2008