Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen

Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen 16OH21005 gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt beim Autor/bei der Autorin.

Open IT Zertifikatsstudiengang Wirtschaftsinformatik Modul 8361: IT-Dienstleistungsmanagement / IT-Projektmanagement IT-Projektmanagement Teil 2: Projektinitialisierung (2/2) Dr. P. Steffen IT-PM 2.2-1

Inhalte Einführung Projekt-Initialisierung Planung von Projekten Steuerung und Kontrolle von Projekten Projektabschluss Agile Methoden im Projektmanagement Dr. P. Steffen IT-PM 2.2-2

Aufgaben in der Initialisierungsphase Vom Ziel zum Projektauftrag Zielplanung Ideenfindung Lasten- und Pflichtenheft Stakeholdermanagement Risikomanagement Projekt strukturieren (Grobplanung) Wirtschaftlichkeitsbetrachtung Projektantrag Auftrag Kick-off Teambildung Dr. P. Steffen IT-PM 2.2-3

Inhalte & Zusammenspiel Lastenheft / Pflichtenheft Was und wofür Wie und womit Inhalte Zielbestimmung Produkteinsatz Produktfunktion Produktdaten Produktleistungen Qualitätsanforderungen Mögliche Ergänzungen Dr. P. Steffen IT-PM 2.2-4

Was ist ein Lastenheft, was ein Pflichtenheft? Lastenheft gehört dem Auftraggeber wird vom Auftraggeber verfasst DIN 69905: die vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages Im Lastenheft stellt der Auftraggeber seine Anforderungen an das Projekt Beschreibung des Problems behandelt das WAS und WOFÜR Pflichtenheft gehört dem Auftragnehmer wird vom Auftragnehmer verfasst DIN 69905: die vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts Im Pflichtenheft gibt der Auftragnehmer an, inwieweit dieses realisierbar ist Beschreibung der Lösung behandelt das WIE und WOMIT Dr. P. Steffen IT-PM 2.2-5

Projektumfeldanalyse: Stakeholder beeinflussen das Projekt und werden ihrerseits vom Projekt beeinflusst Stakeholder: Aktiv am Projekt Beteiligte Am Projekt Interessierte Potenzielle Beeinflusser des Projekts Vom Projektergebnis Betroffene Einzelpersonen oder Gruppen Partner Betroffene Abteilungen Lieferanten Auftraggeber Markt Geschäftsführung Projekt interne Stakeholder externe Stakeholder Gesetzgeber Anwender Projektteam Andere Projekte Wettbewerber Kunden Dr. P. Steffen IT-PM 2.2-7

Einflussstärke Niedrig Hoch Einordnung der Stakeholder Identifikation der Stakeholder + Key - Stakeholder - + - + - - + + - + - - - + + - + - - + + - + Niedrig Betroffenheit / Interesse Hoch Dr. P. Steffen IT-PM 2.2-8

Kommunikationsmaßnahmen für die priorisierten Stakeholder Kategorisierung Stakeholder, für die Sofortmaßnahmen erforderlich sind Stakeholder, die regelmäßig zu informieren sind Stakeholder, für die im Wesentlichen eine einmalige Information ausreicht + - Maßnahmen zur Stärkung der Förderung Lückenlose Information der Förderer Persönlichen Draht aufbauen Auch Einbeziehung von Meinungsbildnern und Multiplikatoren Maßnahmen zur Verringerung der Widerstände Pro- und Kontra-Argumente herausarbeiten Botschaften für Zielgruppen erarbeiten Vertrauensbasis schaffen Ehrliche und klare Kommunikation. Dr. P. Steffen IT-PM 2.2-9

Interessenmatrix Stakeholder Fachabteilung A1 Mitarbeiter und Leiter der Fachabteilung A2 Erwartete Unterstützung Interesse an neuer Lösung Erwartete Widerstände./. Kein Interesse, da zukünftig weniger Kompetenzen Mitarbeiter Ax./. Aufgaben des Mitarbeiters Ax werden tangiert Bereichsleiter B1 Fachabteilung C./. Hohe zeitliche Belastung der MA dauerhaft befürchtet Prozessprobleme Maßnahmen (Sofort, präventiv, etc.)./. Information zur neuen Lösung Projektmarketing Informationsveranstaltung Mitarbeiter in das Projekt einbeziehen Leiter der Abteilung in den Lenkungsausschuss des Projekts aufnehmen./. Know How in das Projekt Frequenz Tipp: werden Setzen gelöst/ Sie sich frühzeitig einbringen mit den und in potenziellen den reduziert Verlauf einbinden Widerständen proaktiv auseinander! einmalig (abhängig von Projektdauer) Präventiv, sofort Regelmäßig informieren dauerhaft Punktuell, situativ Dr. P. Steffen IT-PM 2.2-10

Zusammenfassung: Der Stakeholder- Management - Prozess 1 2 3 Potenzielle Stakeholder Stakeholder-Ziele und identifizieren Erwartungen feststellen Brainstorming im Projektteam Wer ist betroffen?: o Abteilungen, externe Lieferanten, Partner, o Prozesse und Personen, die von gesetzlichen, markttechnischen, politischen oder technologischen Rahmenbedingen tangiert werden Brainstorming vermutete Erwartungen Befragung der Stakeholder 4 5 6 Stakeholder-Wirkungen auf das Projekt analysieren Projektwirkungen auf die Stakeholder analysieren Art & Weise der Einflussnahme einschätzen (direkt/ indirekt, Stärke) Kategorien bilden 7 Betroffenheit/Widerstände/ mögliche Reaktionen ableiten Positives Interesse aufnehmen Kategorien bilden Einflussstärke der Stakeholder feststellen Brainstorming, Interviews Machtfaktoren und ausübung abschätzen Kategorien bilden Maßnahmen zum Stakeholder-Mgmt planen Maßnahmenkatalog erstellen Maßnahmen den Stakeholdern zuordnen Maßnahmen priorisieren je nach Stakeholder-Kategorie Maßnahmen anwenden, Auswirkungen analysieren Ggf. Maßnahmen anpassen Dr. P. Steffen IT-PM 2.2-11

Risiken Strukturierung Quellen für Risiken Projektstrukturplan Stakeholderanalyse Sonstige Kontextanalysen Vorhandene Risikochecklisten * In Anlehnung an an Burkhardt (2002), S. 298 Dr. P. Steffen IT-PM 2.2-13

Systematik zur Überwachung und Steuerung von Risiken (Beispiel) Nr. Risikobezeichnung 1 T Ausfall von wichtigen Personalressourcen 2 K, T Überschreitung von Zeit und Budget 3 Q, K, T Mangelnde Management- Attention bei der GF 4 T, K Mitwirkungsrechte des Betriebsrates werden berührt und nicht ausreichend behandelt 5 Q Umsetzung nicht beauftragter Anforderungen 6 Q Kommunikationsprobleme zwischen AG und AN (insbes. Anforderungen und Ziele) Alle Risiken sammeln, sowohl Stakeholder-Risiken als auch z.b. Planungs- oder Komplexitätsrisiken Möglichen Folgen/ Tragweite Kategorie Schadenshöhe Eintrittswahrscheinlichkeit Zeitlicher Verzug hoch mittel Verärgerter Kunde (zusätzliche Kosten) Insbes. in kritischen Situationen keine Unterstützung durch die GF Projekt kann kurz vor dem Abschluss gestoppt werden sehr hoch sehr hoch sehr hoch mittel gering gering Unbezahlter Aufwand mittel mittel Streit um Abnahme sehr hoch mittel 7 Q, K, T Fehler in der Planungsphase Zeitlicher Verzug und hoch gering Budgetüberschreitung 8 Q, T Neuer Lieferant für wichtige Komponenten Stillstand hoch mittel Eintrittsindikatoren Gegenmaßnahmen Dr. P. Steffen IT-PM 2.2-14

Zusammenfassung: Der Risikomanagementprozess Ziel: Projektrisiken identifizieren und bewerten, Gegenmaßnahmen aufzeigen und überwachen 1 Projektrisiken identifizieren 2 Risiken klassifizieren 3 Risiken dokumentieren Inputs: Zielplanung Umfeldanalysen Rahmenbedingungen Stakeholder-Analyse Bestehende Risiko-Checklisten Was ist in vergleichbaren Projekten schief gelaufen? Feststellen, ob bei einem Risikoeintritt o Qualitätsziele o Kostenziele o Terminziele betroffen sind. Mehrfachnennungen möglich Erkannte Risiken in einer Tabelle ( Risikoinventar ) schriftlich festhalten 4 Risiken bewerten Möglichen Folgen, Eintrittsindikatoren sowie Gegenmaßnahmen beschreiben Eintrittswahrscheinlichkeit abschätzen Potenzielle Schadenshöhe ( Tragweite ) abschätzen 7 5 Risiken kommunizieren Risiken müssen kommuniziert werden! Das gesamte Projektteam sollte Zugriff auf das Risikoinventar haben.. Präventivmaßnahmen planen und durchführen Entscheidung hierzu muss sorgfältig abgewogen werden und, da die Umsetzung in der Regel mit Kosten verbunden ist bzw. zu Terminverschiebung führen kann, mit dem Auftraggeber abgesprochen werden. Risiken überwachen über den gesamten Projektverlauf 6 Dr. P. Steffen IT-PM 2.2-15

Planungsbedarf bei einem IT-Vorhaben (schematisch) Initialisierung Informieren über Aufgabenstellung, Ziele, Rahmenbedingungen Konzeptionsphase Erarbeitung von Lösungsvorschlägen, bzw. Systemkonzepten Fertigstellung des IT-Produktes Planungs- Bedarf Hier evtl. Machbarkeitsstudie Realisierungsphase Einführungsphase Produkteinführung, Dokumentation des Projektes Am Ende einer Phase wird oft ein Meilenstein gesetzt! Dr. P. Steffen IT-PM 2.2-17

Machbarkeit einer Projektidee prüfen Ist die Gesamtaufgabenstellung klar? Entspricht die Zielsetzung bzw. die angestrebte technische Lösung der Unternehmensstrategie? Lässt sich die angestrebte technische Lösung in die vorhandene Infrastruktur integrieren? Lässt sich die angestrebte technische Lösung in der vorhandenen Infrastruktur betreiben? Ist der notwendige Skill/das Know How zur Projektdurchführung vorhanden oder lässt sich dieses im Rahmen der zur Verfügung stehenden Budgets beschaffen? Stehen die erforderlichen Personalressourcen zur Verfügung? Sind dem Auftraggeber die Beistellpflichten bekannt und hat er zugesichert, diesen nachzukommen? Dr. P. Steffen IT-PM 2.2-18

Setzen von Meilensteinen als ergebnisorientierte Basisstruktur jedes Projekts Meilensteine sind Ereignisse und keine Zeitpunkte! Zweck: Fortschrittsüberwachung Aktivität Aktivität Aktivität Aktivität Ergebnisse Phase Synonyme: Arbeitspaket Vorgang Tätigkeit Erkennung von Fehlentwicklungen Entscheidungshilfe über Fortführung oder Beendigung des Projekts Besondere Bedeutung: haben Controlling-Funktion definieren Zwischenetappen eines Projektes. Ergebnisse Der Meilensteinplan (auch Abwicklungszielplan ) bildet die Grundlage des Projektstrukturplans Dr. P. Steffen IT-PM 2.2-19

Projekte müssen strukturiert werden! Statt Teilaufgaben könnten hier auch Teilprojekte oder Phasen stehen! 1. Ebene Projekt typische Meilenstein- Ebene 2. Ebene Teilaufgabe Teilaufgabe Teilaufgabe Arbeitspaket Arbeitspaket Arbeitspaket 3. Ebene Arbeitspaket Arbeitspaket Arbeitspaket Teilaufgabe Arbeitspaket Ein Arbeitspaket ist der Teil des Projektes, der im Projektstrukturplan nicht weiter aufgegliedert wird und auf einer beliebigen Gliederungsebene liegen kann. [DIN 69901] Arbeitspaket Arbeitspaket Arbeitspaket 4. Ebene Zu jedem Element im PSP gehört eine eindeutige PSP-Nr. oder ein PSP-Code. Dr. P. Steffen IT-PM 2.2-20

Aufbauarten für den Projektstrukturplan Objektorientiert Haus Prozessorientiert* Haus Keller Erdgeschoss Dach Erdarbeiten durchführen Maurerarbeiten durchführen Zimmermannarbeiten durchführen Phasenorientiert Haus Gemischtorientiert Planung Haus Ausführung Planung Ausführung Abnahme Entwurf Mauerwerk Statik Dach Dr. P. Steffen IT-PM * In der Literatur auch häufig funktionsorientiert oder vorgehensorientiert genannt 2.2-21

Balkendiagramm zur Darstellung der zeitlichen Struktur (grober Ablaufplan) Synonym: Gantt-Diagramm Anforderungen 1. Quartal 2. Quartal 3. Quartal 4. Quartal Grobkonzept Feinkonzept Implementierung Test Einführung Dr. P. Steffen IT-PM 2.2-22

Wirtschaftlichkeitsbetrachtung Projekte sind Investitionsvorhaben 1. Es werden grundsätzlich nur solche Projekte durchgeführt, die sich wirtschaftlich rechnen. 2. Bei konkurrierenden Projekten werden aufgrund knapper Ressourcen - diejenigen mit der besten Wirtschaftlichkeit priorisiert. Wirtschaftlichkeitsbetrachtung Nutzen Quantifizierbarer Nutzen ( ) Nicht-quantifizierbarer Nutzen Kosten Reine Projektkosten Investitionskosten Betriebskosten Projekt- Business- Case Lebensdauer realistisch einschätzen Nutzen tritt häufig erst mit zeitlicher Verzögerung ein: Umstellungs-/ Einführungsaufwand, geringere Produktivität/Mehraufwand in der Startphase u.ä. Einsparungspotenziale müssen auch realisiert werden! Dr. P. Steffen IT-PM 2.2-24

Methoden der Wirtschaftlichkeitsberechnung Wirtschaftlichkeitsverfahren Statische Verfahren Dynamische Verfahren Bewertungs- Verfahren Kostenvergleich Gewinnvergleich Rentabilitätsrechnung Amortisationsrechnung Kapitalwertmethode Annuitätenmethode Interne Zinsfußmethode Kosten-Nutzen-Analyse Nutzwertanalyse Hauptproblem: Verfügbarkeit zuverlässiger Daten a Genauigkeit nicht übertreiben! Dr. P. Steffen IT-PM 2.2-25

Welchen Nutzen bringt das Projekt? Die Nutzwertanalyse Definition Die Nutzwertanalyse ist ein Verfahren mit dem Zweck, komplexe Projektalternativen entsprechend den Präferenzen des Entscheidungsträgers bezüglich eines multidimensionalen Zielsystems zu ordnen.* Die Nutzwertanalyse wird auch als Multifaktorentechnik oder Punktwertverfahren bezeichnet. * Quelle: Zangemeister, Ch.; Nutzwertanalysen von Projektalternativen; Expert Verlag; Greifenau 1974 Feststellen, welche Kriterien für eine Projektentscheidung wichtig und maßgeblich sein sollen. Gewichtung der Kriterien: Diese können beispielsweise als Multiplikatoren von 1 (wenig wichtig) bis 5 (sehr wichtig) gewählt werden. Beispiel 1/3: Verfahren Hinweis: Gewichtungen festlegen mittels Methode Paarvergleich Dr. P. Steffen IT-PM 2.2-26

Beurteilung von Projektalternativen (Beispiel 2/3) Dem Beispiel liegen die folgenden drei Projektvorschläge zugrunde: Diese Projekte sind nun hinsichtlich der o.g. Kriterien zu bewerten. Die Bewertung kann mit unterschiedlichen Bewertungssystemen durchgeführt werden; hier Punktwerte 10 (sehr gut) bis 1 (sehr schlecht) Dr. P. Steffen IT-PM 2.2-27

Beurteilung von Projektalternativen (Beispiel 3/3) Die Ermittlung des Ergebnisses einer NWA erfolgt in zwei Rechenschritten: 1. Multiplikation der Kriteriengewichtung mit der jeweiligen Beurteilung 2. Addition der Multiplikationsergebnisse für jedes Projekt. Dr. P. Steffen IT-PM 2.2-28

Kombination der Verfahren In der Praxis werden häufig zwei Verfahren miteinander kombiniert, um Lösungsalternativen zu vergleichen Für die monetär messbaren Kriterien: Ein statisches oder dynamisches Verfahren der Wirtschaftlichkeitsrechnung Für die nicht monetär messbaren Kriterien: Nutzwertanalyse Auswahl der Alternative durch Direktive Abstimmung Integration der monetären Ergebnisse in die Nutzwertanalyse (in Form eines eigenen Kriteriums). Dr. P. Steffen IT-PM 2.2-29

Interner Auftraggeber: Projektantrag Externer Auftraggeber: Angebot Umfang Angebot bzw. Projektantrag enthält in der Regel nur eine Grobplanung Inhalte Projektname (eindeutig, verständlich, ausdrucksvoll) Projektziel Beginn- und Ende-Termin Meilensteine Projektorganisation Auftraggeber, Projektleiter ggf. Projektsteuerungsgremium (z. B. Lenkungsausschuss ); je nach Projektdimension Liste möglicher Projektmitarbeiter Betroffene Fachabteilungen Wirtschaftlichkeitsbetrachtung Ressourcen/Kosten: Mitarbeiter-Ressourcen, Investitionen, Betriebskosten Erwarteter Nutzen [quantitativ ( ), nicht-quantitativ] Potenzielle Risiken Mögliche Qualitätsmängel, Zeitverzögerungen, Kostenüberschreitungen Mögliche Gefährdungen des Projektes. Dr. P. Steffen IT-PM 2.2-31

Der Weg zum Projektauftrag Ziele und Inhalte werden zwischen internem Auftraggeber (z.b. Vorstand oder Bereichsleiter) bzw. externem Kunden und Auftragnehmer (Projektleiter) abgestimmt Intern: Projektantrag geht zur Genehmigung an Priorisierungsgremium Nach Zustimmung zum Projektantrag wird dieser zum Projektauftrag Unterzeichnung durch Auftraggeber und Auftragnehmer (= Projektleiter) Projektauftrag ist die vertragliche Basis des Projektes Häufig gibt es zwei Detaillierungsphasen, die separat beauftragt werden: 1. Antrag / Angebot für Konzept / Pflichtenheft / Grobplanung 2. Detailspezifikation, Feinplanung, Durchführung, Abschluss Dr. P. Steffen IT-PM 2.2-32

Kick-off-Veranstaltung und Projektstartsitzung Kick-off - Sitzung Teilnehmer: Auftraggeber und Projektleiter Mitglieder des Lenkungsausschusses Ziele: Konsens zwischen dem Projektauftraggeber, dem Projektleiter sowie dem Lenkungsausschuss erzeugen Einigkeit bei allen Beteiligten bzgl. der Projektziele und inhalte Festlegung der Rollen der Projektbeteiligten Berichtswesen (AG und LA) festlegen Organisator : Leitung Projektstartsitzung Alle Projektmitarbeiter Projektleiter Projektleiter Projektleiter Vorsitzender des Lenkungsausschusses Ergebnisse: Abgestimmte Projektziele und -inhalte Projektorganisationsform Zusammensetzung des Projektteams (inkl. der Verfügbarkeit der vorgesehenen Projektmitarbeiter) Sitzungsprotokoll Vermittlung der Ziele und Inhalte des Projektes auf der Grundlage des Projektauftrages Information der Projektmitarbeiter über ihre Rolle im Projekt Projektziele, Abgrenzungen und Schnittstellen sind beschrieben Projektstrukturplan, Detailplanung /Terminplanung sind erarbeitet Arbeitspakete sind festgelegt Erzeugung eines Teamgeistes für eine reibungslose Projektarbeit Teamfindungsprozess ist eingeleitet Infos über Festlegungen aus den Kick-off- Sitzung (z. B. Berichtswesen) Projektleiter Festgelegte Projektorganisationsform Zu verwendende Sachmittel, Methoden und Werkzeuge Rollen und Aufgaben der einzelnen Projektmitarbeiter und des Projektleiters Projektstrukturplan, Detailplanung, Arbeitspakete Erteilte Aufträge zur Ausformulierung der Arbeitspaketbeschreibungen Art der Projektdokumentation Sitzungsprotokoll Dr. P. Steffen IT-PM 2.2-33

Spielregeln der Zusammenarbeit im Projektteam Informations- und Kommunikationsverhalten Grundregel: Für Informationen, die man hat, gilt Bringschuld. Für Informationen, die man braucht, gilt Holschuld Berichtswesen Wann und in welcher Form sind Statusberichte abzugeben? Wie soll an den Lenkungsausschuss berichtet werden? Kontakte zu Auftraggebern oder Betroffenen Teammitglieder dürfen keine Änderungswünsche annehmen. Dies geht nur über den Projektleiter. Kommunikation über das Projekt nach außen Grundregel bei Problemen: Keep it in the family. Nicht bei Dritten beklagen! Konflikte Wünsche rechtzeitig äußern. Ärger über Kollegen oder den Projektleiter möglichst früh zur Sprache bringen. Probleme sind wie Korken: Sie kommen immer wieder hoch! Dr. P. Steffen IT-PM 2.2-35

Teamarbeit: Festlegen von Grundwerten und Normen ( Norming ) Grundwerte und Normen zu Anfang jeder Teamarbeit festlegen, gerade auch bei virtueller Teamarbeit! Zusammenarbeitsziel (s. o.: Zielstruktur) sollten von sämtlichen Teammitgliedern schriftlich bestätigt werden Abläufe Erreichbarkeit Regeln für Telefon- und Videokonferenzen Dr. P. Steffen IT-PM Teamregeln (Beispiel) Jeder erkennt den anderen als gleichwertigen Partner an. Jeder hat immer zu 100% subjektiv recht. Die Rollen in unserem Team können sich ändern. Jeder übernimmt die Aufgabe eines anderen, wenn dies erforderlich ist. Meinungen sollen ständig herausgefordert werden. Schweigen bedeutet nie Zustimmung. Zuhören ist genauso wichtig wie reden. Konflikte werden nicht verschleiert, sondern aufgedeckt. Meinungsverschiedenheiten sind keine Störfaktoren sondern der Anstoß für eine Konfliktklärung oder eine Verbesserung. Innerhalb unseres Teams kritisiert und tadelt niemand den anderen. Jede Meinung oder Erfahrung kann in Frage gestellt werden. Jeder kann seinen Lernbedarf deutlich machen. Im Team hat jeder die Informationen, die er braucht. Alle Unterlagen stehen jedem immer zur Verfügung. Entscheidungen werden nicht durch Mehrheitsbeschluss, sondern durch Einstimmigkeit gefällt. Keiner führt eine Aktivität aus, die nicht vorher beschlossen wurde. Jeder weiß immer, was die anderen tun. Entscheidungen, Diskussions-/ Arbeitsergebnisse werden laufend festgehalten und visualisiert. Neue Aspekte und Zielabweichungen werden immer kommuniziert und besprochen. Die Einhaltung der Regeln wird beachtet. Sind die Regeln nicht mehr hilfreich, so müssen sie diskutiert werden. * Quelle: www.softskills-fuer-projektleiter.de, posted 2007 2.2-36

Ende des Kapitels Vielen Dank für Ihre Beiträge! Quellenangaben (für alle Kapitel): Burghardt, M.: Einführung in Projektmanagement, Definition, Planung, Kontrolle und Abschluss, 6. überarb. und erw. Aufl., Publicis Publ., 2013. Gloger, B., Margetich, J.: Das Scrum-Prinzip: Agile Organisationen aufbauen und gestalten, Schäffer-Poeschel, 2014. Heilmann, H., Etzel, H.-J., Richter, R. (Hrsg.): IT-Projektmanagement - Fallstricke und Erfolgsfaktoren - Erfahrungsberichte aus der Praxis, 2., überarb. und erw. Aufl., dpunkt, 2003. Jenny, B.: Projektmanagement: Das Wissen für eine erfolgreiche Karriere, 5. überarb. u. aktual. Aufl., vdf, 2016. Patzak, G., Rattay, G.: Projektmanagement: Leitfaden zum Management von Projekten, Projektportfolios und projektorientierten Unternehmen, 6. Aufl., Linde (2014). Pfetzing, K., Rohde, A.: Ganzheitliches Projektmanagement, 6. überarb. u. aktual. Aufl., Schmidt (Götz), 2017. Wieczorrek, H. W., Mertens, P.: Management von IT-Projekten, 4. Aufl., Springer, 2011. Dr. P. Steffen IT-PM 2.2-37