II Das Unternehmen als Kontext der Projektabwicklung

Präsentation zum Thema: "II Das Unternehmen als Kontext der Projektabwicklung"—  Präsentation transkript:

1 II Das Unternehmen als Kontext der Projektabwicklung
Produktionsfaktor: Information (vgl. Systemwürfel) soll in geeigneter Form entsprechend definierter Vorgaben bzgl. Ort, Zeitpunkt, Menge bereitgestellt werden. diesem Zweck dient das Informationssystem Ziel eines Informationssystems ist es, die - in einem Unternehmen vorhandenen Informationen, - in einem Unternehmen nachgefragten Informationen - für ein Unternehmen notwendigen Informationen auf den Arbeitsprozess so abzustimmen, dass damit die bestmögliche Leistung erbracht werden kann

2 Informationssystem-Management
Das ISM erstreckt sich auf die Entwicklung und den Betrieb der Informationssysteme von Unternehmen Zwei gegensätzliche Anforderungen müssen ausgewogen werden: Entwickler und Anwenden sollen möglichst wenig einschränkt werden, um neue Applikationen rasch und kreativ einführen/erstellen zu können. Entwickler und Anwendungen müssen so koordiniert werden, daß Doppelarbeit, Insellösungen, umständliche Abläufe vermieden werden, damit das IS längerfristig entwicklungsfähig bleibt und das IS mit der Geschäftsstrategie zusammenpaßt.

3 Informationssystem-Management
(Jenny, Abb. 1.17, S. 19)

4 Stufe: IS-Konzept (Jenny, Abb.1.19, S.22) Das IS-Konzept ist durch die Informationsstrategie selbst Teil der Unternehmensstrategie. Es muss daher mit den anderen Bereichsstrategien (Markt-, Produkt-, ...) in Einklang stehen.

5 Stufe: IS-Konzept Das IS-Konzept enthält Normen, wie:
Leitbild und resultierende Erfolgsfaktoren Grundsätze Standards und Richtlinien Das IS-Konzept enthält Beschreibungen von Vorgehen und verantwortlichen Stellen, wie: Projektmanagement IS-Organisation Methoden der Systementwicklung Prinzipien des IS-Controlling

6 Stufe: IS-Architektur
Einheitliche Architektur ist erforderlich, da i.a. viele interne und externe Partner an der Entwicklung eines IS beteiligt sind. Eine integrierte IS-Architektur ermöglicht die gemeinsame Nutzung von Informationen mittels Unterstützung verschiedener Anwendungen. Umfassende, Informatik-orientierte Gesamtkonzepte für Unternehmen können realisiert werden. (nach Jenny, Abb. 1.19, S. 22)

7 Stufe: IS-Architektur - Komponenten
IS-Architektur umfaßt: Datenmodell: konzeptuelles Modell ist implementierungsunabhängig, daher flexibel Prozeßmodell: erfaßt alle Geschäftsabläufe; vorteilhaft: top down und bottom up Erfassung Systemmodell: Gliederung von Geschäftsfällen entsprechend der Konsumation/Erzeugung gleicher Datenklassen; daraus: Ableitung von Subsystemen ; Subsysteme entsprechen oft Geschäftsbereichen wie Produktion, Vertrieb, etc. . Gerätemodell (siehe PRI I)

8 Stufe: IS-Architektur Daten- und Prozessmodell
bei Anwendung eines objekt-orientierten (OO) Ansatzes sind Daten- und Prozessmodell eng verknüpft Beispiel: Klassendiagramme und Use-Case-Diagramme im UP Klassenmodell (d.h. Daten wie auch die darauf definierten Operationen) wird aus der Modellierung von Use-Cases (Geschäftsfällen) abgeleitet. grobe Vorgehensskizze: Identifikation und nat.spr. Beschreibung von Use-Cases zunächst Normalabläufe, dann seltenere (Ausnahme)Fälle Hierarchische Anordnung von Use-Cases Ableitung des Klassenmodells

9 Stufe: IS-Architektur Daten- und Prozessmodellbeispiel

10 Stufe: IS-Architektur Daten- und Prozessmodellbeispiel

11 IS-Projektportfolio globales Ziel des IS-Projektportfolios: Initialisierung des richtigen Projektes mit den erforderlichen Ressourcen zur richtigen Zeit im richtigen Unternehmens-bereich. die für eine Aufnahme ins IS-Projektportfolio gestellten Bedingungen werden i.a. nach individuellen Unternehmenskriterien festgelegt. Unterschiedliche Vorhaben können so verglichen und priorisiert werden, damit die (möglichst objektiv!) wichtigsten Vorhaben realisiert werden können.

12 IS-Projektportfolio Aufgabe des IS-Projektportfolios ist es, aufzuzeigen: welche Projekte durchzuführen sind, wann mit welchen Projekten begonnen werden kann, wann ein Projekt abgeschlossen sein muß, welche Projekte parallel bzw. sequentiell realisiert werden sollen, wie lange das gesamte Realisierungsvorhaben dauert, wie hoch der (jährliche) Realisierungsaufwand ist.

13 IS-Projektportfolio - Ablauf
1. IS-Antrag Aufnahmekanäle: IS-Architektur oder Fachabteilungen: intern oder extern produzierte Bedürfnisse 2. Bewertung 3. Machbarkeitsstudie 4. Entwicklungsplanung 5. Projektfreigabe: Entwicklung auf der IS-Projektebene 6. IS-Entwicklungskontrolle: via Kontrollgrößen wird der Bezug zur Planung koordiniert

14 IS-Projektportfolio Ablauf: Antrag - Bewertung
Zwecks fachgerechter Prüfung/Bewertung der IS-Anträge, sollten darin folgende Projektmerkmale festgelegt sein: Projektumfang und Projektdauer Projektspezialitäten, z.B. Innovationsgrad, spezielle Infrastruktur, spezielle Methoden/Vertragsbedingungen,… Projektbedeutung: Stellenwert gegenüber der Konkurrenz, strategische/finanzielle Gewichtung, Prestigeobjekt,… Projektkomplexität: grobe Schätzung durch Einflußgrößen: - Anzahl der betroffenen Organisationseinheiten: gegenseitige Abhängigkeiten, Querverbindungen - Bereich der starken Veränderung: bzgl. Daten - Geschäftsfällen - Bereich der Methoden- und Toolwahl

15 IS-Projektportfolio Ablauf: Antrag - Bewertung
Projektkosten: Entwicklungs-, Management-, Produktinvestitionskosten Projektrisiken: möglicher Schaden für das Unternehmen, falls die Projektziele nicht erreicht werden Projektintensität: Ausmaß der Auslastung der Mitarbeiter während der Dauer des Projektes Projektart: Unterstützungs-, Entwicklungs-, Organisationsprojekte

16 IS-Projektportfolio Ablauf: Machbarkeitsstudie
Ziel der Machbarkeitsstudie: Beurteilung der Durchführbarkeit und Wirtschaftlichkeit eines Projektes Aufwand: max. 3 Personenmonate, Dauer < 2 Monate Ergebnis: Management-Summary mit folgenden Themen: - Ausgangslage - Ziele und Lösungsansätze - Wirtschaftlichkeitsanalyse - Risikoanalyse - Projektorganisation - Projektgesamtplanung - Aufgliederung in Teilprojekte - Erweiterter IS-Antrag

17 IS-Projektportfolio Ablauf: IS-Entwicklungsplanung
Ziel der Entwicklungsplanung: Festlegen der Reihenfolge der Projekte und Zuordnung der Ressourcen für die Realisierung der Projekte Entwicklungsplan: Erstellung durch Gremium mit gutem IS-Architektur Wissen und Managementkompetenz Schritte : Ermittlung der unternehmerischen Reihenfolge Kriterien: Unternehmensziele, Wirtschaftlichkeit Ermittlung der betrieblichen Reihenfolge

18 IS-Projektportfolio Ablauf: IS-Entwicklungsplanung
Kriterien: Wichtigkeit/Dringlichkeit, zur Verfügung stehende Ressourcen, betriebswirtschaftlicher Aufbau der IS-Architektur Aufstellung des applikatorischen Migrationsplans: Kompromiß; enthält die Realisierungsreihenfolge der Projekte Personal- und Finanzplanung Risikoanalyse der Projektanträge: Hauptproblem: “Was könnte während der Projektabwicklung mit welcher Wahrscheinlichkeit passieren und welches wären die Folgen dieser Ereignisse”.

19 IS-Projektportfolio Ablauf: Entwicklungsplanung
Beispiel einer Tabelle zur unternehmerischen Reihenfolge der Projekte: (Jenny Abb. 1.25, S. 35)

20 IS-Projektportfolio Ablauf: Entwicklungsplanung
Beispiel eines applikatorischen Migrationsplans (Jenny Abb. 1.29, S. 38)

21 IS-Projektportfolio Ablauf: Entwicklungsplanung
Beispiel eines Portfolio-Personalplans (Jenny Abb. 1.28, S. 37)

22 IS-Projektportfolio Ablauf: Entwicklungsplanung
Beispiel eines Portfolio-Finanzplans (Jenny Abb. 1.28, S. 37)

23 IS-Projektportfolio Ablauf: Entwicklungskontrolle
Aufgaben: Planungskontrolle: Kosten/Aufwand und Termine werden mit den Planungsvorhaben des Portfolios verglichen Projekt-Sachfortschrittskontrolle: SOLL-Vorgaben des IS-Projektportfolios werden mit den IST-Zuständen (z.B. aus Phasenabschlußberichten) verglichen Kontrolle des IS-Entwicklungsplans: alle Resultate der IST-SOLL-Vergleiche der laufenden Projekte bilden zusammengefaßt den “Statusbericht zur Umsetzung des IS-Entwicklungsplans”; Rückkopplung in das Projektportfolio Projekt-Nachkontrolle: direkter IST-SOLL-Vergleich bzgl.: Entwicklungskosten, Wirtschaftlichkeit, Projektdauer.

24 Informationssystem-Projekt
Projektebene der IS-Pyramide: IS-Projekte werden gemäß dem IS-Entwicklungsplan zusammengestellt. (Jenny, Abb.1.32, S.43)

25 Informationssystem-Projekt
Komponenten der Projektabwicklung im IS-Projektbereich (Jenny, Abb. 1.33, S.44)

26 Informationssystem-Projekt Standards und Richtlinien der Informatik-Abteilung
Quellen 1) IS-Architektur: Hardware, zentrale SW, Konzeption,…; Ausrichtung auf Daten-, Prozeß-, Systemmodell 2) Organisationshandbuch: - wird auf die Informatik-Abteilung spezialisiert; - enthält betriebliche Regelungen und Vorschriften als Umsetzung des Leitbildes des Unternehmens Leitbild: umfasst Unternehmensgrundsätze: Verhalten der Unternehmung gegenüber Umwelt, Kunden, Staat, etc. Führungsgrundsätze: Verhalten von Vorgesetzten zu Untergebenen (wird hier nicht behandelt)

27 Informationssystem-Projekt
Gliederung des Standards und Richtlinien Handbuches: (Jenny, Abb. 1.35, S. 47)

28 Informationssystem-Projekt Richtlinien für die Projektabwicklung
Projekthandbuch (PHB): beinhaltet organisatorische Regelungen für die Projektorganisation und -durchführung PHB ist ggf. Teil des S&R Handbuches Ziele: Grundlagen der Abwicklungsziele festlegen Arbeitsweise im Projekt festlegen Verbindliche Richtlinie für die Zusammenarbeit Zuweisung von Aufgaben, Kompetenzen und Verantwortungen an beteiligte Stellen Festlegung der Projektorganisation

29 Informationssystem-Projekt Richtlinien für die Projektabwicklung
Grundlage zur Erteilung detaillierter Aufträge im Rahmen des Projektes Unterstützung bei der Erstellung und Ausarbeitung notwendiger Verträge Festlegung des obligatorischen Outputs der aus den im PHB angeführten Tätigkeiten Kommentar: es ist sehr wichtig, daß die Richtlinien für die Projektabwicklung offen gehalten werden, um das Projekt-team nicht zu behindern, sondern zu unterstützen. dazu dient: Tailoring: Mit dem Tailoring werden die nichtrelevanten Tätigkeiten, die im PHB angeführt sind, gestrichen. Damit wird gewährleistet, daß der Aufwand für jedes Projekt situationsgerecht ist.

30 Informationssystem-Projekt Richtlinien für die Projektabwicklung
Metamodell eines Projekthandbuches: (Jenny, Abb1.36, S. 49)

31 Informationssystem-Projekt Gliederungsschema für ein Projekthandbuch
Key-PHB Übergreifende Standards, Organisationsübersichten und Projektqualifikationswerte etc. werden im Key-PHB aufgeführt. Literaturverzeichnis, Glossar, Definitionen Den Benutzer unterstützende Schriften sind in diesem Modul aufgeführt, so dass er diese in der Bibliothek einfach finden kann. Auch das Glossar und die Definitionen werden in dem Grad aufgebührt, dass es für den Anwender unterstützend ist. Projektmanagement Das Modul Projektmanagement enthält die allgemeingültigen Projektleiter-Aufgaben sowie die Vorgaben des Problem- und Änderungsmanagements, des Konfigurationsmanagements, des Risikomanagements sowie des Qualitätsmanagements.

32 Informationssystem-Projekt Gliederungsschema für ein Projekthandbuch
Vorgehensmethode Hier werden die in einer Firma angewandten Vorgehensmodelle und ihre Anwendungsberechtigungen erläutert. Projektorganisation Hier werden die Gremien (Stellen und Instanzen) und Organisationsformen, die innerhalb einer Firma für ein Projekt gebildet werden müssen oder können, aufgeführt. Im weiteren können weitere zusätzliche institutionelle Werte (z.B. Informationssystem etc.) aufgeführt werden, die in den Projekten ihre Anwendung finden. Dokumentation Hier werden alle notwendigen Vorgaben (Schlüsselwerte, Strukturen etc.) bezüglich der zu erstellenden Dokumentation aufgefiihrt. So auch die Strukturen der externen Projektsicht, z.B. Verträge, Pflichtenhefte etc.

33 Informationssystem-Projekt Gliederungsschema für ein Projekthandbuch
Phasenmodell und Problemlösungszyklus Hier werden alle Tätigkeiten und Ergebnisse, die in einer Phase oder in einem Phasenzyklus durchgefiihrt respektive erstellt werden können, aufgeführt. Qualitätssicherungssystem In diesem Modul sind die Vorgaben bezüglich des gewünschten Qualitätsstandards aufgeführt. Checklisten In diesem Modul werden Checklisten definiert, die bei einem Review oder Audit von Ergebnissen zur Anwendung gelangen. Methoden/Techniken Hier werden die Methoden/Techniken beschrieben, die in einem Projekt zur Anwendung gelangen sollen. Instrumente/Tools Abgestimmt auf die Methoden erfolgen hier Beschreibungen über die einzusetzenden Tools.

34 Informationssystem-Projekt Gliederungsschema für ein Projekthandbuch
Musterergebnisse Aufgrund von Aktivitäten und dem Ergebnismodell aus dem Modul "Phasenmodell" werden hier Musterergebnisse als Richtgrössen aufgeführt. Organisationsentwicklungskonzept Insbesondere bei Informatikprojekten ist es wichtig, daß das Organisationsentwicklungskonzept mit berücksichtigt wird. Das heißt, daß neben den funktionalen auch die sozio-psychologischen Veränderungen zum richtigen Zeitpunkt vorgenommen werden sollten. Konfigurationsmanagement Um sicherzustellen, daß ein Produkt bezüglich seiner funktionellen wie auch seiner äußeren Merkmale eindeutig identifizierbar ist, wird das Konfigurationsmanagement im PHB ausführlich beschrieben. Innerhalb des Konfigurationsmanagements muß auch das Change-/Änderungsmanagement beschrieben werden.

35 Informationssystem-Projekt Projektabwicklung
Gliederung des Projektmanagements: (Jenny, Abb. 1.40, S. 62)

36 Informationssystem-Projekt Projektabwicklung
Projektdurchführung: Vorgehensmodelle, Lebenszyklus-Modelle Vorgehensmodelle, Lebenszyklus-Modelle Projektphasen Problemlösungszyklus Projektdurchführungstechniken, z.B.: Requirements Engineering, UML, Risikoanalyse, Entscheidungsbaum, ...

37 IS-Projekt Vorgehensmodelle, SW-Lebenszyklus
verschiedene Vorgehensmodelle zur Entwicklung/Wartung von Software SW-Lebenszyklus: beschreibt die Phasen, die ein SW-Projekt “durchlebt”; jede Phase ist mit spezifischen Aktivitäten sowie der Erstellung/Ergänzung vordefinierter Dokumente verbunden; die Vorphasen: Zielanalyse und Planung sind nicht in allen Modellen berücksichtigt

38 IS-Projekt Vorgehensmodelle, SW-Lebenszyklus
Überblick über Lebenszyklus-Modelle: reines Wasserfallmodell und Wasserfallmodell mit Rückkopplung/Validierung Wasserfallmodell mit “Rapid Prototyping” in Analysephase evolutionäres/inkrementelles Vorgehensmodell exploratory Programming operationales Modell mit formalen Transformationen: formale Anforderungsspezifikation wird schrittweise durch automatisations-unterstützte Transformationen in ein exkutierbares Programm übergeführt Spiralenmodell

39 IS-Projekt das “Wasserfall-Modell”
Wasserfallmodell [Boehm, 1981]mit Rückkopplung

40 IS-Projekt das “Wasserfall-Modell”
Charakteristika des Wasserfallmodells: Phasen werden strikt sequentiell abgearbeitet und abgeschlossen; Ergebisse einer späteren Phase fleßen nur sehr beschränkt in die Überarbeitung einer früheren Phase ein; konstruktivistisches Vorgehen im Gesamtsystem Aufbau auf validierten Dokumenten als Zwischenergebnisse starres Modell, Abweichungen vom ursprünglichen Plan nicht vorgesehen; unterstützt jedoch kompakte, zielstrebige Projektentwicklung; zeiteffizient, jedoch hoch riskant bei neuartigen Anwendungen Anwendung: bei gut bekannten Vorhaben mit wenig Neuigkeitsgrad

41 IS-Projekt - das “Wasserfall-Modell” mit Rapid Prototyping
Modell zur Erweiterung des Wasserfallmodells um die Erstellung eines Prototyps in der Analysephase: Prototyp dient lediglich der Klärung der Anforderungen, er fließt nicht in das endgültige System ein; Nachteil: Kosten; Vorteil: fundiertere Anforderungsspezifikation möglich, verkleinert das Risiko, ein unbrauchbares System zu entwickeln (Sommerville Abb. 6.2, S. 107)

42 IS-Projekt - Exploratory Programming
Vorgehen: Entwicklung eines Prototyps aus der (groben) Anforderungsspezifikation; schrittweise Verfeinerung/ Modifikation dieses Prototyp-Systems bis das gewünschte Verhalten erzielt wird Vorteil: System weist gewünschte Funktionalität auf Nachteile: durch die zahlreichen Änderungen bei der Entwicklung, hat das System keine stabile Struktur; System ist nicht oder nur sehr schwer wartbar Anwendung: bei AI-Anwendungen, z.B. bei Expertensystemen, für die vhll-Entwicklungsumgebungen existieren und das Funktionieren des Systems vorrangig ist.

43 IS-Projekt - das evolutionäre/ inkrementelle Vorgehensmodell
Ziel: Vereinigung der Vorteile des explorativen Programmierens mit jenen des disziplinieten Verfolgens des Wasserfallmodells Vorgehen: frühes Festlegen der Systemarchitektur als Rahmen; Zerlegung des Systems in Teilsysteme, die inkrementell entwickelt werden; jedes Teilsystem wird entsprechend des Wasserfallmodells entwickelt, so daß entsprechende Dokumente erstellt und validiert werden; Teilsysteme werden inkrementell ausgeliefert;

44 IS-Projekt - das evolutionäre/ inkrementelle Vorgehensmodell
das Feedback der Benutzer zu früheren Teilsystemen kann bei der Entwicklung der weiteren Teilsysteme berücksichtigt werden Vorteile: - Pläne und Dokumentation werden für jedes Teilsystem erzeugt: erleichtert das Management des Projektes; - übliche Software-Prozeß-Standards können eingehalten werden: erleichtert die Wartbarkeit, Qualitätssicherung; - Teilergebnisse liegen früh vor: das Risiko einer Gesamt- fehlentwicklung wird minimiert ; - Auftraggeber haben wichtige Teilsysteme früh verfügbar; die frühe praktische Erfahrung wirkt sich positiv auf die weiteren Planungsschritte aus;

45 IS-Projekt - das evolutionäre/ inkrementelle Vorgehensmodell
- kleine Teilprojekte sind für Auftraggeber, Entwickler und Anwender handhabbarer und führen zu schnellem Feedback bzw. Korrekturmöglichkeiten; - Einsparung beim Auftraggeber durch frühe Einführung; - Auftraggeber haben wichtige Teilsysteme früh verfügbar; die frühe praktische Erfahrung wirkt sich positiv auf die weiteren Planungsschritte aus; Nachteile: - führt gelegentlich zu Problemen bei Verträgen; - Zerlegung in abgegrenzte Teilsysteme nicht bei jeder Aufgabenstellung sinnvoll durchführbar.

46 IS-Projekt - das evolutionäre/ inkrementelle Vorgehensmodell
Graph zum Vorgehen im Rahmen des evolutionären/ inkrementellen Modells: (Sommerville, Abb. 6.3, S. 109)

47 IS-Projekt das Spiralenmodell [Boehm, 1986]
mächtigste Erweiterung des Wasserfallmodells: basiert auf der Integration verschiedener Ansätze wie z. B. Prototyping, evolutionäre Etwicklung, Einbeziehung von Validierungsschritten beinhaltet auch Software-Management Aspekte wie Phasenplanung, Risikoanalyse, Wirtschaftlichkeitserwägungen, etc. grundlegende Ideen: - Phasen werden zyklisch aneinandergereiht; - in jeder Phase werden die gleichen Schritte verfolgt: * Bestimmung von Zielen und Alternativen; * Evaluierung; * Durchführung u. Validierung; * Planung der folgenden Phase.

48 IS-Projekt das Spiralenmodell
Anmerkungen zur Graphik: Beginn: im Koordinatenursprung die radiale Dimension repräsentiert die kummulativen Kosten aller vorangehenden Schritte; der Winkel repräsentiert den Fortschritt, der innerhalb jedes Zyklus der Spirale erzielt wurde; in jedem Zyklus werden die gleichen Schritte durchlaufen: für jedes Subsystem sowie für jede Entwicklungsphase; Beginn: Planungsphase; Ende: Kodierung/Inbetriebnahme

49 IS-Projekt das Spiralenmodell
Beispiel zu einem typischen Zyklus der Spirale: Beginn: Identifikation der Ziele der Phase des (Teil)produktes, welches im Entwicklungsprozeß steht Identifikation der alternativen Mittel zur Realisierung obiger Ziele (z.B. Design A, Design B, reuse, Ankauf) Identifikation der Randbedingungen auf die Anwendung obiger Alternativen (z.B. Kosten, Termine, Personal) Evaluierung der Alternativen hinsichtlich Unsicherheiten und somit Risiken der Entwicklung; Formulierung einer kosteneffektiven Strategie zur Minimierung der Risiken, z.B. Benutzerbefragung, Prototyping, Simulation,

50 IS-Projekt das Spiralenmodell
Feststellung des Restrisikos: falls gering, dann - Beschreiten der nächsten Phase des Wasserfallmodells, ggf. mit Einbeziehung der inkrementellen Entwicklung - falls groß, dann weiteres Prototyping; Fortsetzung der Risiko-Resolution; Review und Validierung des Zyklus, inklusive des groben Plans für den nächsten Zyklus; Detailplan für den folgenden Zyklus: dieser kann z.B. die Partitionierung des Produktes in inkremenelle Teilprodukte für ein evolutionäres Vorgehen enthalten; Teilprodukte können für die Entwicklung durch andere Organisationen bestimmt werden.

51 IS-Projekt - Umsysteme der Projektabwicklung
andere Projekte; Beziehungen/Abhängigkeiten zwischen Projekten müssen klar geregelt werden Unternehmensführung und Auftraggeber; liefern Mittel/Unterstützung für das Projekt Beziehungen zum bearbeiteten System; wichtigstes Umsystem, das selbst verändert wird - diese Veränderungen sollten (dynamisch) berücksichtigt werden! intensive Zusammenarbeit zwischen Projektleiter und Leiter des zu verändernden Systems sind für Erfolg erforderlich.

52 IS-Projekt - Einflußgrößen Rahmenbedingungen
Entwicklungsbezogene Rahmenbedingungen: Häufigkeit von Änderungen auf der Entwicklungsbasis Nutzung der Entwicklungsmethoden und Tools Bearbeitungszyklus Unterstützung durch Test- und Prüfverfahren Qualitätssicherung Projektbezogene Rahmenbedingungen: Entwicklungszeit Entscheidungskraft der Leitung Arbeitsaufteilung, Projektstruktur Qualität des Projektmanagements Einsatz von Projekt management-Techniken

53 IS-Projekt - Einflussgrößen Rahmenbedingungen
Firmenbezogene Rahmenbedingungen: Leitbild/Unternehmensphilosophie Standards und Richtlinien Entwicklungsstand des Produktes Wirtschaftlichkeitsvorgaben Personal- und Anwendungsbezogene Rahmenbedingungen: Betroffene Gruppen, Mentalität, Ausbildungsgrad Verfügbarkeit des Personals, Leistungswille Produktbezogene Rahmenbedingungen: Größe des Entwicklungsbereichs (Konzern, Abteilung…) Modularität und Komplexität Wiederholungshäufigkeit des Prozesses

54 IS-Projekt - Einflußgrößen Restriktionen
Umweltbezogene Restriktionen: Technologie Computerrestriktionen (z.B. Prozessorart) Verordnungen (ein Hersteller schreibt etwas vor) Internationale Übermittlungsprotokolle Firmenbezogene Restriktionen: werden bei der Projektinitialisierung definiert: Vorgehensvorgaben Vorgaben bzgl. der elaubten Konsequenzen Termine, Kosten, eingesetztes Personal Veränderungserlaubnis Beispiel: das Projekt muß mit dem Tool X entwickelt werden

55 IS-Projekt - Einflußgrößen Restriktionen
Risikobezogene Restriktionen Managementrisiko Technisches Risiko Soziales Risiko Systembezogene Restriktionen: vor- oder nachgelagerte Stellen/Prozesse geben Größen vor, die eingehalten werden müssen; Beispiel: Das System muß einem vorgegebenen Standard entsprechen Die Durchlaufgeschwindigkeit eines Geschäftsprozesses darf eine Maximaldauer nicht überschreiten Der Geschäftsprozeß darf maximal ‘n’ Arbeitsstellen durchlaufen, ...

56 IS-Projekt - Erfolgsfaktoren
Definition: Ein Projekterfolg liegt vor, wenn die vom Auftraggeber gewünschten Resultate mit den vorgesehenen Mitteln innerhalb der vorgesehenen Zeit in der geforderten Qualität vorliegen. Projekterfolg ist primär abhängig von: System der Projektabwicklung (“Development World”) System, das entwickelt wird (“System World”) Definition: Unter Erfolgsfaktoren in einem Projekt versteht man die Voraussetzungen, die wesentlich zur Erreichung der Merkmale erfolgreicher Projekte beitragen.

57 IS-Projekt - Erfolgsfaktoren
Die fünf Erfolgsfaktoren-Gruppen: (Jenny, Abb.1.57, S. 85)

58 IS-Projekt - Erfolgsfaktoren
PM-Funktionen: Zielsetzungen genau definieren und Projektmitarbeitern mitteilen; ausreichender, angepaßter Detaillierungsgrad der Planung; geordnetes Berichtswesen, Dokumentation, Kontrollen,… Projekteam-Umwelt: umfaßt: Auftraggeber, Sponsoren, Benutzer stetiges Involvieren des Auftraggebers; Benutzer ins Projekt integrieren; rechtzeitige Information und Koordination aller Betroffenen;...

59 IS-Projekt - Erfolgsfaktoren
Projektabwicklungs-Instrumente: umfassen: eingesetzte Methoden, Techniken, Tools; Instrumente sollen situationsgerecht eingesetzt werden; Gliederung von Projekten in Phasen entsprechend Gesamtkonzept; eingesetzte Hilfsmittel müssen einwandfrei funktionieren u. Benutzer müssen mit ihnen professionell umgehen können; … Personen: qualifiziertes Team erforderlich; Teamfähigkeit, Erfahrung,… Organisation: Aufgrund der Einmaligkeit jedes Projektes sollte die Organisation unbürokratisch und flexibel sein.

60 IS-Projekt - Risiken Definition: Projektrisiko: Höhe des Schadens, den ein Unternehmen erleidet, wenn die Projektziele nicht erreicht werden. Risikoentschärfung: permanenter Gebrauch von Erfolgsfaktoren; wiederholte Risikoanalyse, z.B. gemäß Spiralenmodell; Einsatz entsprechender Unterstützungsverfahren Risiken während des Projektablaufs können aufgedeckt werden durch: Projektplanung überprüfen, Durchführen von Reviews, Einbringen von Erfahrungen aus früheren Projekten, ...