Probleme im IT-Projektmanagement

Transkript

1 von Probleme im IT-Projektmanagement WWarum speziell Probleme im IT- Projektmanagement? Aus der Presse und aus Gesprächen im IT-Umfeld ist erkennbar, dass speziell IT-Projekte immer wieder mit den gleichen Schwierigkeiten zu kämpfen haben. Die Problemursachen sind meist deckungsgleich, jedoch hat sich besonders in Großprojekten seit einigen Jahren kaum etwas geändert. Liegt es am Anspruch, liegt es an der Technik oder sind es die Entscheidungsträger und Projektmitarbeiter, die diesen Problemen nicht begegnen können? Was in Bauwesen, Fertigung, Zuliefererindustrie selbstverständlich ist, wird in IT-Projekten nicht mit gleichbedeutender Wertschätzung angewendet. Plankonforme Realisierung, stringente Kosten- und Terminüberwachung mit einer permanenten Kontrolle des Projektfortschritts sowie projektorientierter Einsatz von Material und Ressourcen mit genehmigungspflichtigen Aufwandsleistungen, sind in Branchen, die vom Kunden oder dem zu liefernden Gewerk abhängig sind, selbstverständlich. IT-Projekte sind, bedingt durch den Anspruch an neue Technologien und geschäftlichen Anforderungen komplex und mit Risiken behaftet. Was kann getan werden, um der Problematik zu begegnen? Welche projektspezifischen Situationen könnten die Ursache sein und wie kann die Einführung eines professionellen Projektmanagements Wirkung zeigen? IT-Projekte, die durch die Presse gingen Großprojekte, über die in der Presse zu lesen waren, scheiterten ganz oder teilweise an den üblichen Problemen im IT-Projektmanagement. Trotz Mitwirkung namhafter Firmen der Branche waren die Ergebnisse nicht zufriedenstellend. Alle Projekte hatten einen hohen technischen Anspruch, neue Technologien sollten eingesetzt und mit einem ebenso hohen Anspruch an Methoden und Vorgehensweisen realisiert werden. Doch welche Priorität wurde dem Projektmanagement zugewiesen und wie wurde das Projektmanagement umgesetzt? Um diese Frage zu beantworten, wäre eine umfangreiche Analyse der Projektereignisse notwendig und nur möglich, wenn Projektverlauf und Ereignisse nachvollziehbar wären. Projektname Auftraggeber Produkt Aufwand Status CHEOPS RWE Abrechnung von Leistungen ca. 300 Mannjahre gescheitert der Energiewirt- schaft. Anspruch: Plattformunabhängigkeit, objektorientiertes Design und Realisierung BASIS 3000 Berliner Senat gescheitert Software für die Sozialämter mit rd Anwendern Inpol NEU BKA Fahndungs- und Ermittlungssystem für bundesweiten Einsatz ecrm Unternehmen der New Economiy Internetbasiertes Customer Realtionship Management mit hoher Flexibilität für branchenunabhängigen Einsatz Eine Studie der GEI Aachen aus 97 besagt, dass nur 2 von 100 Softwarelösungen nach der ursprünglichen, ersten Spezifikation eingesetzt werden, nur 3 von 100 Softwarelösungen nach Änderungen eingesetzt werden, 19 von 100 Softwarelösungen ein komplettes Redesign erfahren und 29 von 100 Softwarelösungen niemals produktiv installiert werden. Ein höchst unbefriedigendes Ergebnis, das durchaus verbessert werden kann, wenn die dringend notwendige Priorität des Projektmanage- ments umgesetzt werden würde. unbeziffert, Schätzung 2- stelliger Mio.- Betrag 80 Mio. DM (9 Jahre Entwicklung) unbeziffert, 2 ½ Jahre Entwicklung nach Redesign produktiv gescheitert, Unternehmen insolvent Seite 1

2 von Genannte Gründe aus Studien und Expertenbefragungen der letzten 5 Jahre Die offizielle Aussage von Verantwortlichen aus verschiedenen Problemprojekten war, dass man z.b. einen hohen Erfahrungswert erwirtschaften konnte, die technische Lösung im Vordergrund stand und man künftig auf das Projektmanagement höheren Wert legen wolle. Dazu Ergebnisse aus Studien und Expertenbefragungen (Quellen: Forsa, IFA, CW ): Aussagen von 182 Unternehmensvertretern in der Reihenfolge der Nennungen: - In der Vorbereitungsphase wird geschlampt - Zielsetzung noch unklar, trotzdem Entwicklung - Es wird zu wenig Zeit in die Konzeption investiert - Mangel an kompetenten externen Beratern - Weiterbildungsdefizit bei Kommunikation, Information und Führung Dagegen stehen die Aussagen von direkten Projektverantwortlichen, ebenfalls in der Reihenfolge der Nennungen: - Unklare Anforderungsanalyse - Zeitaufwendige Realisierung - Unklarer Projektauftrag - Fehlende Erfahrung in neuen Vorgehensweisen - Ungünstige Teambesetzung - Fehlendes Projektplanungs- Know-How Stellt man nun noch das Ergebnis einer Expertenbefragung unter 25 IT-Rechtsanwälten und gerichtlich anerkannten IT- Sachverständigen dagegen, so unterscheiden sich die Aussagen von Unternehmensvertretern, Projektleitern und schließlich der letzten Instanz im Falle eines "Worstcase", dem Rechtsfall, nur geringfügig in der Reihenfolge: - Mangelhaftes Projektmanagement und unzureichende Kommunikation mit dem Kunden - Mangelhafte Datensicherung - Unzureichende Spezifikation und Dokumentation der Leistungen - Planungs- und Konzeptionsfehler - Fehlerhafte Programmierung Das Management sagt aus, dass in der Vorbereitungsphase geschlampt wird, Projektleiter sprechen von einer unklaren Anforderungsanalyse. Setzt man die zur Verfügung stehende oder genehmigte Zeit mit den eingesetzten Methoden sowie die verfügbaren Mitarbeiter entgegen, so ist dieses Ergebnis in vielen Fällen obligatorisch. Zielsetzung noch unklar, trotzdem Entwicklung wird vom Management ausgesagt. Die Projektleiter sprechen von einem unklaren Projektauftrag. Wer ist zuständig für die Klärung einer Zielsetzung und die Eindeutigkeit eines Projektauftrags? Ist die Zielsetzung nicht klar, kann es der Projektauftrag auch nicht sein. Beide, Management und Projektleiter wären hier in die Pflicht zu nehmen. Schlussendlich die Aussage des Managements, dass ein Weiterbildungsdefizit bei Kommunikation, Information und Führung besteht. Von Projektleitern wird fehlendes Projektplanungs-Know-How jeweils an letzter Stelle genannt. Im Gegensatz zum Rechtsfall, der Projektmanagement und Kommunikation an erster Stelle beklagt. Eine treffende Situation, denn alle Aussagen beziehen sich direkt auf das Projektmanagement. Ursachen und Folgen Was wird unter dem Begriff "Projektmanagement" verstanden und was wird tatsächlich umgesetzt, ist nach wie vor ein weitreichendes Betätigungsfeld in Unternehmen. Aus der Praxis kann nur bestätigt werden, dass mangelhaftes Projektmanagement, das Vorgehen im Sinne von Planung, Koordination, Kommunikation, Kontrolle und Mitarbeiterführung unzureichend erfolgen. Ziel- und Risikodefinition Entwicklungszyklen für Anwendungssysteme oder die Einführung neuer technische Umgebungen unterliegen immer kürzeren Projektzeiten. Ist die Idee, das Vorhaben erst einmal geboren, werden Zieltermine gesetzt, Erwartungshaltungen kommuniziert, ohne eine Machbarkeit im Sinne der personellen Besetzung, dem dafür notwendigen Skill und schlussendlich dem technischen Anspruch geprüft und geplant zu haben. Seite 2

3 von "Appetit kommt beim Essen!", dieser Ausspruch trifft besonders auf IT-Projekte zu. Aus einer anfänglich überschaubaren Anforderung, der grundlegenden Zieldefinition, wird im Projektverlauf nicht selten erheblich erweiterter Umfang, also eine Überschreibung dieser Zieldefinition. Zeit, Kapazität und Budget bleiben jedoch auf dem Status des Ursprungs oder werden nur geringfügig angepasst. "Unrealistische Zeitvorgabe" ist eine häufig genannte Ursache für diese Probleme. Ziel- und Risikodefinition in Projekten sind die Startaktivitäten und permanente Checkpoints im Projektverlauf. Wird das Ziel verändert, ändern sich die Risiken. Werden Risiken nicht erkannt und beachtet, sind Auswirkungen auf Zeit, Kosten und Qualität unvermeidbar. In einem der genannten Großprojekte tauchte der Begriff "plattformunabhängig" auf. Diese Anforderung wurde bereits zum Zeitpunkt des Projektaufsatzes als zwingend erforderlich aufgenommen. War sie notwendig bzw. was verbarg sich tatsächlich hinter die- ser Anforderung? Technischer hoher Anspruch versus Notwendigkeit für den Einsatz des Produkts sind nicht immer gleichbedeutend. Ein Grund für das Scheitern von IT- Projekten ist nicht selten ein zu hoch gesetzter Anspruch, der mit dem zur Verfügung stehenden Personal, den verfügbaren Kenntnissen und Fähigkeiten (Skill) in der vorgesehenen Zeit, dem vereinbarten Kostenrahmen und der geforderten Qualität nicht umgesetzt werden kann. Personelle Besetzung Ein weiterer Aspekt erweist sich mit Lesen und Hinterfragen einiger typischer Stellenbeschreibungen von Unternehmen, die eine Position des Projektleiters zu besetzen haben. Im Vordergrund steht ein hoher technischer Skill und nebenbei erwähnt die Managementfähigkeit. Muss ein Projektleiter in IT- Projekten tatsächlich über detaillierte technische Kenntnisse wie z.b. mehrere Programmiersprachen, Systemkenntnisse, Kenntnisse in Tools für Design, Entwicklung, Test etc. verfügen? Soll ein Projektleiter die Ergebnisse im technischen Detail prüfen können, soll er selbst an der Entwicklung beteiligt sein oder ist es nicht seine Aufgabe, die Mitarbeiter im Projekt ergebnisorientiert zu steuern, Entscheidungen zu treffen und die Kommunikation mit Management, Fachabteilung oder Kunde aufrecht zu erhalten? Unternehmerisches Denken, straffe Arbeitsmethodik und Fähigkeiten der Mitarbeiterführung sowie Mitarbeitermotivation mit Argumentationsstärke, Auftreten vor Management und Kunden gehören zum Profil eines Projektleiters. Werden diese Eigenschaften vorausgesetzt oder nur erwartet? Eine häufig auftretende kritische Situation in IT-Projekten ist personalbedingt. Mitarbeiter der Fachabteilung und auch der IT werden für ein Projekt aus der Organisation temporär herausgelöst. Hierbei gilt zwar die Vereinbarung, dass diese Mitarbeiter dem Projekt zur Verfügung stehen, Tatsache ist jedoch, dass bei Notwendigkeit die Priorität beim Linienvorgesetzten liegt. Der Projektleiter kann diese Problematik zwar an das Management adressieren, doch die Lösung bleibt meist unbefriedigend, denn Geschäft geht vor Projekt. Mit dem Einsatz externen Ressourcen mit einem geforderten technischen Skill-Profil wird versucht, Engpässe zu überwinden. Mit jedem weiteren Projektmitarbeiter und besonders externen Mitarbeitern wird der Aufwand an Organisation, Kommunikation und Wissenstransfer erhöht. Sind die Voraussetzungen für eine Beschäftigung unternehmensfremder Personen vorhanden, wissen die externen Mitarbeiter wie, was und in welcher Form Ergebnisse kommuniziert werden müssen, sind sie mit dem Vorgehensmodell vertraut und sind sie sich ihrer Verantwortung im Projekt bzw. für das zu liefernde Ergebnis bewusst? Einarbeitungszeit in Tätigkeitsgebiet und Integration in das Projektteam ist nicht kurzfristig. Das Wissen und die Erfahrung mögen vorhanden sein, doch Umsetzung und Integration benötigen wiederum Ressourcen aus dem Projekt. Leider wird auch das unterschätzt bzw. selten beachtet. Die Erwartungshaltung, dass mit dem Einsatz von mehr Personal eine größere Termintreue erreicht wird, wird aus den vorgenannten Gründen kaum erfüllbar sein. Seite 3

4 von Methoden und Verfahren In kaum einer anderen Branche wird soviel über Methoden und Vorgehensmodelle diskutiert wie in der IT- Branche. Umfangreicfhe Dokumentationen zu Vorgehensweisen in anspruchsvoller, nicht selten akademischer Terminologie werden zum Leitfaden für die Projektabwicklung. Welcher Aufwand in Großprojekten durch Lesen, Verstehen und Umsetzen damit produziert wird und ob dieser Aufwand im Verhältnis zur Aufgabe steht, wird bei Verabschiedung dieser Werke selten berücksichtigt. Wird das beschriebene Vorgehen nicht verstanden oder fordert es die Mitarbeiter zu aufwendigen Arbeitsschritten auf, wird es in der Regel nicht befolgt bzw. nur rudimentär. Die Auswirkung stellt sich dann im Rahmen der Qualitätssicherung heraus, wenn die Grundlagen für Analyse, Design und Realisierung nach Vorgehensmodell für die Qualitätssicherung nicht oder nicht aktuell zur Verfügung stehen. Mitarbeiter einer Fachabteilung benötigen die Kenntnis darüber, wie eine fachliche Anforderung als Grundlage für eine Software- Realisierung spezifiziert werden muss. Häufig eingesetzte technische Mitarbeiter aus der Software- Entwicklung dagegen benötigen die Fähigkeit, entsprechende Fragen zu stellen und die Antwort im Sinne einer fachlichen Anforderungsspezifikation zu dokumentieren. Zwei Welten treffen aufeinander, unterschiedliche Terminologie und kommunikative Fähigkeiten beeinflussen das Ergebnis, auch wenn die Methoden dafür schriftlich vorliegen. Methoden und Verfahren müssen im Tagesgeschäft selbstverständlich sein. Neue Methoden und Verfahren müssen verstanden werden und die Tätigkeit der Mitarbeiter unterstützend begleiten, nicht behindern. Ein Beispiel: In einem Projekt wurden wir mit Methoden und Verfahrensweisen für die Geschäftsprozess-Modellierung und Optimierung konfrontiert, die in einem Dokument über 200 Seiten in der Fachterminologie beschrieben waren. Die Prozesse sollten von Mitarbeitern des Fachbereichs mit jeweils einem externen Berater zusammen dokumentiert werden. Während der Umsetzung dieser Aktivitäten stellte sich heraus, dass die Anweisung in Verbindung mit dem eingesetzten Produkt für die Geschäftsprozess-Modellierung nicht umsetzbar, doch zwingende Anforderung der Qualitätssicherung war. Eine Korrektur erfolgte zwar in Teilbereichen, doch erst nach einer Projektlaufzeit von ca. einem Jahr. Der Aufwand für Einarbeitung, Problemerkennung, Korrekturanpassungen betrug ca. 800 Manntage. An der verbalen Ausdrucksweise änderte sich auch danach nichts, die Problemlösung bestand in weiteren Engagements externer Mitarbeiter in der Hoffnung, dass diese mit den Methoden und Verfahren vertraut sind. Ein Aufwand, der auf den Projektfortschritt in Zeit, Ergebnis und Kosten erheblichen Einfluss hatte und durchaus vermeidbar gewesen wäre, hätte man die Zielgruppe und den Zweck der Weiterverwendung dieser Verfahrensanweisung berücksichtigt. Informationsfluss Projekte unterliegen der Dokumentationspflicht, Projektmitarbeiter müssen aktuell informiert werden, Ergebnisse aus Arbeitspaketen werden für die nächsten Schritte benötigt. Ein häufig auftretendes Problem ist die Ablage der aktuellen Dokumente. Nicht alle Unternehmen verfügen über die organisatorischen Bedingungen einer strukturierten und versionierten Dokumentenverwal- tung. Die Projektverantwortlichen nutzen dazu normale Umgebungsbedingungen in Verbindung mit der einge- setzten Standard-Software. Was in der Entwicklung als notwendig und dringend erforderlich installiert wird, die Versionskontrolle für die Programmsourcen, wird für die Grundlage der Entwicklung, die Dokumentation nicht verwendet oder nur selten. Folge davon ist, dass Doppelarbeit entsteht, weil Dokumentationen überholt sind, nicht sofort in aktueller Version gefunden werden oder sich noch im Genehmigungsverfahren der Qualitätssicherung befinden. Auch die Verfügbarkeit von Arbeitsunterlagen ist eine organisatorische Komponente, für die der Projektleiter die Verantwortung trägt. Für alle Projektbeteiligten muss die Vorgehensweise vertraut und selbstverständlich sein. Seite 4

5 von Projektmeetings sind für Informationsaustausch und Statusabgleich notwendig. Werden Projektmeetings jedoch unstrukturiert und ohne Vorbereitung veranstaltet, ist auch dieses Ergebnis unbefriedigend und wenig zweckdienlich. Vom Management werden häufig lange Meetings beklagt. Auch das muss leider bestätigt werden. Nicht nur die dafür aufgewendete Zeit, sondern auch die geladenen Teilnehmer eines Meetings, die teilweise nicht benötigt würden, sind ein Kritikpunkt. Handelt es sich um eine Lösungsentwicklung, um Entscheidungen über weitere Vorgehensweisen oder um den Statusabgleich. Jedes dieser Meetings benötigt eine Vorbereitung, eine Agenda und ein Protokoll mit den dokumentierten Ergebnissen und den Aktivitäten, die vereinbart wurden. Moderation von Meetings im vereinbarten Zeitrahmen, notwendige Vorbereitungen durch die Teilnehmer vor dem Meeting und Verifizierung von Ergebnissen aus den letzten Meetings sind ein Thema der Zusammenarbeit, das im Projektteam selbstverständlich sein muss. Verbale Kommunikation ist notwendig, sie sollte jedoch gezielt und für alle nachvollziehbar sein, deshalb müssen Ergebnisse und nächste vereinbarte Schritte dokumentiert werden, besonders dann, wenn es sich um Vereinbarungen mit Vertragspartnern handelt. Mit laufendem Projektfortschritt rückt diese Pflicht leicht in den Hintergrund, was sich auf die Nachvollziehbarkeit des Projektverlaufs nicht unerheblich auswirkt und zudem ein weiteres Risiko bedeutet. Qualitätssicherung Wo die Qualitätssicherung beginnt und über welche Bereiche eines Projektes sie sich erstreckt, ist sehr individuell. Der theoretische Ansatz ist mit oftmals sehr aufwendiger Dokumentation behaftet. Die Qualität soll gesichert werden, sie soll den Anforderungen aus Zieldefinition und Projektauftrag entsprechen. Jedes Projekt wird mehr oder weniger detailliert dokumentiert. Die Frage des Vorgehens im Rahmen der Qualitätssicherung taucht dann auf, wenn der Zweck und die weitere Verwendung dieser Dokumentation betrachtet wird. Soll eine fachliche Anforderung, also die Grundlage für das Design des Produkts auch als Grundlage für den späteren Test benutzt werden oder dient diese als Nachweis für das realisierte Projekt, den Auftrag? Werden Dokumente, Modelle, Beschreibungen in die Qualitätssicherung einbezogen und wer prüft wie und auf welcher Grundlage die Verwendbarkeit? Verifizieren und prüfen von Anforderungen in Verbindung mit dem Ziel und unter Schätzung von Aufwänden für die nachfolgenden Projektphasen sollte im Vordergrund stehen. Qualitätssicherung bedeutet nicht nur "Test". Oft wird jedoch erst nach einer Realisierung von Teilprojekten damit gestartet oder schlimmstenfalls nach vollständiger Realisierung auf der Basis nicht aktueller Dokumentation. Umfangreiche Nacharbeiten werden notwendig, was sich auf Zeit, Kosten und die Qualität entscheidend auswirkt. Projektplanung und Projektkontrolle Der Einsatz von Werkzeugen für die Planung und Kontrolle von Projekten ist seit dem Einzug von Standard- Software ein weiterer Klagepunkt und eine weitere Ursache für Probleme im Projektmanagement. Ein Beispiel: Werkzeug für die Steuerung in einem Großprojekt! Ein Großprojekt (3-stelliger DM Mio.Betrag) mit 6 Teilprojekten an verschiedenen Standorten und mit ca. 180 Projektmitarbeitern sollte mit einer lokal am Standort der Teilprojekte installierten Access- Applikation und Excel-Stundenlisten kontrolliert werden. Der Aufwand für die jeweiligen Teamleiter konnte mit monatlich 10 bis 15 Stunden für die Kontrolle der Excel-Listen mit anschließender Übernahme in die Access-Applikation beziffert werden. Die Terminplanung erfolgte mit MS Project, jedes Teilprojekt für sich und ohne diverse Regeln für die Planung. Eine Konsolidierung auf das Gesamtprojekt mit der Abbildung von Abhängigkeiten der Teilprojekte war nicht vorgesehen worden. Auswertungen erfolgten manuell mit zweifelhaftem Ergebnis. Damit wurde das Projekt mehr als 2 Jahre verwaltet mit dem Ergebnis, dass eine konsolidierte Soll/Ist- Situation sowie ein nachvollziehbarer Projektverlauf nicht vorhanden war. Seite 5

6 von Damit soll nicht ausgesagt werden, dass ein professionelles Projektmanagement-System alle Probleme im Projekt lösen kann. Kenntnis über die Abläufe, die Arbeitsmethoden im Projekt mimt der Qualifikation für Führung und Managementmethoden sowie die Beurteilungsfähigkeit von angestrebten Lösungen sind die Grundvoraussetzung. Das Werkzeug zur Steuerung, das Projektmanagement-System, kann nur mit einem etablierten Projektmanagement-Prozess und der Disziplin aller Mitarbeiter zur aufgabenorientierten Rückmeldung effektiv eingesetzt werden. Das ist nicht mit einem Seminar für MS Project zu erreichen und MS Project ist nicht das System, das für eine teamorientierte Nutzung für ein unternehmensweites Projektmanagement eingesetzt werden sollte. Leider ist das Verständnis für den Einsatz dieses Planungs-, Kontrollund Steuerungsinstruments nach wie vor nicht ausreichend vorhan- den. Projekte werden zum Selbstläufer Ein Szenario, das besonders in Großprojekten immer wieder auftaucht. Aufgrund unzureichender Kommunikation und unterschiedlichem Wissensstand werden spontane Lösungen entwickelt. Wird das Zeitfenster kleiner, tritt dieser Effekt häufiger auf. Anforderungen aus dem Fachbereich werden ohne Aufwandskalkulation aufgenommen. Meist mit dem Hintergrund, es handle sich nur um eine "kleine" Änderung oder Erweiterung. Die Auswirkungen dieser "kleinen" Änderungen oder Erweiterungen stellen sich erst bei Integration und Test heraus, wenn diese überhaupt getestet werden, da sie meist nicht dokumentiert, sondern auf "Zuruf" implementiert wurden. Technische Lösungsansätze werden umgesetzt, oftmals neben einer konzeptionellen Vorgabe, um ein aktuelles Problem schnell zu lösen. Die Auswirkung zeigt sich dann im Rahmen der Fehlerkorrektur, Wartung oder der nächsten Erweiterung. Meist sind diese sogenannten "Schnellschüsse" ohne jegliche Dokumentation und nur der daran arbeitende Entwickler kennt die Zusammenhänge. Testverfahren werden unter Zeitdruck vorgenommen, meist nur funktionale Tests, der fachliche Qualitätstest erfolgt nach Installation beim Anwender. Wird das Tagesgeschäft beeinflusst, ist das eine sehr kostspielige Variante der Qualitätssicherung. Projekte in Regressverfahren werden mit mangelhafter Unterstützung von Geschäftsabläufen, Überschreitung der vereinbarten Kosten, umständliche Anwendung, nicht Übereinstimmung von Dokumentation und Realisierung etc. eingereicht. Intern in Unternehmen realisierte Projekte werden in diesem Fall nicht selten durch eine Standardlösung ersetzt. In beiden Fällen ist die Vorgehensweise, Umgehung von Verfahren und Anweisungen, mangelnde Kommunikation und die nicht zielorientierte Realisierung Grund dafür, also mangelhaftes Projektmanagement. Mögliche Lösungsansätze Gibt es eine Lösung für Probleme in IT-Projekten oder liegt es an den Umgebungsbedingungen, die sich auch mit einem Lösungsansatz nicht verändern würden? Ein besseres Verständnis mit der daraus resultierenden Umsetzung eines unternehmensweiten Projektmanagements könnte eine Lösung sein. Dazu müssen die Anforderungen an das Projektmanagement von Unternehmensleitung und Projektbeauftragten erarbeitet werden: 1. Was sind die notwendigen und unternehmensspezifischen Anforderungen an das Projektmanagement? 2. Welche Vorgehensweisen sind mit dem Wissen und den Fähigkeiten der Mitarbeiter umsetzbar und wie können diese permanent angewendet werden? 3. Entspricht die Organisation den Anforderungen für eine zügige Projektrealisierung? 4. Welche Kennzahlen werden im Laufe der Projektrealisierung benötigt und wie werden sie weiter verwendet? 5. Gibt es Verfahrensanweisungen, Checklisten sowie eine direkte Unterstützung von Mitarbeitern bei Fragen zu Vorgehen und Abwicklung in Projekten? 6. Mit welchen Werkzeugen sollen die Projekte gesteuert werden? 7. Sind die Kenntnisse und Kapazitäten im Unternehmen vorhanden oder müssen sie erst geschaffen werden? 8. Verfügen die Projektverantwortlichen über die Fähigkeiten, Mitarbeiter zu führen und zielorientiert zu arbeiten? 9. Werden bereits Arbeitsmetho- den im Team angewendet? 10. Können vorhandene Dokumentationen für künftige Projekte herangezogen werden, um das Wissen zu verwenden? Seite 6

7 von Mit diesen Fragen wurde noch kein technischer Anspruch an das IT- Projektmanagement erwähnt, sondern lediglich eine grobe Skizze der Umgebungsbedingungen, die für die Einführung eines professionellen Projektmanagement-Systems im Sinne des Unternehmens und auf der Basis der unternehmensspezifischen Anforderungen notwendig wären. Ziel- und ergebnisorientiertes Arbeiten mit bedarfsgerechter Lösungsentwicklung und Lösungsrealisierung ist die primäre Voraussetzung für den erfolgreichen Abschluss von Projekten. Bedeutung Projektmanagement in IT-Projekten Personelle Einschnitte, Budgetkürzungen in Verbindung mit den geschäftlichen Erfordernissen über immer mehr Druck auf die Projekte aus. Effektives Projektmanagement bedeutet auch kapazitätsgerechte Zuteilung von Aktivitäten, konsequente Projektsteuerung und Verantwortung für Kosten und Budget. Mitarbeiter spielen hierbei die größte Rolle. Nicht allein die in schriftlicher Form vorhandenen Methoden und Verfahren, sondern die Umsetzbarkeit, die Verständlichkeit und Übung im täglichen Ablauf des Projektes sind entscheidend. Arbeitsmethoden der Mitarbeiter für die eigene Organisation sowie für die Zusammenarbeit sind nicht für alle gleichzusetzen. Werden die Mitarbeiter aus dem Tagesgeschäft für das Projekt zur Verfügung gestellt, sind sie trotzdem nicht zu 100% verfügbar. Hier liegt bereits einer der meist festgestellten Planungsfehler. Sogenannte Grundlasten werden nicht berücksichtigt, oft nicht akzeptiert, das Projekt wird mit Verfügbarkeiten kalkuliert, die nicht existent sind. Koordination und Kommunikation ist personenabhängig. Nicht jeder Projektmitarbeiter erkennt die Wichtigkeit der Informationsweitergabe. Diese Kultur muss in Projekten erst entstehen. Projektmanagement ist Disziplin und regelbasierte gemeinsame Arbeit. In IT-Projekten werden qualifizierte und meist akademisch ausgebildete Mitarbeiter mit den Aufgaben beauftragt. Regeln und Vorgaben in diesem Kreis zu etablieren und zu leben bedarf eines gemeinsamen Verständnisses für die Notwendigkeit. IT-Projekte können effektiver abgewickelt werden, wenn die Managementfunktion der Leitungsinstanz nicht nur erwartet, sondern auch aktiv unterstützt wird. Beachte man bei jedem Vorhaben, das einem Projekt zugrunde liegt, dass ohne die aktive und kreative Leistung eines jeden Mitarbeiters im Projekt eine erfolgreiche Realisierung nicht möglich ist. Den Mitarbeitern die Arbeit ermöglichen, sie dabei zu unterstützen und die Ergebnisse im Sinne des Projektes zu kontrollieren, sollte der Grundsatz des IT-Projektmanagements sein. Beachten Sie das Workshop-Programm zum Thema: Projektmanagement in IT-Projekten Einsatz professioneller Planungssysteme (Vorbereitung der Auswahl) Projektmanagement Grundlagen und Arbeitstechniken im Projekt Seite 7