Home

Leitfaden Projektmanagement - Office-2

Contents

1. tmplemen tierung Entwicklung und Verifikation des Produkts der n chsten Generation Planung der n chsten Phasen Abbildung 18 Spiralmodell Am Ende jeder Windung steht ein Review berpr fung bei dem der aktuelle Projektfortschritt bewertet wird Anschlie end werden die Pl ne f r die n chste Windung verabschiedet sowie die dabei verf gbaren Ressourcen festgelegt oder aber die Entwicklung abgebrochen 12 7 2 1Festlegung von Zielen Alternativen und Rahmenbedingungen Am Beginn jedes Zyklus werden inhaltliche vorgaben an das zu entwickelnde Teilprodukt festgelegt z B Funktionalit t Qualit tskriterien Nutzung von Bibliotheken zur Wiederverwendung und alternative Vorgehensweisen herausgearbeitet wie zum Beispiel e Unterschiedliche Analyse oder Entwurfstechniken e Einsatz von Werkzeugen e make or buy Entscheidungen Als Rahmenbedingungen werden Einschr nkungen bez glich Zeit Personal Kosten und der Hard und Softwareumgebung festgelegt Seite 103 Q Office 2 Heip Inhaltliche Vorgaben werden zu Beginn des Zyklus festgelegt Leitfaden Projektmanagement To Office 2 Heip Unterschiedlich e Techniken einsetzbar Unterschied liche Planungs tiefen m glich Vorzeitiger Projektabbruch m glich Seite 104 12 7 2 2Evaluierung der Alternativen Erkennen und Reduktion von Risiken In der zweiten Phase der Windungen werden die Alternativen hinsichtlich der festgelegten Ziele und
2. Leitfaden Projektmanagement Q Office 2 Heip Doris Curth B roservice Lortzingstra e 1 61267 Neu Anspach Tel 06081 961832 Fax 06081 961833 http www office 2 help de e mail info office 2 help de 3 Auflage 2007 Alle Informationen in dieser Dokumentation werden ohne R cksicht auf einen eventuellen Patentschutz ver ffentlicht Warennamen und Beschreibungen werden ohne Gew hrleistung der freien Verwendbarkeit benutzt Beim Erstellen von Texten und Bildern wurde mit gr ter Sorgfalt vorgegangen Trotzdem k nnen Fehler nicht vollst ndig ausgeschlossen werden Einen Anspruch auf Vollst ndigkeit erhebt dieses Handbuch nicht denn die Technologien und damit auch die Terminologien entwickeln sich extrem rasant Der Autor kann f r fehlerhafte Angaben und deren Folgen weder eine juristische noch irgendeine Haftung bernehmen Seite 2 Leitfaden Projektmanagement Q Office 2 Heip Inhaltsverzeichnis 5 Definition eines Projektes nnnuuunnnnnnnnununnnunnunnannnnnnunnannnnnnnunannnnnnnnn 16 51 Das Prolekt nee 16 5 4 Grunds tze der Projektarbeit uuuuuunnunununnunnunnnnununnunnunununnunnnnununnnnnnnn 18 5 4 1 Die Grundregeln der Projektarbeit zznunnoonnannnnnannaannnnnnnnannnnenn 18 5 5 Ziele und Zielkonslilkie 22 000400 000 nn ai aiaa 19 6 jek i 5 6 7 Mitarbeiter im Projektmanagement 2oo
3. Testen ist die Methode mit der Qualit t nachgewiesen wird Testen sollte weder als einmalige Angelegenheit noch als individuelle Testfolge gewertet bzw betrachtet werden Testen ist ein umfassender Workflow der eine Serie von Einzeltests innerhalb des gesamten Entwicklungszyklus umfasst Diese Tests konzentrieren sich auf die Identifizierung und Beseitigung von Fehlern und dem kontinuierlichen Erreichen der Produktqualit t zum fr hestm glichen Zeitpunkt Kruch99 Definition von Testen Prinzipiell kann man beim Testen von zwei verschiedenen Standpunkten Zwei ausgehen verschiedene Testarten e White box Testen betrachtet das Programm als white box sieht also alle Implementierungs Details Dementsprechend kann man bei der Auswahl der Testf lle auch die inneren Details ber cksichtigen e Black box Testen betrachtet das Programm als black box Beim Testen schaut man dabei haupts chlich ob das Programm sich spezifikationengem verh lt Da man aber auch die Spezifikation des Programms nur in seltenen F llen in elektronischer oder automatisch verwertbarer Form vorliegen hat beschr nkt sich Black box Testen h ufig auf das Testen des Input Output Verhaltens einer Funktion Prozedur Testen wird niemals zu einem einzigen Zeitpunkt durchgef hrt Getestet werden unterschiedliche Typen von Objekten Testobjekte in unterschiedlichen Phasen der Softwareentwicklung Der Testprozess erstreckt sich vom Testen kleinerer E
4. Sie sorgt f r kontrollierten Start Verlauf und Ende des Projekts F r jeden Dokumententyp der von PRINCE2 gefordert wird stehen Vorlagen mit den geforderten Unterstrukturen zur Verf gung So entsteht eine leicht verst ndliche standardisierte und vollst ndige Dokumentation Sie kann auf die Bed rfnisse einzelner Organisationen oder Projekte angepasst werden Sie ist geb hrenfrei so kann eine Organisation von ihren Lieferanten fordern PRINCE2 einzusetzen ohne Lizenzfragen beachten zu m ssen Die PRINCE2 Materialien liegen als ver ffentlichte Dokumente vor so dass eine Organisation nicht ihre eigene Projektmanagementmethode entwickeln muss um ihr Personal in ihrer Anwendung zu schulen Seite 127 Leitfaden Projektmanagement Q Office 2 Heip Seite 128 12 7 8 14Schw chen PRINCE2 hat die folgenden Schw chen e Einige Organisationen leiden unter PINO engl Prince In Name Only dt Prince nur dem Namen nach indem sie sich unbedacht der Methodologie bedienen sich dabei aber nicht an die Grunds tze halten Wie bei einigen der unten aufgef hrten Punkten ist dies Problem nat rlich nicht eine Schw che der Methodologie selbst sondern vielmehr ihrer Anwender e PRINCE2 ist stark dokumentenorientiert um eine gute Steuerung zu erm glichen Allerdings werden die Dokumente in einigen Organisationen zum Selbstzweck wobei die eigentlichen Projekte ins Wanken geraten e PRINCE2 stellt keine ausdr ckliche B
5. Das Phasenkonzept nach objektorientierter Vorgehensweise OO VM gliedert sich in 7 Teilschritte Abbildung 36 Teilschritte bei objektorientierter Vorgehensweise OO VM Die objektorientierte Vorgehensweise weicht von dem Wasserfall Prinzip ab und erlaubt eine zyklische Bearbeitung der Phasen OOA Analyse OOD Design und OOP Implementierung Diese Vorgehensweise iterativer Prozess ist erst mit objektorientierten Analyse und Design Methoden sinnvoll Die Phasen OOA OOD und OOP setzen dabei auf einem einheitlichen Modell auf das keiner Transformationen mehr zwischen den einzelnen Phasen bedarf Leitfaden Projektmanagement Q Office 2 Heip 17 3 2Verfahrensdokumentation Die Verfahrensdokumentation entsteht im Verlauf der Projektarbeit in den jeweiligen Phasen Die Ergebnisse der einzelnen Aktivit ten der Anwendungsentwicklung gem Vorgehensmodell sind in der in den Produktnormen vorgeschriebenen oder empfohlenen Form zu dokumentieren 17 4Methoden 17 4 1Allgemeine Methoden Die Durchf hrung eines komplexen Entwicklungsprozesses erfordert auch eine Allgemeine zielgerichtete methodische Vorgehensweise Deshalb werden in den Methoden verschiedenen Aktivit ten daf r geeignete Methoden und Techniken angewandt um einheitliche und qualitativ hochwertige Ergebnisse zu erhalten Im Anhang finden Sie eine Checkliste f r die Anwendung von Methoden und Techniken f r bestimmte Projektaktivit ten sowie Hinweise zu Erhebungsmeth
6. potentiellen Risiken in Ihrem Projekt erheblich mindern Verwenden Sie die Tipps in diesem Dokument um eine entsprechende Risikoanalyse durchzuf hren und Seite 148 Leitfaden Projektmanagement Q Office 2 Heip einen Risikoplan zu erstellen Wir hoffen dass Ihr Projekt dadurch sehr erfolgreich wird Seite 149 Leitfaden Projektmanagement To Office 2 Heip Projektplanung Aufbau Projektplan Prinzipien der Projektplanung Seite 150 16Projektmanagement 16 1Projektplanung Die Projekt Planung ist ein integraler Bestandteil im Projekt Lebenszyklus und w chst in der Detaillierung in dem Ma wie das Projekt fortschreitet Die Projektplanungsmethoden dienen dazu ausgehend von fachlich inhaltlichen Aktivit ten das Projekt nach den verschiedenen Dimensionen zu planen Als Ergebnis ist der Projektplan zu erstellen Er enth lt alle Gr en Ma e und Daten des gesamten Projektes Neben der Planung der Aktivit ten der Anwendungsentwicklung m ssen die Aktivit ten des Qualit tsmanagements mit eingeplant werden Hier sind sowohl Zeiten als auch Mitarbeiter mit entsprechenden Qualifikationen mit vorzusehen siehe Leitfaden Qualit tsmanagement Der Projektplan besteht aus folgenden Teilpl nen Aufgabenstrukturplan Terminplan Finanzplan Personalplan Sachmittelplan Schulungsplan Der Projektleiter ist daf r verantwortlich dass der Projektplan immer an die bestehende Strategie f r Informationsverarbeitung angepasst
7. Problemerkennung als darin sich einen Status zu verschaffen um solche Probleme tats chlich l sen zu k nnen Umgang mit Zielkonflikten Zielkonflikte in Projekten sind zwangsl ufig da die Ziele des Projektmanagements interdependent sind Abweichungen bei einem der Ziele haben damit zwangsl ufig Einfluss auf die Erreichung der beiden anderen Ziele Abbildung 1 Zielkonflikte beim Projektmanagement Hinzu kommen noch weitere Nebenbedingungen die blicherweise zumindest auf eines der Ziele Einfluss nehmen und auf diesem Weg auch die anderen Ziele des Projekts beeinflussen Wenn es beispielsweise zu Konflikten bei der Freistellung von Mitarbeitern f r das Projekt kommt bedeutet das in der Konsequenz dass das Terminziel als erstes betroffen sein wird Damit ergeben sich aber zwangsl ufig Auswirkungen auf das Sach und Kostenziel Zwischen allen drei Zielen gibt es Konflikte So ist beispielsweise die Erreichung des Sachziels in vielen F llen nur unter berschreitung der vorgegebenen Termine und damit blicherweise auch der geplanten Kosten m glich Das gilt gerade bei Entwicklungsprojekten deren tats chlicher Aufwand zu Beginn oft noch schwer abzusch tzen ist Seite 23 Leitfaden Projektmanagement To Office 2 Heip Seite 24 Konflikte zwischen den verschiedenen Zielen lassen sich grunds tzlich auf mehrere Arten l sen e Ziele werden angepasst Das kann beispielsweise durch eine Verschiebung von Endterminen und da
8. Selbst Seite 89 Leitfaden Projektmanagement To Office 2 Heip IT Profis fehlen an allen Ecken und Enden Qualit ts sicherung am Ende eines Projektes ist Sabotage des Projektes Seite 90 ein dreit giger C Kurs hilft hier nicht viel er lernt allenfalls die Syntax der Programmiersprache nicht jedoch die dahinterstehende Philosophie Er wird also nicht nur ins kalte Wasser geworfen man muss ihm sogar noch einen Pickel mitgeben damit der die dar ber befindliche Eisschicht erst aufschlagen kann Wenn wir z B den Einsatz der Unified Modelling Language UML in Software Entwicklungsprojekten betrachten so ist auch dies nicht ohne ein gezieltes Ausbildungsprogramm durchzuf hren dies w hre nicht nur unprofessionell sondern f hrt auch unweigerlich zum Scheitern des Projektes 10 1 18Fehlende Ressourcen In Zeiten von Engp ssen auf dem Arbeitsmarkt bez glich qualifizierter Arbeitskr fte in der IT Branche m ssen Personalabteiluingen umdenken Das alleinige Schalten einer Stellenanzeige in den einschl gigen Tageszeitungen reicht schon lange nicht mehr aus In den n chsten beiden Jahren werden allein von den gro en IT Unternehmen in Deutschland tausende von Arbeitskr ften gesucht doch woher nehmen Die Frankfurter Zentralstelle f r Arbeitsvermittlung ZAV der Bundesanstalt f r Arbeit berichtet von weniger als 3 000 arbeitslosen Informatikern das Angebot und auch die Qualifikationen sind deutlich ge
9. Sitzung Kick off Meeting unter folgender Beteiligung Auftraggeber Auftragnehmer an der Durchf hrung wesentlich beteiligte interne oder externe Personen Entscheidungstr ger die nicht als Person in das Projekt eingebunden sind ggf ein Vertreter des Betriebsrates Gesamtbetriebsrates Ziele und Ergebnisse der konstituierenden Sitzung sind Feststellung des Vorliegens der Voraussetzungen Ziele des Projektes sind definiert Auftraggeber ist verantwortlich benannt Abgrenzung des Projektes ist vorgegeben Beteiligung aller Betroffenen ist gew hrleistet Rahmenplan Ressourcen Kosten Zeit usw ist erstellt Budgets sind vorhanden Benennung der Beteiligten im Projekt Projektleiter und Teammitglieder Review Board ggf zus tzlich Projekt Board sonstige Beteiligte Arbeitspakete und Meilensteine sind genehmigt Projektauftrag liegt schriftlich vor und ist best tigt Projektfreigabe bzw Nichtzulassung Leitfaden Projektmanagement 10Warum Projekte Scheitern Es w hre recht m ig an dieser Stelle alle gescheiterten Projekte aufzuz hlen Die Gr nde jedoch die f r das eine oder andere scheitern von Projekten verantwortlich sind sind berschaubar Ein erfahrener Projektleiter wird die nachstehend aufgef hrten Gr nde nicht nur best tigen sondern sie gegebenenfalls noch durch eigene Erfahrungen in den Details erg nzen k nnen 10 1Wann ist ein Projekt gescheitert Das diese Frage so weit vorn in diesem Leitfaden geste
10. Wiederkehrende immer gleiche Routineaufgaben stellen keine Projekte dar Wesentlich f r ein Projekt ist auch Abgeschlossenheit Es handelt sich um ein vorhaben und nicht um eine endlose Reihe von vorhaben Auch f r den Einsatz von Projektplanungssoftware ist es sehr wichtig diese Abgeschlossenheit explizit zu definieren Ganz abgesehen davon das die klare Definition von Anfang und Ende ein zwangsl ufiges Ergebnis eines Prozesses sind in dem solche Vorhaben definiert werden Denn wie schon in der Norm noch viel mehr aber in der Praxis deutlich wird Ein klares Ziel ist eine zwingende Voraussetzung f r ein Projektmanagement In der Praxis l sst sich oftmals zwar nicht der Fall beobachten bei dem mit einem klaren ziel gearbeitet wird Stattdessen wird plan und ziellos und damit letztlich oft genug auch ergebnislos gearbeitet Die entscheidenden Merkmale von Projekten sind also e Definierte Ziele Die Ziele eines Projektes m ssen die Unternehmensziele nachhaltig unterst tzen e Nicht gew hnliche Bedingungen e Eine klare Abgrenzung gegen ber anderen Vorhaben e Die Abgeschlossenheit Leitfaden Projektmanagement Q Office 2 Heip Bevor ein Projekt beginnt wird gepr ft und gekl rt ob in einem Teil eines Konzerns Unternehmens oder durch Einsatz von Standards eine L sung verf gbar ist die den Anwender bereits zufrieden stellen k nnte Dabei wird in die berlegung mit einbezogen wie gro der Modifikationsaufwand bei vorhan
11. gliche Schritte im Probleml sungszyklus bzw im Bereich des Projektmanagements dargestellt denen diese zugeordnet werden k nnen Die Methoden und Techniken sind in Standardliteratur wie z B in Systems Engineering von DAENZER 92 beschrieben Vorgehensschritt Aktivit t im Projekt Management D c 3 b o 5 E O 3 p 3 2 c 9 g o fr D o 5 gt E D 2 dD D fa c p c ce c gt c m 5 s 2 x 5 5 35 2 3 E s E a a 3 7 o O O E x x S e S 8 8 amp j 2 o o 2 2 Kategorie Methode Technik 7 N x x m m m System beschreibung Modell und Modellmethode x x x Blackbox Methode x x Input Output Methode x x Graphen x x Matrizen x x x o Ablaufdiagramme x x x x Polarit ts profil x x x Regelkreismodell o X Vergangenheits Zukunftsorientiert amp Inform ations beschaffung Interview x o Fragebogen x o Panel Befragung x o Multimomentaufnahmen x Wahrscheinlichkeitstheorie x Mathematische Statistik x o Korrelations Analyse x o o Regressions Analyse x o o Mittelwertbildung x o Exponentielle Gl ttung x Trend Extrapolation x o o S ttigungs modelle x Hochrechnungsprognosen x Delphi Methode x o o Scenario Writing x o X x o Schwerpunkt der Anwendung m gliche Anwendung Checkliste Methoden und Techniken Teil A Leitfaden Projektmanagement Q Office 2 Heip Seite 187 Leitfaden Projektmanagement Q Office 2 Heip Vorgehensschritt Aktivit t im Projekt Ma
12. higen Teilsystem siehe Abbildung Timeboxen Die Timeboxen m ssen nicht unbedingt benutzt werden Sind die Anforderungen vollst ndig spezifiziert und die Realisierungsphase klar abgrenzbar dann k nnen die einzelnen Phasen auch nur einmal durchlaufen werden Vereinfacht kann man aber dann sagen dass nur eine Timebox existiert und diese nur einmal durchlaufen wird Leitfaden Projektmanagement Q Office 2 Heip Wichtigstes Prinzip der Timebox ist der definierte Zeitraum Ist es nicht m glich Definierter die volle Funktionalit t innerhalb dieses Zeitraums zu realisieren so wird die Zeitraum Funktionalit t reduziert Der Zeitabschnitt wird nicht verl ngert Die fehlende Funktionalit t muss dann in zus tzlichen Timeboxen realisiert werden Dadurch sind Projektproblembereiche und Terminverschiebungen fr hzeitig erkenn und steuerbar Projektinitialisierung Projektplanung Grobkonzept Domain Modellierung Zentrales Datenmanagement Workshop fachl Feinkonzept Fachliches Feinkonzept Subsysteme Timeboxen festlegen Timebox Subsystem erstellen User Review Fachliches Feinkonzept erstellen vertiefen Timeboxes DV technisches Feinkonzept f r andere erstellen vertiefen Projekte Realisierung Implementierung Konsolidierung und Re use Dokumentation Technische Abnahme Einf hrung Abbildung 32 Prinzip der Timeboxen Seite 153 Leitfaden Projektmanagement To Office 2 Heip
13. ngt von der Gr e und den Risiken des Projekts ab Dieser Prozess beschreibt das tagt gliche Management durch den Projektmanager Die Elemente des Prozesses Steuern einer Phase sind CS1 Arbeitspaket freigeben CS2 Fortschritt berwachen CS3 Offene Punkte aufnehmen CS4 Offene Punkte pr fen CS5 Phasenstatus pr fen CS6 ber Projektstatus berichten CS7 Korrekturma nahmen einleiten CS8 Offene Punkte eskalieren CS9 Abgeschlossenes Arbeitspaket entgegennehmen 12 7 8 8Managen der Produktlieferung PRINCE2 ist ein Produkt basiertes System Ein Produkt kann ein k rperlicher Gegenstand wie ein Buch oder ein eher immaterieller Gegenstand wie ein Dienstleistungsvertrag sein Tats chlich ist alles was von PRINCE2 erzeugt wird ein Produkt einschlie lich der Dokumente Im Gegensatz zu Spezialistenprodukten sind die von der Methode PRINCE2 definierten Produkte Managementprodukte Produkte k nnen von jedem erzeugt werden auch von externen Zulieferern Dieser Prozess erzeugt die Produkte des Projekts hier wird der gr te Teil der Projektressourcen eingesetzt Die Elemente des Prozesses Managen der Produktlieferung sind e MP1 Arbeitspaket annehmen e MP2 Arbeitspaket ausf hren e MP3 Arbeitspaket abliefern Seite 123 Leitfaden Projektmanagement Q Office 2 Heip Seite 124 12 7 8 9Managen der Phasen berg nge Nach den PRINCE2 Grunds tzen muss jede Phase vom Lenkungsausschuss abgeschlossen und gebillig
14. ser in Ihrer berwachungsliste und leiten Sie entsprechende Korrekturma nahmen ein sobald diese erforderlich werden Machen Sie die berwachung zu einer t glichen Aktivit t f r sich Wir denken das Ihnen die nachfolgenden Punkte bei der Risiko berwachung helfen werden e F gen Sie in Ihren Statusreport einen Punkt Risiko hinzu Holen Sie sich von jeder betroffenen Personenressource bei jedem Statusmeeting regelm ig eine zuverl ssige Aussage zu dem den entsprechenden Risikopunkt en und fragen Sie die Ressourcen ab ob evtl neue Risiken erkannt wurden e Planen Sie regelm ige Risiko Meetings w hrend deren Sie mit Ihren Teammitgliedern den Risiko und Projektplan durcharbeiten um m gliche Risiken zu identifizieren Jede Sitzung beginnt mit einem Bericht ber den Fortschritt bei den Top Ten Risikoelementen Die Risiko bersicht sollte die Rangordnung jedes Risikoelementes angeben den Rang bei der letzten Sitzung und wie oft das Element auf der Top Ten Liste stand Au erdem sollte angegeben werden wie sich das Risikoelement seit der letzten Sitzung entwickelt hat Die Sitzung selbst sollte sich darauf konzentrieren die Risikoelemente zu beseitigen e Nehmen Sie den Risikoplan zur Hand sobald Sie signifikante Projekt Abweichungen in Ihrem Projekt feststellen Versuchen Sie die Ursache zu ergr nden und entsprechende Gegenma nahmen festzulegen Mit etwas vorausschauender Planung und etwas Nachdenken k nnen Sie die
15. wof r er verantwortlich ist e Wie kann in einem Projekt sichergestellt werden dass jeder Mitarbeiter wei von wem er welchen Input bekommt und an wen er welchen Output Ergebnisse zu liefern hat e Wie kann ein laufendes Projekt realistisch hinsichtlich seines Fortschrittes beobachtet werden e Wie k nnen in einem Projekt unvorhersehbare Gefahren Risiken rechtzeitig erkannt und eliminiert bzw einged mmt werden 10 1 14Soziale Faktoren Diese Faktoren werden oft zu wenig beachtet Das Klima im Team ist jedoch ein entscheidender Faktor f r die Leistungsf higkeit 10 1 14 1Akzeptanz Im Idealfall sollten alle Projektbeteiligen die Stellung des Projektleiters akzeptieren Wenn es an dieser Stelle Akzeptanzschwierigkeiten im Team gibt m ssen diese vor dem Projekt durch offene Gespr che aus der Welt geschafft werden F rderlich f r eine gesicherte und gest rkte Position als Projektleiter ist die R ckendeckung durch die Gesch ftsf hrung Fehlt diese ist man eigentlich schon auf verlorenem Posten Im Zweifelsfall sollten Sie mit der Gesch ftsf hrung bzw mit Ihren Vorgesetzten sprechen bevor Sie eine Ernennung zum Projektleiter annehmen 10 1 14 2Kommunikation Eine offene Kommunikation im Projektteam ist unerl sslich Zur F rderung der Kommunikationsf higkeit ist ein Workshop mit dem Team zum Thema Kommunikation bestimmt keine schlechte Idee Dadurch k nnen etwaige Blockaden oder kritische Faktoren erkannt und behoben
16. 162 12 2 1 Vorgehensm delle ee ee 162 17 3 2 Verfahrensdokumentation uuunneannnaannnannnannnnannnannnnannnannnannnnannnn 165 19 1 1 Regeln f r die Projektgr ndung sssessssnnresnnnnnonnnnnsnnnnnnsnnnnnnenennne 172 19 1 2 Regeln zur inneren Organisation des Projektes 172 19 1 3 Regeln zur u eren Organisation des Projektes u 175 19 1 4 Regeln zur Proektsch lzung ee 177 19 1 5 Regel Projektpl Seite 6 Leitfaden Projektmanagement Q Office 2 Heip 19 5 Erhebungsmeilhoden 0000 naar 189 196 Stalusshzungen 0 00 190 19 7 Durchf hrung eines InterviewS uuusunnuonnnunununnnunnunuununnnunnnnunnununnununnunn 191 21 3 Duslienvetzelchnis dii 207 2131 Algemen Literati hecno aree 207 21 4 Auftraggeberinterne Literatur und Richtlinien sssssssssssssnsnnnnnnnnn 208 22 D r A f nna iaiia 209 23 BUehruchsee nee 210 Abbildungsverzeichnis Abbildung 1 Zielkonflikte beim Projektmanagement uurressnnnnennnnnn 23 Abbildung 2 Der sequentielle Ablauf des Projektes u 0000 28 Abbildung 3 Struktur Projektteam s uuu00000000000000nnn0nnnnnnn nn nnnnn nn 35 Abbildung 4 Klassische Struktur einer Projektorganisation 36 Abbildung 5 Die Matrix Projektorganisation uuusnssnnnnnnnnnnnnnnnnnnnnnn 37 Abbildung 6 Die Arbeit mi
17. 2 Heip Um eine optimale berwachung w hrend des Projekts sicherzustellen sind folgende Punkte zu beachten e Nachdem der Projektplan an alle kommuniziert wurde muss dieser stets gepflegt werden Aus dem Plan muss jederzeit hervorgehen wie viel Prozent eines Vorgangs bereits erledigt und welche Meilensteine bereits erreicht wurden Der Plan muss auch im Hinblick auf die Dauer die Ressourcen und die einzelnen Sachziele immer aktuell sein e Wird die berwachung konsequent und sauber durchgef hrt und haben Sie f r alle Vorg nge die Ressourcen definiert k nnen Ressourcenengp sse erkannt und darauf reagiert werden Hierf r kann eine Projektmanagement Software als Hilfsmittel verwendet werden e Die Projektsitzungen m ssen dazu dienen um den Abarbeitungsgrad der einzelnen Vorg nge festzustellen und um etwaige kritische Faktoren zu erkennen Kommunikation im Team ist hier ganz gro geschrieben Versorgen Sie ihr Team mit den richtigen Information zum richtigen Zeitpunkt bersch tten mit Informationen ist keine L sung Erstellen Sie ein Protokoll das an alle Beteiligten verteilt wird Hiermit soll sichergestellt sein dass Entscheidungen die getroffen wurden auch von allen so gemeint waren e Alles was aus den Sitzungen hervorgeht muss vom Projektleiter bearbeitet werden Optimieren Sie die Vorg nge um Versp tungen zu vermeiden Informieren Sie Ihre Auftraggeber regelm ig ber den Projektfortschritt und lassen Sie sic
18. A Statusbericht Vom Projektleiter zu erstellende bersicht ber den aktuellen Projektstand Soll Ist Vergleich von Terminen Kosten Aufw nden als Information f r den Auftraggeber Ein Statusbericht wird in regelm igen Abst nden oder bei Erreichen bestimmter Meilensteine angefertigt Team Zusammenarbeit verschiedener qualifizierter Mitarbeiter in einer Gruppe um eine gemeinsame Aufgabe zu erledigen Leitfaden Projektmanagement Q Office 2 Heip Terminplanung Planung der Anfangs und Endzeitpunkte aller Arbeitspakete eines Projektes Termintreue Einsatzplanung Planung ohne Ber cksichtigung der max Verf gbarkeit der ausf hrenden Kapazit ten Kapazit tsbedarfsplanung Verkn pfungen Anordnungsbeziehung Quantifizierbare Abh ngigkeit zwischen zwei Arbeitspaketen eines Projektes e Normalfolge Ende Anfang e Anfangsfolge Anfang Anfang e Endfolge Ende Ende e Sprungfolge Anfang Ende Vorw rtsrechnung 3 Schritt der Netzplanberechnung in dem die fr hestens m glichen Anfangs und Endzeitpunkte der Arbeitspakete ermittelt werden Zeitabstand Zeitwert Wird einer Anordnungsbeziehung zugeordnet Er kann gr er als kleiner als oder gleich Null sein Beispiele Normalfolge mit 3 Tagen Zeitabstand bedeutet dass der Nachfolger erst 3 Tage nach dem Ende des Vorg ngers starten darf Normalfolge mit 3 Tagen Zeitabstand bedeutet dass der Nachfolger schon 3 Tage vor dem En
19. Der Auftraggeber genehmigt das Projektbudget und die Rahmentermine Aufwand Der Aufwand eines Arbeitspakets beschreibt die Arbeitsmenge die notwendig ist um ein definiertes Arbeitsergebnis zu erbringen Microsoft Project verwendet die Bezeichnung Arbeit Einheit Personentage PT Personenstunden PH etc Aufwandssch tzung Absch tzung des zur Abarbeitung eines Arbeitspakets notwendigen Aufwandes 100 reine Projektarbeit sowie der Bearbeiter Sie basiert vor allem auf Erfahrungen und ist die Grundlage f r die Kapazit ts und Terminplanung Balken Netzplan vernetzter Balkenplan Erweiterung des Balkenplans um die Darstellung der Abh ngigkeiten zwischen den Arbeitspaketen Balkenplan Gantt Diagramm Diagramm zur Visualisierung der Zeitplanung eines Projektes Die Dauer eines Arbeitspakets wird durch die L nge des Balkens in der Zeitachse symbolisiert Die Balken k nnen sowohl Ist als auch Soll Daten umfassen Ereignisse werden als Zeitpunkte dargestellt Belastungsdiagramm Graphik zur Visualisierung der Belastung von Mitarbeitern oder Abteilungen durch Arbeitspakete aus ein oder mehreren Projekten Dauer Zeitspanne vom Anfang bis zum Ende eines Arbeitspaketes Einheit Tage Stunden Wochen etc Sie wird entweder direkt gesch tzt oder richtet sich nach der Bearbeitungsdauer der einzelnen Ressourcen Einsatzplanung Ressourcenplanung Planung des zeitlichen Einsatzes der an der Projektdurchf hrung
20. Einschr nkungen untersucht und bewertet Es tauchen in der Regel Fragen Unsch rfen und Unw gbarkeiten auf die jede Entscheidung f r oder wider eine Alternative bzw die Verwerfung aller Alternativen zu einer unsicheren Entscheidung machen Unsichere Entscheidungen sind aber Risikoquellen des Projekts Der Grad der Unsicherheit bzw das Risiko sollte daher immer unter Ber cksichtigung der zugeh rigen Kosten soweit wie m glich reduziert werden Dazu k nnen unterschiedliche Techniken wie z B Prototyping Simulation Datenmodellierung oder Benchmark Tests eingesetzt werden 12 7 2 3Realisierung und Pr fung des Zwischenprodukts Im dritten Schritt der aktuellen Windung wird die gew hlte Alternative unter Einhaltung der Ziel und Ressourcenvorgaben realisiert getestet und Qualit tsgesichert Die Entscheidung f r eine einzusetzende Methode bzw eine sinnvolle Kombination mehrerer Vorgehensweisen erfolgt Risikoorientiert und jeweils nur f r die aktuelle Windung 12 7 2 4Planung der Projektsetzung Zum Abschluss der aktuellen Windung wird auf der Grundlage des aktuellen Projektstands die n chste Spiralwindung inhaltlich und organisatorisch geplant Die Planung muss nicht auf die unmittelbare Phase beschr nkt bleiben Sie kann mehrere Windungen betreffen M glich ist auch die Aufteilung des Projektes in weitgehend unabh ngige Teilprojekte die von verschiedenen Entwicklungsteams parallel durchgef hrt und erst zu einem sp teren Zeitp
21. Entwicklung selbst durchgef hrt wird Die Gliederung des Submodells SE ist gepr gt durch Aktivit ten auf folgende drei verschiedene Ebenen e Systemebene e Segmentebene e Ebene der Software und Hardwareeinheiten Entscheidend sind diese Ebenen aus Sicht des Systementwicklungsprozesses sowohl in den zeitlichen fr hen Aktivit ten um berhaupt zur Software und Hardware zu gelangen als auch in den sp teren Aktivit ten um von der Software und Hardwareebenen aus zum Gesamtsystem kommen Die nachstehende Abbildung gibt eine bersicht ber die in diesem Submodell enthaltenen Aktivit ten und stellt auch gleich die entsprechenden Komponenten der Qualit tssicherung dar Fachliche Fein konzeption Detaillierte Modul beschreibung Ergebnisfllu Korrektur Pr fung Kor Abbildung 20 Submodell SE im V Modell Seite 107 Leitfaden Projektmanagement KM entspricht ISO 12207 Seite 108 Q Office 2 Heip 12 7 3 3Submodell KM Das Ziel des Konfigurationsmanagements KM besteht darin sicherzustellen dass ein Produkt bez glich seiner funktionellen wie auch u eren Merkmale wie z B Dokumente eindeutig identifizierbar ist Diese Identifikation dient der systematischen Kontrolle von nderungen und zur Sicherstellung der Integrit t Das Konfigurationsmanagement im V Modell 97 berwacht entsprechend ISO 12207 die Konfiguration w hrend der gesamten Entwicklung so dass die Zusammenh nge und Unters
22. Gro projekt wahrnehmen bevor sie diese in Eigenverantwortung an ein gr eres Projekt herangehen lassen Mit der Einf hrung von Prozessmodellen wird besonders die Projektleitung von gro en Projekten vereinfacht Dem unerfahrenen Projektleiter stehen Richtlinien zur Verf gung die im Idealfall aus Praxiserfahrungen der Prozessautoren stammen wie beim Rational Unified Process Dadurch kann der Projektleiter sich wesentlich sicherer bewegen seine Planung sowohl hinsichtlich Budget als auch Ressourcen kann er auf Basis bereits vorliegender Ergebnisse vornehmen Das bedeutet nat rlich dass dies nicht gleich bei der ersten Verwendung eines Prozessmodells so sein wird sondern erst nach einigen Projekten der Fall ist Die Vorteile von Prozessmodellen sind ferner darin zu sehen dass ein Prozessmodell die Basis f r die Kommunikation mit dem Auftraggeber ist Das bedeutet jedoch auch dass das verwendete Prozessmodell bis zu einem gewissen Grad anpassbar sein muss wie im Vorherigen Abschnitt dargestellt da kein Auftraggeber ein vorgefertiges Prozessmodell akzeptieren wird Das Prozessmodell muss dem Auftraggeber die M glichkeit geben individuelle Anpassungen beim Entwicklungsprozess des Auftragnehmers vornehmen zu k nnen Seite 131 Q Office 2 Heip Der Rational Unified Prozess ist flexibler anpassbar Verschiedene Auspr gungen des Projekt Managements Prozessmodelle vereinfachen die Projektleitung Prozessmodelle regeln
23. PI etc Koordination aller IT Aktivit ten Sys PI Beratung zu Datenschutz Datensicherheit SI Unterst tzung zu Teststrategie MuT Unterst tzung bei QS von Fachfeinkonzept MuT DV Feinkonzept Beratung zu Datenbank Design ZDM QS Ma nahmen Daqtenbank Design Abnahme ZDM Generierung der Datenbank ZDM Programmierung Beratung zur Anwendung von Programmierrichtlinien MuT Integration und Systemtest Beratung zu Integration und Systemtest MuT Seite 184 Leitfaden Projektmanagement Q Office 2 Heip Projektaktivit t Bereich Einf hrungsvorbereitung Beratung zu Einf hrungsaktivit ten allgemein Beratung zu Erstellung RZ Handb cher Betrieb Tuning Datenbank Installation der Systeme Planen und durchf hren Schulungsma nahmen Verfahrenstest Beratung zu Verfahrenstest Abnahme der Sw in die Produktion Legende t Strategie OSSR Tools Zentrales Datenmanagement ZDM Qualit tssicherung Ss 3 Systemplanung __ SysPI i CSS Seite 185 Leitfaden Projektmanagement Q Office 2 Heip Seite 186 19 4Checkliste f r die Anwendung von Methoden und Techniken Die folgende in Tabellenform dargestellte Checkliste soll Anregungen vermitteln hinsichtlich der M glichkeit der Anwendung bestimmter Methoden und Techniken in Rahmen eines gew hlten Probleml sungsverfahrens In den Zeilen sind die als besonders wichtig betrachteten Methoden und Techniken angef hrt In den Spalten sind m
24. Projektabschluss ist notwendig um formal festzustellen welche Ergebnisse das Projekt geliefert hat und ob alle Projektaufgaben erledigt und die Ziele erf llt wurden Dabei soll der Projektleiter und das Team formal entlastet werden Der Projektabschluss wird in einer Abschlusssitzung Abschluss Review festgestellt und in einem Projektabschlu bericht analysiert und dokumentiert Themen des Abschluss Reviews sollten zus tzlich sein welche Folgeaktivit ten m ssen nach Abschluss noch getan werden was wer bis wann R ckschau auf Projektverlauf Positives Negatives Lerneffekte f r Projektbeteiligte Erfahrungssicherung f r k nftige Projekte fachlich methodisch administrativ ggf Anerkennung und Kritik Damit die Erfahrungen die die Projektgruppe w hrend der Projektlaufzeit gesammelt hat auch f r Folgeprojekte von Nutzen sein k nnen soll auf jeden Fall eine Erfahrungssicherung vorgenommen werden Dies sollte unbedingt in schriftlicher Form geschehen damit die Einzelpunkte gezielt ausgewertet und Verbesserungen durch die beteiligten Funktionen zust ndigen Stellen eingeleitet werden k nnen Weiterhin sollte ein Vergleich zwischen urspr nglicher Planung und den Ist Werten des Projektverlaufs vorgenommen werden Hier ist interessant festzuhalten weshalb Plan Werte nicht eingehalten werden konnten bzw aus welchen Gr nden Plan nderungen vorgenommen werden mussten Die Vorschl ge k nnen sich auf verschieden Themenber
25. Reviews in welchen Arbeitsergebnisse z B Dokumente gepr ft werden Die Arbeitsergebnisse werden Experten vorgelegt welche diese einer kritischen Durchsicht unterziehen siehe auch Leitfaden Qualit tsmanagement Es ist nicht Aufgabe des Qualit tsreviews L sungen zu erarbeiten sondern sie dienen der Absicherung der Arbeitsergebnisse der einzelnen Phasen Die Einberufung erfolgt durch den Projektleiter kann aber auch an den Autor der Arbeitsergebnisse oder den genannten Moderator delegiert werden e Die Vorbereitung des Qualit tsreviews liegt in der Verantwortung des Autors Er ist daf r verantwortlich dass die f r das Review ben tigten Unterlagen 3 Tage vor dem Review bei den eingeladenen Experten vorliegen e Alle Projektmitarbeiter stellen ihre Ergebnisse in einem Qualit tsreview vor e Diskussionsleitung und ablauf e F rjedes Review muss ein Moderator benannt werden dessen Aufgabe es ist das Review zu leiten Er ist weiterhin daf r verantwortlich dass im Review Ergebnisse erarbeitet werden und dass diese Ergebnisse dokumentiert werden e Personalvorgesetzte sollen i d R bei Qualit tsreviews nicht anwesend sein e Ergebnisse der Reviews dienen nicht der Mitarbeiterbeurteilung Leitfaden Projektmanagement Q Office 2 Heip 19 2Profilbeschreibungen Projektmitarbeiter 19 2 1Projektleiter aus Fachbereichen oder IT Funktion und Er Sie Verantwortung e erarbeitet Konzeptionen und Architekturen der Inf
26. Sie hier den Zeitfaktor die zur Verf gung stehenden Ressourcen die Unterst tzung des Managements wie auch die Realisierbarkeit berpr fen Diese Investition an Vorarbeit zahlt sich absolut aus wenn man an die Kosten denkt die bei einem gescheiterten Projekt wegen Nichtdurchf hrbarkeit anfallen Seite 77 Q Office 2 Heip Eine endlose Liste von Gr nden f r das scheitern von Projekten Viele Projektverantwo rtliche wollten gar nicht wahrhaben dass ihr Projekt gescheitert ist Leitfaden Projektmanagement To Office 2 Heip Seite 78 e Pr fbarkeit Wie l sst sich pr fen oder messen ob das Ziel erreicht wurde Bereits w hrend der Projektabwicklung ist die berpr fung von Teilzielen Meilensteinen wichtig Nach Abschluss der Zieldefinition muss unbedingt eine Abnahme der Zieldefinition durch den Auftraggeber erfolgen So k nnen an dieser Stelle nochmals Missverst ndnisse oder Kommunikationsfehler vermieden werden Das Ziel muss jetzt allen Projektbeteiligten im Kick Off Meeting mitgeteilt werden Oft wird diesem wichtigem Punkt nicht die Bedeutung beigemessen oder er wird gar ganz vergessen Was n tzt eine ausf hrliche und detaillierte Zieldefinition wenn diese nicht an die Beteiligten kommuniziert wird Jeder der Beteiligten muss sich letztendlich hinter das Ziel stellen damit es erreicht werden kann 10 1 2Das Ziel ndert sich w hrend der Projektarbeit Dieses Problem kann aus einem nicht klar defini
27. So beschreibt das V Modell XT eine ziel und ergebnisorientierte Vorgehensweise Diese Grundphilosophie ist an vielen Stellen sichtbar Seite 113 Leitfaden Projektmanagement Q Office 2 Heip Seite 114 e Entscheidungspunkte der Projektdurchf hrungsstrategien geben den bergeordneten Projektsteuerungsrahmen durch die logische Reihenfolge der Produktfertigstellung vor e Detaillierte Projektplanung und steuerung wird auf Basis der Bearbeitung und Fertigstellung von Produkten durchgef hrt e Jedem Produkt ist eindeutig eine verantwortliche Rolle zugeordnet e Die Produktqualit t ist durch Anforderungen an das Produkt und explizite Beschreibung der Abh ngigkeiten zu anderen Produkten berpr fbar Abbildung 24 Das V Modell XT Projakt Projekt karat on Projekt genehmigt efiewert geplant abgeschlossen 5 O m l a Alle V Modal rojekte Organisalionsspezifsches N ian en Vorgehersmodell Worgehansmodall Verbesserung Verbesserung analysiert Vorgelrensmodell konzipiert Vorgehansmodel realisiert Die IABG brachte in das Projekt WEIT das gesamte Know how aus der Entwicklung aller V Modell Vorg ngerversionen mit ein Dar ber hinaus bearbeitete sie die Themen Projektmanagement Anforderungserfassung Qualit tssicherung Benutzbarkeit und Ergonomie nderungsmanagement Systemsicherheit sowie die Abbildung auf die Standards ISO 15288 und CPM Leitfaden Projektmanagement Q Office 2 Heip 12 7 5Der Microsoft
28. besteht zwischen denen festgelegte Beziehungen existieren und die bestimmte Funktionen erf llen Ausgangspunkt jeder Systembetrachtung ist das Erfassen Verstehen und Ordnen der in einem System bestehenden Beziehungen Dazu wird das System soweit in seine Teilbereiche als Elemente bezeichnet zerlegt bis alle Einzelelemente voneinander abgegrenzt und die Beziehungen zwischen den Elementen sichtbar sind Dieser Vorgang wird Strukturierung genannt Strukturiertes Vorgehen macht komplexe Aufgaben transparenter und damit leichter handhabbar Das gilt f r die Systembetrachtung ebenso wie f r das Projektmanagement Strukturieren und das Verstehen komplexer Systemen k nnen Sie aus der Systemtheorie lernen Aber vermeiden Sie unn tige und k nstliche Grenzen innerhalb des Systems und ber das System hinaus Grenzen k nnen schnell einmal auch zu un berwindlichen H rden werden Um aber das Gesamtziel nicht aus den Augen zu verlieren sind die Einzelaspekte nicht f r sich allein sondern als Bestandteil eines umfassenden Ganzen zu betrachten Es gilt den ber hmten Blick ber den Tellerrand zu wagen Dieser Seite 41 Leitfaden Projektmanagement TOJ Office 2 Heip Seite 42 grundlegende Denkansatz wird als Systemdenken oder auch als ganzheitliches Denken bezeichnet Durch das Denken in Zusammenh ngen ber die Grenzen des eigenen Fachbereichs und der eigenen wissenschaftlichen Spezialisierung hinaus lassen sich Inse
29. beteiligten Ressourcen abh ngig von ihrer Verf gbarkeit Endfolge Anordnungsbeziehung vom Ende eines Arbeitspaketes zum Ende seines Nachfolgers d h Arbeitspaket B kann erst abgeschlossen werden wenn Arbeitspaket A bereits abgeschlossen ist Endzeitpunkt Auf Basis der Ablaufplanung errechnetes oder fest definiertes Ende eines Arbeitspaketes Abh ngig von der Berechnungsmethode ergeben sich e Fr hester Endzeitpunkt Vorw rtsrechnung e Sp tester Endzeitpunkt R ckw rtsrechnung Entscheidungsgremien Leitfaden Projektmanagement Q Office 2 Heip Instanzen der Projektorganisation wie z B Lenkungsteam Steuerungskreis Controlling Ausschu usw Sie sind i d R daf r zust ndig projekt bergreifende Konflikte zu l sen und Priorit ten zu vergeben Fertigstellungsgrad Prozentsatz zu dem die Arbeiten an einem Arbeitspaket abgeschlossen sind Freier Puffer Der Zeitraum um den ein Arbeitspaket im Netzplan verschoben werden kann ohne 199ass ein anderes Arbeitspaket ebenfalls verschoben wird Gantt Diagramm Balkenplan Diagramm zur Visualisierung der Zeitplanung eines Projektes Die Dauer eines Arbeitspakets wird durch die L nge des Balkens in der Zeitachse symbolisiert Die Balken k nnen sowohl Ist als auch Soll Daten umfassen Ereignisse werden als Zeitpunkte dargestellt Gesamtpuffer Zeitraum um den ein Arbeitspaket im Netzplan verschoben werden darf ohne dass das Projektende verschoben werden muss I
30. des Software Engineering Prozesses war Lediglich der Erfolg den die Prozessmodelle letztendlich zu verzeichnen hatten war unterschiedlich gelagert 12 7 1Das Wasserfallmodell Wenn eine bersicht der Prozessmodelle aufgebaut wird darf dieses Modell nat rlich nicht fehlen Es ist das erste Modell das eine koordinierte Software Entwicklung beschreibt Die nachstehende Abbildung beschreibt das Prinzip des Wasserfallmodells Voraussetzung daf r ist eine moderne Management Einstellung die lauten muss Fehler sind dazu das dass man daraus lernt Leitfaden Projektmanagement i Q Office 2 Heip Abbildung 17 Wasserfallmodell Aus der Abbildung wird deutlich dass das Wasserfallmodell ein Vorgehensmodell ist das sich ausschlie lich an dem Faktor Zeit orientiert Demzufolge ist auch der Prozess aufgebaut Er teilt sich in die folgenden Aktivit ten auf Gesch ftsprozesse modellieren und Anforderungen aufnehmen Entwurf Analyse und Design Entwicklung Implementierung Test Verteilung und Wartung Dieses Modell hat sich in vielen Projekten beweisen k nnen hat jedoch in noch viel mehr Projekten versagt Entscheiden f r den Erfolg des Wasserfallmodells ist dass eine Art von Projektskizze existiert Die keinerlei nderungen mehr zul sst Sobald Auftraggeber und Auftragnehmer sich ber diese Vorgehensweise einig sind und dies auch vertraglich festgehalten haben ist das Wasserfall Modell sehr gutes Instrument f r Softwa
31. desto wichtiger ist es dass die Projektmitarbeiter regelm ig und offen miteinander reden Betrachtet man die drei wesentlichen Rollen innerhalb eines Projektes Analysten Entwickler und Tester Qualit tssicherung Rollen und Phasen bergreifend jedoch mit Schwerpunkt im Bereich Testen so hat in der Vergangenheit besonders die fehlende Kommunikation zwischen Entwickler und Tester zu gro en Schwierigkeiten in Projekten gef hrt Ebenso herrschen zum Teil einzelnen Dom nen un berwindbare Abgrenzungen zwischen den Anforderungsmanagement Change Management Testen und Qualit tssicherung Modellierung Besonders Analysten und Tester haben oft berhaupt keine Beziehung zueinander Durch den von Rational entwickelten Rational Unified Process RUP werden die bisherigen Grenzen zwischen diesen und anderen Rollen aufgehoben So werden beispielsweise die vom Analysten erstellten Use Cases Anwendungsf lle als Test Use Case vom Tester weiterverwendet Ebenfalls unter dem Aspekt der mangelnden Kommunikation f llt der Einsatz diverser Werkzeuge die ebenfalls in den meisten F llen nicht miteinander kommunizieren k nnen Sicherlich ist der Tooleinsatz Werkzeigansatz erforderlich und unabdingbar doch was n tzt das beste CASE Tool wenn keinerlei Schnittstelle zu einem Anforderungsmanagementwerkzeug existiert Aber es treten jedoch noch weitere Schwierigkeiten beim Einsatz diverser Werkzeuge v
32. die Kommunikation des Projektleiters mit dem Auftraggeber Leitfaden Projektmanagement To Office 2 Heip Fingerspitzen gef hl ist gefragt Seite 132 Nat rlich ist hier ein gef hrlicher Grad zu erkennen da der Auftragnehmer sich nicht in die wesentlichen Bestandteile seiner Vorgehensweise bei der Softwareerstellung hineinreden lassen m chte In einem solchen Fall ist dann der Projektmager gefragt mit seiner Erfahrung aber auch mit seinen Managementf higkeiten mit dem Auftraggeber sich auf ein gesundes Ma der Anpassung zu einigen Das hei t das der Auftraggeber sic wiederfindet und gleichzeitig des Entwicklungsteam seinen Prozess nicht umstellen muss 12 10Zusammenfassung Dieses Kapitel hat die Bedeutung von Prozessmodellen f r die Softwareentwicklung herausgestellt Die in den letzten Jahren bedeutenden Prozessmodelle waren Das Wasserfallmodell Das Spiralmodell Das V Modell Der Microsoft Solutions Framework Der Rational Unified Process Eine der wesentlichen Anforderungen an Prozessmodelle ist die Anpassbarkeit an die individuellen Gegebenheiten in einem Unternehmen Allen Modellen gemeinsam ist dass Sie mit den gleichen Hintergrund entwickelt wurden n mlich den Softwareentwicklungsprozess zu koordinieren Weniger gemeinsam ist der Erfolg den diese Modelle zu verzeichnen haben W hrend das Wasserfall Modell in der Gesamtheit versagt hat jedoch im Rational Unified Process f r einzelne Iterationen
33. die Ressourcenplanung eigentlich machen m sste der Projektleiter oft in Verbindung mit F hrungskr ften in den Linienbereichen ohnehin schon stark belastet ndern sich die Daten sehr h ufig und werden sie nicht korrekt und laufend nachgef hrt ist die Ressourcenplanung ohnehin nicht korrekt und kann gleich beendet werden Hier hilft nur eine radikale Reduzierung der Datenmengen Eine nach einheitlichen Regeln mit einem definierten Grad an Unsch rfe durchgef hrte Ressourcenplanung ist mehr wert als der zum Scheitern verurteilte Versuch die Realit t exakt im Projektplanungssystem abzubilden Seite 45 Leitfaden Projektmanagement Q Office 2 Heip Seite 46 5 7 10Die Datenpflege Der Pflegeaufwand f r die Daten hat interessanterweise eine U Form Es scheint eine optimale Menge an Projektt tigkeiten pro Projekt zu geben bei der der Ressourcenplanungsaufwand das optimale Ma erreicht Sind die Projekte sehr kurz sind die nderungen darin sofort von Bedeutung f r die Ressourcenplanung Sind Projekte sehr lang und damit sehr gro ist die bersicht eingeschr nkt und es kommt zu vielen nderungen in der Logik und zu fehlenden T tigkeiten die eine erneute berarbeitung erzwingen Damit verbunden auch v llig andere Ressourcenauslastungen und erneute Belastungen Die Kunst des richtigen Detaillierungsgrades muss erlernt werden Erst durch eigene Erfahrung kann man sagen wann ein Projekt in welchem Ma e gegliedert we
34. die Verbindung zwischen der IT und den Anforderungen der Organisation her Durch die Gesch ftsanforderungen werden die IT Anforderungen formuliert IT Infrastructure Management Umfasst die Planung Entwicklung und Wartung der IT Infrastruktur Application Management Beschreibt ein Vorgehensmodell f r bereits vorhandene aber auch neue Applikationen Beinhaltet gesamten Life Cycle von Applikationen und Softwareproduktion Seite 119 Leitfaden Projektmanagement Q Office 2 H elp Seite 120 12 7 8Prince Prince 2 PRINCE2 oder Projects in Controlled Environments ist eine Projektmanagement Methode Sie behandelt Management Steuerung und Organisation eines Projekts Die Rechte an PRINCE2 liegen beim OGC Office of Government Commerce Dass OGC tr gt auch die Verantwortung f r Zertifizierungen Abbildung 29 Prince Modell Unternehmens Programm Management Die Pfeile in der Grafik symbolisieren Informationsfl sse Die Methode ist wiederholbar und kann gelehrt werden ist flexibel und kann an die Anforderungen des Projekts angepasst werden stellt sicher dass der Bezug zum Gesch ft nicht verloren geht geht durch management by exception sparsam mit der Zeit der Beteiligten um Unn tige Routine entf llt Was ist PRINCE2 PRINCE 2 ist eine Methode die ein skalierbares Vorgehensmodell definiert abgeleitet aus erfolgreichen und gescheitertern Projekten Was nicht ben tigt wird kann weggelassen werden weni
35. diesem Grund ist es ausgesprochen wichtig die Neben oder auch Rahmenbedingungen in einem Projekt fr hzeitig zu analysieren und entsprechend zu ber cksichtigen W hrend sich das mit klar definierten Rahmenbedingungen wie gesetzlichen Regelungen relativ einfach bewerkstelligen l sst wird diese Planung im personellen Bereich schon schwieriger Hier lassen sich zwar ebenfalls manche beeinflussende Faktoren fr hzeitig erkennen Wer beispielsweise einen lange geplanten Urlaub erst sp t in seine Projektplanung einbezieht ist selbst schuld Es gibt auf der anderen Seite aber auch eine ganze Menge an Faktoren die nicht so ohne weiteres planbar sind Krankheiten und Unf lle sind ein Beispiel daf r Aus Sicht des Projektmanagers spielen dar ber hinaus auch noch die weichen nicht messbaren Faktoren eine Rolle die sich aber in einem Projekt im Laufe der Zeit durchaus bemerkbar machen k nnen Von diesen Faktoren werden Projekte in beachtlichem Umfang betroffen e Bei Projekten an denen mehrere Abteilungen oder Bereiche eines Unternehmens beteiligt sind kommt es h ufig vor dass sich bestehende Konflikte zwischen den Abteilungen Bereichen auch auf das Projekt auswirken Das kann sich beispielsweise darin u ern dass die Abstellung von Mitarbeitern behindert wird oder regelm ig deutlich gemacht wird dass das Projekt eine deutlich niedrigere Priorit t als das Tagesgesch ft der Abteilung beziehungsweise des Bereichs hat e Projekte wer
36. eine Unterst tzung des Projektleiters falls dieser im Recht ist Daraus resultiert aber auch eine erzieherische Aufgabegegen ber dem Projektleiter falls dieser sich verrennt Der Auftraggeber ist auch f r die Qualit t des Projektleiters verantwortlich und muss reagieren falls er dort eine Fehlbesetzung vorgenommen hat e Der Auftraggeber muss bei der Definition von Meilensteinen mitarbeiten und sich bei der Festlegung von Priorit ten im Projekt einbringen soweit es dabei Unklarheiten gibt In jedem Fall ist er eine Kontrollinstanz die Leitfaden Projektmanagement Q Office 2 Heip sicherstellen muss dass beispielsweise Meilensteine gesetzt sind und an diesen Meilensteinen auch etwas geschieht Der Auftraggeber beziehungsweise Sponsor ist derjenige der sicherstellt dass ein Projekt in einem Unternehmen auch wirklich durchgef hrt werden kann Er ist vor allem dann von gro er Bedeutung wenn der Projektleiter nicht die hierarchische Position hat um aufgrund dieser den Erfolg der Projektarbeit sicherzustellen Und das ist meistens der Fall da die eigentliche Projektleitung praktisch immer delegiert wird Er ist damit eben letztlich auch die Person die f r den Projektleiter verantwortlich ist Ein starker Sponsor kann sehr deutlich zum Gelingen eines Projekts beitragen Das Fehlen eines solchen Sponsors ist f r das Scheitern vieler Projekte verantwortlich Diese Problematik stellt sich bei vielen Projekten So ist es f r ein
37. geleitet von einem Projektleiter der das Projektteam zusammenstellt und die Kommunikation innerhalb des Teams nach au en quer ber alle horizontalen Funktionsbereiche sicherstellt Seite 15 Leitfaden Projektmanagement To Office 2 Heip Normen Projekt Grunds tze Seite 16 5Definition eines Projektes Auch wenn Normen die Praxis nicht immer sinnvoll beschreiben stellt die DIN Norm 69 901 doch einen guten Ausgangspunkt dar um die erforderliche Klarheit ber diesen Begriff zu erreichen In der Norm DIN 69 901 wird einer der Wortbestandteile das Projekt definiert Der zweite Bestandteil das Management wird in diesem Leitfaden noch einer n heren Betrachtung unterzogen 5 1Das Projekt Ein Projekt ist gem DIN 69 901 ein komplexes Vorhaben das durch folgende Kriterien gekennzeichnet ist e Zielvorgabe durch Beschreibung einer komplexen Aufgabe e personelle sachliche finanzielle und zeitliche Abgrenzung gegen ber anderen Vorhaben e Beteiligung mehrerer Organisationseinheiten die in einer projektspezifischen Organisation zusammengefasst werden e Einmaligkeit der Bedingungen Was in der Definition deutlich wird ist der Unterschied von Projekten und Routineaufgaben Projekte unterscheiden sich von Routineaufgaben dadurch dass neue noch unbekannte oder in dieser Kombination unbekannte Anforderungen und Teilaufgaben auftreten Die Einmaligkeit dieser Bedingungen ist ein sehr wesentliches Element eines Projekts
38. geplant wurden vor allem wenn solche Terminverschiebungen erst sp t im Projekt auftreten Auch gutes und softwaregest tztes Projektmanagement wird das nicht verhindern k nnen Gutes Projektmanagement kann aber Terminverschiebungen fr hzeitig erkennen und damit fr her handeln Gegen unerwartete Einfl sse ist man auch dann nicht gefeit Die ber l ngere Zeit absehbaren Verschiebungen werden aber fr h deutlich Ein guter Projektmanager wird diese auch fr hzeitig adressieren selbst wenn er damit auf politische Widerst nde in seiner Organisation st t Wenn aber deutlich gemacht wird welche Probleme es gibt und wie diese gel st werden k nnen ist das zu einem fr hen Zeitpunkt f r das Standing des Projektmanagers allemal besser als sehr sp t einzugestehen dass das Ziel nicht zu halten ist Wenn das Kind erst einmal in den Brunnen gefallen das Terminziel also definitiv verfehlt ist und dann erst Alarm geschlagen hat hat der Projektmanager seinen Job nicht gut gemacht Neben diesen Zielen die es zu erreichen gilt gibt es bei jedem Projekt auch noch Nebenbedingungen Zu diesen Nebenbedingungen geh rt die Verf gbarkeit von Seite 21 Leitfaden Projektmanagement To Office 2 Heip Seite 22 Ressourcen geh ren gesetzliche Rahmen beispielsweise bei Entwicklungsprojekten Genehmigungsverfahren und dergleichen mehr Alle diese Nebenbedingungen k nnen den Verlauf des Projekts durchaus entscheidend beeinflussen Aus
39. herumpfuscht wird es brechen Wenn es klemmt wende Gewalt an Wenn es kaputt geht h tte es sowieso erneuert werden m ssen Maschinen die versagt haben funktionieren einwandfrei wenn der Kundendienst ankommt Konstruiere ein System das selbst ein Irrer anwenden kann und so wird es auch nur ein Irrer anwenden wollen Jeder hat ein System reich zu werden das nicht funktioniert In einer Hierarchie versucht jeder Untergebene seine Stufe der Unf higkeit zu erreichen Man hat niemals Zeit es richtig zu machen aber immer Zeit es noch einmal zu machen Sind Sie im Zweifel murmeln Sie Sind Sie in Schwierigkeiten delegieren Sie Alles Gute im Leben ist entweder ungeseitzlich unmoralisch oder es macht dick Murphys goldene Regel Wer zahlt schafft an Die Natur ergreift immer die Partei des versteckten Fehlers Eine Smith und Wesson bertrumpft vier Asse Hast Du Zweifel lass es berzeugend klingen Diskutiere nie mit einem Irren die Leute k nnten den Unterschied nicht feststellen Freunde kommen und gehen aber Feinde sammeln sich an Sch nheit ist nur oberfl chlich aber H sslichkeit geht durch und durch Um etwas sauberzumachen muss etwas anderes dreckig werden Aber Du kannst alles dreckig machen ohne etwas sauber zu bekommen Jedes technische Problem kann mit gen gend Zeit und Geld gel st werden Du bekommst nie genug Zeit und Geld Leitfaden Projektmanagement Q Office 2 Heip Wenn Baumeis
40. ist Diese Ausrichtung kann zuerst existieren ein Projekt kann ebenso selbstverst ndlich zur Revision bestehender Ausrichtungen anregen und beitragen Werden Entwicklungen im Anwenderbereich autonom durchgef hrt die zu irgend einem Zeitpunkt Ressourcen von der Kunden IT beanspruchen z B Anschluss an Host System Betreuung so ist eine Abstimmung und technische Pr fung mit den entsprechenden Organisationseinheiten erforderlich Bei gr eren Projekten ist es sinnvoll und hilfreich den Projektplan bzw die Teilpl ne mittels eines DV gest tzten Planungstools zu erstellen und zu pflegen Hinweis F r Projekte ist MS Project als Planungswerkzeug festgelegt 16 2Projektkontrolle und steuerung Projektkontrolle ist ausgerichtet auf die berwachung des Projektes aber dient nicht zur Kontrolle der Mitarbeiter Zur berpr fung der Planung und Feststellung des Zustandes eines Projektes werden Reviews durchgef hrt Reviews sind von ihrer Funktion her Einrichtungen deren Aufgabe es ist durch kritische Durchsicht und Pr fung von Ergebnissen und Projektsituationen Probleme und Fehler aufzudecken Die Termine der Reviews werden im Projektplan festgehalten Abh ngig von der Zielsetzung werden verschiedene Reviewtypen angesetzt e Statussitzungen siehe Anhang e Qualit tsreviews siehe Leitfaden Qualit tsmanagement Leitfaden Projektmanagement To Office 2 Heip Um das Projekt erfolgreich zum Ziel zu f hren m ssen w h
41. k nnen so hilft Ihnen hier nur eine Sch tzung die Sie dann anhand der Erfahrungen Ihres Projektteams durchf hren sollten Einige Tipps um Risiken zu erkennen Verwenden Sie das PERT Analyse Werkzeug aus Microsoft Project um eine Aussage zu bekommen wie genau Sie Ihren Zeitplan einhalten Wenn sich die Zeitdauer Ihrer Aufgaben deutlich von denen der PERT Analyse unterscheiden so ist das ein sicheres Zeichen f r ein erh htes Risiko e Betrachten Sie die Zeitpl nen und Ergebnisse von bereits abgewickelten Projekten um herauszufinden ob in der Vergangenheit hnliche Aufgaben l nger dauerten oder zu h heren Kosten gef hrt haben e Sprechen Sie mit ihrem Team Ressourcen und finden Sie heraus inwieweit die von Ihnen gemachten Planungen mit den eigenen Sch tzungen der Ressourcen bereinstimmen Wenn die durchf hrenden Ressourcen nicht mit Ihrem Plan bereinstimmen so haben Sie m glicherweise ein erh htes Risiko e Weisen Sie jedem Risiko eine Kostensch tzung zu 15 1 2 3Risiken Messen Wie kann man Risiken Messen Nun zum einen in verlorenem Geld zum anderen in verlorener Zeit oder auch in verlorener Qualit t M glicherweise und das ist der schlimmste Fall auch in allen drei genannten Punkten Versuchen Sie die Kosten eines Risikos einzusch tzen Sollte Ihnen dies nicht exakt m glich sein so verwenden Sie eine Bandbreite wie z B 25 000 50 000 DM Eine andere M glichkeit der Kostenfindung ist es den Projektplan
42. ltigung nehmen bis zu 20 der Zeit und Energie von Projekt Managern in Anspruch 8 4 4 1Konfliktmanagement Konflikte sind sozialer Kampf um Werte Status Macht Ziele Einfluss Liebe und Mittel Ausdruck f r gestaute Energie und Zeichen f r Identifikation und Motivation nervig unangenehm und unbequem bisweilen anstrengender Energieverlust Chancen f r Entwicklungen Verbesserungen und die Bew ltigung tieferliegender Krisen und Spannungen in mir selbst bzw zwischen Partnern Gruppen und oder Organisationen Seite 71 Leitfaden Projektmanagement Q Office 2 Heip Seite 72 8 4 4 2Basisstrategien der Konfliktbehandlung Flucht o Konflikte werden verdr ngt ausgeklammert auf die lange Bank geschoben Kampf o Konfliktl sung durch Zwang K ndigung Versetzung Druck Drohung Reglementierung Delegation o L sung durch Einschaltung von Hierarchien Einsatz von Gremien Aussch ssen Kompromiss o L sung durch Verhandlung nach dem Prinzip Jeder gibt und erh lt etwas Konsens o Erarbeitung durch Wille zum Konsens bei Beteiligten Eingehen auf Motive und Interessen 8 4 4 3Widerstand gegen Ver nderungen Ver nderungen rufen Unsicherheiten Missverst ndnisse und Interessensgegens tze hervor aus denen Widerst nde entstehen k nnen Signale f r solche Widerst nde sind Unlust Dienst nach Vorschrift Unzufriedenheit jammern Ratlosigkeit Desinteresse Stockende Entscheidungsprozesse Innere
43. nderungs w nsche und Problem meldungen nderungs verfahren Seite 154 16 2 3 nderungsmanagement Im Laufe eines Projekts k nnen sich aus verschiedenen Richtungen Anderungsw nsche und Problemmeldungen ergeben z B Initiator nderungserfordernis wunsch Gesetzgeber gesetzliche Regelung Auftraggeber nderung der gew nschten Funktionalit t Verallgemeinerung einer wiederverwendbaren Komponente Projekt intern technische nderung Um entsprechende nderungsantr ge zu bearbeiten ist ein definiertes nderungsverfahren notwendig das sich in folgende Schritte gliedert e Der dem Projektleiter vorgelegte nderungsantrag wird bewertet das Ergebnis dieser Bewertung ist ein nderungsvorschlag der insbesondere die L sungs alternativen und deren Auswirkungen auf die Rahmenpl ne Ressourcen Kosten Zeit darstellt vgl Mustergliederung nderungsvorschlag e Der Projektleiter oder in besonderen F llen das Review Board entscheidet anhand des nderungsvorschlags ber den nderungsantrag Entweder wird die nderung verworfen oder es wird eine L sungsalternative ausgew hlt und ein entsprechender nderungsauftrag vgl Mustergliederung nderungsauftrag erzeugt In jedem Fall ist die Entscheidung zu protokollieren e Der Projektleiter aktualisiert gegebenenfalls die entsprechenden Rahmenpl ne Ressourcen Kosten Zeit und leitet die nderung ein e Nach Durchf hrung der nderung erh lt der Initiato
44. nge Je mehr Werkzeuge desto mehr Schnittstellen Je mehr Schnittstellen desto mehr Koordinierungsbedarf Je mehr Koordinierungsbedarf desto h her die Fehleranf lligkeit Je h her die Fehleranf lligkeit desto wahrscheinlicher ein Produktivit tsverlust e Je h her der Produktivit tsverlust desto gr er die Wahrscheinlichkeit dass das Projekt scheitert Als Resultat unserer Betrachtung ergibt sich also dass um im Projekt einen durchg ngigen Informationsfluss zu erreichen sind Mauern abzubauen Dies geschieht unter anderem durch den Einsatz von miteinander integrierten Werkzeugen wie sie z B von Rational angeboten werden die noch dazu ber Leitfaden Projektmanagement Q Office 2 Heip offene Schnittstellen zu anderen auf dem Markt verf gbaren Werkzeugen anderer Hersteller verf gen 10 1 11Zu sp te Integration Einer der gr ten Fehler in Softwareentwicklungsprojekten ist die Big Bang Eine Big Bang Integration am Ende eines Projektes Integration ist t dlich Welche Auswirkungen eine zu sp te Integration haben kann wird aus der nachstehenden Tabelle ersichtlich bis zu 40 und mehr werden f r die Integration und die damit verbundenen Testma nahmen verbraucht Tabelle 5 Aufwendungen f r die Projektphasen herk mmlich Das Alarmierende an diesen Kennzahlen ist dass zu Projektbeginn f r die Integration und den Test eben nicht diese 40 der Aufwendungen
45. parallel ausgef hrt werden k nnen werden die Balken bereinander angezeigt Die Gantt Diagramme erm glichen einen schnellen berblick ber den zeitlichen Ablauf eines Projektes Tabelle 4 Die wichtigsten Projektmanagement Begriffe Seite 47 Leitfaden Projektmanagement Q Office 2 Heip Untere Eckwerte Projekte Seite 48 5 8Eckwerte f r Projekte 5 8 1Untere Eckwerte Bei der Generierung und Planung von Projekten sollten Sie sich bereits an dieser Stelle Gedanken machen welches die unteren und oberen Eckwerte f r eine Projektarbeit in Ihrem Unternehmen oder wenn Sie im Auftrag f r einen Kunden arbeiten f r den Kunden sind Ziel dieser Definition ist es kleinere Aufgaben nicht als Projekte zu definieren da bei solchen Projekten der Aufwand f r eine Projektstruktur oft den tats chlichen Nutzen bersteigt Gleiches gilt f r die Obergrenze bei Projekten Wird ein Projekt zu gro und damit un bersichtlich so sollten Sie es in ein Haupt und ggf mehrere Teilprojekte aufteilen Definieren Sie hier die unteren Eckwerte f r Ihre Projektarbeit oder oder oder Abbildung 7 Untere Projekt Eckwerte Die Kriterien f r ein Projekt sind genau dann erf llt wenn vorstehende Gr en mit sehr hoher Wahrscheinlichkeit berschritten werden Ein Projekt ist auch dann einzurichten wenn die Besonderheit der Aufgabe eine Organisation in Projektform erfordert Leitfaden Projektmanagement Q O
46. r solche die wegfallen bzw nach expliziter Besprechung Vereinbarung ber Zeit Kosten und Ressourcen und der Aufzeigung von dadurch entstehenden Risiken 11 3Realisierung Ausrichtung und Abarbeitung nach festgelegten Priorit ten und Meilensteinen Kontinuierliche Verfolgung und Bericht des Fortschritts w chentlich Implementierung unter Ber cksichtigung von Testbarkeit Wartbarkeit und Betriebsf hrbarkeit Es werden keine Design nderungen vorgenommen es sei denn als Ersatz f r Dinge die wegfallen bzw expliziter Besprechung Vereinbarung ber Zeit Kosten Ressourcen und Risiken 11 4Rollout und Betriebsf hrung Muss explizit bereits ab der Anforderungsanalyse ber cksichtigt geplant vorbereitet und begleitet werden Als Querschnittsaufgabe ber das gesamte Projekt hinweg kommt noch das Qualit tsmanagement hinzu In allen Bereichen gilt Aufgaben werden immer schriftlich fixiert und haben immer einen Beginn und Ende Termin sowie einen Eigner Protokolle werden im Zweifel immer von der Projektleitung geschrieben Leitfaden Projektmanagement Q Office 2 Heip 12Prozessmodelle Prozessmodelle werden von vielen Softwareentwicklern nur als eins bezeichnet Als Einschr nkung bzw Beschneidung ihres Freiheitsgrades durch Prozessmodelle werden kreative und k nstlerische F higkeiten unterdr ckt das ist so ziemlich der aggressivste Vorwurf der Prozessmodellen gegen ber vorgebracht wird Warum Proz
47. rlich nicht nur f r die Softwareentwicklung sonder auch f r andere Disziplinen wie z B der Gesch ftsprozessmodellierung Projekte in denen diese 80 20 Regel nicht beachtet werden geraten schnell in Gefahr sich zu verzetteln und immer mehr Gewicht auf Kleinigkeiten zu legen 10 2Zusammenfassung Dieses Kapitel hat verdeutlicht dass die Softwarekrise ausgel st durch unterschiedliche Ursachen noch lange nicht behoben ist Das gr te Problem ist sicherlich die fehlende Qualit tssicherung und das darin integrierte Testen von Software Doch gibt es eine Vielzahl weiterer Ursachen f r die Softwarekrise Unklare Anforderungen Wechselnde Technologien Zu sp te Integration Zu hohe Dokumentenorientierung Fehlende Vorgehensweisen Prozessmodelle Mangelnde Ausbildung der Projektmitarbeiter Fehlende Ressourcen f r die Projektabwicklung Nichtbeachten der 80 20 Regel Leitfaden Projektmanagement Q Office 2 Heip Dieser Leitfaden erhebt nicht den Anspruch die Softwarekrise zu l sen doch es vermittelt f r Projektleiter einige n tzliche Hinweise wie durch Verwendung von z B des Rational Unified Process RUP viele der oben aufgef hrten Ursachen bereits im Keim erstickt werden k nnen Doch soll dieses Buch ebenso zum Ausdruck bringen dass Disziplin also die Einhaltung von Prozessrichtlinien eine der wichtigsten Voraussetzungen ist eine Softwarekrise im eigen Unternehmen zu beheben oder besser noch Ihr vor
48. sich durchaus bew hrt ist das noch letztes Jahr so hoch gelobte V Modell mehr und mehr in Kritik Immer noch zu hohe Papierflut immer noch zu viel B rokratismus immer noch fehlender Pragmatismus Man merkt dass das V Modell von einer Beh rde beauftragt und ebenso von einem beh rden hnlichen Unternehmen entwickelt wurde Das dies einen erheblichen Einfluss auf die Akzeptanz des V Modells hat ist ganz offensichtlich Leitfaden Projektmanagement Q Office 2 Heip 13Anforderungs und Change Management Ein oft im Projektablauf vergessener Punkt ist das Anforderungs und Change Management In den meisten Projekten begn gt man sich beim Anforderungsmanagement auf die Spezifizierung der Anforderungen in der Projektanfangsphase Das reicht jedoch bei weitem nicht aus Die Aufgaben beim Anforderungsmanagement reichen ber die komplette Spanne eines Projektes Zu jeder Zeit muss klar sein ob die gesteckten Anforderungen auch erf llt werden und wenn nicht warum Nur dann ist es m glich in die Phase des Change Managements berzugehen um bereits w hrend des laufenden Projektes die neuen oder erweiterten Anforderungen in die Planung mit aufzunehmen Anforderungen in die Planung mit aufzunehmen hei t jedoch noch lange nicht das diese Anforderungen in der aktuellen Projektphase oder dem aktuellen Projekt realisiert werden m ssen oder k nnen Es hei t vielmehr dass im Rahmen eines aktiven Change Managements e Anforderungen festgelegt
49. terminiert 8 4 1Dimensionen des Projektmanagements e Psycho soziale Dimension Personenebene o Verhalten Kommunikation und Emotionen e Sachdimension o L sung von Problemen e Ablaufdimension o Planung und Steuerung des Projektablaufs e Organisationsdimension e Verh ltnis der Projektorganisation zur brigen Organisation Seite 68 Leitfaden Projektmanagement Q Office 2 Heip 8 4 2Dimensionen mE TOSAHRE Einf hrung und Ver nderung von PM VERaR Aeq die Kommunikations und Interaktionsbeziehung per betreffe gt Yanisation Konflikte Widerst nde Immer wenn Personer 2 iiU 2hieht dies auf 3 Ebenen Sachebene Aktionsebene Personenebene Oooo O Diese 3 Ebenen beeinflussen sich dauernd wechselseitig Die Personen Ebene beeinflusst dabei die beiden anderen Ebenen st rker als umgekehrt Seite 69 Leitfaden Projektmanagement Seite 70 Q Office 2 Heip 8 4 3Konsequenzen Sachebene Systematik Strukturierung Instrumente Motivation Kooperation Konflikte Leitfaden Projektmanagement Q Office 2 Heip 8 4 4Konfliktbew ltigung Eine richtige Konfliktbearbeitung ist eine Investition in die k nftige Arbeitssituation in der fach und hierarchie bergreifende Zusammenarbeit reibungsloser gelingt Permanente Flucht vor Konflikten bringt den gleichen Konflikt immer wieder als ungel stes Problem zur ck Und ihre Bew
50. und deren Hierarchien Sie zielt prim r auf eine schnelle Kommunikation und Erreichung der Projektziele ab Diese wird vom ernannten Projektleiter den beteiligten bzw betroffenen Bereichen vorgeschlagen und von dem Entscheidungsgremium Review Board Lenkungsausschuss in einer konstituierenden Sitzung genehmigt Nachdem ein Projekt beendet ist wird die Projektorganisation wieder aufgel st Weiterf hrende Aufgaben k nnen durch Folgeprojekte abgewickelt werden die ggf ihren Mitarbeiterstamm aus dem vorangestellten Projekt rekrutieren Es gibt einen Hauptverantwortlichen f r das Projekt den Projektleiter Ihm sind sowohl Mitarbeiter aus technischen Bereichen als auch die Mitarbeiter aus den beteiligten Fachbereichen tempor r technisch fachlich unterstellt W hrend der Projektlaufzeit delegieren die betroffenen F hrungskr fte nach Absprache sachliche und fachliche Verantwortung mit den erforderlichen Befugnissen an den Projektleiter Die personelle Verantwortung verbleibt bei den F hrungskr ften mit Personalverantwortung Die Abgrenzung der Verantwortung sollte bei Beginn schriftlich festgelegt werden Eine eindeutige Delegation ist ein wesentlicher Faktor f r den Erfolg eines Projektes und der Projektorganisation Die F hrungskr fte aller Ebenen sind verpflichtet steuernd und unterst tzend auf den Projektverlauf Einfluss zu nehmen insbesondere wenn es gravierende negative Abweichungen von den genehmigten Pl nen gibt We
51. von den Erfordernissen des Projektes und unter Ber cksichtigung des zu untersuchenden Bereichs legt der Projektleiter die anzuwendende Erhebungsmethode z B Interview Metaplan fest Dies muss in Abstimmung mit dem Auftraggeber den beteiligten Fachbereichen und dem Betriebsrat geschehen e Bei der Auswahl der Erhebungsmethode ist darauf zu achten dass die Methode ausgew hlt wird die Arbeitsabl ufe im zu untersuchenden Bereich m glichst wenig st ren e Die von der Erhebung betroffenen Mitarbeiter werden in einem Gespr ch zwischen Auftraggeber und Fachbereich festgelegt und schriftlich fixiert e Es ist Aufgabe des Projektleiters die Qualifikation der bei der Erhebung eingesetzten Projektmitarbeiter zu berpr fen und im Bedarfsfall diese Mitarbeiter zu schulen Seite 173 Leitfaden Projektmanagement Q Office 2 Heip e Es ist weiterhin Aufgabe des Projektleiters die Arbeit Erhebung seiner Mitarbeiter im Fachbereich zu steuern und zu berwachen Seite 174 Leitfaden Projektmanagement Q Office 2 Heip 19 1 3Regeln zur u eren Organisation des Projektes e Der Projektleiter stellt vor Beginn jeder Phase seine Personal anforderungen an die Bereiche zusammen Dazu sind anzugeben die Anzahl der Qualifikation der Mitarbeiter sowie Beginn Dauer und Intensit t der Abordnung f r das Projekt e Der Projektleiter leitet die Personalanforderungen an den Auftraggeber weiter der die Freistellung und Vertretung mit den Berei
52. werden Auch im Kick Off Meeting kann die Art und Weise der Kommunikation im Team gemeinsam erarbeitet und festgelegt werden Somit ist sichergestellt dass alle mit den Seite 87 Ein direkter Return on Investment l sst sich f r ein Prozessmodell nur sehr schwer errechnen Leitfaden Projektmanagement To Office 2 Heip Seite 88 Verfahrensweisen einverstanden sind da sie im Team gemeinsam festgelegt wurden Als Projektleiter sollten Sie eine offene Kommunikation vorleben und nicht z gern Probleme anzusprechen Sie sollten erkennen k nnen wenn Mitarbeiter sich zur ckziehen Nur dann sind Sie als Projektleiter sozial kompetent 10 1 14 3Macht Von oben Wenn das Projekt von der Gesch ftsleitung nicht getragen und unterst tzt wird wird es zwangsl ufig immer Probleme geben Das Management muss sich zum Projekt und den Beteiligten bekennen und diese st ndig mit relevanten Informationen versorgen Stimmt die Kommunikation hier nicht ist der Projekterfolg unmittelbar davon betroffen Von unten Eine negative Einstellung der Mitarbeiter dem Projekt gegen ber kann den Projekterfolg genauso gef hrden Hier ist berzeugungsarbeit von oben und vom Projektleiter notwendig Es muss sichergestellt sein dass alle Mitarbeiter ausreichend informiert wurden so dass keine Missverst ndnisse entstehen k nnen Machen Sie positives Marketing f r Ihr Projekt Gehen Sie Probleme im Team sofort an warten Sie nicht bis sie eskali
53. 00u00000u00unan nun nn 27 Tabelle 2 Die Phasen des Projektmanagements uu02200n0H00n0000 27 Leitfaden Projektmanagement Q Office 2 Heip Tabelle 3Einsatzbereich von MS Project in Projekten uunnennnseeennn 30 Tabelle 4 Die wichtigsten Projektmanagement Begriffe 47 Tabelle 5 Aufwendungen f r die Projektphasen herk mmlich 85 Tabelle 6 Die Top 10 Risiken einer Software Entwicklung 139 Tabelle 7 Risikofaktoren ein Beispiel uunsnnnnsennnnnnnnnnnnnnnnnnnnnnnnnnn 147 Tabelle 8 Berichiswege ui 168 Seite 9 Leitfaden Projektmanagement Q Office 2 Heip Die Ursachen sind wichtig Seite 10 1Vorwort Ob Sie ein Haus bauen einen Tunnel bauen eine Urlaubsreise planen ein neues Medikament entwickeln eine Software erstellen oder nur eine Hochzeit planen hinter allem steht dasselbe Prinzip Sie sind voll verantwortlich daf r dass alles so klappt wie von Ihnen geplant und von Ihrem Kunden erwartet Funktioniert etwas nicht so wie erwartet und geplant so wird Sie keiner nach den Ursachen fragen sondern nur das Ergebnis betrachten Anders ausgedr ckt als Projektleiter oder Projektleiterin haben Sie nur eine einzige Aufgabe Das Projekt erfolgreich zu Ende zu bringen schaffen Sie das sind Sie der Gewinner wenn nicht dann Leitfaden Projektmanagement Q Office 2 Heip 2Einleitung Der Gesch ftserfolg von Unternehmen h ngt heutz
54. 1 Leitfaden Projektmanagement To Office 2 Heip Funktion und Verantwortung Qualifikationen Seite 182 19 2 2Projekt Mitarbeiter aus IT Er Sie Eine bearbeitet ein definiertes Aufgabengebiet in der Informationsverarbeitung Beratungs Planungs Konzeptions und Realisierungsaufgaben tr gt in definiertem Ma e Verantwortung f r die Erarbeitung von L sungen f r die Informationsverarbeitung die Arbeitsziele der eigenen technischen IS Aufgaben Kontrolle der Arbeiten erfolgt anhand der Ergebnisse bzw des Zielerreichungsgrades Er Sie ben tigt folgende Qualifikationen Analytische und konzeptionelle F higkeiten definierter Tiefe und Komplexit t Berufserfahrung definierter L nge und Erfahrungstiefe in einer IS Funktion oder auf einem anwendungsbezogenen Arbeitsgebiet Dazu z hlt insbesondere Arbeiten mit DV Schreiben und Warten von Programmen Realisierungstechniken fachlichen Entwurf analysieren von Systemen systematischen Testen Pr sentieren Durchf hren von Anwenderschulungen Spezialwissen in definiertem Umfang z B Programmprodukte zu bewerten komplexe Sachverhalte klar zu beschreiben F higkeit besitzen in einem Team zu arbeiten Beherrschen der Methoden und Techniken des eigenen Fachgebietes insbesondere Gesch ftsprozessmodellierung Datenverarbeitungsprodukten und Anwendungen Programmiersprachen Projekt Phasen Gespr chsf hrung Planungsmethoden Aufwandssch tzungen
55. 1 Projektinitiierung freigeben DP2 Projekt freigeben DP3 Phasen oder Ausnahmeplan freigeben DP4 Ad hoc Anweisungen geben DP5 Projektabschluss best tigen 12 7 8 5Planen Planen ist ein Prozess der ber die ganze Projektdauer ben tigt wird Die Elemente des Prozesses Planen sind PL1 Plan entwerfen PL2 Produkte definieren und analysieren PL3 Aktivit ten und Abh ngigkeiten identifizieren PL4 Aufwand absch tzen PL5 Zeitplan erstellen PL6 Risiken analysieren PL7 Plan vervollst ndigen Leitfaden Projektmanagement Q Office 2 Heip 12 7 8 6lnitiieren eines Projekts Damit ein Projekt genehmigt wird muss es sorgf ltig geplant werden und zeigen wie es seine Ziele erreicht Dazu m ssen detaillierte Absch tzungen der Kosten gemacht werden Gleichzeitig wird das Haupt Produkt dieses Prozesses erstellt das Projektleitdokument Project Initiation Document oder PID das vom Lenkungsausschuss zu genehmigen ist bevor die Implementierung beginnen kann Die Elemente des Prozesses Initiieren eines Projekts sind IP1 Qualit t planen IP2 Projekt planen IP3 Business Case und Risiken verfeinern IP4 Projektsteuerungsmittel einrichten IP5 Projektablagestruktur einrichten IP6 Projektleitdokument PID zusammenstellen 12 7 8 7Steuern einer Phase Bearbeiten Um sie leichter managen und steuern zu k nnen werden PRINCE2 Projekte in Phasen unterteilt Die genaue Zahl der Phasen ist nicht festgelegt sie h
56. Arbeitern mit den unterschiedlichsten T tigkeiten sowie den daf r erforderlichen Materialeinsatz zu planen durchzuf hren und zu kontrollieren Seite 13 Leitfaden Projektmanagement To Office 2 Heip Frederic Taylor Henry Gantt PERT Charts Seite 14 4 2Anstrengungen im fr hen 20 Jahrhundert Nahe der Jahrhundertwende begann Frederick Taylor 1856 1915 mit seinen Studien bez glich der Arbeitst tigkeit Taylor bewies auf wissenschaftlicher Basis das Arbeit und Arbeitsabl ufe analysierbar und im weiteren verbesserbar sind wenn man sich auf die elementaren Teile konzentriert Tayler bewies durch Studien die sich auf Stahlwerke Kiesabbau und das Bewegen von Teilen bezogen das durch entsprechen Planungen Leistungssteigerungen m glich waren die bisher nur durch l ngere und oder h rtere Arbeiten m glich geworden w hren Die Inschrift auf Tailors Grabstein The Father of Scientific Management der Vater des Wissenschaftliichen Managements zeigt seinen Platz in der Vergangenheit des Managements auf Taylor s Kollege Henry Gantt 1861 1919 studierte im Detail die Reihenfolge von T tigkeiten Operationen bei der Arbeit Seine Studien basierten im wesentlichen auf der Konstruktion von Schiffen f r die US Navy w hrend des 2 Weltkriegs Seine Gantt Charts mit T tigkeitslinien und Milestone Markierungen zeigen die zeitliche Abfolge und Dauer aller T tigkeiten Aufgaben innerhalb eines Prozesses Gantt Char
57. Auftraggeber dem Projektleiter und dem Projektteam kann jedoch den Erfordernissen entsprechend um weitere Kontroll und Entscheidungsgremien erweitert werden Mit dem Ende des Projektes wird die Projektorganisation aufgel st Projektphasen Zeitlich voneinander abh ngige Abschnitte eines Projektablaufs Beispiel Analyse Konzept Entwicklung Realisierung Test Projektplanung Alle T tigkeiten die zu einem Projektplan f hren Ein Projektplan kann aus folgenden Elementen bestehen Projektstrukturplan inkl Arbeitspaketbeschreibungen Terminplan Netz Balken Meilensteinplan Ressourcenplan Kostenplan Risikoanalyse LEON a Projektrahmenorganisation Zusammenwirken von Projekt und Linienorganisation M gliche Formen sind e Reine Projektorganisation e Projektkoordination e Matrix Projektorganisation Je nach Organisationsform besitzt der Projektleiter mehr oder weniger Verantwortung und Befugnisse Projektsteuerung Projektcontrolling Aufgabe des Projektleiters Ziel ist es m gliche Probleme w hrend der Projektabwicklung m glichst fr hzeitig zu erkennen und evtl Steuerungsma nahmen ergreifen zu k nnen Projektstrukturierung Erarbeiten eines Projektstrukturplans Ein Projekt wird hierarchisch in immer kleinere Elemente zerteilt Die unterste Ebene ist die Basis f r die weitere Projektplanung Projektstrukturplan Meist graphische bersicht ber alle zur Erreichung des Projektziels erforde
58. Br cke zwischen unterschiedlichen Disziplinen REE IPAE EEA EE T har TA EEEE EE E AAE EET EET SEPT T TT 98 12 5 Einsatzfelder der Prozessmodelle uuuununnaunnnunnunnnunnaunnuunnunnnunnunnnnunnnnn 98 12 6 Weitere Vorteile der Verwendung von Prozessmodellen uunuunsnunen 99 12 7 Prozessmodelle der letzten Jahre zuunnauunanunnaunnuunnnnunnununnuunnununnunnnn 100 12 741 BE WIESE I NO ae 100 12 2 E82 iin lanss a 102 I2 7 EDER Noel ee 105 1 ZA e ea Ts teil 113 12 7 5 Der Microsoft Solutions Framework 2uuucneanneanneannnannnnannnannnannnn 113 12 7 6 Der Rational Unified Procss3 r u 22 00rs0neneieneeeiihehh 115 AN 1 ER 117 12 7 8 Pics Prince 2 einer 120 12 8 Anpassbarkeit von Prozessmodellen uuunuuuunuunnunnnunnuuuununnnnunnunnen 129 12 9 Die Bedeutung von Prozessmodellen f r das Projektmanagement 131 12 10 Zusammenfassung u00u0n00u0n 0001000 ahnen 132 Seite 5 Leitfaden Projektmanagement Q Office 2 Heip 15 1 RERO SEIKAN O niet 138 1a LA PERS Anal enges 141 1 5 FE I ee en ee ae 145 15 1 4 Risiko Priorntatenbld uessa 147 16 Projekimanagement 0 0 0 0 150 16 1 Projektp enung EE P EEE E ATTE A E ATTAT 150 17 Rahmenbedingungen nsssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn a 157 12 1 PIOJERIV era nee 157 17 3 AnwendungsentwicklungsprozeSS uuuuuuuuuunnnnnnnnnnnnunnnnnnnnnnnnnnnnnnnnn
59. Die Top 10 Risiken einer Software Entwicklung Seite 139 Leitfaden Projektmanagement Seite 140 Q Office 2 Heip Um zu einer genaueren Einsch tzung eines Risikos zu gelangen k nnen Risiko Wahrscheinlichkeitstabellen herangezogen werden Nachfolgende Tabelle soll helfen die Wahrscheinlichkeit einzusch tzen dass ein Projekt seinen Kostenrahmen berschreitet Kostenverursacher Anforderungen Umfang Hardwarebedingte Beschr nkungen Anwendung Technologie Anforderungs nderungen Personal Verf gbarkeit Mischung der Software Disziplinen Erfahrungen Personalf hrung Wiederverwendbare Software Verf gbarkeit Modifikationen Sprache Lizenzrechte Zertifizierung Werkzeuge und Umgebung Einrichtungen Verf gbarkeit Lizenzrechte Konfigurationsmanagemen Volle Kontrolle Wahrscheinlichkeit Unwahrscheinlich 0 0 3 Wahrscheinlich 0 4 0 6 H ufigkeit 0 7 1 Gering einfach oder Mittlere Komplexit t Umfangreich sehr leicht zerlegbar zerlegbar komplex oder nicht zerlegbar Keine Echtzeit geringe Eingebettet einige Echtzeit eingebettet Systemabh ngigkeit Systemabh ngigkeit starke Systemabh ngigkeit Reif vorhanden eigene Vorhanden einige Neu oder neue Erfahrungen eigene Erfahrungen Anwendung wenig Erfahrung Vorhanden geringe Verf gbar etwas Nicht verf gbar hohe Fluktuation zu erwarten Fluktuation zu erwarten Fluktuation zu erwarten Gute Mischung Einige Diszi
60. Erfahrungswerte dokumentiert Damit ist eine klar fassbare Basis f r die Planung gegeben Und damit muss nicht mehr auf die Erfahrung von Experten die durch viele Faktoren beeinflusst wird zur ckgegriffen werden 5 6 3Die Struktur des Projektmanagements Neben der reinen Technik der Projektarbeit bedarf das Projektmanagement einer Reihe weiterer Voraussetzungen e Das Projektmanagement muss in die Organisationsstruktur des Unternehmens integriert werden e Mitarbeiter im Projekt und insbesondere Projektmanager m ssen eine ausreichende Qualifizierung erhalten e Projekte m ssen effizient verwaltet werden Nur so l sst sich eine erfolgreiche Umsetzung von Projekten sicherstellen Dieser Abschnitt besch ftigt sich mit der Struktur des Projektmanagements als Basisvoraussetzung f r erfolgreiches Projektmanagement Es werden sowohl m gliche Organisationsformen f r das Projektmanagement als auch Einbindungsm glichkeiten des Projektmanagements in Organisationen vorgestellt Es wird auf die Anforderungen an Mitarbeiter die ben tigten Qualifikationen und die Position des Projektleiters eingegangen Und es wird diskutiert wie in einem Projekt effizient gearbeitet werden kann F r die Projektorganisation sind zwei Aspekte zu unterscheiden e Die Organisation im Projekt e Die Einbindung des Projekts in die Unternehmensorganisation Diese beiden Aspekte sind eng miteinander verbunden da die Projektorganisation in hohem Ma e vorn Stelle
61. IST Aufnahme der Gewinnung der f r das Projekt techniken wichtigen Informationen ber den Fachbereich also sollten folgende Erhebungstechniken angewandt werden Interview Befragung der Fachabteilung aktuell sorgf ltig vorbereiten Zusatzfragen m glich direkter Kontakt Erfahrung notwendig Metaplan Sammeln von Argumenten effizient Ordnen der Argumente alle tragen das Ergebnis direkte Dokumentation Technik mu gelernt werden Wichtige Voraussetzung ist eine rechtzeitige und umfassende Information der von der Erhebung betroffenen Mitarbeiter der Fachbereiche ber Sinn und Aufgabe der Erhebungsma nahme Dies ist Aufgabe des Auftraggebers oder des f r den Fachbereich verantwortlichen Managements Regeln f r die Auswahl der Erhebungsmethode Auswahl der Erhebungs Der Projektleiter w hlt die Erhebungsmethode aus methode Die ausgew hlte Methode muss abgestimmt werden mit den betroffenen Fachbereichen dem Betriebsrat Die Gespr chspartner m ssen gemeinsam mit dem f r den Fachbereich zust ndigen Management festgelegt werden Die Absprachen m ssen schriftlich fixiert werden e Die vorgeschlagenen Mitarbeiter des Fachbereiches sind durch Auftraggeber und verantwortiiches Management auf ihre Aufgabe vorzubereiten Projektintern Projektinterne e berpr fung der Qualifikation der Projektmitglieder im Hinblick auf die von Regeln ihnen zu praktizierende Erhebungsmethode e Im B
62. K ndigung Krank sein Erh hte Fluktuation Killerphrasen Aggressionen Sabotage Leitfaden Projektmanagement Q Office 2 Heip Gr nde f r Widerstand e Die Betroffenen haben nicht verstanden worum es geht Sie sehen keinen Sinn in der Ver nderung e Die Betroffenen haben verstanden worum es geht Sie glauben aber nicht an die Ver nderung e Die Betroffenen haben verstanden und sie glauben auch was gesagt wird aber sie wollen nicht Dieser Unwille kann viele Ursachen haben z B Gef hl der Machtlosigkeit Gef hl der Abh ngigkeit Verletzung des Eigenwertgef hls Festhalten an Gewohntem Vertraute Sicherheitsdenken Betriebsblindheit Unsicherheit vor Zuk nftigem Felder des Widerstandes Geld Sicherheit Kontakt Anerkennung Selbst ndigkeit Entwicklung Strategien im Umgang mit Widerstand Offene Information Einbeziehen der Mitarbeiter in Ver nderungs berlegungen Zeit lassen zur Eingew hnung Lernklima schaffen Fehler zulassen und auswerten Analyse der Widerst nde Pers nliche Problemkl rung Aushandeln und abschlie en von Ver nderungskontrakten Kraftfeldanalyse Lewin Seite 73 Leitfaden Projektmanagement Q Office 2 Heip 8 5Zusammenwirken der Projektbeteiligten Die nachfolgende Abbildung zeigt die Integration eines Projektes in die hierarchische Struktur und ihr Zusammenwirken Abbildung 13 Zusammenwirken der Projektbeteiligten Grundsatz f r Alle Beteiligten sol
63. Kenntnisse von IS Entwicklungen und Anwendungsarchitekturen Definierte F higkeiten der englischen Sprache und ggf einer weiteren Fremdsprache Leitfaden Projektmanagement Q Office 2 Heip 19 2 3Projekt Mitarbeiter aus Fachbereich Funktion und Er Sie Verantwortung Eine bearbeitet dabei ein definiertes Aufgabengebiet der Fachabteilung mit bezug zur informationstechnischen Abbildung der gesch ftlichen Abl ufe Planungs Konzeptions und Realisierungsaufgaben tr gt in definiertem Ma e Verantwortung f r die Erarbeitung von L sungen f r die Fachabteilung die Arbeitsziele der eigenen fachlichen IS Aufgaben Kontrolle der Arbeiten erfolgt anhand der Ergebnisse bzw des Zielerreichungsgrades Er Sie ben tigt folgende Qualifikationen Qualifikationen Analytische und konzeptionelle F higkeiten definierter Tiefe und Komplexit t Berufserfahrung definierter L nge und Erfahrungstiefe in einer IS Funktion oder auf einem anwendungsbezogenen Arbeitsgebiet Dazu z hlt insbesondere Arbeiten mit DV Bewerten und Ermitteln von Anwenderanforderungen Bedarfsanalyse fachlichen Entwurf Pflichtenheft Pr sentation Durchf hren von Anwenderschulungen Spezialwissen in definiertem Umfang z B Programmprodukte zu bewerten F higkeit besitzen in einem Team zu arbeiten Beherrschen der Methoden und Techniken des eigenen Fachgebietes insbesondere Gesch ftsprozessmodellierung Datenverarbeitung Prinzipien der Softwa
64. Netzplan Anfangsfolge Anordnungsbeziehung vom Anfang eines Arbeitspakets zum Anfang seines Nachfolgers d h der Start von Arbeitspaket B richtet sich nach dem Start von Arbeitspaket A Anfangszeitpunkt Auf Basis der Ablaufplanung errechneter oder fest definierter Beginn eines Arbeitspaketes Abh ngig von der Berechnungsmethode ergeben sich e Fr hester Anfangszeitpunkt Vorw rtsrechnung e Sp tester Anfangszeitpunkt R ckw rtsrechnung Anordnungsbeziehung Verkn pfung Quantifizierbare Abh ngigkeit zwischen zwei Arbeitspaketen eines Projektes e Normalfolge Ende Anfang e Anfangsfolge Anfang Anfang e Endfolge Ende Ende e Sprungfolge Anfang Ende Arbeitspaket Teil eines Projektes der im Projektstrukturplan nicht weiter aufgegliedert ist Ein Arbeitspaket kann auf einer beliebigen Gliederungsebene liegen Um das Projektziel zu erreichen ist die Abarbeitung aller Arbeitspakete n tig Im allgemeinen Sprachgebrauch werden Arbeitspakete h ufig auch mit Aufgabe Aktivit t oder Vorgang bezeichnet in Microsoft Project Vorgang Arbeitspaketverantwortlicher Ansprechpartner f r den Projektleiter bei der Durchf hrung eines Arbeitspakets Der AP Verantwortliche muss nicht unbedingt alle Arbeiten selbst durchf hren Auftraggeber eines Projektes Seite 197 Leitfaden Projektmanagement To Office 2 Heip Seite 198 Gesamtverantwortlicher f r ein Vorhaben oder ein Projekt
65. Sie sich von einer derartigen Einstellung freisprechen Ich jedenfalls nicht Und so geht es mehr oder weniger den Mitarbeitern eines Projektteams Heutzutage ist die Hilfebereitstellung via navigationsf higem Online Dokument State of the Art Doch welches Prozessmodell ber cksichtigt diesen Trend Bereits seit vielen Jahren ist der Satz Ein Bild sagt mehr als tausend Worte als Tatsache bewiesen Doch wenn man sich die Berge von Dokumentationen ansieht die t glich innerhalb der Projekte produziert werden stellt sich einem die Frage ob manche Projektleiter hier immer noch in der Steinzeit leben Leitfaden Projektmanagement Q Office 2 Heip 10 1 13Fehlende Prozessmodelle Fehlende oder schlechte Prozessmodelle sind zwar der h ufigste Grund warum Softwareprojekte scheitern aber es ist sehr schwer nachzuweisen dass ein Prozessmodell die eigentliche Ursache f r das Scheitern war Das sich eine Technologie ge ndert hat ist f r jeden ersichtlich und wird somit als Grund anerkannt ebenso deutlich erkennbar ist es wenn sich eine Anforderung ndert Da jedoch an einem Prozessmodell sehr viele Dinge h ngen l sst sich hier der Nachweis nur sehr schwer f hren Als Anregung nachstehend einige Fragen die Sie sich stellen sollten e Wie kann in einem Projekt sicher gestellt werden dass die Kommunikation funktioniert e Wie kann in einem Projekt gew hrleistet werden dass jeder Mitarbeiter zu jedem Zeitpunkt wei
66. Solutions Framework Sammeln der Anforderungen Analyse amp Design Planung Implementierung Konzeption Management e itiial el I Verteilung amp Ausfl chung Auswertung x amp Korrekturen Abbildung 25 Microsoft Solutions Framework MSF 12 7 6Der Rational Unified Process Es handelt sich dabei um ein reinrassiges objektorientiertes Prozessmodell Dadurch ist sein Umfang auch nicht so erschlagend wie der des V Modells Der Rational Unified Process definiert sich ber sogenannte Workflows die jedoch nicht sequentiell sondern parallel ber die folgenden Phasen ablaufen Konzeptionalisierungsphase Entwurfsphase Konstruktionsphase bergangsphase Seite 115 Leitfaden Projektmanagement Q Office 2 Heip Phasen Prozess Arbeitsabl ufe Inception Elaboration Construction Transition Modellierung Gesch ftsabl ufe mi Festlegung Anforderungen Analyse amp Design Implementierung Realisierung Test Rollout Verteilung Unterst tzende Arbeitsabl ufe Konfigurations Mgmt D SS E A EREERREE Projekt Management i En nm Umgebungseinfliss m i i l Preliminary Iter Iter Iter Iter Iter Iter Iter Iteration s 1 2 n n 1 n 2 m m 1 Iterationen Abbildung 26 Der Rational Unified Process F r die folgenden Themenkomplexe existieren im Rational Unified Process RUP Workflows Gesch ftsprozessmodellierung Anforderungsmanagement Analyse und Design Implementi
67. aaaeaaeaaanaaannanaaann 38 5 6 8 Aufgaben des ProjektmanagerS ssssnnnnnnnnsnsnnnnnnnnnnnnnnnnnnnnnnnnnnennne 39 5 6 9 Qualifikationen von Mitarbeitern im Projekt 20ssnnnnnnnnnnnnnnnnnnnnnnennna 40 5 7 Die zehn wichtigsten Regeln f r erfolgreiches Projektmanagement 41 5 7 2 Aufl sung von Konsens 42 5 7 3 Ganzheitliches Projektmanagement oounnnoonanannnnnonaannnnnnanannannnn 42 5 7 4 Der ProjektebonszykUS ee 43 5 7 10 De fD AON Oge e 46 5 7 11 Die wichtigsten Begriffe im Projektmanagement ueunoooaaaeeannn 46 EB Eckwerte fur Projekj osised aaan a aaa 48 o8 INES ECKWETTO ascuns aiaaeS 48 Doa ONSE Pre een een 49 Seite 3 Leitfaden Projektmanagement To Office 2 Heip Seite 4 6 Der Pro kile Reponn aoia aaa 50 6 1 1 Falsche Besetzung in Projekten ssssesnnsnnnnsnnnnnnonnnnnnnssnnnnnnnnnnnnnnene 50 6 1 2 Der Projektleiter Ein Organisationsgenie snsssssnnsnnnnnsnnnnnennnnnee 51 6 1 3 Ich bin Projektleiter was NUN inne ee 52 7 Projekt Vorbereitungsphasen uuuuunonunnnnnnnnnnnnnnnnnuunnnnnnnnnnunnnnnnnnnnnnnnnn 53 7 3 Grunds tzliches T A A ie ee 53 7 2 Gesamizusammen hangisini nennen 54 27 3 LENDIAN nice 54 7 4 Wei buch f r den Einsatz der Informationstechnologie unauunuuunnn 55 8 Projektaufbauorganisation nunnnnnnunnnnnunnnnnnununnununnnnnunnnnnnnnnnnnnnnnnnnn 56 8 1 Projekta
68. agement begleitet den gesamten nderungsprozess vom nderungsantrag ber alle Entscheidungen bis zum nderungsabschluss und der R ckmeldung Die KM Dienste werden in bestimmten Intervallen bzw nach Bedarf durchgef hrt Hierzu z hlen die Ergebnissicherung KM Dokumentation und die KM Dienstleistungen zur zentralen und projekt bergreifenden Datenadministration und Produktwiederverwendung sowie Schnittstellenkoordination und das Releasemanagement 12 7 3 4Submodell QS Die im Submodell Qualit tssicherung QS beschriebenen Ma nahmen dienen dem Nachweis der Erf llung dieser vorgegebenen Anforderungen aber auch dazu M ngel von vornherein u verhindern Zu einen wird Softwarequalit t durch den Einsatz konstruktiver und pr ventiver Konstruktive Ma nahmen erreicht zum anderen werden konstruktive Ma nahmen durch und pr ventive analytische Ma nahmen erg nzt Ma nahmen Das Submodell QS umfasst die Planung von Pr ventiven konstruktiven und analytischen Ma nahmen sowie die Vorbereitung Sicherstellung Durchf hrung und das Berichtswesen f r die analytischen Ma nahmen Es bezieht sich dabei auf e Organisation e Prozesse e Produkte Die konstruktiven Ma nahmen werden im Submodell QS festgelegt die Anwendung der konstruktiven Ma nahmen erfolgt im Submodell SE Einen Gesamt berblick Zusammenfassung ber alle Aktivit ten die in diesem Submodell von Bedeutung sind sehen Sie in nachfolgender Abbildung Seite 109 L
69. ahmen fest Erkennen der Risiko Ausl ser Risikoausl ser sind Anzeichen Merkmale eines potentiellen Risikos die erkennen lassen ob sich ein potentielles Risiko entwickelt oder ob es evtl bereits eingetreten ist Die idealen Ausl ser informieren Sie bereits bei den ersten Anzeichen eines potentiellen Problems Um Ausl ser zu erkennen ist es notwendig dass Sie mit denjenigen Personen sprechen die f r das Auftreten eines Problems verantwortlich sein k nnten sowie mit denjenigen Personen die von den auftretenden Risiken betroffen w ren Fragen Sie die Personen wie sie feststellen k nnen w rden dass ein Problem entsteht oder bereits entstanden ist Beginnen Sie dabei mit den Zeitpunkt der Problemerkennung und arbeiten Sie sich dann zur ck zu den m glichen Ausl sern Als Projektmanager m ssen Sie sich Gedanken machen wie ein potentielles Risiko Ihren Projektplan beeinflusst Kommt es z B dadurch zu berstunden f r spezifische Ressourcen oder werden Aufgaben erst mit Versp tung erledigt Erstellen Sie sich eine berwachungsliste die jedes der potentiellen Risiken enth lt Vermerken Sie zu jedem potentiellen Risiko den entsprechenden Ausl ser sowie die Person Ressource die diesen Ausl ser berwacht Seite 145 Leitfaden Projektmanagement To Office 2 Heip Seite 146 Pl ne schmieden Haben Sie die Ausl ser von potentiellen und m glichen Risiken festgestellt so ist es jetzt an der Zeit endsprechende korrigie
70. als eine zweite Kopie zu speichern und in der neuen Kopie die Risiken kalkulatorisch mit einzubeziehen Bei einem Vergleich beider Projektpl ne erhalten Sie dann einen Risikobetrag ber das Projekt Weisen Sie jedem Risiko eine Priorit t zu Nehmen Sie den von Ihnen festgelegten Schwellenwert f r den Toleranz Level die m glichen entstehenden Kosten f r das Risiko und weisen Sie dem potentiellen Risiko eine Priorit t innerhalb aller Risiken zu Verfahren Sie so mit allen anderen Risiken bis alle potentiellen Risiken mit einer Priorit t versehen sind Beispiel wenn ein potentielles Risiko unter dem von Ihnen festgelegten Schwellenwert Toleranzlevel liegt und die Wahrscheinlichkeit das der Risikofall Leitfaden Projektmanagement Q Office 2 Heip eintrifft hoch ist so weisen Sie diesem Risiko eine hohe Priorit t zu Konzentrieren Sie sich als erstes auf Risiken mit hoher Priorit t 15 1 3Risiko Planung Haben Sie Risiken erkannt und quantifiziert so beginnt jetzt f r diese potentiellen Risiken die Risikoplanung Da eine professionelle Risikoplanung eine ganze Menge an Zeit und pers nlicher Energie verbraucht so macht es Sinn sich auf jeden Fall um die Risiken mit hoher und mittlerer Priorit t zu k mmern Planungsvorgehen e identifizieren Sie den Ausl ser f r ein potentielle Risiko e Sorgen Sie daf r das Sie bez glich des Risikos vom Projektteam auf dem laufenden gehalten werden e Legen sie vorsorglich Korrekturma n
71. ammenhang Die Einrichtung von Projekten muss immer in einem Gesamtzusammenhang gesehen werden 7 3Leitplan Ein Leitplan oft auch als Masterplan bezeichnet vermittelt aus einer ganzheitlichen und integrativen Sicht ein Verst ndnis f r die Zusammenh nge und Abl ufe innerhalb des Unternehmens Die einzelnen Informationssysteme k nnen erst dann die Gesch ftsprozesse angemessen unterst tzen wenn das Einzelsystem sinnvoll in die Wirkungszusammenh nge des Unternehmens eingeordnet wird Der Leitplan stellt die Grundlagen und detaillierten Informationen bereit die sowohl der fachlichen als auch der informationstechnischen Seite ein wechselseitiges Verst ndnis und effektive Zusammenarbeit erm glichen um so integrierte Informationssysteme f r betriebswirtschaftliche L sungen zu schaffen Leitfaden Projektmanagement Q Office 2 Heip 7 4Wei buch f r den Einsatz der Informationstechnologie Ein Wei buch f r den Einsatz der Informationstechnologie bei Unternehmen Wei buch dokumentiert die IS Strategie der aufbauend auf den Zielsetzungen des Leitplans als integrierender Gesamtrahmen und die geplante Umsetzung durch IT Abteilungen Es versucht die Zusammenh nge und die sich daraus ergebenden Priorit ten und Aktionen aus einer detaillierteren Sicht zusammenzufassen Dabei wird sowohl der Handlungsbedarf neu beleuchtet als auch die Voraussetzungen die geschaffen werden m ssen um diesen Handlungsbedarf schnell umzusetze
72. as wichtigste Element in einem Projekt ist das Projektteam Dieses selbst setzt sich zusammen aus e Projektleiter e Mitarbeitern aus Fachabteilungen e Mitarbeitern aus den auftraggebenden Bereichen In vielen F llen kommen noch externe Berater hinzu jedes Projektteam sollte eine flache Hierarchie aufweisen in der nur der Projektleiter eine exponierte Stellung besitzt Nur in sehr gro en Projekten kann ber komplexere Strukturen nachgedacht werden Aber auch dann bietet sich eine eher team orientierte flache Struktur an bei der es Teams mit Teamleitern und dar ber noch eine koordinierende Instanz gibt Die Kernaufgaben des Teamleiters sind Koordination Kommunikation und Reporting mit anderen Stellen Leitung der Projektplanung Steuerung und berwachung des Projekts Die Position des Projektmanagers ist keine Vorgesetztenposition im eigentlichen Sinne Es handelt sich vielmehr um einen Fachvorgesetzten f r einen speziellen Bereich Ein starker Projektmanager gewinnt seine Autorit t durch seine Person und nicht durch die formale Stellung Wichtig ist zudem dass der Projektmanager bei fachlichen Fragestellungen keine berragende Stellung besitzen und fordern sollte Nur so kann es gelingen den Sachverstand der Projektmitarbeiter gewinnbringend einzusetzen Eine gut gef hrte Gruppe wird immer ein besseres Ergebnis als das beste Mitglied innerhalb einer Gruppe liefern Der Projektmanager muss vor allem daf r sorgen dass das Proj
73. ase Machbarkeitstudie Grobgliederung Messbarkeit der Ziele Planungsphase berwachungsphase Abschlussphase Projektnachrechnung Kontrolle gegebenenfalls Initialisierung eines neuen Projekts f r Weiterentwicklung Tabelle 2 Die Phasen des Projektmanagements Wichtig ist zu erkennen dass es zwei verschiedene Phasenmodelle gibt Zum einen gibt es die Phasen der technischen Strukturierung des Projektes Diese verlaufen in hohem Ma e sequentiell Seite 27 Leitfaden Projektmanagement Q Office 2 Heip Seite 28 Abbildung 2 Der sequentielle Ablauf des Projektes Nat rlich k nnen sich auch solche Phasen in Teilen berlappen So ist es durchaus denkbar dass sich einige Komponenten eines komplexen Produkts noch in der Entwicklung Analyse und Definition befinden w hrend andere bereits produziert Codierung werden Damit so etwas funktioniert sind sowohl klare Pflichtenhefte als auch saubere Schnittstellendefinitionen erforderlich Leitfaden Projektmanagement Q Office 2 Heip Dem stehen die revolvierenden Phasen im Projektmanagement gegen ber Die Phasen des Projektmanagements verlaufen in weiten Bereichen nicht sequentiell Das wird besonders an zwei Beispielen deutlich o Wenn es innerhalb eines Projekts zu Abweichungen kommt muss die Planung ver ndert werden Aus der berwachungsphase heraus wird also immer wieder zur ck in die Planungsphase gesprungen Unter Umst nden muss sogar
74. aufbauen Je mehr eine Aufgabe auf andere Aufgaben oder Zulieferungen angewiesen ist um so gr er ist die m gliche dadurch ausgel ste Zeitverschiebung und damit auch die Kosten e Aufgaben die sehr lange dauern Und oder ber eine gro e Anzahl von Ressourcen verf gt Die entsprechenden Planungen sind m glicherweise nicht richtig 2 Gedankenaustausch und Gespr che mit Experten Es gibt eine ganze Reihe von Projektrisiken die nicht unbedingt direkt und unmittelbar aus einem Projektplan ablesbar sind Es ist von unsch tzbarem Wert ein Brainstorming Meeting mit allen Projektbeteiligten und Schl sselpersonen ihres Projektes einzuberufen Fragen Sie diese Personen in welchen Aufgaben Zeitabl ufen etc sie Risiken sehen Sie werden berrascht sein was Sie hierdurch alles entdecken Sind Sie in der gl cklichen Lagen in Ihrem Kollegen oder Bekanntenkreis einen erfahrenen Projektmanager zu kennen so lassen Sie diesen doch einmal einen Blick auf Ihren Projektplan werfen und sich m gliche Risiken aufzeigen Planen Sie mit externen Zulieferern zu arbeiten so versuchen Sie mit Personen zu sprechen die bereits Erfahrungen mit diesem oder anderen Zulieferer hatten 15 1 2 2Risken Quantifizieren Risiken zu Quantifizieren ist ein eigenes und sehr komplexes Thema Ihre M glichkeiten reichen hier von u erst umfangreichen Sch tzungen und Untersuchungen bis hin zu einfacheren Methoden wie sie nachstehend beschrieben werden Es ist offens
75. aus klarstellt dass es selbstverst ndlich gerne bereit ist innerhalb k rzester Zeit die gew nschten nderungen vorzunehmen aber gleichzeitig deutlich macht dass erheblich Extrakosten getragen werden m ssen die nicht das Softwarehaus verursacht hat ist der Kunde in der Regel bereit diese auch zu tragen Im Baugesch ft machen diese Extraverg tungen inzwischen eine nicht unerheblichen Teil der Gesamteinnehmen aus im IT Sektor scheuen sich viele Projektleiter immer noch diese eigentlich selbstverst ndlichen Forderungen zu stellen Detaillierte AGB zum Vertragsgegenstand finden sich nur u erst selten in den AGB der Projektgesch fte weil in der Regel jedes Projekt seine Besonderheiten hat Daher ist es auch nicht m glich diese standardm ig zu erfassen Dennoch ist in den AGB ein Hinweis auf den Vertragsgegenstand nicht verkehrt weil er den Verwender selbst nochmals auf die hohe Relevanz des Vertragsgegenstands hinweist Au erdem kann er wie eine Checkliste funktionieren Die Klausel enth lt einfach diejenigen Punkte ber die noch zu verhandeln ist und die gleichzeitig den Umfang der Arbeiten und das Vertragsziel definieren Eine Formulierung k nnte lauten Der Auftragnehmer wird f r den Auftraggeber lauff hige EDV Anlagen und hnliche Werle herstellen Die dabei vom Unternehmer zu erbringenden Leistungen und das Werkergebnis werden in einem gesonderten Einzelvertrag beschrieben Dieser Einzelvertrag enth lt z
76. barkeit beim Sachziel in vielen F llen nur schwer zu erreichen Wie misst man beispielsweise die Sachzielerreichung bei Forschungs und Entwicklungsprojekten Daher wird bei sehr vielen Projekten mit Pflichtenheften gearbeitet Ob diese explizit diese Bezeichnung tragen oder implizit Gegenstand beispielsweise einer ffentlichen Ausschreibung sind ist sekund r Entscheidend ist dass ein richtig erstelltes Pflichtenheft eine vollst ndige Beschreibung der sachlichen Leistungen die ein Projekt erbringen soll beinhaltet Es ist der Rahmen an dem der Projekterfolg nachher gemessen werden kann Das Sachziel ist also die Aufgabe die es im Projekt zu l sen gilt Die besondere Bedeutung des Sachziels in einem Projekt ergibt sich schlicht daraus dass seine Erreichung der ureigene Zweck des Projekts ist Wenn das Sachziel nicht erreicht wird daf r aber Kosten und Terminziele eingehalten werden ist der Sinn des Projekts blicherweise verfehlt worden nderungen am Sachziel k nnen im Verlauf eines Projekts zwar vorkommen sollten aber nicht die Regel sein Seite 19 Leitfaden Projektmanagement To Office 2 Heip Seite 20 Das Kostenziel ist das zweite wichtige Ziel Es gilt die Kosten in einem definierten Rahmen zu halten Das Kostenziel hat je nach Struktur des Projekts sehr unterschiedliche Bedeutung So gibt es genug Beispiele f r interne Projekte bei denen beispielsweise Organisationsstrukturen angepasst oder Konzepte unterschiedli
77. beiter e Positive Einstellung zur Teamarbeit e Konflikt und Kritiktoleranz e Gegenseitige Anerkennung und Respektierung der fachlichen Qualifikation und pers nlichen Integrit t e Partnerschaftliches Verhalten e F higkeit widerspr chliche und voneinander abweichende Informationen zu verarbeiten e Bereitschaft sich voll im Team zu integrieren e Mitsich selbst zufrieden sein Ein eingeschworenes Team erkennt man an folgenden Merkmalen Niedrige Fluktuationsrate Ausgepr gtes Identifikationsbewusstsein Freude an der Arbeit e e e e Bewusstsein einer Elitemannschaft 8 2 2Die Gr e der Arbeitseinheiten Eine Arbeitseinheit kann umso gr er sein je umfassender die Koordinierung durch Standardisierung im Vergleich zur pers nlichen Weisung erfolgt Je besser die Mitarbeiter ausgebildet sind desto weniger m ssen sie angeleitet und kontrolliert werden und desto gr er k nnen somit ihre Arbeitseinheiten sein Eine Arbeitseinheit muss umso kleiner sein je st rker die gegenseitige Abstimmung zur Koordination interdepender Aufgaben erforderlich ist Zur L sung komplexer miteinander verflochtener Arbeitsaufgaben m ssen die Mitarbeiter unmittelbar miteinander sprechen Daher muss die Arbeitseinheit klein genug sein um zweckm ige h ufige und informelle Interaktionen der Mitglieder Seite 59 Leitfaden Projektmanagement Q Office 2 Heip untereinander zu f rdern Gruppen mit mehr als zehn Mitgliedern beg nstigen
78. bleibt das Problem dass sich nach wie vor in der Gesamtgestaltung beliebige viele Fehler einschleichen k nnen Ein Technologie berblick hilf die f r die Realisierung eines Projektes oder einer Software notwendigen Verfahren auszuw hlen Dann erst l sst sich bezogen auf das gesetzte Ziel eine optimale Architektur festlegen ein Design entwerfen und dieses in einer Realisierungs und QS Phase Qualit tssicherungs Phase umzusetzen Nat rlich spielen die Realisierungs und QS Phase eine wesentliche Rolle so dass man hier sehr sorgf ltig entscheiden muss Hier gemachte Fehler machen das Projekt erheblich teurer und sind nur recht schwierig und aufwendig wieder zu beseitigen Die effizienteste und damit kosteng nstigste Methode und M glichkeit den Projekterfolg zu gew hrleisten bietet hier neben gezieltem Training das Coaching Der Coach muss projekterfahren sein und sich auf dem Gebiet Projektbereich SW Anwendung Programmiertechnik etc auskennen Die Wissensvermittlung erfolgt dabei ber gr ere Zeitr ume im Sinne eines Learning by doing und oder komprimierten Workshops Schlie lich sollte eine Ausbildung m glichst auch ber die real existierenden Techniken hinausgehen Das bedeutet dass Begriffe wie Design by Contract oder aspektorientiertes Programmieren etc gel ufig sind und werden auch wenn die entsprechenden Techniken derzeit noch nicht verabschiedet sind Seite 53 Gratwanderung Vernunft
79. bnisse im Projekt und werden blicherweise f r berpr fungen _im Projekt Leitfaden Projektmanagement Q Office 2 Heip Der kritische Pfad Pert Diagramme Gantt Diagramm e verwendet Stellt man sich die Vorg nge bildlich vor so hat man ein ganzes Geflecht an Vorg ngen vor sich Vom ersten zum letzten Vorgang gibt es dabei viele Wege Der kritische Pfad ist der l ngste Weg vom Anfang bis zum Ende des Projektes Alle Vorg nge im kritischen Pfad sind ohne zeitliche Puffer voneinander abh ngig Bei Verz gerungen eines Vorgangs im kritischen Pfad verl ngert sich damit die Gesamtdauer des Projektes Das kann bei der Kalkulation Verschiebungen des Anfangs oder Endtermins zur Folge haben Durch Verz gerungen im kritischen Pfad kann sich auch ein neuer kritischer Pfad ergeben Das Modell des kritischen Pfades bildet die Grundlage der heute blicherweise verwendeten Projektplanungstechniken Man spricht hier von CPM was f r Critical Path Method steht Von CPM Verfahren oder Methode zu sprechen ist also nicht ganz richtig da das M bereits f r Methode steht Pert Diagramme stellen die einzelnen Vorg nge mit den zwischen ihnen bestehenden Beziehungen dar Dabei wird auch der kritische Pfad besonders deutlich sichtbar Gantt Diagramme sind Balkendiagramme die jeden Vorgang als Balken darstellen Die x Achse der Diagramme ist die Zeit so dass die L nge eines Balkens die Dauer des Vorgangs angibt Wenn mehrere Vorg nge
80. brauchen Mitarbeiter das Gef hl einzigartig zu sein Irgendwann f ngt ein Team an sich als etwas besonderes zu sehen Alle versp ren dasselbe Elitegef hl man hebt sich von den anderen ab Egal worin sich die Einzigartigkeit ausdr ckt sie bildet die Grundlage f r die Identit t des Teams Jedes Team braucht eine Herausforderung Nur das beste ist gut genug f r uns Bekommt das Team nur die Gelegenheit einer mittelm igen T tigkeit weil z B Zeit oder Geld fehlen dann hat das Team keinen Anreiz eine herausragende Leistung zu erbringen Jeder sch mt sich auch an einem Schundprojekt mitzuarbeiten Qualit tsbewusstsein ist immer wichtiger Daher ist das Teammotto Nur die beste Qualit t ist gut genug f r uns vom Management her zu f rdern Leitfaden Projektmanagement Q Office 2 Heip Hier noch Punkte die einen Teamorientierten Manager sowie einen Teamorientierten Mitarbeiter auszeichnen Teamorientierter Manager e Kompetenz bei Mitarbeitern anerkennen e Gewisses Ma an Freiheit und Verantwortung f r bestimmte Aufgaben an Mitarbeiter bertragen e Vertrauensvorschuss gew hren e Teams sich selbst bilden lassen Mitspracherecht bei der Zusammensetzung einr umen e Administrative und organisatorische H rden f r das Team aus dem Weg r umen e Teams zeitweise v llig autonom arbeiten lassen e Teams zeitweise in Isolation verbannen Hotel abgelegenes B ro Ferienhaus Teamorientierter Mitar
81. chen zeitkritisch Diese Projekte mussten eben inklusive aller Tests bis zum 31 12 1999 abgeschlossen sein W hre dies nicht der Fall gewesen so w hren ein elementares Projektziel verfehlt worden Ebenso musste die Umstellung von Software von vierstelligen auf die f nfstelligen Postleitzahlen ebenso zu einem bestimmten Termin fertig werden Es gibt kaum ein Projekt bei dem kein explizites Terminziel festgelegt ist Termine sind verglichen mit Kosten aber auch mit dem Sachziel einfach zu definieren und zu berwachen Wichtig bei der Definition des Terminziels ist das Ziel so zu definieren dass es auch realistisch erreicht werden kann Die Erfahrung aus vielen Projekten zeigt dass hier allzu oft F hrungskr fte Termine versprechen die bei genauerer Analyse des Projekts nicht zu halten sind Dabei spielen oftmals die politischen Gr nde eine Rolle Die Leistungsf higkeit des eigenen Bereichs soll bewiesen werden ein anderer Bereich soll ausgestochen werden und so weiter Oder der Vertrieb hat in seinen Kundenverhandlungen den Mund etwas zu voll genommen und zuviel versprochen So muss es auch nicht wundern dass Terminziele sehr h ufig verschoben werden Das ist beispielsweise bei Forschungs und Entwicklungsprojekten durchaus typisch und oft zwingend da sich der Verlauf eines solchen Projekts nicht immer exakt determinieren l sst Auf der anderen Seite zeigt sich daran oft auch dass Projekte eben nicht gr ndlich analysiert und
82. chen regelt Die getroffenen Abmachungen m ssen in einem Protokoll festgehalten werden e Die Projektorganisation ist vom Projektleiter in Absprache mit dem Auftraggeber und dem Review Board unter Ber cksichtigung der Unternehmensorganisation und der Projektsituation festzulegen Projekte sind standardm ig nach Matrixorganisation zu organisieren Die ins Projekt abgeordneten Mitarbeiter berichten demnach fachlich an den Projektleiter disziplinarisch bleiben sie ihrem personalverantwortlichen Leiter unterstellt e Der abgebende personalverantwortliche Leiter muss sicherstellen dass vollzeit abgeordnete Mitarbeiter nach Beendigung dieser Abordnung in ihrem alten Bereich entweder ihre alte T tigkeit oder eine neue gleichwertige T tigkeit aufnehmen k nnen Diese Regelung ist mit jedem Mitarbeiter vor Beginn der Abordnung abzukl ren und schriftlich zu fixieren e Die zwischen Auftraggeber Projektleiter und abgebendem Management abgesprochenen Zeitr ume der Abordnung oder die bei sporadischer Mitarbeit am Projekt in Frage kommenden Projekttage werden vom Projektleiter terminlich fixiert Die so festgelegten Zeitr ume bzw Termine sind f r alle Beteiligten verbindlich e Projektteam Mitglieder sind nur nach R cksprache mit dem Projektleiter f r andere T tigkeiten abstellbar e Mit Start des Projektes wird falls noch nicht geschehen ein Review Board gegr ndet das als oberste Kontrollinstanz im Projekt fungiert und gleichzeitig in Pr
83. chiede zwischen fr heren Konfigurationen und den aktuellen Konfigurationen immer erkennbar sind Das Konfigurationsmanagement stellt sicher dass jederzeit auf vorausgegangene Versionen zur ckgegriffen werden kann Dadurch sind nderungen nachvollziehbar und berpr fbar KM1 KM Planung Man gt KM1 1 KM Plan erstellen KM12 KM einrichten KM2 Produkt und Konfigurationsverwaltung KM2 1 Produkt initialisieren Konfiguration initialisieren Produkt verwalten Konfiguration fartschreiben KM2 5 Zugriffsrechte verwalten Adr ngauragl Protienmek ng KM3 nderungsmanagement Konfigurationssteuerung KM3 1 nderung bewerten KM3 2 nderungsvorgehen entschei den und nderung einleiten KM33 nderung abschlie en KM4 KM Dienste Daten administrieren SW HW Produkte katalogisieren Schnittstellen koordinieren Ergebnisse sichern KM Dokumentation f hren Release Management durchf hren Projekthistorie f hren j Zentraler Produktkanlog Abbildung 21 Submodell KM im V Modell ber die KM Planung werden die f r das Projekt geltenden Richtlinien verbindlich festgelegt und die Voraussetzungen f r ein zuverl ssiges Konfigurationsmanagement geschaffen Die Produkt und Konfigurationsverwaltung sorg daf r dass Produkte und Konfigurationen eindeutig Leitfaden Projektmanagement Q Office 2 Heip identifiziert zugriffsgesichert und rekonstruierbar gespeichert sind Das nderungsman
84. chster Art entwickelt werden bei denen die Kosten berhaupt keine Rolle spielen Aber selbst bei Softwareentwicklungsprojekten gerade in gr eren Unternehmen spielen die Kosten nur eine untergeordnete Rolle im Projektmanagement Urs chlich daf r sind zwei Aspekte e Die Mitarbeiter sind ohnehin vorhanden Die meisten Kosten entfallen aber auf die Mitarbeiter oder auf andere Gemeinkosten Es entstehen nur wenige dem Projekt direkt zurechenbare Kosten e Die Kosten sind schwer messbar da es sich eben um Gemeinkosten handelt Daher wird oftmals auf eine Betrachtung der Kosten verzichtet Dieses Verhalten spiegelt ein mangelndes Kostenbewusstsein wider Sp testens dann wenn das Ergebnis eines Projektes in irgendeiner Form verkauft wird sollten die Kosten zumindest n herungsweise genau erfasst werden Nur dann kann ein Kostenziel definiert und erkannt werden ob sich das Projekt berhaupt rechnet Kosten lassen sich bei allen Projekten erfassen In vielen F llen sind bereits Verrechnungskosten beispielsweise f r Personal definiert die verwendet werden k nnen um die im Projekt entstehenden Kosten einigerma en genau zu erfassen Auch wenn es zu keinen direkten Mittelabfl ssen kommt und auch wenn die meisten entstehenden Kosten Gemeinkosten sind l sst sich so doch eine einigerma en genaue Betrachtung erreichen Das aber hilft f r eine ganze Reihe von Punkten e Durch die Einbeziehung der Kosten in das Projektmanagement kann ei
85. chtert Ein wichtiger Faktor ist in diesem Zusammenhang auch die Strukturierung von Projekten Strukturierung bedeutet eine Verminderung der Komplexit t 5 7 3Ganzheitliches Projektmanagement Projekte k nnen ebenfalls als Systeme betrachtet werden Sie sind Teile eines Ganzen bestehen aber auch ihrerseits aus zahlreichen Einzelelementen Die formalisierten Abl ufe und Verfahren die Sie kennenlernen werden und die die Zielgr en aus dem magischen Dreieck erfassen sind nur die eine Seite der Medaille Im Alltag eines Projektes spielen auch die nicht formalisierbaren Soft Faktoren eine Rolle Das hei t Kommunikationsprobleme ngste von Mitarbeitern Status Leitfaden Projektmanagement Q Office 2 Heip und Prestigedenken fehlende Teamregeln und so weiter behindern oft die Projektarbeit und stellen den Gesamtprojekterfolg in Frage Das Ganzheitliche Projektmanagement integriert die eingesetzten Systeme Verfahren und Methoden mit den psycho sozialen Prozessen der Projektarbeit Es ber cksichtigt gleichzeitig die strukturellen Voraussetzungen der Organisation Fachkenntnisse der Projektbeteiligten richtige Anwendung der Methoden Kenntnisse um Verhaltensaspekte der Teammitglieder 5 7 4Der Projektiebenszyklus Die Laufzeit eines Projekts kann je nach Gr e und Komplexit t unterschiedlich sein Im Kern folgt aber jedes Projekt einem bestimmten Zyklus dem Projektlebenszyklus Ob Sie ein Haus bauen eine Feier orga
86. cial PRINCE2 publication Wikipedia Addison Wesley Nadin Ebel Seite 207 Die Function Point Methode IBM Form Nr GE12 1618 1 Systems Engineering Methodik und Praxis Verlag Industrielle Organisation Z rich 7 Auflage ISBN 3 85743 964 5 Lehrbuch der Softwaretechnik Software Management Software Qualit tssicherung Unternehmensmodellierung ISBN 3 8274 0065 1 Sneed Harry Sch tzung der Entwicklungskosten von objektorientierter Software in Informatik Spektrum 19 133 140 1996 Br mmer Wolfgang Management von DV Projekten Praxiswissen zur erfolgreichen Projektorganisation in mittelst ndischen Unternehmen Vieweg Braunschweig Wiesbaden 1994 deutsch Kupper Hubert Zur Kunst der Projektsteuerung Qualifikation und Aufgaben eines Projektleiters bei DV Anwendungsentwicklungen Oldenbourg M nchen Wien 1988 deutsch Handbuch zur Projektmanagement Software MS Project Project 98 2000 Microsoft Press Page Jones Meilir Praktisches DV Projektmanagement Grundlagen und Strategien Regeln Ratschl ge und Praxisbeispiele Hanser M nchen Wien 1991 deutsch Steve McConnell Software Project Survival Guide Microsoft Press Walker Royce Software Project Management Addison Wesley Gerhard Verstegen Projektmanagement mit dem Rational Unified Process Sonderdruck RAK 2000 IT Infrastructure Library Clemens Winkler 2007 The Stationery Office Managing Successful Pr
87. d Abnahmeprozess ebenso wie die Aufnahme von Anforderungen Ferner wird durch da im RUP integrierte nderungsmanagement die Handhabung von nderungsw nschen f r beide Seiten Auftraggeber und Auftragnehmer standardisiert e Durch eine konsequente Teststrategie und kontinuierliche Integrationsvorg nge wird eine b se berraschung am Ende des Projektes vermieden e Schnelle Fehlerbehebung und Vermeidung von Folgefehlern e Durch sogenannte Toolmentoren wird innerhalb des RUP direkte Hilfestellung zur Werkzughandhabung innerhalb des Projektes geboten e Verbesserung der Kommunikation im Projekt Mangelnde Kommunikation ist eine der h ufigsten Ursachen f r das Scheitern von Projekten Der RUP regelt den Informationsfluss auf eine eindeutige Art und Weise e Bessere Planungsm glichkeiten als Projektleiter e Einheitliche Vorgehensweise projekt bergreifend Wichtige Projekterfahrungen ob negativ oder positiv werden in neuen Projekten direkt genutzt Durch die Flexibilit t des RUP der eine kontinuierliche Anpassung gestattet k nnen besonders die negativen Erfahrungen in Folgeprojekten vermieden werden 12 7Prozessmodelle der letzten Jahre Im folgenden sollen die Prozessmodelle kurz angerissen werden die in den letzten Jahren die Softwareentwicklung Softwareentwicklungsprojekte gepr gt haben Allen Modellen gemeinsam ist dass die Motivation die bei der Konzeption dieser Modelle im Vordergrund stand immer die Verbesserung
88. d Controlling RMC bedeutet nicht die sehr kostenintensive Ausschaltung jeglicher Risiken sondern das Bewusstsein im Hinblick auf vorhandene Risiken und einen aktiven Umgang mit diesen Wagnissen Unternehmen und Projektleiter die ihre Risiken kennen und diese perfekt managen werden in Zukunft die erfolgreichsten sein Denn Risikomanagement bedeutet auch Chancenmanagement 5 Murphys Low Murphys Gesetze Auszug Wenn etwas schief gehen kann dann wird es auch schief gehen Seite 135 Leitfaden Projektmanagement To Office 2 Heip Seite 136 Risiko deckung Abbildung 30 Abw gen Risiko Ziel des Risikomanagements ist es die Wechselbeziehungen zwischen Risiken und Erfolg zu formalisieren und in anwendbare Prinzipien und Praktiken umzusetzen Aufgabe des Risikomanagements ist es Risiken zu identifizieren anzusprechen und zu beseitigen bevor sie zu einer Gefahr f r ein erfolgreiches Projekt werden oder die Hauptquelle f r berarbeitung darstellen Fazit Angesichts der Komplexit t von Projekten entstehen leicht Frustration oder Resignation Aber es gibt langfristig gesehen keine Alternative zum Einsatz und der Durchf hrung eines Risikomanagements Beginnen Sie in kleinen Schritten und mit den Ihnen zur Verf gung stehenden Potentialen Hierzu werden keine teuren IT Tools ben tigt Viele der Ma nahmen lassen sich mit den meist den im Unternehmen vorhandenen Potentialen realisieren Es geht in erster Linie um den zie
89. darzustellen Der Projektleiter ist daf r verantwortlich dass alle Pl ne in dem f r das Projekt festgelegten berwachungsturnus siehe Regeln zur Projektkontrolle aktualisiert werden F r alle Projekte ist zur berwachung des Projektfortschritts der Einsatz eines Planungs und Steuerungsinstruments verbindlich 19 1 6Regeln zur Projektkontrolle Projektkontrolle dient nicht der Kontrolle der Mitarbeiter sondern ist auf die Uberwachung des Projektes ausgerichtet Basis der Projekt berwachung ist der in einem festgelegten Turnus von jedem Projektmitarbeiter abzuliefernde T tigkeitsbericht Es obliegt dem Projektleiter ob eine schriftliche Fassung notwendig ist oder ob die Projektteam Sitzungen daf r ausreichend sind Eine Zusammenfassung des sich aus den T tigkeitsberichten bzw nachweisen ergebenden Projektstatus ist in schriftlicher Form an den Auftraggeber bzw das Review Board Projekt Board zu richten z B monatlich jeweils zum 30 des Monats Verantwortlich f r diesen Bericht ist der Projektleiter Bei gravierenden Planabweichungen ist der Projektleiter verpflichtet das Review Board umgehend zu informieren bzw eine au ergew hnliche Status Sitzung einzuberufen Bei dieser Status Sitzung sind vom Projektleiter die Abweichungen von den Planwerten transparent zu machen die Gr nde f r die Abweichungen klarzulegen und nach M glichkeit Alternativen zur Behebung der Probleme aufzuzeigen Ma nahmen Dabei
90. de des Vorg ngers starten darf Zeitwert Zeitabstand Wird einer Anordnungsbeziehung zugeordnet Er kann gr er als kleiner als oder gleich Null sein Beispiele Normalfolge mit 3 Tagen Zeitwert bedeutet dass der Nachfolger erst 3 Tage nach dem Ende des Vorg ngers starten darf Normalfolge mit 3 Tagen Zeitwert bedeutet dass der Nachfolger schon 3 Tage vor dem Ende des Vorg ngers starten darf Seite 205 Leitfaden Projektmanagement Seite 206 21 2 2Abk rzungen CASE DV FSA function points Q Office 2 Heip Computer Aided Software Engineering Datenverarbeitung Funktionsstrukturanalyse Ma f r den Umfang Gr e und Komplexit t eines Anwendungssystems Gesch ftsbereich Individuelle Informationsverarbeitung Informations Systeme Informationsstrukturanalyse Informations Technologie Microsoft Solutions Framework Projekthandbuch Projektleiter Qualit tssicherung Rational Unified Process Rechenzentrum Software Entwicklungs Vorgehens Modell Unified Modelling Language Frankfurter Zentralstelle f r Arbeitsvermittlung der Bundesanstalt f r Arbeit Leitfaden Projektmanagement Q Office 2 Heip 21 3Quellenverzeichnis 21 3 1Allgemein Literatur IBM DAENZER HELMUT BALZER SNEED BR MMER KUPPER MICROSOFT CORPORATION 1997 MARTIN KUPPINGER HELMUT REINKE MATTHIAS J GER PAGE JONES STEVE MCCONELL WALKER ROYCE GERGARD VERSTEGEN Clemens Winkler Offi
91. den oftmals durch irrationale auch als politisch bezeichnete Entscheidungen von Vorgesetzten unterschiedlicher Ebenen beeinflusst Das beginnt bei den schon erw hnten Terminvorgaben und geht bis zu kurzfristigen nderungen elementarer Bestandteile des definierten Sachziels e Innerhalb von Projektteams spielen sich wohl immer auch soziale Konflikte ab Ob es dabei um Hackordnungen zwischen den Teilnehmern geht oder schlicht darum dass sich einzelne Projektteilnehmer nicht leiden k nnen in jedem Fall ist der Projektmanager gefordert diese Situation zu kontrollieren um zu verhindern dass sie sich auf den Erfolg des Projekts durchschl gt F r den Projektmanager bedeutet das dass er sich vor dem Projekt ber solche Probleme informieren muss dass er die Ziele im Projekt klar definieren muss und dass er nach M glichkeit selbst Einfluss auf das Projektteam nehmen sollte soweit er das kann In jedem Fall erfordert es aber vom Projektmanager neben der fachlichen Kompetenz f r das Projektmanagement ein hohes Ma an personeller F hrungsf higkeit Diese Probleme spielen bei externen und internen Projektmanagern gleicherma en eine Rolle F r den externen Projektmanager liegt das Leitfaden Projektmanagement Q Office 2 Heip Hauptproblem darin interne Probleme zu erkennen und sich eine aus reichende R ckendeckung f r die L sung solcher Probleme zu sichern F r den internen Projektmanager liegt die Schwierigkeit weniger in der
92. denen L sungen in Relation zum Aufwand f r organisatorische nderungen bestehender Gesch ftsprozesse ist 5 2Das Management Das zweite Element des Begriffes Projektmanagement ist das Management Der Duden definiert Management als Leitung eines Unternehmens Betriebsf hrung Der Begriff des managen wird mit leiten zustande bringen geschickt bewerkstelligen organisieren definiert F r das Projektmanagement ist es wichtig den Begriff mit leiten zu bersetzen Beim Projektmanagement geht es um mehr als die Verwaltung der Durchf hrung einer Aufgabe Es geht auch um mehr als die unreflektierte Umsetzung vordefinierter Schemata und die Nutzung definierter Methoden Projektmanagement bedeutet die Leitung der Projekte und die L sung der dabei entstehenden Konflikte Dies Verst ndnis ist von elementarer Bedeutung f r den Projekterfolg Der Projektmanager muss Regelungskompetenzen besitzen um schnell reagieren und Konflikte ohne endlose und gar zu oft auch fruchtlose Konsultationen anderer Instanzen der Organisation l sen zu k nnen F r den Erfolg eines Projektes ist es unerl sslich das leidiges Kompetenzgerangel soweit wie m glich ausgeschlossen wird und der Projektmanager den n tigen Handlungsspielraum hat 5 3Das Projektmanagement Das Projektmanagement ist damit die Leitung eines durch seine Einmaligkeit definierten Vorhabens Damit ist Projektmanagement eine Herausforderung f r die durchf hrenden Kr fte Nicht ums
93. die Cliquenbildung und zerfallen leicht in kleinere Gruppen Diese Aussage steht scheinbar im Widerspruch zu der Aussage dass Professionalismus d h Standardisierung von Qualifikationen die Bildung gro er Einheiten zul sst Der Widerspruch l st sich wenn man beachtet dass professionelle Arbeit immer komplex aber nicht immer interdependent ist Es gib zwei Arten von professioneller Arbeit Die eigenst ndigen nach au en hin abgegrenzten Aufgaben die eine ganz andere Strukturform verlangen als die interdependenten Aufgaben Betrachtet man einmal die Gr e von Arbeitseinheiten und Teams und die Anzahl der dabei entstehenden Kommunikationskan le untereinander so wir man sehr schnell feststellen das die direkte Kommunikation innerhalb einer Organisation nur mit einer begrenzten Anzahl von Mitarbeitern funktioniert und es sinnvoll ist nur entsprechend berschaubare Team Organisationsstrukturen z B im Projekt aufzubauen sind Bei 5 Mitarbeitern entstehen so bereits 10 Kommunikationspaare Abbildung 9 Kommunikationspaare 5 Mitarbeiter Bei 9 Mitarbeitern entstehen sogar schon 36 Kommunikationspaare FI ZZ TEL Abbildung 10 Kommunikationspaare 9 Mitarbeiter Seite 60 Leitfaden Projektmanagement Q Office 2 Heip Der Kommunikationsaufwand darf also nicht untersch tzt werden Bei anspruchsvollen Projekten mit starker gegenseitiger Abh ngigkeit der Aufgaben d rfen d rfte die optimale Mitarbeiterzahl ve
94. diesem Fall ist die Projektarbeit davon abh ngig wie gut es Leitfaden Projektmanagement Q Office 2 Heip gelingt die Projektmitarbeiter f r die Projektarbeit zu gewinnen und sich gegen die Linie durchzusetzen Die Einfluss Projektorganisation bedarf eines st rkeren Sponsoring als andere Formen der Projektorganisation Sie wird immer dann auf Dauer gut funktionieren wenn der Stellenwert der Projektarbeit im Unternehmen hoch ist Die dritte Form als Matrix Projektorganisation bezeichnet ist letztlich die projektspezifische Auspr gung der inzwischen schon klassischen Matrixorganisation Dabei werden gr ere ber die Funktionsbereiche hin berreichende Projekte durch Projektleiter geleitet die auch Vorgesetzte mit allen Verantwortlichkeiten f r dieses Projekt sind Durch diese Organisationsform werden allerdings weder die Probleme in der Abstimmung zwischen Linie und Projekt noch andere Probleme wirklich gel st Im Vergleich mit einem effizienten Sponsoring zum Beispiel durch einen Lenkungsausschuss bew hrt sich diese Form daher kaum Eine h ufig in Unternehmen in denen die Projektarbeit einen hohen Stellenwert besitzt vorzufindende Struktur ist die Einf hrung eines Lenkungsausschusses Der Lenkungsausschuss ist gleichbedeutend mit einer Institutionalisierung des Sponsoring f r Projekte Abbildung 5 Die Matrix Projektorganisation Er hat allerdings den kleinen Nachteil dass die Gefahr besteht dass Projekte bereits da
95. e als auch auf unterschiedliche Unternehmensformen anpassbar sein m ssen Nur so kann sichergestellt werden dass ein Projektmodell auch in der Fl che und nicht nur in einer kleinen Anwendergruppe zum Einsatz kommt Im V Modell wird dieser Prozess der Anpassbarkeit als Tailoring Zuschneiden Anpassen bezeichnet das f r jedes neue Projekt durchgef hrt wird Dazu werden entsprechende Schl sseleigenschaften des Projektes untersucht um anschlie end die durchzuf hrenden Aktivit ten zu bestimmen und die Produkte festzulegen die erstellt werden m ssen Um das V Modell f r ein konkretes Projekt anwendbar zu machen muss deshalb entschieden werden e Welche Aktivit ten sind f r die Durchf hrung des Projektes erforderlich e Welche Produkte m ssen im Rahmen der Projektabwicklung erzeugt werden Im V Modell existiert somit ein festes Regelwerk in dem definiert wird wann und unter welchen Bedingungen welche Aktivit t durchgef hrt werden muss Das Hauptanliegen des Tailoring besteht darin f r jedes Projekt zu gew hrleisten dass der eingesetzte Aufwand den Projektzielen dienlich ist Zu vermeidende Probleme dabei sind e berm ige Papierflut e Sinnlose Dokumente e Das fehlen von wichtigen Dokumenten Dies wird durch die Reduzierung der allgemeing ltigen generischen Regelungen des V Modells auf die aus sachlichen Gr nden erforderlichen Regelungen erreicht Die entsprechende Teilmenge des V Modells projektspezifi
96. e mit dem Auftraggeber Leitfaden Projektmanagement Q Office 2 Heip 8 3 2Review Board Lenkungskreis Das Review Board oder oft auch Lenkungskreis genannt ist die oberste Review Board Kontrollinstanz und stellt gleichzeitig in Problemsituationen die Anlaufstation und Entscheidungsinstanz f r den Projektleiter dar Dem Review Board geh ren folgende Mitglieder an als st ndige Mitglieder Vertreter der Konzernleitung der Auftraggeber Leitung DV der Projektleiter nur als berichtendes Mitglied Finanz Controller optional bei Projekten mit starker externer Beteiligung o Entscheidungstr ger externer Partner 00000 Abbildung 12 Struktur eines Review Boards Seite 65 Leitfaden Projektmanagement To Office 2 Heip Aufgaben Review Board Projekt Board Aufgaben Projekt Board Seite 66 Die Aufgaben des Review Boards sind Genehmigung der Projektorganisation Uberpr fung und Freigabe von Zielen Freigabe von Projektphasen Beseitigung von realen und m glichen Konflikten zur Erreichung des Zieles oberste von zwei m glichen Eskalationsstufen bei Problemen im Projekt Bereitstellung der technischen Mittel e Bereitstellung der finanziellen Mittel Budgets e Best tigen des Projektplans des Projekt Handbuchs und des Qualit ts Plans Voraussetzung zur Erf llung vorstehender Aufgaben ist die Beschlussf higkeit Dazu m ssen die im Review Board anwesenden Personen die notwendige fachliche und finanziel
97. eam sichergestellt Die Anwendervertretung bernimmt innerhalb des Projektteams eine Teilverantwortung und vertritt die Anwenderziele des Projektes Dar ber hinaus kann es notwendig sein weitere Anwendervertreter in den Abstimmungsprozess mit einzubeziehen Dies kann z B in Form von Workshops geschehen in denen bestimmte Zwischenergebnisse vorgestellt und weitere Vorgehensschritte abgestimmt werden Funktionen des Projektteams sind e Praxisgerechte L sung entwickeln e Produkte installieren und testen e Abnahme vorbereiten e Schulung des Endanwenders Im Projektteam kann es Teilteams mit abgegrenzten Aufgabenkompetenzen geben Der Projektleiter hat dies zu organisieren In kurzen Abst nden m ssen informelle Sitzungen stattfinden Projektteam Sitzungen dienen der Information des Projektteams In diesen Sitzungen berichtet jeder Mitarbeiter ber seine T tigkeit im vergangenen Berichtszeitraum und ber die aufgetretenen Probleme Der kommende Berichtszeitraum wird gemeinsam geplant Aktionen und T tigkeiten f r diesen festgelegt Seite 63 Mitglieder des Projektteams Anwendervertret er Repr sentanten Funktionen des Projektteams Projektteam Sitzungen Leitfaden Projektmanagement Q Office 2 Heip Auftraggeber Seite 64 Diese Sitzungen m ssen in einem festen Turnus stattfinden z B jeden Freitag 14 30 Uhr sie sollten von der Dauer her begrenzt sein z B max 1 Stunde Die festgelegte Zeit
98. echnischen Universit t M nchen TUM und den Partnern IABG EADS Siemens AG 4Soft GmbH und TU Kaiserslautern in Auftrag gegeben In das neue V Modell XT eXtreme Tailoring sind neben neuer Methodik und Technologie auch umfangreiche Erfahrungen und Verbesserungsvorschl ge die bei der Anwendung des V Modells 97 gesammelt wurden eingeflossen Neben der inhaltlichen Aktualisierung sind dabei insbesondere die folgenden Verbesserungen und Neuerungen enthalten e Vereinfachte projektspezifische Anpassung Tailoring e berpr fbare Projektfortschrittsstufen f r eine Risiko minimierende Projektsteuerung e Ausschreibungserstellung Vergabe und Projektdurchf hrung durch den Auftraggeber e Verbesserung der Auftraggeber Auftragnehmer Schnittstelle e Systementwicklung unter Ber cksichtigung des gesamten Systemlebenszyklus e Abdeckung von Hardwareentwicklung Logistik Systemsicherheit und Migration e Einf hrung und Pflege eines organisationsspezifischen Vorgehensmodells e Integration von aktuellen Quasi Standards Normen und Vorschriften e Sichtenbasierte Darstellung und anwenderspezifischer Zugang zum V Modell e Erweiterter Geltungsbereich Erweiterter Geltungsbereich hei t mit dem V Modell XT hat sich auch die zugrunde liegende Philosophie weiter entwickelt Das neue V Modell unterscheidet grunds tzlich in Auftraggeber und Auftragnehmer Projekte Die Ergebnisse stehen im Mittelpunkt und nicht wie bisher die Aktivit ten
99. edarfsfall Schulung e Uberwachung der Durchf hrung der Erhebung Seite 189 Leitfaden Projektmanagement To Office 2 Heip Ziele Vorbereitung Durchf hrung Themenliste Folgeaktivit ten Termin Seite 190 19 6Statussitzungen Ziele e alle am Projekt Beteiligten sind ber Status und Problemsituation informiert e alle wichtigen Entscheidungen werden ohne Verz gerung gef llt e unterst tzende Aktionen werden gestartet Vorbereitung Projektleiter e Aufbereitung der erforderlichen Unterlagen e Einberufung durch Projektleiter Durchf hrung Teilnehmer e alle Mitglieder des Review Boards sonst nicht beschlussf hig Themenliste e Problemsituation darstellen und durchleuchten e entsprechende Ma nahmen Wege aufzeigen e Experten zu Rate ziehen e Entscheidungen f llen Standard ist hierbei generelle Fortschrittskontrolle Pl ne sichten Projektstatus berpr fen Zielsetzungen berpr fen Ausbildungsstand berpr fen Kostensituation berpr fen Personalsituation berpr fen neue Projekte Phasen einleiten gt Freigabe Folgeaktivit ten Projektleiter e Sitzungsprotokoll erstellen und verteilen e Ma nahmen unverz glich durchf hren e Termineinhaltung gew hrleisten Review Board Mitglieder e die ihnen zugeordneten Aktionen einleiten und durchf hren Termin e definiert z B monatlich e Phasenende bzw Phasenbeginn z B Meilenstein Reviews e zu anderen Situationen Problemsituationen L
100. ehandlung von Anforderungsanalysen zur Verf gung Es ist eine Implementierungsmethodologie was dazu f hren kann dass Projekte unter falschen Voraussetzungen aufgenommen werden und in der Folge scheitern e Ohne sorgf ltige Anpassung an die Erfordernisse des Projekts kann PRINCE2 ein viel zu schwergewichtiges Vorgehen f r kleine Projekte sein weil es zu viel Arbeit erzeugt e Die B cher die f r die Schulungen unentbehrlich sind sind ziemlich teuer 12 7 8 15Zertifizierungen F r PRINCE2 gibt es zwei Zertifizierungen 12 7 8 15 1Foundation Examination Die Foundation Examination deutsch Grundlagen Pr fung ist ein Wissenstest ber das PRINCE2 Handbuch und seine Projektmanagement Methodologie Die Pr fung dauert eine Stunde und besteht aus einem Multiple Choice Test mit 75 Fragen Zum Bestehen muss man mindestens 38 Fragen richtig beantworten 12 7 8 15 2Practitioner Examination Kandidaten f r die PRINCE2 Practitioner Examination deutsch Praktiker Pr fung m ssen zuvor die Foundation Examination bestanden haben Die dreist ndige Pr fung ist fallbasiert mit einem Hintergrund Szenario und drei Fragen Jeder der diese Pr fung bestanden hat sollte in der Lage sein PRINCE2 im Ablauf und Management eines Projekts anzuwenden Leitfaden Projektmanagement Q Office 2 Heip 12 8Anpassbarkeit von Prozessmodellen Eine wesentliche Voraussetzung f r Prozessmodelle besteht darin dass sie sowohl auf verschiedene Projekt
101. eiche beziehen Vorgehensmodell Leitf den Produktnormen Werkzeuge Zusammenarbeit mit Beteiligten Sch tzung Planwerte Abweichungen Leitfaden Projektmanagement Q Office 2 Heip Obwohl jedes Projekt einzigartig ist gibt es jedoch einige Phasen Abschnitte die Zielerreichungs in jedem Projekt wiederholt bzw zur Planung und Kontrolle verwendet werden analyse Nutzen m ssen bewertung Eine Zielerreichungsanalyse Nutzenbewertung sollte unbedingt durchgef hrt werden wenn wesentliche Ergebnisse f r das Projekt oder die Weiter und Neuentwicklung von Verfahren und Informationssystemen zu erzielen sind Dieses Element kann deshalb erg nzend in den Projektmanagementprozess aufgenommen werden wenn der Kunde es w nscht Ziele Wirtschaftlichkeitsanalyse Systemausbau und Aktualisierung Funktione Einsatz des Systems im betrieblichen Produktionsprozess kontrollieren n sowie Erfolgskontrolle des realisierten Verfahrens inwieweit die urspr nglich gesetzten Ziele nach einer Einf hrungszeit von 3 bis 6 Monaten erreicht wurden 1 berwachung des Informationsflusses 2 Aufnahme von Kenndaten Nutzen Kosten Personalaufwand Qualifikation 3 Verbesserung der Systemwartung Instanzen Auftraggeber ggf Review Board bzw Projekt Board oder IT Seite 171 Leitfaden Projektmanagement To Office 2 Heip 19Hilfsmittel 19 1Regeln zur Projektdurchf hrung 19 1 1Regeln f r die Projektgr ndung Auftraggeber f r das Projekt i
102. eiligung von Besch ftigten anderer Unternehmen externe Berater muss durch vertragliche Regelungen ber die Aufgabenverteilung festgelegt werden wer in dem Projekt die fachliche Verantwortung bernimmt Dies ist insbesondere bei Beratervertr gen zu beachten In disziplinarischer Hinsicht bleiben externe Berater ihren jeweiligen Personalvorgesetzten in der Firma unterstellt Leitfaden Projektmanagement Q Office 2 Heip 19 1 4Regeln zur Projektsch tzung Der Projektleiter ist verpflichtet vor dem Start einer Projektphase eine realistische Aufwand und Zeitsch tzung f r diese Phase und zugleich f r den Gesamtaufwand durchzuf hren F r diese Sch tzung muss dem Projektleiter gen gend Zeit zur Verf gung gestellt werden Die ermittelten Sch tzwerte sind in schriftlicher Form unter Angabe der Sch tzungsmethode und dieser Sch tzung zugrunde gelegten Randbedingungen an den Auftraggeber zu bergeben Eine einmal gew hlte Sch tzmethode ist f r die Dauer des Projektes beizu behalten Die Sch tzergebnisse k nnen und sollen durch den Einsatz anderer Verfahren im Lauf des Projektfortschrittes pr zisiert verfiziert werden 19 1 5Regeln zur Projektplanung e Dem Projektleiter muss gen gend Zeit zur Planung zur Verf gung gestellt werden e Der Aufwand des Projektleiters f r Planung und Sch tzung ist aus Gr nden der Nachkalkulation als Aktivit t in dem Projektplan explizit auszuweisen e Die Planung des Projektes
103. eilungen Risiko Projektabschluss Letzte Phase des Projektlebenszyklus in der e das Projektergebnis an den Auftraggeber bergeben e die Projektorganisation aufgel st und e ein Res mee aus dem zur ckliegenden Projektverlauf gezogen wird zur Erfahrungssicherung f r zuk nftige Projekte Nach dem Projektabschluss ist das Projekt offiziell zu Ende Projektabschlu bericht Bericht des Projektleiters mit einer Zusammenfassung des Projektverlaufs Projektabschlusssitzung Projektreview Letzte Sitzung des Projektteams in der die Erfahrungen aus der Projektabwicklung diskutiert werden Ferner wird festgelegt wer ber den Projektabschluss und dessen Ergebnis informiert werden soll Projektantrag Ein noch nicht erteilter Projektauftrag der alle Informationen enth lt nach denen eine Entscheidung ber die Sinnhaftigkeit eines Projektes gef llt werden kann Projektarten Seite 201 Leitfaden Projektmanagement To Office 2 Heip Seite 202 Kategorisierung von Projekten um leichter Standards z B Standard Projektstruktur entwickeln zu k nnen Beispiele Investitionsprojekte EDV Projekte Forschungs und Entwicklungsprojekte Organisationsprojekte Bauprojekte Projektcontrolling Projektsteuerung Aufgabe des Projektleiters Ziel ist es m gliche Probleme w hrend der Projektabwicklung m glichst fr hzeitig zu erkennen und evtl Steuerungsma nahmen ergreifen zu k nnen Projektkoordination Form e
104. eingeplant werden sondern deutlich weniger Projektzeit Zudem ist es u erst schwierig eine Integrationsma nahme zu planen da hier eine gro e Menge an unbekannten Faktoren existieren die zum Teil erst w hrend der eigentlichen Integration offensichtlich werden und dann zu der Projektverz gerung f hren Seite 85 Leitfaden Projektmanagement To Office 2 Heip Wer liest heute noch Prozessmodelle in Papierform Seite 86 10 1 12Zu hohe Dokumentenorientierung Nahezu alle Prozessmodelle hatten eines gemeinsam sie liegen in erster Linie als Papierform vor Demzufolge orientierte sich auch die gesamte Projektabwicklung anhand von Dokumenten Mal ganz abgesehen vom Umweltaspekt Wer liest schon alle diese Dokumente Oder noch pr ziser gesagt wer hat die Zeit daf r um diese meist gro e Anzahl von Dokumenten w hrend seiner t glichen Arbeit zu lesen Abbildung 15 Die Bedeutung von Dokumenten zugegeben etwas sarkastisch Haben sie schon jemals ein Handbuch von Microsoft WinWord benutzt oder arbeiten Sie mit der Online Hilfe Wenn Sie ehrlich sind werden Sie feststellen dass Sie selbst in ihrem privaten Haushalt auf Dokumente wie eine Bedienungsanleitung f r den neuen Videorecorder kaum noch zur ckgreifen Etwas platt formuliert Entweder das Ding funktioniert auch so und wenn ich etwas wissen will hilft mir die intuitive Benutzerf hrung der Fernbedienung oder das Ger t taugt in dieser Hinsicht nichts K nnen
105. einlichkeit ein unbefriedigendes Ergebnis zu erhalten multipliziert mit dem Schadensausma das dieses unbefriedigende Ergebnis zur Folge hat Ein unbefriedigendes Ergebnis liegt dann vor wenn die Hauptbeteiligten an einem Projekt durch das Ergebnis einen Schaden erleiden Ein unbefriedigendes Ergebnis ist mehrdimensional e F r Kunden und Entwickler sind Kosten und Termin berschreitungen unbefriedigend e F r Anwender Benutzer sind Produkte mit der falschen Funktionalit t mit Defiziten der Benutzeroberfl che der Leistung oder Zuverl ssigkeit unbefriedigend e F r Wartungs und Service Personal ist schlechte Qualit t unbefriedigend Nachstehend einige m gliche Risiko Faktoren e Einsatzfrequenz o Bei einer Funktion einem Vorgang etc der die einige Male am Tag durchgef hrt wird ist die Fehlerwahrscheinlichkeit wesentlich gr er als wenn die Funktion der Vorgang nur einmal im Jahr durchgef hrt wird e Fehlerwahrscheinlichkeit o Komplexe Funktionen o G nzlich neue Funktionen o Funktionen die einer laufenden Ver nderung unterliegen o Funktionen Techniken oder Werkzeuge die zum ersten Mal eingesetzt werden Funktionen die zwischenzeitlich einem anderen bertragen wurden Funktionen die unter hohem Zeitdruck entwickelt werden o Funktionen die berdurchschnittlich optimiert werden m ssen Beschleunigung oder Kostenersparnis o Funktionen in denen bereits in einer fr heren Freigabe oder Pr fung Fehler gefunden wu
106. eiterungen mit Ausnahme gesetzlicher Vorgaben nur noch nach den Regeln des nderungsmanagements zul ssig e Nach dieser Regelung m ssen nderungen mit Begr ndung per Formular nderungsantrag schriftlich an den Projektleiter gerichtet werden Der Projektleiter bewertet die Antr ge Zeit Aufwand und legt diese turnusm ig dem Projekt Board zur Entscheidung vor Diese Entscheidung ist f r alle Beteiligten verbindlich e Der anfordernden Stelle wird eine Kopie des Antrages mit der Entscheidung des Projekt Boards als Nachweis zugesandt Das Projekt Board genehmigt in dieser Sitzung die f r die Durchf hrung der nderung zus tzlich erforderlichen Mitarbeiter bzw die durch die nderungsma nahmen evtl sich ergebenden Terminverschiebungen e Im Konfliktfall ist die Entscheidung durch das Review Board zu erwirken F r Projekte ohne Projekt Board ist das Review Board oberste Entscheidungsgremium e Absicherung der Projektaktivit ten e Die Abwicklung der Projektaktivit ten ist aus bersichts und Steuerungsgr nden durch Pl ne abzusichern e Vorgeschrieben sind dabei folgende Plantypen o Terminplan als Grob und bersichtsplan o Aufgabenstrukturplan o Personalplan e ber die Notwendigkeit weiterer Pl ne muss der Projektleiter von Fall zu Fall abh ngig von der Projektsituation entscheiden e Der Projektleiter tr gt die Verantwortung f r die Aktualit t der Projektpl ne e Einsatz von Erhebungsmethoden e Abh ngig
107. eitfaden Projektmanagement 19 7Durchf hrung eines Interviews Formelle Begr ung e Erkl rung Funktion Ereignis e Top Down Vorgehen erkl ren e auf Ablauf Prozess orientierung eingehen weg von Funktionssicht Organisation behandeln auf Flip Chart festhalten Frage nach dem Ergebnis nicht nach der Leistung der T tigkeit des Kunden nach Ereignissen etc e daraus wird der 1 Prozess auf Top Ebene abgeleitet Verfeinerung des Top Prozesses Abschluss Frage nach Anliegen Schwierigkeiten Verbesserungsm glichkeiten gleichartigen Aktivit ten anderer auch in anderen Bereichen W hrend des Interviews e werden Leistungen des Kunden z B Zusammenstellung weiterer Informa tionen erforderlich dann genauen Termin vereinbaren Wichtig Ablauf muss dargestellt werden Anfang und Ende e Ebenenspr nge Umwege k nnen in Kauf genommen werden Seite 191 Q Office 2 Heip Begr ung Erkl rung Organisation behandeln Fragen Verfeinerung Top Prozess Abschluss F r Leistungen Termine vereinbaren Ablauf darstellen Leitfaden Projektmanagement To Office 2 Heip Seite 192 20Werkzeuge Tools 20 1Microsoft Project Die unterschwellige Hoffnung vieler Projektverantwortlicher wenn sie sich das erste Mal mit einer Software wie z B Microsoft Project besch ftigen ist es ein Werkzeug in die Hand zu bekommen mit dem sich das Projekt mehr oder wenige selbst verwaltet Die ersten Erfahrungen s
108. eitfaden Projektmanagement Q Office 2 Heip QS1 QS Initialisierung QS1 1 OQS Plan erstellen forderungen enthalten QS12 Pr fplan erstellen Qs2 Pr fungsvorberatung Pr fmethoden und kriterien festlegen Pr fumgebung definieren Pr ff lle festlegen Pr fprozedur erstellen Qs3 Proze pr fung von Aktivit ten QS 4 Produktpr fung QS 4 1 Pr fbarkeit feststellen QS42 Produkt inhaltlich pr fen QSS QS Berichtswesen Abbildung 22 Submodell QS im V Modell Im einzelnen sind das mindestens die nachfolgenden Aktivit ten 1 Seite 110 QS Initialisierung a QS Plan erstellen b Pr fplan erstellen Pr fungsvorbereitung a Pr fmethoden und Kriterien festlegen b Pr fumgebung definieren c Pr ff lle festlegen d Pr fprozedur erstellen Prozesspr fung von Aktivit ten Produktpr fung a Pr fbarkeit feststellen b Produkt inhaltlich pr fen QS Berichtswesen a Defekttracking Leitfaden Projektmanagement 12 7 3 5Submodell PM Die Regelungen die das V Modell bez glich der Abwicklung des Projektmanagements trifft beziehen sich nicht auf die organisatorische Einbettung des Projektmanagements innerhalb des Unternehmens vielmehr werden die durchzuf hrenden Arbeiten die wichtigen Phasen und die zu erstellenden Produkte dargestellt Generell lassen sich wie nachstehend dargestellt die einzelnen Aktionen des Submodells drei wesentlichen Bereiche zuo
109. ekten ist manchmal noch viel schlimmer als dieses Gott sei dank nur erfundene Szenario An dem vorherigen Beispiel ist sehr gut zu erkennen auf was es beim Erwartungsmanagement ankommt e Klare u erung was gew nscht wird e Klare Spiegelung der W nsche aus Projektsicht zum Anforderer habe ich es richtig verstanden e Schriftliche Festlegung der gemeinsam gefundenen Basis denn diese Festlegung ist das einzige was Ihnen hilft sollte es zu Meinungsverschiedenheiten kommen e Rechtzeitige klare und umfassende Informationen an den Anforderer wenn Sie feststellen dass die Erwartungen des Anfordernden nicht unvollst ndig oder mit h heren Zeitlichen oder monet ren Aufwand zu realisieren ist Sie helfen dem Anforderer sein Gesicht zur n chsth heren Instanz zu wahren denn nichts ist peinlicher als wenn solche Informationen hinter dem R cken des Projektleiters an den Anforderer kommuniziert werden Doch es bestehen nicht nur Erwartungen nach au en sondern auch Erwartungen nach innen Diese Erwartungen kommen vom eigenen Projektteam als auch von z B Sublieferanten und externen Kunden des Projektes Seite 134 Leitfaden Projektmanagement Q Office 2 Heip 15Risikoanalyse und Management Nehmen wir einmal an dass Sie eine Projektmanagement Software wir z B Microsoft Project verwenden um einen detaillierten Projektplan zu erstellen und Sie davon ausgehen und der Meinung sind an alles gedacht zu habe
110. ektteam funktioniert und die M glichkeiten der Gruppe optimal genutzt werden Leitfaden Projektmanagement Q Office 2 Heip Projekt Projekt itarbeite itarbeite H Projekt Projekt itarbeite itarbeite Projekt Projekt itarbeite Projekt itarbeite itarbeite Abbildung 3 Struktur Projektteam Neben den Mitarbeitern im Projektteam und dem Auftraggeber gibt es die Kontroll und Abstimmungsinstanzen die nicht in die regelm ige Projektarbeit eingebunden sind die aber unter Umst nden entscheidend f r die Weiterf hrung und damit den Erfolg des Projekts sein k nnen Dazu geh ren e Sp tere Nutzer des Projektergebnisses die externen oder internen Kunden e Datenschutzbeauftragter e Revision Wirtschaftspr fer e Betriebsrat und je nach Projekt viele andere Mitarbeiter Bei der Definition des Projektteams stellt sich auch die Frage wie viele Mitarbeiter eigentlich in das Team geh ren Gerade bei Gro projekten die sich ber einen l ngeren Zeitraum erstrecken und an denen viele Mitarbeiter beteiligt sind sollten Sie sich immer im klaren dar ber sein dass die Ausf hrenden nicht in der Projektleitung sein m ssen Nicht jeder Planer Architekt Ingenieur Wissenschaftler oder wer auch immer geh rt in das eigentliche Projektteam Die meisten sind nur Auftragnehmer Ressourcen f r das Projekt 5 6 6Stellung des Projektmanagements im Unternehmen Bei der Einordnung von Projekten in die Gesamtorganisation eines U
111. elle ersichtlich 5 6 2 1Funktionen von Microsoft Project Zieldefinition Microsoft Project kann Informationen aus schon durchgef hrten Projekten f r die Verifikation der Zielsetzung liefern berwiegend werden in dieser Phase aber andere Methoden verwendet die nicht unbedingt DV gest tzt sein m ssen Machbarkeitsstudie Microsoft Project kann Informationen aus schon durchgef hrten Projekten ber die Machbarkeit liefern berwiegend werden aber auch hier andere Methoden eingesetzt Allerdings k nnen die Seite 29 Leitfaden Projektmanagement Seite 30 Grobgliederung Messbarkeit der Ziele Feingliederung Planung berwachung Nachrechnung Initialisierung I Office 2 Heip Vergangenheitsinformationen hier sehr wichtig sein Diese stehen bei konsequentem Einsatz von Projektplanungswerkzeugen in differenzierter Form zur Verf gung Die Ergebnisse k nnen in Microsoft Project bernommen werden berwiegend werden aber auch hier andere Methoden wie das Brainstorming eingesetzt Hier kann eine erste Planung in Microsoft Project mit Kosten und grober Ressourcenzuordnung bereits wichtige Informationen liefern Der R ckgriff auf bereits durchgef hrte Projekte mit Microsoft Project liefert ebenfalls Informationen und erleichtert insbesondere die Aufwandssch tzung in dieser Phase werden wieder berwiegend andere Methoden eingesetzt Die Ergebnisse k nnen in Microsoft Proiect bernommen werden D
112. eln e keine berfl ssige Dokumentation Leitfaden Projektmanagement Q Office 2 Heip 5 5Ziele und Zielkonflikte Ein klar definiertes Ziel ist die Kernvoraussetzung f r erfolgreiches Projektmanagement Wenn es kein Ziel gibt kann das Ziel auch nicht erreicht werden Das Ziel muss zudem messbar sein um den Erfolg oder Nichterfolg eines Projektes genau bestimmen zu k nnen In diesem Abschnitt wird auf die klassischen Ziele und Nebenbedingungen des Projektmanagements und auf die generellen Zielkonflikte die in jedem Projekt entstehen eingegangen Die Ziele In der Literatur zum Projektmanagement werden zumeist drei Ziele unterschieden e Sachziel e Terminziel e Kostenziel Ob es sich bei Termin und Kostenziel tats chlich um eigenst ndige Ziele und nicht nur um Nebenbedingungen des Sachziels handelt kann man zum Gegenstand sophistischer Diskussionen machen Letztlich ndert es aber weder an den entstehenden Konflikten noch an der Art und Weise wie Projektmanagement betrieben wird etwas Das bestimmende Ziel ist dabei zweifellos das Sachziel Dieses gibt vor welche Leistung in dem Projekt erreicht werden soll Das Sachziel muss wie jedes andere Ziel messbar sein Nur bei messbaren Zielen kann berpr ft werden ob das Projekt erfolgreich war oder nicht Nur messbare Ziele k nnen also die Me latte f r den Projekterfolg sein Im Gegensatz zu den beiden anderen im Mittelpunkt der Betrachtung stehenden Zielen ist die Mess
113. en Leitfaden Projektmanagement Q Office 2 Heip Der Bereich Informationssysteme des Auftraggebers definiert und ver ffentlicht IT Standards auf dem Gebiet der Informationstechnik IT einen Unternehmensstandard f r das des Unternehmen Auftraggebers Diese IT Standards des Auftraggebers Kunden sind im IT Warenkorb Standards f r die Informationstechnik bei Firma XYZ festgelegt Dieser Standardkatalog IT Warenkorb enth lt alle Festlegungen in Bezug auf Komponenten der Informationstechnik einschlie lich Werkzeugen die von Projekten anzuwenden sind Er wird gegebenenfalls erg nzt durch einen PC Standardkatalog Um den technischen Fortschritt und neue Erkenntnisse zu ber cksichtigen werden die Standards in erforderlichen Zeitabst nden fortgeschrieben Gegenw rtig genutzte nicht im Standardkatalog enthaltene Produkte werden in k nftigen Projekten grunds tzlich nicht mehr ber cksichtigt Die Anwendung der Standards des IT Warenkorbs ist innerhalb des Unternehmens des Auftraggebers verbindlich Eine weitere Quelle die bei der Planung zu beachten ist ist die Strategische IS Landkarte die das Hardware Architektur Modell Dienstleistungsserver Modell darstellt Das Dokument zur Anwendungsarchitektur beschreibt grunds tzliche ber legungen zur Gestaltung von SW Systemen Seite 161 Leitfaden Projektmanagement Q Office 2 Heip 17 3Anwendungsentwicklungsprozess Die nachfolgende Abbildung zeigt die Zusammenh nge
114. en der Industrie aus da viele Manager hierin neue Werkzeuge sahen um das Wachstum und berleben Ihrer Unternehmen in einer sich schnell ver ndernden und wettbewerbsorientierten Welt zu gew hrleisten In den fr hen 60er Jahren wurden die verschiedensten Modelle auf Hochschulen und in der Forschung entwickelt und in der Praxis mehr oder weniger erfolgreich eingesetzt Richard Johnson Fremont Kast und James Rosenzweig beschrieben in Ihrem Buch The Theory and Leitfaden Projektmanagement Q Office 2 Heip Management of Systems Die Theorie und das Management von Systemen dass ein modernes Gesch ftsleben und die damit verbundenen Interaktionen wie ein menschlicher Organismus mit seinen Skelettsystem seinen Muskeln seinem Nervensystem etc an zu sehen ist 4 4Heutige Sichtweise und Vorgehen Die Sichtweise gesch ftliche Prozesse und Abl ufe mit den Funktionsweisen des Prozesse menschlichen K rpers zu vergleichen setzt voraus das alle betroffenen Teile eben Abl ufe so zusammenarbeiten dass die gesetzten Ziele Projektziele erreicht werden In Projektteam den folgenden Jahrzehnten bildeten sich die Wurzeln f r das moderne Projektmanagement heraus so wie wir es heute kennen W hrend dieser Zeit entwickelten sich eine ganze Reihe von Vorgehensmodellen die jedoch alle eines gemeinsam hatten sie basierten auf einer Basisstruktur speziell in der Abwicklung von gro en Projekten und Gesch ftsabwicklungen Diese Basisstruktur wird
115. en externen Projektmanager wenig sinnvoll ein Projekt ohne klaren Sponsor und Auftraggeber berhaupt anzunehmen Denn dort ist mit sehr hoher Wahrscheinlichkeit zu erwarten dass das Projekt in Streitigkeiten zwischen den verschiedenen betroffenen Bereichen schnell das Zeitliche segnet Die Bedeutung des Sponsors w chst mit der Problematik und Komplexit t des Projekts Bei Projekten die gravierende nderungen f r einzelne Unternehmensbereiche oder das gesamte Unternehmen oder auch nur f r wenige Mitarbeiter zur Folge haben k nnen ist er in besonderem Ma e gefordert um das Projekt nicht bereits in einer fr hen Phase an Organizational Defenses scheitern zu lassen Dabei ist es erstaunlich wie kreativ Mitarbeiter sein k nnen wenn es darum geht nderungen zu verhindern 5 6 5Organisation des Projekts Nur in der Sondersituation bei der ein Projekt nur von einer Person geplant verwaltet und durchgef hrt wird kann auf eine explizite oder implizite Festlegung einer Aufbau und Ablauforganisation im Projekt verzichtet werden In allen anderen F llen ist es aber erforderlich sich damit rechtzeitig vor dem Start eines Projektes auseinander zusetzen Ob diese berlegungen mit einer formalen Fixierung in Form eines Projekthandbuchs enden oder eine offenere Form annehmen h ngt sowohl von der Art des Projekts als auch von vielen anderen Umgebungsbedingungen ab Die Aufgaben einer Aufbauorganisation f r ein Projekt sind e Festleg
116. er Art des Projekts abh ngig ebenso wie es die H ufigkeit solcher Zielkonflikte ist Dazu werden exemplarisch zwei wichtige Einsatzbereiche des Projektmanagements die Softwareentwicklung und der Baubereich betrachtet Bei der Softwareentwicklung treten Zielkonflikte sehr h ufig auf Urs chlich daf r ist dass es sich eben um eine Entwicklung handelt Die Projekte weichen h ufig stark von bisherigen Entwicklungsprojekten ab so dass sich sehr schwer absch tzen l sst wie viel Zeit und Geld ben tigt wird um das Ziel zu erreichen Oftmals steht zu Beginn des Projekts noch nicht einmal die genaue Form des Sachziels fest Gerade bei Softwareentwicklungsprojekten ist daher eine exakte Zieldefinition in Form eines umfangreichen Pflichtenhefts unerl sslich Sie bildet die Basis f r den Projekterfolg Wenn nun Zielkonflikte auftreten stellt sich falls das Projekt nicht abgebrochen wird die Frage an welcher Schraube gedreht werden soll Bei internen Softwareentwicklungsprojekten ist dabei ein Blick auf das Sachziel durchaus sinnvoll Wenn daran Abstriche vorgenommen werden k nnen bedeutet das den geringsten Einfluss auf Termin und Kostenziel Bei Projekten die ein marktf higes Produkt zum Ziel haben ist dies schon deutlich schwieriger Die meisten Softwarehersteller fahren hier eine Kompromissschiene Leitfaden Projektmanagement Q Office 2 Heip bei der Produkte sp ter fertig werden mit h heren Kosten entwickelt werden und
117. eren Am besten legen Sie vorab Spielregeln mit dem Team fest an die sich jeder zu halten hat 10 1 15Das Kostenziel wird berzogen Auch hier ist durch eine vern nftige Planung schon vorab viel zu vermeiden Allerdings haben nat rlich u ere Einfl sse eine direkte Auswirkung auf die Kosten zum Beispiel wenn das Projekt l nger dauert als geplant In diesem Zusammenhang ist eine Kosten berziehung eigentlich nicht zu vermeiden sie muss daher unter den gegebenen Umst nden betrachtet werden Es ist klar dass eine Budget berziehung sofort nach deren Erkennen an den Auftraggeber kommuniziert werden muss H ufig muss das Geld nochmals beantragt werden oder es m ssen intern wie extern andere Geldquellen gesucht werden Erfolgt die Information zu sp t also kurz bevor die Geldmittel ben tigt werden bleibt dann oft keine Zeit mehr zur Beschaffung Statistisch gesehen wird das Budget von fast jedem zweiten Projekt berzogen Dies liegt entweder an der zu optimistischen Planung oder an der nicht optimierten Durchf hrung 10 1 16Mangelhafte berwachung des Projektfortschritts Nicht nur eine detaillierte Planung ist f r den Projekterfolg verantwortlich sondern auch eine systematische berwachung des Projekts Hierzu ist es notwendig dass der Projektleiter die notwendige Kapazit t f r diese T tigkeiten frei hat Denn der Arbeitsaufwand w hrend des Projekts ist nicht zu untersch tzen Leitfaden Projektmanagement Q Office
118. erten Projektziel entstehen Je detaillierter und exakter das Ziel abgegrenzt und schlie lich definiert wurde desto gr er ist die Chance dass es auch wie geplant durchgef hrt wird Dar ber hinaus kann der Projektleiter durch eine saubere berwachung des Projekts sofort reagieren Stimmt die Kommunikation im Team dann k nnen diese Probleme besprochen und gel st werden Es kommt jedoch immer wieder vor dass der Auftraggeber zum Beispiel nach der ersten Testinstallation mit der Software doch nicht zufrieden ist obwohl vorher alles eindeutig besprochen und dokumentiert wurde In dieser Situation ist abzuw gen ob der Mehraufwand f r die nderung dem Kunden in Rechnung gestellt werden kann Hierbei sollte die Demotivation im Team nicht au er Acht gelassen werden Ein monatelanger Arbeitsaufwand der dann keine W rdigung findet ist f r alle Beteiligten unerfreulich Die Projektleitung steckt hier zwischen dem Auftraggeber und seinem Team Bisweilen wird durch strategische Entscheidungen der Gesch ftsf hrung ein Projekt eingestellt oder vom Ziel her ver ndert wird Auf diese Entscheidungen hat das Entwicklungsteam oft wenig Einfluss meist kommen solche Entscheidungen auch sehr unerwartet Vor allem in gr eren Unternehmen kommt dies h ufiger vor sodass unter Umst nden diese M glichkeit in der Risikoanalyse ber cksichtigt werden muss Durch vorab durchgef hrte Analysen und durch einen definierten Zielformulierungsprozess
119. erung Test Verteilung Projektmanagement Change und Konfigurationsmanagement Einf hrung einer Werkzeugumgebung Seite 116 Leitfaden Projektmanagement Q Office 2 Heip 12 7 7ITIL ITIL ist die Abk rzung von Information Technology Infrastructure Library Diese ffentliche Bibliotheken wurde in den 80er Jahren von der CCTA Central Computer and Telecommunications Agency heute OGC eine britische Regierungsbeh rde entwickelt ITIL ist ein best practice Framework welches sich herstellerunabh ngig zu einem de facto Standard entwickelt hat ITIL liefert eine Beschreibung zur Planung und Erbringung von IT Leistungen In den ber 45 ffentlichen B chern wird beschrieben welche Ma nahmen f r die verschiedenen ITIL Prozesse getroffen werden m ssen Jedoch nicht wie diese Ma nahmen durchgef hrt werden m ssen ITIL formuliert also keine verbindlichen Vorgaben ITIL ist keine ISO Norm Die entsprechende Norm zu ITIL ist ISO 20000 welche auf dem britischen Standard BS 15000 beruht ITS Ziel und Vorteile von ITIL H here Mitarbeiter und Kundenzufriedenheit Prozessabl ufe werden transparent und steuerbar Effizientere Entwicklung neuer Prozessschritte und Arbeitsabl ufe Effizienterer Informationsaustausch geringere Kommunikation Grundlage f r Qualit tssicherung und Management im IT Service Management e Standardisierte und systematisierte Arbeitsabl ufe e Minimierung von Fehlern und Ausf llen Die Implemen
120. essmodelle dr cken Regeln aus an die sich die im Prozess involvierten Personen halten m ssen und das ist sicher nicht immer einfach 12 1Eine Einf hrung in Prozessmodelle In dem bisherigen Erl uterungen wurde aufgef hrt dass das fehlen von Prozessmodellen bzw schlechte oder veraltete Prozessmodelle mit einer der Gr nde f r die Softwarekrise sind Dieses Kapitel soll eine Einf hrung in Prozessmodelle geben und andererseits aufzeigen warum Prozessmodelle so bedeutend f r eine optimale Softwareentwicklung sind Prozessmodelle werden hierzulande auch als Vorgehensmodelle bezeichnet Sie regeln oder sollen regeln den gesamten Prozess der innerhalb eines Projektes z B in der Softwareentwicklung Im wesentlichen haben Prozessmodelle eins gemeinsam Sie definieren Aktivit ten und legen Produkte Artefakte fest die Ergebnis dieser Aktivit ten sind Ferner bestimmen sie eine gewisse Reihenfolge in der diese Aktivit ten abzuarbeiten sind Im Laufe der Jahre wurden diverse Prozessmodelle publiziert besonders bekannt sind e Das Wasserfallmodell e Das Spiralmodell e Das V Modell e Der Microsoft Solutions Framework e Der Rational Unified Process e PRINCE e ITIL Meist wurden diese Modelle im Laufe der Zeit von neu auf den Markt kommenden Technologien eingeholt bzw berholt so dass sie sich nicht mehr einsatztauglich bewiesen Viele Modelle hatten auch den Nachteil dass sie nur f r eine bestimmte Gruppe von Anwe
121. ete eines Netzplans die zeitlich nicht verschoben werden k nnen ohne dass sich eine Verschiebung des Projektendtermins ergibt liegen auf dem kritischen Weg Matrix Projektorganisation Form einer Projektrahmenorganisation Mischform zwischen reiner Projektorganisation und Projektkoordination Verantwortung und Befugnisse sind zwischen Projektleiter und den beteiligten Linienfunktionen aufgeteilt Meilenstein Ereignis von besonderer Bedeutung im Projektverlauf Ein Meilenstein hat immer die Dauer 0 Tage Meilenstein Trend Analyse Instrument f r das Termin Controlling eines Projektes An regelm igen Berichtszeitpunkten wird die Terminplanung des Projektes durch die Abfrage von Meilensteinterminen graphisch neu erfasst Aus dem Kurvenverlauf l sst sich ein Trend ber die Termintreue des Projektes ableiten Mengenmethode Methode zur Bewertung des Fertigstellungsgrades von Projektaktivit ten Ein Arbeitspaket ist in eine Menge von gleichartigen Objekten mit jeweils demselben Arbeitsaufwand untergliedert z B 30 etwa gleichartige Graphiken Aus der Anzahl der fertiggestellten Objekte l sst sich der Fertigstellungsgrad sch tzen Damit wird das sog 90 Syndrom vermieden Multiprojekt Controlling Analyse des Zusammenwirkens aller Projekte um projekt bergreifende Ressourcenkonflikte Personalkapazit ten Hilfsmittel Finanzen aufzudecken und geeignete koordinierende Ma nahmen einleiten zu k nnen Multiprojektmanageme
122. ffice 2 Heip 5 8 2Obere Eckwerte Nachstehende oberen Eckwerte limitieren die Dimensionen eines Projektes und dienen der Transparenz und berschaubarkeit der Aktivit ten Gro e Aufgaben erfordern ggf aufwendigere Initialbetrachtungen und ein Schneiden in Teilprojekte die ihrerseits den genannten oberen Projekt Eckwerten gen gen und damit zur Kostentransparenz beitragen Definieren Sie hier die oberen Eckwerte und Abbildung 8 Obere Projekt Eckwerte Seite 49 Leitfaden Projektmanagement To Office 2 Heip Aufgaben eines Projektleiters Seite 50 6Der Projektleiter Ein Projektleiter kann sowohl aus dem Management Stab oder aus den Fachabteilungen Linie rekrutiert werden Die Aufgaben eines Projektleiters rechen ber ein sehr weit gef chertes Aufgabengebiet und beinhalten u a die Aufgaben Leitung einer klar definierten zeitlich begrenzten Aufgabe Korrekte Einhaltung aller vorgegebenen Projektziele Planung und berwachung des Projektes nach Umfang Inhalt und Mitteln Koordination aller Funktionen und Bereiche soweit am Projekt beteiligt Herbeif hren schneller fachlichen Entscheidungen umgehende Einleitung von Ma nahmen im Problemfall Sicherstellung der Beachtung der Methoden und Richtlinien Sicherung der Qualit t des Produktes Motivation der Projektmitarbeiter Sicherstellung der Information zum Management zu den beteiligten Bereichen zum Projektteam e Sicherstellen notwendiger Beteilig
123. g B rokratie Prozesse Komponenten Techniken definiert generisch nicht nur in der IT sondern auch z B bei Bau oder Organisationsprojekten angewendet werden kann Leitfaden Projektmanagement Q Office 2 Heip 12 7 8 1Geschichte PRINCE PRojects IN Controlled Environments ist eine Projektmanagement Methode f r Organisation Management und die Steuerung von Projekten Sie wurde urspr nglich 1989 von der britischen Central Computer and Telecommunications Agency CCTA als Regierungsstandard f r Projektmanagement im Bereich der Informationstechnik IT entwickelt wurde jedoch bald regelm ig auch au erhalb von reinen IT Umgebungen angewendet PRINCE2 wurde 1996 als allgemeine Projektmanagement Methode ver ffentlicht PRINCE2 ist zunehmend popul rer geworden und ist nun der de facto Standard f r Projektmanagement in Gro britannien Seine Anwendung ist mittlerweile in mehr als 50 anderen L ndern verbreitet Die aktuelle Version wurde 2005 vom Office of Government Commerce OGC ver ffentlicht das mittlerweile die CCTA abgel st hat 12 7 8 2Prozesse PRINCE2 ist ein prozessorientierter Projektmanagement Ansatz Es werden acht Prozesse definiert Lenken eines Projekts Directing a project DP Planung eines Projekts Planning PL Vorbereiten eines Projekts Starting up a project SU Initiieren eines Projekts Initiating a project IP Steuern einer Phase Controlling a stage CS Managen der Produktlieferung Managin
124. g product delivery MP Managen der Phasen berg nge Managing stage boundaries SB Abschlie en eines Projekts Closing a project CP Ein PRINCE2 Projekt muss aus mindestens zwei Phasen bestehen typischerweise hat es jedoch vier Vorbereiten eines Projekts Starting a project Initiieren eines Projekts Initiating a project Implementierung Implementation Abschlie en eines Projekts Closing a project Die Implementierungsphase kann in mehrere Stufen unterteilt sein wenn es sich wie oftmals der Fall als sinnvoll herausstellt Die Prozesse Vorbereiten eines Projekts Initiieren eines Projekts und Abschlie en eines Projekts beziehen sich jeweils genau auf die entsprechende Projektphase Zur Implementierungsphase geh ren die drei Prozesse Steuern einer Phase Managen der Produktlieferung und Managen der Phasen berg nge Der Prozess Lenken eines Projekts bezieht sich auf die gesamte Projektdauer w hrend Planen sich auf alle Phasen au er der letzten Abschlie en eines Projekts bezieht 12 7 8 3Vorbereiten eines Projekts Das Ziel dieses Prozesses ist es das Projekt richtig aufzusetzen Es ist ein Prozess vor Beginn des Projekts der feststellt ob das Projekt Iohnenswert und durchf hrbar machbar ist bevor die Ressourcen festgelegt werden Seine Haupt Eingangsgr e ist das Projektmandat Der Prozess beinhaltet die Identifizierung der leitenden Entscheider die zur Besetzung des Lenkungsausschusses project board ben tigt we
125. ge k nnen beginnen obwohl andere noch nicht beendet wurden Die Zeit die dadurch eingespart werden kann ist oft betr chtlich und f hrt nicht zu Risiken wie zum Beispiel einen Testlauf ausfallen zu lassen 10 1 4Umfangreiche nderungsw nsche 1 Das Projektteam beklagt sich zunehmend ber nderungsw nsche von Seiten des Kunden die nicht mehr in time und in Budget ausgef hrt werden k nnen An dieser Stelle k nnte man nat rlich diskutieren ob hier ein Planungsfehler vorlag oder ob der Kunde seine Anforderungen grundlegend ge ndert hat Das Ergebnis ist jedoch dasselbe das Projekt befindet sich in einem u erst kritischen Stadium und es existiert ein dringender Handlungsbedarf 2 Der Kunde bringt regelm ig nderungsw nsche heran deren Inhalt nicht den vorangegangenen Projektbesprechungen und Vereinbarungen entspricht 3 nderungsantr ge Change Requests kommen nicht mehr in der vereinbarten Form und auch nicht mehr ber den Tisch des Projektleiters Vorsicht hier wackelt bereits der Kopf des Projektleiters Seite 79 Leitfaden Projektmanagement To Office 2 Heip Interne Warnsignale sind ebenfalls von gro er Bedeutung Seite 80 10 1 5Unbezahlte Rechnungen Werden Rechnungen nach der Ableistung eines Meilensteins auch nach Zahlungs Erinnerung nicht mehr bezahlt so ist es h chste Zeit sich Gedanken zu machen Es k nnen jetzt nur noch zwei Gr nde zutreffen e der Kunde ist Zahl
126. gegen ber den ersten Ank ndigungen funktional eingeschr nkt sind Funktionen werden auf sp tere Versionen verschoben indem ein Teil Sachziel definiert wird Das Projekt wird hier letztlich aufgeteilt gesplittet Bei Produkten die individuell f r einen Kunden entwickelt werden gibt es in der Regel wenig Alternativen Das Sachziel ist blicherweise festgeschrieben ebenso wie das Terminziel Das bedeutet dass nur durch h heren Aufwand beispielsweise in Form von berstunden und damit h here Kosten reagiert werden kann Nimmt man im Gegensatz dazu den Baubereich dann bietet sich hier ein ganz anderes Bild Bei Bauprojekten h ngt es sehr stark von der Struktur des Projekts ab wie gro das Risiko eklatanter Planabweichungen ist Nach der Planung lassen sich die Kosten relativ genau sch tzen da die Erfahrungswerte in Form umfangreicher Aufstellungen allgemein verf gbar sind Eine genaue Kosten und Aufwandssch tzung wird dadurch erleichtert Schwieriger wird das bei neuartigen oder technisch sehr anspruchsvollen Projekten wie dem Kanaltunnel und bei Renovierungen Hier treten wesentlich mehr Sondereinfl sse auf Je nach Struktur des Projekts gibt es auch hier wieder die oben beschriebenen Handlungsalternativen Inwieweit das Sachziel ver ndert werden kann ist auch hier wieder eine Frage des jeweiligen Projekts Bei privaten Bauprojekten wird hier oftmals so entschieden dass das Sachziel reduziert wird indem an der Ausstattung
127. gen erst nach 80 der eigentlichen Fertigstellungszeit bemerken k nnen Sie nur noch zahlen Projektarbeiten werden nicht besser wenn von oben angeordnet wird wie viel Zeit ben tigt werden darf Dadurch werden Probleme nicht bereinigt da die F hrungskr fte nie alle Details kennen und kennen sollen Wichtige Arbeiten f r das Projekt werden dann einfach nicht gemacht 5 7 6Organisation ist alles In der Ressourcenplanung liegt immanent die Gefahr dass die die ohnehin schon viel Arbeit haben noch mehr bekommen Das Problem liegt darin dass viele Entscheidungen vom Projektmanager selbst getroffen werden m ssen Aber auch Entscheidungen die das Projekt als Ganzes betreffen m ssen von Auftraggebern oder Lenkungsaussch ssen getroffen werden die blicherweise mit Personen besetzt sind die zwar ber die Kompetenz f r diesen Entscheidungsbereich verf gen aber mit vielen anderen Fragen belastet sind Abhilfe kann hier nur eine klare Aufteilung von Zust ndigkeiten schaffen die allerdings auch Vertrauen erfordert Delegation kann aber ohne Vertrauen nicht funktionieren Damit Projekte effizient verwaltet werden k nnen muss dieses Vertrauen vorhanden sein Dann k nnen Projekte so organisiert und Aufgaben so verteilt werden dass nur die wirklich kritischen Fragen bei den stark belasteten Entscheidungstr gern anlangen Damit das funktioniert ist neben klaren Regeln auch ein klares Berichtswesen innerhalb eines Projekts erforder
128. gende O nicht vorhanden 10 hoch Risikofaktor Spalte 2 Spalte 3 Tabelle 7 Risikofaktoren ein Beispiel Die Tabelle zeigt aber auch dass es oft sehr schwierig ist Eintrittswahrscheinlichkeiten genau genug zu sch tzen Checklisten wie schon besprochen k nnen helfen diese Wahrscheinlichkeit zu sch tzen Eine vollst ndige Risikoanalyse w rde Prototypen Leistungsmessungen und Simulationen proof of concept erfordern die aber teuer und zeitaufwendig sind Seite 147 Leitfaden Projektmanagement To Office 2 Heip 15 1 5Risikomanagement Planung Nachdem die Hauptrisikoelemente und ihre relativen Priorit ten bestimmt sind m ssen Risikokontroll Aktivit ten etabliert werden um Risikoelemente unter Kontrolle zu bringen Der erste Schritt besteht darin Risikomanagement Pl ne zu entwickeln welche die entsprechende notwendigen Aktivit ten festlegen siehe auch die Top 10 Risikoliste die entsprechende Techni9ken f r die wichtigsten Risikoelemente angibt 15 1 6Risiko berwindung Nach Abschluss der Risikomanagement Planung werden die dort festgelegten Aktivit ten ausgef hrt Beispielsweise wird ein Prototyp erstellt oder es werden Anforderungen gelockert 15 1 7Risiko berwachung Ihr Risikoplan ist erstellt Nun ist es an Ihnen das Sie diesen Plan entsprechend Kommunizieren und sich auch entsprechend dem Plan verhalten Unternehmen Sie alles was Sie bereits proaktiv tun k nnen berwachen Sie die Ausl
129. ger sind normalerweise nicht Teil des Teams das sie leiten Teams haben wie alle Organisationsstrukturen St rken und Schw chen auf die wir an dieser Stelle nicht explizit eingehen wollen Trotzdem wollen wir hier einige Punkte auff hren die ein Projektleiter bei der Teamf hrung beachten sollte um sein Team erfolgreich zu f hren Auf was sollte ein Projektleiter achten Das Team auf ein gemeinsames Ziel ausrichten Dem Team zu erfolg verhelfen Das Elitegef hl st rken Qualit t zum Kult machen Vielfalt ins Team bringen Strategische Richtlinien vorgeben aber keine taktischen Und never change a winning team Was sollte ein Projektleiter niemals tun Kontrolle aus ben statt zu Vertrauen und Autonomie walten zu lassen B rokratie einf hren oder f rdern R umliche Trennung statt r umlicher N he f rdern Gleichzeitige Mitarbeit in mehreren Teams statt nur in einem Scheintermine vereinbaren statt zu Vertrauen Teams brauchen ein gemeinsames Ziel damit sie motiviert arbeiten Firmenziele sind aber viel zu abstrakt Daher ist es wichtig konkrete Ziele des Projektes vorzugeben die vom Team akzeptiert werden Teams ben tigen insbesondere in der Anfangsphase gemeinsame Erfolge und Anerkennung Sie m ssen best tigt werden das sie auf dem richtigen Weg sind Als Manager sollte man daher die zu erledigende Arbeit so aufteilen das gen gend Erfolgserlebnisse m glich sind Um mit sich selbst zufrieden zu sein
130. gespart wird oder Ma nahmen aus dem Projekt herausgenommen werden und beispielsweise der Dachausbau erst sp ter erfolgt Bei ffentlichen Gro projekten wird dagegen meistens zugunsten des Sachziels und zu Lasten vor allem des Kostenziels entschieden Allerdings sind die Spielr ume hier bei kleineren Projekten mittlerweile auch deutlich eingeschr nkt worden Wichtig f r das richtige Handeln bei Zielkonflikten sind vor allem zwei Aspekte e Der Projektmanager muss sich im klaren ber die Ziele sein Nur genau definierte Ziele k nnen verfehlt und ver ndert werden Nur bei klar definierten Zielen k nnen Abweichungen erkannt und darauf reagiert werden e Der Projektmanager muss alle Handlungsalternativen einbeziehen Dazu geh rt explizit auch das Sterbenlassen eines Projekts Ohne klar definierte Ziele und umfassende Pflichtenhefte zur Bestimmung des Sachziels ist kein sinnvolles Projektmanagement m glich Seite 25 Leitfaden Projektmanagement To Office 2 Heip Seite 26 5 6Die Struktur eines Projekts Projekte werden in Phasen gegliedert Doch sind diese Phasen bei der Projektplanung wirklich zwingend Kaum ein Lehrbuch zum Projektmanagement kommt ohne Phasenkonzepte aus Es gibt mindestens so viele Phasenkonzepte f r Projekte wie Lehrb cher zum Projektmanagement Offensichtlich h lt es jeder Autor f r n tig seine eigene Variante zu definieren Die Frage ob Phasenkonzepte erforderlich sind ist zu bejahen Pha
131. h Ihr Vorgehen bei Abweichungen vom Plan genehmigen 10 1 17Mangelnde Ausbildung Unsere Mitarbeiter sind unser wichtigstes Potential Kapital derartige vollmundige Neue Marketingaussagen liest man heutzutage in nahezu jeder Firmenbrosch re Doch Technologien verhalten sich die meisten IT Firmen wirklich so Damit ein Mitarbeiter wirklich ein erfordern solches Potential Kapital darstellen kann muss er optimal ausgebildet sein Ausbildungs st ndig weitergebildet trainiert und auch motiviert werden Damit sind nat rlich Programme neben dem Produktionsausfall auch noch zus tzliche Ausbildungskosten verbunden vor denen sich viele Unternehmen scheuen Kein G rtner k me auf die Idee seine Blumen nicht mehr zu gie en um Wasserkosten zu sparen doch in der IT Branche herrschen offensichtlich andere Gesetze Warum ist dem so Nun eine Begr ndung mag sicherlich die extrem kurze Verweildauer von Mitarbeitern in IT Unternehmen sein die durchschnittlich zwischen zwei und drei Jahren liegt Ein weiterer Grund ist die Ressourcenknappheit der meisten Unternehmen selbst wenn man bereit ist die Ausbildungskosten zu bezahlen so k nnen sich viele Unternehmen nicht leisten auf den Mitarbeiter eine Woche oder gar l nger In Projekten zu verzichten Die Folgen dieses Ausbildungsr ckstandes sind fatal Ein Cobol Programmierer der von heute auf morgen C Code erstellen soll wird sicherlich anfangs nicht besonders viel zustande bringen
132. handelt werden Allerdings wird im V Modell 97 die Kommunikation ber Tabellen gesteuert was die Lesbarkeit des Modells erschwert Im Rational Unified Process hingegen existieren Workflows die mittels den zuvor erw hnten Aktivit tsdiagrammen der Unified Modelling Language beschrieben werden Diese sind erheblich leichter nachzuvollziehen Ferner wird im RUP das Management innerhalb des Software Engineering Prozesses ausf hrlicher betrachtet Somit stellt der RUP Querverbindungen zwischen den folgenden Inhalten des Softwareengineering dar Gesch ftsprozessmodellierung Anforderungsmanagement Analyse und Design Implementierung Test und Qualit tssicherung Verteilung Projektmanagement Change und Konfigurationsmanagement Workflow Einf hrung einer Werkzeugumgebung 12 5Einsatzfelder der Prozessmodelle Prozessmodelle werden nicht f r jedes Software Entwicklungsvorhaben ben tigt Soll z B ein einfacher Makro f r Microsoft WinWord erstellt werden so ist hier sicherlich keine Notwendigkeit vorhanden dabei nach einem Prozessmodell vorzugehen Auch die Entwicklung einer C Applikation eines 2 3 Personen Teams die einen berschaubaren Zeitraum von drei bis vier Wochen umfasst verlangt noch nicht nach einem Prozessmodell Hingegen bei der Erstellung umfangreicher Applikationen sollte man schon ein Prozessmodell hinzuziehen Leitfaden Projektmanagement Q Office 2 Heip Allgemein gibt es die folgenden Kenngr en wann ein Pr
133. he Alternative realisiert werden soll usw e Das Review Board ist in diesen F llen das f r die Entscheidung verantwortliche Gremium e Vor Eintritt in die Vorbereitung der Entscheidung sind vom Auftraggeber bzw Review Board die Zielsetzungen der Entscheidung Alternativenbewertung Wirtschaftlichkeitsuntersuchung USW vorzugeben e Es ist die Aufgabe des Projektleiters notwendige Angaben und Dokumente f r den Entscheidungsproze aus Projektsicht vorzubereiten e Die Bereitstellung der notwendigen Unterlagen und Angaben z B Zahlen material ist Aufgabe der Leitung der jeweils verantwortlichen Bereiche oder des Review Boards 19 1 9Regeln zu Projektreviews Reviews sind Einrichtungen deren Aufgabe es ist durch kritische Durchsicht und Pr fung von Ergebnissen Problemsituationen und Fehler in den Ergebnissen oder Probleme im Projekt aufzudecken Im Review wird nicht nach dem Schuldigen gesucht sondern gemeinsam Mittel und Wege erarbeitet wie Fehler behoben und Probleme bereinigt werden k nnen Es werden zwei Reviewtypen unterschieden e Status Sitzungen e Qualit tsreviews Seite 179 Leitfaden Projektmanagement Q Office 2 Heip Seite 180 Status Sitzungen dienen der Information und Kommunikation mit dem Management Sie werden zu geplanten Terminen Phasenende bzw bei Problemsituationen einberufen Verantwortlich f r ihre Einberufung und ihre Vorbereitung ist der Projektleiter Qualit tsreviews sind
134. hen sitzen die mit mannigfaltigen Talenten und F higkeiten ausgestattet sind Oft liegen Probleme daran dass sie nicht ihren F higkeiten entsprechend eingesetzt werden 6 1 3Ich bin Projektleiter was nun Was k nnen Sie tun wenn Ihnen die Projektleitung aufgedr ngt wurde wie es in der Praxis leider sehr oft vorkommt Hierzu m chte ich einen kleinen Leitfaden f r die ersten Schritte geben e Teilen Sie das Projektziel in Einzelaufgaben auf Grobgliederung e Diese Vorg nge m ssen dann mit einer Dauer und den ben tigten Ressourcen belegt werden e Definieren Sie Meilensteine Teilziele e Anhand der oben angegebenen Grobgliederung erstellen Sie den Projektplan e Sprechen Sie diesen mit ihrem Vorgesetzten durch um m gliche Probleme fr h zu erkennen e Veranstalten Sie ein Kick Off Meeting um die Teamkommunikation zu f rdern und um das Ziel bekannt zu geben Dieses Meeting ist Ihre Plattform um sich gut zu pr sentieren e Achten Sie darauf dass jeder Projektbeteiligte Zugriff auf den Projektplan hat und dieser auch permanent gepflegt wird e F hren Sie regelm ig Projektmeetings durch um die Kommunikation sicherzustellen informieren Sie Ihr Team und Ihren Vorgesetzen ber nderungen e Vor Abschluss muss das Ergebnis nochmals berpr ft werden Pr f und Testphase Dieser Leitfaden ersetzt kein Projektmanagement Training Wenn Sie mit der Aufgabe der Projektleitung beauftragt wurden m ssen S
135. ice 2 Heip Vier unterschiedliche Bereiche Seite 106 12 7 3 1Submodelle im V Modell Das V Modell gliedert sich in vier Bereiche die eng miteinander verkn pft sind System Softwareerstellung SE Projektmanagement PM Qualit tssicherung QS Konfigurationsmanagement KM Diese Bereiche werden auch als Submodelle genannt und sind im wesentlichen Bestandteil des V Modells Voraussetzungen schaffen und Softwareentwicklungs umgebung SEU bereitstellen Projekt planen und kontrollieren a Produkt Produktstruktur Anforderungen Snacken planen vorgeben Produkte Produkte pr fen Rechte verwalten Abbildung 19 Das Zusammenspiel der Submodelle im V Modell Die vorstehende Abbildung zeigt das Zusammenspiel dieser Modelle So liefern gewisse Aktivit ten eines Submodells als Ergebnis den Input f r ein anderes Submodell Um die Navigation durch die 4 Submodelle zu erleichtern wurden im V Modell Tabellen integriert anhand derer erkennbar wird welche Aktivit t welchen Input von welchem Submodell erh lt Im folgenden soll kurz auf die einzelnen Submodelle eingegangen werden Leitfaden Projektmanagement Q Office 2 Heip 12 7 3 2Das Submodell SE W hrend die drei Submodelle Qualit tssicherung QS Projektmanagement PM Drei und Konfigurationsmanagement KM die begleitenden Aktivit ten in einem verschiedene Entwicklungsprojekt beschreiben ist es das Submodell System Ebenen Softwareerstellung SE in welchem die
136. ich Projekteignung Einsatz Planung der Mitarbeiter fachliche steuerungsspezifische Weisungsbefugnis gegen ber seinem Team eigene fachliche steuerungsspezifische Entscheidungen Vergabe von Priorit ten steuerungsspezifisch Gestaltung von Vorgehensweisen Im Berichtsweg nach oben Instanzen berspringen k nnen Zugriff zu allen aus Projektsicht notwendigen Informationen Leitfaden Projektmanagement Q Office 2 Heip 8 2 5Projektteam Das Projektteam besteht aus Anwendervertreter Mitarbeiter Unternehmensintern extern z B Gesch ftsprozess Modellierer SW Designer Datenbank Designer Netzwerk Spezialist Anwendungsentwickler Qualit tssicherer Sonstige Externe Die Zusammensetzung ist abh ngig vom jeweiligen Arbeitsabschnitt Phase des Projektes Mitglieder des Projektteams sind ganz oder teilweise von ihrer normalen Funktion freizustellen Die Abstimmung wann und wie lange eine Mitarbeit im Projekt erforderlich ist muss der Projektleiter mit dem jeweiligen Personalvorgesetzten schriftlich abstimmen Die personelle Verantwortung verbleibt bei den abgebenden F hrungskr ften mit Personalverantwortung Die Beteiligungsrechte der Betriebsr te in personellen Angelegenheiten sind zu beachten Die Zusammenarbeit mit dem Anwender muss in allen Schritten des Projektes sichergestellt sein damit alle fachlichen Faktoren im Projekt ber cksichtigt werden Dies wird durch einen oder mehrere Anwendervertreter im Projektt
137. ichtlich dass die Genauigkeit der Ergebnisse proportional zu dem verwendeten Aufwand und Techniken steht Der nachstehende Absatz beschreibt einige einfache aber sehr effiziente Methoden Um Risiken zu quantifizieren Legen Sie Ihre Toleranzbereiche fest Weisen Sie jedem Risiko eine Wahrscheinlichkeit des Auftretens zu Weisen Sie jedem Risiko eine Kostensch tzung zu Weisen Sie jedem Risiko eine Priorit t zu Legen Sie Ihre Toleranzbereiche fest Seite 143 Leitfaden Projektmanagement To Office 2 Heip Seite 144 Nehmen wir einmal an Sie Arbeiten f r ein kleineres Unternehmen dann w rden mit gro er Wahrscheinlichkeit zus tzliche Projektkosten in H he von DM 500 000 oder eine Projektverz gerung von 2 3 Monaten Ihr Unternehmen in sehr ernste Schwierigkeiten bringen Arbeiten Sie dagegen f r ein gr eres Unternehmen so sind die eben genannten Abweichungszahlen wom glich noch in einem Toleranzbereich Schreiben Sie sich diejenigen Grenzzahlen auf die Sie in ihrem Unternehmen Projekt noch tolerieren k nnen Diese Zahlen sind keine Sch tzzahlen f r das zu bewertende Projekt sondern absolute Grenzzahlen die generell f r Projekte in Ihrem Unternehmen oder f r Projekte gelten Weisen Sie jedem Risiko eine Wahrscheinlichkeit des Auftretens zu Legen sie f r jedes Risiko das Sie betrachten die Wahrscheinlichkeit des Auftretens fest Wenn sie keine statistischen Methoden verwenden und oder auf Erfahrungszahlen zur ckgreifen
138. ie sich mit dem Thema sehr intensiv auseinandersetzen Leitfaden Projektmanagement Q Office 2 Heip 7Projekt Vorbereitungsphasen 7 1Grunds tzliches Oft steht der Projektleiter zu Beginn von Projekten vor der Gratwanderung von Vernunft und Effizienz Er kann in diesem Fall aber nur dann wissen um was es geht und eine richtige Entscheidung treffen wenn er mit dem Projekt und den im Projekt verwendeten Techniken vertraut ist Zwangsl ufig muss er sich daher zus tzlich zu seinen origin ren Projektmanagement Aufgaben mit der Technik sowie den bereits eingesetzten und den neuen Verfahren auseinandersetzen Da ein Gro teil der Projektmanager jedoch nicht ber alle diese Kenntnisse verf gt oder verf gen kann w hre ein umfassendes Training notwendig das die Unternehmen jedoch weder zeitlich noch finanziell einplanen und dessen Nutzen sie wegen der scheinbaren hohen Kosten in Frage stellen Wichtig im Lernprozess ist deshalb vor allen die M glichkeit ungestraft Fehler machen zu k nnen Idealerweise bedeutet das ein Teilprojekt dessen Scheitern keine negativen strategischen Auswirkungen hat auf Basis der neuen Technologie zu starten und deren Erfolg nach Abschluss zu bewerten Solche Projekt machen aber nur dann Sinn wenn alle Beteiligten auch am Folgeprojekt teilnehmen da sonst die Erfahrung wieder verloren geht und erneut gesammelt werden muss Selbst mit der n tigen Kenntnis ber alle verf gbaren Technologien und Verfahren
139. ieser Bereich ist eine Dom ne von Microsoft Project Die Terminplanung und Ressourcenplanung k nnen mit Hilfe des Werkzeugs differenziert erfolgen Auch diese Phase geh rt zum Kerneinsatzbereich von Microsoft Project Dazu geh ren als wichtige Funktionen Alternativensuche Projektcontrolling Plan nderungen und das Reporting die alle mit Werkzeugunterst tzung erfolgen k nnen Auch das ist ein Bereich in dem Microsoft Project sinnvoll eingesetzt werden kann Hier erfolgt eine Analyse des Projekts mit Hilfe der gesammelten Informationen H ufig wird Microsoft Proiect hier durch andere Werkzeuge wie beispielsweise Microsoft Excel erg nzt Initialisierung Microsoft Project liefert die Informationen dar ber wie man es machen soll oder auch nicht aus bisherigen Projekten Tabelle 3Einsatzbereich von MS Project in Projekten Microsoft Project kann in jeder Phase des Projekts eingesetzt werden Besonders dann wenn regelm ig Projekte mit Microsoft Project geplant und unter Leitfaden Projektmanagement Q Office 2 Heip Verwendung von Microsoft Project durchgef hrt werden finden sich dort eine F lle von wertvollen Informationen f r jedes neue Projekt Die Projekte werden dokumentiert das Lernen ber Projekte erfolgt mit Hilfe von Microsoft Project Das ist eine der wichtigsten Funktionen von Projektmanagementsoftware wie Microsoft Project Da die Informationen ber das Projekt konsequent gesammelt werden sind auch
140. in Werkzeug f r die Praxis zu sein Es hilft mit bersichtlichen Checklisten das Tagesgesch ft unter Einsatz minimalster Ressourcen zu bew ltigen Als Praxishilfsmittel befinden sich alle Grafiken und Tabellen auf der dem Buch beigelegten CD ROM Der Autor Seite 210
141. in die Konzeptphase zur ckgegangen werden wenn nderungen an den Zielen erforderlich sind o Innerhalb eines Projekts k nnen keineswegs alle Teile bereits zu Beginn differenziert geplant werden So kann die Feingliederung der technischen Entwicklungsphase erst nach der technischen Definitionsphase erfolgen Die Fertigungsphase kann erst abschlie end geplant werden wenn die Ergebnisse der Entwicklung vorliegen Ein Projekt wird also fortw hrend weiter differenziert Projektmanagement ist kein Prozess bei dem zu Beginn das gesamte Projekt einmal geplant und dann schematisch abgearbeitet wird Typisch ist vielmehr ein Prozess bei dem zun chst eine Grobstruktur f r die Phasenmodelle eine gute Basis bilden entwickelt wird Im weiteren Verlauf werden die verschiedenen Phasen dann immer weiter differenziert wobei teilweise eine Planung erst erfolgt wenn andere Phasen bereits abgeschlossen oder in der berwachung sind Die Frage der anschlie end nachgegangen wird ist die in welchen dieser Phasen sich z B MS Project einsetzen l sst und welche Funktionen des Produkts genutzt werden k nnen 5 6 2Einsatzbereiche von Microsoft Projekt in den Phasen Bei der Frage nach dem sinnvollen Einsatz von Microsoft Project innerhalb eines Projekts wird aus Sicht des Projektmanagers vorgegangen da Microsoft Project ja das Handwerkszeug des Projektmanagers ist Die wichtigsten Schritte sind aus nachfolgender aufgabenorientiert strukturierter Tab
142. ind dann in den meisten F llen mehr als ern chternd Der Umgang mit der Software stellt sich als komplex dar Oftmals scheitert der erste Versucht ein Projekt mit einer solchen software zu verwalten Gr nde daf r sind unter anderen Die Leistungsf higkeit der Software oder besser die Automatisierung von Teilen des Projektmanagements durch die Software wird bersch tzt Der Eingabe und Pflegeaufwand den die Abbildung eines realen Projekts mit einer Projektplanungssoftware erfordert wird untersch tzt Projektplanungssoftware wird oftmals zu sp t im Projekt eingef hrt Sie begleitet das Projekt nicht von Beginn an sondern wird in vielen F llen erst genutzt wenn sich zeigt dass das Projekt sehr komplex ist Die Anforderungen der Software an eine klar strukturierte Abbildung des Projektes zeigen Fehler im bisherigen Vorgehen der Projektplanung auf die ohne externe Hilfe nicht berwunden werden k nnen Es gelingt oftmals schlicht nicht eine korrekte Struktur des Projekts abzubilden eine Struktur die bei einer Projektplanung im Kopf in dieser Klarheit nat rlich nicht erforderlich ist Die Funktionalit t der Projektplanungssoftware ist nicht Trivial und fordert eine genaue Kenntnis der Software Trainingsma nahmen werden vielfach nicht konsequent und zu sp t durchgef hrt ein Coaching als projektbegleitende Ma nahmen entf llt oftmals v llig Das erste Projekt dass mit einer Projektplanungssoftware durchgef hrt werden
143. iner Projektrahmenorganisation F r die Dauer eines Projektes wird die bestehende Linienorganisation um die Stabsfunktion eines Projektkoordinators erweitert Sie besitzt keinerlei Entscheidungs und Weisungsbefugnis gegen ber den Linienfunktionen Projektlebenszyklus Genereller Ablauf eines Projektes aus Sicht des Projektmanagements Er besteht aus folgenden Abschnitten Projektstart Projektplanung Projektsteuerung Projektabschluss Projektleiter Verantwortlicher f r die Erreichung der im Projektauftrag fixierten Projektziele Er ist erster Ansprechpartner des Auftraggebers Aufgaben Befugnisse und Verantwortung des Projektleiters sollten unternehmensweit festgelegt sein Projektmanagement Projektmanagement ist eine F hrungskonzeption die dazu dient Projekte zielorientiert und effizient abzuwickeln Dazu geh ren organisatorische methodische und zwischenmenschliche Aspekte Projektmanagementhandbuch Wird h ufig die Dokumentation grundlegender Festlegungen f r die einheitliche Anwendung von Projektmanagement in einem Unternehmen genannt Projektmanagementsoftware Hilft dem Projektleiter bei der Anwendung von Planungs und Controlling Methoden ersetzt jedoch nicht den gesunden Menschenverstand Leitfaden Projektmanagement Q Office 2 Heip Projektmitarbeiter Alle an einem Projekt beteiligten Personen auch wenn sie nicht zum Projektteam geh ren Projektorganisation Die Projektorganisation besteht prim r aus dem
144. innerhalb des Anwendungs Entwicklungsprozesses Abbildung 34 Das Vorgehensmodell im Anwendungsentwicklungs Prozess 17 3 1Vorgehensmodelle Vorgehens Um den Anwendungsentwicklungsprozess im Griff zu behalten verwendet man modelle blicherweise ein Vorgehensmodell das diesen Prozess in Phasen Teilschritte zerlegt deshalb spricht man auch von Phasenmodell oder Phasenkonzept Das Vorgehensmodell beschreibt f r jede Phase die notwendigen Aktivit ten und die dabei zu erzeugenden Ergebnistypen Hier wird davon ausgegangen dass eine Gesch ftsprozessanalyse Gesch ftsprozessmodellierung bereits stattgefunden hat Die Ergebnisse liegen zur Projektinitialisierung vor Beschreibung siehe Leitfaden Gesch ftsprozessmodellierung Seite 162 Leitfaden Projektmanagement Q Office 2 Heip Dem Vorgehensmodell liegen vier Grundgedanken zugrunde die als kombiniert zu Grundgedanken verwendende Komponenten betrachtet werden sollen Es sind die Vorstellungen dass es zweckm ig ist e vom Groben zum Detail vorzugehen und nicht umgekehrt e das Prinzip des Denkens in Varianten zu beachten d h sich grunds tzlich nicht mit einer Variante i d R der erstbesten zufrieden zugeben sondern nach Alternativen zu fragen e den Prozess der Systementwicklung und realisierung nach zeitlichen Gesichtspunkten zu gliedern Phasenkonzept e bei der L sung von Problemen gleichg ltig welcher Art und in welcher Phase sie auftreten eine Arbeitslogik al
145. ion des Zeitaufwandes zur Erstellung des Programmcodes Sie ben tigt als Grundlage ein fachliches Feinkonzept und kommt deshalb in der entsprechenden Phase bei IS Projekten zum Einsatz Das Projekt wird hierbei aus Sicht des Anwenders betrachtet Technische Reali sierungsaspekte Online oder Batch System Programmiersprache Architekturen werden bei der Bewertung nicht ber cksichtigt Dadurch dass bei der Anwendung der Methode das Projekt anwendungsorientiert betrachtet wird muss die Function Point Bewertung gemeinsam mit dem Anwender durchgef hrt werden Als Hilfsmittel zur Arbeit mit der Function Point Methode kann die Literatur heran gezogen werden Da bei den Auftraggebern k nftig vorwiegend nach objektorientierter Vorgehensweisen gearbeitet wird ist die Aufwandssch tzung nach der Function Point Methode nicht mehr sinnvoll anwendbar In der Literatur sind erste Ans tze f r neue Sch tzverfahren f r die OO Vorgehensweise erkennbar jedoch noch nicht ausreichend erprobt und verifiziert siehe Literatur SNEED Leitfaden Projektmanagement Q Office 2 Heip 17 5Werkzeuge Da Anwendungsentwicklung als komplexer Prozess im Laufe der Projektarbeit viele miteinander gekoppelte Ergebnistypen erzeugt ist der Einsatz von geeigneten Werkzeugen hilfreich und empfehlenswert Diese Werkzeuge werden Computer Aided Software Engineering Werkzeuge kurz CASE Tools genannt Auch wenn die Euphorie und die hochgesteckten Erwar
146. ion sowie Beginn und Zeitdauer der Abordnung werden vor Beginn des Projektes in einem Gespr ch zwischen den abgebenden Bereichen und dem Auftraggeber verbindlich festgeschrieben Der Projektstart erfolgt in einer konstituierenden Sitzung an welcher der Auftraggeber die Leiter der beteiligten Bereiche der Projektleiter und sein Projektteam sowie falls erforderlich ein Vertreter des Betriebsrates teilnehmen Bei dieser Sitzung werden vom Auftraggeber Inhalt und Zielsetzung des Projektes erl utert Gleichzeitig werden Projektleiter und Projektteam soweit bereits bekannt sowie deren Aufgabe den Teilnehmern vorgestellt 19 1 2Regeln zur inneren Organisation des Projektes Phasenmodell o Seite 172 Allen Projekten muss ein Vorgehensmodell zugrunde liegen Das Vorgehensmodell legt verbindlich die Aktivit ten und Ergebnistypen der Projektdurchf hrung fest Leitfaden Projektmanagement Q Office 2 Heip e Inden Projekten hat grunds tzlich eine Analyse der Realisierungsm glichkeiten nach dem dargestellten Schema zu erfolgen o Pr fung des Einsatzes von Standardsoftware oder IIV durchf hren o Pr fung vorhandener Anwendungen e nderungsmanagement e nderungs bzw Erweiterungsw nsche der Fachbereiche oder anderer Unternehmensbereiche sind im Verlauf der Phasen Projektinitialisierung bis Fachliches Feinkonzept ohne Einschr nkungen erlaubt e Nach Ende der Phase Fachliches Feinkonzept sind nderungen und Erw
147. it denen man Risiken vermeidet oder berwindet Risikoelement Risikomanagement Techniken 1 Personelle Defizite e Hochtalentierte Mitarbeiter einstellen e Teams zusammenstellen 2 Unrealistische Termin und e Detaillierte Kosten und Zeitsch tzung Kostenvorgaben mit mehreren Methoden Produkt an Kostenvorgaben orientieren Inkrementelle Entwicklung Wiederverwendung von Software Anforderungen streichen Benutzerbeteiligung Prototypen Fr hzeitiges Benutzerhandbuch Prototypen Aufgabenanalyse Benutzerbeteiligung Anforderungen streichen Prototypen Kosten Nutzenanalyse Entwicklung an den Kosten orientieren Hohe nderungsschwelle Inkrementelle Entwicklung nderungen auf sp tere Erweiterungen verschieben Leistungstest Inspektionen Kompatibilit tsanalyse Prototypen Fr hzeitige berpr fung Vertr ge auf Erfolgsbasis Simulation Leistungstest Modellierung Prototypen Entwicklung von falschen Funktionen und Eigenschaften Entwicklung der falschen Anwender Benutzerschnittstelle Vergolden der Funktionen ber das Ziel hinausschie en Kontinuierliche Anforderungs nderungen Defizite bei extern gelieferten Komponenten Defizite bei extern erledigten Auftr gen Defizite in der Echtleistung Leitfaden Projektmanagement To Office 2 Heip Instrumentierung Tuning 10 berfordern der Technische Analyse Softwaretechnik Kosten Nutzen Analyse Prototypen Tabelle 6
148. itber cksichtigen und umgekehrt Ein weiterer Grund liegt h ufig darin dass Techniker Kauflaute und Juristen eine teilweise unterschiedliche Vorstellung von Pr zision und pr ziser Beschreibung haben Seite 157 Leitfaden Projektmanagement To Office 2 Heip Seite 158 Das bei EDV Projekten nderungen des Vertragsgegenstandes typischer Bestandteil des Gesch ftes sind ndern unpr zise Vertrags nderungen diese unpr zisen Regelungen zum Teil erheblich Der Servicegedanke wird von einigen Lieferanten so gro geschrieben dass auch wirtschaftlich umfangreiche Arbeiten kostenlos bernommen werden weil sie mit dem urspr nglichen Vertrag zusammenh ngen Das kann aber insgesamt erhebliche Nachteile haben e Die H he der Aufwendungen f r freiwillige Nachbesserungen l sst sich am Anfang nicht absch tzen Knapp kalkulierte Projekte werden notleidend Die Gew hrleistungsfrist l uft nicht an e Der Umfang der Gew hrleistung und Haftungsanspr che nimmt zu und kann nicht immer berblickt werden 17 1 1 2Vertrags nderungen k nnen eine Chance darstellen Gegen diese Folgen kann sich der Anbieter nur dann wirksam sch tzen wenn Art und Umfang des Werkes nicht nur technisch sondern auch kaufm nnisch und juristisch pr zise formuliert wurden Dann kann das Software Haus auch gegen ber dem Auftraggeber eine entsprechende Extraverg tung verlangen Der Servicegedanke muss dabei nicht auf der Strecke bleiben Wenn das Software H
149. itere Hinweise und Ordnungsregeln sind in den Abschnitten Projektplanung Projektkontrolle und steuerung sowie den Regeln f r die Durchf hrung von Projekten aufgef hrt 8 2 1Teams bilden und f hren Ein Projekt kann meist nicht durch einen einzelnen Mitarbeiter durchgef hrt werden da er zu viel Zeit ben tigen w rde um entsprechende Arbeiten durchzuf hren und ihm evtl zus tzlich in verschiedenen Bereichen die entsprechenden Kenntnisse fehlen Daher muss eine Gruppe an Mitarbeitern gemeinsam an einer Aufgab arbeiten Ein Team stellt die ausgepr gteste Form der Gruppenarbeit dar In einem Team arbeiten Mitarbeiter unterschiedlicher Qualifikationen miteinander um eine Aufgabe zu erledigen Teamarbeit ist durch folgende Charakteristika gekennzeichnet e Regelm ige und kontinuierliche Kommunikation miteinander e Gleichberechtigte Mitbestimmung aller Teammitglieder bei der Diskussion von Methoden Inhalten und Zielen der Arbeit und ihrer Durchf hrung e Alle Teammitglieder sind gleichrangig und agieren auch gleichrangig e Verschiedene Teammitglieder bernehmen zeitweise die F hrungsrolle jeweils auf dem Gebiet auf dem sie ihre St rken haben Seite 57 Projektaufbau Organisation Projektleiter Andere F hrungskr fte Teamarbeit ist Zusammenarbei t Leitfaden Projektmanagement To Office 2 Heip Die richtigen Ziele setzen Seite 58 Die Struktur eines Teams ist ein Netzwerk und keine Hierarchie Mana
150. kann oder ob Nachbesserungen notwendig sind Ebenso muss gepr ft werden ob nicht Ereignisse eingetreten sind die einen Abbruch des Projektes erfordern 16 2 2Kontrolle und Steuerung bei objektorientierter Vorgehensweise Zur Kontrolle und Steuerung von Projekten mit objektorientierter Vorgehensweise eignet sich die Timebox Eine Timebox dient der Projektleitung dazu die Kontrolle ber ein Projekt zu behalten das die einzelnen Phasen der Projektarbeit zyklisch mehrfach durchl uft Die zyklische Abarbeitung bedingt dass die Ergebnisse der einzelnen Phasen nicht vollst ndig und damit nicht oder nur in Teilen abnahmef hig sind Aus diesem Grund wird das Projekt in mehrere Teilprojekte Themenbereiche aufgegliedert Diese Bereiche werden in sogenannten Timeboxen bearbeitet Eine Timebox stellt in diesem Zusammenhang einen festen Zeitabschnitt dar max 6 Monate in dem ein vorher definiertes Teilsystem realisiert wird Die einzelnen Timeboxen des Projektes k nnen unterschiedlich lang sein Die L nge variiert mit dem Aufwand f r das Teilsystem Innerhalb der Timebox werden f r das Teilsystem die Phasen Fachliches Feinkonzept Analyse DV technisches Feinkonzept Design Implementierung und Test f r das Teilsystem ggf mehrfach 2 5 mal durchlaufen Am Schluss eines Iterationsschrittes steht immer ein lauff higer Prototyp der von den Benutzern einem Review unterzogen wird Der Prototyp wird evolution r weiterentwickelt bis zum lauff
151. kann viel Unheil vermieden werden Ob eine Zielver nderung notwendig sinnvoll und durchf hrbar ist h ngt jedoch stark vom Einzelfall ab vom Fortschritt des Projekts und den bisher angefallenen Kosten Leitfaden Projektmanagement Q Office 2 Heip 10 1 3Der Endtermin verschiebt sich nach vorne Eine solche Entscheidung ist immer ein fataler Fehler Oft wird dann versucht zus tzliches Personal hinzuzuziehen Hier kommt allerdings Murphy s Law zum Zuge Hinzuf gen von Personal z gert ein versp tetes Projekt noch mehr hinaus Der Grund daf r liegt in dem gr eren Koordinations und Kommunikationsaufwand aufgrund der steigenden Mitarbeiterzahl Es w re an dieser Stelle sinnvoller eine Entscheidung zu treffen dass bestimmte Module oder bestimmte F higkeiten der Software erst zu einem sp terem Zeitpunkt oder mit dem n chsten Release erstellt werden Denn alles was jetzt unter Zeitdruck wom glich mit neuen ungeschulten Mitarbeitern geschieht hat direkten Einfluss auf die Qualit t Vor allem macht es keinen Sinn die Zeit die f r die Pr f und Testphase eingeplant wurde zu k rzen oder gar zu streichen Das kann sich zu einem Schlag nach hinten entwickeln Sinnvoll w re statt dessen eine Optimierung der Abl ufe Welche Vorg nge und T tigkeiten k nnen parallelisiert werden welche T tigkeiten die bisher eine Ende Anfang Beziehung haben k nnen m glicherweise berlappend eingeplant werden sprich welche Vorg n
152. kratisch 8 1 2Organisation nach Funktionen Ein Organisationsaufbau nach Funktionen ber cksichtigt die Interdependenzen im Hinblick auf Arbeitsprozesse und wirtschaftliche optimale Arbeitsbereiche unter Vernachl ssigung der Interdependenzen beim Arbeitsablauf Die Spezialisierung wird gef rdert z B durch Einrichtung von Aufstiegsm glichkeiten f r Spezialisten innerhalb des eigenen Bereichs durch Zuordnung von Vorgesetzten aus demselben Fachgebiet Durch die Spezialisierung nimmt aber das Interesse an den organisatorischen Gesamtleistungen ab Die Mitarbeiter sind nicht an den umfassenderen Zielsetzungen der Organisation ausgerichtet Au erdem l sst sich die Leistung in einer funktionalen Struktur nicht ohne weiteres messen Der funktionalen Struktur fehlt ein eingebauter Mechanismus zur Koordinierung des Arbeitsablaufs Die gegenseitige Abstimmung unter den verschiedenen Spezialisten und die pers nliche Weisung durch die jeweiligen F hrungskr fte werden behindert Die funktionale Struktur ist unvollst ndig Es werden zus tzliche Koordinationsinstrumente ben tigt Funktionale Strukturen neigen zu gr erem B rokratismus In den h heren Hierarchien werden mehr F hrungskr fte ben tigt um die funktionale bergreifenden Abl ufe und Entscheidungen zu koordinieren Leitfaden Projektmanagement Q Office 2 Heip 8 2Die Projektorganisation Die Projektorganisation ist eine tempor re berlagerung der normalen Organisationsstruktur
153. kt betrachtet und in der Planung und Realisierung ber cksichtigt werden Seite 12 Leitfaden Projektmanagement To Office 2 Heip 4Die Geschichte des Projektmanagements Zu Begin des Leitfadens m chte ich Ihnen etwas dar ber ausf hren wie und warum das heutige Projektmanagement berhaupt entstanden ist Die Wurzeln des modernen Projektmanagements liegen erst einige Jahrzehnte Die Wurzeln zur ck Zu Beginn der 60er Jahre erkannten bereits Unternehmen und Organisationen den Vorteil Arbeiten in der Form von Projekten durchzuf hren Gleichzeitig wuchs das Verst ndnis f r die Anforderung Arbeiten und Kommunikation ber mehrere Abteilungen Firmen Spezialisten etc zu verteilen und durchzuf hren 4 1Die Anf nge Das sp te 19 Jahrhundert Reisen wir jedoch noch weiter zur ck in die Vergangenheit zum Ende des 19ten Jahrhunderts und zu den immer komplexer werdenden Gesch ftspraktiken in der Gesch ftswelt Hier erkennen wir bereits wie sich das Projektmanagement aus den allgemeinen Management Prinzipien heraus entwickelt hat Gro e staatliche Projekte waren dann der Ausl ser f r wichtige Entscheidungen die dann schlie lich und endlich in Management Entscheidungen m ndeten In unserem Land war eines der ersten gr eren Projekte die Planung und Realisierung der Eisenbahn Pl tzlich fanden sich f hrende Gesch ftsleute und Unternehmer mit der Tatsache konfrontiert die Arbeit von tausenden und abertausenden von
154. kungsausschuss genehmigt werden Dieser wird in der Regel eine Analyse der Auswirkungen der nderung fordern Spezifikationsabweichungen k nnen direkt vom Projektmanager behandelt werden wenn sie innerhalb vorgegebener Toleranzgrenzen liegen Der Lenkungsausschuss kann eine Spezifikationsabweichung als Konzession ohne weitere nderung genehmigen 12 7 8 12 3Qualit tspr fungen PRINCE2 fordert dass Produkte auf ihre Qualit t gepr ft werden Dies findet in einer Qualit tspr fungs Sitzung statt in der Fehler im Produkt identifiziert werden In dieser Sitzung wird nicht versucht die identifizierten Probleme zu beheben 12 7 8 13St rken Die PRINCE2 Methode hat eine Reihe von St rken Sie liefert stark standardisierte Projekte die ein einheitliches Vorgehen einheitliches Vokabular und einheitliche Dokumente haben Schlie lich ist es eine leicht erlernbare Arbeitsweise und jeder der mit einer Methode vertraut ist kann sich in einem sorgf ltig gef hrtem PRINCE2 Projekt schnell zurechtfinden Sie verk rpert Best Practise im Projektmanagement d h sie beinhaltet verschiedene in der Praxis bew hrte Methoden Sie propagiert Management by Exception als Richtlinie was es den Projektmanagern erlaubt ihre Arbeit ohne unn tige Einmischung auszuf hren w hrend gleichzeitig bergeordnete Manager an den Punkten wo das Projekt schlecht l uft oder nach PRINCE2 au erhalb der Toleranzgrenzen involviert werden
155. l getroffen und auf m gliche Projektgr en und das Lernverhalten abgestimmt werden Sicherlich ist ein Seminar hilfreich doch stellen sich die Probleme und Fragen erst w hrend des laufenden Projekts heraus Und hier ist f r die erfolgreiche Leitung eines Projekts au er Erfahrung auch eine ordentliche Portion Begabung notwendig Wir kommen sp ter noch einmal zum Thema Besetzung der Projektleitung zur ck Zun chst aber gilt es einen wichtigen Begriff zu kl ren 6 1 1 1Was ist ein Projekt Wir wissen ja schon ein Projekt ist ein einmaliges Ereignis in einem bestimmten Zeitraum mit einem eindeutigen Ziel unter bestimmten Bedingungen Im Bereich der Softwareentwicklung k nnte das zum Beispiel die Entwicklung einer neuen Version f r die Software ABC bis zur n chsten Cebit sein Was f r diesen Job ben tigt wird sind einerseits kreative Softwareentwickler und andererseits ein Projektleiter mit einem hohen Ma an Organisationsverm gen und sozialer Kompetenz Nat rlich k nnen Tools aus dem Bereich des Projektmanagements sinnvoll unterst tzen Aber der Mensch steht eindeutig im Mittelpunkt 6 1 2Der Projektleiter Ein Organisationsgenie Das Problem bei vielen Projekten im Entwicklungsbereich ist nun dass die Die richtige Mitarbeiter die zu Projektleitern benannt werden immer noch selbst Besetzung der mitentwickeln H ufig bleibt im Kopf kein Platz mehr f r Gedanken an die PL Funktion Koordination der Termine und deren Kom
156. le Kompetenz besitzen bzw diesbez glich mit allen notwendigen Vollmachten ausgestattet sein 8 3 3Projekt Board Das Projekt Board kann bei Projekten mit entsprechender Komplexit t zur weiteren fachlichen Unterst tzung eingerichtet werden Dieses Gremium ist eine fakultative Einrichtung Dem Projekt Board geh ren folgende Mitglieder an e das Management der betroffenen und ggf beteiligten Bereiche Auftraggeber und Auftragnehmer e der Projektleiter als berichtendes Mitglied Die Aufgaben des Projekt Boards sind e Schnelle fachliche Entscheidungen bei Problemen unterste von zwei Eskalationsstufen bei Problemen im Projektteam e Definition und Kontrolle kurzfristiger Ziele e Festlegung von Priorit ten e Schaffung der Voraussetzung zur Freigabe von Projektphasen 8 3 4Beteiligte Funktionen W hrend der Projektarbeit kann es sich als sinnvoll und notwendig erweisen zeitweise Unterst tzung von Funktionen aus der Regelorganisation in Anspruch zu nehmen Die Organisationseinheit beim Kunden welche die Systemplanung f r den Gesamtbereich durchf hrt ist sofort bei Beginn des Projektes vom Projektleiter einzubeziehen Diese ist ber den gesamten Projektierungszeitraum Ansprechpartner des Projektleiters Sie veranlasst die Einbindung weiterer Struktureinheiten wenn es notwendig ist Leitfaden Projektmanagement Q Office 2 Heip In der Regel sind Ansprechpartner aus folgenden Themenbereichen zu beteiligen bzw zu konsul
157. lemente des Systems wie z B von Komponenten Einzeltest bis hin zum Testen des gesamten Systems Systemtest Insgesamt werden dabei folgende Typen unterschieden e Einzeltest Die kleinste testbare Einheit des Systems wird individuell getestet Das kann ein einzelnes Objekt betreffen oder auch ein Framework das in eine Applikation eingebunden wird e Integrationstest Hier werden die einzelnen Komponenten Einheiten oder Subsysteme hinsichtlich ihrer Integration getestet e Systemtest Die Anwendung und das gesamte System bestehend aus einer oder mehrerer Anwendungen werden getestet e Akzeptanztest Die Anwendung oder das System werden vom Endbenutzer Anwender Kunden hinsichtlich Auslieferungsf higkeit getestet Dabei handelt es sich in den meisten F llen um den kritischsten Test da hier zum Teil auf Jahre zur ckliegende Anforderungen auf einen neuen State of the Art treffen e Regressionstests Hiermit repr sentiert sich eine Teststrategie bei der Regressions zuvor getestete Objekte erneut mit einer neuen Version des Testobjektes Tests getestet werden Der Sinn von Regressionstests liegt darin dass sichergestellt werden muss o Dass die Fehler die beim vorherigen Testlauf entdeckt wurden mittlerweile beseitigt sind o Und nderungen die am Code des Testobjektes vorgenommen wurden nicht neue Fehler hervorgerufen oder alte Fehler aufgeweckt haben Seite 91 Leitfaden Projektmanagement To Office 2 Heip Die T
158. len mit dem Ziel zusammenarbeiten einen gemeinsamen Erfolg die f r das Unternehmen zu erreichen Zusammenarbei t der Beteiligten Seite 74 Leitfaden Projektmanagement Q Office 2 Heip 9Projektvorbereitung 9 1Projektausl ser Es kann verschiedene Ursachen geben die ein Projekt ausl sen TOP Down aus einem Wei buch abgeleitet Migrationserfordernis eines bestehenden Informationssystems Spontane Anforderung aufgrund eines aktuellen Bedarfs Wartungserfordernis f r eine bestehende Anwendung 9 2Projektinitialisierung Bevor berhaupt ein Projekt definitiv eingerichtet werden soll m ssen bestimmte Fragen vorab gekl rt werden In dieser kurzen Konzeptionsphase sind verschiedene fachlich inhaltliche Zusammenh nge abzukl ren die in der Projektidee zusammengefasst werden siehe Vorgehensmodell V97 SEVM Projektinitialisierung Die Dauer dieser Projektidee Phase sollte 10 Tage nicht berschreiten Ebenso sind projektorganisatorische Festlegungen zu treffen und die entsprechenden Voraussetzungen f r einen Projektstart zu schaffen Hierzu ist ein erster grober Projektplan mit Arbeitspaketen und Meilensteinen zu erstellen Es sind z B folgende Aufgaben zu erledigen e Personal freistellen Abordnung oder Versetzung e R ume beschaffen e Ger te und Werkzeuge bereitstellen e Beratung bei verschiedenen Organisationseinheiten einholen Jedes Projekt wird mit einem schriftlichen Auftrag des Anwenders Auftraggebers bego
159. lgerichteten Einsatz von Vorhandenen gepaart mit der richtigen Methodik und dem Verst ndnis f r die Problematik Nur jene Unternehmen und Projektleiter die Ihre Projekte betriebswirtschaftlich im Griff haben und entsprechend laufend weiterentwickeln werden langfristig handlungsf hig bleiben Leitfaden Projektmanagement Q Office 2 Heip 15 1Vorgehensweise Risikomanagement besteht aus einer Reihe von Schritten Jedem dieser Schritte k nnen eine oder mehrere Techniken zugeordnet werden die helfen sollen die jeweiligen Aufgaben erfolgreich durchzuf hren Einige dieser Vorgehensweisen und Techniken werden wir in diesem Kapitel n her betrachten Risikotechniken Risikobewertung D 5 O RZ ku k Q p a Seite 137 Leitfaden Projektmanagement Q Office 2 Heip Seite 138 15 1 1Risiko Identifikation Das Ergebnis einer Risiko Identifikation ist eine Liste der projektspezifischen Risikoelemente die den Projekterfolg gef hrden Projektspezifische Risiken sind Risiken die nicht allgemein auf alle Projekte zutreffen wie z B das Risiko ein fehlerhaftes Produkt zu erstellen Bei der Risikoidentifikation kann man sich an Checklisten orientieren um die projektspezifischen Risiken zu finden Eine solche m gliche Checkliste hier f r ein Softwareprojekt zeigt die nachstehende Tabelle Sie enth lt die 10 wichtigsten Quellen f r Risiken in Software Projekten Jedem Risiko sind Techniken zugeordnet m
160. lich Informationen ber kritische Vorg nge m ssen sicher bei Entscheidungstr gern ankommen Unkritische Aspekte m ssen ebenso sicher gefiltert werden 5 7 7Halten Sie das System flexibel H ufig wird der Versuch unternommen in Excel oder in anderen Tabellenkalkulationen eine Projektbuchhaltung aufzubauen Dies sollte dann meist auch noch als Export Import Schnittstelle zu Terminplanungssystemen dienen Dieser Ansatz ist prinzipiell nicht falsch jedoch wird meist bersehen dass bereits Buchhaltungen existieren ebenso wie Betriebsdatenerfassungssysteme Eine Projektbuchhaltung ist ein berwachungsinstrument f r die Projektkostenkontrolle Kostenvoranschl gen und nachtr gen steht ein Pool von Rechnungen gegen ber die meist unter anderen Gesichtspunkten durch die Projektleiter gegliedert werden m ssen Beachten Sie In einem Projekt ndern sich Daten sehr h ufig infolge technischer und terminlicher nderungen Das System muss flexibel bleiben und die Projektstruktur abbilden Die Buchhaltung hat meist andere Strukturen Sie kann Leitfaden Projektmanagement Q Office 2 Heip zwar Informationen bernehmen F r die Projektplanung sollten sie aber das richtige System mit dem richtigen Grad an Genauigkeit der Informationen verwenden Sie werden bei dem Versuch scheitern direkt mit Microsoft Project Zahlen in der Genauigkeit zu generieren dass sie direkt in SAP R 3 etc bernommen werden k nnen 5 7 8Die Belegung der Re
161. liegt in der Verantwortung des Projektleiters e Ziel der Planung ist es die verf gbaren Projektmitarbeiter den erforderlichen Projektaktivit ten so zuzuordnen dass der f r die betrachtete Phase g ltige Zeitrahmen nicht berschritten und die angestrebte Qualit t nicht unterschritten wird e Bei der Festlegung dieser Aktivit ten sind folgende Forderungen einzuhalten e T tigkeiten sind so zu definieren dass sie o einem Mitarbeiter zugeordnet werden k nnen o ein definiertes steuerbares Ergebnis zur Folge haben o in einem Zeitintervall abgewickelt werden k nnen welches eine schnelle Reaktion auf Planabweichungen zul sst z B 2 Wochen Der maximal zul ssige Planungszeitraum ist auf 3 Wochen festgelegt e Obligatorisch f r die Projektplanung sind folgende Planungsunterlagen o Aufgabenstrukturplan o Gesamt berblick ber die Projektaktivit ten und die ihnen zugeordneten Mitarbeiter Feinplan Terminplan Zeitliche und logische Abfolge der Projektaktivit ten Grobplan Ressourcenplan Zu den Ressourcen in einem Projekt geh ren IT Personal Fach Personal aus den Fachbereichen 000000 Seite 177 Leitfaden Projektmanagement TOJ Office 2 Heip Seite 178 o Leistung von externen Hardware Software H usern und Beratungsfirmen o Hardware im Rechenzentrum o Sachmittel R ume o Finanzplan Aus Gr nden der besseren Kommunikation sind alle Planungsdaten zus tzlich zur zahlenm igen Darstellung grafisch
162. ll sungen vermeiden Auch das ist etwas was f r das Projektmanagement wichtig ist Projektmanagement bedeutet sich mit neuem zu besch ftigen Und dazu m ssen komplexe Zusammenh nge erfasst werden und neues gedacht werden 5 7 2Aufl sung von Komplexit t je gr er die Komplexit t eines Systems ist umso wichtiger ist die Analyse Durch eine erweiterte Betrachtungsweise das Schauen ber den Tellerrand hinaus und berlegtes Vorgehen k nnen drohende Misserfolge fr hzeitig erkannt und rechtzeitig Ma nahmen zur Steuerung ergriffen werden Nehmen Sie sich gerade am Anfang ausreichend Zeit die Zusammenh nge aufzudecken Sprechen Sie Ihr Vorhaben nicht nur mit den Planern eines Projektes ab sondern holen Sie ebenso die Realisierer mit in das Boot diejenigen die das Projekt schlie lich umsetzen m ssen Sie werden sehen dass das Projektmanagement eine Aufgabe ist die erlernt werden muss Das erste Projekt das Sie mit den Methoden des Projektmanagements durchziehen wird sie sehr viel Zeit und Kraft kosten Sie werden aber bereits beim ersten Projekt feststellen dass Sie auf einmal sehr viel mehr ber Ihre Arbeit wissen Nehmen Sie sich also wirklich die Zeit Durch bung l sst sich die Komplexit t reduzieren Methoden zur Reduktion der Komplexit t sind zu Beginn ebenfalls komplex Im Laufe der Zeit wird das Verst ndnis komplexer Systeme und Zusammenh nge im Projekt aber durch die konsequente Nutzung der Methodik erlei
163. llt wird hat eine ganze Reihe von Gr nden Eine davon ist dass Projektverantwortliche in den meisten F llen gar nicht wahrhaben wollen dass ihr Projekt gescheitert ist Die gr te Gefahr in scheiternden Projekten besteht darin dass eine aufkommende brenzlige Situation nicht rechtzeitig erkannt wird Dies geschieht entweder aus Unerfahrenheit oder sogar aus Absicht zur Jobsicherung F r die erstgenannte Kategorie ist dieser Leitfaden eine wesentliche und wichtige Hilfe Der zweiten Kategorie ist sicher auch mit diesem Leitfaden nicht zu helfen Ein Projekt ist dann gescheitert wenn folgende Symptome erkennbar sind 10 1 1Keine eindeutige Zieldefinition Eine exakte Zieldefinition ist einer der wichtigsten Schritte innerhalb der Projektinitiierung Was in diesem Bereich an Vorarbeit vers umt wird muss hinterher bitter geb t werden Nur durch ein eindeutig definiertes Projektziel ist eine realistische Planung m glich Was sind die Eigenschaften einer erfolgreichen Zielformulierung e L sungsneutralit t Es sollte vermieden werden L sungen vorwegzunehmen Vorweggenommene L sungen vermindern die Chance dass mehrere L sungswege gefunden werden und f hren zu einem Motivationsdefizit im Team e Durchf hrbarkeit und Erreichbarkeit Projektziele m ssen erreichbar und mit den zur Verf gung stehenden Mitteln durchf hrbar sein Hierzu ist es sinnvoll vorab eine Machbarkeitsanalyse durchzuf hren Anhand einer Checkliste sollten
164. meinsam gemanagt werden m ssen Bezogen auf Projektmanagement geh ren dazu alle Produkte und Lieferergebnisse Konfigurationsmanagement besteht aus f nf Haupt Funktionen Planung Identifikation Steuerung Status Fortschreibung Verifikation 12 7 8 11 8 nderungssteuerung Die Steuerung von nderungen wird von der Technik nderungssteuerungstechnik behandelt siehe weiter unten 12 7 8 12Techniken PRINCE2 benennt drei Techniken f r die spezielle Verwendung in Projekten 12 7 8 12 1Produktbasierte Planung Im Gegensatz zu aktivit tsbasierter Planung setzt PRINCE2 produktbasierte Planung ein Das hei t PRINCE2 plant und misst gegen objektive und messbare Produkte z B die Wand statt gegen eher subjektiv definierte und gemessene Aktivit ten z B 50 des Baus der Wand Produktbasierte Planung bedeutet die Erstellung von e Produktstrukturplan e Produktbeschreibungen des Endprodukts des Projekts und jedes Produkts e Produktflussdiagrammen Leitfaden Projektmanagement Q Office 2 Heip 12 7 8 12 2 nderungssteuerung In PRINCE2 werden alle nderungen als offene Punkte des Projekts behandelt Es gibt drei Typen von nderungen nderungsantrag Spezifikationsabweichung Dies ist wenn ein Produkt einer Anforderung nicht gen gt Anfrage Alle offenen Punkte liegen in der Verantwortung des Projektmanagers und werden in eine Liste der offenen Punkte aufgenommen nderungsantrf ge m ssen vom Len
165. ment sondern nur zu einer fr heren Fehlererkennung und besseren Strukturierung und Dokumentation des Projekts Das bessere Projektmanagement muss das ziel sen nicht die Reduzierung des Aufwands f r das Projektmanagement Diese Einsicht ist zun chst ern chternd Ein System wie Microsoft Project oder hnliche Programme ist eben nicht die L sung f r ein Problem sondern ein Werkzeug f r die effiziente L sung eines Problems n mlich des Projektmanagements Eine der besten Einsichten zum Thema Projektplanungssoftware ist die folgende Projektplanungssoftware kann einen guten Projektmanager noch besser machen sie wird aber aus einem schlechten oder mittelm igen Projektmager niemals einen guten Projektmanager machen Seite 193 Leitfaden Projektmanagement To Office 2 Heip Seite 194 21Anhang 21 1Murphys und andere Gesetze 21 1 1Murphys Gesetze Wenn etwas schief gehen kann dann wird es auch schief gehen Das was Du suchst findest Du immer an dem Platz an dem Du zuletzt nachschaust Egal wie lange und m hselig man versucht einen Gegenstand zu kaufen wird er nachdem man ihn endlich gekauft hat irgendwo billiger verkauft werden Die andere Schlange kommt stets schneller voran Um ein Darlehen zu bekommen muss man erst beweisen dass man keines braucht Alles was Du in Ordnung zu bringen versuchst wird l nger dauern und Dich mehr kosten als Du dachtest Wenn man lange genug an einem Ding
166. mit blicherweise auch durch h here Kosten geschehen Aber auch das Sachziel kann angepasst werden wenn die Art des Projekts so etwas zul sst e Innerhalb des Projekts werden Rationalisierungspotentiale analysiert So k nnen h ufig Terminprobleme nicht nur durch die Verschiebung des Endtermins gel st werden sondern auch durch eine effizientere Anordnung von Vorg ngen innerhalb eines Projektes Gerade die Parallelisierung aber auch die Zerlegung von Vorg ngen bieten hier gro es Potential e Das Projekt wird abgebrochen Das bietet sich gerade in fr hen Projektphasen an in denen noch nicht allzu viel Arbeit und Geld in ein Projekt investiert wurde Ein guter Projektmanager ist in der Lage ein Projekt zu beenden wenn dies sinnvoll ist Das ist kein Zeichen von Schw che sondern eines von St rke Es kostet sehr viel mehr R ckgrat ein Projekt zu beenden als es gegen die Wand zu fahren Diese Situation l sst sich gut mit dem Bergsteigen vergleichen Ein guter Bergsteiger kehrt um wenn die Situation nicht erwarten l sst dass er den Gipfel erreichen und wieder sicher zur H tte zur ckkehren kann Wer das nicht macht und in Schwierigkeiten ger t ist ein schlechter Bergsteiger Rechtzeitiges Umkehren ist eine der gr ten Herausforderungen beim Bergsteigen Und ebenso ist das rechtzeitige Abbrechen eines Projekts eine der gr ten Herausforderungen beim Projektmanagement Welche Ziele ver ndert werden ist in hohem Ma e von d
167. modell QS im V Modell unssssnnnsnsnnnnnnnnnnnnnnnnnnnnnnnn 110 Abbildung 23 Submodell PM im V Modell uuuusssunnnnsnnnennnnnnnnnnnnnnnnnnn 111 Abbildung 24 Das V Modell XT unnssuunsennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn anne 114 Abbildung 25 Microsoft Solutions Framework MSF uuu r 115 Abbildung 26 Der Rational Unified Process unuenssnnnnnnnnnnnnnnnnnnnnnnnnnn 116 Abbildung 27 ITIL Supporting Processes unuuunusunnnnnnnnnnnnnnnnnnnnnnnnnnnn 118 Abbildung 28 Kernpublikationen uunsusssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 119 Abbildung 29 Prince Modell rn 120 Abbildung 30 Abw gen Risiko uuuuuunnunnnnnnnnnnnnnnnnnnnnnanannnnnnnnnnnnnnnnnnnn 136 Abbildung 31 Entscheidungsprozess uuuunnannnanannnnnnnnnnnnnnnnnnnnnnnnnnnnn 151 Abbildung 32 Prinzip der Timeboxen uunuusunuunnnnnnnnnnnnnnnnnnnnnnnnnnnn 153 Abbildung 33 nderungsverfahren grober Ablauf 2 2 22 2022r2s20020 155 Abbildung 34 Das Vorgehensmodell im Anwendungsentwicklungs Aera E ET E a 162 Abbildung 35 Modul SEVM im V Modell uuussnunssssnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 163 Abbildung 36 Teilschritte bei objektorientierter Vorgehensweise OO ATAA p EETA AES PER EBENEN A EE EEEE A SUSE BRENNROANE A EENE RE TNEPUEINERDENENDABR 164 Abbildung 37 Berichtswesen unnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 169 Tabellenverzeichnis Tabelle 1 Projektphasen usu
168. munikation innerhalb des Teams Der Projektleiter sollte im Idealfall von der Entwicklung befreit werden um sich voll und ganz auf Projektmanagement zu konzentrieren Ist das Know how eines Mitarbeiters sehr stark gefragt dann sollte man doch in Erw gung ziehen einen anderen Mitarbeiter mit der Projektleitung zu betrauen Wie erw hnt hat Projektmanagement mit Organisationsverm gen und bergreifendem und vorausschauendem Denken zu tun Der beste Entwickler im Team hat seine St rken in der Regel woanders Es stellt sich die berechtigte Frage ob ein Entwickler der zum Projektleiter bef rdert wird nicht entgegen seiner Talente und F higkeiten eingesetzt wird 6 1 2 1Arbeit muss Spa machen Wenn die Arbeit keinen Spa mehr macht dann geht die Leistung mit oder ohne Projektmanagement automatisch zur ck Kurzum Lieber ein hervorragender Softwareentwickler der mit ein wenig Chaos zu sehr guten Ergebnissen gelangt und durch einen f higen Projektleiter unterst tzt wird als ein schlechter Projektleiter dem die Felle davonschwimmen und der als Entwickler eine L cke Seite 51 Leitfaden Projektmanagement To Office 2 Heip Seite 52 hinterl sst Und wenn es wirklich eine Bef rderung sein soll Wie w re es mit einem Posten als Chef Architekt Nat rlich sind Projektmanagement und Qualit tssicherung bei Entwicklungsprojekten von immenser Bedeutung aber man sollte nicht vergessen dass hinter jeder T tigkeit Mensc
169. n vielleicht als Versuch zur L sung dieser Probleme Dieser Umstand ist ein klares Indiz f r die offensichtliche Bereitschaft alles zu versuchen um diese Probleme zu l sen allerdings genauso ein Indiz daf r dass die L sung gar nicht so einfach ist Dieser kontinuierliche Technologiewechsel hat nun f r Sie als Projektleiter zur Folge dass Sie sich zwar am Anfang eines Projektes f r eine Technologie entscheiden m ssen jedoch st ndig im Auge behalten m ssen dass sich die Technologie je nach Projektlaufzeit auch wieder ndern kann Nat rlich ist es sehr schwer innerhalb eines laufenden Projektes einen Technologiewechsel vorzunehmen Unter Umst nden kann es bedeuten nahezu wieder von vorne anzufangen doch letztendlich entscheidet eine Return on Investment Rechnung dar ber ob und wann Sie einen Technologiewechsel vornehmen Doch Technologiewechsel bewirken auch beim Kunden ein nderung der zuvor gestellten Anforderungen Denken Sie nur einige Jahre zur ck als grafische Benutzeroberfl chen noch ein Fremdwort waren und ASCIl Oberfl chen State of the Art waren Ein Projekt dass damals eine ASCIl Oberfl che vorsah war im sp teren Projektverlauf gezwungen unabh ngig was die Return on Investment Rechnung ergab Hier existierte ein wesentlich gewichtigeres Argument die gestiegenen Anforderungen des Kunden Leitfaden Projektmanagement 10 1 10Mangelnde Kommunikation im Projekt Je gr er ein Projekt ist
170. n Das Wei buch ist Ergebnis der strategischen Informationsplanung und beschreibt den strategischen Handlungsbedarf und seine Umsetzung f r die Prozesse der Gesch ftsbereiche der Querschnittsprozesse und der Arbeitsplatzprozesse Mit dem Wei buch soll die Basis f r einen unternehmensweiten Konsens f r die Priorit ten f r die IT Investitionen f r die n chsten Jahre herbeigef hrt werden Seite 55 Leitfaden Projektmanagement To Office 2 Heip Seite 56 8Projektaufbauorganisation 8 1Projektaufbauorganisation allgemein Die Gestaltung der Projektaufbauorganisation h ngt ma geblich von denen sie umgebenden Organisationen ab Diese Organisationen k nnen z B nach e M rkten e Funktionen aufgebaut sein 8 1 1Organisation nach M rkten Ein Organisationsaufbau nach M rkten bildet Einheiten die alle wichtigen und sequentiellen und reziproken Interdependenzen umfasst so dass nur noch die gepolten Interdependenzen brigbleiben Jede Einheit bezieht Ihre Ressourcen und vielleicht auch bestimmte Hilfsdienste aus der gemeinsamen Struktur Sie f hrt alle anfallenden Funktionen f r eine bestimmte Kategorie von Produkten Dienstleistungen Kunden oder Orten aus Sie tendiert daher dazu sich mit diesen M rkten zu identifizieren Ihre Leistung ist entsprechend einfach zu beurteilen Da gegenseitige Abstimmung und pers nliche Weisung innerhalb einer Einheit zu leisten sind ist die Organisation in aller Regel wenig b ro
171. n Kostenziel definiert und berwacht werden Damit l sst sich erkennen ob und bis zu welchem Punkt die Durchf hrung eines Projekts unter dem Aspekt der Kosten berhaupt vertretbar ist e Die Betrachtung von Kosten in Projekten kann die Kostendisziplin in Projekten wesentlich erh hen e Die Information ber Kosten von Projekten stellt einen wesentlichen Baustein bei einer zwischenzeitlichen oder abschlie enden Kosten Nutzenbetrachtung dar und liefert damit auch wichtige Informationen ber den Projekterfolg und dar ber was bei zuk nftigen Projekten des gleichen Typs zu beachten ist Sie kann auch die Basis f r die Preis bei zuk nftigen Angeboten im gleichen Bereich bilden Das Terminziel als drittes Ziel hat in den meisten Projekten eine wesentlich gr ere explizite Bedeutung als das Kostenziel Das Projekt soll zu einem definierten Zeitpunkt zu Ende gebracht werden Unter Umst nden m ssen sogar Teilleistungen innerhalb des Projekts zu fr heren Zeitpunkten abgeliefert werden Leitfaden Projektmanagement Q Office 2 Heip Terminmanagement ist damit eine der gro en Herausforderungen des Projektmanagements Es gibt eine Vielzahl von Situationen bei denen es keinen Spielraum f r die Endtermine in einem Projekt gibt Wenn Satelliten gebaut werden die mit einer bestimmten Tr gerrakete transportiert werden sollen m ssen diese p nktlich fertig werden Bei Softwareprojekten waren zum Beispiel die Jahr 2000 Projekte ausgespro
172. n Sie den Plan mittels einem Projektmanagement Werkzeug so wie z B MS Project Betrachten Sie den Risikoplan zusammen mit dem eigentlichen Projektplan Sollten durch das Zusammenspiel von Projektplan und Risikoplan neue Risiken aufzeige so nehmen Sie sich diesen wie schon zuvor beschrieben an Leitfaden Projektmanagement Q Office 2 Heip 15 1 4Risiko Priorit tenbildung Um zu verhindern dass man vor lauter identifizierten und analisierten Risikoelementen die wirklich relevanten Risiken nicht bersieht m ssen die Risiken nach Priorit ten geordnet werden Eine M glichkeit dazu besteht in der Berechnung der Risikofaktoren Oft konzentriert man sich auf die Eintretenswahrscheinlichkeit oder das Schadensausma Wie die nachstehende Tabelle zeigt gibt jedoch der Risikofaktor die h chsten Risiken an Unbefriedigendes Wahrscheinlichk Sch den Risikofakto Ergebnis eit f r verursacht durch unbefriedigende unbefriedigendes sErg ons eig nnle Projekt den Verlust ve von Daten Fehlertolerante Eigenschaften 28 56 f hren zu einer nicht annehmbaren Leistung berwachung der Software ergibt das unsichere Bedingungen als sicher gemeldet werden berwachung der Software ergibt das sichere Bedingungen als unsicher gemeldet werden Softwarefehler bei der Datenkomprimierung f hren zu zus tzlichen Arbeiten Hauptspeicher nicht ausreichend Verz gerungen bei der Hardwarelieferung verursacht Zeit berschreitungen Le
173. n Was kann nun noch schief gehen Wir denken eine ganzen Menge Die Frage ist jetzt zu welchem Zeitpunkt oder bei welchem Ereignis l uft das Projekt aus dem Ruder und was k nnen Sie dagegen unternehmen M gliche Risiken herauszufinden diese zu analysieren und entsprechend zu Handeln und gegenzusteuern ist die beste Waffe gegen m gliche Projektkatastrophen Wenn Sie Ihren Projektplan auf m gliche potentielle Probleme hin untersuchen und endsprechende Gegenstrategien und Vorgehensweisen f r diese m glichen Probleme entwickeln erh hen Sie die Chance auf ein erfolgreiches wenn nicht sogar perfektes Projekt dramatisch Was ist eine Risiko Ein Risiko beschreibt die M glichkeit dass eine Aktivit t einen k rperlichen oder materiellen Verlust oder Schaden zur Folge hat Von Risiko spricht man nur dann wenn die Folgen ungewiss sind Anders ausgedr ckt ein Risiko ist ein potentielles Problem Ein Problem ist ein Risiko das eingetreten ist Risikomanagement und Controlling RMC Das Thema Risikomanagement und Controlling wird in Unternehmen bisher nur unter zwei Gesichtspunkten diskutiert und betrachtet e Die IT Security dient der Abwehr unmittelbarer Bedrohungen wie Hacker oder Viren e Die Risikobetrachtung erfolgt im Rahmen des eines gesetzlich vorgeschriebenen Minimums Beides hat mit Risikomanagement und Controlling eines Projektes als unternehmerische Projektleitungsfunktion nur wenig zu tun Risikomanagement un
174. n zumindest nicht immer noch sich darauf st tzen sollte Projektmanagement muss als Teamarbeit verstanden werden und auch der Projektleiter ist Mitglied dieses Teams W hrend auf die mit der Projektmanagement Methodik verbundenen Aufgaben des Projektmanagers in diesem Buch noch mehrfach eingegangen wird soll hier nur noch einmal kurz auf den Aspekt der Motivation eingegangen werden Betrachtet man die Durchf hrung von Projekten in verschiedenen Unternehmenskulturen so werden dort gro e Unterschiede deutlich W hrend gerade in gro en deutschen Unternehmen die Projektarbeit h ufig sehr n chtern erfolgt wird auf den Teamgeist in manchen amerikanischen aber nicht nur diesen Unternehmen sehr viel mehr Wert gelegt Auch wenn man ber die Ausw chse einer T Shirt Kultur zu jedem Projekt geh rt mindestens eines oder den Spitznamen Mom f r den Projektleiter l cheln mag der Teamgeist ist da M glich gemacht wird vieles durch die Bereitstellung von kleinen Budgets f r Incentives innerhalb des Projekts vor allem aber durch das Verst ndnis dass der Erfolg des Projekts nicht der Erfolg eines einzelnen ist Projektmanager m ssen daher versuchen einen kooperativen F hrungsstil zu entwickeln Dieser l sst sich trainieren Voraussetzung ist allerdings auch dass die Mitarbeiter im Projekt ebenfalls mit der Einstellung arbeiten das Projekt vor ihren pers nlichen Erfolg zu stellen 5 6 9Qualifikationen von Mitarbeitern im Pr
175. n den Phasen Definition von Kontrollpunkten und Reviews Aufteilung des Projekts in berschaubarere Bl cke Alle gr eren Institutionen bei denen Projekte von gr erer Bedeutung sind verf gen ber eigene Varianten solcher Phasenkonzepte Damit wird eine Vereinheitlichung der Projektarbeit ebenso erreicht wie sichergestellt wird dass in bestimmten Situationen eine berpr fung des Projektstatus erfolgt Auch f r Ihr Unternehmen ist es sinnvoll ein einheitliches Phasenmodell zu definieren um einheitliche Projektstrukturen zu erhalten Das Phasenmodell das von uns f r die Beschreibung gew hlt wurde ist leicht auf andere Modelle zu bertragen und hat folgende Form Leitfaden Projektmanagement Q Office 2 Heip Inhalt Problemerkennung grobe Zieldefinition Initialisierung des Projekts Konzeptphase Zielverfeinerung Machbarkeitsstudie Alternativensuche Bewertungskriterien Grobplanung abschlie end Definition eines Pflichtenhefts Schnittstellen Abh ngigkeiten Feinplanung auf Basis der entwickelten Definitionen Entwicklungsphase Detailentwicklung Pl ne f r Produktion und Test Detaillierung der Planung Fertigungsphase Produktion und Test Installationsphase Auslieferung und Inbetriebnahme Betriebsphase Betrieb und Wartung Tabelle 1 Projektphasen Parallel dazu lassen sich auch Phasen unterscheiden welche die wesentlichen Aufgaben des Projektmanagers aufzeigen Problemphase Zieldefinition Konzeptph
176. n folgenden Punkten beginnen sollten a Nehmen Sie die Aufgabenliste und den zeitlichen Ablauf unter die Lupe b F hren Sie einen regen Gedankenaustausch Brainstorming mit Experten 1 Untersuchung der Aufgabenliste und des zeitlichen Ablaufs Ziehen Sie Ihren Projektplan zu rate betrachten Sie als erstes die Aufgaben im kritischen Pfad danach die Aufgaben nahe dem kritischen Pfad und schlie lich die Aufgaben die als nichtkritisch eingestuft wurden Legen Sie besonderes Augenmerk auf e Aufgaben f r die Ihr Team ber keine Erfahrungen oder kein Wissen verf gt Die zeitliche Dauer f r diese Aufgaben und die damit verbundenen Kosten sind mit sehr gro er wahrscheinlich nicht richtig eingesch tzt e Sch tzungen von Zeit und Kosten im Besonderen dann wenn das Budget sehr knapp kalkuliert ist Sprechen sie mit den Sch tzern und fragen Sie diese wie viel Vertrauen Sie in diese ihre Leitfaden Projektmanagement Q Office 2 Heip Sch tzungen haben Tun Sie dies speziell f r Aufgaben im kritischen Pfad e Situationen bei denen Sie nur ber eine begrenzte Anzahl von Ressourcen f r spezifische Aufgaben verf gen und diese Ressourcen bereits zu 100 verplant sind berplant sind oder wo sich nicht sicher sind die Ressourcen berhaupt zu bekommen Ressourcen k nnen wegfallen durch K ndigungen oder sie werden innerhalb der Organisation in andere Bereiche versetzt e Aufgaben die auf eine ganze Reihe von Vorbedingungen
177. nagement Situationsanalyse Zielformulierung Konzept Synthese Konzept Analyse Bewertung Entscheidung Projektplanung und steuerung Projektorganisation Kategorie Methode Technik Zielformulierung Operationalisierung Ziel Mittel Denken Relevanzbaum x x X Xx Xx x x Kreativit t Analogiemethode Brainstorming K rtchentechnik Methode 635 Morphologie Synektik 00 000 o XxX Xx X XXX Analyse ABC Analyse Entscheidungstabellen Wertanalyse Katasthrophen Analyse Sensibilit ts Analyse Sicherheits Analyse Checklistentechnik o o o O X X X o oX X XX X o Bewertung Entscheidung Investionsrechnung Wirtschaftlichkeitsrechnung Kosten Nutzen Analyse Kosten Wirksamkeits Analyse Nutzwertanalyse Entscheidungsbaum Verfahren o o ojojojojojo O XXX xx Optimierungsverfahren Lineare Optimierung Simplex Methode Nicht Lineare Optimierung Dynamische Optimierung Reihenfolge Probleme Simulationstechnik Monte Carlo Methode o Warteschlange Modelle o Zuteilungsprobleme Konkurenzprobleme Spieltheorie o Ersatzprobleme o Branch and Bound ojojojojojojojojojo ojojojojojojojojojo Projektmanagement Balkendiagramme Netzplantechnik Termintrend Diagramme Zeit Kosten Forschritts Diagramme Funktions Diagramme x Projekt Organisationsmethode Koordinierunginstrumentarien x x XX X X x Seite 188 Leitfaden Projektmanagement Q Office 2 Heip 19 5Erhebungsmethoden Erhebungs Bei der Durchf hrung der
178. ndern oder eine bestimmte Art von Projekten konzipiert wurden So entpuppte sich das Wasserfall Modell ziemlich schnell als untauglich bei gr eren Projekten mit l ngerer Laufzeit Auch das V Modell in seiner ersten Version V Modell 92 hatte ziemlich schnell den Ruf weg in erster Linie berfl ssige Papierberge zu erzeugen und die Projektkosten durch unsinnige Aktivit ten in die H he zu treiben Daher wurden diese Modelle bei gr eren Projekten entweder nicht mehr eingesetzt Wasserfallmodell oder den neuen Anforderungen angepasst V Modell 97 Bereits an dieser Stelle soll darauf hingewiesen werden dass sich das Seite 95 Prozessmodelle regeln den gesamten Prozess der Software Entwicklung Leitfaden Projektmanagement Q Office 2 Heip Seite 96 Wasserfall Modell f r gewisse Projekte durchaus eignet Mehr dazu in den folgenden Abschnitten Alle Modelle der Vergangenheit hatten jedoch einen entscheidenden Nachteil Sie lagen nur in Papierform vor und mussten vom Anwender quasi als Nachschlagewerk eingesetzt werden Hier stellt der Rational Unified Process eine Ausnahme dar da er direkt in den Projektablauf integrierbar ist F r ihn existiert eine sogenannte Online Version Anforderungen Entwicklung Microsoft Visual Studio Robot ReaquisitePro Rose Anforderungen Modelle Testscripte Abbildung 16 RUP Prozess In der Online Version des RUP hat der Anwender die M glichkeit mi
179. nehmer oder besser gesagt Anwenderseite Seine Anpassbarkeit wurde extrem flexibel gehalten Das hat den Vorteil dass der Anwender ihn nahezu auf alle unternehmensspezifischen Gegebenheiten anpassen kann Auf der anderen Seite wird durch das fehlen von Vorschriften vom Anwender eine wesentlich intensivere Auseinandersetzung mit dem Prozess erwartet da er alles m gliche hinzuf gen oder weglassen kann 12 9Die Bedeutung von Prozessmodellen f r das Projektmanagement Mit der Einf hrung vom Prozessmodellen erh lt auch das Projektmanagement eine neue Bedeutung Doch was ist eigentlich das Interessante am Projektmanagement Nun sicherlich die verschiedene Auspr gungen welche die Rolle eines Projektmanagers inne hat So ist zum Beispiel bei einem Kleinstprojekt der Projektmager Analytiker Designer Entwickler Tester und eben der Projektleiter alle in einem schlie lich handelt es sich um ein Ein Mann Projekt Hingegen wird bei einem 100 Mann Projekt der Projektleiter fern ab von irgendwelchen T tigkeiten im Bereich Analyse Design oder gar Entwicklung sein Hier wird er allenfalls beratend zum Einsatz kommen wenn er mit seinem Wissen einem unerfahrenen neuem Mitarbeiter zur Seite steht blicherweise verl uft die Karriere eines Projektmanagers leiters auf dem Weg vom Ein Mann Projekt ber 20 Mann Projekte bis hin zum Gro projekt Professionelle Unternehmen lassen zuk nftige Projektleiter erst einmal die Rolle der Projektassistenz in einem
180. nen 8 Stunden Tag h lt also um 9 00 Vormittags kommt und sp testens um 5 00 Nachmittags wieder geht Leitfaden Projektmanagement 10 1 8Unklare Anforderungen Wissen Sie zu Projektbeginn was Ihr Kunde wirklich will Oder pr ziser Wissen Sie was Ihr potentieller Kunde durch eine Ver u erung seiner Ausschreibung will Haben Sie sich schon mal berlegt was Ihr Kunde oder auch zuk nftiger Kunde eigentlich mit einer Anforderung ausdr ckt Eigentlich den Wunsch wie sich seine zuk nftige L sung verhalten soll Was programmiert wird Wade Po kmanayse ergibt a We fe Programm kationen zum Lenbach wid Was der Anwender elgentich haben wollte Abbildung 14 Unklare Anforderungen Doch wann u ert er diesen Wunsch nun ganz einfach wenn er entsteht Wann reagieren Sie dann wenn Sie von dem Wunsch wissen Und wann k nnen Sie diesem Kunden eine L sung anbieten erst nachdem Sie einen Auftrag erhalten haben seine Anforderungen umgesetzt haben und letztlich das lang erwartete Ergebnis liefern Wenn sie zu den kritischen Zeitgenossen unserer Zeit geh ren werden Sie sicherlich ein Feedback erwarten oder vielleicht bef rchten Das w rde der Wahrheit wesentlich n her kommen denn das was Sie abgeliefert haben entspricht eventuell den Anforderungen die der Kunde am Beginn des Projektes an Sie hatte doch mit den aktuellen Anforderungen hat Ihr abgeliefertes Produkt meist nicht mehr viel zu
181. nisieren oder an einem Industrieprojekt mitarbeiten Sie werden feststellen dass sich jedes Projekt hnlich wie in der Natur in Stufen beziehungsweise Lebensphasen entwickelt Aufgrund ihrer Komplexit t und Ihrer Neuartigkeit sind Projekte nach einer systematischen Vorgehensweise abzuwickeln Dieser Vorgehensweg wird durch drei Grundprinzipien bestimmt e Strukturierung in Phasen e vom Groben zum Detail e Probleml sungszyklus Die Strukturierung eines Projekts ist die Basis f r den Projekterfolg Nur bei klar strukturierten Projekten k nnen Sie die Komplexit t des Gesamtsystems berschauen 5 7 5Keine Angst vor dem PC Viele Projektleiter haben Schwierigkeiten beim Umgang mit der Tastatur Dadurch wird die Zusammenarbeit ber Computer abgelehnt Das haben wir immer so gemacht und hnliche Argumente dienen dann dazu die eigenen Probleme mit der EDV zu vertuschen Fehlt das Vertrauensverh ltnis zu den Abteilungs Gruppenleitern und Inhabern k nnen Sie nicht erwarten korrekte Werte und R ckmeldungen zu erhalten Da jeder Mitarbeiter versucht eigene Schwierigkeiten anderen anzulasten oder auf andere Projekte abzuw lzen wird die Kalkulation und R ckmeldung tats chlich zu einem L genzettel Seite 43 Leitfaden Projektmanagement Q Office 2 Heip Seite 44 Notwendig ist ein offener Austausch der Informationen so dass R ckmeldungen ber Schwierigkeiten m glichst fr h eintreffen Wenn Sie Uberschreitun
182. nnen In diesem Auftrag wird generell ausgesagt was die Anwendung k nnen soll und was sie ausdr cklich nicht k nnen muss Der Auftrag eines Projektes muss mindestens folgende Punkte enthalten Projektziele und aufgaben Problembeschreibung Aufgabenstellung Abgrenzung der Aufgabenstellung Geplanter Projektbeginn geplantes Projektende Projektbeteiligte Rahmenbedingungen Kostenrahmen Nutzen Die Angaben zum Kostenrahmen und zum Nutzen k nnen zu diesem Zeitpunkt nur auf grober Sch tzung beruhen und erste Anhaltspunkte sein Genauere Angaben Zahlen m ssen mit zunehmendem Projektfortschritt detailliert werden Seite 75 Projektausl ser Projektidee Projektauftrag Leitfaden Projektmanagement Q Office 2 Heip Konstituierende Sitzung Ziele und Ergebnisse der konstituieren den Sitzung Seite 76 Da jedes Projekt i d R auch umfangreiche Finanzmittel ben tigt ist das Projekt aus Unternehmenssicht auch ein Finanzvorhaben Hinweise Der bergang vom Kostenrahmen zum geforderten Finanzierungsplan erfolgt durch Detaillierung Aufstellen von Kostenvoranschl gen Die Bewilligung und Zuteilung der Ressourcen erfolgt durch das zust ndige Controlling Es ist darauf zu achten das vor Projektbeginn die Teammitglieder entsprechend den Qualifikationsanforderungen geschult und so auf ihre Aufgaben im Projekt vorbereitet werden Der Start bzw die Nichtzulassung von Projekten erfolgt durch eine konstituierende
183. nt Aufgabe des Multiprojektmanagements ist es mehrere Einzelprojekte so zu koordinieren z B hinsichtlich der ben tigten Ressourcen dass das Gesamtergebnis aller Projekte hinsichtlich der Unternehmenzsziele ein Optimum ergibt Netzplan Graphische Darstellung der Abh ngigkeiten zwischen Arbeitspaketen also der Vorgehensweise bei der Projektabwicklung Netzplantechnik Rechenmethode zur Ermittlung der fr hestens m glichen sowie sp testens notwendigen Anfangs und Endzeitpunkte der Arbeitspakete Leitfaden Projektmanagement Q Office 2 Heip Normalfolge Anordnungsbeziehung vom Ende eines Arbeitspaketes zum Anfang seines Nachfolgers d h mit Arbeitspaket B kann erst begonnen werden wenn Arbeitspaket A abgeschlossen ist Personaleinsatz Intensit t mit der eine Ressource ein Arbeitspaketes abarbeitet Ist der Personaleinsatz hoch ergibt sich eine kurze Bearbeitungsdauer und umgekehrt Einheit Prozent oder Personenstunden Tag Phasenmodell Standardisierter Projektstrukturplan der in zeitlich voneinander abh ngige Abschnitte gegliedert ist Diese k nnen sequentiell aufeinander folgen oder sich berlappen Beispiel Analyse Konzept Entwicklung Realisierung Test Projekt Vorhaben das folgende Kriterien erf llt Einmaligkeit keine Routinet tigkeit eindeutige Zielvorgabe zeitliche finanzielle personelle oder andere Begrenzungen hohe Komplexit t Indikatoren Aufwand Anzahl an beteiligten Abt
184. nterdisziplin re Zusammensetzung Zusammensetzung eines Projektteams aus Mitarbeitern unterschiedlicher Bereiche eines Unternehmens um deren unterschiedliche menschliche und fachliche St rken zum Erreichen des Projektziels zu nutzen Kapazit tsbedarf Ressourcenbedarf Bedarf an Personal das f r die Abarbeitung der Arbeitspakete eines Projektes n tig ist ermittelt aus dem gesch tzten Aufwand und der Zeitrechnung des Netzplans Kapazit tsplanung Namentliche und quantitative Zuordnung der ausf hrenden Kapazit t en Ressourcen zu jedem einzelnen f r das Projekt notwendige Arbeitspaket unter Ber cksichtigung der Aufwandssch tzung Kapazit tstreue Einsatzplanung Zeitplanung unter Ber cksichtigung der max Verf gbarkeit der ausf hrenden Ressourcen Kernteam Projektteam Projektmitarbeiterr die zusammen mit dem Projektleiter f r die Projektdurchf hrung verantwortlich sind Kick Off Sitzung Projekt Kick Off Erstes Treffen von Projektleiter und Projektteam zur Initialisierung eines Projektes Dabei werden der Projektauftrag Projektziele inhalte termine und deren Rahmenbedingungen diskutiert die Teammitglieder miteinander bekannt gemacht sowie die weitere Vorgehensweise beschlossen Seite 199 Leitfaden Projektmanagement To Office 2 Heip Seite 200 Kreativit tstechniken Methoden zur Anregung der Kreativit t bei der Erarbeitung neuartiger Probleml sungsans tze Kritischer Weg Alle Arbeitspak
185. nternehmen gestellt werden 8 2 4Projektleiter Der Projektleiter hat die Verantwortung f r das Projekt und kann selbst ndig Entscheidungen im Rahmen seiner Kompetenzen treffen Generelle Rechte und Pflichten des Projektleiters sind nachfolgend dargestellt Diese k nnen durch das Review Board Lenkungskreis eingeschr nkt oder erweitert werden Der Projektleiter ist verantwortlich f r die Erreichung der Projektziele Leitung einer klar definierten zeitlich begrenzten Aufgabe Korrekte Einhaltung aller vorgegebenen Projektziele Planung und berwachung des Projektes nach Umfang Inhalt und Mitteln Koordination aller Funktionen und Bereiche soweit am Projekt beteiligt schnelle fachliche Entscheidungen herbeif hren umgehende Einleitung von Ma nahmen im Problemfall Sicherstellung der Beachtung der Methoden und Richtlinien Sicherung der Qualit t des Produktes Motivation der Projektmitarbeiter Sicherstellung der Information zum Management zu den beteiligten Bereichen zum Projektteam e Sicherstellen notwendiger Beteiligungen Datenmanagement Betriebsf hrung Betriebsrat Datenschutzbeauftragter e Loyalit t gegen ber dem Auftraggeber eigene und die der Mitarbeiter e Sicherstellung vollst ndiger und aktualisierter Dokumentationen e Ordnungsgem e Beendigung des Projektes Dem Projektleiter stehen folgende Rechte zu Mitsprache bei der Auswahl der Projektmitarbeiter Beurteilung der Mitarbeiter Mitwirkung hinsichtl
186. nternehmens lassen sich eine F lle unterschiedlicher Formen unterscheiden Auch heute ist in vielen Unternehmen und Beh rden die Projektarbeit schlicht noch nicht explizit Seite 35 Leitfaden Projektmanagement Q Office 2 Heip Seite 36 vorgesehen Sie findet einfach statt und wird in der Regel auch toleriert h ufig sogar gef rdert Klare Regelungen f r ihre Integration in die Unternehmensorganisation und damit der Aufbau einer Projektorganisation und die F rderung einer Projektkultur fehlen aber Wenn das Projektmanagement dagegen bewusst in die Unternehmensorganisation eingebunden wird lassen sich insbesondere die Formen e Reine Projektorganisation e Einfluss Projektorganisation e Matrix Projektorganisation unterscheiden Bei der reinen Projektorganisation werden die Projektteilnehmer aus ihren Linienfunktionen ausgegliedert Die Projekte stehen isoliert von der herk mmlichen Organisation Der Unterschied zur Linie besteht rein in der zeitlichen Befristung dieser Organisationseinheiten Die reine Projektorganisation bietet sich insbesondere dann an wenn das Projekt von besonderer Bedeutung f r das Unternehmen ist und sich ber lange mehrj hrige Zeitr ume erstreckt Abbildung 4 Klassische Struktur einer Projektorganisation Die Einfluss Projektorganisation ist die loseste Form einer Projektorganisation bei der die Mitarbeiter weiterhin in der Linie arbeiten und nur einen Teil ihrer Zeit im Projekt verbringen In
187. nwert des Projektmanagements im Unternehmen abh ngt Die Strukturen innerhalb des Projekts k nnen sich nur an dem Rahmen orientieren der f r das Projektmanagement im Unternehmen insgesamt gesetzt ist So sind beispielsweise die personellen Handlungsspielr ume von Projektmanager durch die Projektkultur des Unternehmens als Ganzes wesentlich beeinflusst Seite 31 Leitfaden Projektmanagement To Office 2 Heip Seite 32 5 6 4Der Auftraggeber Eine besonders wichtige Funktion im Projekt nimmt der Auftraggeber ein Dabei kann es sich um die Gesch ftsleitung oder einen im Unternehmen an entsprechend hoher hierarchischer Stelle angesiedelten Mitarbeiter handeln Dieser Auftraggeber besitzt f r das Projekt insbesondere deshalb eine herausragende Bedeutung weil er es eben nicht nur initiiert sondern auch der Sponsor des Projekts ist In vielen Unternehmen gibt es Projekt oder F hrungskreise deren Aufgabe es ist neben der offiziellen Auftragerteilung insbesondere das Sponsoring des Projekts die R ckendeckung f r das Projekt sicherzustellen Ohne einen Auftraggeber oder Sponsor l sst sich ein Projekt kaum erfolgreich durchf hren Denn dieser gibt dem Projektmanager die R ckendeckung bei Problemen im Projekt und bei Konflikten mit anderen Bereichen des Unternehmens Sich die erforderliche Unterst tzung zu sichern ist eine der wichtigsten Voraussetzungen f r erfolgreiches Projektmanagement Viele Projekte lassen sich sinnvoll nu
188. oblemsituationen die Anlaufstation und die Entscheidungsinstanz f r den Projektleiter darstellt Die Einberufung von Review Board Sitzungen kann durch den Projektleiter oder auf Initiative von Mitgliedern des Review Boards erfolgen e Dem Review Board geh ren folgende Mitglieder an Als st ndiger Vertreter o die Vertretung der Konzermleitung o das Management der betroffenen Bereiche Betriebsrat und oder der beteiligte oder betroffene Leiter IT o der Projektleiter nur als berichtendes Mitglied e Die st ndigen Vertreter m ssen die notwendige fachliche und finanzielle Kompetenz besitzen und sind diesbez glich mit allen Vollmachten ausgestattet o Aufgaben des Review Boards sind u a o berwachung des Projektes in gro em Rahmen sachlich technisch fachlich finanziell terminlich usw Seite 175 Leitfaden Projektmanagement Q Office 2 Heip Seite 176 Kontrolle der Einhaltung der vorgegebenen Ziele Festlegung der Priorit ten Einhaltung der Priorit ten berwachen schnelle Entscheidungen treffen bei sachlichen personellen finanziellen und terminlichen Problemen Schaffung von Grundlagen zur Behebung der Probleme sachliche und finanzielle Freigabe der Projektphasen o Protokollierung der Sitzung O OOO O O Aufgaben des Projektleiters sind u a e Sicherstellung der vollst ndigen Erledigung des Auftrages e Einhaltung der Zielsetzung sicherstellen e Planung Kontrolle und Steuerung des Projektes Aufgabenve
189. oden 17 4 2Spezielle SE Methoden Im Rahmen des Vorgehensmodells werden innerhalb der Produktnormen PN Spezielle SE Methoden empfohlen die sich f r die Erarbeitung der vorgesehenen Methoden Ergebnistypen bew hrt haben Die w hrend der Anwendungsentwicklung eingesetzte Methode f r die Datenmodellierung ist die Informationsstrukturanalyse ISA f r die Funktionsmodellierung die Funktionsstrukturanalyse FSA Im Rahmen der objektorientierten Entwicklung wird zur Klassenmodellierung eine Kombination aus einschl gigen in der Literatur genannten Methoden eingesetzt da sich in diesem Bereich bisher noch keine Methode als allgemeing ltige etabliert hat jedoch ist erkennbar dass die derzeit noch unterschiedlichen Methoden sich in Richtung einer einheitlichen Methodik entwickeln werden 17 4 3Aufwandssch tzung Bedeutung Aufwandssch tzung f r die Produktentwicklung und dem mit ihr verbundenen Einfluss auf Entscheidungen des Managements in bezug auf Personal Termin und Kostenplanung erh lt eine immer h here Bedeutung Sch tzen ist detailliertes Besch ftigen mit den Aktivit ten eines Projektes bzw einer Projektphase und der zeitlichen und finanziellen Bewertung dieser Aktivit ten unter der Annahme ganz bestimmter definierter Voraussetzungen und unter Ber cksichtigung aller im Augenblick erkennbaren Beeintr chtigungen von au en und innen Sch tzungen erfolgen auf der Basis des Projektauftrages und unter Annahme Rand be
190. oehm Das Spiralmodell erlaubt die Kombination bereits existierender Ans tze unter st ndiger Kontrolle des Managements Es integriert mehrere der St rken von anderen Modellen und l st mehrere der Schwierigkeiten bzw Schw chen dieser Modelle Im Spiralmodell wird der Software Entwicklungsprozess als iterativer Prozess verstanden Festlegung von Zielen Alternativen und Rahmenbedingungen Evaluierung der Alternativen Erkennen und Reduktion von Risiken Realisierung und berpr fung des Zwischenprodukts Planung und Projektfortsetzung Initialisierung bzw Beenden der Spirale Leitfaden Projektmanagement _ ea schrittweises Vorgehen Evaluierung der Alter nativen Identifizierung und berwindung der Risiken Ziele Alternativen und Randbedingungen identifizieren f r jedes Teilprodukt Risikoanalyse RA Risikoanalyse RA Risikoanalyse RA Einverst ndnis ber n chsten Zyklus herstellen berpr fung review A Prototyp Prototyp Prototyp system Simulationen Modelle Vergleiche Anforderungsplan Vorgehens 1 benchmark Lebenszyklusplan konzept Detail Entwurf Software Produkt Entwurf Software Anforder ungen Entwicklungs Validation der plan Anforder ungen Integration Validation und und Testplan Verifikation des Entwurfs Integration und Test Abnahme test
191. ojects with PRINCE2 ISBN 0113308914 Projektmanagementmethode http de wikipedia org wiki PRINCE2 The Stationery Office Tailoring PRINCE2 ISBN 0113308973 How to adapt PRINCE2 to your particular situation PRINCE2 Projektmanagement mit Methode ISBN 3827325420 M rz 2007 Leitfaden Projektmanagement Q Office 2 Heip 21 4Auftraggeberinterne Literatur und Richtlinien Seite 208 Leitfaden Projektmanagement Q Office 2 Heip 22Der Autor Rainer Curth Der Schwerpunkt des Autors Rainer Curth umfasst sowohl das klassische Management das Projektmanagement im Dienstleistungs und Industriebereich als auch die besonderen Anforderungen beim Projekt Qualit ts Management gro er Enterprise Softwareprojekte Rainer Curth ist auch Autor der B cher Handbuch Software Qualit tssicherung und Projektmanagement die jeweils einen themen und praxisbezogene Leitfaden darstellen Seite 209 Leitfaden Projektmanagement Q Office 2 Heip 23Buchr ckseite Moderne Betriebssystem Softwarearchitekturen und Entwicklungswerkzeuge erlauben es Softwareentwicklern sehr schnell neue Anwendungen zu erstellen Oft kommt jedoch nach der ersten Euphorie Katerstimmung auf denn nur zu oft gleiten solche Projekte aus den H nden der Auftraggeber und des Managements da grundlegende Projekt und Qualit tsans tze nicht beachtet wurden Dieses Buch verfolgt den Ansatz Management Entscheidern und Entwicklern gleicherma en e
192. ojekt Erfolgreiche Projektarbeit setzt geeignete und damit ausreichend qualifizierte Mitarbeiter voraus Vor dem Beginn der Projektarbeit m ssen daher sowohl Projektleiter als auch Projektmitarbeiter auf ihre neuen Aufgaben vorbereitet werden Die ben tigten Kenntnisse umfassen e Projektmanagement Methodik e Umgang mit Projektmanagement Werkzeugen e Training im Bereich Teamarbeit und Teamf higkeit F r die Projektmanager sind dar ber hinaus e F hrungstechnik Leitfaden Projektmanagement Q Office 2 Heip e Motivation e Moderation von besonderer Bedeutung um ein Projekt erfolgreich f hren zu k nnen Wie oben bereits ausgef hrt wurde muss das Hauptaugenmerk in diesem Zusammenhang der Entwicklung eines offenen kooperativen F hrungsverhaltens gelten Projekte k nnen nicht durchgef hrt werden wenn nicht alle Mitarbeiter die erforderlichen Kenntnisse ber das Projektmanagement besitzen 5 7Die zehn wichtigsten Regeln f r erfolgreiches Projektmanagement Erfolgreiches Projektmanagement ist nicht nur die Anwendung von Regeln Erfolgreiches Projektmanagement setzt sowohl das richtige Verst ndnis f r das Projekt als auch den sinnvollen Umgang mit den Werkzeugen voraus Die zehn wichtigsten Regeln f r erfolgreiches Projektmanagement finden Sie auf den n chsten Seiten 5 7 1 1Lernen Sie aus der Systemtheorie Unter einem System versteht man eine gegen ber der Umwelt abgegrenzte Ganzheit die aus einzelnen Elementen
193. on unterschiedlichen Herstellern auf So wird der Projektleiter durch die Vielzahl zu verwaltenden Versionen aus unterschiedlichen Herstellerquellen erheblich belastet Seite 83 Q Office 2 Heip Ein Projekt ohne gute Kommunikation der Projekt beteiligten scheitert Ein Projekt ben tigt eine Vielzahl von Unterst tzungs Werkzeugen die jedoch miteinander kommunizieren m ssen Leitfaden Projektmanagement Q Office 2 Heip Die Schnittstellen zwischen Werkzeugen sind problematisch Seite 84 Beispiel Es kommen in einem Projekt folgende Werkzeuge zum Einsatz Konfigurationsmanagement CASE Tool Anforderungsmanagement Werkzeug Testwerkzeug f r Black box Tests Testwerkzeug f r White box Tests Projektmanagement Werkzeug Dokumentationswerkzeug Geht man jetzt davon aus dass jedes der Werkzeuge einmal im Jahr mit einem neuen Release auf den Markt kommt so hat der Projektleiter insgesamt 7 Releasewechsel im Jahr vor sich Abgesehen von diesem Aufwand m ssen auch die Ausfallzeiten ber cksichtigt werden die durch diese Releaseumstellung hervorgerufen wurden Ein weiterer negativer Aspekt ist die Tatsache dass bei einem Releasewechsel meist die Schnittstelle falls berhaupt existent zu den anderen im Projekt eingesetzten Werkzeugen berarbeitet werden muss Wie bereits gesagt die Verwendung von Werkzeugen ist in einem modernen Softwareentwicklungsprozess unabdingbar doch es gelten die folgenden Zusammenh
194. onst ist es heute in vielen Unternehmen so dass die erfolgreiche Durchf hrung eines gro en Projekts ein Sprungbrett f r die weitere Karriere ist Projektmanagement besch ftigt sich daher auch nicht nur mit Netzpl nen oder der Verwaltung irgendwelcher kleiner Teilaufgaben Es ist auch nicht nur die sture Anwendung vorgegebener Methoden die in mehreren Leitz Ordnern niedergeschrieben sind Die entscheidende Herausforderung beim Projektmanagement ist die Arbeit mit und in Projektgruppen die L sung von Problemen zwischen den Projektbeteiligten und Zulieferern und die L sung von entstehenden Konflikten Seite 17 Leitfaden Projektmanagement Q Office 2 Heip Seite 18 5 4Grunds tze der Projektarbeit Im Rahmen eines Projektes oder einer Projektarbeit gibt es eine ganze Menge zu beachten Dies gilt sowohl f r fachlichen und administrativen als auch f r den menschlichen und zwischenmenschlichen Bereich Als Projektleiter und Projektverantwortlicher ist es Ihr Aufgabe und Verpflichtung die Voraussetzungen f r diese Regeln zu schaffen und herbeizuf hren als auch diese Regeln Gebote zu etablieren und vorzuleben 5 4 1Die Grundregeln der Projektarbeit Grundregeln Wahrheit e es wird nichts besch nigt e es wird nichts verschwiegen Vertrauen e Zusagen werden eingehalten e Information ist eine Bringschuld Klarheit e jeder wei was er zu tun hat e jeder wei wie er es zu tun hat Einfachheit e keine unn tigen Reg
195. op 10 Metriken der industriellen Software Entwicklung Eine Vielzahl von Ursachen Seite 92 Jede der oben aufgef hrten Testarten kann mit einem Regressionstest erneut durchgef hrt werden Typischerweise werden bei einer iterativen Vorgehensweise nach jeder Iteration eines Testdurchlaufes Regressionstests f r jede Testart vorgenommen Das Testmodell stellt dar was getestet werden soll Es beinhaltet eine Auflistung aller Testf lle Testprozeduren Testscripten und der erwarteten Ergebnisse sowie eine Beschreibung der untereinander bestehenden Beziehungen 10 1 20Nichtbeachtung der 80 20 Regel Bereits 1987 stellte Barry Boehm Boehm87 eine bersicht auf die als Top 10 Metriken industrieller Softwareentwicklung bekannt wurde Eine dieser Metriken umfasst die 80 20 Regel Pareto Zeitprinzip die folgende Aspekte bedeuten Definition Diese Regel besagt dass mit 20 des maximalen Aufwandes bereits 80 des maximal M glichen erreicht wird Somit verursachen die letzten 20 des Aufwandes 80 der Kosten 80 des Engineeerings werden f r 20 der Anforderungen ben tigt 80 der Gesamtkosten werden f r 20 der Komponenten ausgegeben 80 der Fehler werden durch 20 der Komponenten verursacht 80 der Ressourcen werden f r 20 der Komponenten verbraucht 80 des Projektfortschritts werden von 20 der Mitarbeiter erzielt 80 des Engineerings wird von 20 der Tools durchgef hrt D e DN a Diese 80 20 Regel gilt nat
196. ormationsverarbeitung e bearbeitet dabei ein definiertes Aufgabengebiet in der Informationsverarbeitung Beratungs Planungs Konzeptions und Realisierungsaufgaben e hat die fachliche Leitung von Projekten mit definiertem Komplexit tsgrad Er Sie tr gt in definiertem Ma e Verantwortung f r e die Arbeitsinhalte und die Zieldefinitionen der Aufgabengebiete des Projektes e die Erarbeitung von L sungen f r die Informationsverarbeitung und f r die Fachabteilung Eine Kontrolle der Arbeiten erfolgt anhand des Zielerreichungsgrades Die Entscheidungsbefugnis ist projektbezogen definiert Er Sie ben tigt folgende Qualifikationen Qualifikationen Analytische und konzeptionelle F higkeiten definierter Tiefe und Komplexit t Berufserfahrung definierter L nge und Erfahrungstiefe in einer IS Funktion oder auf einem anwendungsbezogenen Arbeitsgebiet Dazu z hlt insbesondere F hren von Mitarbeitern Organisieren von Arbeit Arbeiten mit DV berwachen von Pl nen Pr sentieren Spezialwissen in definiertem Umfang z B Projektsteuerungstechniken zu benutzen Kommunikationstechniken eine Gruppe zu leiten Entscheidungen zu treffen Beherrschen der Methoden und Techniken des eigenen Fachgebietes insbesondere DV Produkte und Anwendungen Programmiersprachen Planungsmethoden Kenntnisse von IS Entwicklungen und Anwendungsarchitekturen Definierte F higkeiten der englischen Sprache und ggf einer weiteren Fremdsprache Seite 18
197. ozessmodell einzusetzen ist wobei dies hier aus dem Blickwinkel des Projektteams und der Projektart vorgenommen wird e Projektteam o Gro es Team o Auf unterschiedliche Standorte verteiltes Projektteam o International verteiltes Team o Heterogenes Projektteam sowohl sehr erfahrene als auch recht neue Mitarbeiter Projektteam das sich aus Mitarbeitern unterschiedlicher Unternehmen Abteilungen zusammensetzt o Projektteam in das Mitarbeiter des Auftraggebers involviert sind e Projektart o Entwicklung einer Standardsoftware Produkt o Mittleres oder gr eres Projekt Projektdauer l nger als 3 Monate o Kritisches Projekt o Hoher Modellierungsaufwand im Vorfeld trifft z B bei Datenbankanwendungen zu o Projekte die einer l ngeren Gew hrleistung unterliegen O Entscheidend dabei ist dass wenn einmal ein Prozessmodell eingef hrt wurde ab dann auch alle k nftigen Projekte nach diesem Modell abgewickelt werden sollen Man h rt oft das Vorurteil dass die Verwendung von Prozessmodellen teuer sei bzw teurer als wenn man ohne Prozessmodell arbeitet Sicherlich ist der Mehraufwand der durch die Verwendung eines Prozessmodells entsteht vorhanden Setzt man ihn jedoch dem Wartungsaufwand bei einem Projekt entgegen dass ohne Prozessmodell angewickelt wurde so sieht das Nutzen Kostenverh ltnis schon ganz anders aus Generell sollte auch ber cksichtigt werden dass Prozessmodelle nicht von heute auf morgen eingef hr
198. plinen Einige Disziplinen nicht unterrepr sentiert vorhanden Mittel Kompatibel Inkompatibel Extensive nderungen Geringe oder keine nderungen Kompatibel Teilweise kompatibel Einige nderungen Inkompatibel Inkompatibel mit Wartungskonzept Kompatibel mit Wartungs und Teilweise kompatibel Wettbewerbsanforderun Nicht zertifiziert wenig oder keine Testdaten Verifizierte Leistung Einige anwendungskompatible Testdaten verf gbar verf gbar Modifikation vorhanden nicht vorhanden Etwas Kontrolle Keine Kontrolle I Auswirkungen O Ausreichende finanzielle Defizite bei finanziellen Signifikante finanzielle Ressourcen Ressourcen m gliche Defizite berziehung Kosten berschreitungen wahrscheinlich Leitfaden Projektmanagement Q Office 2 Heip 15 1 2Risiko Analyse Bei der Risikoanalyse wird die Schadenswahrscheinlichkeit und das Schadensausma f r jedes identifizierte Risikoelement gesch tzt Au erdem werden zusammengesetzte Risiken abgesch tzt Um zu einer quantitativen Bewertung eines Risikos zu gelangen berechnet man den Risikofaktor Der Risikofaktor ergibt sich aus dem erwarteten Verlust d h die H he der m glichen Verluste oder der Sch den Schadensausma multipliziert mit den Wahrscheinlichkeiten ihres Eintretens Schadenswahrscheinlichkeiten Risikofaktor Fehlschlag Schadenswahrscheinlichkeit Schaden Schadenausma Der Risikofaktor wird also bestimmt durch die Wahrsch
199. r Projektleiter diese Aufgaben selbst bernehmen oder an einen Projektassistenten delegieren Stellen Sie Ihr Projekt von Beginn an durch wenige klare bersichtliche und aussagekr ftige Schaubilder Folien oder Power Point Pr sentationen dar Dar ber hinaus sollten Sie die Ergebnisse bzw Zwischenergebnisse in geeigneter Form einer breiteren internen oder eventuell auch externen ffentlichkeit bekannt machen Liefern Sie regelm ig aktuelle Informationen zu Ihrem Projekt an die entsprechenden Stellen z B Controlling etc Informieren Sie fr hzeitig den Betriebsrat Gesamtbetriebsrat ber den Stand des Projektes Damit erf llen Sie Ihre Pflicht gem BetrVG und erm glichen dass Vorschl ge und oder Bedenken des BR GBR bei der Planung und Entwicklung der IS Anwendung ber cksichtigt werden k nnen Leitfaden Projektmanagement Q Office 2 Heip 17Rahmenbedingungen 17 1Projektvertrag Der Vertrag ist noch nicht unterschrieben Vor allem ist noch nicht klar was die zu erstellende Software oder EDV Anlage alles leisten sollte Auf beiden Seiten dr ngen jedoch die Entscheider auf den baldigen Beginn des Projektes Daher fangen beide Parteien schon einmal mit den ersten Arbeiten an Wie wichtig jedoch ein exakt festgelegter Vertragsgegenstand ist entnehmen sollen die Nachfolgenden Zeilen darlegen Der Vertragsgegenstand ist der zentrale Bereich eines Projektvertrages Er legt nicht zuletzt ma geblich fest nach welche
200. r Vertragsart der Vertrag geregelt wird in der Regel ein Dienst oder Werkvertrag Zum Teil wird der Vertragsgegenstand auch direkt aus dem Pflichtenheft entnommen Das ist dann m glich wenn zwischen der Erstellung des Pflichtenheftes und der Auftragsvergabe eine Z sur ist oder wenn von vornherein das Pflichtenheft auf den Vertragsgegenstand hin entwickelt wurde und gewollt war Dann muss das Pflichtenheft vor allem ber die technische Beschreibung hinausgehen und die Vertragsziele mindestens grob umfassen Wenn zum Beispiel nicht pr zise festgelegt ist welchen Umfang die EDV Anlage haben soll dann ist auch nicht pr zise beschrieben wann die Abnahme erkl rt werden kann und wann das Werk errichtet ist Im Werkvertrag steht der Verg tungsanspruch in unmittelbarem Zusammenhang mit der Verg tung die Verg tung wird f r den im Vertragsgegenstand festgelegten Umfang bezahlt Das bedeutet dass der Werkersteller in der Regel der Entwickler oder das Softwarehaus nur diejenigen Leistungen erbringen muss die auch tats chlich gefordert waren 17 1 1 1Vertragsgegenstand legt den Inhalt des Vertrages fest Problematisch ist bei der Festlegung des Vertragsgegenstandes auch dass dieser sowohl von Kaufleuten als auch von Technikern und teilweise der Rechtsabteilung oder externen Anw lten festgelegt wird und daher die Gefahr besteht dass bestimmte Vertragsteile vergessen werden weil hier die Techniker dachten die Kaufleute w rden das m
201. r der nderung eine nderungsmiitteilung vgl Mustergliederung nderungsmitteilung Anmerkungen Im nderungsantrag sind Aussagen zur Dringlichkeit erforderlich Au erdem sollte eine Kategorisierung erfolgen Fehler in Spezifikation Entwurf Codierung im Verfahren Problem Modifikation Erweiterung Verbesserung etc Das im Projekt festgelegte nderungsverfahren ist im Projekthandbuch detailliert zu beschreiben Bei der Festlegung des nderungsablaufs sollte unterschieden werden ob sich eine nderung auf Produkte bezieht die bereits an den Auftraggeber ausgeliefert wurden oder nicht Vor der Produktauslieferung kann eine verk rzte und weniger formale nderungsprozedur durchgef hrt werden Statt nderungen zu verwerfen k nnen sie auch gesammelt werden um in einer Folge Version realisiert zu werden Release Planung Leitfaden Projektmanagement i Q Office 2 H elp Abbildung 33 nderungsverfahren grober Ablauf Seite 155 Leitfaden Projektmanagement To Office 2 Heip Projektb ro Empfehlungen an den Projektleiter Seite 156 16 3Projektadministration Bei gr eren Projekten ist es sinnvoll ein Projektb ro einzurichten das u a folgende Aufgaben zu erf llen hat Projekthandbuch f hren siehe Mustergliederungen Pl ne aktualisieren Berichte erstellen und Verteilen Schriftverkehr f hren Bestellungen t tigen Dokumentation organisieren Bei kleineren Projekten muss de
202. r realisieren wenn diese Unterst tzung gegeben ist Das gilt beispielsweise f r IT Projekte bei denen massiv in andere Aufgabenbereiche eingegriffen wird oder bei denen viele Bereiche kooperieren m ssen Wenn hier nicht von oberster Stelle im Unternehmen eine R ckendeckung gegeben ist ist der Erfolg eines solchen Projekts mehr als fraglich Die wesentlichen Aufgaben des Auftraggebers sind e Formulierung des Projektauftrags Dazu geh rt ein Grobziel und gege benenfalls erste Randbedingungen und Auflagen f r die Durchf hrung des Projekts Der Auftraggeber wird diesen Auftrag zumindest formal definieren und steht daf r ein e Ernennung des Projektleiters und gegebenenfalls weiterer Projektmitarbeiter Inwieweit das erfolgt ist in hohem Ma e eine Frage der Projektorganisation im Unternehmen Der Projektleiter muss auf jeden Fall die Unterst tzung durch den Auftraggeber besitzen Falls die Projektmitarbeiter durch den Projektleiter gesucht werden besteht die Aufgabe des Auftraggebers in der Best tigung der Personalentscheidungen seiner Projektleiters und der Unterst tzung des Projektleiters falls f r das Projekt ben tigte Mitarbeiter nicht in ausreichendem Um fang von ihren Linienaufgaben freigestellt werden e Eine wichtige Aufgabe ist die Kompetenzregelung zwischen Projektleiter Projektmitarbeitern und Linienbereichen falls diese nicht bereits auf Unternehmensebene erfolgt ist In jedem Fall geh rt dazu aber bei Streitigkeiten
203. ran scheitern dass sie im Lenkungsausschuss keine Mehrheit finden die starre Form kann dazu f hren dass Ver nderungen langsam oder nicht erfolgen Das ist insbesondere dann der Fall wenn Entscheidungen im Seite 37 Leitfaden Projektmanagement T0 Office 2 Heip Seite 38 Lenkungsausschuss wie es zum Teil in der Literatur gefordert wird einstimmig erfolgen m ssen Bei gr eren Unternehmen kann es sinnvoll sein f r Projekte in unterschiedlichen Bereichen dar ber hinaus Fachaussch sse zu bilden die sich um Projekte zu ihren jeweiligen Themenbereichen k mmern Abbildung 6 Die Arbeit mit einem Lenkungsausschuss Die Projektorganisation in Form einer Einfluss Projektorganisation mit einem starken flexiblen und f r neues offenen Lenkungsausschuss ist sicher f r die kleineren Projekte im Unternehmen die beste Organisationsform Solche Organisationsformen lassen sich zudem auch im kleinen realisieren da sie nicht zwingend auf oberster Ebene festgelegt werden m ssen So k nnen zum Beispiel kleinere Projekte im Direktions oder Hauptabteilungsrahmen mit einem Lenkungsausschuss und Teams die nur aus dem entsprechenden Bereich kommen realisiert werden 5 6 7Mitarbeiter im Projektmanagement Mitarbeiter in Projekten befinden sich zumindest dann wenn das Projekt neben ihrer Linienfunktion abl uft in einem Spannungsfeld Dieses Spannungsfeld entsteht generell in zwei Situationen e Die Projektarbeit ist zeitlich beschr nk
204. rden o Funktionen mit vielen Schnittstellen oO Seite 141 Leitfaden Projektmanagement Q Office 2 Heip Seite 142 o Unerfahrene Mitarbeiter Unzureichende Beteiligung der Anwender oder des Fachbereichs o Unzureichende Qualit tssicherung w hrend des gesamten Prozesses Projektes o Neue Entwicklungsumgebungen Plattformen o Gro e Projekt Realisierungsteams o Projekt und Realisierungsteams ohne ausreichende und optimale Kommunikation O e Schaden o Welcher Schaden ergibt sich wenn ein Fehlerereignis eintritt Hierbei kann man an die Fehlerbehebungs Fehlerbeseitigungskosten Direkt und Folgekosten denken Ein Schaden wird noch gr er wen er sich direkt oder indirekt auf Folgeprojekte Folge oder Rundum Systeme auswirkt Zu einer ausreichenden Risikoanalyse ben tigen Sie einen detaillierten Plan Wir finden die beste Zeit um eine initiale Risikoanalyse durchzuf hren ist bereits bei der ersten Projektplanung d h bevor das Projekt gestartet wurde Aber Vorsicht Risikoanalyse und Risikomanagement sind keine einmaligen Aufgaben Untersuchen Sie Ihren Projektplan von Zeit zu Zeit w hrend des Projektes regelm ig ganz besonders dann wenn Sie in Ihrem Projekt Abweichungen vom Projektplan feststellen 15 1 2 1Risken Identifizieren Es gibt eine ganze Reihe vom Wegen und M glichkeiten Risiken zu identifizieren Meistens haben Sie jedoch nur eine begrenzte Zeit daf r zur Verf gung Wir meinen dass Sie mit de
205. rden und die das Projekt berwachen Der Lenkungsausschuss w hlt einen Projektmanager aus Die Gr nde f r das Projekt werden in einer Projektbeschreibung dargestellt Es werden ein L sungsansatz und ein Plan f r die Initiierungsphase beschlossen um dem Projekt eine solide Grundlage zu geben Seite 121 Leitfaden Projektmanagement Q Office 2 Heip Seite 122 Die Elemente des Prozesses Vorbereiten eines Projekts sind SU1 Projektauftraggeber und Projektmanager ernennen SU2 Projektmanagementteam entwerfen SU3 Projektmanagementteam verpflichten SUA Projektbeschreibung vorbereiten SU5 Projektl sungsansatz definieren SU6 Initiierungsphase planen 12 7 8 4Lenken eines Projekts Dieser Prozess definiert die Funktionen des Lenkungsausschusses der f r das Projekt verantwortlich ist Der Projektmanager informiert den Lenkungsausschuss mit regelm igen Berichten die t glichen Management Aufgaben des Projekts bleiben dem Projektmanager berlassen Der Lenkungsausschuss wird nur an den Phasengrenzen eingebunden wo er den bisherigen Fortschritt billigen und den bergang in die n chste Phase freigeben muss Ein grundlegendes Prinzip von PRINCE2 ist Management by Exception was bedeutet dass der Lenkungsausschuss nur in einem einzigen weiteren Ausnahme Fall Entscheidungen ber das Projekt trifft n mlich dann wenn abzusehen ist dass es vom Kurs abweicht Die Elemente des Prozesses Lenken eines Projekts sind DP
206. rden muss Wer aber konsequent vom Groben zum Feinen plant wird dabei feststellen dass sich dieses Gef hl schnell einstellt Immer dann wenn Sie das Gef hl haben der Differenzierungsgrad der im Projektplanungssystem enthaltenen Informationen reicht nicht aus m ssen Sie das Projekt weiter differenzieren 5 7 11Die wichtigsten Begriffe im Projektmanagement Bevor Sie nun darangehen Ihre Projekte mit Hilfe von MS Project f r Windows zu verwalten sollen noch einige Grundbegriffe die im Projektmanagement eine wichtige Rolle spielen erl utert werden Auf die verschiedenen Begriffe und noch manchen weiteren Begriff wird im weiteren Verlauf des Leitfades noch intensiv eingegangen Hier werden nur die wichtigsten Begriffe kurz und zusammenfassend erl utert Begriff Bedeu Vorg nge Vorg nge oder auch Aktivit ten bilden das Projekt Ein Projekt wird in Vorg nge gegliedert Die Vorg nge sind also das Ergebnis der Strukturierung eines Projekts Sie beschreiben weiche Aktivit ten erforderlich sind um das Sachziel des Projekts zu erreichen Ressourcen Ressourcen sind die Mittel die zur Bearbeitung eines Projektes eingesetzt werden Ressourcen sind blicherweise knapp und kosten Geld Es ist also sowohl zur Einhaltung der Termine als auch aus Kostengr nden wichtig diese Ressourcen bei der Planung zu ber cksichtigen Meilensteine Meilensteine stellen Fixpunkte in einem Projekt dar Sie definieren besonders wichtige Zwischenerge
207. rdnen Dem Projekt als ganzes einem Planungsabschnitt oder einem Arbeitsabschnitt Projektinitialisierung Projekt einrichten Projektkriterien und Entwicklungsstrategie Vergabe Beschaffung V Modell erstellen nt durchf hren ngebon bewertung SE QS IME Produkte PM 3 Prenner FA CDE Anarene Be F Management PM7 PMSs Fi Risikomanagement Projektkontrolle und steuerung von OS EM PM9 Berichtsdohmerne Informationsdienst 4 Berichtswesen stem architektur CO mmn O anse von se PMS PM6 Kosten Nutzenanalyse Durchf hrungsentscheidung eye n Planungsabschnitt I PM 1 PMR Bereitstellung der Vergabe von Ressourcen Arbeitsauftr gen Frae iihandouch PB Frae ipian PR Schulung Einarbeitung PM2 Einweisung der Mitarbeiter Arbeitsabschnitt PM 14 Projektabschlu Abbildung 23 Submodell PM im V Modell Seite 111 Q Office 2 Heip Drei wesentliche Bereiche des Projekt Managements Leitfaden Projektmanagement To Office 2 Heip Nachstehend finden Sie die wichtigsten Aktivit tsabschnitte und deren wichtigste Einzelaktivit ten 1 Projekt a Projekt initialisieren b Beschaffung Vergabe c Auftragnehmermanagement d Projektabschluss 2 Planungsabschnitt a Feinplanung b Kosten Nutzenanalyse c Durchf hrungsentscheidung 3 Arbeitsabschnitt a Schulung Einarbeitung b Einsatzmittel c Arbeitsauf
208. re Entwicklung Gestaltung von Anwendungssystemen Testmethoden Projekt Phasen Gespr chsf hrung Aufwandssch tzungen Kenntnisse von IS Entwicklungen und Anwendungsarchitekturen Definierte F higkeiten der englischen Sprache und ggf einer weiteren Fremdsprache Seite 183 Leitfaden Projektmanagement To Office 2 Heip 19 3Beteiligte Funktionen aus der Regelorganisation Die folgende Tabelle zeigt an zu welchen Aktivit ten Kontakte zu Funktionen aus der Regelorganisation sinnvoll sein k nnen und welche Unterst tzung des Projektes durch Organisationseinheiten des Auftraggebers geleistet werden kann Sie erhebt nicht den Anspruch auf Vollst ndigkeit Projektaktivit t Bereich Projektinitialisierung Beratung zur Architektur STR Erfassung Daten f r Projektsteckbrief STR Vorgehensmodell SEVM PM QS MuT Methoden und CASE Tools MuT Beratung zum Datenmanagement ZDM finanzielle Angelegenheiten bei Projektabwicklung Fin Grobkonzept Methoden und CASE Tools MuT Beratung zu Datenmodell und Bereitstellung von Datenmodell ZDM ausschnitt bzw zur Klassenmodellierung Anwendungs klassen Beratung zu technischen Klassen Bausteinb rse MuT Fachl Feinkonzept Beratung Unterst tzung bei Datenmodellierung ZDM QS Abnahme von Datenmodell ZDM Integration des Projektdatenmodells in Datenmodell des ZDM Unternehmens Beratung zu Methoden und CASE Tools MuT Beratung und Festlegung der Systemarchitektur Hw Netz Sys
209. reentwicklungsprojekte Warum werden Sie sich jetzt fragen nun die Antwort ist einfach Wenn von Anfang an alle Anforderungen feststehen ist das Wasserfall ein ingenieurm iges Vorgehen das eine optimale Projektabwicklung garantiert Doch leider sieht die Realit t anders aus als die Theorie Es gibt immer weniger Immer weniger Projekte wo sich das Wasserfallmodell noch anwenden l sst Immer h ufiger Projekte k nnen finden w hrend eines laufenden Projektes Technologiewechsel statt oder es muss nach dem mit u erster Schnelle auf Funktionalit ten eines Mitbewerbers reagiert werden ode abgewickelt werden _ Seite 101 Leitfaden Projektmanagement To Office 2 Heip Das Spiralmodell erlaubt die Kombination bereits existierender Ans tze Seite 102 12 7 2Das Spiralmodell Das Wasserfallmodell und seine im laufe der letzten Zeit entstandenen Varianten dazu geh rt auch der Microsoft Solutions Framework kurz MSF zeichnen sich durch unterschiedliche St rken und Schw chen aus Auf dem Wasserfallmodell basierende Software Entwicklungsprozesse sind durch Meilensteine und Dokumente innerhalb und am Ende der einzelnen Phasen aus organisatorischer Sicht gut zu beherrschen Die Schw chen liegen in der mangelnden Flexibilit t die eine Anpassung an bestimmte Problemstellungen erschwert Eine zuverl ssige Projektplanung und die Kontrolle des Projektfortschritts ist jedoch schwierig In diese L cke zielt das Spiralmodell von B
210. reinfachungen auf denen sie beruht gepr ft und ihre Anwendbarkeit festgestellt haben Merksatz Unbedingt Gebrauchsanleitung beachten Verwechseln Sie nie das Modell mit der Realit t Merksatz Versuch nicht die Speisekarte zu essen Verzerren Sie nicht die Realit t damit sie zu Ihrem Modell passt Merksatz Wende nie die Prokrustesmethode an Beschr nken Sie sich nicht auf ein einziges Modell Um verschiedene Aspekte eines Ph nomens zu beleuchten ist es oft n tzlich verschiedene Modelle zu haben Merksatz Polygamie muss legalisiert werden Halten Sie niemals an einem berholten Modell fest Merksatz Es hat keinen Sinn toten Pferden die Peitsche zu geben Verlieben Sie sich nicht in Ihre Modelle Merksatz Pygmalion Wenden Sie nicht die Begriffe des Gegenstands A auf den Gegenstand B an wenn es beiden nichts nutzt Merksatz Neuer Wein in alten Schl uchen Unterliegen Sie nicht dem Irrglauben Sie h tten den D mon vernichtet wenn Sie einen Begriff daf r haben Merksatz Rumpelstilzchen Leitfaden Projektmanagement Q Office 2 Heip 21 2Glossar 21 2 1Glossar Projektmanagement 90 Syndrom Gefahr der bersch tzung des Fertigstellungsgrades eines Arbeitspakets Der Bearbeiter gibt an ein Arbeitspaket zu 90 erledigt zu haben der wahre Arbeitsfortschritt liegt jedoch darunter Ablaufplanung Zeitliche und logische Anordnung der Arbeitspakete eines Projektes Das Ergebnis der Ablaufplanung ist der
211. rend des Projektes ebenso wie zu Beginn Entscheidungen ber Fortsetzung Beendigung oder Richtungskorrektur getroffen werden Diese Entscheidungen sind jeweils sachlich technisch fachlich und finanziell abzustimmen Die Entscheidungen m ssen von den am Projekt beteiligten Personen getragen werden und sind personenbezogen zu dokumentieren Die wesentlichsten und schwierigsten Entscheidungen f r den Anwender sind die sachlichen funktionalen Freigaben Hiermit entscheidet er in den verschiedenen Projektstadien ob die Konzeption die detaillierte Definition oder die Realisierung des Projektgegenstandes zu einer fachlichen L sung f hrt die er benutzen kann Diese Entscheidungen stellen wichtige Weichen des Projektverlaufs und k nnen in der Regel nicht wieder zur ckgenommen werden Abbildung 31 Entscheidungsprozess Seite 151 Leitfaden Projektmanagement To Office 2 Heip Freigabe entscheidung Timebox Iteration Seite 152 16 2 1Kontrolle und Steuerung bei klassischer Vorgehensweise Nach jeder Phase im Vorgehensmodell nach klassischer Vorgehensweise ist durch das Review Board eine Entscheidung zu treffen e Phasenfreigabe Weiterarbeit mit Folgephase e Iteration Anderung von Ergebnisse der Phase e Abbruch Projekt wird abgebrochen Jede Phase ist ber die Voraussetzungen Aktivit ten und Ergebnistypen definiert Durch die Qualit tssicherung Qualit tsreview ist festzustellen ob die Phase freigegeben werden
212. rende Vorgehensweisen und Pl ne auszuarbeiten F r die Risikoplanung gibt es grunds tzlich 3 Wege e Versuchen Sie m gliche Risiken so fr h als m glich zu erkennen Dadurch sinkt die Chance dass ein Risiko irgendwann wirklich entsteht Beispiel haben Sie f r eine kritische Aufgabe nur eine Ressource zur Verf gung so sollten Sie vorsorglich eine zweite Ressource ausbilden oder sich der Verf gbarkeit einer weiteren Ressource versichern e Schw chen Sie das Risiko ab f r den Fall das es eintritt Beispiel Sind Sie auf einen Zulieferer angewiesen so nehmen sie in den Vertrag mit dem Zulieferer entsprechende Klauseln mit Konventionalstrafen mit auf die dann eintreten wenn sich z B Zulieferungen versp ten gar nicht eintreffen oder die Qualit t nicht der vereinbarten entspricht e Entgegnen Sie dem Risiko mit einem entsprechenden Verf gbarkeitsplan sobald der Problemfall eintritt Beispiel eine geplante Aufgabe wird sich verz gern oder l nger dauern als geplant stellen Sie sicher das gen gend Ressourcen verf gbar sind um hier zus tzlich eingesetzt zu werden Um die entsprechenden Ressourcen Menschen Maschinen Material etc rechtzeitig zu erhalten ist es notwendig auch die Planung daf r rechtzeitig durchzuf hren und nicht erst dann wenn Sie die Ressourcen dringend ben tigen Denken Sie daran das die Planung und das durchf hren eines Risikomanagements oftmals unerwartete Ergebnisse mit sich bringen Modelliere
213. rgenommen welche die jeweiligen Aktivit ten aus ben durchf hren Diese Definition ist nat rlich sehr theoretisch Doch wenn Sie sich einige Minuten Zeitnehmen und die dahinter verborgenen Aussagen erkennen wird die Bedeutung offensichtlich Eine koordinierte Vorgehensweise verlangt nicht nur einen Plan sondern auch gewisse Erfahrungen auf denen dieser Plan basiert Derartige Erfahrungen werden weder in einem Studium noch im eigenen Berufsleben gemacht solche Erfahrungen werden auch nicht von einzelnen Software Entwicklungsabteilungen oder einem einzelnen Unternehmen gewonnen Derartige Erfahrungen m ssen auf hunderten von Projekten der unterschiedlichsten Gr e beruhen Eine so gro e Anzahl wickelt nat rlich nicht ein einzelnes Unternehmen ab hier gilt es den Erfahrungsschatz einer breiten Masse von Unternehmen zu nutzen 12 3Gesch ftsprozessmodellierung als Basis f r Prozessmodelle Seit sich vor einigen Jahren das Thema Gesch ftsprozessmodellierung innerhalb der IT Branche etablieren konnte hat sich eine Art Prozessdenken innerhalb der Industrie durchgesetzt Jedoch erst durch Prof Dr Scheer wurde eine gewisse Akzeptanz erreicht Mit ARIS Architektur Integrierter Informationssysteme entstand ein Produkt das f r die Abbildung Analyse und teilweise Simulation von Gesch ftsprozessen geeignet war Ivar Jacobson publizierte im Jahre 1992 zum ersten male seine Use Cases damit war der Bann gebrochen die Objektorien
214. rh ltnism ig niedrig sein etwa 3 7 Mitarbeiter pro Gruppe Teilprojekt Projekt Ein einmal in Terminverzug geratenes Projekt kann durch zus tzliche zu sp t eingesetzte Mitarbeiter nicht termintreuer gemacht werden Im Gegenteil es kann dadurch noch mehr in Verzug gebracht werden Zus tzliche Mitarbeiter m ssen von den vorhandenen geschult und eingearbeitet werden Es muss eine erneute Abstimmung und eine weitere Aufgabenteilung vorgenommen werden Dadurch sinkt die Produktivit t der alten Mitarbeiter Die neuen Mitarbeiter ben tigen mehr Betreuung erschweren die Kommunikation und sind noch nicht mit dem laufenden Projekt vertraut Die optimale Mitarbeiterzahl sollte also rechtzeitig zur Verf gung stehen da eine versp tete Mitarbeiteraufstockung fast immer zu Terminverz gerungen f hrt 8 2 3Projektstruktur Projektstrukturen sind nicht eindeutig und klar in ein hierarchisches Model einzuordnen vielmehr wirk hier sehr stark die Teamkomponente ohne dabei die F hrungs und berwachungsaufgaben des Projektleiters zu schm lern Ein Projekt hat zum Beispiel die folgende Organisationsstruktur Abbildung 11 Struktur eines Projektes Seite 61 Leitfaden Projektmanagement To Office 2 Heip Projekt Verantwortung Pflichten Rechte Seite 62 Das Projektteam setzt sich zusammen aus e Projektleiter PL e Projektgruppe Der Projektleiter kann vom Auftraggeber Anwender oder einem externen U
215. rin den Projektmitarbeitern den R cken gegen ber der Linienfunktion freizuhalten Dazu geh ren e Sicherung einer ausreichenden Entlastung von Linienaufgaben f r die Dauer des Projekts e Sicherung einer ausreichenden zeitlichen Freistellung f r das Projekt e Verhinderung von Nachteilen bei der Weiterentwicklung in der Linienfunktion nach Abschluss des Projekts Karrieresicherung Nur in dieser Situation ist es berhaupt m glich dass die Mitarbeiter den f r eine erfolgreiche Projektarbeit erforderlichen Freiraum haben Die Problematik besteht nur dann nicht in diesem Ma e wenn das eigentliche Tagesgesch ft in der Projektarbeit besteht 5 6 8Aufgaben des Projektmanagers Im letzten Abschnitt wurde bereits auf eine der wichtigsten Aufgaben von Projektmanagern eingegangen die Motivation der Mitarbeiter im Projektteam Daneben liegen die Aufgaben insbesondere in e Steuerung der Projektorganisation Seite 39 Leitfaden Projektmanagement To Office 2 Heip Seite 40 Sicherstellung von regelm igen Projekt Reviews Organisation von Projektsitzungen L sung von Problemen Kommunikation mit anderen am Projekt beteiligten interessierten Personengruppen Sein Aufgabenbereich liegt also sowohl in der Projektmanagement Methodik als auch darin sein Team zu f hren Diese F hrungsfunktion ist insbesondere deshalb anspruchsvoll weil es sich um eine fachliche F hrung handelt die sich weder auf hierarchische Macht st tzen kan
216. ringer als die Nachfrage 10 1 19Fehlende Qualit tssicherung Erst in den letzten Jahren wurde Qualit tssicherung zu einem festen Bestandteil eines Softwareentwicklungsprojektes So wahr die Aussage Qualit tssicherung am Ende eines Projektes ist Sabotage des Projektes auch ist ber cksichtigt wird sie auch heutzutage noch nicht Dies betrifft insbesondere auch das Testen von Software das gar nicht fr h genug vorgenommen werden kann Viele Softwareprojekt laufen immer noch nach dem selben Schema ab Es wird analysiert anschlie end entworfen und dann entwickelt Sp testens nach der H lfte der anberaumten Entwicklungszeit tritt so langsam aber sicher deutlicher Termindruck auf Dieser bewirkt in der Regel dass das gr ndliche gewissenhafte und vollst ndige austesten der Software auf der Strecke bleibt Resultat ist eine fehlerhafte Software ein unzufriedener Kunde und damit einhergehend ein berzogenes Projektbudget Aber auch st ndige oder unkontrollierte Qualit tskontrolle l sst kein Projekt erfolgreich zu Ende kommen ISO 9000 hin oder her es zeigt sich immer mehr dass nicht die Unternehmen erfolgreich sind die langwierige undausgefeilte aber zertifizierte Prozesse zur Softwareerstellung benutzen sondern diejenigen die einen praktikablen und zugleich qualit tsbewussten Ansatz w hlen Um diesen Ansatz zu finden soll die Aktivit t Testen n her beschrieben werden Leitfaden Projektmanagement Q Office 2 Heip
217. rlichen Arbeitsschritte Projektteam Kernteam Seite 203 Leitfaden Projektmanagement To Office 2 Heip Seite 204 Projektmitarbeiter die zusammen mit dem Projektleiter f r die Projektdurchf hrung verantwortlich sind Projektziel Das Projektziel ist Bestandteil des Projektauftrags und besteht aus den drei Komponenten e Inhalt e Zeit e Kosten Es muss erreichbar vollst ndig widerspruchsfrei nicht interpretierbar pr fbar l sungsneutral dokumentiert und zwischen AG und PL abgestimmt sein Reine Projektorganisation Form einer Projektrahmenorganisation F r die Dauer eines Projektes werden die beteiligten Mitarbeiter zu einer selbst ndigen Organisationseinheit zusammengefasst und dem Projektleiter unterstellt Ressourcenplanung Einsatzplanung Planung des zeitlichen Einsatzes der an der Projektdurchf hrung beteiligten Ressourcen abh ngig von ihrer Verf gbarkeit Risiko M glichkeit eines k rperlichen oder materiellen Schadens oder Verlustes durch eine Aktivit t Risikomanagement F hrungsstil bei dem sich der Manager auf die Risikobewertung und die Risikobeherrschung konzentriert R ckw rtsrechnung 2 Schritt der Netzplanberechnung in dem die sp test m glichen Anfangs und Endzeitpunkte der Arbeitspakete ermittelt werden Sprungfolge Anordnungsbeziehung vom Anfang eines Arbeitspaketes zum Ende seines Nachfolgers d h das Ende von Arbeitspaket B ist abh ngig vom Beginn des Arbeitspakets
218. rteilung Zeit Mitarbeiter usw F hrung des Projektteams Motivation der Mitarbeiter Erstellung der Projektdokumentation sicherstellen Erstellung der Bediener und Anwenderhandb cher sicherstellen Sicherstellung der Qualit tssicherung Koordination der beteiligten Bereiche gezielte Information der beteiligten Bereiche Entscheidung ber Werkzeugauswahl Aufgaben des Projektteams sind u a e Analyse der vom Projekt betroffenen Bereiche Entwicklung praxisgerechter und wirtschaftlicher L sungsalternativen Realisierung der angenommenen Alternative Installation der Anwendung Dokumentation der Anwendung Schulung der betroffenen Bereiche Entwicklung der Anwender und Bedienerhandb cher Informant f r den eigenen Stammbereich Pr sentationen Hinweise f r das Zusammenwirken von Projekt Mitarbeitern des Auftraggebers Kunden und Besch ftigten anderer Unternehmen externe Berater in Projekten Grunds tzlich sollen alle Projektbeteiligen unabh ngig von ihrer Firmenzugeh rigkeit so zusammenarbeiten dass der Projekterfolg sichergestellt und die bergeordneten Anforderungen aus Unternehmenssicht erf llt werden Die Projektmitarbeiter berichten an den Projektleiter und sind ihm in fachlicher Hinsicht unterstellt In disziplinarischer Hinsicht bleiben sie weiterhin dem abgebenden personalverantwortlichen Leiter unterstellt Dies gilt sowohl f r Mitarbeiter des Auftraggebers sowie f r externe Berater Im Falle der Bet
219. s formalen Vorgehensleitfaden anzuwenden Probleml sungszyklus Diese Komponenten bilden in sinnvolles Ganzes da sie miteinander verbunden werden k nnen Das im folgenden aufgezeigte Phasenmodell unterscheidet zwischen klassischer Phasenmodell und objektorientierter Vorgehensweise Abbildung 35 Modul SEVM im V Modell Seite 163 Leitfaden Projektmanagement To Office 2 Heip Tailoring Phasenkonzept objektorientierte Vorgehensweise Seite 164 Neben den eigentlichen Aktivit ten zur Anwendungsentwicklung die sich auf die fachlich inhaltlichen Aufgaben konzentrieren gibt es die zeitlich parallel verlaufenden F hrungsprozesse des Projektmanagements und des Qualit tsmanagements Unterst tzt werden die Prozesse der Anwendungsentwicklung durch das Konfigurationsmanagement das u a die einzelnen Versionen der Ergebnisse der Entwicklung berwacht Die klassische Vorgehensweise orientiert sich am BVB Phasenmodell Die einzelnen Phasen werden als abgeschlossene Einheiten betrachtet und werden nach dem Wasserfall Prinzip durchlaufen BVB ist in diesem Zusammenhang Grundlage aller Vertragsmuster beim Einkauf von IS Produkten und Dienstleistungen Im Bedarfsfall kann das vorgegebene Vorgehensmodell an projektspezifische Erfordernisse und Besonderheiten angepasst werden Dieses Anpassen wird allgemein als Tailoring bezeichnet Tailoring Massnahmen sind schriftlich zu begr nden und mit dem Bereich Methoden und Tools abzukl ren
220. s innerhalb der Projektorganisation dar und zeigt WER von WEM WANN WIE ber WAS informiert wird WER von WEM REVIEW BOARD von der PROJEKT LEITUNG bei einem Phasenabschluss bei kritischen Projekten bzw in kritischen Phasen w chentlich sofort im Problemfall und bei gravierenden absehbaren Planabweichungen BEE Projektstatus SOLL IST Vergleich Planabweichungsgr nde Aufwand Kosten Termine Vorgehensweise Arbeitseffizienz Werkzeuge Umfeld Arbeitsklima Probleme und Vorschl ge f r zu treffende Ma nahmen Entscheidungsvorbereitung WER von WEM WER von WEM PROJEKT LEITUNG von den PROJEKT MITARBEITERN BEER regelm ig sofort im Problemfall Projektsitzungen Gespr chsprotokolle pers nliches Gespr ch Ergebnisstatus aufgetretene Probleme und getroffene Entscheidungen m gliche Terminverz gerungen WER von WEM PROJEKT MITARBEITER von der PROJEKT LEITUNG o OE regelm ig sofort im Problemfall Projektsitzungen Gespr chsprotokolle Arbeitsauftr ge Ergebnisstatus aufgetretene Probleme und getroffene Entscheidungen Aufgabenverteilung Tabelle 8 Berichtswege Leitfaden Projektmanagement i Q Office 2 Heip informiert und kommuniziert mit Abbildung 37 Berichtswesen Seite 169 Leitfaden Projektmanagement To Office 2 Heip Projektabschlus s Projekt erfahrungen auswerten Seite 170 18Projektnachbereitung Ein systematischer
221. sches V Modell ist neben der Beschreibung des Projektes seiner Organisation und seiner Ziele Hauptbestandteil des Projekthandbuchs PHB Das Tailoring besteht aus folgenden Schritten e Festlegung der Form des projektspezifischen V Modells Hier wird entweder bestimmt dass das PHB die Aktivit ten und Produkte des V Modells lediglich referenziert oder dass die vollst ndige Darstellung des V Modells auch in das PHB bernommen werden sollte e Selektion von Aktivit ten und Produkten Dies geschieht durch Tailoring mit Streichbedingungen oder durch standardisiertes Vortailoring e Selektion der Aktivit ten und Produktklassen die f r das Projekt prinzipiell sinnvoll sind e Streichen von Aktivit ten und zugeh rigen Produktklassen die anderweitig erledigt werden bzw bereits erledigt wurden Seite 129 Wesentliche Voraussetzung f r Prozess Modelle Teilschritte des Tailoring Leitfaden Projektmanagement Q Office 2 Heip e Anpassung der Texte der Aktivit ten Das Ergebnis des Tailorings ist immer ein deutlich reduziertes Vorgehensmodell in Form von Tabellen und den dazugeh rigen textuellen Beschreibungen Seite 130 Leitfaden Projektmanagement Die Anpassbarkeit des V Modells ist als streng geregelt Das liegt in erster Linie daran dass das V Modell ein Vorgehensmodell ist das von Auftraggeberseite entwickelt wurde Hingegen kommt der Rational Unified Process RUP aus der Praxis also von Seiten der Auftrag
222. senkonzepte sind vor allem ein Hilfsmittel f r die Strukturierung von Projekten Sie sind ein wesentlicher Bestandteil effizienter Strukturierung des Projekts Denn Phasen definieren Anfangs und Endpunkte Phasen beinhalten berpr fungen des Projektstatus Phasen schaffen eine erste Strukturierung des Projekts Die Phasenmodelle haben sich daher auch in vielen Jahren der Projektarbeit bew hrt Welches Modell man letztlich w hlt ist dabei sekund r Wichtig ist dass eine klare Strukturierung des Projekts erfolgt Im weiteren entstehen die meisten Projekte ja meist nicht allein und ohne Abh ngigkeiten und auf der gr nen Wiese sondern sind in einen Unternehmens bzw Produktionsrahmen eingebunden Hier kommen dann erg nzender Modelle und Vorgehensweisen wie z B die IT Infrastructure Library kurz ITIL genannt zum Tragen ITIL beschreibt die f r den Betrieb einer IT Infrastruktur notwendigen Prozesse Die Prozesse orientieren sich bei ITIL nicht an der Technik sondern an den durch den IT Betrieb erbrachten Services bzw den Dienstleistungen Daher bildet ITIL eine m gliche Grundlage f r ein IT Service Management dass hei t den Wirk und Regelbetrieb nach einer initialen Projektphase 5 6 1Das Phasenmodell und die Projektstrukturierung Die Unterteilung des Projekts in Phasen ist ein erster Schritt f r eine klare Strukturierung des Projekts Phasenkonzepte umfassen mehrere wesentliche Elemente Beschreibung der Inhalte Aufgaben i
223. soll ist sehr h ufig ein komplexes Projekt Die Strukturen f r das Projektmanagement und die Nutzung der Projektplanungssoftware sind vielfach nicht sauber definiert Da Eingaben bei der Software in vielen F llen einen direkten Handlungsbedarf aufzeigen m ssen auch unmittelbar Entscheidungen getroffen werden k nnen Die Entscheidungswege sind in vielen f llen zu lang Die Projektplanungssoftware wird nicht von allen Projektbeteiligten genutzt Die Software wird in verschiedenen Bereichen mit Projekten die sich berlappen in unterschiedlicher Weise eingesetzt Leitfaden Projektmanagement Q Office 2 Heip Die L nge dieser Liste macht schon deutlich dass eine Menge an Voraussetzungen geschaffen werden m ssen um Projektplanungssoftware erfolgreich nutzen zu k nnen Diese Voraussetzungen lassen sich in drei Punkten zusammenfassen e Die organisatorischen Strukturen und Rahmenbedingungen f r das Projektmanagement und f r die Nutzung einer Projektplanungssoftware im Unternehmen m ssen klar definiert sein e Es muss Klarheit dar ber bestehen dass Projektplanungssoftware keine L sung sondern ein Werkzeug ist Projektmanagement findet weiterhin zun chst im Kopf der verantwortlichen statt Diese m ssen die Methodik des Projektmanagements und die Handhabung und Logik der Projektplanungssoftware beherrschen e Der Einsatz von Projektplanungssoftware f hrt blicherweise nicht zu einem messbar geringeren Aufwand f r das Projektmanage
224. sollten nach M glichkeit die zur Durchf hrung der erarbeiteten Ma nahmen erforderlichen Ressourcen zus tzliche Mitarbeiter finanzielle Mittel usw von den Verantwortlichen bereits in der Status Sitzung freigegeben werden 19 1 7Regeln zur Projektdokumentation Die Dokumentation dient der Transparenz des Projektes und der Kommunikation der am Projekt beteiligten Bereiche und ist dar ber hinaus Grundlage f r notwendig werdende nderungen oder Erweiterungen Produktiveinsatz bzw der Betreuung und Schulung der Anwender Es liegt in der Verantwortung des Projektleiters die Autoren der einzelnen Dokumente anzuhalten diese eindeutig und f r alle Betroffenen Leitfaden Projektmanagement Q Office 2 Heip verst ndlich abzufassen Die berwachung dieser Vorschrift liegt beim Projektleiter e F r die Erstellung der Dokumente sind vom Projektleiter Formulare und Produktmuster vorzugeben soweit diese nicht schon im Unternehmen vorgeschrieben sind e Alle Dokumentationen sind aus Aktualisierungsgr nden maschinell zu f hren e S mtliche Dokumentationen sind projektbegleitend zu erstellen 19 1 8Regeln zur Entscheidungsfindung Verantwortliche Entscheidungen fallen an den markanten Projektpunkten wie z B nach Projektidee vor dem eigentlichen Projektstart Fachliches Grobkonzept Anforderungskatalog Fachliches Feinkonzept Etc an und dienen letztlich der Klarstellung ob das Projekt weitergef hrt werden soll welc
225. ssourcen Mit das gr te Problem in einem Projekt ist die Absch tzung der Zeit und damit die Belegung der Ressourcen W hrend die Gesch ftsleiter und Vorgesetzten meist geringere Dauern sch tzen liegen die Sch tzungen der Betroffenen meist h her Die Diskrepanz besteht in der Regel darin dass durch Vorgesetzte und Gesch ftsleitung Randarbeiten wie Dokumentation Auswertungen abgeschlossener Projekte und Projektteile viel zu gering oder gar nicht beachtet werden Meist fehlt auch der Einblick in die konkreten Probleme Andererseits wird jeder der seinen Aufwand absch tzen muss im Kopf einen Puffer hinzurechnen Ein Ausweg aus diesem Dilemma ist die Nutzung der Auftragssummen und anderer Kennwerte Diese werden in Stunden umgerechnet und bieten eine gute Ausgangsposition Die Erfahrungen vergangener Projekte k nnen ebenfalls eine wichtige Hilfestellung bieten Nicht zu untersch tzen ist schlie lich auch noch der Einfluss der Projektkultur Wenn akzeptiert wird dass Sch tzungen und das impliziert der Begriff falsch sein k nnen und nderungen daran vorgenommen werden m ssen wird die Bereitschaft zu realistischen Aussagen steigen Wenn aus jeder Fehleinsch tzung ein Drama gemacht wird werden dagegen mehr und mehr Puffer einkalkuliert werden 5 7 9Die Ressourcenplanung Das erste Kriterium das die Ressourcenplanung scheitern l sst ist meist der Aufwand der getrieben werden muss Wie oben schon beschrieben ist der der
226. st die Unternehmensleitung oder ein von der Unternehmensleitung nominierter Auftraggeber bzw ein Review Board Der Auftraggeber oder das Review Board nominiert den f r das Projekt verantwortlichen Projektleiter Diese Ernennung muss offiziell gegen ber allen beteiligten Bereichen erfolgen F r die Dauer des Projektes wird der Projektleiter von allen anderen Aufgaben freigestellt Der Projektauftrag wird vom Auftraggeber und dem Projektleiter gemeinsam erarbeitet und schriftlich fixiert Der Auftrag muss eine exakte Problembeschreibung inkl Definition der betroffenen Unternehmensbereiche Abgrenzung sowie die Angabe eines Wunschtermins der Beendigung Kostenrahmen und deren Nutzen und Priorit t enthalten Projekte m ssen bei berschreitung des Zeitrahmens von 24 Zeitmonaten in Teilprojekte aufgeteilt werden Diese m ssen jeweils wieder der Regel 1 4 gen gen F r die Einarbeitung in die Projektthematik muss dem Projektleiter ausreichend Zeit au erhalb des Projektzeitrahmens zur Verf gung stehen Der Auftraggeber informiert alle beteiligten Bereiche bereits vor dem Projektstart dar ber dass f r das Projekt Mitarbeiter bereitgestellt werden m ssen Projektteam Die Aufgabe dieser Mitarbeiter ist es das kompakte Fachwissen in das Produkt hineinzutragen Die Mitarbeiter m ssen ber sehr gute Fachkenntnisse verf gen Die Anforderungen des Projektleiters bez glich der Anzahl der bereitzustellenden Mitarbeiter und deren Qualifikat
227. stand unvorhersehbarer Risiken Risiko wird als Unsicherheit des Ergebnisses verstanden Beim Risikomanagement geht es darum die Risiken auf effektive und wirtschaftliche Art innerhalb akzeptabler Grenzen zu halten Die folgenden drei Grunds tze gelten f r das Risikomanagement e Risiko Toleranz e Risiko Verantwortung e Risiko Eigent mer Seite 125 Leitfaden Projektmanagement Q Office 2 Heip Seite 126 12 7 8 11 6Qualit t in einer Projektumgebung Zun chst sollte festgestellt werden dass sich Qualit t nicht auf die allt gliche Bedeutung des Wortes bezieht sondern auf jede quantifizierbare Eigenschaft des Produkts die es f r seinen Zweck geeignet macht Zum Beispiel sind das Produkt muss um 09 00h morgens fertig sein das Produkt muss blau sein oder das Firmenlogo muss mindestens 3 cm gro gedruckt sein alles Qualit tserwartungen Das Ziel eines Projekts ist es Produkte herzustellen die f r ihren Zweck geeignet sind und die die Erfordernisse und Erwartungen des Kunden erf llen Die Qualit tserwartungen sind in der Projektbeschreibung und im PID festgehalten Qualit tsmanagement besteht aus vier wesentlichen Elementen Qualit tsmanagement System Qualit tssicherungs Funktion Qualit tsplanung Qualit tssteuerung 12 7 8 11 7Konfigurationsmanagement Konfigurationsmanagement befasst sich mit der Steuerung aller Produkte des Projekts Eine Konfiguration ist eine Menge logisch verwandter Produkte die ge
228. stimmter Voraussetzungen den Randbedingungen bedingungen Seite 165 Leitfaden Projektmanagement To Office 2 Heip Detaillierung Beispiel Function Point Methode Sch tzmethode bei objekt orientierter Vorgehensweise Seite 166 Randbedingungen k nnen sein e bestimmte Mitarbeiter im Projektteam e Einsatz bestimmter Werkzeuge e angenommene Maschinenverf gbarkeit Diese Randbedingungen m ssen als Bestandteil der Sch tzwerte mit diesen gemeinsam an den Auftraggeber schriftlich weitergeleitet werden Sch tzungen nicht en bloc f r das Gesamtprojekt durchf hren sondern Sinnvollerweise in vern nftige Abschnitte teilen e Phasenweises Sch tzen e Jede Phase m glichst detailliert in Aktivit ten zerlegen Die Summe der Sch tzungen aller Aktivit ten ergibt den voraussichtlichen Gesamtaufwand der Phase Beispiel f r Aufwandsch tzung nach klassischem Phasen Modell Vorlauf Projektinitialisierung 5 Grobkonzept 10 Fachliches Feinkonzept 25 DV technisches Feinkonzept 15 Programmierung 25 Systemtest Integration 15 Installation Einf hrung 5 100 Ungef hr 3 6 Zeitaufwand sollte f r die Ausbildung eingeplant werden da man bei Projektbeginn nicht damit rechnen kann dass alle Projektteammitglieder entsprechende Qualifikationen aufweisen Sch tzmethode bei klassischer Vorgehensweise FUNCTION POINT METHODE Das Sch tzverfahren Function Point Methode dient zur Kalkulat
229. t e Die Projektarbeit l uft parallel zu den Linienaufgaben Leitfaden Projektmanagement Q Office 2 Heip Selbst bei gro en Projekten erfolgt zumindest in deutschen Unternehmen in der Regel nur eine zeitweilige Delegation in das Projekt die aufgrund der relativ geringen Beweglichkeit der Mitarbeiter die Problematik aufwirft dass diese anschlie end wieder in eine gleiche oder bessere Linienfunktion zur ckkehren m chten Die aus dieser Situation resultierende Unsicherheit ist in ihren Folgen f r das Engagement der Mitarbeiter in einem Projekt und f r die Bereitschaft in Projekten mitzuarbeiten nicht zu untersch tzen Eine wesentliche Anforderung f r den Erfolg des Projekts ist dass die Mitarbeiter sich mit den Projektzielen identifizieren Projektarbeit bedeutet fast zwangsl ufig einen erh hten Einsatz Sie erfordert neben dem zeitlichen Einsatz vor allem e Engagement e Kreativit t Diese werden erbracht wenn die Motivation der Mitarbeiter stimmt Diese Motivation wird bereits bei der Zusammenstellung der Projektgruppe beeinflusst und h ngt in hohem Ma e von der Arbeit in der Projektgruppe ab F r die Auswahl der Mitarbeiter bedeutet das zun chst dass versucht werden sollte interessierte aktive Mitarbeiter zu gewinnen Es bedeutet aber auch dass der Projektmanager sich w hrend des Projekts intensiv um das Klima in der Gruppe k mmern muss Die wesentliche Aufgabe des Auftraggebers beziehungsweise Sponsors liegt da
230. t Diagramme erwiesen sich als ein solch m chtiges Unterst tzungs und Analysewerkzeug f r Manager so das sie f r nahezu 100 Jahre unver ndert blieben Erst in den 90er Jahren wurden Verbindungslinien zu den Gantt Charts zugef gt so dass eine pr zisere Aussage ber die Abh ngigkeiten von Aufgaben m glich wurde Taylor Gantt und andere waren ma geblich daran beteiligt dass die Funktion Management als solches in eine etablierte Gesch ftsfunktion entwickelt wurde die heutzutage ein Studium und strickte Disziplin erfordert In den Jahrzehnten bis hin zum 2 Weltkrieg entwickelten sich dazu zus tzlich Marketingans tze und industriell angewandte Psychologie In den weiteren Jahren wurden zus tzlich noch Mitarbeiterprogramme als integraler Bestandteil des Managements eingef hrt 4 3Die Mitte des 20 Jahrhunderts und seine Anstrengungen Nach dem 2 Weltkrieg erforderten neue umfangreiche und komplexe Projekte auch neue organisatorische Strukturen Die Einf hrung neuer und komplexer Netzwerk Diagramme wie den sogenannten PERT Charts und der kritischen Pfad Methode gab Managern eine viel effizientere und umfassendere Kontrolle ber extrem komplexe Projekte mit deren hohen Anzahl an auszuf hrenden T tigkeiten und vielen gleichzeitigen Aktionen die teilweise an den unterschiedlichsten rtlichkeiten zur gleichen Zeit ausgef hrt werden mussten Schnell breiteten sich diese Techniken in allen m glichen Bereich
231. t einem Lenkungsausschuss uuuuuueeennnnnn 38 Abbildung 7 Untere Projekt Eckwerte ununusssnnnnnnennnnnnnnnnnannnnnnnnnnnnnnn 48 Abbildung 8 Obere Projekt Eckwerte uuuuununnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 49 Abbildung 9 Kommunikationspaare 5 Mitarbeiter uuuuunsnnnnnnnnnnnenn 60 Abbildung 10 Kommunikationspaare 9 Mitarbeiter uuunnunnnnnnnnnnnnn 60 Abbildung 11 Struktur eines Projektes uunnsnsnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 61 Abbildung 12 Struktur eines Review Boards nnnnnunnn nn 65 Seite 7 Leitfaden Projektmanagement Q Office 2 Heip Seite 8 Abbildung 13 Zusammenwirken der Projektbeteiligten 74 Abbildung 14 Unklare Anforderungen uuuu r22000nn0nn0nnnnnnnnnnnnnnnnnnnnnnn 81 Abbildung 15 Die Bedeutung von Dokumenten zugegeben etwas Sarkaslisch esaiesaeneineun nannten sahen innerer 86 Abbildung 16 RUP Prozess uss u s0n00nun0nusonu0Hunnanaann ann nnan an nnnnsannan daran 96 Abbildung 17 Wasserfallmodell unuunsssssnnnnnnnnnnnnnannnnnnnnnnnnnnnnnnnnnnnn nn 101 Abbildung 18 Spiralmodell usu000000nu0s040404000 ann aLananonannnnunan ann nun 103 Abbildung 19 Das Zusammenspiel der Submodelle im V Modell 106 Abbildung 20 Submodell SE im V Modell uuuuuuuuu00000000nnnnnnnnnnnnn 00 107 Abbildung 21 Submodell KM im V Modell uunnesssnnnennnnnennnnnnnnnnnnnnnnnnen 108 Abbildung 22 Sub
232. t jedem g ngigen Web Browser parallel zu seiner Software Entwicklung sich kontinuierlich die erforderlichen Hilfestellungen anzeigen zu lassen Die Navigation wird durch zahlreiche Hyperlinks und interaktive Abbildungen stark vereinfacht Hinzu kommen durch die sogenannte Extended Help einer Vielzahl von Produkten die in den Rational Unified Process eingebunden sind direkt aus dem jeweiligen Werkzeug auf den Prozess zugegriffen werden kann Damit erspart sich der Anwender den blichen Griff in das B cherregal wo das bisherige Prozessmodell langsam aber sicher verstaubt 12 2Warum brauchen wir Prozessmodelle Leitfaden Projektmanagement Q Office 2 Heip Selbst der gr te Pfusch bei einem Hausbau ist gegen ber dem State of the Art der Softwareentwicklung immer noch als professionell zu bezeichnen da hier zumindest noch nach einem Modell vorgegangen wird Hintergrund dieses sicherlich zynischen Vergleichs ist die Motivation zu verdeutlichen welche Auswirkungen es haben kann Software ohne ein Prozessmodell zu entwickeln Doch was ist ein Prozessmodell Die folgende Definition soll hier ber Klarheit verschaffen Ein Prozessmodell ist eine Beschreibung einer koordinierten Vorgehensweise bei der Abwicklung eines Vorhabens Es definiert sowohl den Input der zur Abwicklung der Aktivit t notwendig ist als auch den Output der als Ergebnis der Arbeit produziert wird Dabei wird eine feste Zuordnung von Workern Arbeitern vo
233. t werden bevor der Ubergang in die n chste Phase freigegeben wird Die Elemente des Prozesses Managen der Phasen berg nge sind SB1 Phase planen SB2 Projektplan aktualisieren SB3 Business Case aktualisieren SB4 Risikoprotokoll aktualisieren SB5 ber Phasenabschluss berichten SB6 Ausnahmeplan erstellen 12 7 8 10Abschlie en eines Projekts Ein weiterer Grundsatz von PRINCE2 ist dass Projekte kontrolliert und geordnet abgeschlossen werden m ssen Das beinhaltet eine Bewertung des Projektergebnisses die Projektrevision Alle gemachten Erfahrungen Lessons learned werden dokumentiert wenn n tig wird ein bergabedokument erstellt und ein Implementierungs Revisionsplan erstellt Die Elemente des Prozesses Abschlie en eines Projekts sind e CP1 Projekt aufl sen e CP2 Folgeaktionen identifizieren e CP3 Projekt bewerten 12 7 8 11Komponenten PRINCE2 hat acht Haupt Konzepte die die Prozesse unterst tzen 12 7 8 11 1Business Case Der Zweck des Business Caseist die betriebswirtschaftliche Rechtfertigung des Projekts er ist die Motivation f r den Gesch ftsprozess und stellt sicher dass der Projektfortschritt an den Gesch ftszielen ausgerichtet ist F r die Existenz des Projekts wird ein stichhaltiger Business Case ben tigt Eigent mer des Business Case ist der Auftraggeber des Projekts Ein Hauptbestandteil des Business Case ist das Projektmandat 12 7 8 11 2Organisation Definiert alle Rollen
234. t werden k nnen Das bedeutet dass die Einf hrung eines Prozessmodells mit Zeitaufwand und damit Kosten verbunden ist Letztere entstehen zus tzlich durch die Bereitstellung der notwendigen Werkzeugumgebungen 12 6Weitere Vorteile der Verwendung von Prozessmodellen Die Verwendung von Prozessmodellen birgt eine Reihe von Vorteilen in sich Im folgenden werden besonders die Vorteile herausgearbeitet die durch den Einsatz des RUP Rational Unified Process als Prozessmodell erreicht werden k nnen e Neue Mitarbeiter k nnen direkt in ein Projekt integriert werden nachdem sie die notwendigen Schulungsma nahmen durchlaufen haben Durch die extended Help sowie Toolmentoren wird die Einarbeitung erheblich vereinfacht und kann direkt am laufenden Projekt vorgenommen werden 3 Unter einem kritischen Projekt wird ein Projekt verstanden dessen Funktionst chtigkeit von Bedeutung ist Im V Modell wird zum Beispiel unterschieden ob ein Fehlverhalten Sachschaden oder Personenschaden verursachen oder sogar Menschenleben gef hrden kann Seite 99 Die Einf hrung von Prozessmodelle n nimmt Zeit in Anspruch Einarbeitung neuer Mitarbeiter Bessere Kommunikation Leitfaden Projektmanagement To Office 2 Heip Erh hung der Qualit t Bessere Integration von Unterst tzungs Werkzeugen Seite 100 e Die im RUP Prozess erstellten Artefakte sind unmissverst ndlich und eindeutig Sie vereinfachen den Qualit tssicherungs un
235. ter Geb ude bauten so wie Programmierer Programme machen dann w rde der erste Specht der vorbeikommt die Zivilisation zerst ren Ein Computerprogramm tut was Du schreibst nicht was Du willst Irren ist menschlich um die Lage wirklich ekelhaft zu machen ben tigt man schon einen Computer Murphys Gesetz wurde nicht von Murphy selbst formuliert sondern von einem Mann gleichen Namens 21 1 2Gesetze der Computer Programmierung Jedes fertige Programm das l uft ist veraltet Jedes Programm kostet mehr und dauert l nger wenn es nochmals abl uft Wenn ein Programm n tzlich ist muss es ge ndert werden Wenn ein Programm nutzlos ist muss es dokumentiert werden Ein Programm wird solange expandieren bis es den verf gbaren Speicher f llt Der Wert eines Programms steht im umgekehrten Verh ltnis zu dem Gewicht seiner Ausgabe Die Komplexit t eines Programms w chst so lange bis sie die F higkeit des Programmierers bertrifft der es weiterf hren muss Seite 195 Leitfaden Projektmanagement To Office 2 Heip Seite 196 21 1 3Golombs Merks tze zur Verwendung mathematischer Modelle Machen Sie sich keine Sorgen wegen der Erscheinungen im 33 Stadium einer ersten Modellrechnung Merksatz Cum grano salis Extrapolieren Sie nicht ber den Bereich hinaus f r den das Modell gerade noch passt Merksatz Spring nicht ins Nichtschwimmerbecken Wenden Sie keine Modellrechnung an solange Sie nicht die Ve
236. terium BMVG hat die Industrieanlagen Betriebsgesellschaft IABG in Ottobrunn dieses Vorgehensmodell entwickelt Seit 1997 wurde es f r Bundesbeh rden und deren nachgeordneten Bereichen als verpflichtender Standard festgelegt Das BMI Innenministerium hat sich dem im selben Jahr angeschlossen Das V Modell ist eine Anpassung des Standards V Modell 92 Im wesentlichen wurden dabei die Erfahrungen die mit dem Vorg nger gemacht wurden in das fortgeschriebenen Modell integriert Das V Modell an sich wirkt auf den ersten Blick vom Volumen her erschlagend und mutet sehr theoretisch an Die Originaldokumentation besteht aus drei B nden e Entwicklungsstandard e Methodenstandard e WWerkzeuganforderungen Diese sogenannte Handbuchsammlung umfasst einige hundert Seiten und ist in Einige hundert drei Ordner verteilt Doch der eigentliche Regelungsteil betr gt nu 30 Seiten der Seiten Rest besteht aus Abwicklungstexten Empfehlungen Kommentaren uvm Das Handbuch Vorurteil dass das V Modell im Gegensatz zu anderen Vorgehensweisen 50 Sammlung Mehraufwand erfordert ist falsch Der Aufwand ist abh ngig vom Ergebnis des Projektzuschnitts Tailoring Werden hier Fehler gemacht so steigt nat rlich der Aufwand Hinzu kommt dass der Aufwand zwar h her ist als der bei Chaos Programmierung sich jedoch die Zeiten f r die anschlie ende Wartung oder den nderungsdienst erheblich reduzieren Seite 105 Leitfaden Projektmanagement To Off
237. tieren und stehen dem Projekt w hrend der gesamten Projektlaufzeit unterst tzend zur Seite Anwendungsarchitektur Systemarchitektur Methoden und Werkzeuge Zentrales Datenmanagement Qualit tssicherung Systemplanung Betriebsf hrung Finanzangelegenheiten W hrend der Phasen Grobkonzept Fachliches Feinkonzept ist auf Fachdienstseite ggf noch das fachliche Datenmanagement zu beteiligen In Abh ngigkeit von Gr e Bedeutung Kritikalit t des Projektes kann es notwendig werden zus tzliche Gremien einzurichten Als Beispiel seien hier genannt Nutzerkreis Anwenderberater Kontaktmitarbeiter die bei der Einf hrungs und Inbetriebnahmephase auf Seite des Fachdienstes Unterst tzung leisten Ebenso gibt es Stellen innerhalb der Regelorganisation die u a bei folgenden Problemstellungen Service Leistungen geben k nnen z B R ume und M bel bereitstellen Besprechungsr ume buchen Bereitstellen Hilfsmittel wie Metaplan W nde Fahrkarten f r Mitarbeiter Hotelbuchung Bewirtung etc Empfehlung Nehmen Sie rechtzeitig mit den entsprechenden Organisationseinheiten Kontakt auf und lassen Sie sich beraten So lernen Sie die Leute kennen und wissen wo Sie im Bedarfsfall schnell und geeignete Hilfe erhalten k nnen Seite 67 Zu beteiligende Ansprechpartne r Leitfaden Projektmanagement To Office 2 Heip 8 4Die Psycho Soziale Dimension Mindestens zwei Drittel des Projekterfolgs werden durch die psycho soziale Ebene
238. tierung erhielt Einzug in die Gesch ftsprozessmodellierung Der gro e Vorteil der dadurch gewonnen wurde lag darin dass die aus der Gesch ftsprozessmodellierung erzielten Ergebnisse direkt bei der Software Entwicklung wiederverwendet werden konnten Nachdem die Unified Modelling Language der Aktivit tsdiagramme zur Spezifizierung von Use Cases bereitstellte war die wesentliche Voraussetzung geschaffen Gesch ftsprozesse nun nicht nur visuell zu modellieren sondern auch visuell zu spezifizieren Die UML gestattet auch eine textuelle Spezifikation der USE Cases Seite 97 Festlegen einer Vorgehensweise Definition Prozessmodell UML als Grundlage Leitfaden Projektmanagement To Office 2 Heip Vier Submodelle Seite 98 12 4Prozessmodelle als Br cke zwischen unterschiedlichen Disziplinen Bereits in den vorherigen Abschnitten ist darauf eingegangen worden dass mangelnde Kommunikation sei es zwischen den Mitarbeitern im Projekt oder zwischen den im Projekt eingesetzten Werkzeugen eine wesentliche Ursache f r Probleme bei Projekten in der Software Entwicklung ist Prozessmodelle greifen hier besonders wirksam da sie den Softwareentwicklungsprozess als ganzes sehen und nicht zwischen den einzelnen Disziplinen der Softwareentwicklung unterscheiden Dies wird z B im V Modell 97 deutlich wo die 4 Submodell Softwareentwicklung Projektmanagement Konfigurationsmanagement Qualit tssicherung bergreifend be
239. tierung von ITIL erlaubt dass alle Bereiche der IT mit einer einheitlichen Sprache kommunizieren die gleichen Modelle und Prozesse anwenden Durch die Einf hrung des Frameworks gewinnt die gesamte IT in einem Unternehmen an Transparenz bspw Eindeutige Schnittstellen und somit weiter auch an Effizienz einfachere Messbarkeit Ein weiterer wesentlicher Vorteil von ITIL ist dass es nicht vorschreibt wie die Anforderungen umzusetzen sind Seite 117 Leitfaden Projektmanagement 10 Office 2 H elp Seite 118 Abbildung 27 ITIL Supporting Processes Services Supporting Processes Management Infrastructure So ist durch ITIL eine h here Flexibilit t gegeben Es lassen sich noch etliche Vorteile von ITIL finden hier sei an dieser Stelle jedoch auf die entsprechende Literatur zu ITIL verwiesen ITIL Rahmenwerk ITIL umfasst in der aktuellen Revision sieben Kernpublikationen siehe Abb Es f llt auf dass die gesamte IT hier von zwei Sichten aus betrachtet wird Einmal die unternehmerische Sicht The Business und weiters die technologische Sicht The Technology Leitfaden Projektmanagement To Office 2 Heip Abbildung 28 Kernpublikationen Planning to Implement Service Management Beschreibt die Planung Implementierung und die kontinuierliche Optimierung der ITILProzesse Beginnend mit einer Vision Formulierung der Ziele und ermittelt der aktuellen Ist Situation Business Perspective Stellt
240. tr ge d Einweisung Dabei bedeutet ein Arbeitsabschnitt den kleinsten Bezugspunkt innerhalb des Submodells Projektmanagement Ein Beispiel w re die Definition des Arbeitsauftrags Ein Planungsabschnitt hingegen umfasst eine Reihe von Arbeitsabschnitten Es l sst sich festhalten dass das Projektmanagement in erster Linie in Form von Zyklen durchgef hrt wird Das bedeutet dass das Projektmanagement sich an die Gegebenheiten im Projekt insbesondere falls es sich um ein Projekt handelt das inkrementell und iterativ abgewickelt wird anpassen muss Hierbei werden diese Vorteile aus dem Spiralmodell genutzt Periodische Die meisten Hauptaktivit ten in diesem Submodell zeichnen sich dadurch aus Durchf hrung dass sie kontinuierlich durchgef hrt werden und somit keine Teilaktivit ten haben von Aktivit ten Gewisse andere Aktivit ten werden periodisch durchgef hrt Diese Vorgehensweise erfordert nat rlich vom Projektmager nicht nur Erfahrung sondern auch ein H chstma an Flexibilit t Seite 112 Leitfaden Projektmanagement Q Office 2 Heip 12 7 4V Modell XT Der vormalige Standard das V Modell 97 der ma geblich von der IABG entwickelt wurde wurde seit 1997 nicht mehr an die Neuerungen der Informationstechnologie angepasst worden Deshalb wurde vom BMVg IT AmtBw und BMI KBSt das Projekt Weiterentwicklung des Entwicklungsstandards f r IT Systeme des Bundes auf Basis des V Modell 97 WEIT bei der T
241. tun Mehr zum Thema Anforderungs und Change Management finden Sie weiter hinten im Leitfaden 10 1 9Wechselnde Technologien Die Computerbranche zeichnet sich durch einen kontinuierlichen Technologiewechsel aus Dies betrifft sowohl die Hardware als auch die Software Bei der Hardware ist der st ndige Technologiewechsel allerdings eher als eine Hardwareoptimierung und Preisreduzierung zu bezeichnen als das ein echter und revolution rer Technologiewechsel stattfindet Hingegen bei der Softwareentwicklung kamen in den letzten Jahren revolution re Technologien auf den Markt Weg von der strukturierten Entwicklung hin zur objektorientierten komponentenbasierten Entwicklung Seite 81 Q Office 2 Heip Zu fr he und zu pr zise Formulierung von Anforderungen Die Computer branche zeichnet sich durch einen kontinuierlichen Technologie wechsel aus Leitfaden Projektmanagement To Office 2 Heip Neu Technologien zur L sung aus dem Dilemma Seite 82 Doch Technologiewechsel haben auch gewisse Risiken so fallen zus tzliche Ausbildungskosten f r Mitarbeiter an Investitionen in Werkzeugumgebungen werden notwendig und was sicherlich am gravierendsten ist die wertvollen Erfahrungen die in fr heren Perioden mit alten Technologien gewonnen wurden sind nun berholt Warum werden also neue Technologien gerade in der Informationstechnik st ndig eingef hrt die ohnehin schon Probleme genug hat Softwarekrise Nu
242. tungen vergangener Jahre bzgl Effizienzsteigerung beim Einsatz von CASE Tools gewichen sind und mittlerweile durch eine eher n chterne Einsch tzung ersetzt wurden so bleibt dennoch festzuhalten der konsequente Einsatz von Methoden und Werkzeugen schafft die Voraussetzungen f r die Transparenz Qualit t und Vergleichbarkeit der Ergebnisse und nicht zuletzt f r die Wiederverwendung von Datenmodellen Komponenten und Bausteinen Die f r den Einsatz beim Auftraggeber vorgesehenen CASE Tools und sonstigen Werkzeuge im Umfeld der Software Entwicklung sind im IT Warenkorb aufgef hrt Als Werkzeug f r die Projektplanung und steuerung ist das Tool MS Project vorgesehen F r den Bereich Werkzeuge und Tools gibt es in diesem Leitfaden einen eigenen Abschnitt 17 6Projektdokumentation Das Projekthandbuch enth lt alle organisatorischen methodischen und sonstigen Festlegungen die w hrend der Projektlaufzeit getroffen werden und an einer zentralen Stelle dokumentiert sein sollen Das Projekthandbuch ist kein Ersatz f r die Verfahrensdokumentation Eine Verfahrensdokumentation entsteht im Anwendungsentwicklungsprozess und enth lt die geforderten Entwicklungsergebnisse Seite 167 CASE Werkzeuge Einsatz von Werkzeugen beim Auftraggeber Projekt handbuch Leitfaden Projektmanagement Q Office 2 Heip Projekt berichtswesen Seite 168 17 7Berichtswesen Das Projektberichtswesen stellt den geregelten Informationsflus
243. ufbauorganisation allgemein nnnnnnnnnnunnunununuununnnnnnnnnunnnnnunnunn 56 8 1 1 Organisation nach BABTETEI ni 2a ae er 56 8 1 2 Organisation nach FOnkEiSian ee 56 8 2 Die Projektorganisation uuunuuununnunnnnunnunnunnunnunnnnnnnnuunnnnnnnununnnnnnnnnnunnnnn 57 E21 leame Bilden und TUNTO ee een 57 8 2 2 Die Gr e der Arbeitseinheiten u eisernen 59 SEIT EENENUFNN en e e a EE a 61 o2 APTOS KIOO cusna EN 62 8 2 2 FIRE ee 63 9 Prole kivorpere MNO aaa ea has Anh 75 9 1 Projektausl ser IPEUUVERUEEENEETESTTERTFTTTTETTEUFTTTERTETETELTTTFESTEEEDETEELUTTELDTTESTESPERSETEISESTOE 75 10 1 2 Das Ziel ndert sich w hrend der Projektarbeit 78 10 1 3 Der Endtermin verschiebt sich nach vorna uuuceessssunsansauasssunsauunsune 79 10 1 4 Umfangreiche Anderungsw nsche nensaouunnnnnnnonnnnnunnnunnnnnnnnnn 79 10 1 5 Unbezahlte Rechnunge N eier 80 10 1 6 Fehlen eines Defect Tracking Werkzeuges nnnanssanannnanaaannnn 80 10 1 7 Typische interne Warnsignale sssessssnnnsssnnnnnnnnnnnnnnnnnnnnnnnnennnnnnnnne 80 10 1 8 Unklare Anforderungen sssnnsesssennnnnonnnnnnnnnennnnnnssnennnnnnnrennnnenenee 81 10 1 9 Wechselnde TSchnolgeen a ee 81 Leitfaden Projektmanagement Q Office 2 Heip 10 1 10 Mangelnde Kommunikation im Projekt 83 1 1 11 Zu spate Megalo ee 85 10 1 12 Zu hohe Dokumentenorientierung zzz
244. umindest die folgenden Punkte Leitfaden Projektmanagement Q Office 2 Heip e Zu erreichende Vertragsziele e Leistungsumfang und Spezifikation e Verg tung Anschlie end kommen dann noch weitere Punkte wie z B Zeitplan Umfang der Arbeiten Repr sentanten Test und Abnahmevereinbarungen 17 1 1 3Ergebnis Der Vertragsgegenstand ist das Kernst ck des Projektvertrages Er sollte mit gr tm glicher Sorgfalt formuliert werden Sowohl Techniker als auch Kaufleute und eventuell Juristen sollten ihn gemeinsam formulieren und festlegen AGB k nnen als Checkliste dienen 17 2Richtlinien Standards 17 2 1Richtlinien allgemein Alle beim Kunden Auftraggeber g ltigen Vorschriften gelten selbstverst ndlich auch f r Projekte Explizit gelten f r Projekte bei Kunde XYZ folgende Verfahren Vorschriften F gen Sie hier die jeweils g ltigen Vorschriften ein e XYZ e XYZ e XYZ 17 2 2Richtlinien zur Anwendungsentwicklung Den Richtlinien zur Anwendungsentwicklung liegt das Software Entwicklungs Vorgehens Modell SEVM zugrunde das vom BVB Phasenmodell abgeleitet ist Die detaillierten Bestimmungen sind in den Leitf den den Produktnormen und Hilfsmitteln sowie den Mustergliederungen aufgef hrt Beabsichtigtes Abweichen von der dort vorgesehenen Vorgehensweise sind mit den zust ndigen Organisationseinheiten abzustimmen und m ssen vom Review Board genehmigt werden Diese Richtlinien zur Anwendungsentwicklung bzw SW Erstell
245. und Effizienz Coaching Leitfaden Projektmanagement To Office 2 Heip Computer Integrated Railroading Seite 54 Als letztes spielt die soziale Komponente insbesondere die Integration des Coaches und externer Projektmitarbeiter innerhalb des Teams eine entscheidende Rolle Diesen Punkt vernachl ssigen bisweilen die traditionell eher technikorientierten IT Firmen ebenso wie viele Trainingsunternehmen Damit also ein Projekt erfolgreich ablaufen kann bedarf es also einer fundierten Ausbildung Die Dauer dieser Grundausbildung h ngt von den Kenntnissen des Teams ab der Umfang der weiterf hrenden Schulungen vom Projektziel Bei einem gro en Team ist es sinnvoll f r Spezialgebiete kleinere Gruppen zu bilden die sich ausschlie lich oder insbesondere mit ausgew hlten Themen besch ftigen Erst wenn alle erforderlichen Grundkenntnisse erlernt sind kann das Team als Gruppe ein Projekt starten Zus tzlich lernt das Team dann durch Trainings Workshops und die t gliche Arbeit die gelegentlich durch einen Coach betreut wird den sicheren Umgang mit den Technologien und deren zielgerichteten effizienten Einsatz Nur auf diese Weise lassen sich Fehler vermeiden welche die Zuverl ssigkeit und Performance beeintr chtigen sowohl in puncto Architektur und Design als auch bei der Realisierung Codierung Die Einf hrung eines systematischen Qualit ts und Testkonzepts steigert die Qualit t noch einmal dramatisch 7 2Gesamtzus
246. und Verantwortlichkeiten f r die Personen die das Projekt managen und durchf hren PRINCE2 geht davon aus dass Projekte in einer Kunde Lieferant Umgebung ablaufen Die wichtigsten Rollen sind Lenkungsausschuss Auftraggeber Benutzervertreter Lieferantenvertreter Projektmanager Projektsicherung Leitfaden Projektmanagement Q Office 2 Heip Optionale Rollen sind e Teammanager e Projektunterst tzung 12 7 8 11 3Pl ne PRINCE2 Pl ne m ssen vor ihrer Umsetzung genehmigt werden Es werden drei Ebenen von Pl nen unterschieden e Projektpl ne e Phasenpl ne e Teampl ne Bei Projektabweichungen wird als vierte Art von Plan ein Ausnahmeplan verwendet der den Phasenplan ersetzt 12 7 8 11 4Steuerungsmittel Steuerungsmittel stellen sicher dass die richtigen Produkte zur richtigen Zeit hergestellt werden und dass das Projekt im Sinne des Business Case durchf hrbar bleibt PRINCE2 folgt dem Konzept Management by Exception Daher gibt es ausdr cklich keine Anforderung standardm ig Sitzungen mit dem Lenkungsausschuss einzuberufen andererseits wird der Lenkungsausschuss aber unmittelbar informiert wenn Ausnahmen auftreten Die wichtigsten Arten von Steuerungsmitteln sind Projektinitiierung Projektstatusberichte Ausnahmeberichte Ausnahmebewertung Phasenabschlussbewertung Projektabschluss Toleranz 12 7 8 11 5Risikomanagement Jedes Projekt ist ein einmaliges individuelles Unterfangen und damit Gegen
247. und vor allem die vereinbarte Dauer sollte unbedingt eingehalten werden wenn auf lange Sicht die Funktionsf higkeit dieser Ma nahme gew hrleistet sein soll Am Ende dieser Sitzung sollten alle Mitarbeiter ber den Status des Projektes im Bilde sein Alle w hrend der Sitzung besprochenen Punkte m ssen in einem vorl ufigen Sitzungsprotokoll zusammengefasst werden und zeitnah z B innerhalb von 24 Stunden an die Projektteilnehmer und einen definierten Adressatenkreis zu verteilen Die Sitzungsteilnehmer sollten wieder zeitnah auch hier sind 24 Stunden vorzusehen auf das Sitzungsprotokoll reagieren und eventuelle Anmerkungen Korrekturen etc einbringen Anschlie end wird das Protokoll als endg ltiges Protokoll an alle Adressaten verteilt 8 3Projektumfeld 8 3 1Auftraggeber Zu jedem Projekt muss es einen klar benannten Auftraggeber Besteller geben Er ist u a verantwortlich f r Formulierung der Aufgabenstellung Projektauftrag Bereitstellung der Anwendervertreter nach Zahl und Qualifikation Bereitstellung der Finanzmittel fachliche Entscheidungen w hrend der Projektarbeit bzw den Review Terminen e die Umsetzung des Anwendungssystems in die Gesch ftsprozesse und die Erreichung des erwarteten Nutzens e Unterst tzung der Projektleitung Er wird vom Projektleiter u a informiert ber e Fortschritt des Projektes erledigte Aufgaben e Ressourcenverbrauch Zeit und Geld e Vorgesehene Test und Abnahmetermin
248. ung einer Funktionsstruktur um eine ergebnis und sachbezogene Arbeit sicherzustellen e Zuordnung von Aufgaben Verantwortung und Kompetenzen e Definition einer klaren Struktur um bei nderungen von Zielen und Randbedingungen des Projekts schnell reagieren zu k nnen Hier wird aber auch schnell wieder deutlich dass die Zuordnung von Kompetenzen alleine nichts bringt Die Mitarbeiter m ssen auch bereit sein die Kompetenzen zu Seite 33 Leitfaden Projektmanagement Q Office 2 Heip Seite 34 nutzen und Verantwortung zu tragen Das erreicht man nicht durch formalisierte Strukturen sondern durch Personalentwicklung und durch die Auswahl der richtigen Mitarbeiter Man erreicht es auch indem R ckgrat belohnt wird Nichts ist kritischer f r die Projektkultur als Mitarbeiter die konsequent ihren Job erledigen daf r zu bestrafen Auch wenn der Prophet im eigenen Lande bekanntlich nichts gilt sollte er doch geh rt werden Man muss nicht immer einen teuren Unternehmensberater kommen lassen um sich die Meinung noch einmal best tigen zu lassen Dieser Bereich ist eine anspruchsvolle F hrungsaufgabe da nat rlich nicht alles was Mitarbeiter machen sinnvoll ist Hier ist viel Fingerspitzengef hl gefordert um aus Sicht des Unternehmens und nicht einer einzelnen F hrungskraft richtige Handlungsweise bewusst zu unterst tzen und kritische Entwicklungen zu bremsen ohne dass es zur Frustration von Projektmitarbeitern kommt D
249. ung werden regelm ig an die Neuerungen in der Informationstechnologie angepasst und fortgeschrieben Als Beispiele seien hier genannt e objektorientierte Entwicklung e Client Server Anwendungen e wissensbasierte Systeme e Data Warehouse Der bergabe realisierter Anwendungen an die Betriebsf hrung und Wartung ist besondere Aufmerksamkeit zu schenken Eine rechtzeitige Information und Seite 159 Richtlinien f r IS Projekte SEVM Betriebsf hrung und Wartung Leitfaden Projektmanagement Q Office 2 Heip Abnahme bedingungen Standards Seite 160 Absprache mit den verantwortlichen Personen tr gt wesentlich dazu bei die IS Anwendung geordnet in die Betriebsf hrung und die Wartung zu bernehmen Als Grundvoraussetzung f r die bernahme realisierter Anwendungen in die Betriebsf hrung und die Wartung m ssen alle Abnahmebedingungen erf llt sein Wie die Abnahmebedingungen im einzelnen aussehen wird in den zugeh rigen Dokumenten Hilfsmittel und Produktnormen zur Projekt Anwendungsintegration innerhalb der Phase Einf hrungsunterst tzung n her beschrieben Bei vernetzten Anwendungen im C S Umfeld ist in der Regel ein h herer Integrationsaufwand als bei klassischen Mainframe Anwendungen anzusetzen In den oben genannten Dokumenten werden beschrieben e die bestehende Architektur und Ihre Nutzungsm glichkeit e die bestehende Betriebsf hrungsarchitektur und ihre Leistungsf higkeit und e der Pro
250. ungen Datenmanagement Betriebsf hrung Betriebsrat Datenschutzbeauftragter e Sicherstellung vollst ndiger und aktualisierter Dokumentationen e Ordnungsgem e Beendigung des Projektes Hinzu kommen m glicherweise T tigkeiten die technische Detailkenntnisse u a in den Bereichen Datenbanktechnologien Netzwerktopologien Anwendungsentwicklung Programmierung Anwendungsintegration Betriebsf hrung etc voraussetzen 6 1 1Falsche Besetzung in Projekten Oft werden Mitarbeiter zu Projektleitern benannt ohne dass die entsprechenden Voraussetzungen gegeben sind Die Mitarbeiter werden nicht geschult und bekommen auch sonst wenig Unterst tzung im Bereich des Projektmanagements Ein L sungsansatz zu diesem Problem w re an einem Einf hrungsseminar zum Thema Projektmanagement teilzunehmen Ein Projektmanagement Training f r Einsteiger dauert meist nur ein bis zwei Tage und soll dazu dienen innerhalb dieser kurzen Zeit einen Abriss zu dem Thema zu geben Dort werden die Grundbegriffe des Projektmanagements gekl rt und eine Einf hrung in die Projektplanung und Projektorganisation gegeben Leitfaden Projektmanagement Q Office 2 Heip Betrachtet man hingegen die Kosten die selten unter 600 pro Tag liegen fragt man sich ob der Kauf eines Fachbuchs f r 30 bis 50 nicht auch gen gen w rde Vor allem bei Freiberuflern die nicht immer soviel Budget f r Trainings offen haben Diese Entscheidung muss individuel
251. ungsunf hig e der Kunde ist mit den vom Projektleiter oder Projektteam erbrachten Leistungen nicht zufrieden Welche dieser M glichkeiten auch zutrifft es k nnte ein Scheitern des Projektes bevorstehen 10 1 6Fehlen eines Defect Tracking Werkzeuges e Es wurden Fehler behoben und kurze Zeit sp ter tauchen eine Reihe neuer Fehler auf und werden gemeldet Nun zeigt es sich wie genau Sie feststellen k nnen ob das Projekt bereits einen gewissen Reifegrad erreicht hat und eine Behebung aller hoch priorisierten Defekte bis zum Projektabschluss gew hrleistet ist Ohne ein vern nftiges Defekt Tracking Werkzeug ist dies nicht zu erreichen Es k nnen jetzt ernsthaft Probleme auftauchen und das Projekt so ins Wanken bringen Bisher wurden in erster Linie Symptome aufgezeigt die von au en auf das Projekt einwirken Doch ein Projekt kann auch durch interne Einfl sse zum scheitern gebracht werden 10 1 7Typische interne Warnsignale e Werden Ihnen die besten Mitarbeiter und Know How Tr ger entzogen und in einem anderen wichtigen Projekt eingesetzt dann ist ein extrem kritischer Punkt erreicht e Stellen sie typische Erm dungserscheinungen bei ihren Projektmitarbeitern fest wie z B h ufige Krankmeldungen 9 5 Mentalit t st ndig schlechte Laune usw Dann ist die Motivation des Teams das Projekt erfolgreich zu beenden sehr gering 1 Unter 9 5 Mentalit t versteht man dass ein Mitarbeiter sich strikt an sei
252. unkt integriert werden Nach diesen vorarbeiten greift der Kontrollmechanismus des Spiralmodells In einem Review werden die Projektfortschritte des letzten Zyklus analysiert die Ergebnisse bewertet und die Projektperspektiven diskutiert bis unter allen beteiligten Parteien Konsens ber die Situation im Projekt besteht Sind z B die technischen oder wirtschaftlichen Risiken einer Projektfortsetzung zu hoch so endet die Spirale und das Projekt an diesem Punkt Erfolgt kein vorzeitiger Projektabbruch so liegt am Ende der letzten Windung die neue oder modifizierte Software installiert vor und im letzten Review erfolgt ein abschlie ender Teil der Anfangshypothese auf Basis des realen Ablaufs 12 7 2 5lnitialisieren bzw Beenden der Spirale Die Spirale wird durch die Aufnahme von Anwenderanforderungen initialisiert Die Formulierung des Ziels und die Entwicklung konkreter L sungsvorschl ge bilden den Beginn des ersten Spiralzyklus Die Spirale endet bei der Installation der neuen oder modifizierten software Leitfaden Projektmanagement Q Office 2 Heip 12 7 3Das V Modell Das V Modell existiert in seiner ersten Version seit 1992 und wird seitdem im Das V Modell ffentlichen Bereich als Standard f r die Softwareentwicklung eingesetzt Die existiert in 2 fortgeschriebene Version V Modell 97 findet neben dem ffentlichen Bereich auch Versionen zunehmend Verbreitung im Banken und Versicherungsumfeld Im Auftrag des Bundesverteidigungsminis
253. urch die Anwendung einheitlicher Regeln und Methoden soll die Qualit t Transparenz und Effizienz der Projektarbeit erh ht werden Nutzen des Der Leitfaden verfolgt einen prozessorientierten Ansatz Prozessmodelle werden Leitfadens hierzulande auch als Vorgehensmodelle bezeichnet Sie regeln oder sollen regeln den gesamten Prozess der innerhalb eines Projektes z B in der Softwareentwicklung Im Wesentlichen haben Prozessmodelle eins gemeinsam Sie definieren Aktivit ten und legen Produkte Artefakte fest die Ergebnis dieser Aktivit ten sind Ferner bestimmen sie eine gewisse Reihenfolge in der diese Aktivit ten abzuarbeiten sind Im Laufe der vergangenen Jahre wurden verschieden Prozessmodelle Regelwerke und Vorgehensmodelle publiziert besonders bekannte Modelle sind Wasserfallmodell Spiralmodell V Modell CMM CMMI SPICE Prince Prince2 ITIL Microsoft Solutions Framework Rational Unified Process Gesch ftserfolg Wir orientieren uns in diesem Leitfaden schwerpunktm ig am und Microsoft Solution Framework sowie dem Rational Unified Process Informations in deren 4 Phasen Systeme e Anforderungsanalyse und management auch Erwartungsmanagement e Design e Realisierung e Rollout und Betriebsf hrung Das beste aus beiden Vorgehensmodellen kombiniert mit Betrachtungen zum Risikomanagement und in Gro projekten gewonnenen Erfahrungen soll sicherstellen dass m glichst alle Facetten in einem Proje
254. utage in im Wesentlichen von der Effektivit t seiner Informationsbeschaffung bereitstellung und verarbeitung ab Moderne Unternehmen sind deswegen bestrebt ihre Informationssysteme kontinuierlich zu verbessern und auszubauen Die im Rahmen dieses Aus und Umbaus notwendigen T tigkeiten e m ssen wirtschaftlich begr ndet sein e m ssen L sungen hervorbringen welche die Anwender und das Unternehmen effektiv bei der Informationsbearbeitung und Informationsverarbeitung unterst tzen e m ssen in einem definierten Zeitraum realisiert werden und e d rfen einen kalkulierten und festgelegten Kostenrahmen nicht bersteigen T tigkeiten werden deshalb in Projekten zusammengefasst Erfahrungen aus der Praxis des Projektmanagements und der Projektsteuerung mit Schwerpunkt auf EDV Softwareprojekte werden in diesem Leitfaden umfassend beschrieben Der Leitfaden geht im weiteren auch auf allgemeine Projekt Rahmenbedingungen wie z B der Zusammenstellung eines Projekt Teams ein Seite 11 Gesch ftserfolg und Informations Systeme Leitfaden Projektmanagement To Office 2 Heip 3Zielgruppen Zielgruppe Die Zielgruppe des Leitfadens sind alle mit der Initiierung und Durchf hrung von Projekten befassten Personen Dieser Leitfaden Projektmanagement ist als ein st ndiger Begleiter f r die Projektbeteiligten gedacht Er ber t und gibt Auskunft in allen strukturellen und organisatorischen Angelegenheiten eines Projektes D
255. uzuuuuuuununnununussunssusnuanen 86 10 1 13 Fehlende Prozessmodelle ccccoccnsenooonnanonnnnannnnnnannnnnannnnnnannen 87 101 14 Soziale Faktsren ai sense 87 10 1 15 Das Kostanziel wird berz6B n ieussiriisinenininieriniinienreeee 88 10 1 16 Mangelhafte berwachung des Projektfortschritts 88 10 1 17 Mangelnde Ausbildung snisssnesssnesssnnsiuiesintentniunneinhe 89 10 1 18 Fehlende Ressourcen ccoccocenveaaooonennansannnnanansannasnanannanannannnnaann 90 10 1 19 Fehlende Diallstesichar und nee 90 10 1 20 Nichtbeachtung der 80 20 Regel nnnnsnnnnnnnnnnnnnnnnnnnnnnnnnsnnnnnnnennne 92 10 2 ZusammenmiassSU L PRRENERRENEBEREREEREREEREERELEREREEENEEEREESEENEEEHNEFEEBEBEEDERTERREERERNEFERERERS 92 IE a E E T E a E E E E ee 93 11 Die 4 Prpieklah agent er 94 11 1 Anforderungsanalyse und management auch Erwarlungsm anagemenl iieissirizuenieninieienhe inneren 94 11 2 Desl on eisen EAE A AEEA 94 11 3 Be lisierung 2 nee 94 11 4 Rollout und Betriebsf hrung uuuuuunuununnnuunununnannnnnunnnnnannunnnnunnnunnunnnn 94 12 PIO2BES5 180 a a 95 12 1 Eine Einf hrung in Prozessmodelle uuuuusonauunnnnnnnuununuuunnnunnunnnnnnnnnn 95 12 2 Warum brauchen wir Prozessmodelle unauunaunnnaunnanunnnnunnanunnnuunnnunn 96 12 3 Gesch ftsprozessmodellierung als Basis f r Prozessmodelle 97 12 4 Prozessmodelle als
256. werden e Die daf r ben tigten Ressourcen ermittelt werden o Monet r o Zeitlich o Personell e Die Realisierung geplant wird o W hrend aktiven Projekt o Nach dem Projekt e Der Rollout geplant wird o Patch o Subrelease Nicht selten beginnt die Planungsphase eine Folgeprojektes bereits w hrend der Endphase eines aktiven Projekte In solchen Situationen ist mit u erstem Fingerspitzengef hl und unter Einbindung aller Beteiligten w hrend des Anforderungs und Change Prozesses vorzugehen Seite 133 Leitfaden Projektmanagement To Office 2 Heip 14Erwartungsmanagement Das Erwartungsmanagement ist als hoch Politisch einzustufen Stellen sie sich nur einmal vor Ihnen wird von Ihrem Maler versprochen Ihre Wohnung innerhalb einer Woche zu renovieren und zwar so wie sie es mit ihm abgesprochen haben Farbe Tapeten Zeitdauer und finanzieller Aufwand Nun fahren Sie eine Woche in Urlaub und freuen sich schon auf Ihre neu renovierte Wohnung Nach einer Woche kommen sie zur ck und stellen fest dass die Wohnung noch gar nicht fertig renoviert ist In der K che sind die alten Flie en entfernt jedoch die neuen stehen noch eingepackt auf dem K chenboden Die Tapete im Wohnzimmer ist bei weitem nicht die Qualit t die Sie mit dem Maler vereinbart hatten und dann erst die Farbgebung im Schlafzimmer es entf hrt Ihnen ein Urschrei Sicher ist das alles konstruiert aber glauben sie mir die Wirklichkeit bei Softwareproj
257. zess der Integration in die Betriebsf hrungsumgebung Im Rahmen dieses Prozesses wird e der nderungsbedarf an die Architektur und deren Leistungsf higkeit definiert e die Ressourcenplanung f r die Systemplattform und die Betriebsf hrung sowie e deren Realisierung beauftragt Dabei k nnen je nach Komplexit t des Projektes erhebliche Sprungkosten auf beiden Seiten entstehen Eine genaue Termin und Aufwandssch tzung ist ohne die Beachtung und Einhaltung der in den o g Dokumenten gemachten Aussagen nicht m glich 17 2 3Standards Ein Standard in Bezug auf Informationssysteme und Kommunikationssysteme oder Komponenten ist eine beschr nkte Auswahl von Methoden und Produkten z B Hardware Software Netzkomponenten etc die f r die Anwendung in einzelnen Projekten Anwendungen zugelassen sind Die Standards sollen sinnvoll in ihrer jeweiligen Umgebung eingesetzt werden Man unterscheidet zwischen herstellerspezifischen Standards und allgemeinen Standards die von internationalen bzw nationalen Standardisierungsgremien verabschiedet werden Als Standard f r Projekte kommen nur solche Produkte infrage die sich am Markt durchgesetzt haben und die als zukunftsweisend gelten k nnen Standards sind erforderlich um wegweisend die Richtung aufzuzeigen in die die k nftige Entwicklung weitergehen wird um eine weitgehend homogene und damit kosteng nstige Basis f r die Informationstechnik und Telekommunikation zu gew hrleist
258. zubeugen Dabei h ngt es sicher in erster Linie von der berzeugungskraft und dem Durchsetzungsverm gen des Projektleiters ab in wieweit dieser Erfolg sich signifikant auf den Gesamterfolg des Unternehmens auswirkt 10 2 1Fazit Der Projekterfolg ist von vielen Faktoren abh ngig Viele Probleme k nnen durch vern nftige Planung vermieden werden Andere kritische Faktoren m ssen durch Pr fmechanismen erkannt werden damit sofort darauf reagiert werden kann Ein Projektleiter hat durch Schulung ausf hrliche Vorbereitung offene Kommunikation und vor allem saubere berwachung und Durchf hrung direkten Einfluss auf den Projekterfolg Der Mensch steht im Mittelpunkt des Projekts er ist daher auch der wichtigste Erfolgsfaktor Seite 93 Leitfaden Projektmanagement To Office 2 Heip Seite 94 11Die 4 Projektphasen 11 1Anforderungsanalyse und management auch Erwartungsmanagement Klare schriftliche Fixierung der Anforderungen geordnet nach Priorit ten Explizite schriftliche Zustimmung der Auftraggeber bei mehreren Auftraggebern Teilauftraggebern die Zustimmung aller 11 2Design Klare schriftliche Fixierung der Design Eckpunkte geordnet nach Priorit ten Definition von Meilensteinen und Dauer der Einzelaufgaben Am Ende des Designs wird eine Liste der 5 oder 10 gr ten Risiken aufgestellt Diese Risikoliste wird kontinuierlich nachverfolgt Es werden keine neuen Anforderungen aufgenommen es sei denn als Ersatz f

Download Pdf Manuals

Related Search

Related Contents

取扱説明書 - マックスレイ  Mode d'emploi  ID TECH Omni Duo  Istruzioni d`uso ed installazione  Cables Direct CB-012  浴室用換気扇 UF-24A 取付工事・・取扱説明書 安全のために  EXSYS EX-11494    Manuel d`utilisation d`HyperMed 2008 et DermatoSup  Dimension One Spas 01510-1030E User's Manual  

Copyright © All rights reserved. Failed to retrieve file