Einführung
Projekte sind oft das Mittel zur Operationalisierung strategischer Pläne einer Organisation. Es sind Projekte zur Entwicklung von Produkten und Dienstleistungen sowie zur Steigerung der betrieblichen Effizienz vorgesehen. Das Geschäft wird zunehmend projektiert und die globalen Ausgaben für Projekte liegen in der Größenordnung von vielen Milliarden Dollar pro Jahr (Williams, 2005). Die Gründe liegen auf der Hand. Projekte bieten die Möglichkeit, Projektmanagementpraktiken anzuwenden, die eine effiziente und effektive Nutzung von Ressourcen fördern. Trotz der Fortschritte in der Disziplin und im Beruf des Projektmanagements deutet die allgemeine Erfahrung darauf hin, dass viele Projekte scheitern (Williams, 2005), was die Bedeutung und die Notwendigkeit unterstreicht, die Prozesse und die Leistung des Projektmanagements zu verbessern.
Im Allgemeinen bemühen sich Organisationen, Best Practices des traditionellen Projektmanagements — basierend auf PMI—Standards – zu implementieren, um Projektziele zu erreichen und die Erwartungen der Kunden zu erfüllen. Allerdings sind möglicherweise nicht alle empfohlenen Prozesse und Praktiken des Project Management Body of Knowledge (PMBOK® Guide) für jedes Projekt relevant. Oft ist ein selektiver Ansatz sinnvoll, um Projektmanagementprozesse und -praktiken an die spezifischen Anforderungen des Projekts anzupassen, basierend auf seiner Größe, Art, Komplexität und der Branche, in der das Projekt durchgeführt wird. Ein solcher Bedarf an einem anderen Ansatz zur Verwaltung von IT-Projekten ist in der Projektmanagement-Literatur gut dokumentiert.
Softwareentwicklungsprojekte stehen oft vor widersprüchlichen Herausforderungen, Softwareprodukte in einem beschleunigten Tempo zu entwickeln und sie gleichzeitig robust zu entwickeln, um sie zuverlässig zu machen (Boehm, 2002). IT-Projekte, die mit den sich schnell ändernden Technologieentwicklungen Schritt halten wollen, unterliegen häufig Änderungen des Umfangs während der Planungs- und Implementierungsphase. Folglich haben IT-Projekte Herausforderungen, die sich von traditionellen Projekten unterscheiden. Für IT-Projekte werden verschiedene Anpassungen und Modifikationen traditioneller Projektmanagement-Praktiken entwickelt und praktiziert, wodurch neue Projektmanagement-Methoden wie agiles Projektmanagement eingeführt werden.
Agile Projektmanagement—Methodik—mit seiner größeren Anpassungsfähigkeit an häufig wechselnde Umfang-verwendet iterative oder Phasenplanung und Continuous Integration. Das Schlüsselprinzip ist, den Projektumfang weich zu halten. Die Methodik fördert die Zusammenarbeit und führt zu einer erhöhten Kundenzufriedenheit. Agile ist jedoch keine vollständige Lösung, um Software in einem schnellen Tempo zu entwickeln und gleichzeitig die Anforderungen der Kunden an Robustheit und Zuverlässigkeit zu erfüllen. In diesem Zusammenhang empfahl Boehm (2002) eine Kombination aus traditionellem Projektmanagement und agiler Softwareentwicklungsmethodik, die machbar und vorzuziehen ist. Ein komplementärer Ansatz wäre die Entwicklung eines risikobasierten Ansatzes, der darauf zugeschnitten ist, die Vorteile sowohl agiler als auch plangetriebener Methoden beizubehalten und gleichzeitig viele ihrer Schwächen zu mindern (Boehm & Turner, 2003).
Diese Forschungsarbeit zielt darauf ab, die oben genannten Vorschläge (Boehm, 2002; Boehm & Turner, 2003) eines kombinierten Ansatzes für das Management von IT-Beratungsprojekten zu untersuchen, die sich von IT-Projekten unterscheiden. IT-Beratungsprojekte sind konzipiert, um IT-Projekte zu managen und zu unterstützen. Sie werden oft im Regierungssektor initiiert. IT-Beratungsprojekte sind keine Softwareentwicklungsprojekte, sondern bieten Projektunterstützung für IT-Projekte.
In dieser Studie wollen wir ein Verständnis dafür entwickeln, wie agile Projektmanagement-Praktiken für IT-Beratungsprojekte relevant sind. Ziel der Studie ist es, die Vorteile des Einsatzes von agilem Projektmanagement, seine Eignung und welche Aspekte des traditionellen Projektmanagements mit agilem Projektmanagement für IT-Beratungsprojekte kombiniert werden können, um die Projektleistung zu verbessern. Im nächsten Abschnitt haben wir anhand einer umfangreichen Literaturübersicht der agilen Projektmanagement-Methodik die wichtigsten Merkmale der agilen Methode und ihren einzigartigen Ansatz für das Projektmanagement im Vergleich zum herkömmlichen Projektmanagement identifiziert. Die Literaturrecherche hat dazu beigetragen, ein Verständnis für die wichtigsten Konzepte und Vorteile der agilen Softwareentwicklung zu entwickeln. Basierend auf den Ergebnissen der Literaturrecherche haben wir eine Forschungsmethode entwickelt und vorgestellt, die einen strukturierten Fragebogen verwendet, um ein Verständnis für IT-Beratungsprojekte zu entwickeln. Datenanalyse und Diskussion, die anschließend präsentiert werden, liefern wichtige Erkenntnisse und Ergebnisse der Studie. Wir schließen das Papier mit unseren Forschungsergebnissen und Empfehlungen für IT-Beratungsprojekte ab.
Literaturübersicht
Traditionelle Projektmanagementpraktiken, die auf einer umfassenden Planung beruhen, können verwendet werden, wenn die Projektspezifikationen klar definiert sind. Auf der anderen Seite, wenn Spezifikationen während der Projektlaufzeit häufigen Änderungen unterliegen, funktioniert der traditionelle Ansatz zum Verwalten von Projekten möglicherweise nicht effizient. Softwareentwicklungsprojekte werden oft mit minimalen Spezifikationen konzipiert, was zu häufigen Änderungen dieser Spezifikationen während der Projektumsetzung führt. Darüber hinaus sind die Entwicklungszeiten von Softwareprojekten kurz. Agile Methoden eignen sich im Vergleich zu herkömmlichen Projektmanagementtechniken aufgrund der kurzen Entwicklungsdauer dieser Projekte für Softwareentwicklungsprojekte (Hanakawa & Okura, 2004).
Im Allgemeinen versprechen verschiedene Softwareentwicklungsmethoden wie agiles Projektmanagement eine erhöhte Kundenzufriedenheit, geringere Fehlerraten, schnellere Entwicklungszeiten und dienen als Lösung für sich schnell ändernde Projektanforderungen (Boehm & Turner, 2003). Im Gegensatz zum agilen Projektmanagement verwendet ein Stage-Gate-Modell einen Arbeitsprozess von der Konzeptidee bis zum Produkt, das letztendlich geliefert wird. Dieses Modell entwickelt Projektmanagementlebenszyklusphasen basierend auf verschiedenen Phasen der Produktentwicklung für das Management von Projekten. Ein wichtiger Unterschied zwischen einem Stage-Gate-Modell und agilem Projektmanagement besteht darin, dass erstere versuchen, Anforderungsänderungen zu minimieren, damit das Produkt rechtzeitig fertiggestellt wird (Karistrom & Runeson, 2005). Eine andere Methode zur Entwicklung von Software ist SCRUM, eine Reihe von Projektmanagementprinzipien, bei denen kleine funktionsübergreifende und selbstverwaltete Teams eingesetzt werden (Schatz & Abdelshafi, 2005). SCRUM erfordert, dass jedes Teammitglied und jeder Product Owner zu Beginn jedes Entwicklungselements zusammenarbeiten und die Methodik als Wrapper für bestehende Entwicklungsprozesse fungiert. Daher argumentierten Schatz und Abdelshafi, dass SCRUM keinen Basisplan zur Messung des Projekterfolgs haben wird. Agiles Projektmanagement wird für diese Studie jedoch aufgrund seiner größeren Flexibilität und Anpassungsfähigkeit an Softwareentwicklungsprojekte in Betracht gezogen.
Zusätzlich zu den oben diskutierten Vorteilen ist die agile Methodik auf turbulente und sich ständig verändernde Umgebungen anwendbar (Highsmith & Cockburn, 2001). Darüber hinaus betont die agile Methode die Anpassungsfähigkeit an Markt, Technologie und Prozess (Mellor, 2005). Die agile Methodik ist ein Ansatz, der sich zuerst auf wichtige Funktionen konzentriert und daher nach frühem Feedback zu Funktionen sucht (Karistrom & Runeson, 2005). Sobald wichtige Merkmale identifiziert sind, stellt der Projektmanager sicher, dass es keine Verzögerungen gibt. Karistrom und Runeson wiesen darauf hin, dass der agile Prozess das Pauken von Ressourcen, festen Plänen und die Unterstützung langfristiger Pläne vermeiden würde.
Die agile Methodik eignet sich jedoch nicht für alle Softwareentwicklungsprojekte. Unter Berufung auf Scott Ambler, den Entwickler der agilen Methode, empfahl Boehm (2002) traditionelle, plangesteuerte Projektmanagementmethoden für Assurance-Software wie lebenskritische Systeme.
Die agile Methode erfordert aufgrund ihres anspruchsvollen Projektumfelds, das von Chaos und Unsicherheit geprägt ist, Projektteams, die aus talentierten Mitarbeitern bestehen, um herausfordernden Bedürfnissen und Anforderungen gerecht zu werden. Unter Berufung auf eine Forschungsstudie von Constantine (2001) schlug Boehm (2002) vor, dass agile Methoden hochqualifizierte Mitarbeiter erfordern. Darüber hinaus ist Agile nicht für größere Teams geeignet (Highsmith & Cockburn, 2001), da es eng koordinierte Teamarbeit erfordert, um erfolgreich zu sein, und Teams mit mehr als 15 oder 20 Entwicklern erhöhen die Schwierigkeit, das Projekt zu verwalten (Constantine, 2001).
Es ist offensichtlich, dass die agile Methode kohärente Teams verwendet (Karistrom & Runeson, 2005). Karistrom und Runeson identifizierten zusätzliche agile Funktionen wie kleine und überschaubare Aufgaben, kontinuierliche Integration und automatische Tests. Folglich zeichnen sich agile Projektteams durch gute interne Kommunikation, höhere Qualität und ein Gefühl der Kontrolle aus (Karistrom & Runeson). Sie sehen jedoch eine potenzielle Isolation für das agile Team vor.
In Bezug auf Kommunikation, dokumentenbasiertes Fortschrittsmanagement und Qualitätskontrolle passt eine gängige Praxis im traditionellen Projektmanagement nicht zur agilen Softwareentwicklungsmethode (Hanakawa & Okura, 2004). Face-to-Face-Interaktion zur kontinuierlichen Neuausrichtung der Entwicklungsziele wird in agilen Methoden meist bevorzugt (Melnik & Mauer, 2004). Melnik und Mauer betonten den Unterschied zwischen traditionellen und agilen Methoden und schlugen vor, dass kurzer Wissenstransfer und direkte Kommunikation und Zusammenarbeit in der Softwareentwicklung bevorzugt werden, im Gegensatz zu den traditionellen Projektmanagementpraktiken, bei denen lange Wissenstransferketten verwendet werden, die häufig anfällig für Verzerrungen und Informationsverluste sind.
Einer der wichtigsten Unterschiede zwischen plangesteuerten traditionellen Projektmanagement-Praktiken und agilen Methoden besteht darin, dass agile Methoden die Agilität eher aus dem stillschweigenden Wissen des Projektteams als aus dem expliziten Wissen erfassen, das im traditionellen Projektmanagement häufig in Form von Dokumenten und Plänen verwendet wird (Boehm, 2002).
Ein weiterer Unterschied ist die Menge und Art der Dokumentation für Projekte erstellt. Plangesteuertes traditionelles Projektmanagement betont die detaillierte Planung, Überwachung und Kontrolle von Dokumenten. Entwurfsgrundlagen, Dokumente, die Gründe und Begründungen ausdrücken, werden mit einem hochautomatisierten Verfahren erstellt und diese Entwurfsgrundlagen dienen als agile Dokumentation (Sauer, 2003).
Coram und Bohner (2005) haben gemeinsame Merkmale der agilen Methode identifiziert: Zusammenarbeit, kleine Teams, kurze Release-Zeitpläne, Zeitboxen und ständiges Testen. Der Projektmanager ist dafür verantwortlich, ein hochgradig kollaboratives Umfeld zu gewährleisten. Zu diesem Zweck fördert die agile Methode kleine Teams und einige Unterteams pro Projekt, um die Zusammenarbeit zu fördern. Infolgedessen erfordert die agile Methode wahrscheinlich weniger Prozess und Planung, um Teamaktivitäten zu koordinieren. Die agile Methode verwendet auch kurze Release-Zeitpläne, die von zwei Wochen bis zu sechs Monaten variieren können. Time Boxing ist ein Konzept, das eine feste Dauer für die Freigabe von Projektleistungen vorschreibt, wodurch Vergoldung und Umfangskriechen reduziert werden. Ständige Tests stellen die Produktqualität und -integration sicher. Darüber hinaus schlugen Coram und Bohner vor, dass Projektmanager den Fortschritt verfolgen und Geschäftsentscheidungen treffen müssen, wobei der Schwerpunkt darauf liegt, auf Veränderungen zu reagieren, anstatt einem bestimmten Plan zu folgen.
Zeitboxen führt zu unvorhersehbarer Planung nach bestem Wissen und festen Terminen, die während der Entwicklungsphase zu unerwarteten Überraschungen führen können (Patton, 2003). Ein weiteres Ergebnis dieses iterativen Projektplanungsprozesses ist, dass die agile Methode den Fortschritt nicht anhand des Prozentsatzes der Fertigstellung überwachen kann (Patton, 2003).
Die Einbeziehung kleiner Unterteams in die Planung führt zu motivierten Softwareentwicklungsingenieuren; Technische Probleme werden früh im Projekt angesprochen und es wird wenig Widerstand bei der Umsetzung geben (Karistrom & Runeson, 2005). Darüber hinaus würde die Definition des Projektumfangs mit einem agilen Ansatz zu einer Kostensenkung führen (Mcgovern, 2002). Die agile Methode verwendet eine anforderungsbasierte Planung und lässt uns auch den Umfang kontrollieren (McGovern).
Unter Verwendung aller bisherigen Referenzen und Diskussionen (Little Greene, Phillips, Pilger & Poldervaart, 2004; Little, 2005; Abrahamsson, Warsta, Siponen, & Ronkainen, 2003; Ilieva, Ivanov, & Stefanova, 2004; Lindvall, 2004) bietet Tabelle 1 einen zusammenfassenden Vergleich zwischen traditionellen und agilen Projektmanagementpraktiken.
Tabelle 1: Vergleich zwischen agilem und traditionellem Projektmanagement
| Projektphase | Traditionell | Agil |
| Einleitung |
|
|
| Planung |
|
|
| Execution |
|
|
| Monitoring und Controlling |
|
|
| Restposten |
|
|
Zusammenfassung der Literaturübersicht
Die agile Projektmanagement-Methodik wird häufig für Softwareentwicklungsprojekte verwendet. Es hat eine größere Anpassungsfähigkeit an häufig wechselnden Umfang. Agiles Projektmanagement setzt daher auf iterative oder phasenweise Planung und kontinuierliche Integration während der gesamten Projektlaufzeit. Das Schlüsselprinzip im agilen Projektmanagement ist es, den Projektumfang weich zu halten. Die agile Projektmanagementmethode unterscheidet sich von einer traditionellen Projektmanagementmethode dadurch, dass Faktoren, die traditionell als unwichtig angesehen werden, Bedeutung beigemessen wird. Agile ordnet relativ höhere Bedeutung zu:
- Einzelpersonen und Interaktionen über Prozesse und Tools
- Projektabwicklung über umfassende Dokumentation
- Zusammenarbeit mit Kunden über Vertragsverhandlungen
- Reaktion auf Änderungen über einen Projektplan
Die agile Methode betont die Flexibilität, um Projektanforderungen zu erfüllen. Darüber hinaus ist es auf Kundenfeedback angewiesen, um Änderungen an einem Projektplan einzuleiten. Die Methodik verwendet den Ansatz, die geeigneten Endbenutzer und ihre Ziele zu identifizieren, um Projektergebnisse zu formulieren und die Leistungsanforderungen der Geschäftsprozesse zu erfüllen. Zu den Vorteilen der agilen Methode zählen eine erhöhte Kundenzufriedenheit, geringere Fehlerraten und schnellere Entwicklungszeiten. Darüber hinaus ist die agile Methode eine Antwort auf sich schnell ändernde Anforderungen, da sie frühes Feedback zu technologischen Merkmalen von Projektleistungen verwendet. Die agile Methode stellt sicher, dass die Anforderungen nicht überfüllt werden. Wesentliche Merkmale der agilen Methode sind die effektive Kommunikation innerhalb und außerhalb des Projektteams sowie die Flexibilität beim Hinzufügen weiterer Anforderungen.
Diese Vorteile würden Unternehmen helfen, einen besseren Kundenservice zu bieten. Darüber hinaus sind sie in der heutigen Wirtschaft relevant, in der Globalisierung und eine freie Marketingphilosophie die Wahrnehmung der Kunden beeinflussen, indem sie die Erwartungen wecken, Produkte und / oder Dienstleistungen schneller, billiger und besser zu liefern.
Die agile Methode ist jedoch nicht ohne Mängel, wie Tabelle 1 zeigt. Häufig wechselnder Umfang führt zu Schwierigkeiten bei der Überwachung des Projektfortschritts. Es ist auch nicht einfach, stillschweigendes Wissen in Form von Lessons Learned zu erfassen. Umfang Änderungskontrolle, Dokumentation, umfassender Plan, Qualitätsmanagement und Risikomanagement sind wichtige Vorteile des traditionellen Projektmanagements, die uns bei der Anwendung agiler Methoden vorenthalten werden können.
Forschungsmethodik
Wir haben sowohl persönliche Interviews als auch Fragebögen verwendet, um die Daten zu sammeln. Wir haben einen strukturierten Fragebogen entwickelt, der aus zwei Abschnitten besteht. Der erste Abschnitt wurde entwickelt, um Details über das Projekt und seine Eigenschaften zu erfassen. Dieser Abschnitt besteht aus 13 Fragen, die sich auf Projektdemografie und Projektmanagementpraktiken beziehen. Sie wurden den Teilnehmern der Studie mit der Option präsentiert, bei Bedarf offene Antworten zu geben.
Der zweite Abschnitt konzentrierte sich auf Aussagen zur Projektmanagement-Praxis, und die Teilnehmer wurden gebeten, auf diese Aussagen auf einer Fünf-Punkte-Skala zu antworten, wobei 1 „absolut nicht einverstanden“ und 5 „absolut einverstanden“ bedeutet.“ Die folgenden Aussagen wurden verwendet, um wichtige gemeinsame Grundsätze der Projektmanagementpraktiken anzusprechen und traditionelle und agile Projektmanagementpraktiken zu kontrastieren.
- Die Kriterien zur Messung des Projekterfolgs basieren auf den Projektzielen.
- Das Projekt wird von Anforderungen angetrieben.
- Das Projekt kann an Änderungen angepasst werden.
- Ihrer Meinung nach haben die Bemühungen des Projektmanagements die erwarteten Ergebnisse erzielt
- Face-to-Face-Interaktionen und kürzere Kommunikationsketten werden wichtiger als Prozesse und Tools.
- Der Fokus des Teams liegt auf der Projektabwicklung über eine umfassende Dokumentation.
- Die Zusammenarbeit mit Kunden über Vertragsverhandlungen funktioniert für Ihr Team besser.
- Das Projekt hat einen klar definierten Projektumfang.
- Projektmanagement-Praktiken folgen dem PMBOK® Leitfaden Projektlebenszyklus.
- Für das Projekt wird eine iterative oder phasenweise Projektplanung verfolgt.
- Das Projekt hat Dokumentationsanforderungen wie die Einhaltung von Standards wie ISO9000, OMB 300.
- UAT-Verfahren (User Acceptance Testing) werden während des gesamten Projekts befolgt.
- Der Projektmanager ist befugt, projektbezogene Entscheidungen ohne Eingreifen des Kunden zu treffen.
Antworten auf diese Aussagen werden in Verbindung mit den entsprechenden Fragen aus dem ersten Satz von 13 Fragen analysiert. Gemeinsam lieferten die Antworten auf beide Abschnitte ein detailliertes Verständnis des Projekts für eine aussagekräftige Analyse.
Studienergebnisse
Der Fragebogen wurde strukturiert, um Daten zu 20 IT-Beratungsprojekten zu erfassen, die zum Zeitpunkt der Untersuchung im Gange waren. Von den Projekten sind 65% Zeit- und Materialvertragsprojekte und die restlichen sind feste Festpreise (FFP). Unter den Zeit- und Materialprojekten haben 55% eine Projektlaufzeit von mehr als zwei Jahren.
Die meisten Projektteams sind klein: Nur 15% haben 10 oder mehr Mitglieder. In Bezug auf die Kommunikation zwischen den Projektteammitgliedern haben 60% der Befragten nur formale Kommunikation für Projektanforderungen verwendet; 30% nutzten sowohl formelle als auch informelle Kommunikation, und die restlichen 10% stützten sich allein auf informelle Methoden.
Jeder zweite Befragte gab an, dass seine Projekte einen Projektplan verwendet haben. In einer verwandten Frage verwendeten 80% der Projekte, die keinen Projektplan hatten, auch keine iterative Planung.
Scope Change ist ein wichtiger Aspekt dieser Studie. Von den Projekten haben 70% mindestens einmal eine Änderung des Umfangs erfahren. Von denen, die eine Änderung des Projektumfangs erlebten, erlebten 60% diese mehr als zweimal. Während der Kunde über die Änderung des Umfangs entscheidet, kann der Berater — mit Zustimmung des Kunden — den Qualitätskontrollplan in den Projektmanagementplan aufnehmen. Auf die Frage, ob sie einen Qualitätskontrollplan für ihr Projekt haben, gaben 65% der Befragten an, dass sie keinen Qualitätskontrollplan verwenden.
Ergebnisdiskussion und -analyse
Die Forschungsergebnisse wurden analysiert, indem der Zusammenhang zwischen einer Frage und allen anderen Fragen sorgfältig untersucht wurde, um zunächst die Ergebnisse zu validieren und zweitens wirksame Managementstrategien zu entwickeln. Darüber hinaus wurden diese Ergebnisse analysiert, um zu untersuchen, welche agilen und traditionellen Projektmanagementpraktiken in Kombination verwendet werden können, um einen robusten Projektmanagementansatz für IT-Beratungsprojekte zu entwickeln.
Projekterfolgskriterien basierend auf ihren Zielen und Zielen
Ein Projekt gilt als erfolgreich, wenn es seine Ziele und Ziele erreicht. Nur 60% der Befragten stimmten der Aussage zu: „Die Kriterien zur Messung des Projekterfolgs basieren auf den Projektzielen.“ Etwa 30% der Befragten waren anderer Meinung. Weitere Analysen haben gezeigt, dass der Grund für die Ablehnung darin bestand, dass diese Projekte ständig wechselnden Bedingungen und Anforderungen ausgesetzt waren oder der Kunde sich über das Projekt nicht im Klaren war. Letztendlich erlebten diese Projekte häufige Umfangsänderungen. In einem bestimmten Fall haben sich die Projektziele geändert.
Es ist interessant festzustellen, dass es keinen Zusammenhang zwischen der Tatsache gibt, dass die Erfolgskriterien eines Projekts von seinen Zielen und Umfangsänderungen, der Art des Projekts und der Existenz eines Projektplans abgeleitet werden. Mit anderen Worten, die Ableitung von Projektkriterien aus dem strategischen Plan der Organisation hat keinen Einfluss auf die Änderung des Umfangs und darauf, ob das Projekt einen Plan hat.
Projektanforderungen
Normalerweise wird ein detaillierter Projektplan entwickelt, nachdem die Anforderungen des Projektsponsors klar identifiziert wurden. Die Entwicklung des Projektplans und seine Ausführung sollten grundsätzlich von diesen Anforderungen bestimmt werden. Daher würde man erwarten, dass Projektmanager der Aussage zustimmen würden: „Das Projekt wird von Anforderungen angetrieben.“ Studienergebnisse zeigen, dass nur 60% der Befragten angaben, dass ihre Projekte von Anforderungen getrieben sind. Etwa 20% der Befragten, die mit der Aussage nicht einverstanden waren, gaben an, dass ihre Projekte ohne Verwendung eines Projektplans ausgeführt werden.
Etwa 20% der Befragten, die neutral auf diese Aussage reagierten, sind die Projektmanager, die keine Bereichsänderung in ihren Projekten erfahren haben. Alle anderen Befragten, die der Aussage zustimmten oder nicht zustimmten, haben in ihren aktuellen Projekten mindestens einmal eine Änderung des Umfangs erfahren.
Wenn ein Projekt nicht planmäßig umgesetzt wird, können wir im Allgemeinen davon ausgehen, dass die Anforderungen nicht identifiziert werden oder dass sich die Projektanforderungen während der Ausführung ändern werden. In dieser Studie können wir jedoch keinen solchen Zusammenhang zwischen „Umsetzung des Projekts ohne Verwendung des Projektplans“ und „Das Projekt wird nicht von Anforderungen angetrieben“ herstellen, da nur 50% derjenigen, die der zweiten Aussage zustimmten, auch Projekte ohne Verwendung eines Plans verwaltet haben.
Anpassungsfähigkeit an Veränderungen
Achtzehn von 20 Projekten haben erfolgreich auf Änderungen im Projekt reagiert. Anpassungsfähigkeit an Veränderungen wird als primäres Merkmal für ein Projekt angesehen, um ein Kandidat für die Verwendung der agilen Projektmanagement-Methodik zu sein. IT-Beratungsprojekte, die in dieser Studie vertreten sind, haben gezeigt, dass sie anpassungsfähig sind, um mit dem Klimawandel umzugehen.
Projektmanagementbemühungen erzielten erwartete Ergebnisse
Die Ergebnisse deuten darauf hin, dass der Kunde mit dem Ergebnis in den meisten Projekten (70%) zufrieden ist. Diese Antworten waren jedoch nicht mit Antworten auf andere wichtige Umfragefragen zum Projektfortschritt und zum Produkt verbunden, die aus Sicht des Projektmanagers entwickelt wurden. Die Gründe liegen auf der Hand. Projekte erlebten immer noch Zeit- und Kostenüberschreitungen. Während das Endergebnis bei der Bereitstellung des Softwareprodukts zufriedenstellend ist, wurden Projektmanagementprozesse nicht erfolgreich ausgeführt. Die Schlussfolgerung könnte sein, dass die Einführung traditioneller Projektmanagementpraktiken wie die Entwicklung von Meilensteinen, Überwachung und Controlling dazu beigetragen hätte, das Projekt erfolgreich zu verwalten.
Bedeutung der persönlichen Kommunikation im Vergleich zu Prozessen
Kommunikation ist der Schlüssel zum Verständnis von Rollen, Verantwortlichkeiten, Richtlinien und Verfahren im Zusammenhang mit Projekten und zur Förderung der Zusammenarbeit. Letztendlich führt Kommunikation zu einem zusammenhängenden Projektteam und ermutigt die Teammitglieder, zusammenzuarbeiten und an der Entscheidungsfindung teilzunehmen. Sieben von zehn Projektmanagern, die an der Studie teilnahmen, waren sich einig, dass Face-to-Face-Interaktionen und kürzere Kommunikationsketten wichtiger sind als Prozesse und Tools.
Die Ergebnisse zeigen einen starken Zusammenhang zwischen der Bedeutung der persönlichen Kommunikation und den Kommunikationsmitteln zwischen den Projektteammitgliedern. Diejenigen, die nicht der Meinung waren, dass die Kommunikation von Angesicht zu Angesicht wichtiger ist als die Projektprozesse, haben die informelle Kommunikation zwischen den Mitgliedern des Projektteams verwendet, während diejenigen, die die Kommunikation von Angesicht zu Angesicht für wichtiger hielten, sowohl formelle als auch informelle Kommunikation verwendet haben.
Fokus auf Projektausführung statt Dokumentation
Die Projektdokumentation wird oft übersehen, und folglich werden Organisationen wichtige Erkenntnisse aus der Projektplanung und -ausführung vorenthalten. In Anbetracht der Tatsache, dass es sich bei allen in dieser Studie vertretenen Projekten um Projekte der Bundesregierung handelt, ist es interessant festzustellen, dass 70% der befragten Projektmanager zustimmten, dass sich ihre Teams auf die Projektabwicklung konzentrierten, anstatt eine umfassende Dokumentation zu erstellen. In einigen Fällen, in denen Projektmanager der Ansicht waren, dass die Dokumentation wichtiger ist als die Projektausführung, ergab eine weitere Untersuchung, dass der Kunde in all diesen Fällen unentschlossen war.
Zusammenarbeit mit dem Kunden über Vertragsverhandlungen
Vertragsverhandlungen sind ein wesentliches Merkmal externer Projekte. Während der Verhandlungen würden sich beide Parteien auf den Schutz ihrer Eigeninteressen konzentrieren. Die Vertragsverhandlungen können in verschiedenen Phasen des Projekts stattfinden. Es ist wünschenswert, diese Probleme durch Zusammenarbeit zu lösen, insbesondere während der Projektumsetzung. Andernfalls wird es zu Problemen wie einer Vertragsverlängerung kommen. Angesichts der Tatsache, dass es sich bei allen in dieser Studie vertretenen Projekten um Verträge handelt, ist es ermutigend festzustellen, dass mehr als die Hälfte der befragten Projektmanager (60%) die Zusammenarbeit mit Kunden für wichtiger halten als Vertragsverhandlungen. Sie schlugen vor, dass die Zusammenarbeit für Projektteams besser funktioniert.
Wo es Meinungsverschiedenheiten gab, was bedeutet, dass Zusammenarbeit nicht so wichtig ist wie Verhandlungen, wurden zwei interessante Fakten mit diesen Projekten in Verbindung gebracht. Alle anderen Projekte verwendeten den direkten Kontakt als Kommunikationsmittel mit den Projektbeteiligten, aber diese Projekte verwendeten eine Befehlskettenkommunikation, und der Kunde war ebenfalls unentschlossen über das Projekt. Beide Faktoren bedeuten schwierige Bedingungen für die Zusammenarbeit.
Projekt und ein genau definierter Projektumfang
Projekte sind in der Regel mit Unsicherheiten und unbekannten Faktoren verbunden, die zu Mehrdeutigkeiten führen. Daher können in der frühen Phase des Projekts kein detaillierter Umfang und keine detaillierten Spezifikationen entwickelt werden. Der Umfang des Projekts ändert sich im Laufe des Projekts ständig. Manchmal können sich auch die ursprünglichen Ziele des Projekts ändern. Von den befragten Projekten haben 40% einen genau definierten Umfang, weitere 45% nicht.
Bei 80% der Projekte kam es jedoch mindestens einmal zu einer Änderung des Geltungsbereichs, was die zuvor vorgelegten Argumente bestätigt.
Projektmanagementpraktiken und der PMBOK®-Leitfaden Projektlebenszyklus
Der PMBOK®-Leitfaden hat einen ausgeklügelten Projektmanagementlebenszyklusprozess entwickelt; es ist erschöpfend und umfassend. Es ist jedoch nicht notwendig, dass jeder Prozess des PMBOK® Guide Projektmanagement-Lebenszyklus auf jedes Projekt angewendet wird. Die Annahme sollte projektspezifisch sein. Wie erwartet folgten 45% der Projektmanager den Projektmanagementpraktiken des PMBOK® Guide Project Life Cycle und weitere 45% nicht.
Iterative oder phasenweise Projektplanung
Umfangsdefinition und Projektmanagementplan sind Teil des Projektplans. Wie bereits erwähnt, kann eine detaillierte Entwicklung des Umfangs und der Spezifikationen nicht zu Beginn des Projekts entwickelt werden. Folglich ändert sich der Umfang des Projekts im Laufe des Projekts ständig, was die Bedeutung der iterativen oder schrittweisen Projektplanung unterstreicht, ein wichtiges Merkmal der agilen Methode. Auf die Frage, ob eine iterative oder phasenweise Projektplanung für das Projekt befolgt wird oder nicht, gab die Hälfte der Befragten Ja an, und nur 15% folgten keiner iterativen Projektplanung. Es ist interessant festzustellen, dass alle, die mit der Praxis der iterativen Projektplanung nicht einverstanden waren, überhaupt keinen Projektplan hatten.
Dokumentation und Einhaltung von Standards
Die Projektdokumentation dient als Referenz für die Analyse historischer Daten und hilft Organisationen, die Projektmanagementprozesse kontinuierlich zu verbessern und Standards zu entwickeln. Die Dokumentation wird auch dazu beitragen, Lessons Learned zu identifizieren und Projektmanagementsysteme zu modifizieren, die zur Reife des Projektmanagements führen. OMB300 und ISO9000 dienen als Leitfaden bei der Entwicklung von Projektdokumentationssystemen. Insbesondere müssen viele Regierungsprojekte die OMB300-Richtlinien einhalten. Von den Befragten gaben 80% an, dass die von ihnen verwalteten IT-Projekte Dokumentationsanforderungen wie die Einhaltung von Standards wie ISO9000 und OMB300 hatten. Diese Anforderungen an die IT-Beratungsprojekte sind jedoch in begrenztem Umfang anwendbar.
User Acceptance Test Procedures
Kundenzufriedenheit ist das primäre Maß für Qualität und Erfolg für projektlieferbare Artikel. Daher werden Benutzerakzeptanztestverfahren als wichtig angesehen. Selbst bei weniger greifbaren Projektergebnissen wie Service ist das zugrunde liegende Maß für den Projekterfolg die Kundenzufriedenheit. Es ist jedoch subjektiv. Nur 30% der Befragten gaben an, während des gesamten Projekts Benutzerakzeptanztests durchgeführt zu haben, 45% der Befragten nicht.
Befähigung, projektbezogene Entscheidungen zu treffen
Im Allgemeinen sollten Projektmanagern freie Hand gegeben werden, um projektbezogene Entscheidungen ohne Eingreifen des Kunden zu treffen, wenn diese Entscheidungen keinen wesentlichen Einfluss auf den Projektumfang oder die Projektergebnisse haben. Nur 15% stimmten zu, dass der Projektmanager befugt ist, projektbezogene Entscheidungen ohne Eingreifen des Kunden zu treffen. Etwa 40% blieben neutral, und die restlichen 45% sagten, der Projektmanager habe diese Macht nicht. Da es sich bei diesen Projekten um externe und staatliche Projekte handelt, sind diese Ergebnisse sinnvoll.
Fazit
Unsere Studienergebnisse zeigen, dass der Großteil der Projekte von Anforderungen getrieben wird. Fast alle in dieser Studie vertretenen Projekte zeigten, dass sie sich an Veränderungen anpassen können. Informelle Kommunikation gilt als wichtiger als formale Prozesse und Systeme. In Anbetracht der Tatsache, dass die Projekte in der Studie mit der Regierungsarbeit zusammenhängen, zeigen die Ergebnisse, dass sich das Projektteam auf die Projektabwicklung über eine umfassende Dokumentation konzentrierte. Darüber hinaus funktioniert die Zusammenarbeit mit Kunden über Vertragsverhandlungen für Projektteams besser. Häufige Änderungen des Projektumfangs bedeuten die Bedeutung einer iterativen oder schrittweisen Projektplanung; ein wichtiges Merkmal des agilen Projektmanagements. Da es sich bei allen in dieser Studie vertretenen IT-Beratungsprojekten um Verträge handelt, ermutigen die Studienergebnisse dazu, die agile Methodik für IT-Beratungsprojekte formal zu übernehmen und mit traditionellen Projektmanagementpraktiken wie plangesteuerter Meilensteinentwicklung und -überwachung, Benutzerakzeptanzverfahren und Qualitätsmanagementpraktiken zu kombinieren.
Die Eignung der agilen Methode für Projekte ist eine vertragliche Verpflichtung in Bezug auf Dokumente zur Projektplanung, -überwachung und -steuerung. Projekte im Zusammenhang mit der Bundesregierung haben in der Regel erhebliche Dokumentationspflichten, wie die Einhaltung von Standards wie ISO9000 und OMB300; Wir sollten bei der Änderung der agilen Methode für solche Projekte Vorsicht walten lassen.
Die Herausforderung besteht darin, die Agilität, die schnelle Reaktion auf Veränderungen, flexible und einfache Pläne, die kontinuierliche Integration und andere Vorteile der agilen Methode beizubehalten und gleichzeitig einige der umfassenden Prozesse traditioneller Projektmanagementpraktiken zu integrieren.