Web Cyberfahnder
über Suchmaschinen und -strategien
  Cybercrime    Ermittlungen    TK & Internet    Literatur    intern    Impressum 
kritische Projekte  
zurück zum Verweis zur nächsten Überschrift kritische Projekte
 


Großprojekte. Projektmanagement
Fehlerquellen
der subjektive Faktor
IT-Projekte
  Softwareentwicklung
Eskalation

fachliche Gefahrenquellen
Anmerkungen
 

 
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.
 

zurück zum Verweis zur nächsten Überschrift nach oben Großprojekte. Projektmanagement
 


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.
 

zurück zum Verweis zur nächsten Überschrift nach oben Fehlerquellen
 

 
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.
 

zurück zum Verweis zur nächsten Überschrift nach oben der subjektive Faktor
 

 
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.
 

zurück zum Verweis zur nächsten Überschrift nach oben IT-Projekte
 

 
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!
 

zurück zum Verweis zur nächsten Überschrift nach oben Softwareentwicklung
 

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

zurück zum Verweis zur nächsten Überschrift nach oben Eskalation
 

 
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


zurück zum Verweis zur nächsten Überschrift nach oben fachliche Gefahrenquellen
   
Zwischen den Jahren, also nach Weihnachten und vor Neujahr, gelangt dem jungen Richter - und das ist kein Vorwurf, sondern ein notwendiges Übergangsstadium - ein Antrag des ortsansässigen Großunternehmens auf den Tisch, das ausdrücklich mit Geltung ab dem 1. Januar des nächsten Jahres die Erhöhung seines Grundkapitals um 100.000 Euro beantragt.
 
Der Mensch ist in einer Zwickmühle. Er ist für das Handelsregister zuständig, hat aber ab Sylvester Urlaub. Den Kollegen, die ihn vertreten müssen, möchte er so wenig Arbeit hinterlassen wie möglich.
 
Er ruft deshalb das Programm "Handelsregister-Fach" auf und trägt die gewünschten Änderungen ein. Doch wann immer er das Verfügungsdatum auf den "01.01.<Folgejahr>" setzen will, "meckert" das Programm und trägt das aktuelle Datum ein.
 
Er ruft beim ServiceDesk an. Auch dort ist zwischen den Feiertagen eine Notbesetzung im Einsatz, freundlich und bemüht. Er schildert sein Problem und die beratende Stimme macht einen zielführenden Vorschlag: Er solle die Eintragung unter dem heutigen Datum machen. Sie werde die zuständige Fachverfahrensgruppe über den Programmfehler informieren und die regionale Systemverwaltung damit beauftragen, das Datum der Verfügung auf den 1. Januar umzusetzen.
 
So geschieht es.

 

 
Die Eintragungen im Handelsregister sind Verwaltungsaufgaben und unterliegen nicht dem Richterprivileg ( Art 97 Abs. 1 Grundgesetz - GG). Sie sind zudem konstitutiv, d.h. sie sind wirksam ab dem Moment, wann sie mit Unterschrift oder einer technischen Entsprechung verfügt werden.

Das Grundkapital des Unternehmens hat sich also noch im alten Jahr um 100.000 Euro erhöht. In aller Regel muss es seinen Jahresabschluss per 31.12. des laufenden Jahres erstellen ( § 242 Handelsgesetzbuch - HGB). Durch die Eintragung im Handelsregister erhöht sich sein Eigenkapital und sein Gewinn. Der Gewinn ist steuerpflichtig und könnte rund 50.000 Euro ausmachen.

Das ist der Schaden, der dem Unternehmen und als Schadenersatz dem jungen Richter droht.

Wenn der rührige Systemverwalter im Januar das Datum der Verfügung ändert, begeht er eine Fälschung technischer Aufzeichnungen ( § 268 StGB).

Das Fachverfahren jedenfalls hat richtig reagiert und auf das maßgebliche Datum des aktuellen Tages bestanden. Vorwerfen kann man ihm und seinen Entwicklern nur, dass es nicht auch das "Warum" seiner Meckerei angezeigt hat.
 

 
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.
 

zurück zum Verweis nach oben Anmerkungen  
 

 
(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
 

zurück zum Verweis nach oben Cyberfahnder
 

 

 

 

 

 

 

 

 

 

 

© Dieter Kochheim, 29.07.2009