IT als People Business (Teil 2) – Organisationsmodelle in der Steuerung von IT-Projekten. Der Praxis-Leitfaden.

Die Ausgangsthese bleibt noch immer: IT ist vor allem „People Business“. D.h. die subjektiven Konstruktionen der Realität der Beteiligten sind wesentlich im Alltag. Alle Beteiligten haben ihre sehr spezielle Sicht zu ihren eigenen Aufgaben und zu dem, was für sie (un-) wichtig ist. Der detaillierte IT-Praxis-Leitfaden.

von Dr. Peter Bohnenkamp  

Dies gilt vor allem auch für Softwarenentwicklungsprojekte: Fachbereiche, Entwickler und IT-Betrieb (sowie „sonstige Interessierte“) lassen sich dabei in verschiedenartigen Konstellationen anordnen. Hier hat man in der Praxis schon so ziemlich alle Varianten ausprobiert. Ihre (natürlich wiederum subjektiven) Vor- und Nachteile stehen im Mittelpunkt der folgenden Diskussion.

Bevor wir zu diesen kommen, sei kurz auf die Komplexitätsfaktoren von Software-Entwicklungsprojekten (SWE) und die wesentlichen Dokumente in einem effizienzorientierten Vorgehensmodell eingegangen.

Strukturparameter von Softwareentwicklungsprojekten und passende Dokumente – ein normativ-abstraktes Modell

Die Komplexitätsfaktoren sind vielfältig in der Literatur diskutiert. Jeder Profi hat hier sicher seine eigene Meinung. Der Autor dieses Artikels nutzt meist das folgende Modell, um ein Softwareprojekt erfolgreich zu gestalten:

1. Das „A und O“ eines SWE-Projektes ist eine erstklassige fachliche Beschreibung der Aufgaben der Anwendung (und auch dessen, „was nicht Gegenstand des Release 1“, sondern ggf. zukünftiger Releases ist). Diese gilt es zu zerlegen in „Use Cases“ (Wobei dies nur heißt: Es sollte eine gut lesbare fachliche Beschreibung erstellt werden; diese muss aber nicht „formal“ speziellen Anforderungen genügen). Die Menge der „Use Cases“ muss vor Start der Entwicklung vollständig und insb. konsistent sein. Das ist zentral! Eine „perfekte“ Beschreibung (in der Tiefe) ist für die erste Iteration aber nicht Voraussetzung (aber besser wäre es natürlich). Die obligaten Komponenten, die man zerlegt beschreiben sollte, sind: (a) Oberflächen mit passenden Prüfungen (b) Funktionen im Hintergrund (man kann diese auch „Services“ nennen, wenn man „moderner“ sein will), d.h. Abspeichern/ Löschen/ Ändern/ Ergänzen/ ggf. sogar „Rechnen“,  (c) alle Schnittstellen zu anderen Anwendungen (Daten „in“/ „out“ – nur die funktionale Sicht, nicht die Technik der Schnittstellen!), (d) Recherche/ Reporting/ Archivierung-Funktionen und auch (e) Rollen & Rechte hierzu sowie (f) (nicht zu unterschätzende) „House-Keeping-Funktionen/ -Jobs.

2. Damit die Konsistenz gesichert wird, sollte man ein passendes „fachliches Datenmodell“ aufstellen und idealerweise mit einem (Excel-) Beispiel (in Kombination mit 1) unterlegen – das ist nach allen Erfahrungen hilfreich für die Realitätsnähe der Konzeption; so wird dann i.Ü. auch ein erster Satz an Testfällen und passenden Testdaten entwickelt.

Die beiden Dokumente „zerrt“ man (ja, das Wort ist bewusst so gewählt) durch das ganze Projekt und passt sie an, wenn sich in der Entwicklung oder im Test „Neues/ Anderes“ ergibt (Disziplin ist hier der wesentliche Faktor!). Man fügt dann auch die sukzessive erstellten, realen Screenshots der Oberfläche und  ggf. Auswertungen ein, erweitert die Testfall-Menge etc. Auch wenn der Autor der schönen Meinung ist „Change Requests sind Schande!“ – im Kleinen gibt es sie immer… Nur wenn am Ende des Projektes die beiden Dokumente 100% dem Gebauten entsprechen, ist es gut (sonst leider meist unvollständig, denn ein einmalig am Anfang geschriebenes Dokument ist im Anschluss nur 65-85% der Wahrheit und schon startet man mit einem „Gap“ in den endlosen Lebenszyklus der Anwendung).

3. Gebaut und getestet wird natürlich in Iterationen resp. sukzessive in Bausteingruppen (nicht alles auf einmal/ erst am Ende alles!).

Dass dies an dieser Stelle so explizit gesagt wird, beruht auf drei Faktoren: (A) Der Tatsache, dass es – aus welchen Gründen auch immer – nur wenig Menschen gibt, die schnell ein gutes, komplett konsistentes Fachkonzept schreiben können auf einem angemessenen Abstraktionslevel, dies aber wesentlich ist, will man die Aufwände in Zeit & Geld vorab schätzen, um zu entscheiden, ob man das Projekt überhaupt durchführt, resp. ggf. was man weglassen kann, damit es sich „lohnt“. (B) Dem häufigen Missverständnis, dass in <nicht radikalagilen Ansätzen“> ein Fachkonzept immer bis in die „letzte Tiefe“ geschrieben wird mit „lästigen formalen Vorgaben“, gar ohne Berücksichtigung der Wünsche der Kunden, resp. der normativen These, dass „schon eine ordentliche Liste aller Use-Cases zu Beginn ein verbotenes Etwas sei“. Alles leider nur albern. (C) Radikale Agilitätsvertreter übersehen dann auch gern, dass kein vernünftiger Projektleiter in der Vergangenheit gewartet hat, bis alles fertig gebaut war; er hat immer in Abschnitten/ partiell auch parallel Module bauen lassen und diese frühzeitig getestet. Die strikte Dichotomie (böser) Wasserfall – (gutes radikal-) Scrum ist ein Mythos, resp. eine Seltenheit (dann mit „Amateuren“ auf beiden Seiten). Damit sind wir bei den technischen Themen:

4. Welche „Frameworks“, Programmiersprachen, Datenbanken etc. genutzt werden, bleibt eine Frage der (A) firmeneigenen Standards und vor allem aber auch (B) der Kompetenz zu den Themen in Entwicklung/ Betrieb sowie (C) der Funktionalität (eine High-Performance Transaktionsengine z.B. hat andere Anforderungen als eine Oberfläche im Internet oder eine Big-Data-Analyse-Anwendung – es existiert leider nicht der „eine Technologie-Stack, der für alles richtig ist“). Zu viele Neuerungen (nicht selten gern gesehen von Entwicklern, Architekten, Herstellern und Technologie-Experten im Betrieb) ist dabei leider selten bis nie gut für das Projekt – resp. erhöht die Komplexität in (zu) hohem Maße.

5. Dies gilt auch für die Auswahl der Dienstleister, die man im Projekt einsetzt: „Drei (insb. neue) sind sicher schon fast zwei zu viel“, lautet da die subjektive Meinung – ergänzend auch: „Setze nie Dienstleister ein, die glauben, die Größten zu sein und alles besser zu wissen, als ihr Auftraggeber“.

6. Welche Hardware genutzt wird, sollte man sich passend zu den Performance-, Verfügbarkeits- et al. Anforderungen (und dem Technologie-Stack) auch am Anfang gut überlegen; Experimente hier müssen sehr gut begründet sein und dürfen nur in Projekten umgesetzt werden, die weder Zeit- noch Budgetdruck, noch irgendeine sonstige „Wichtigkeitsfunktion“ aufweisen.

6. Konventionelle DV-Konzepte schreiben, ist inzwischen bekanntlich aus der Mode gekommen; ein „pragmatisches DV-Konzept“ besteht am Anfang daher nur aus den Entscheidungen zu 4 und 6; am Ende sollten dann noch vorliegen: (a) Ein Datenbank-Dokument (das die realen Datenbank-Tabellen mit ihren Feldern listet und eine Zuordnung zu den fachlichen Funktionen aus 1. resp. der fachlichen Datensicht aus 2. aufweist) sowie (b) eine (z.B. Excel-) Tabelle, in der je Use Case (aus 1.) beschrieben wird, welche Programme/ Klassen/ Methoden für diese relevant sind und welche Datenbank-Tabellen dabei aufgerufen werden (d.h. ein Use Case weist dann x Zeilen – jeweilig 1 Zeile pro Objekt – auf).

Das finden klassisch denkende Kritiker vielleicht anarchistisch-minimalistisch und zu wenig technisch (resp. sie rufen aus: „Was haben denn die fachlichen Use Cases hier verloren“?). Nun, hierzu gilt die Meinung: Im praktischen Leben ist es später vor allem wichtig, möglichst schnell reagieren zu können, wenn der Fachbereich „die Funktion x nun statt in Rot, lieber in Grün“ hätte… Das findet man hier perfekt schnell, grenzt den Umfang der SW-Objekte maximal ein und den „Rest“ muss der Entwickler sich dann ohnehin in den Software-Objekten selbst ansehen (schön wenn diese dann aussagekräftige Kommentare enthalten – das ist aber ein anderes Thema).

Mit diesen Meinungen ausgestattet ordnen wir nun die Aufgaben Personen zu, resp. Organisationseinheiten (oder -bereichen) und legen die Beziehungen zwischen den Beteiligten fest.

Klassische Varianten der Zusammenarbeit im Softwareentwicklungsprojekt von „Auftraggeber“/ „Fachbereich“, „Entwicklung“, „Betrieb“ und „Projektleitung“

Die folgende Übersicht zeigt die Strukturkomponenten und einen ersten Satz („klassischer“) Varianten der Steuerung der Zusammenarbeit.  Nicht selten wird dies Thema auch unter dem Stichwort der „IT Governance“ diskutiert.

Variante A1 „Fachbereichs-Modell“ in der obigen Darstellung geht von der These aus „Entwickler sind <Programmierknechte>; sie sollen das technisch umsetzen, was im Fachkonzept steht und Ende“. D.h. der Fachbereich beansprucht für sich alle Macht der inhaltlichen Definition („Wer das Geld hat, schafft an“) – das mag bis hin zur Vorgabe der Technologie reichen, blickt man auf das Vorgehensmodell in Kapitel 1.

Leider setzt dies voraus, dass die Mitarbeiter des Fachbereichs dann erstklassig in der Lage sind, „grade Sätze zu schreiben“, d.h. ihre Vorstellungen in einem konsistenten Satz von Use Cases und einem fachlichen Daten- und Testmodell abzubilden, das so gut ist, dass Entwickler (die ja hier “keine Ahnung von der Fachlichkeit haben“)  es „blind“ 1:1 umsetzen können. Schade, dass gilt, dass diese Entwickler ein Fachkonzept nie ganz genau lesen, da es (aus ihrer Sicht) „ja nie vollständig sein kann und es sie in ihrer Entwicklungskreativität einschränkt“. Die Fachbereiche sollten auch genügend Technologie-Kenntnis besitzen, wenn sie sich hierzu zu äußern gedenken… Sie dürfen sich hier aber gern auch belügen, was sie denn alles unbedingt benötigen – denn es ist hier meist auch „ihr Geld“ (d.h. ein solches Modell erscheint ohnehin nur sinnhaft in einer Organisation, in der die Fachbereiche eine weitreichende Budget-Hoheit haben, solange sie ihre Deckungsbeitragsziele erreichen).

Variante A2 der Zusammenarbeit geht aus vom Bild der „Entwicklung als Schrittmacher“ – d. h. der umgekehrten These: „Fachbereiche wollen immer nur mehr, sie können ihre Wünsche nicht ordentlich darstellen, haben keine Ahnung von der Technik und den Auswirkungen ihrer Wünsche auf die Kosten“ sagt die IT und bestimmt daher hier das Geschehen auch in den frühen Phasen des Modells aus Kapitel 1. Die Entwickler (mit umfassenderem Fach-Know-How) schreiben auch die Fachkonzepte in der Tiefe (basierend auf „Wunschzetteln“ oder groben Interviews mit den Usern). Technik-Themen werden mit dem Fachbereich nicht diskutiert. Er bekommt eine Rechnung. That`s it.

Der Autor sagt dazu nur: „Ausgerechnet die Entwickler sollen 1. und 2. (d.h. die fachliche Beschreibung der Anwendung und das fachliche Datenmodell) schreiben? Dazu müssten sie in der Lage und auch motiviert sein. Da sie (siehe Rollenmodell) jedwede Dokumentation hassen, ist es noch unwahrscheinlicher als Variante A1, das dies funktioniert“.  Kritiker werden einwenden: „Immerhin könnten die Technologie-Entscheidungen hier besser sein als bei A1 und Entwickler mit Fachkompetenz seien doch hilfreich“. Da stimmt der Autor partiell zu und freut sich im Projekt über jeden, der wenigsten ein wenig Ahnung vom Thema hat. Aber Entwickler/ die IT allein im Lead?  Da bleibt es beim “Nein!“ für dieses Modell.

Variante A3 der Zusammenarbeit: „Das („Kuschel“) Scrum Modell“

Theoretiker, Personaler und andere Menschen, die an das Gute glauben, sagen nun die Antwort ist doch ganz einfach: Da bringen wir Fachbereichs- und Entwicklungs-Mitarbeiter zusammen in eine Gruppe in einem positiven (räumlichen und sozialen Umfeld (sagen der Change und der Innenarchitekturberater, die auch Geld verdienen wollen). Dann entwickeln die Mitarbeiter „frei und glücklich“ die Dokumente und die Anwendung gemeinsam-kooperativ, sukzessive in „Sprints“ (ggf. sogar unter Befragung der Enduser, wenn es denn solche geben sollte, im „Design Thinking Approach“; das Ganze im „puren Scrum“ auch ohne einen fest definierten Scope). „Mhm, diese Menschen glauben auch an das Christkind“ sagen die Kritiker der Praxis und ergänzen Scrum – wie hier – um ein Zusatzwort, das die positivistische Sicht karikiert. Wenn Sie gut gelaunt sind, hört man gelegentlich: „Ok, kann man machen, wenn es nur eine unwichtige, z.B. „Fun“-Anwendung auf der Spieloberfläche des Internets ist. Aber sonst: Nein, insb. nicht, wenn Zeit und Geld höchst knappe Güter sind und das Thema komplex ist – insb. im Sinne der notwendigen Konsistenz der Komponenten“. Für Zyniker ist die Meinung eines gestandenen Managers, den wir fragten, ob er wirklich daran glaubt, was er da machen lässt: Die Antwort lautete „Ich muss es versuchen; ich habe keinen, der allein ein Fachkonzept ordentlich schreiben kann…“ Da ist auch dem hiesigen Autor nichts mehr eingefallen, denn er wusste, dass er mit dieser Einschätzung leider Recht hatte.

Damit wechseln wir die Seite der Diskussion und wenden uns dem auch immer besonderen Verhältnis von Entwicklern und IT-Betriebs-Experten zu:

Variante B1 „Entwicklung bestimmt Technik“ im obigen Bild ist analog A1; hier sagt die Entwicklungseinheit, welche Middleware sie nutzen will und was damit für Implikationen auf die Hardware verbunden sind. „Die Betriebsmenschen sollen die Software aufspielen, sich um ihre Kisten, Kühlung und Strom im RZ kümmern. That´s it.“

Variante B2 „IT-Betrieb bestimmt Standard“ – kommt aus der Sichtweise des Betriebs: „Entwickler? Die machen immer alles durcheinander“… Hier also legt der IT-Betrieb rigoros Technologie-Standards fest, die bis weit in hohe Regionen der typischen Schichtenmodelle reichen und die damit die Entwickler einschränken mit Software, die sie gern „deployed“ hätten (und die ggf. nicht zur Standard-Hardware oder der aktuellen Betriebssystem-Version et al. passt). „Angepasst werden die Standards nur widerwillig, oder wenn der Betrieb gern Neues hätte“ (sagen dann die Entwickler und andere interessierte Gruppen kritisch zu diesem Modell und der aus ihrer subjektiven Sicht typischen Einstellung des Betriebs dabei).

Variante B3 „(Kuschel) DevOPs“ – Wie oben bei A3 (“reines Scrum“): Entwickler und IT-Betriebler sollen „näher zusammenarbeiten, netter zueinander sein und gemeinsam agiler werden“… „Trotz all ihrer divergierenden Interessen (Dynamik versus Stabilität und Ordnung, die für einen effizienten Betrieb nun einmal wichtig sind)?“ – fragt der Autor hier die Vertreter dieses Modells. Außerdem gilt seines Erachtens: „Wie wahrscheinlich ist es wohl, dass zwei Spielkinder zusammen versuchen, Kosten zu senken, wenn man sie mit Geld in einen Spielzeugladen lässt…“ Seine Antwort lautet also: Alle drei Varianten in diesem Teilthema sind leider wohl nur selten erfolgreich im Ziel der Zeit-& Kostenminimierung.

Eine wirklich gute allgemeingültige Lösung haben wir bisher also noch nicht gefunden, so das Zwischenfazit. Versuchen wir es daher noch mit einem weiteren Satz an Möglichkeiten:

Intermediär-Varianten der Zusammenarbeit im Softwareentwicklungsprojekt von „Auftraggeber“/ „Fachbereich“, „Entwicklung“, „Betrieb“ und „Projektleitung”

Diese Ansätze basieren auf der Idee, dass man eine eigens dafür ausgestattete Gruppen von Menschen in der Organisation vorhält, die:

1. Intellektuell dazu in der Lage sind, erstklassige, konsistente und dabei auch erstklassig pragmatische Fachkonzepte (mit Fachdatenmodell und Testfallbeispiel/ -strukturen) zu schreiben,

2. So viel von der Technik verstehen, dass sie beurteilen können, welche der Middle-/ Hardware- et al Komponenten wohl zu ihrem Thema passen („aus-reichend passen“ ist das Kriterium, wenn Geld und Zeit knapp erscheinen),

3. und das Projekt planen und steuern können durch alle Untiefen des Alltags.

Dahinter steckt natürlich die Einstellung, dass Fachbereiche, Entwickler und IT- Betrieb weder einzeln noch (ungesteuert) zusammen in der Lage sind, das Projekt funktional richtig/ angemessen („in Function“), in minimierter Zeit („in Time“) und mit minimiertem Geld („in Budget“) abzuliefern, sondern dass dies vielmehr eine Aufgabe für Spezialisten ist.

D. h. im Übrigen nicht, dass Fachbereich, Entwicklungsmannschaft und IT Betrieb – insb. bei sehr großen Projekten – dann nicht auch jeweilig eine eigene Führungsmannschaft für ihre Projektteile einsetzen (dies ist vielmehr ein ergänzendes Muss, wenn man z. B. viele Anwendungen in einem regulatorischen Großprojekt anpasst oder neu baut und entsprechend viele Menschen mitwirken).

Es gilt dann aber: Der Projektleiter und das Projekt Office kommen aus einer Spezialeinheit. Sie schreiben das Fachkonzept auf dem Top-Level (damit die Teile zusammenpassen und von Anfang der Rahmen vollständig klar und befüllt ist); sie koordinieren im mindestens (wenn sie es nicht selbst machen) dann die Detailausgestaltung der Use Cases (um die Konsistenz zu bewahren – d. h. sie lesen die Details auch und diskutieren mit resp. intervenieren, wenn z. B. zu viel technologische Innovation erwarten lässt, dass „in Time/ Function/ Budget“ ggf. gefährdet würden oder zu sehr abgewichen wird vom Gesamtkonzept, so dass andere Projektteile dann umdisponieren müssten).

Sie kümmern sich um die Gesamt-Schätzung aller Aufwände – hier ist es ihre Aufgabe (und Sendungsbewusstsein, wenn es die richtigen sind), den kleinstmöglichen Zustand herbeizuführen, der „gerade mal so reicht“ (und die Einhaltung der Ziele sicherzustellen, wenn sie erst einmal verabschiedet wurden). Sie halten den/ die Auftraggeber „bei Laune“, „bekämpfen“ jedweden Versuch, den Scope zu ändern und liefern am Ende „getestet auf dem Hof“ (sprich in der Produktion) ab.

Dies ist inhaltlich deutlich mehr als ein rein „formaler Projektoffice-Job“. Hier sind dann „Change Requests in größerem Stil (intellektuelle) Schande“,  „Nur Projekte <in Function> aber <under Budget and Time> wirklich erstklassige Projekte“ und grundsätzlich „nur fertige Projekte gute Projekte“… Das ist ein anderes Selbstverständnis und setzt andere „Skills“ voraus (im Sinne des Rollenmodells „harte“ und/ oder erstklassig-erfahrene „politische Projektleiter).

„Das ist ja alles schön, aber damit haben wir das Problem, dass es nur ganz wenig Menschen gibt, die dies wirklich können, nicht wirklich gelöst“ sagen die Kritiker. „Wir haben diese seltenen Ressourcen zumindest gebündelt und ihnen das gegeben, was sie meist dann auch lieben, nämlich Macht!“ antworteten die Befürworter. Dies hängt letztlich aber natürlich davon ab, wo und wie man die <Spezialeinheit> ansiedelt in der Aufbauorganisation. Die Subvarianten sind:

C1 Eine spezielle (meist als „COO“ Einheit benannte) Stabstelle in jedem Fachbereich einzeln,

C2 Ein „Consulting/ Projektmanagement-Team“ in z.B. der IT direkt unter dem Top-Management dort,

C3 Ein separater („COO“/ oder „Consulting-„) Bereich gleichberechtigt zu den anderen unter dem Vorstand direkt.

Die Meinung des Autors lautet: C1 und C2 sind besser als die vorstehenden Varianten; C3 ist theoretisch sicher die ideale Lösung (insb. für „harte Zeiten“). Allerdings darf man keine Wunder erwarten: Ist die (kleine) Einheit richtig gut, wird sie sich (außer beim Top Management) ganz wenig Freunde machen, denn sie gewinnt schnell an Macht, führt jedes (insb. erfolgreich minimierte) Projekt dazu, dass irgendwer aus IT und/ oder Fachbereichen verärgert wird, weil er das, was er wollte, nicht bekommen hat, hohen Druck ertragen musste etc. C3 ist umgekehrt kein Job für Menschen, die gern „nett sein wollen/ viele Freunde haben möchten“ – sind die Player es nicht, wird ggf. sogar das Top Management „weich“ bei Beschwerden zu „Stilfragen“; das wiederum schwächt die C3 Player im nächsten Projekt und/ oder verärgert sie – was auch selten hilfreich sein dürfte.

Damit wären wir am Ende? Noch nicht ganz – es bleiben noch die anderen Aktoren aus dem Rollenmodell im Projektumfeld, deren Interessen zu beachten sind:

Betreuung der sonstigen Aktoren im Projektumfeld

Die IT-Sicherheits (et al-) „Beauftragten“ sind heute – dank BaFin bei Banken zumindest – alle „unabhängig“ (mit genügend Geld ausgestattet, als „Alien- resp. Blockwart-Stellen“ wie Kritiker sagen) im Unternehmen platziert.⁶ Auf keinen Fall darf man sie ignorieren. Aus Projektsicht sagt man – so der hiesige Vorschlag – klassisch „jaja“ und setzt ein Nachwuchstalent (intern oder von einem befreundeten Berater) darauf an, die geforderten Templates zu befüllen und weist aus Prinzip die Kosten dafür in jeder Lenkungsausschuss-Präsentation separat/ in Großbuchstaben aus. Stellen sie tatsächlich inhaltliche Anforderungen, die jenseits der (subjektiven Projekt-) Vernunft Geld/ Zeit kosten würden, gilt das Gleiche: Ausweisen, ironisch kommentieren und abwarten, ob der/ die nervösen Auftraggeber diese erfüllen wollen oder nicht.

IT-Architekten kann man hingegen meist ignorieren; außer sie versuchen, das „eigene“ Projekt (aus Sicht der Projektleitung/ des Auftraggebers)  zu einem Einsatzgebiet (als Pilot) für ihre neusten Standardisierungsideen zu erklären und man will als Auftraggeber/ Projektleiter dies auf keinen Fall, weil es Geld/ Zeit kosten wird oder gar so viel Komplexität anliefert, dass die Erreichung des Projektziels überhaupt unsicher(er) erscheint. Da gilt es dann „politisch zu agieren und die Architekten auf diesem Weg auszuschalten“. Zur Meinung: „Vielleicht haben sie ja gute Ideen, manches kann man auch mal ausprobieren und so vielleicht auch die Techniker im Projekt glücklich(er) zu machen“ sagen zynische Projektmanager“: „Ja, aber nur, wenn es nicht den <Flow> stört. Sollen sie doch in ihrer Freizeit glücklich werden!“

Die Revision – ist Schicksal, kommt bei (insb. Groß-) Projekten wenn alles fertig ist, und sucht formal nach Fehlern; darauf sollte man als gute Projektleitung vorbereitet sein, keine groben Fehler machen (z.B. komplett fehlende Dokumentationen, die vorgeschrieben sind, keine unbeweisbaren Entscheidungen zu Kernfragen) und sich nicht ärgern, wenn es dann heißt: „Ja, war mit Einschränkungen schon ganz ok…“

IT-Controller – kann man ignorieren, wenn man als Projektleiter Geld für wichtig hält und sich intensiv darum kümmert (siehe oben in den C-Modellen); für Techniker (mit wenig Sendungsbewusstsein hier) sind sie nicht selten gar Gegner vor dem Management, wenn es <schlecht läuft>. Zu diesem Problem sagt der Autor nur: „Was uns wieder einmal beweist, keine reinen Techniker als Projektleiter kritischer IT-Großprojekte einzusetzen“.

Hard- & Software Hersteller – Sind bekanntlich der natürliche Feind aller Menschen, die die IT-Kosten senken (oder halten) wollen; muss sich das IT-Linien-Management kümmern, dass sie keinen Einfluss im Projekt gewinnen. Im Grenzfall muss man als Projektleiter ganz früh im Verlauf strikt den Einsatz neuer Technologien ablehnen oder mit sehr viel Aufmerksamkeit sehr streng managen.

IT-Berater – Sind in einem Projekt entweder in der Fachkonzeption oder aber der Entwicklung einsetzbar, wenn die eigenen Kompetenzen quantitativ oder qualitativ nicht ausreichen. Sie erinnern sich: „Drei sind meist schon zwei zu viel“ – denn sie mögen sich untereinander selten bis gar nicht, haben eigene Methodenvorstellungen, die nicht mit den eigenen Revisions-/ IT-Standards übereinstimmen, haben einen anderen „Rhythmus“ als die eigenen Entwickler… Reichen die eigenen Kompetenzen qualitativ nicht, sollte man sich daher überlegen, ob man nicht größere Teile an einen einzigen Berater gibt, um die Kommunikations-Schnittstellen im Projekt zu minimieren. Dieser darf dann aber kein übersteigertes Selbstwertgefühl/ Sendungsbewusstsein haben, denn dann bekommt man als Projektleitung/ Auftraggeber auch selten das, was man möchte in „Time, Function & Budget“.

Und nur das zählt am Ende. Aber dies ist natürlich auch eine spezielle subjektive Meinung und nicht mehr.Dr. Peter Bohnenkamp