51 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 03/ 2021 DOI 10.24053/ PM-2021-0052 Begutachtung von EDV-Projekten Jürgen Reinke Für eilige Leser | Immer wieder hört oder liest man, dass Einführungs- oder Umstrukturierungsprojekte in der Informationstechnik scheitern oder in Zeit und Budget weit über das hinausgehen, was seinerzeit geplant war. Lag es am fehlenden oder falschen Projektmanagementansatz? Wurde die falsche Steuerungsmethodik gewählt? Hat man die Komplexität unter- und die Kompetenz der Beteiligten überschätzt? Oder lag es einfach daran, dass die ‚Stakeholder‘ nicht mitgezogen haben? Im Zuge einer Gutachtenerstellung wird der Sachverständige aufgefordert, zu diesen Fragen Stellung zu nehmen. Entsprechende Ansätze stellt der Autor in dem folgenden Beitrag vor. Schlagwörter | EDV-Projekt, SAP-Projekt, Gutachten, Ressourcenplanung, Normen, Kosten, Standards, Kommunikation, Systemische Projektsicht 1 Projekte aus der Sicht des Sachverständigen Als Sachverständiger der Fachgruppe Informationstechnik wird man i. d. R. erst herangezogen, wenn die ausgeführte Arbeit zur erheblichen Unzufriedenheit des Auftraggebers oder -nehmers ausgeführt wurde oder- - volkstümlich ausgedrückt- - „ das Kind in den Brunnen gefallen ist “. Die Unzufriedenheiten in der Ausführung können technischer (z. B. unzureichende System- oder Programmleistung) oder organisatorischer (schlechtes Projektmanagement, unzureichende Kompetenz oder Widerstände bei den Mitarbeitern) Natur sein. Die typische Situation ist, dass die Kosten davonlaufen und weit und breit noch kein definiertes Ende zu sehen ist. Die Projektleitung steht dann vor folgendem Dilemma: • Der ‚Sprint‘ im Projekt muss aufrechterhalten werden, damit die Projektpartner mit der notwendigen Energie (weiter) am Projekt arbeiten. • Die i. d. R. sich widersprechenden Aussagen der Projektpartner (Eigene Mitarbeiter: „ Es läuft gar nichts! “ vs. externer Projektpartner: „ Wir stehen kurz vor Produktivsetzung! “) müssen verifiziert und abgeglichen werden. • Die Kosten bzw. die weitere Finanzierung des Projektes müssen glaubhaft budgetiert und gegenüber ‚Sponsoren‘ dargelegt und von diesen genehmigt werden. • U. U. muss ein ‚Eskalationsmanagement‘ bzw. ‚Task-Force‘ gebildet werden, um nicht mit den bisherigen Strukturen weiterzuarbeiten. • U. U. muss sogar ein Abbruch des Projektes in Erwägung gezogen werden mit den daraus resultierenden rechtlichen und organisatorischen Folgen. Nicht zuletzt wird der Sachverständige aufgefordert, eine Begutachtung darüber zu abzugeben, „ wer denn nun schuld sei“. 2 Vorgehensweise des Sachverständigen 2.1 Umfeld des Sachverständigen Ein Sachverständiger baut sein Gutachten im Wesentlichen auf drei Säulen auf: • Gesetzliche Grundlagen, deren Nichteinhaltung oder -beachtung ‚automatisch‘ einen Rechtsmangel darstellt; • Normen und Standards, deren Einhaltung zwar nicht zwingend vorgeschrieben ist, aber einen Handlungsmaßstab bilden können, nach dem eine Leistung bewertet werden kann; • persönliche Erfahrung, aufgrund derer der Untersuchungsgegenstand weitgehend objektiv nach den Regeln der Wissenschaft oder des Gewerbes zu beurteilen ist. Unter Beachtung dieser drei Säulen hat der Sachverständige ein Gutachten zu erstellen, das nachvollziehbar und objektiv zu sein hat. Da ein Gutachten i. d. R. zugunsten eines Kontrahenten ausfällt, muss sich der Sachverständige auf die ‚Gegenwehr‘ (i. d. R. durch gegnerische Rechtsanwälte) einstellen, die versuchen, sein Gutachten zu ‚zerpflücken‘. Wissen Begutachtung von EDV-Projekten DOI 10.24053/ PM-2021-0052 32. Jahrgang · 03/ 2021 Wissen | Begutachtung von EDV-Projekten 52 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 03/ 2021 DOI 10.24053/ PM-2021-0052 So kommt es vor, dass ein von der Gegenseite beauftragter Sachverständiger aufgrund der gleichen Säulen genau das Gegenteil beweisen will. 2.1.1 Normenumfeld Dem IT-Sachverständigen stehen im Bereich Projektmanagement einige Normen (z. B. DIN 69 900-69 909-2, DIN ISO 21 500) zur Verfügung. Diese Normen sind aber in der Projektmanagement(PM)-Ausbildung kaum Schulungsinhalt. Ebenso spielen diese Normen in der praktischen Tätigkeit eines Projektmanagers kaum eine Rolle- - ja sind diesem meistens nicht einmal bekannt. Allein die Nichtanwendung von Normen bedeutet aber noch kein schlechtes Projektmanagement. 2.1.2 Rechtliches Umfeld In der Regel wird ein IT-Sachverständiger von einem Auftragnehmer/ -geber oder von einem Gericht herangezogen, um einen allfälligen Mangel und der daraus resultierenden Weigerung auf Bezahlung einer Leistung , Anspruch auf Rückabwicklung eines (Teil-)Auftrages (Wandlung) oder Zubilligung eines Schadenersatzes (z. B. bei Projektverzögerungen oder -abbruch) zu bewerten. Die typischen Fragestellungen bezüglich strittiger Leistungen beim Projektmanagement sind: • Ist das Projektmanagement auf beiden Seiten ziel- und sachorientiert durchgeführt worden? • Welche Ursachen könnten zu dem problematischen Projektverlauf beigetragen haben und wem ist eine Verantwortung zuzuweisen? Dazu muss bemerkt werden, dass die Leistung Projektmanagement i. d. R. niemals allein Gegenstand eines Gutachtens sind. Meistens geht es auch um Fragen der Programmqualität, Budgettreue, Qualitätsmanagement, Technische Realisierung u. w. In diesem Artikel soll aber isoliert die Aufnahme und Bewertung der Leistung Projektmanagement betrachtet werden. Eine umfassende Abhandlung der rechtlichen Beurteilung einer Leistung Projektmanagement würde ein eigenes Thema für einen Fachbeitrag füllen. In diesem Beitrag soll dieses Thema deshalb nur mit einigen kurzen Punkten besprochen werden. Juristen (und auch IT-Fachleute in ihrer Eigenschaft als Sachverständige ) haben die Gegenstände ihrer Untersuchung nach folgender ‚Hierarchie‘ zu bewerten: 1. Welche vertraglichen Vereinbarungen sind getroffen worden? • Werkverträge schulden den Erfolg eines Projektes. Das bedeutet, es müssen nicht nur die unter den folgenden Punkten 2. und 3. genannten Kriterien bei der Realisierung erfüllt sein. Es muss der Erfolg garantiert werden. In einem konkreten EDV-Projekt muss also die Anwendung zur Zufriedenheit des Auftragnehmers laufen. • Dienstleistungsverträge schulden das redliche Bemühen des Aufragnehmers, die bedungene Leistung ordnungsgemäß zu erbringen. Ob das Projekt letztlich erfolgreich ist, ist nicht relevant. In einem EDV-Projekt muss also lediglich die Dienstleitung (z. B. eine Programmierung) ‚handwerklich‘ nach den im folgenden Punkt 3. genannten Kriterien erbracht werden. • Bei einem Dienst- oder Arbeitsvertrag ist die Situation wieder eine ganz andere, da hier arbeitsrechtliche Punkte wie Befolgung von Dienstanweisungen , Treueverhältnis , Aufsichtspflichten etc. eine Rolle spielen. 2. Welche konkreten Arbeitsvorgaben sind vertraglich vereinbart worden? • Ist die Anwendung von Normen oder weitgehend anerkannten Methoden (z. B. Vorgehensweise nach Critical Chain CCPM, PMI , PMBOK , SAP -Phasenmodell oder DIN 69 900, ISO 21 500) vereinbart worden? • Ist die Erfüllung konkreter Teilaufgaben anhand von Milestones an die weiteren Aufgabenschritte gebunden (Teil-Abnahme)? Abbildung 1: Zusammenhang zwischen MA-Zahl und Produktivität. (Eigene Darstellung) Wissen | Begutachtung von EDV-Projekten 53 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 03/ 2021 DOI 10.24053/ PM-2021-0052 3. Entspricht die Leistung folgenden Kriterien? • den anerkannten Regeln der Technik. • dem Stand der Technik . • dem Stand von Wissenschaft und Technik. • den Verkehrssitten. • den Gebräuchen im Geschäftsverkehr . Nehmen wir folgende vertragliche Konstellation an: Es ist ein Werkvertrag zur Einführung eines kompletten EDV-Systems (z. B. für Auftragsabwicklung, Produktion und Rechnungswesen ) mit einem IT-Dienstleister vereinbart worden. Die konkrete Anwendung eines bestimmten Projektmanagementmodells ist nicht vereinbart worden. Eine in solchen Fällen übliche Formulierung lautet: „ Der Auftragnehmer übernimmt eigenverantwortlich sämtliche Arbeiten und Leistungen, die für die erfolgreiche und zeitgerechte Implementierung des vertragsgegenständlichen SAP -Systems erforderlich sind.“ Aus einer solchen Formulierung ist unschwer zu ermitteln, dass dazu auch ein adäquates Projektmanagement gehört. Es sei denn, es handelt sich bei dem Auftraggeber um ein Ein- Personen-Unternehmen, was bei der Einführung z. B. eines SAP-Systems i. d. R. nicht anzunehmen ist. Bezüglich der o. g. Punkte schuldet der Dienstleister gem. Nr. 1. den Erfolg . Zu 2. gibt es keine konkreten Vereinbarungen. Insofern ist er frei bzgl. Normen und Standards. Im Grunde muss er nicht einmal nachweisen, nach irgendwelchen Normen oder Standards gearbeitet zu haben. Die Einhaltung der Kriterien zu Punkt 3 werden von ihm im Rahmen seiner Sorgfaltspflicht als ordentlicher Kaufmann erwartet. Wenn nun das Projekt ‚in Schieflage‘ gerät, geht der Sachverständige an die Aufgabe heran. Die zentrale Frage ist: Ist die Projektplanung und- - durchführung dem Projektauftrag angemessen, nachvollziehbar und schlüssig? 2.2 Untersuchungsgegenstände Soll der ‚Erfolg‘ eines Projektes untersucht werden, gehören folgende Untersuchungsgegenstände dazu: • Welche Projektpartner mit welchen Aufgaben waren / sind involviert? • Welche Annahmen sind hinsichtlich der vertraglichen Grundlagen vorauszusetzen (s. o.)? • Sind Anforderungen und deren Realisierung adäquat priorisiert worden? • Wie waren / sind die jeweils aktuellen Stände des Budgetverbrauchs in Abstimmung mit dem Fertigstellungsgrad? • Wie viele und welche (insbesondere personellen) Ressourcen waren / sind im Projekt involviert? Abbildung 2: Nachträgliche Feststellung des MA-Einsatzes im Projektlauf-- getrennt nach Funktionsprofilen. (Eigene Darstellung) Abbildung 3: Feststellung der prozentualen Aufteilung der Ressourcen während des Projektlaufes-- ungünstiger Verlauf. (Eigene Darstellung) Wissen | Begutachtung von EDV-Projekten 54 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 03/ 2021 DOI 10.24053/ PM-2021-0052 • Welche Instrumente standen / stehen für Ressourcensteuerung und Qualitätsprüfung zur Verfügung? • Wie lief / läuft die Kommunikation im Projekt? 2.2.1 Projektpartner Nicht selten sind in großen EDV-Projekten interne und externe Projektpartner in zweistelliger Anzahl mit entsprechend vielen Mitarbeitern vertreten. Häufig passiert es, dass sich Projektpartner gegenseitig die Verantwortung für bestimmte Projektteile zuschieben. Wer ist z. B. für die Vorbereitungen zur Migration in einem System verantwortlich? Hier gilt es-- leider oft erst im Nachhinein-- zu klären, ob und welche Strukturen hinsichtlich Liefern und Empfangen von Informationen notwendig sind bzw. gewesen wären. 2.2.2 Priorisierung von Anforderungen Das Einfordern der Priorisierung von Anforderungen aus einem Pflichten- oder Lastenheft ist eine wesentliche Aufgabe des Projektmanagements. Dabei stellt sich häufig ein ‚ABC-Effekt‘ heraus: Für 80 % aller Anforderungen (A- und B-Aufgaben) werden 60 % der Ressourcen verbraucht. Für die restlichen 20 % (C-Aufgaben) werden noch einmal 40 % der Ressourcen gebraucht. Dabei wird folgendes übersehen: • Die Organisation ist häufig gar nicht reif für bestimmte automatisierte Vorgänge, die früher durch qualifizierte Mitarbeiter für jeden Einzelfall gelöst wurden. • Während der Entwicklung eines (integrierten) EDV-Systems ist dieses ‚unproduktiv‘, verursacht aber hohe Kosten und Kapitalbindung. Ebenso muss das ‚alte‘ System weiter gefahren werden mit entsprechenden Aufwendungen. • Es gelingt ‚findigen‘ Mitarbeitern durch die Definition von immer neuen Anforderungen („ Das muss unbedingt automatisch laufen “), den Termin für den ‚Echtbetrieb‘ immer weiter hinauszuzögern. 2.2.3 Budgetverbrauch Nehmen wir als Beispiel, der Auftraggeber hat für ein Projekt ein Budget von € 1 Mio. reserviert. Ein häufiger Fehler ist, dass das Management erst eingreift, wenn dieses Budget aufgebraucht ist. In einer Analyse des Projektstatus wird festgestellt, dass zwar € 1 Mio. ausgegeben worden ist, jedoch erst ca. 30 % aller vorgesehenen Projektaufgaben erledigt sind. Nehmen wir an, der Auftraggeber ist bereit, noch einmal € 2 Mio. zusätzlich auszugeben, um das Projekt zu 100 % abzuschließen. Nach einer Zeit sind € 3 Mio. ausgegeben-- und das Projekt zu 60 % fertiggestellt. Hier darf der Sachverständige nicht den Grundsatz ‚Augen zu und durch‘ unterstützen. Sofern Listen der (geplanten) Aktivitäten vorliegen (Diese sind oft als ‚Anhänge‘ zu Verträgen vorhanden) gilt es, mit den Mitarbeitern zu definieren, welche Aktivitäten nun wirklich ‚fertig‘ (einschl. Test und Abnahme) sind. Häufig stellt sich dann heraus, dass eine ‚relative‘ Budgetüberschreitung schon viel früher eingetreten ist. 2.2.4 Ressourcen Kein Projekt kommt ohne Ressourcen aus. In Bauprojekten stehen neben personellen auch umfangreiche technische Ressourcen zur Verfügung. In EDV-Projekten braucht man natürlich auch technische Ressourcen (Server, PC-Arbeitsplätze, Netzwerke, Leitungen). Diese sind aber i. d. R. leicht zu beschaffen, zu steuern und zu budgetieren. Die wesentlichen Kostentreiber sind die personellen Ressourcen. Sollte es zu Projektverzögerungen- - meistens kombiniert mit Budgetüberschreitungen- - kommen, gilt oft der Grundsatz „ Einfach mehr Ressourcen… “. Frei nach dem Dreisatz: „ Wenn 10 Aufgaben von 5 Menschen erledigt werden, wie viel werden dann von 15 Menschen erledigt? - = 30 Aufgaben? “ Rechnerisch richtig- - aber trotzdem falsch. Der USamerikanische Informatiker Frederick Phillips Brooks, Jr. [1] stellt fest: „ Der Einsatz zusätzlicher Arbeitskräfte bei bereits verzögerten Softwareprojekten verzögert sie nur noch mehr .“ Durch die Einarbeitung der neuen Mitarbeiter, Kompetenzabgrenzungen und-- nicht zuletzt-- verschiedene individuelle Arbeits- und Herangehensweisen entstehen Verzögerungen, die den erwarteten ‚Sprint‘ zu einem ‚peu á peu‘ werden lassen. Brooks stellt den Zusammenhang von Projektteamgröße und Produktivität dar: Aufgrund des überproportionalen Kommunikationsbedarfes nimmt die Produktivität eines Projektteams degressiv ab. Brooks berechnet nun die maximalen Kommunikationspfade nach der Formel Abbildung 4: Feststellung der prozentualen Aufteilung der Ressourcen während des Projektlaufes-- günstiger Verlauf. (Eigene Darstellung) Wissen | Begutachtung von EDV-Projekten 55 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 03/ 2021 DOI 10.24053/ PM-2021-0052 Komm.-pfade-= Anz. MA x ((Anz. MA - 1 )/ 2 ). Nehmen wir als Beispiel ein Projekt mit 2.000 zu erfüllenden Aufgaben, die (der Einfachheit halber) durchschnittlich jeweils einen Tag dauern. Würde eine Person diese Aufgaben erledigen, bräuchte sie 2.000 Tage, zwei Personen würden 1.000 Tage brauchen usw. Wären durchschnittlich 30 Personen in das Projekt involviert, müsste das Projekt rechnerisch in 67 Tagen abgeschlossen sein und damit eine Produktivität von 100 % sichergestellt sein. Unter Berücksichtigung der o. g. Formel errechnen wir aber eine Projektlaufzeit von 197 Tagen. Also eine Produktivität von 34 % (s.o. Abbildung 1). Nun kann man einwenden, dass ja nicht jeder mit jedem reden muss. In der Praxis zeigt sich aber doch, dass-- insbesondere bei unzureichendem Kommunikationsmanagement-- die Kommunikation nicht in einer produktiven Weise durchgeführt wird. Im Übrigen wird hier noch nicht auf die Qualität der Kommunikation eingegangen. Wir wissen aus dem praktischen Leben nur zu gut, dass es Menschen immer wieder schaffen, stundenlang ‚aneinander vorbeizureden‘. In der Praxis bedeutet das: • Bei der Projektplanung kann es sinnvoll sein, eine längere Laufzeit einzuplanen-- und dafür weniger MA (in Abhängigkeit von erforderlichen Kompetenzen) zu planen. Die Notwendigkeit der Kontinuität der eingesetzten Mitarbeiter sei hier nur der Vollständigkeit halber erwähnt. • Bei einer Eskalation kann es sinnvoller sein kann, den Produktivtermin nach hinten zu verlegen- - und mit dem bestehenden Team weiterzuarbeiten, als-- unkoordiniert-- neue Ressourcen einzubinden. Eine weitere Frage ist, welche Qualität die Ressourcen haben bzw. welche Qualifikationen eingesetzt werden. In meiner ersten Projektleiter-Ausbildung wurde folgende kleine Geschichte zum Besten gegeben: Ein Ruderteam stellt fest, dass in einem Ruderboot ein Ruderer und acht Steuermänner sitzen. Da das Team nicht sonderlich erfolgreich war, suchte man nach einer Lösung. Nach umfangreicher Beratung und Analyse kam man zu folgender Lösung: Den Ruderer mehr motivieren! Dieses kleine Beispiel mag zeigen, dass viele ‚Steuermänner‘ in einem Projekt eher hinderlich sein können. Ebenso ist es unproduktiv, wenn viele ‚Ruderer‘ arbeiten, ohne dass es eine effiziente Steuerung gibt. Wie lautet nun die ‚ideale‘ Zusammensetzung eines solchen Teams? Nun, das kommt darauf an! Auf die jeweilige Projektphase. Dazu kann man ein Intensitätsraster erstellen, das eine ‚Ausgewogenheit‘ der eingesetzten Profile darstellt. Graphisch ist das in Abbildung 2 dargestellt. Auf der y-Achse sind die jeweiligen Einsatztage in dem Quartal dargestellt. Deutlich sind hier ‚Dellen‘ in den Quartalen I und II / 2015 zu erkennen. Durch einen Wechsel in der Projektleitung war das Projekt kurzzeitig ‚führungslos‘. Trotzdem wurden die ‚ausführenden‘ Kräfte aufgestockt, um das Projekt voranzubringen. In Zusammenhang mit den vorhergehenden Ausführungen zur Produktivität kann man sich vorstellen. wie ‚chaotisch‘ das Projekt in dieser Zeit lief. Durch den massiven Einsatz des (neuen) Projektleiters in den Quartalen III und IV / 2015 konnte das Projekt jedoch nicht mehr ‚gerettet‘ werden. Ende 2015 wurde das Projekt gestoppt-- und der Sachverständige nahm seine Arbeit auf. Das Intensitätsraster kann auch in einer weiteren Hinsicht genutzt werden. Gerade bei SAP-Projekten werden i. d. R. externe Beratungen hinzugezogen, die nicht nur beraten , sondern auch realisieren. Hier stellt sich die Frage der Ausgewogenheit zwischen externen und internen Ressourcen. Bezüglich dieser Konstellationen sind folgende Phänomene zu beobachten: • Die externen Ressourcen sind überproportional vertreten und ‚interpretieren‘ die Wünsche des Kunden und realisieren an den wirklichen Anforderungen vorbei. • Die internen Anwender richten ihre Wünsche direkt an die jeweils realisierenden Berater ohne eine Abstimmung mit der Projektbzw. Geschäftsleitung. Hier sei der Hinweis gestattet, dass es grundsätzlich sinnvoll ist, wenn realisierende Berater (z. B. Programmierer) direkt mit Anwendern zusammenarbeiten, um hier ‚kurze Wege‘ zu finden. Die grundsätzliche Entscheidung, ob eine Anforderung realisiert werden soll, muss jedoch von den jeweiligen Steuerungsebenen herbeigeführt und beauftragt werden. • Beratungsunternehmen neigen dazu, ihre z. Zt. ‚arbeitslosen‘ oder noch in Ausbildung befindlichen Berater Abbildung 5: Systemwürfel gemäß Liebelt Wissen | Begutachtung von EDV-Projekten 56 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 03/ 2021 DOI 10.24053/ PM-2021-0052 in laufende Projekte ‚zu drücken‘, um diese wirtschaftlich zu nutzen. Ebenso kommt es häufig vor, dass hochqualifizierte bzw. gefragte Berater ‚aus dem Projekt gezogen‘ werden, um sie in anderen Projekten einzusetzen. • Auftraggeber neigen dazu, sich von der Beauftragung eines Beratungsunternehmens eine ‚schlüsselfertige‘ Lösung zu erhoffen. Die Notwendigkeit der Mitarbeit der eigenen MA wird unterschätzt und oft nicht entsprechend geplant. Von den eigenen MA wird erwartet, dass sie die Mitarbeit am Projekt neben ihrer normalen Tätigkeit erledigen. Wenn auch nicht alle Ereignisse in der Zusammenarbeit zwischen internen und externen Ressourcen rechnerisch analysiert werden können, gibt es aus der Erfahrung einige ‚Größenordnungen‘ in welchem Verhältnis interne und externe Ressourcen zusammengesetzt sein sollten. Einen eher ungünstigen Verlauf sieht man in Abbildung 3. Die Intensität des Projektverlaufes zeigt die blaue Linie. Die Linie zeigt die üblichen Projektverläufe. Zur Erläuterung des Beispiels: Wenn ein Projekt 10 Quartale läuft, würden sich linear pro Quartal 10 % an Aktivitäten ergeben. Das ist jedoch nicht praxisorientiert. In den ersten drei Quartalen pendeln die Aktivitäten zwischen 6 % und 12 %. In den folgenden Phasen der Realisierung steigt die Intensität von ca. 7 % bis ca. 15 %. Die höchste Intensität sollte bei Test, Integration des alten Systems und Produktivsetzung vorhanden sein. Alle Prozentwerte der Projektkurve ergeben 100 %. Die Einsätze der externen und internen Mitarbeiter sollten sinnvollerweise der Projektlinie folgen. Das Beispiel zeigt folgende Eigenschaften: • Zum Anfang waren zu viel externe Ressourcen eingebunden, die bereits einen großen Teil des Budgets verbraucht haben. • In der Realisierungsphase waren (wohl noch zu früh) zu viele interne Ressourcen gebunden, die zu diesem Zeitpunkt noch nicht voll produktiv für das Projekt arbeiten konnten. Die realisierten Objekte waren noch nicht so weit, um von den Anwendern getestet, bewertet und abgenommen zu werden. • Aufgrund der hohen Belastung oder anderer Faktoren (z. B. Ausscheiden entscheidender Mitarbeiter) ‚sackt‘ die Kurve ab, so dass die notwendigen Aktivitäten in den Abschlussphasen (Test, Integration, Prod.-setzung) von externen Ressourcen wahrgenommen wurden. Eine ideale oder zumindest optimale Kurve sollte einen Verlauf nehmen wie in Abbildung 4, die sich durch folgende Eigenschaften auszeichnet: • Zum Anfang sind hohe interne Ressourcen eingebunden, um das Projekt aufzusetzen und die notwendigen Informationen für das Design bereitzustellen. Als externe Ressourcen sind primär die Solution-Architects eingebunden, also die externen Berater, die das Geschäft des Auftraggebers verstehen müssen und Konzepte erarbeiten. • In der Realisierung stehen hohe externe Ressourcen (z. B. für Programmierung und Customizing) zur Verfügung. Für Abstimmprozesse müssen natürlich auch entsprechende interne Ressourcen zur Verfügung stehen. • In der Abschlussphase (Test, Integration, Produktivsetzung) sollten interne und externe (nach Bedarf) Ressourcen zur Verfügung stehen, um den Abnahmeprozess entsprechend zu unterstützen. Die externen Ressourcen sollten vornehmlich aus Solution-Architects bzw. Senior Consultants bestehen. Diese geben den Bereinigungsbedarf an die Programmierer oder Customizer weiter. 2.2.5 Systemische Projektsicht Die vorgenannten Mengenrelationen zeigen nur den quantitativen Aspekt einer Projektentwicklung. Eine weitere Sicht sollte auf die qualitativen Aspekte eines Projektes gelegt werden. Bruno Jenny [2] liefert dazu einen interessanten Ansatz. In Form eines Systemwürfels [3] stellt er die verschiedenen Aspekte einer qualitativen Betrachtung des Projektverlaufes dar. Die Aspekte Beziehungen (Organisation), Abbildung 6: Beispiel einer ‚humanen‘ Projektentwicklung für ein-- zumindest was die Projektmanagement- Parameter betrifft-- erfolgreiches Projekt. (Eigene Darstellung, in Anlehnung an Liebelt [3]) Wissen | Begutachtung von EDV-Projekten 57 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 03/ 2021 DOI 10.24053/ PM-2021-0052 Elemente (Aufgaben) und Dimensionen (Umfeld) stellt er in einem dreidimensionalen Zusammenhang. (s. Abbildung 5) Die Darstellung in diesem Würfel wird vom Sachverständigen dahingehend erweitert, dass die ‚Erfüllungsgrade‘ entsprechend visualisiert werden. Ein Beispiel für einen ‚humanen‘ Projektverlauf zeigt Abbildung 6. Einige Bereiche sind zwar im ‚roten Bereich‘ gelandet. Dies ist aber nicht ungewöhnlich. Insgesamt kann das Projekt als (organisatorisch) erfolgreich angesehen werden. Natürlich kann man noch nicht vollständig von einem ‚erfolgreichen‘ Projekt sprechen. Die Ergebnisse des ‚Würfels‘ sagen nur aus, dass das Projekt bezüglich der Projektmanagement-Parameter erfolgreich war. Ob die Ziele inhaltlich vollständig (bzw. zur Zufriedenheit der Auftraggeber) erreicht wurden, kann man ggf. darstellen, indem man den Würfel entsprechend adaptiert und z. B. die Aspekte Funktionen , Integration und Ergonomie mit den entsprechenden Ausprägungen (z. B. Aspekt: Funktionen mit den Ausprägungen Rechnungseingang, Rechnungsausgang, Buchhaltung, Controlling) erfasst. Ein anderes Beispiel zeigt Abbildung 7. Hier hat sich das Projekt im letzten Drittel chaotisch entwickelt. Alle Komponenten sind im roten Bereich gelandet. Dass das Projekt inhaltlich erfolgreich war, ist zwar nicht ganz ausgeschlossen, aber eher unwahrscheinlich. 3 Conclusio Wird ein Sachverständiger mit einem Gutachten zu einem Projektverlauf beauftragt, wird er zunächst eine weitgehende Befundung vorzunehmen. Das bedeutet: Verträge, Protokolle lesen, Interviews führen und u. a. die vorgestellten Analysen durchzuführen. Dann bewertet er, welche Dinge hätten erkannt und anders gemacht werden müssen, oder welche ‚zumutbar‘ gewesen wären. Dabei ist es grundsätzlich von Vorteil, wenn der jeweilige Projektmanager ein nachvollziehbares und schlüssiges Vorgehen darstellen kann. Ebenso ist es während der Projektlaufzeit immer zielführend, die Kommunikation mit allen Ebenen bezüglich des Projektmanagements aufrechtzuerhalten, also gewissermaßen ‚den Faden gespannt zu halten‘. Auch wenn es selbstverständlich klingt: Die Mitarbeiter müssen ‚mit ins Boot' geholt werden. Das ausgeklügeltste PM-Konzept nützt nichts, wenn es nicht gelebt wird. Und-- zu guter Letzt: Für welches PM-Modell sich der Projektmanager auch immer entscheidet. Der Erfolg kann nie garantiert werden. Dazu hat jedes Projekt zu viele Parameter. Aber das ist eine andere Geschichte. Literatur [1] Fred Brooks , The Mythical Man-Month. Essays on Software Engineering3 (1995), Verlag Addison-Wesley [2] Jenny, Bruno : Projektmanagement in der Wirtschaftsinformatik5 (2001), Verlag vdf Hochschulverlag AG an der ETH Zürich [3] angelehnt an W. Liebelt, M. Sulzberger, Grundlagen der Ablauforganisation (1989) und G. Schmid , Grundlagen der Aufbauorganisation (1985), Verlag Götz Schmidt, Giessen Eingangsabbildung: © iStock.com / DNY59 Jürgen Reinke Jürgen Reinke ist seit 1980 IT-Berater für ERP-Systeme in mittleren und Großunternehmen. Er leitete mehrere Großprojekte in internationalen Versicherungskonzernen wie auch Industrieunternehmen. Seit 2011 ist er Allgemein beeideter und gerichtlich zertifizierter Sachverständiger für Informationstechnik (Fachgebiet Projektmanagement) in Österreich. 5760 Saalfelden, Haid 109 Telefon: 0664 / 150 5 440 eMail: juergen.reinke@reinke.at Internet: www.reinke.at Abbildung 7: Beispiel einer chaotischen Projektentwicklung für ein-- zumindest was die Projektmanagement- Parameter betrifft-- misslungenes Projekt. (Eigene Darstellung, in Anlehnung an Liebelt [3])