Home

Zusammenfassung PRMA - roger

1. si 7 Be Risikokatalog Risikokatalog berpr fung amp Erstellung Nachf hrung Planen Einrichten Steuern Abschliessen As ooo Y s lt Produkt Systementwicklung Probleml sung Abb Zeitpunkt der Risikoanalyse Marco amp Roger 05 07 05 PRMA 19 88 Eidg Dipl Wirtschaftsinformatiker 3 9 Risikoanalyse Kwick 2000 Risk Management Spezifische Risikofaktoren Datum 20 8 02 Risikokurz bezeichnung Fremdsysteme x SvAuftrag bbbbbbbbbbbbbb mb Service Aenderungen Schnittstelle Technologie betr Werzeuge 11 Intern Projekt Organisation Marco amp Roger 05 07 05 PRMA 20 88 VM Status Eintrretenswahschei nlichkeit Schaden sausmass lt j mandi d lt 5 Durchschnitt der E 0 d Risikoauswirkun N s N N CA O O _ CH O N OQ gt 9 N O O N O O O O O Ou O N CA Eidg Dipl Wirtschaftsinformatiker Risikokurz Die Risikokurzbezeichnung muss in einfachst m glicher Form eine eindeutige Identifizierung des Risikos erlauben Die bezeichnung Risikokurzbezeichnung wird als Referenz in anderen Listen verwendet Risikobeschreibung D
2. 75 11 4 1 Direkter e 75 11 4 2 Indirekter Nutzen 75 12 Anhang 76 KR EN E E 76 12 2 78 12 3 Projektmanagement Summary Projekt XP 81 12 4 Projekt Management Summary Optisches 83 12 5 Projekt Management Summary CAT 84 Marco amp Roger 05 07 05 PRMA Eidg Dipl Wirtschaftsinformatiker 4 88 Eidg Dipl Wirtschaftsinformatiker Big Picture Projekt Initialisierung Konzept Realisierung Einf hrung bersicht mit Phasen Sien oft Prosessen Proeklfundarent Funktionale und nicht Entwurf der Imslementierung und Ausbreitung der uw Produkiskizze funktionale Anforderungen IT L sung Test der IT L sung Applikalior s IT L sung und Ergebnissen Wirtschaftlich die IT L sung Inksgralionstest keitsprognase Produktionstest Fil Fequiremants Sign off Projektauftrag Hrolektauftrag Projekt und Risikomanagement ing Statusbericht Schlussbericht Betriebsorganisation EE Anforderungsspezifikation
3. Investition Nicht IT HW SW 1 44 14 Externe Dienstleistung LI II SW Customization Integration SW J o Schulung Kommunikation 44 4 Ausbreitung Datenmigaion Abl sung obsoleter Applikationen Systeme Weitere relevante Kosten TTT Total Realisierungs Einf hrungskosten__ Y 0 0 9 Betriebskosten Bereitstellung Produktionsumgebung DW III Bereitstellung Produktionsumgebung IT Sw BERNER DEN RER j Betrieb Nicht ir TT Wartung Applikation Intern T II L Wartung Applikation Extern LI 4 4 4 Amortisation THW 44 44 4 4 Amortisation IT Sw III Nicht IT HW SW LI 44 4 4 LeasngiIHW teasing TSW 4 44 4 Leasing Nicht IT HW SW 4 4 4 Weitere relevante Kosten LL L L Applikationen Systeme Total Betriebskosten 0 OL 0 ll Total Projektkosten I L 0 0 S mtliche Angaben in PM 2002 2003 2004 2005 2006 Realisierungs Einf hrungsaufwand Entwicklungsaufwand ITT Entwicklungsaufwand Extern TUI Entwicklungsauf wand Intern Bankfach J 2 Externe Dienstleistung __ SW Customization Integration SW Schulung Kommunikation Jo Ausbreitung Datenmigration Weiterer relevanter Aufwand Betriebsaufwand Betrieb lT 1141 Betrieb M
4. modellierung und i i T Anforderungen service Level Vereinbarung Ga Evaluation Report Standard Software IT Analyse und Informatikspezifikation I1 Design Decommissioning Spat E EGD 27 Implementierung Configuration amp Change Management Report Change Configuration Management Plan u Releaseflash 2W AIT 4 Ausbreitungskonzept Anwenderhandbuch Schulung Ausbreitung EEE 27 AIT x IT B etriebsanlaitung 1W e Qualit t f Qualit tsplan u smanagemen ER Testdrebbocht bericht SE Stellungnahme Review GEI Umgebung Projekt Umgebung Test Umgebung Entwicklung Umgebung Produktion Legende B50 550 50 Das Ergebnis geht durch den entsprechenden Sign off Pn Ergebnis mit Federf hrung im Mitarbeit durch IT RSO Der Auftraggeber besi ligt explizit die Anforderungen die T L sung Ergebnis mit Federf hrung in der IT Mitarbeit durch Business BTG Das Ergebnis muss zwischen 3 Wochen 15 Arbeitstage bis 2 Tage vor dem Ergebnis mehreran Auspr gungen Dia Federf hrung ist fallweise Aa So lart des Applikalions Integralionstesis AIT oder Produktiontesis durch den Projektleiter festzulegen eingereicht werden Die genauen Daten bezogen auf ein Einf hrungspaket sind im Bei Wartung Der Inhalt des Relsase bestimmt ob das Ergebnis Integrationsplan 1G Plan aufgef hrt nachgef hrt oder unver ndert bleib
5. Diverses Wenn Experte ein Glas Wasser anbietet sollte es genommen werden Ablehnung wirkt unanst ndig Marco amp Roger 05 07 05 PRMA 60 88 Agenda f hren und nachf hren differenzierte Reihung Dauer Zuerst erarbeiten ist die eigentliche Argumentation Steigerung der Spannung Einw nde vorwegnehmen Logische Gliederung Dialektische Gliederung Zuh rer einstimmen Interesse wecken Aufmerksamkeit erzeugen Begr ssung Freude ausdrucken Ausgangslage sich selbst Vorstellen Zielsetzung Nutzen f r Zuh rer Thematik Traktanden Agenda Arbeitsweise Arbeitszeit evtl Unfreezing Weg zum Ziel Zitat Sprichwort Witz Provokation Standpunkt Standpunkt Demonstration Einstiegsmotivation Anfang und Schluss ist fast das wichtigste an der Pr sentation Anfang Teilnehmer gewinnen Schluss bleibt haften 8 4 4 Gliederung der Folien 8 4 5 Inhalt Folien Gestaltung Inhalt der Pr sentation festlegen Welches Ziel will ich mit der Pr sentation erreichen Inhalt der Pr sentation erarbeiten Was geh rt alles zu diesem Thema Welche Teilbereich kennen die Zuh rer bereits Was ist an diesem Thema f r die Zuh rer wichtig Welche Erkl rungen sind zur Erreichung des Ziels absolut notwendig 1 Reduzieren des Stoffes Welches sind die zentralen und wesentlichen Punkte Wie viel Zeit ben tige ich f r die Darstellung dieses Themas
6. Infrastruktur O Eidg Dipl Wirtschaftsinformatiker 3 9 1 Risikenkatalog je Bereiche Projektdauer Fachberichte Auswirkungen analysieren Neue Entwicklungen Technologiespr nge in der Informationen beschaffen Branche Umstrukturierungen Partner suchen Projekt technisch nicht machbar Erster Einsatz neues Klar kommunizieren Partner mit Anwendungsgebiet keine ins Boot holen Projektabbruch Referenzen Pilotinstallation oder Unterbruchkriterien L sungen scheinen mit heutiger festlegen Technologie unrealistisch Die Schnittstellen zu den Kunde plant Einf hrung Informationen Beschaffen anderen Systemen ndern Erweiterungen bei den Abstimmen und absichern Umsystemen Hersteller Bedingungen festhalten k ndigen neue Versionen an Anwendungsgebiet ndert fehlt zuwenig Professionalit t Planung und Tracking der erkennbar Bedingungen Kommunikation Produkt eskalieren Lobbying Workshop Demos Marketing Informationskonzept Durchsetzen von erarbeiten Einzelw nschen Vertragliche Absicherungen organisatorische strukturelle Koordinationsw nsche Schnittstellen festlegen und Kkundenseitig genehmigen lassen Grosse organisatorische Projektziele werden nicht Kommunikation Auswirkungen gef hrden die kommuniziert Belegschaft wenig Akzeptanz beim Kunden involviert Produkt hat viele Anwender Workshop zum Produkt durchf hren Folgen aufze
7. u u 34 5 2 Gr nd f r Proj ektcecontr ollin 8 u Uu sa 34 5 3 Zunehmende Bedeutung des Projektcontrollings 22 34 5 4 Zweck Ziel und positive Ergebnisse der Projektkontrollen 34 5 4 1 Bereiche der Projektkontrolle 35 5 5 Kontrollverfahren Eee 35 5 6 Die Unterst tzung der Projektf hrung durch den Projektcontroller 35 5 7 Die Instrumente des Projektcontrollers 36 e RE EIER 36 el Ee ENEE Din Le 36 5 8 Aufgaben der Projektkontrolle u u 36 5 8 1 Schritte der Projektkontrolle 36 Marco amp Roger 05 07 05 PRMA 2 88 Eidg Dipl Wirtschaftsinformatiker 6 Projektportfolio 38 121 lHlormatonen nenne ne eu 38 6 2 Ablauf im IS Projektportfolio Projektportfolio 39 6 3 EE EE 39 6 4 Das Projektportfolio zeigt auf u 40 e EE 40 6 4 2 IS A trag 40 9
8. 42 Projekt 69 Planungsberich 54 Bertchiwesen 54 G Planungskontrolle 35 Betriebsdokumentation 50 globale Ziel 40 Planungsrisiko 15 Betriebskosten 28 H Politisches 16 Betriebskostenplanung 28 Hellraumprojektor 62 Pr sentation 57 Bewertung Ihrer Zufriedenheit 77 Pr sentationsabwicklung 58 Bewertungskriterien 77 Informationen 38 Pr sentationstechnik 59 1 28 Informationsbeschaffung 32 29 72 Informationsbeschaffungskonze Produktabnahme 67 Bebe 32 Produktionsfaktor Informationen Checklisten Institutionelles DM GC SNE E 38 Projektantrag 48 Integrationsabnahme 67 Projekt Projektauftrag 72 IS A Ir80 40 Rangfolge 42 Projektmanagemert 73 K Projektabschluss 48 67 Checklisten 72 Projektabschlussbericht 70 Projektabwicklung 72 Kick On 56 Projektabschluss Beurteilung 69 Projektsta a 72 Konfigurati
9. Protokoll Erstellen eines Projektaufl sungsprotokolls Sitzungen unterzeichnen lassen und verteilen Siehe Kap 10 1 6 Aufl sung Aufl sen aller projekteigenen Ressourcen und Institutionalisierungen Feiern Feiern der erbrachten Leistungen Marco amp Roger 05 07 05 PRMA 72 88 Eidg Dipl Wirtschaftsinformatiker 11 Diverse Checklisten zu Projektabwicklung 11 1 Wie starte ich ein Projekt Auftraggeber aktiv einbinden Auch m gliche Benutzer und erfahrene PL kontaktieren Doku beschaffen und studieren Ziele hinterfragen e Projektabgrenzung sehr grob festlegen inkl Umfeld e Meetings mit allen m glicherweise Beteiligten Ist Zustand grob analysieren erste Interviews f hren e Kontakt mit IT ORG MA mit Erfahrung auf diesem Gebiet sowie externen Zulieferanten e L sungen grob _Kosten Nutzen sehr grob berlegen e Timing und Projektorganisation f r n chste Phase erstellen Inkl Einsatz von Externen berlegen Kontakte zu Linienvorgesetzten aufbauen Mitarbeiter evaluieren e Alle Punkte im Projektantrag abf llen Projektantrag erstellen Genehmigungsprozess f r Initialisierungsphase einleiten Zeit f r Entscheide einplanen 11 2 Vom Antrag zum Projektauftrag Team aufbauen e Interne und externe Partner sichern Zusagen Vertr ge Klare Zuordnungen verf gbar Kompetenzen etc Teambildungsprozess denkt daran Stormi
10. 5 Projektphasen 53 12 ee 79 Projektkosten 28 Sicherstellung 45 L Projektleiter 12 Sinn und Zweck 44 Leistungsindex 37 Projektmanagement Dokumentation 44 Lenkungsausschuss 12 Funktionen 9 SUE 46 Projektnutzen 74 E Machbarkeiten 41 Projektorganisation 11 EINT hLUNg ie 64 Machbarkeitsstudie 42 Projektportfolio 38 40 41 Einf hrungen dee 65 Management Summary EIER 50 54 41 Einf hrungskonzept 66 Managementrisiken 15 siehe ZF_ISMA 38 Einf hrungskosten 28 Massnahmen 27 57 Einf hrungsrisiko 15 Massnahmen zur Sicherstellung Projektsitzungen 56 Einf hrungsstrategie 65 der Projektdokumente 45 Projektstart 72 Eintretenswahrscheinlichkeit Migrationskonzept 66 Projektstartsitzung 56 E 21 Migrationsplan 43 Projektsteuerung 12 Entwickler 12 Mitarbeiterrisik0 00 16 Projektteam 10 Entwicklung
11. Betont und gliedert Gem ss Cl Richtlinien einsetzen Schwarze Schrift auf weiss oder Gelbe Schrift auf blau bei grossen PC Pr sentationen Max drei verschiedene Farben einsetzen Rote Schrift ist schlecht lesbar Folien nummerieren Lesbarkeit von schwarz weiss Kopien sicherstellen Folien Unterst tzen das Gesagte Enthalten nicht genau das Gleiche wie das GesagterF olien pro Zeit 2edezeit Anzahl Folien Richtwerte Bis 10 Min Jede Folie hat einen Titel Wenn m glich hat jede Folie eine KernaussageJede Grafik Muss f r sich alleine verst ndlich sein Darf nicht zu viele Details enthalten Sollte auf einfache Art komplexe Inhalte darstellen Muss gut lesbare Titel und Skalen haben Sollte eine Quellenangabe haben Aussage Das Wesentliche auf einen Blick erfassbar machen Folien zu Pr sentationszwecken Werden w hrend der Pr sentation verwendet Werden mittels PC Beamer oder Overheadprojektor an die Wand projiziert M ssen bersichtlich und gross geschrieben sein Sollten das Gesagte nicht wiederholen sondern veranschaulichen Sollten nur Stichworte und m glichst viele Bilder Grafiken enthalten 05 07 05 PRMA 62 88 Eidg Dipl Wirtschaftsinformatiker Folien als Handouts Enthalten Zusatzinformationen zum Gesagten Werden meistens als Vorablekt re vor oder als Zusatzinformation nach der eigentlichen Pr sentation v
12. Attraktivit t Wirtschaftlichkeit des Projektes Netto Nutzen des Projektes Kosten Nutzen berlegung Kosteneinsparungen Umsatz Ergebnis Verbesserung Produktivit tssteigerung Entwicklungsaufwand einmalig Betriebskosten j hrlich Zeitreduktion H ufigkeit der Anwendung Benutzung Attraktivit t des Arbeitsplatzes vorhandene Personalkapazit t Erfahrungen Risiko berlegungen technische Abl sung Machbarkeiten Ressourcen Skills Finanzielle Restriktionen Politische Technische Organisatorische 6 4 2 3 Die Bewertung kann auf folgende Weisen erfolgen Verbale Bewertung Matrix Varianten Vorteile Nachteile Visuelle Bewertung z B mit und Rangreihenverfahren Ranking mehrere Personen nehmen Rangierung von Varianten vor Wirtschaftlichkeitsrechnung Kostenvergleich und Gewinn Rentabilit tsvergleich Nutzwertanalyse Kostenwirksamkeitsanalyse Marco amp Roger 05 07 05 PRMA 41 88 Eidg Dipl Wirtschaftsinformatiker 6 4 3 Machbarkeitsstudie Ergebnisse der M ist ein Management Summery und beinhaltet Ausgangslage Ziele und L sungsans tze operationalisiert L sungsans tze Vor und Nachteil Wirtschaftlichkeit Analyse Kosten Nutten Risikoanalyse Gr sse Dauer Lokationen Bereiche Projektorganisation Grobe Projektplanungen 6 4 4 Entwicklungsplanung Ziel der IS Ent
13. Projekt berichtswesen 2 4 3 5 144 Projekt besprechungen 2 4 2 15 140 Projektsitzungen 2 4 2 1 5 141 Dialoge 2 4 2 2 5 143 Pr sentationen 2 4 2 3 5 443 Institutionelles Projektmanagement eine bersicht Kapitelangabe aus PM Buch B Jenny Marco amp Roger 05 07 05 PRMA Projekt dokumenations system Vorgehens dokumentation 2 5 2 S 156 System dokumentation 2 5 3 S 167 74 88 Projektkommunika tionssystem 2 6 S 171 Sachmittel system Arbeitsplatz Gestaltung 2 7 1 15 172 Gruppenmaterial 2 7 2 1S 173 Software 2 7 3 5 173 Hardware 2 7 4 5 176 11 4 Projektnutzen Auflistung von Beispielen 11 4 1 Direkter Nutzen Direkte Einsparungen e Absolute Personaleinsparungen e Wegfall von Mieten f r konventionelle Ger te Wegfall von Servicekosten e Absolute Materialeinsparungen e Wegfall von Mietkosten e Kapitalbindungen im Lager Reduktion der Durchlaufzeitkosten Vermeidbare Kosten Kein zus tliches Personal bei Erh ung des Arbeitsvolumens Vermeidbare zus tzliche externe Leistungen Sp tere Bezahlung der Kreditoren durch gezielte berwachung der Zahlungsausg nge Fr hzeitige Erkennung von Ladenh tern Vermeidung von Liquidationskosten Nicht quantifizierbarer Nutzen e Transparenz ber Bewegungen und Best nde e Aktuelle Informationen rasche und gezielte Dispositionen e Weniger Fehler Werbeeffekt Verbesse
14. Sehr hoher Aufwand f r Anwender und Entwickler Hohe Systembelastung EDV Support Datenkonsistenz Integrit tsprobleme Neue Systemanforderungen m ssen im alten und neuen System nachgef hrt werden z B gesetzliche nderungen Systembelastung Alt und Neu Datenkonsistenzprobleme wenn Alt und Neu parallel gef hrt werden Aufwendige Fallback L sung f r den Pilotbereich Was werden wir tun um zu verhindern dass etwas scher geht Was werden wir tun wenn etwas scher geht Ausserbetriebsetzung des alten Systems Entsorgung der HW SW Archivierungskonzept f r die alten Datenbest nde SW 9 5 3 Systemabnahme 9 Marco amp Roger 05 07 05 Gen gend Ausbildung und Erfahrung der Anwender Neue Aufgaben Abl ufe und Zust ndigkeiten klar bergangsphase neu sichergestellt Organisatorische Voraussetzungen i O alte Weisungen ausser Kraft gesetzt Betriebsunterst tzung geregelt Hotline Konzept bekannt Wartung des neuen Systems geregelt Systemzust ndigkeit geregelt PRMA 67 88 Eidg Dipl Wirtschaftsinformatiker 10 Projektabschluss PRMA Buch S 493 ff Oftmals werden Projekte gar nie abgeschlossen Dies hat h ufig mit einem Nachlassen der Konzentration und des Interesses am Projektes zu tun Das Aufr umen w rde bestimmt besser honoriert wenn man allen Beteiligten verst ndlich machen k nnte welche enorme Vorteile
15. Anforderungen an den Kreditwunsch FK Bankfachspezifikation Change Request Wurde offeriert und wird im Rel 4 0 realisiert Informativ ur als Zusatzinformation vorhanden Wird nicht realisiert gem ss Absprache siehe Comment Nicht offeriert wird nicht umgesetzt kann mittels CR eingebracht werden Bewilligter Change Request f r Release 4 0 BF CR OK NR NO CR Zwingend E Implies that the software will not be acceptable unless these requirements are provided in an agreed manner W nschenswert Implies that these are requirements that would enhance the software product but would not make it unacceptable ifthey are absent Optional Implies a class of functions that may or may not be worthwhile This gives the supplier the opportunity to propose something that exceeds the SRS B 1 ion bh ngig Requirement that has to be supplied by another system and or Project Analysis verification based on analytic proofs obtained by calculation without any intervention on the system components Demonstration D verificationof the operational characteristics observable the system in operation without involving physical measurements Test T nspection visual or dimensional verification of system components verification of measurable functional characteristics which can be accessed directly or indirectly ot Applicable N A Marco amp Roger 05 07 05 PRMA 31 88 Eidg Dipl Wirts
16. Dokument Detailkonzept erstellt Es enth llt alle Arbeitsergebnisse aus dieser Phase 7 7 7 Projektabschluss Dokumenation siehe Kp 0 Seite 54 Der Projektabschlussbericht enth lt alle entscheidenden Ergebnisse der Sequenzen und enth llt generell die folgenden Informationen Resumee des gesamten Projektteams Positive und negative Erfahrungen mit den Erwartungen aus Benutzersicht Positive und negative Erfahrungen verglichen aus der Sicht RZ oder Systembetreuer Aussagen ber tats chliche Kosten und Nutzen des Systems Welche Arbeiten noch erledigt werden m ssen damit das Projekt als abgeschlossen betrachtet werden kann Begr ndung der Abweichungen Weiteres Vorgehen bez glich System bergabe und unterhalt Aufl sung des Projektes 7 7 8 Inhalt Projekt Antrag Problembeschreibung Zielvorstellung Begr ndung Folgen der neuen L sung Org gesetzl Folgen bei Nichtrealisierung Erfolgserwartungen Personalressourcen Stellungnahme IT 7 8 1 Ideen zum Projektantrag Ist Zustand Beurteilung Projektziele grob Rahmenbedingungen Restriktionen L sungsidee Risiken grob Kosten Nutzen 9 9 9 9 N 9 9 9 9 05 07 05 PRMA 48 88 Eidg Dipl Wirtschaftsinformatiker Vorgehen grob 7 7 9 Ideen zum Projektauftrag Ausgangslage Projektbeschreibung Umfang System und Vorgenhensziele Projektabgrenzung Resultate und Zuliefer Resultate Rahmen
17. Marco amp Roger 05 07 05 PRMA Eidg Dipl Wirtschaftsinformatiker Kr nung Ist sehr wichtig Wirkt nach bleibt haften Detailliert vorbereiten Weg zum Ziel Zusammenfassung Wiederholung der Zielsetzungen und Hauptsaussagen Folgerung und Ausblick Nutzen nochmals aufzeigen Aufforderung Appell an Zuh rer Verabschiedung 61 88 Eidg Dipl Wirtschaftsinformatiker Welche Punkte innerhalb des Themas sind eher schwierig zu verstehen welche sind eher einfach F r welche Punkte innerhalb dieses Themas braucht es mehr f r welche weniger Zeit Beachte max 70 der Zeit vorbereiten In welcher Reihenfolge sollen die wesentlichen Punkte erkl rt werden Material und Argumente vorbereiten Welche praktischen Beispiele eignen sich zur Veranschaulichung Welche Einstellungen Meinungen k nnten die Zuh rer haben Welche Fragen Einw nde k nnen von Seiten der Zuh rer kommen Gestaltung der Folie Nur ein Thema pro Folie Stichworte Aufz hlungen Text gliedern und max 6 bis 8 Zeilen zu je 7 W rten pr gnante einfache Schrift Arial gross klein Schriftgr sse Text nicht unter 18 Punkt max 3 Farben pro Folie Bitte verwenden Sie keine l ngeren Textbausteine die komplexe zum Teil auch verschachtelte S tze enthalten k nnen da sonst der Zuh rer v llig vom Lesen beansprucht wird und Ihnen nicht mehr zuh ren kann Farbe Erh ht die Aufmerksamkeit
18. No Are planned resources available Assessment Plan actual Manpower and Skills Reasons Implications Measures G Y R for IT for Business Yes Nr No IT Architecture Specs Implementation Testing Siehe Project delivery Etliche Change Requests aus Erkenntnissen im Verlaufe der Entwicklung der umliegenden SKP Teilsystme Measures to be implemented Requests Assessment Description Respon Deadline Plan sible Act 01 Da eine Aufteilung des SKP Rel 4 0 auf zwei Teile 4 0 und 4 1 erfolgte und BF E2E damit Erweiterungen erst nach SKP Rel 4 1 geplant Ende 2003 in die Projektleitun Entwickung gegeben werden k nnen berpr ft das Bankfach die zur ckgestellten Change requests Durch die Aufteilung in SKP Rel 4 0 und SKP Rel 4 1 k nnte es Probleme mit der Bereitstellung von und Bankfach Personal f r die Tests und Unterst tzung nach Einf hrung Rel 4 0 geben Success of initiated Measures Additional Comments Marco amp Roger 05 07 05 PRMA 77 88 12 2 Projektbewertung Eidg Dipl Wirtschaftsinformatiker Bewertung Ihrer Zufriedenheit Projektauftr ge und Beratungsmandate Angaben zum Auftraggeber Kunden Bewertungskriterien 1 Zeitgerechte Lieferung Qualit t der Lieferung Budget resp Kostentransparenz Flexibilit t Fachkompetenz Sozialkompetenz Innovation Beitrag neuer Ideen Einbezug der Benutzer Kunden Marco amp Rog
19. Projekttr gerinstanz stattfinden 2 2 2 Projektteam Umwelt Zur Projektteam Umwelt geh ren in erster Linie der Auftraggeber die Sponsoren die Promoter die ein aktives Projektmarketing betreiben wie auch der Benutzer Je nach Qualit t der Projektumwelt ist es den Projektmitarbeitern m glich ihre F higkeiten ihre Motivation und Umsetzungsverm gen optimal einzusetzen Daher ist es wichtig folgende Erfolgsfaktoren zu ber cksichtigen Bed rfnistr ger Der Bed rfnistr ger Benutzer muss ins Projekt integriert werden Information und Durch rechtzeitige vollst ndige Information und Koordination ist Koordination die Mitarbeit der direkt oder indirekt Betroffenen zu f rdern Zielsetzung F r das Projekt sind gem ss der Zieldefinition klare und messbare Zielsetzungen in schriftlicher Form festzuhalten Auftraggeber involvieren Durch stetiges Involvieren des Auftraggebers erh lt das Projekt durch ihn die notwendige Unterst tzung Promoter und Sponsoren Der Beistand eines Promoters oder Sponsors schafft eine gr ssere Akzeptanz und Durchschlagskraft und erm glicht ein effizientes Projektmarketing 2 2 3 Projektabwicklungs Instrumente Instrumente sind die Methoden Top Down Vorgehen Systemdenken Konfigurationsmanagement usw sowie die Hilfsmittel Werkzeuge Techniken und Tools Planunssoftware Datenbanken Diagramme usw die in einem Projekt zur Anwendung gelangen respektive situa
20. gbarkeit des Personals 20 100 Mentalit t Ausbildungsgrad der Anwender Leistungswille und f higkeit der Anwender Trends Trendw nsche des Kunden respektieren Modularit t Komplexit t Wiederholungsh ufigkeit des Prozesses Gr sse des Entwicklungsbereiches z B Abteilung Konzern Projektbezogen Firmenbezogen Personal und Anwendungsbezogen Produktbezogen 1 2 Restriktionen einer Projektabwicklung Restriktionen zeigen dem Projektleiter ganz klare Grenzen Er ist verpflichtet diese zu beachten das sie f r ihn Gesetzte sind Die Schwierigkeit f r den Projektleiter besteht darin nur die echten Restriktionen zu ber cksichtigen 1 2 1 Umweltbezogene Restriktionen Nicht selten kommen Restriktionen die ein Projektleiter einhalten muss von aussen von den Umsystemen Er muss sie befolgen sonst droht ihm z B die technische Isolation _Technologiebezogene Restriktionen e _Computerrestriktionen Verordnungen ein Hersteller schreibt z B etwas vor Marco amp Roger 05 07 05 PRMA 7 88 Eidg Dipl Wirtschaftsinformatiker e Internationale Vorgaben der bermittlungsprotokolle 1 2 2 Firmenbezogene Restriktionen Firmenbezogene Restriktionen geh ren zu den Projektaufgaben die zu Beginn in der Projektinitialisierungsphase definiert werden m ssen und meistens im Auftrag vermerkt sind Diese k
21. 1 0 4292 2 Anerkemnungspr mien Naturalgeschenke 2 Personalfest 40404 _ Spota Freizeit rr r LP Personalwerbung Inserate Vermittlungsgeb hren Transportentsch digung Heizung Strom Reinigung x o o o KalkkMitel bs _ Kalk Eigenmiete 2 Unterhalt Maschinen Apparate 2 Unterhalt 202 222 Trebsof _ Versicherungen Fahrzeuge 2 _ Leasingzinsen 2 Software Kosen bis CHF 20000 2 Formular und Drucksachen 000002 22 o Fachb cher OO Marco amp Roger 05 07 05 PRMA 29 88 Eidg Dipl Wirtschaftsinformatiker LD Dienebe 02 E DEIER 7 Postheckgebu ien O 2 Telekommunikationsgeb hren Apparate amp Anschl sse Fax Tel inteme Kommunikation O o Werbung Filialen 2 Personal ohne MwST 2 x O 2 _ O e S O __ Freiwillige Beitr ge Vergabungen 2 Jirnspre O 2 y Soo C SOS x MwSt auf Leasingraten Abgrenzung Sachaufwand B Di s Abschreibungen Sachanlagen Ausserordentliche Abschreibungen Abschreibungen Immobilien Investitionen Sachmittel Fhz Kunst Maschinen Kommunikationseinrichtungen HW amp SW etc 4 3 Ziel
22. 2 IS Antrag bewerten Schwierigkeiten bei der Bewertung Dynamik der Gesch ftswelt sowie der Informatik Absch tzungen der Komplexit t des Systems Informationsspr nge in der Infrastruktur Einsparungspotenzial Langfristigkeit der Investitionen Strategische Relevanz der Investitionen Zuordnung der Kosten 6 4 2 1 Prozess der Projektbewertung Die Bewertung beinhaltet Vervollst ndigen und Strukturierung Pr fung der Konsistenz mit der IS Architektur Strukturierung und Aufteilung aus 1 macht 2 nderungsantrag kleines Projekt oder Gro projekt Klassifikation im muss kann und experimentelle Projekte Sch tzung der Komplexit t Sch tzung der Risiken Sch tzung der Kosten Bestimmung ob eine Machbarkeitsstudie erfolgen zu Marco amp Roger 05 07 05 PRMA 40 88 Eidg Dipl Wirtschaftsinformatiker 6 4 2 2 Kriterien f r die Bewertung der Projekte im Projektportfolio Strategische Bedeutung des Projekte Unterst tzung von langfristigen Unternehmenszielen Strategiekonformit t Effektivit t Politische Einfl sse Dringlichkeit Unternehmens Vorgaben allg Erh hung der Kundenanbindung Steigerung des Wettbewerbspotenzials Erh hungen der Dienstleistungsqualit t Bedeutung f r betroffene Gesch ftsprozesse Applikationsdefizite IST Applikatorische Voraussetzung Bedeutung f r andere wichtige Projekte technisches Realisierungsrisiko
23. 4 3 MaenDarKeltsstUdlee 42 6 4 4 Entwicklungsplanung EE 42 7 Dokumentation eines Projektes 44 7 1 Sinn und Zweck des Dokumentationssystems 2 2 1 44 7 2 Anforderungen ein Dokumentationssystem 44 7 3 Ablage und Ordungssystem a Ik 44 7 4 Sicherstellung der Projektdokumentation 4 22 22 45 7 5 Massnahmen zur Sicherstellung der 45 7 6 Gliederung der Projektdokumentation 45 7 7 Statische Dokumentation Abwicklungsdokumentation 46 ee re GE 47 VOorstudien DOKUMENT uu u uu uu ee 47 7 7 3 47 7 1 4 Pllichtenhell 48 7 129 8 llerleNKald 09 22 48 7 15 Detallkonzepl Dok ment 222 ee 48 7 7 7 5 48 7 7 8 Inhalt 2 2 9 48 7 1 9 ldsen zum Projekt uflrag 2 82 88 m Lun m u DENE 49 7 8 Dynamische Dokumentation Systemdokumentation 49 7 8 Reg Din
24. Datenbankarchitekt ist eine spezielle Auspr gung des Entwicklers Er entwirft das Datenmodell f r das gew nschte System Er berichtet an den Projektleiter Konfigurationsmanager Der Konfigurationsmanager entwirft ein Konzept f r das projektspezifische Konfigurationsmanagement Versionsverwaltung und berwacht dessen Einhaltung Er berichtet an den Projektleiter Tester Tester sind f r die Vorbereitung Durchf hrung und Dokumentation der verschiedenen Testauspr gungen Komponententest Systemtest User Acceptance Test Lasttest zust ndig Die Tester berichten an den Qualit tsmanager Projekt Controller Der Projekt Controller wird bei gro en oder kritischen Projekten eingesetzt Er berwacht ob alle f r das Projekt geltenden Regelungen eingehalten werden und initiiert gegebenenfalls Gegenma nahmen Die Projektorganisation ist im Projekthandbuch zu dokumentieren Marco amp Roger 05 07 05 PRMA 13 88 Eidg Dipl Wirtschaftsinformatiker 3 Risiken eines Projektes PRMA Buch Seite 88 ff Gem ss Lehnher Leh 1991 wird unter Projektrisiko die H he des Schadens verstanden den ein Komplexe Projekte enthalten eine Vielzahl von unbekannten Faktoren die dieses in irgendeiner Form gef hrden k nnten Es ist die Aufgabe des Projektleiters diese Risiken vorauszusehen und die m glichen Sch den abzusch tzen 3 1 Teilrisiken Aufgrund der obenstehenden Definition wird von einem sogenannten Gesamtris
25. Dokumentationsarbeit gespart mit dem Argument diese Arbeit werde nachgeholt Die Praxis zeigt dass dies bei den seltensten Projekten der Fall ist Daher muss das Projekt Informationssystem durch ein Kontrollsystem berwacht werden Dieses Kontrollsystem sollte folgende periodische Pr fung beinhalten e Vollst ndigkeit IST Zustand und Prognose e Zuverl ssigkeit Genauigkeitsgrad muss bekannt sein e Aktualit t Lieber sofort und gut gesch tzt als auf zwei Kommastellen genau und berhaupt nie e Einfachheit der Ausf hrung vom groben ins Detail e WWirtschaftlichkeit Wurden die Informationen pr gnant und einfach erstellt Hierarchiegerechtigkeit Wie sage ich es dem Benutzer Feedback Hat der Empf nger eine schriftliche oder m ndliche Antwort auf die erhaltene Information gegeben e Wahrnehmen der Informationsverantwortung 7 6 Gliederung der Projektdokumentation Projektdokumentation Abwicklungsdokumentation Systemdokumentation Statisch Dynamisch Phasenabh nige Phasenunabh nige W artungs Betriebs Benutzer Dokumentation Dokumentation dokumenation dokumentation dokumentation Abb Gliederung der Projektdokum entation Marco amp Roger 05 07 05 PRMA 45 88 Eidg Dipl Wirtschaftsinformatiker 7 7 Statische Dokumentation Abwicklungsdokumentation Diese Dokumentation zeigt die unver nderten Arbeitsergebnisse sofern sie nicht in ein dynamisches Dokument einfliessen Dazu z hlen die E
26. Freigabe 6 Monate 8 Antrag Aufgrund der hohen Nutzen gegen ber den Kosten eines Optischen Archives beantrage ich die Freigabe des Projekts 12 5 Projekt Management Summary CAT Beschreibung der Firma Die Hypobank ist die marktf hrende Z rcher Universalbank mit nationaler Ausrichtung Gemessen an der Bilanzsumme ist sie die gr sste Kantonalbank und drittgr sste Schweizer Bank Als selbst ndige und ffentlich rechtliche Anstalt des Kantons Z rich geniesst sie Staatsgarantie Ausgangslage Das Marktumfeld im Kreditgesch ft hat sich in den letzten Jahren markant versch rft Neue Anbieter Postfinance Privatbanken Pensionskassen Versicherungen Makler und Finanzberater dr ngen in den hart umk mpften Hypothekarmarkt ein Gleichzeitig hat die Markttransparenz durch neue Vertriebskan le Immobilien Portale und spezialisierte Medien Immobilienberatung ber TV direkte Preisvergleiche in Konsumentenpublikationen zugenommen Diese Marktentwicklung zwingt die Kreditanbieter zu neuen Gesch ftsmodellen welche nur mit erh hten Investitionen in IT Systeme realisiert werden k nnen Die ber den Banken lastende Marco amp Roger 05 07 05 PRMA 84 88 Eidg Dipl Wirtschaftsinformatiker Kosten Ertrags Schere hat in den neunziger Jahren zu einem Konzentrationsprozess gef hrt von dem vor allem grosse Anbieter profitieren Als Preis und Kostenf hrer setzen diese Technologie Standards der Branche Zur weiteren Aussch
27. Informationsaustausch auftraggeber 5 we Interventions Verantwortung Projekt ausschuss Projektleiter Projekt Controller Marco amp Roger 05 07 05 PRMA 35 88 Eidg Dipl Wirtschaftsinformatiker 5 6 Die Instrumente des Projektcontrollers Analyseinstrumente Risiko analyse Projektplan steuerung Ressourcen steuerung Projektcontroller hat die Aufgabe die Risikofaktoren im Projekt zu erkennen und einzusch tzen Der Projektcontroller analysiert die schriftlichen Vereinbarungen Projektauftrag Vertr ge Projektpl ne und f hrt Gespr che mit verantwortlichen Personen im Projekt sowie in dessen Umfeld Input Output Projekt Matrix bericht 5 6 1 Risikoanalyse 5 6 2 Projektplansteuerung Angefallene IST Werte werden den festgelegten SOLL Werten gegen bergestellt und unter Ber cksichtigung der abgelaufenen Projektzeit beurteilt In die Kontrolle sind alle quantifizierbaren Projektgr ssen wie Zeit Aufwand und Kosten 7 auch Leistungen miteinzubeziehen Resssourcensteuerung Projektbericht 5 7 Aufgaben der Projektkontrolle Wie sieht es terminlich aus Wie gross ist die Restdauer der Aktivit t Welcher Aufwand ist aufgelaufen Welche Restkosten sind noch zu erwarten Welche direkten Kosten Wie steht es mit der Qualit t der Ergebnisse Aufwand Kosten Wert er geleisteten Arbeit Wie gross ist der Arbeitsfortsc
28. Le ele E In EE 49 1 0 2 Betriepsdokume iIaligii eebe 50 7 8 3 50 7 9 Man gement summary dee 50 ZWeck EE 50 7 9 2 Deckblatt des Management Summary 50 EE 51 7 9 4 Arten von Management Gummanvs 51 7 10 Dokumentenergebnisse aus den Projektphasen 2 2 53 7 11 Proj kteBeriChttWesS riuuuuuuuu Sa Ee 54 7 11 1 Zwingende Berichte Dokumente f r ein 56 8 Projektsitzung und Prasentationen 57 8 1 Moderation Sitzungsleitung T 57 fe Bee ee WE 57 Ee 57 8 2 ProjekKtsitzungen a u 57 8 3 EEN 58 O ZWECKE u s uu ee 58 3 932 EINS IZ 58 ABlaUl es 58 8 4 EE d EE 58 BA E 58 8 4 2 59 8 4 3 Prasehlallonstechhikasn en 60 8 4 4 Gliederung der 61 8 4 5 Inhalt Folien Gestaltung EE 6
29. Roger 05 07 05 PRMA 26 88 4 Projektmanagement Eidg Wirtschaftsinformatiker 4 1 Steuerungsmassnahmen bei Projektverzung Leistungsreduzierung Veersionskonzept Priorit tentenderschiebung Wechsel der verfolgten L sung Ablehnung von nderungsw nschen R ckgriff auf Alternativen Einbau von Sicherheiten Verschiebung des Endtermins Fortbildung der Mitarbeiter Projektmarketing Motivationsf rderung Transparenz Offene Informationspolitik Pers nliche Anerkennung Delegation Verbesserung des Arbeitsumfeldes Marco amp Roger 05 07 05 PRMA Parallelarbeit nderung der zeitlilchen logischen Abfolge Technikeinsatz Streichung unwichtiger Arbeitspakete Umverteilung innerhalb Puffer Einstellung zus tzlicher Mitarbeiter Zukauf externer Kapazit ten berstunden Mehrarbeit Informationssystem ausbauen Kommunikationssystem verbessern Abschirmung der Mitarbeiter Intensivierung der Planung Erh hung der Kontrollen Sorgf ltige Ursachenforschung R umliche Zentralisierung Optimierung der Sachmittelausstattung 27 88 Eidg Dipl Wirtschaftsinformatiker 4 2 Projektkosten und Budget S mtliche Angaben in CHF 2002 2003 2004 2005 2006 Realisierungs Einf hrungskosten Entwicklungsaufwand Intern IT TT _Entwicklungsaufwand Extern IT 4 4 4 _Entwicklungsaufwand Intern Bankfach J Bereitstellung Entwicklungs BE Bereitstellung Entwicklungs
30. ZS besch ftigt in ca 9000 Mitarbeiter in der ganzen Schweizverteilt Hauptsitz ist in Z rich 2 Ausgangslage In der Z rich Region Schweiz ist heute Windows im Einsatz das per Juni 2002 am Ende seines Lebenszyklus ankommen ist Der Hersteller Microsoft als auch der restliche Markt gibt zum Produkt keine weitere Unterst tzung Des weiteren ist mit dem Zusammenschluss vom Konzern welche im Moment Windows 2000 verwenden der ZS und des Rechenzentrums in Schlieren mit der ZCH zu einem IT Service Center ein komplexes und heterogenes Umfeld entstanden Diese Situation f hrt zu aufwendigen Umgehungsl sungen und zu Mehraufwendungen in der Organisationseinheit ITSC 3 Ziele Das infrastrukturelle Erneuerungsprojekt wird der heutigen unzul nglichen Situation Abhilfe verschaffen Aus vier Hauptaspekten wird die neue eWP Infrastruktur auf der Basis von Windows XP Client Systemen und Windows 2000 Servern mit dem Verzeichnisdienst Active Directory den ihr gestellten Anforderungen entsprechen Diese sind Abl sung der end of life Infrastruktur durch Produkte mit entsprechender Marktunterst tzung Konsolidierung und Verringerung der Komplexit t Vereinheitlichung der eWP Verrechnungsmodelle Erzielung von zuk nftigen Kosteneinsparungen Marco amp Roger 05 07 05 PRMA 81 88 PRMA Eidg Dipl Wirtschaftsinformatiker 4 Planung und Kosten 1st Quarter 3rd Quarter 131 Quarter Srd Quarter Start Fi
31. bei Changes Problemen oder auch bei nderungen von Rahmenbedingungen ist auf das Interesse des Kunden ausgerichtet Das Know how der GB IT Mitarbeiter speziell im angestammten Bereich aber auch das notwendige Bankwissen ist aktuell Die GB Mitarbeiter bringen den Partnern Respekt entgegen Sie sind ehrlich offen freundlich positiv und sie sind teamf hig Die GB IT Mitarbeiter bringen neue Ideen ein sei das aus Erkenntnissen anderer Projekte oder aus dem Markt state of the art Die Auftraggeber und Businessvertreter werden m glichst fr h aktiv in alle relevanten Entscheidungs Entwicklungs oder Probleml sungsprozesse eingebunden Der GB IT vermittelt relevante Informationen sowie ihr Know How ber die IT Projekte effizient zum Business Eidg Dipl Wirtschaftsinformatiker Die GB IT Mitarbeiter werden als _Kundenorientierung O Bewertung flexibel kundenorientiert stabil kompetent und professionell wahrgenommen Allgemeine Bemerkungen des Interviewers 12 3 Projektmanagement Summary Projekt XP Management Summary Projekt Rollout XP 1 Beschreibung der Firma Die Z rich Schweiz nachfolgend ZS genannt ist eine Gesch ftseinheit des weltweit t tigen Versicherungs und Finanzdienstleistungsunternehmens Z rich Financial Services Kerngesch fte der Z rich Schweiz sind die Lebens und Nichtlebensversicherung sowie die Fonds und Verm gensverwaltung Die
32. den Hilfsmitteln umgegangen e Wie haben sie die technischen und organisatorischen Anforderungen gemeistert e Wie wurde der vorgegebene Zeitplan und das Budget eingehalten e Welche Wirkung hatte der Projektleiter wie erf llte er seine F hrungsaufgaben e Wie wurde auf Massnahmen des Steuerungsgremiums reagiert Direkt und Indirekt Betroffene Pr fung folgender Aspekte e Welche organisatorische und oder technische Leistung wurde von ihnen erbracht Welche Rolle spielten sie zu welchem Zeitpunkt w hrend der Projektdurchf hrung e Wie gingen sie mit den offiziell erhaltenen Informationen um es inoffizielle Kommunikationskan le Haben sie dem Projekt gen tzt oder geschadet Marco amp Roger 05 07 05 PRMA 69 88 Eidg Dipl Wirtschaftsinformatiker 10 1 2 3 Fragenbereich f r Projektabschluss Beurteilung nein Abb Fragenkette f r Produktabahme Marco amp Roger 05 07 05 PRMA 70 88 Eidg Dipl Wirtschaftsinformatiker 10 1 3 Erstellung Projektabschlussbericht Der Projektabschlussbericht enth lt alle entscheidenden Ergebnisse der Sequenzen Produktabnahme und Projektabschlussanalyse sowie die offizielle Regelung der bergabe des Produktes durch den Auftragnehmer Dieser Bericht sollte in der Regel mit jedem Betroffenen besprochen werden bevor er als offiziell gilt Projektabschluss Inhalt Res mee des gesamten Projektteams Positive und negative Erfahrunge
33. die Abschlussarbeiten mit sich bringen Erbrachte Leistungen k nnen genau nachvollzogen werden Motivation kann eher bis zum definierten Schluss beibehalten werden Die Mitarbeiter k nnen sich danach 100 tig auf ihre neue Aufgabe konzentrieren e Durch die Projektanalyse werden Schw chen und St rken aufgedeckt und daraus kann das gesamte Unternehmen profitieren 10 1 Projektabschluss T tigkeiten Produktabnahme Projektabschluss Projektabschluss Erfahrungssicherung Einf hrungs Projektaufl sung beurteilung bericht nachbearbeitung Abb Arbeiten in der Projektabschlussphase Die in der Abbildung aufgef hrten Sequenzen werden nachfolgend kurz erl utert Ob die gezeigte Reihenfolge chronologisch richtig ist ist weitgehend irrelevant Vielmehr geht es darum diese sechs Punkte mit den zust ndigen Personen durchzuarbeiten Die grundlegenden Ziele einer Projektaufl sung sind offizielles Bekannt geben des Projektabschlusses Neuzuteilung der Verantwortlichkeiten e Offizielles Aufl sen der Projektgruppe Sichern der Erfahrungswerte e Festhalten des Systemzustandes zum Zeitpunkt des Projektendes Der Zeitraum der Projektabschlusst tigkeiten in einem 15 umfasst je nach Gr sse des Projektes zwischen 2 6 Monate Am idealsten ist es gewisse Arbeiten nach ca 2 3 Betriebsmonaten auszuf hren 10 1 1 Produktabnahme Bei der Produktabnahme geht es darum das im Auftrag formulierte und schlussendlic
34. gliedert sich in 4 Phasen Erste Phase die Einleitung Teilnehmer begr ssen Vorstellung des Pr sentators Agenda Rahmenbedingungen erl utern Zielsetzung erkl ren Zweite Phase der Vortrag Thema erl utern Dritte Phase die Diskussion Dir Fragen der Teilnehmer beantworten gem ss Spielregeln Vierte Phase der Abschluss offizieller Abschluss erl utern wie es weiter geht ev Ank ndigung des Protokolls oder eines Ergebnisses 8 4 2 4 Nachbearbeitungsphase Ergebnisprotokoll erstellten und m glichst am gleichen Tag den Teilnehmern zustellen Man verkritik wurde das geplante Ziel erreicht Was war gut was ist beim n chsten zu verbessern War die Zielgruppe richtig gew hlt War der Ort gut gew hlt War der Zeitpunkt richtig Marco amp Roger 05 07 05 PRMA 59 88 Eidg Dipl Wirtschaftsinformatiker 8 4 3 Pr sentationstechnik Wie kann man Spannung erzeugen bermitteln durch machen von Pausen muss nat rlich wirken Modulation der Stimme direktes Ansprechen der Teilnehmer rhetorische Frage stellen die ICH Form verwenden Ich bin der Meinung versuchen zu lachen gl cklich zu sein 7 Muskeln wird auf die Zuh rer bertragen mit dem Publikum etwas erarbeiten z B Auf Folie die Milestones eintragen Auftreten beim Pr sentieren Augenkontakt sicher stellen alle Teilnehmer ber cksichtigen nicht nerv s auftreten jedoch auch nicht zu statisch wirken Vorsic
35. k nnen Contingency Planning Verantwortung Contingency Planning oder Eventualfall Planung heisst sich f r den Eventualfall vorzubereiten und aus den vorhandenen M glichkeiten die beste L sung auszuw hlen Ein Eventualfall Plan ist dem Change Management unterstellt und wird regelm ssig getestet Der Contingency Planning Prozess Planung Marco amp Roger 05 07 05 PRMA 17 88 Eidg Dipl Wirtschaftsinformatiker Die Auswirkungen eines Eventualfalles auf das Gesch ft und welche Gegenmassnahmen gerechtfertigt sind Implementierung durch das Erstellen des Contingency Planes berpr fung durch regelm ssiges Testen und berpr fen der Aktualit t des Planes ur Ermittlung der Risiken werden in der Eventualfallplanung Risikomanagementtechniken eingesetzt N 9 9 9 05 07 05 PRMA 18 88 Eidg Wirtschaftsinformatiker 3 7 Ablauf einer Risikoanalyse Graphisch Risiken Ursachen Eintrittswahr Tragweite ermitteln beschreiben cheinlichkeit Kosten berechnen bewerten Bild Ablauf einer Risikoanalyse vermeidbare Risiken gt unvermeidbare Risiken gt l Fr hwarn SEH Pr ventiv Risikograd system massnahmen bestimmen definieren festlegen a vorhersehen einrichten Risiken vermeiden Risiken vermindern 3 8 Zeitpunkt der Risikoanalyse Graphisch
36. wird die Phase Hauptstudie erarbeitet Es fasst alle geleisteten Arbeiten zusammen Marco amp Roger 05 07 05 PRMA 47 88 Eidg Dipl Wirtschaftsinformatiker e Erarbeiten einer detailierten Konzeption auf der Basis des in der Vorstudie gew hlten L sungsvorschlages Benutzersicht Festlegung der daraus reultierenden Anforderungen und Voraussetzungen Personal Hard und Software R ume organisatorische und technische Hilfsmittel usw 7 7 4 Pflichtenheft Wird aufgrund der L sungserarbeitung Vorstudie beschlossen L sungen oder auch nur Teill sungen auf dem Markt einzukaufen so wird die Erstellung eines Pflichtenheftes notwendig e Im Pflichtenheft werden die angestrebten Ziele Anforderungen und W nsche das zuk nftige System formuliert Damit wird das Pflichtenheft zur unentbehrlichen Grundlage f r die Offertabgabe 7 7 5 Kriterienkatalog Der Kriterienkatalog wird parallel zur Anforderungsdefinition des Pflichtenheftes erstellt Er definiert die Werte die das neue System oder Objekt aufweisen muss Der Kriterienkatalog besteht im wesentlichen aus zwei Teilen e die vom Projektteam in Vertretung des Benutzers verlangten Kriterien mit den relativen und absoluten Gewichtungen e freien platz f r sp tere Eintragungen der Ergebnisse aus der Offertbewertung 7 7 6 Detailkonzept Dokument Wurde nach der Vorstudie auch die Hauptstudie gutgeheisen so wird der Phase Detailstudie das
37. 1 64 6 Spickzellel uuu 63 EE 63 an een ai 64 9 Einf hrung 65 GERT EN 65 92 Ranmenorganisation WEE 65 Marco amp Roger 05 07 05 PRMA 3 88 Ce tele EE UE 66 98341 Einfl ssfakl fen ann ee lee 66 9 3 2 Arten von Einf hrungen 66 94 E 67 el 67 9 42 ele ele EE 67 9 4 3 67 10 Projektabschluss 68 10 1 Projektabschluss T tigkeiten 68 DN Wa Geet a ele In VE 68 10 1 2 5 0 0 00 68 10 1 3 Erstellung Projektabschlussbericht 71 10TA ErfahrungssichelUng au u uuu ae ee He 71 10 1 5 Emt brungs Nachbearbetung 71 10 1 9 Pro jeklteam Aull sungs Asse nee ie 71 10 1 7 Projektaufl sung Checkliste A 71 11 Diverse Checklisten zu Projektabwicklung 73 11 1 Wi start Ich ein Projekt u un sea aa 73 11 2 Vom Antrag zum Projektauftrag 73 11 3 bersicht Institutionelles 0 4 1 2 4 u u u 74 11 4 Projektnutzen Auflistung von
38. 8 1 Moderation Sitzungsleitung 8 1 1 Moderation siehe PRMA Seite 400 Ein guter Moderator erf llt die folgenden personenbezogenen Anforderungen Neutralit t Soziale Sensibilit t Sprachliche Ausdrucksf higkeit Sachliche Kenntnisse der Arbeitsmethoden Techniken Allgemeine Akzeptanz bei den Gespr chsparteien Die erfolgreiche Leitung einer Sitzung verlangt vom Moderator Gr ndliche Vorbereitung Formulierung und Durchsetzung der gemeinsamen anerkannten Spielregeln Aktive F hrung der Gruppenarbeiten Lenkung mittels Aufgabenorientierung damit gemeinsames Ziel verfolgt wird Mittels Zuspruch Anerkennung und Aufmunterung steigert er den Gruppenzusammenhalt Durch Abgrenzung der pers nlichen und der sachlichen Ebene verhindert er negative zwischenmenschliche Beziehungen 8 1 2 Sitzungsleitung Ein grosser Teil des Erfolges einer Sitzung liegt in der Vorbereitung siehe Pr sentation Seite 58 Festlegung des Ziels Festlegung der Traktanden Agenda und Sitzungsdauer Teilnahme der richtigen Personen Fr hzeitige Information der Teilnehmer anhand der notwendigen Unterlagen Aufgaben des Gespr chleiters dass das Ziel der Sitzung erreicht wird die Zeit und das festgelegte Vorgehen eingehalten werden bei Abschweifung die Teilnehmer zum Thema zur ckf hren alle Teilnehmer zu Wort kommen und niemand bevorzugt oder benachteiligt wird St rungen Konf
39. Die rechtlichen und systemtechnischen Abkl rungen sind zu einem positiven Resultat gelangt Projektteam Projektteam empfiehlt daher umgehend die Phase Definition zu initiieren Antrag Das Projektteam beantragt Abnahme des Business Case Gesch ftsmodell CAT Freigabe der Definitionsphase und der damit verbundenen Mittel von CHF 1 5 Mio Marco amp Roger 05 07 05 PRMA 86 88 Eidg Dipl Wirtschaftsinformatiker INDEX A Projektteam 10 N Ablauf einer Risikoanalyse 19 ProjMngt E 9 Nicht quantifizierbarer Nutzen Abschluss bericht 55 Erfolgsfaktoren GENEE 74 Abwicklungsdokumentation 46 Evaluation O Akzeptanzpr fung 67 ZF_STSW 30 Organisation 11 Amortisation 28 Experten Gespr ch 63 P Ansprechpartner des F parallel Einf hrung 65 Auftraggebers 12 Ferienstopp 16 Personal und Finanzplanung 43 37 Finanzplanung 43 11 Flipchart 63 Pflichtenheft 48 Beamer 62 Fragenbereich Pilot Einf hrung 65 Benutzerdokumentation 50 Beurteilung Abschluss 69 Pinwand 63
40. Information nicht zur Verf gung steht Man weiss nicht dass die Information berhaupt existiert Man weiss zwar dass die Information existiert aber nicht wo Man weiss zwar wo die Information existiert aber sie ist unzug nglich Man weiss zwar wie man auf Information zugreift aber sie hatte das falsche Format Man weiss zwar wie die Information ist aber sie ist entweder irrelevant fehlerhaft unvollst ndig veraltet oder steht nicht zum richtigen Zeitpunkt zu Verf gung Unzufriedenheit Qualit tsziele 5 sehr Wichtig IT wird voll unterst tzt k rzere Verarbeitung 4 wichtig 1 Kundenzufriedenheit 3 n tzlich 2 zufriedene MA 2 to Nicht durch IT unterst tzt Wettbewerbsf higkeit 1 nicht wichtig Flexibilit t Unabh ngigkeit Banken Lief Termintreue Wirtschaftlichkeit Kostenred Organisation Markanteil ausbauen Wachstum Marco amp Roger 05 07 05 PRMA 38 88 PRMA Eidg Dipl Wirtschaftsinformatiker 6 2 Ablauf im IS Projektportfolio Projektportfolio Formelles Pr fen des Aufbereiten des Bewertung der Projektvor Antrages auf Voll Antrages f r die haben gem ss Kriterien st ndigkeit amp Konsistenz Bewertung im Projekt raster portfolio E Bewertungsvorbereitung Bewertung durch Analyst Projektportfoliomanager Projektportfoliomanager Aufwand lt 2 PM Aufwand gt 2 PM nderung
41. Zusammenfassung PRMA Lehrgang Eidg Dipl Wirtschaftsinformatiker 2002 2003 Autor Marco Storchi amp Roger Wiesendanger Version ZF PRMA 030414 Benutzer Eidg Dipl Wirtschaftsinformatiker INHALTSVERZEICHNIS 1 Einflussgr ssen eines Projektes 7 1 1 Rahmenbedingungen f r die Projektabwicklung 7 1 2 Restriktionen in einer Projektabwicklung 7 1 2 1 Umweltbezogene Restriktionen 7 1 2 2 Firmenbezogene Restriktionen 8 1 2 3 Risikobezogene 8 1 2 4 Systembezogene Restriktionen nennen nenne nnnnnne nennen nenne 8 2 Erfolgsfaktoren eines Projektes 9 2 KR Ge E ee EE 9 2 2 Erfolgsfaktoren eines Projekts u u 9 2 2 1 Projektmanagement Funktionen 9 222 2 E 10 2 2 3 Projektabwicklungs lnstrumente nenne 10 22A POONG utu eb euere 11 2 2 5 EE E 11 3 Risiken eines Projektes 14 TellriISIKen EE 14 3 2 ENIWICKlUNgsrIsiken ac nn ea 15 3 3 Managementrisiken u enge 15 3 4 Soziale Risiken nu
42. agement mit nicht gen gend ernst Umst nde hat stattgefunden es betriebsblinden Personen ist immer so beteiligte Sensibilisierung Personen darauf hin dass ein Umstand normal ist Wir kommunizieren die Risiken Nicht publizieren eigener Risiken Offene Kommunikation nicht gen gend Angst vor Schlappe Verst ndnis f r Probleme f rdern Nicht alle Projektmitarbeiter sind MA habe nur eine begrenzte Klare Information berblickbare optimal informiert Sicht im Projekt Aenderungen Dokumentationsstruktur Vortschritte und Probleme sind IInfomationen zug nglich nicht allen bekannt machen Holschuld der Information einf hren z B bei wiederkehrenden Informationen Das Verh ltnis zu allf lligen Kein spezifischer gepr fter Klarheit schaffen Requirement Unterlieferanten ist unklar Vertrag vorhanden Aufgaben Itraceability aufzeigen Funktionen nicht abgrenzt Lieferergebnisse Iklassifizieren und Verantwortungsbereiche sindjauflisten gruppieren und oder Zustand der Lieferungen sind nicht abschliessend definiert Pr fmassnahmen der technische Leistungsabh ngige Zahlungs Ergebnisse sind ungen gend Meilensteine definieren im oder nicht vereinbart es existiert Vertrag Nachweis des keine Pr fung der Lieferanten f r Projektmanagementergebnisse vertragskonformes Produkt Audits Projektmanagement verlangen Reviews es gibt keine strukturierten Projektberichte Gemeinsame L sungssuche Eskalation
43. ammenfassung Unter Management verstehen wir Personen und Personengruppen in der Unternehmenshierarchie die ber Entscheidungs und Anordnungsbefugnisse verf gen z B die Gesch ftsleitung Das Management Summary soll also in einer stark komprimierten Form als zusammenfassender Bericht dienen Wo sinnvoll kann auch eine einfache schematische Grafik eingef gt werden Dabei sollte ein Management Summary ohne spezielle Vorkenntnisse zu lesen sein Der Inhalt soll zielgruppengerecht aufgearbeitet sein und als Entscheidungsgrundlage dienen k nnen F r die Zielgruppe Management Gesch ftsleitung sind daher weniger technische Details sondern vielmehr betriebswirtschaftliche Aussagen Konsequenzen und Zusammenh nge aufzuzeigen Deckblatt des Management Summary Marco amp Roger 05 07 05 PRMA 50 88 Eidg Dipl Wirtschaftsinformatiker Verteiler Datum Titel Kopf mit Projekttyp Version Genehmigungsvermerke Unterschriften 7 9 3 Struktur Ausgangslage Grundlagen oder Situationsanalyse kann z B Aussagen enthalten ber Trends Unternehmungsstrategie Informatikstrategie Marktsituation Konkurrenzsituation Situation vor Projekt Gr nde f r Projektvorhaben definierte Ziele gem ss einem Auftrag L sungsans tze Produkte oder Dienstleistungen generelle Beschreibung der in Frage kommenden Produkte und Dienstleistungen oder erarbeiteten L sungsvarianten Entwicklung Produktion oder Einf hrun
44. anungsbericht Termine Reviewer PSA sporad Dient der PSA dazu die Kosten Statusberichte des PLs Aufw nde mittels Review zu kontrollieren Dient dem PL dazu die eigenen Planung pr fen zu lassen Das Reviewboard wird durch den PL oder PSA beauftragt Der Review erfolgt sporadisch oder bei grossem Planungsrisiko Management Ziele PSA 1 der PSA sich Summary Ergebnisse der Phase Auftraggebe einen schnellen Projektstand r berblick ber eine Fortschritt Kosten Phase zu verschaffen Termine Der PL entlastet sich Risiken durch die Erstellung des weiteres Vorgehen Antrag Entscheid Massnahmen Probleme Hauptaktivit ten der Berichtsperiode Phasenberichts und die Komprimierung der Daten zu einem Mgmt Summary Der Bericht wird am Schluss jeder Phase erstellt Marco amp Roger 05 07 05 PRMA 55 88 Qualit tsbericht Terminkenngr ssen 5 eingeleitete QS Massnahmen er Fehler und Probleme bez glich QS Kosten der eingeleiteten Massnahmen Produktivit tsangaben bez glich QS Reviewbericht Istdaten Beurteilung Gewichtung m gliche Massnahmen Abschluss bericht Zielerreichung Begr ndung f r Abweichung Wichtige Entscheidungen im Verlauf des Projektes Wirtschaftlichkeit Erfahrungen des PL und des Teams offene Punkte weiteres Vorgehen Fazit PL Beauftragt Projektplanungsdaten Reviewer Eidg Dipl Wirtschaftsinformatiker Bezei
45. auftreten k nnen Projektleitungsrisiko Dies ist eines der am h ufigsten eintretenden Risiken Es beruht vielfach auf der oberfl chlichen Selektion des Projektleiters so dass diese Funktion nicht mit den notwendigen F higkeiten ausgef llt wird Diese Situation ist meistens der Ausl ser anderer Projektrisiken Planungsrisiko Ein Planungsrisiko kann aufgrund von fehlerhaften Planungen bez glich Zeit und Aufwand eintreten Auch die st ndige Zunahme der Anforderungen an das Produkt kann eine m gliche Ursache f r dieses Risiko sein Es f hrt nicht selten zu Performance Problemen die nur mit berdurchschnittlichen kurzfristigen Investitionen gel st werden k nnen Informations und Kommunikationsrisiko Je mehr Unternehmensbereiche in ein Projekt involviert sind desto gr sser wird der Informations und Kommunikatonsaufwand Sind die Beteiligten nicht entsprechend informiert so kann es zu einem Informations oder Kommunikationsmanko f hren Die Folge davon k nnten eine Eigendynamik oder sogar ein Stillstand des Projektes sein Koordinationsrisiko Die Koordination eines Projektes wird durch die Projektgr sse stark beeinflusst Wird nicht Marco amp Roger 05 07 05 PRMA 15 88 Eidg Wirtschaftsinformatiker gen gend Koordiniert so entstehen Doppelspurigkeiten und Insell sungen die das Projekt stark gef hrden k nnten 3 4 Soziale Risiken Motivationsrisiko Menschliche Leistung wird gem ss F h
46. bedingungen Restriktionen externe Abh ngigkeit Projektorganisation Termine und Meilensteine Budget Risikoanalyse Projektinformationswesen 7 8 Dynamische Dokumentation Systemdokumentation Dies betrifft die Dokumente die nach der Einf hrung des Systems auf dem aktuellen Stand zu halten sind da sie f r den Betrieb den Unterhalt und die Weiterentwicklung gebraucht werden Sie stammen zur Hauptsache aus der Realisierungsphase __System _ Betrieb dokumentation Betriebs umgebung z B Operating Arbeitsplatz des Benutzers Abb Struktur der Systemdokumentation 7 8 1 Wartungsdokument Aufbewahrungs Verwendungs ort zweck Entwicklungs Pflege und abteilung Erg nzungen Installation und t glicher Betrieb Funktions durchf hrungs unterst tzung Die Wartungsdokumente basieren auf Entw rfen die aus diversen Phasen des Projektes stammen Folgende Dokumente k nnen als sogenannte Wartungsdokumente bezeichnet werden e Programmvorgabe e Listings _Funktionsbeschreibungen Modulbeschreibungen e System berblick z B Prozessmodell Testfallordner z B Rallyel ufe e Testkonzept und szenario Marco amp Roger 05 07 05 PRMA 49 88 Eidg Dipl Wirtschaftsinformatiker Dokumentation bez glich Unterhaltsverantwortlichen Die Wartungsdokumentation soll die Kommunikation der Systementwickler erleichtern eine Grund
47. berichtet an den Qualit tsmanager e Ansprechpartner des Auftraggebers Es ist u erst wichtig dass dem Projektteam ein kompetenter und entscheidungsbefugter Ansprechpartner des Auftraggebers z B bei externen Projekten des Kunden zur Verf gung steht Dieser Ansprechpartner muss daf r sorgen dass Arbeitsergebnisse Pflichtenheft Prototyp Gesamtsystem von den geeigneten Personen des Auftraggebers gepr ft werden Weiterhin hat er das Projektteam bei R ckfragen bzgl Funktionalit t usw zu unterst tzen Der Ansprechpartner des Auftraggebers berichtet an den Lenkungsausschuss e Entwickler Der Entwickler normalerweise mehrere ist f r die Analyse die Konzeption und die Entwicklung des Systems zust ndig Der Entwickler berichtet an den Projektleiter bzw Teilprojektleiter Die folgenden Stellen Rollen sind je nach Art und Gr sse des Projektes zu besetzen Marco amp Roger 05 07 05 PRMA 12 88 Eidg Wirtschaftsinformatiker Systemanalytiker Der Systemanalytiker ist eine spezielle Auspr gung des Entwicklers Er ist zust ndig f r die Analyse des aktuellen Ist Zustandes und der Dokumentation des gew nschten Soll Zustandes Er berichtet an den Projektleiter Systemarchitekt Der Systemarchitekt ist eine spezielle Auspr gung des Entwicklers Er ist daf r zust ndig aus dem dokumentierten Soll Zustand des Systems ein Konzept zu entwickeln Er berichtet den Projektleiter Datenbankarchitekt Der
48. ch Systemverhalten Massendaten ist nicht bekannt Sehr hohes Einf hrungsrisiko Hoher Aufwand f r Fallback L sung Hohe Belastung f r den Anwender Es k nnen Datenkonsistenz und Integrit tsprobleme auftreten Schnittstellenprobleme Sehr hoher Aufwand f r die Erstellung von tempor ren Schnittstellen 66 88 Eidg Dipl Wirtschaftsinformatiker 12 Nachteil Anwender kann sich laufend ins neue System einarbeiten Laufender Vergleich Alt und Neu m glich Laufende Optimierung des neuen System ohne Betriebsgef hrdung Einfache Fallback L sung Neues System kann unter produktiven Bedingungen vollst ndig berpr ft werden Erfahrungen k nnen vollumf nglich gesammelt werden Operatives altes System wird nicht gef hrdet Unzul nglichkeiten k nnen im operativen Einsatz ermittelt werden 9 5 Konzepte 9 5 1 Einf hrungskonzept Einf hrungsvorgehen strategie Migrationskonzept IST zum SOLL System Mittelbedarf Planung und Organisation Information Ausbildung 9 5 2 Migrationskonzept Die Daten bernahme Datenerhebung qualitativ quantitativ Daten bernahmeregeln Konversionsregeln Datenbereinigungs Datenerfassungverfahren Die Terminplanung Aufwand und Terminplanung Verarbeitungszeit Mittelbedarfsanalyse Risikobeurteilung Was kann alles schief gehen Wie und wann wissen wir wenn etwas schief geht
49. chaftsinformatiker 4 6 Informationsbeschaffung siehe ZF_ISMA 4 6 1 Sinn und Zweck eines Konzepts Stellenwert der Informationsbeschaffung rechtfertigt ein konzeptionelles Vorgehen bei der Informationsbeschaffung _Konzeptionelle Vorbereitungen einer Informationsbeschaffung gew hrleistet Korrekte Abgrenzungen Untersuchungsgebiet _Sachgerechte Auseinandersetzung mit der Problemstellung Kontrollierbarkeit des Vorhabens Qualit t Sicherheit bei den Resultaten Finanzierbarkeit Budgetierung Sicherheit bei der Resultatdarstellung was muss ausgewiesen werden Transparenz gegen ber dem Auftraggeber vor Beginn Konzept tr gt massgeblich zu einer Anforderungsgerechten und qualitativ hochstehenden Informationsbeschaffung unabh ngig vom Vorhaben bei 4 6 2 Fragestellungen zur Informationsbeschaffung Warum braucht es Informationen Zweckbindung Ziel Welche Informationen werden ben tigt Welche sind davon unerl sslich Welche Schl sse sollten daraus gezogen werden In welchem Genauigkeits und Detaillierungsgrad Bis zu welchem Zeitpunkt Welcher Aufwand ist f r die Informationsbeschaffung zul ssig Wo und wie k nnen die Informationen gefunden werden Wer kann mit der Beschaffung beauftrag werden JO gt 4 6 3 Informationsbeschaffungskonzept Informationsbeschaffung zur Kl rung der IST Situation St rken Schw chenprofile Aufbau Ablauforga
50. chnung Inhalt des Berichts Empf nger Periode Beschreibung der Relevanz PSA PL amp Auftraggebe r PSA Team Projekt amp Auftraggebe r 7 11 5 Zwingende Berichte Dokumente f r ein Kundenprojekt Projektauftrag Auftragsbest tigung Projektinitiierung Projektplan 6 Wartungsdokumentation Information Helpdesk 10 11 8 Fehlerhandbuch ER Benutzeranleitung 10 Abschlussbericht f r Kunde 1xMonat Pr fung der Einhatlung der Qualit tsstandards durch den PSA F hrungsinstrument Der QS Beauftragte informiert ber alle QS Massnahmen und die Ergebnisse Der Bericht wird periodisch erstellt und dient dem PL zur Einleitung von entspr Massnahmen PL kann auf Grund des Berichts Massnahmen einleiten F r den PSA ist der Bericht ein F hrungs und Kontrollinstrument Der Bericht wird periodisch je nach Dauer des Projektes durchgef hrt die Periode richtet sich nach der Gr sse der Risiken Dient der PSA zur Nachkontrolle Schlusskontrolle des Projekterfolgs Der PL kann seine Erfahrungen weiteren Projekten zur Verf gung stellen Der Bericht dient zur Entlastung des PLs Der Bericht wird w hrend Phase Projektabschluss erstellt Projektplan Projektfortschrittsbericht Status E Marco 05 07 05 11 Abschlussbericht f r Intern im Betrieb PRMA 56 88 Eidg Dipl Wirtschaftsinformatiker 8 Projektsitzung und Pr sentationen
51. definition Zielformulierung siehe ZF_PROT Eigenschaften eines gut formulierten Zieles e Qualit t Definition des Endzustandes e Quantit t Definition messbarer Gr ssen e Termin Zeitpunkt der Erreichung des Endzustandes Zielformulierungen sind e schriftlich fixiert e mess bzw pr fbar e realistisch und motivierend e l sungsneuftral e klar und konkret e sinnvoll und durchsetzbar e Beteiligten bekannt 4 4 Evaluation siehe ZF STSW Marco amp Roger 05 07 05 PRMA 30 88 Eidg Dipl Wirtschaftsinformatiker 4 5 Requirement Traceability Liste transp Anforderungsliste j 14 2 BF Die wesentlichsten Aenderungen Klammer betreffen Anpassungen in Bezug auf die Klammerung von Gesch ftsf llen BF F r die zur Abwicklung erfolgte Klammer definitive Freigabe von einzelnen bzw geklammerten Auftr gen wird der Status verwendet In diesem Fall lautet der Status weitergeleitet 4 BF Die Minimall sung zielt darauf hin dass Klammer ein Auftrag erst dann definitiv freigegeben werden kann wenn alle zur Klammer geh renden Antr ge freigegeben worden sind Das heisst dass KWICK2000 die ChangeRequest Klammer geklammerten Auftr ge erst sehen darf wurde an wenn die ganze Klammer freigegeben ServiceAuftrage worden ist gestellt BF Auf Protokoll Ansicht Papier Kreditwun OK Kreditwunsch muss eine eventuelle sch Klammerung ersichtlich sein Siehe da zu Kapitel 13 6
52. e Unterst tzungsfunktionen geeignet ex Projektleiter als PR Controller Die Projektcontrolling T tigkeit macht 3 des Gesamtvolumens aus 5 2 Grund f r Projektcontrolling Um Kosten und Terminabweichungen bei der Abwicklung sowie Qualit tsunterschiede beim Produkt feststellen zu k nnen ist eine umfassende Projektabwicklungs und Produktkontrolle notwendig Sie wird in Form von Reviews Inspektionen Qualit ts Audits Test usw durchgef hrt Die Abweichungen bez glich Zeit Aufwand Qualit t Kosten Funktionalit t etc und die daraus gewonnenen neuen Erkenntnisse fliessen wieder in die Projektplanung ein 9 3 Bedeutung des Projektcontrollings Fehlende Transparenz bei den Entscheidungstr gern ber den Projektfortschritt Zunehmender Kostendruck und Budgetknappheit Steigende Gr sse und Komplexit t der Projekte Steigender Zeitdruck zur Realisierung von Informatikvorhaben Zunehmende Integration der Informatik in die Kernprozesse der Unternehmung Fehlendes Projektmanagement Know how in der Linienorganisation 5 4 Zweck Ziel und positive Ergebnisse der Projektkontrollen je fr her ein Fehler aufgedeckt wird desto einfacher ist es ihn zu korrigieren Alle Projektbeteiligte werden auf den gleichen Informationsstand gebracht Kl rung ob evtl vom Projekthandbuch vorgeschriebene Aufgaben bergangen werden k nnen nderungs und Verbesserungsvorschl ge k nnen auf ihre G ltigkeit Anw
53. e Das laufende System nochmals auf seine Funktionalit t Best ndigkeit Leistungsf higkeit und Qualit t zu untersuchen Siehe Kap 10 1 2 1 das System untersucht erungen realisiert sind Projektziele Beurteilen ob die gesetzten Projektziele erreicht wurden Projektnutzen Pr fen ob der Nutzen des Projektes resp des laufenden Systems ersichtlich ist Soll Ist Abweichung Festhalten der Soll Ist Abweichungen pr fung Anforderungen Pr fungsresultate Verfassen eines Projektaudits mit allen Pr fungsresultaten Projekt Mittels des erstellten Projektaudits den Projektabwicklungsprozess abwicklungsprozess durchleuchten und beurteilt Beitr ge der betroffenen Personen und Verhalten des Projektes Siehe Kap 10 1 2 2 Projektabschluss Verfassen eines Projektabschlussbereichtes der alle entscheidenden bericht Ergebnisse festh lt Siehe Kap 10 1 3 bergabe des Festhalten der offiziellen Regelung zur bergabe des Produktes durch den Produktes Auftragnehmer und den Auftraggeber M ngelbehebung berarbeitung in den ersten Monaten festgestellter M ngel bis der Benutzer ohne Probleme funktionell arbeiten kann Siehe Kap 10 1 5 nderungs Festhalten und Sichern der neu geforderten Funktionalit t oder Systemqualit t mangement im Anderungsmanagement Projektabschluss Bei der Projekttr gerinstanz den Antrag auf Projektabschluss stellen Antrag Dokumentation bergabe der bereinigten Projekt und Systemdokumentation
54. ellten Change Requests muss nach PSG Entscheid durch das Bankfach verifiziert 01 werden Costs Status gt mark with Reasons Implications Reasons Implications Measures G Y R for IT for Business Yes Nr No Assessment Plan actual Changes in project scope Durch die Aufteilung in einen SKP Durch die Aufteilung in einen SKP Rel 4 0 und 4 1 k nnen infolge des Mehraufwands bei den IT Ressourcen Engp sse entstehen Rel 4 0 und 4 1 k nnen infolge des Mehraufwands bei den Bankfach Ressourcen Engp sse entstehen Vor allem im Bereich der Tests die somit zweimal durchgef hrt werden m ssen Trend cost development 6 _ Fusszeile Project Manager B Mehmann Stream 1C proSAP Nr X 000942 Sponsor B Marelli Bus Case approved 29 01 2002 Author B Mehmann Page 76 of 88 Data out of SAP Budget Year Budget vs Actual Trend Cost Development Deviation YTD Forecast Forecasted Dev Budget Actual full Year of yearly Budget Monat 11 CHF CHF CHF Marco amp Roger 05 07 05 PRMA 76 88 Eidg Dipl Wirtschaftsinformatiker Primary Costs IT ___ l S S S S S o Secondary Costs IT 989 404 906 955 949087 42132 1 035 368 45 964 Primary Costs Business 458 400 420 200 350 756 69 444 382 643 78757 Secondary Costs Business 595 560 545 930 103 620 442 310 113040 482520 Resources Status gt mark with Reasons Implications Reasons Implications Measures G Y R for IT for Business Yes Nr
55. endbarkeit und Auswirkungen berpr ft werden Marco 05 07 05 34 88 Eidg Dipl Wirtschaftsinformatiker Unbekannte Abh ngigkeiten und ussere Einfl sse werden rechtzeitig aufgedeckt berpr fung der definierten Projektziele auf ihre G ltigkeit und Erreichbarkeit evtl Zielrevision Kl rung ob Projektinstitution leitung und berwachung ausreichen Vertr glichkeit der Pl ne Mittel und Ziele k nnen gepr ft werden Beziehungen zwischen k nftigen Benutzern und Projektteams werden verbessert Gruppenbewusstsein des Projektteams wird gest rkt Feststellung ob das Projekt den gr sstm glichen Beitrag zu den definierten Unternehmens Kunden und MA Zielen liefert Verantwortung f r die L sung der erkannten Probleme kam besser zugeordnet werden 5 4 1 Bereiche der Projektkontrolle Planungskontrolle Aufwand und Kostenkontrolle Terminkontrolle Realisierungskontroll Sachfortschrittskontrolle Qualit tspr fung Projekt Dokumentationskontrolle Projekt Informationskontrolle 5 4 2 Kontrollverfahren Reviews Formelle und informelle Reviews Walkthroughs Inspektioonen Peer Rating Techn Reviews Projektreview Code Inspektion Vernehmlassungsreview Testreview 1 Audits Tests 5 5 Die Unterst tzung der Projektf hrung durch den Projektcontroller Projekt F hrung Projekt Kontrolle Weisungsbefugnis Projekt
56. er 05 07 05 Angaben zum IT Projektleiter Mitarbeiter Leistungserbringer Bewertung 0 10 On Time gilt f r alle zugesagten Termine und bezieht sich auf den jeweils vereinbarten Lieferumfang Die Ergebnisse entsprechen den vereinbarten Anforderungen Die GB IT Mitarbeiter sind stets bem ht ihre Dienstleistungen so auszurichten dass f r die Kunden ein Mehrwert entsteht GB IT strebt eine hohe Kosten und Planungs transparenz an Weisen die Reports auf gr s sere Abweichungen hin so wird die Situation unmittelbar den Betroffenen kommuniziert Das Verhalten bei Changes Problemen oder auch bei nderungen von Rahmenbedingungen ist auf das Interesse des Kunden ausgerichtet Das Know how der GB IT Mitarbeiter speziell im angestammten Bereich aber auch das notwendige Bankwissen ist aktuell Die GB IT Mitarbeiter bringen den Partnern Respekt entgegen Sie sind ehrlich offen freundlich positiv und sie sind teamf hig Die GB Mitarbeiter bringen neue Ideen ein sei das aus Erkenntnissen anderer Projekte oder aus dem Markt state of the art Die Auftraggeber und Businessvertreter werden m glichst fr h aktiv in alle relevanten Entscheidungs Entwicklungs oder Probleml sungsprozesse eingebunden PRMA 78 88 9 Informationsvermittlung 10 Kundenorientierung berhaupt nicht zufrieden zufrieden 0 4 7 8 Interpretation Marco amp Roger 05 07 05 Eidg Dipl Wirt
57. er eigenen Erhebung Personenkenntnisse Aufgabentr ger Techniken bestimmen pro Personenkreis Vorbereiten Technik Kenntnisse erlangen Nutzen aufzeigen QS mit kleinem Personenkreis inkl Auswertung Terminplanung wann wo wer wie wie lange etc Unterlagen verteilen Fragebogen Selbstaufschreibungsformular etc Basis ist die vorbereitete Empf ngerliste Durchf hrung der Informationsbeschaffung Sitzungen gt Interview abhalten gt Multimomentstudie Dokumentenstudium QS R cklaufquoten etc Resultatsammlung ggf Zwischenresultate Auswertung Verdichtung z B Zusammenfassung gleichartiger Aussagen Darstellung Pr sentation keine Analyse 5 wenn Entscheidungsgrundlage Detailberichte etc Marco amp Roger 05 07 05 PRMA 33 88 Eidg Dipl Wirtschaftsinformatiker 5 Projekt Controlling berwachung sieh ZF_ISMA controlling Auftraggeber Projektauftrag Ziele Projektleiter Projektunterst tzung 1 Projektplanung Projektabwicklungs zyklus 2 Projekt Steuerung Output Input SOLL Werte IST Werte Projektgruppe Proiektdurchfiihr ino 5 1 Aufgaben des Projektcontrollings Informationsmanagement verdichtete Berichte Mgmt Summarys etc Risikobeurteilung Kosten Termin Kontrolle Sachfortschritts Kontroll
58. erteilt K nnen z B bestehen aus Zeitungsartikeln Prospekten Zusammenfassungen etc 8 4 6 Spickzettel Moderatorenkarten Gr sse einer Karteikarte ist gut handhabbar Festigkeit des Papiers gibt l ngere Lebensdauer Stichworte erlauben freies Formulieren Anschauen Aufschauen Aussprechen 1 Satz ausgeschrieben Stichwort a erg nzende Angaben Stichwort b Stichwort c 1 Stichw ort der n chsten Karte 8 4 7 Medien Tipps zum Einsatz F r bis zu 300 Teilnehmer Vorbereitung sehr wichtig Vorher ausprobieren Darstellung mit Bild Video Ton Systemvoraussetzungen kl ren z B Internet Direkte Pr sentation von Anwendungen oder Remax Anschluss BankWeb Internet etc Reihenfolge bei Einschalten der Ger te beachten Wirkt sehr professionell Abkl ren wie in Pausenzeiten die Leinwand verdunkelt werden kann Besonders leicht zu bedienen ist der PC mit der passenden Funkmaus Als Reserve Folien und Projektor bereithalten Verl ssliche Technik Zum Publikum sprechen nicht zum Projektor F r Pr sentationen bis zu 150 Teilnehmer Zeigen nicht mit dem Finger sondern mit einem Stift Zeigen nicht an der Leinwand sondern auf dem Projektor Stift liegen lassen Spontane Erg nzung der Folien w hrend der Pr sentation mgl Bei Erl uterungen den Projektor ausschalten Marco amp Roger 05 07 05 PRMA 63 88 Eidg Dipl Wirtschaftsinformatiker Vorteil Tip
59. es darum das System Produkt anhand folgender Kriterien zu bewerten e Wurden die urspr nglichen Vorstellungen gem ss der Vorstudie realisiert Entspricht das System den aktuellen Spezifikationen und die Dokumentation dem System zu welchem Grad wurden die Ziele erf llt Klare Auff hrung der Kenngr en Nachkalkulation kl re Pr zisierung des heute ersichtlichen Nutzens und die Gegen berstellung mit der Nutzenberechnung vom Projektbeginn Kosten Nutzen Vergleich Wirtschaftlichkeitsanalyse Sammeln und Begr nden von allen Abweichungen die das nun lauff hige System gegen ber den Zielsetzungen und w nschen aufweist e Welche Anforderungen sind noch nicht erf llt nur zum Teil erf llt oder bed rfen einer nderung Als Basiswerte f r diese Arbeit werden die Resultate der Produktabnahme beigezogen 10 1 2 2 Beurteilung des Abwicklungsprozesses Bei der Beurteilung des Abwicklungsprozesses werden alle beteiligten respektive betroffenen Personen sowie deren Beitr ge und Verhalten w hrend des Projektverlaufes bewertet Fachbeteiligte Die Beurteilung der Fachbeteiligten beinhaltet u a die folgenden Kriterien e In welchem Masse haben sie sich beteiligt In welchem Grad haben sie die Mitverantwortung bei der Entwicklung getragen Wie h ufig kamen ver nderte Anforderungen pro Funktion durchschnittlich vor e Usw Projektgruppe Kriterien der Beurteilung einer Projektgruppe e Wie wurde mit
60. est Frontend Hypotheken Verwaltungssysteme Kreditvergabe T Ausbau best Frontend Verarbeitungssystem amp prozesse Aufbau Kompetenz und R echtf achf hrung Servicecenter Business BetriebsorganisationBTO Treasury Recht RiskManagement Testing Finanz Analyse Total Kostenarten Feb 03 Dez 03 Jan 04 Aug 04 Okt 04 Wirtschaftlichkeit F r die Ermittlung der Skalenertr ge werden aufgrund des gesch tzten Marktpotentials drei Szenarien f r die j hrlich zu bernehmenden Hypotheken zugrunde gelegt Basisszenarium 25 000 Hypo Kontrakte Optimalszenarium 36 700 Hypo Kontrakte Minimalszenarium 12 500 Hypo Kontrakte Werden lediglich die Fixkosten der Hypothekenproduktion ber cksichtigt ergeben sich im Basisszenarium eine St ckkosten Reduktion von 44 22 auf 33 89 1 Jahr bzw 27 47 2 Jahr und 23 10 3 Jahr Durch die Produktionsausweitung Insourcing k nnen auf den rund 82 000 HYPOBANK Kontrakten ber drei Jahre Kosteneinsparungen von Total CHF 3952400 realisiert und die gesch tzten Projektkosten somit bereits amortisiert werden Empfehlung Der vorliegende Business Case dokumentiert die strategische Bedeutung f r die HYPOBANK Drittinstituten eine Kredit Outsourcing L sungen anbieten zu k nnen Das vorgeschlagene Gesch ftsmodell ist unter Ber cksichtigung des gesch tzten Marktpotentials und der dadurch zu erwartenden Skalenertrf ge als wirtschaftlich interessant zu betrachten
61. et Wartung Applikation Intern _ Weiterer relevanter Aufwand LL Applikationen Systeme Total Betriebsaufwand U Jo 00 00 00 00 Total Projektaufwann oo oo Einf hrungskosten Realisierungskosten Betriebskosten Amortisation Projektkosten 4 2 1 Betriebskostenplanung KST Zeitlicher Kostenanfall Die geplanten Kosten werden linear auf 12 Monate aufgeteilt Marco amp Roger 05 07 05 PRMA 28 88 Eidg Dipl Wirtschaftsinformatiker Zeitliche Abgrenzung Es ist zu beachten dass gr ssere Rechnungen ab CHF 100000 welche sich auf die zuk nftige Periode beziehen in der IST Abrechnung zeitlich abgegrenzt werden Planbare Kostenarten Prim rkosen 2 Reinigung 00 2 Fremdes Aushilfepersonal z B Aushilfssekret rin 2 Treuepr mien 020 Lohnausfallsentsch digung Aufwandsminderung Bonus Besoldungen Bons o gt Z o o NEE ESCH E 2 Areitslosenversicheung 2 Familien und Kinderzulagen 00 2 Pensionskassen 2 jPensonskasenBous 444444 Unfallversicherungsbeitr ge 2 nteme Ausbildungen 2 L usbildungebeltr ge x 55220 1 2 2 1 00 2 2
62. etreiber verantwortlich Marco amp Roger 05 07 05 PRMA 88 88
63. ez in einmalige Kosten intern dies sind Aufw nde die durch Eigenleistung von John Lay Electronics anfallen sowie in wiederkehrende Kosten Wartung Unterhalt Verbrauchsmaterialien etc Einmalige Kosten extern Hardware Software Dienstleistungen 494 000 CHF Einmalige Kosten intern Belege anpassen 25 920 CHF Wiederkehrende Kosten Wartung Bedienung 67 000 CHF 6 Nutzen Der Nutzen wird ausgewiesen in monet rem Nutzen einerseits und nichtmonet rem Nutzen andererseits Beim monet ren Nutzen sind die Einsparungen pro Jahr deklariert 6 1 Monet re Nutzen Einsparung bei Ablagevorgang 52500 CHF Einsparung bei Suchvorgang 351 000 CHF Einsparung an R ume Schr nke Papier 46 390 CHF Total 449 890 CHF 6 2 Nichtmonet re Nutzen Keine Sucharbeit mehr gt vom Arbeitsplatz aus in Sekundenschnelle abrufbar Sofortauskunft f r Kundenanfragen auf Wunsch direkte Kopiezustellung via Fax Mail Workflow m glich in weiterer Phase f r Kreditorenbelege Sicherheit kann besser geregelt werden Zugriff auf Dokumente Belege sind l ckenlos abgelegt keine verlorenen Belege Mitarbeiter Motivation moderner Arbeitsplatz Entlastung von Routinearbeiten Es k nnen wiederum alle Belege archiviert werden die heute aus Zeitgr nden nicht mehr abgelegt werden Ersatzteile Reparaturen Lieferscheine Ersatzteile 7 Termine Ziel ist m glichst rasch ein Pilot aufzusetzen um die Risiken zu minimieren Die Projektdauer betr gt nach der
64. g kann z B Aussagen enthalten ber Strategien Technologien Vorgehensweisen Aktivit ten usw Management Organisation kann z B Aussagen enthalten ber Aufbau und Ablauforganisation Personalbedarf und qualifikation Ausbildung EDV Sachmittel usw Wirtschaftlichkeit kann z B Aussagen enthalten ber Investitionen Kosten Ertr ge Rentabilit t Wirtschaftlichkeit nicht quantifizierbarer Nutzen usw Beurteilung kann z B Aussagen enthalten ber Chancen Risiken usw 7 9 4 Arten von Management Summarys Inhalt eines Management Summary einer Machbarkeitsstudie Ausgangslage Ziele und L sungsans tze Wirtschaftlichkeitsanalyse Risikoanalyse Projektorganisation Wird die Projektorganisation im Rahmen der Machbarkeitsstudie festgelegt so k nnen die entsprechenden Personen ihren projektbedingten Einsatz planen und das Projekt kann ohne Verzug mit den richtigen Personen und Gremien starten Projektgesamtplanung Aufgliederung der Teilprojekte Projekte deren Dauer auf l nger als 1 Jahre veranschlagt wird sollen in mehrere berschaubare und zusammengeh rende Teilprojekte gegliedert werden Erweiterter IS Antrag Inhalt eines Management Summary eines Phasenberichtes Einleitung Einf hrung Projekt Auftraggeber Gesch ftsstrategieverfolgung Problemstellung Welche Ziele sollen erreicht werden Ergebnisse der Phase Pr sentation der L sungsvariante Schnittstellenproblemati
65. gung hnlich der Informationspr sentation allerdings wird hier grosser Wert darauf gelegt den Anwesenden die Vorteile der L sung darzulegen Marco amp Roger 05 07 05 PRMA 58 88 Eidg Dipl Wirtschaftsinformatiker 8 4 2 Pr sentationsabwicklung Ablauf Planungsphase Vorbereitungsphase Durchf hrungsphase Nachbearbeitungsphase 8 4 2 1 Planungsphase Ziel der Pr sentation festlegen Inhalt der Pr sentation erarbeiten Reduzieren des Stoffes Einsatzzeitpunkt und Dauer der einzelnen Teammitarbeiter planen Zielpublikum kennen Geeignete Planungsmassnahmen zur Eingrenzung m glicher St rfaktoren Darstellungsform und weise Darstellungsmittel 8 4 2 2 Vorbereitungsphase Den Veranstaltungstermin auf die anstehenden Arbeiten abgleichen Raum und notwendige Infrastruktur reservieren und best tigen lassen Einladung der Teilnehmer entwerfen und rechtzeitig versenden mit Agenda Unterlagen f r Teilnehmer und f r den Pr sentator erstellen Die gesamte Raumeinrichtung am Pr sentationsort berpr fen Bereitstellen aller Hilfsmedien und ausprobieren eventuell Hauptprobe durchf hren 8 4 2 3 Durchf hrungsphase Sobald die Teilnehmer den Raum betreten sollte eine gute Atmosph re geschaffen werden Der Pr sentator sollte vor seinem Vortrag in aller Ruhe einen Kaffee oder Zigi einnehmen Die ersten 5 S tze muss der Pr sentator auswendig kennen Der Vortrag
66. h erstellte System oder Produkt einer Schlusskontrolle zu unterziehen Es k nnen folgende T tigkeiten durchgef hrt werden Systemabnahme Bei der Systemabnahme wird das System auf seine Funktionalit t Best ndigkeit Leistungsf higkeit und Qualit t gepr ft Integrationsabnahme Hier wird das System als Ganzes und die Subsysteme oder Module in Bezug auf deren Schnittstellen und Verbindungen in der bestehenden Systemumgebung gepr ft Auch Abnahmetest Hier wird das Vertrauen des Benutzers oder Auftraggebers in das System berpr ft Systemabnahme Protokoll Es sollte immer mit den Resultaten aus allen Pr fungen ein Systemabnahme Protokoll erstellt werden in dem alle Ergebnisse erf llt oder nicht erf llt festgehalten sind Dieses Protokoll sollten alle Beteiligten unterzeichnen 10 1 2 Projektabschluss Beurteilung Die Projektabschluss Beurteilung beleuchtet die gesamte Projektabwicklung nochmals Die bei der Produktabnahme gemachten Tests und deren Ergebnisse sind f r die Beurteilung sehr wertvoll Eine vollst ndige Sammlung aller Ergebnisse erm glicht das Erstellen eines umfassenden Marco amp Roger 05 07 05 PRMA 68 88 Eidg Dipl Wirtschaftsinformatiker Projektabnahmeberichts Die Projektabschluss Beurteilung erfolgt in zwei Schritten 1 In der Beurteilung des Systems 2 In der Beurteilung des Abwicklungsprozesses 10 1 2 1 Beurteilung des Systems Bei der System oder Produktbeurteilung geht
67. hritt 5 7 1 Vorgehen Schritte der Projektkontrolle 1 Projektplanung SOLL 3 Analyse des Projektstandes Arbeitspakete Dauer Personalaufwand Trmintreue Aufwand Kostentreue Q Erf llung direkte Kosten Trendanalysen 2 IST Erfassung 4 Auswertungen Bericht Personalaufwand rsp direkte Kosten Budget bis Stichtag fertig Restdauer Restaufwand Ist Kosten bis Stichtag Arbeitswert bis Stichtag Abweichung Budget IST Kosten Abw Budget Arbeitswert Leistungsindex Kostenindex Marco amp Roger 05 07 05 PRMA 36 88 Arbeitswert bis heute Eidg Dipl Wirtschaftsinformatiker Stichtag heute IST Kosten bis heute gt Start Budget bis heute Gesch tzter Restaufwand Budget bis fertig Definition AW Arbeitswert Budget gesamt x fertig Arbeitswert Kostenindex IST Kosten bis Stichtag Arbeitswert LI Leistungsindex LI Kosten berschreitung lt 1 Termin berschreitung lt 1 Beispiel Projektplanung SOLL Projektkontrolle per 15 03 a Budget bis Stichtag b Abweichung Budget IST Kosten c Abweichung IST Kosten Arbeitswert d Leistungsindex Kostenindex im obigen Rahmen nachteilhaft Marco amp Roger 05 07 05 Budget bis Stichtag gt 4 Kostenunterschreitung Terminunterschreitung nachteilhaft unentschieden vorteilhaft IE gt 1 Termin 1 8 31 8 4 W 30 Tage Umfang 40 grosse S
68. ht mit K rtchen nicht beide H nde verwenden zum Halten Armbewegungen nicht nur die Unterarme bewegen sondern der ganze Arm wirkt sonst verklemmt nach vorne gehen und nicht zur ck gerade und entspannte K rperhaltung Reh am Waldrand beim Grasen entspannt aber immer auf draht 9 9 Inhalt vermitteln Verkaufen eine Pr sentation ist ein Verkaufen eine Show Verkaufen mit Ziel Zustimmung zu erhalten und bereinstimmung zu erziehlen Argumentieren Argument mit Beweis Nutzen f r Zuh rer Kontrollfrage nicht vorlesen Argumentationsfolge Anschauen Aufschauen Aussprechen die bei Spickzettel Sprache prechtechnik kurze S tze Atemtechnik T tigkeitsw rter Pausentechnik direkte Sprache Sprechtempo aktive Form Lautst rke positive anschauliche Bildersprache Aussprache Redefiguren Lautbildung Stimmlage Sicherheit f rs Pr sentieren Lampenfieber Die ersten 5 S tze muss der Pr sentator auswendig kennen eine bekannte Person w hrend der Pr sentation anschauen kurze Pausen einnehmen Agenda f hren und nachf hren Vor der Pr sentation k rperliche bungen durchf hren Sprungbrett und auf F ssen wippen Lockerungs bungen durchf hren Apfel essen oder Weiswein trinken ist gut f r die Stimme Sich den WorstCase vorstellen und diesen zu Hause Vorbereiten Die m glichen Gr nde f r eine Blockade notieren und sich dies Bewusst machen
69. ie Risikobeschreibung muss so ausf hrlich sein dass sich erstens alle Workshop Teilnehmenden mit der Formulierung einverstanden erkl ren und zweitens nicht involvierte Personen ohne weitere Erkl rungen verstehen k nnen um welches Risiko inkl Umfeld History es sich handelt Risikoauswirkung Beschreibt die Auswirkungen bei eingetretenem Risiko Risiko Gruppe In der Spalte Risiko Gruppe Cluster muss ein Oberbegriff f r eine Risiko Gruppe definiert werden Ziel dieser Massnahme ist es dass Cluster verwandte bzw von einander abh ngige Risiken zusammen bearbeitet werden k nnen z B von Arbeitsgruppen Eintretenswahrschein P bezeichnet die Eintretenswahrscheinlichkeit des Ereignisses lichkeit Der Wert von P muss gr sser als 0 bei Eingabe 0 w re das Ereignis unm glich und kleiner als 100 bei Eingabe 1 w re das Ereignis sicher bzw schon eingetreten sein Damit nicht mit einer Pseudogenauigkeit gerechnet wird wird vorgeschlagen dass die kleinste Einheit F nferschritte sind kleinstes P 5 gr sstes P 95 Schadensausmass Das Risikoausmass wird bei diesem Verfahren als relativer nicht finanzieller Wert angegeben Der Wert muss aus mathematischen Gr nden gr sser als 0 sein kann jedoch 100 erreichen Damit nicht mit einer Pseudogenauigkeit gerechnet wird wird vorgeschlagen dass die kleinste Einheit F nferschritte sind kleinster Wert 5 gr sster Wert 100 Vermeidungsmassna Vermeidungsmassnahmen si
70. ie notwendige Starthilfe und Unterst tzung F rdern sie ihre Projektmitarbeiter durch konstruktive Kritik unter vier Augen die vor allem dem Vermeiden von zuk nftigen Fehlern dient F rdern sie ihre Mitarbeiter aktiv mit Aus und Weiterbildungsmassnahmen Loben sie ihre Mitarbeiter und sprechen Anerkennung aus Erm glichen sie dem Mitarbeiter ein selbst ndiges Arbeiten Stellen sie eine zeitgem sse Besoldung sicher und entsch digen sie Spezialefforts Umfassende und rasche Informationsfl sse f rdern und selbst leben R umen sie den Mitarbeitern Mitentscheidungsrechte ein Gehen sie auf die Vorschl ge der Projektmitarbeiter ein Contingency Planning Risikoverminderungsmassnahme gt Verminderungsmassnahmen sind Massnahmen welche eingeleitet werden um bei eingetretenem Ereignis die Folgen zu vermindern Warum Contingency Planning In zunehmendem Mass sind die Unternehmen von der Verf gbarkeit und der Funktionsf higkeit der eingesetzten Informationstechnologie abh ngig Die Vorbereitung auf einen Eventualfall erh lt somit immer gr ssere Bedeutung Der Sinn besteht darin die Verf gbarkeit der Dienstleistungen zu sch tzen Dazu geh rt das Verbessern der Zuverl ssigkeit der Dienstleistungen selber das Durchf hren von vorbeugenden Massnahmen um die Wahrscheinlichkeit von Ausf llen zu reduzieren das Vorkehren von Gegenmassnahmen um die Dienstleistungen im Katastrophenfall in der erforderlichen Zeit wiederherstellen zu
71. iehung zueinander was beinahe wieder einen Erfolgsfaktor ergibt Es ist namlich wesentlich einfacher einen einzelnen Faktor zu verfolgen als gleichzeitig mehrere Faktoren im Auge zu behalten die f nf Erfolgsfaktoren 1 PM Funktionen siehe 2 2 1 Seite 9 Projektteam Umwelt siehe 2 2 2 Seite 10 Projektabwicklungsinstrumente siehe 2 2 3 Seite 10 Personen siehe 2 2 4 Seite 11 Organisation PM Funktionen siehe 2 2 5 Seite 11 2 2 1 Projektmanagement Funktionen Je komplexer und umfangreicher ein Projekt ist um so mehr spielt dieser Managementfaktor eine Rolle Um ein aktives und gutes Projektmanagement verfolgen zu k nnen sollten folgende managementbezogene Erfolgsfaktoren ber cksichtigt werden Management Attention Das Management muss der Projektstartphase die gr sste Beachtung schenken Marco amp Roger 05 07 05 PRMA 9 88 Eidg Dipl Wirtschaftsinformatiker Dokumentationen und Die saubere Aufbereitung der Entscheidungsunterlagen der Berichtswesen Dokumentationen sowie der Ergebnisse ist ebenso wichtig wie ein geordnetes Berichtswesen Planungsumfang Der Planungsumfang muss der Aufgabenstellung und der Projektgr sse angepasst Tailoring sein Detaillierungsgrad Der Detaillierungsgrad der Planung muss aussreichend sein Es sollte gen gend Spielraum f r die Bearbeitung von situativ anfallenden Problemen eingeplant werden Kontrollen In jedem Projekt m ssen zweckm ssige Kontrollen durch die
72. igen Entscheidungsschwierigkeiten W nsche sammeln bei Anforderungen nicht konsolidieren und Auswirkungen koordiniertes W nschen kommunizieren Schl sselpersonen sind nicht involviert keine festen Ansprechpartner Know how vorhanden wenig Darstellung der Auswirkungen interne Kommunikation ber ohne Anforderungen kein Marco amp Roger 05 07 05 PRMA 23 88 Sich ver ndernde Anforderungen wirken sich schlecht auf den strukturierte Projektablauf aus gef hrdet die erwarteten Eidg Dipl Wirtschaftsinformatiker Ablauf bei nderungen ist nicht definiert es existiert kein nderungsformular und oder keine nderungsgeschichte Konsequenzen auf nderungsw nsche werden nicht durchdacht funktional wie auch bez glich Aufwand Terminen Kosten und nicht mit dem Kunden besprochen Kunde hat keine Zeit Kunde hat Risiko klar an die verursachenden Stellen Projektmanagement Kunde l sst delegieren Konsequenzen sich nicht einbinden Leistungen aufzeigen Klare Spezifikationen bzw Grundlagen schaffen kommunizieren von schlechter Qualit t Kunde vertr stet Ger chte schlechte Zahlungsmoral laufende Betreibungen Vertreter des Kunden besitzen keine Kompetenzen Kunde kommt seinen Verpflichtungen nicht nach dauernd Prinzipielle Aufgabenteilung zwischen Auftragnehmer und Kunde sowie die V erantwortungen werden Schwierigkeiten bereiten unrealistische Erwartungen bez glich Reaktion
73. iko gesprochen dass sich in drei Teilrisiken zerlegen l sst 1 Entwicklungs Risiken 2 Management Risiken 3 Soziale Risiken Einf hrungsrisiko Entwicklungs risiken Applikationsrisiko 4 2 Materialzulieferungs Risiko Projektleitungsrisiko Management Projektrisiken risiken Planungsrisiko 4 3 Informations und Kommunikationsrisiko Motivationsrisiko Soziale Risiken Kap 4 4 Politisches Risiko Mitarbeiterrisiko Abb Risiken eines Projekttes Die Folgen von eintreffenden Teilrisiken k nnen sein Der Auftraggeber oder Kunde ist nicht zufrieden Es werden zus tzliche Ressourcen ben tigt e Die Wirtschaftlichkeit erweist sich als niedriger als erwartet Das Produkt weist M ngel auf Termine k nnen nicht eingehalten werden e Die Motivation aller Beteiligten sinkt Marco amp Roger 05 07 05 PRMA 14 88 Eidg Wirtschaftsinformatiker Die Projektrisiken weisen einen polarisierenden Wert zu den Erfolgsfaktoren eines Projektes hin Das bedeutet wenn ein Projektleiter von den m glichen Risiken Kenntnis hat kann er die Aufmerksamkeit auf die Einhaltung des entsprechenden Erfolgfaktors richten siehe auch Kap 2 2 Erfolgsfaktoren eines Projekts 3 2 Entwicklungsrisiken Entwicklungsrisiken k nnen sich aus folgenden Situationen ergeben Applikations Entwicklungsrisik
74. inzusetzen In einem solchen Fall kann die Projektstruktur sehr hnlich zu der hier vorgestellten aussehen Das K stchen Entwickler wird jedoch feiner strukturiert indem mehrere Teil Projektleiter oder Gruppenleiter die Verantwortung f r Teilprojekte bernehmen Normalerweise ist es nicht sinnvoll die Rollen Konfigurationsmanager oder Qualit tsmanager spezifisch f r einzelne Teilprojekte zu besetzen es reicht diese Rollen einmal f r das Gesamtprojekt zu besetzen F r jedes Projekt m ssen mindestens die folgenden Stellen vorhanden bzw Rollen besetzt sein Lenkungsausschuss oder auch Projektsteuerung Dieser Ausschuss legt strategische Ziele fest greift bei ernsthaften Problemen steuernd ein und berwacht den globalen Projektverlauf e Projektleiter Der Projektleiter muss daf r sorgen dass das Projekt die Projektziele fachlich finanziell terminlich qualitativ erreicht Er plant berwacht und steuert den Projektverlauf Alle Mitarbeiter des Projektes berichten bei Teilprojekten teils indirekt an ihn Der Projektleiter berichtet an den Lenkungsausschuss und an den Ansprechpartner des Auftraggebers e Qualit tsmanager Der Qualit tsmanager ist f r das Einrichten und die berwachung des konstruktiven Qualit tsmanagements im Projekt zust ndig Weiterhin hat er die analytische Qualit tssicherung Test zu planen zu steuern und zu berwachen Er berichtet an den Projektleiter Ein gegebenenfalls vorhandenes Test Team
75. k Kosten Nutzen Bewertungsresultate absolut relativ Gibt es Abweichungen gegen ber dem Geplanten Projektstand Marco amp Roger 05 07 05 PRMA 51 88 Eidg Dipl Wirtschaftsinformatiker Arbeitsfortschritt Produktfortschritt Kosten Aufwand Termine Meilensteine Besondere Projektrisiken Weiteres Vorgehen z B n chster Phasentermin usw Antrag auf Entscheid Phasensgenehmigung Beispiele von Managment Summarys siehe 12 2 Seite 78 12 4 Seite 83 Marco amp Roger 05 07 05 PRMA 52 88 Eidg Dipl Wirtschaftsinformatiker 7 10 Dokumentenergebnisse aus den Projektphasen Business Case DL Produkte Markt etc Projektauftrag Projektorganisation Kosten etc Projektplan Aufgabe Zeit Ressourcen Fach Konzept Marketting Konzept ORG Konzept IT Konzept Realisierungsstrategie Pflichtenheft IT Designspezifikation evtl Evaluation Anbieter Einf hrungs Konzept Benutzer Doku Schulungs Doku Programmierung Testen Programm Doku Migration Daten bernahme IT Integration inkl Netzwerke Infrastruktur Ausbildungsplan RZ IC IDV Doku Systemtest Pilotvorbereitung Einf hrung Begleitung Pilot Nachbearbeitung Pilot Vorbereitung Einf hrung Infrastruktur Ausbreitung Schulung Einf hrung Support Aufbau Hotline etc Abb Phasenmodell und Arbeitspakete Marco amp Roger 05 07 05 PRMA 53 88 Eidg Dipl Wi
76. lage f r die Fehlersuche bilden sowie nderungen und Erweiterungen des Systems vereinfachen 7 8 2 Betriebsdokumentation Die Betriebsdokumente basieren auf den Entwurfs und Entwicklungsdokumenten die aus diversen Phasen des Projekts stammen und von denen der gr sste Teil in der Phase Detailkonzept erarbeitet wurde Folgende Dokumente k nnen als Betriebsdokumente bezeichnet werden e RZ Handbuch Katastrophenszenario e Eskalationsplan e Pikettlisten e Installattionshandbuch Konfigurationshandbuch 7 8 3 Benutzerdokumentation Die Benutzerdokumente sollen sicherstellen dass das Softwareprodukt respektive das System ohne Zuhilfenahme weiterer Informationen benutzt werden kann Sie werden meistens in der Phase Realisierung anl sslich der Rahmenorganisation verfasst und enthalten mehrere f r verschiedene Zwecke bestimmte Papiere Dies sind unter anderen e Benutzerhandbuch e Online Help Online Dokumentation e _Systembenutzer Dokumentation Fehlerhandbuch Hot Line Ablauf Bestimmungen Anforderungsrichtlinien f r HW und SW Eine Benutzeranforderung muss folgenden Anforderungen gen gen Knapp und pr zise aber nicht g nzlich ohne Redundanz selektiven Lesen geeignet Vom Allgemeinen zum Detail f hrend Einwandfreier Schreibstil 7 9 Management Summary 7 9 1 Zweck Ein Summary ist eine kurze Inhaltsangabe ein Auszug oder eine Zus
77. laufen Marco amp Roger 05 07 05 PRMA 8 88 Eidg Dipl Wirtschaftsinformatiker 2 Erfolgsfaktoren eines Projektes 2 1 Projekterfolg Ein Projekterfolg liegt dann vor wenn die vom Arbeitgeber gew nschten Systemresultate mit den vorgeschlagenen Mitteln innerhalb der vorgegebenen Zeit in der geforderten Qualit t erreicht werden Wenn man von Projekterfolg spricht sind dabei immer die Projektabwicklung also wie wir das Projekt abwickeln und das zu bauende System gemeint Aufbauorganisation Aufbauorganisation 2 Projekterfolg Projektabwicklung Projekterfolg System Leistung Qualit t Zeit D Zufriedenheit D 4 Wirtschaftlichkeit Ablauforganisation Ablauforganisation Aufgabe Aufgabentr ger Sachmittel Information Aufgabe Aufgabentr ger Sachm Information Abwicklungsziele J Systemziele Abb Erfolgsermittlungskriterien in Anlehnung an Keplinger 2 2 Erfolgsfaktoren eines Projekts Unter Erfolgsfaktoren in einem Projekt versteht man die Voraussetzungen die wesentlich zur Erreichung der w nschbaren Zust nde gem ss Erfolgsermittlungskriterien beitragen Gem ss der Erhebung von Keplinger der die Erfolgsmerkmale von erfolgreichen Projekten untersucht hat k nnen die Erfolgsfaktoren in f nf Gruppen zusammengefasst werden Diese Gruppen stehen in Bez
78. lecht Es ist besser wenn der Experte konsumieren kann und sogar den Referent unterbrechen muss um eine weitere Frage stellen zu k nnen Marco amp Roger 05 07 05 PRMA 64 88 Eidg Dipl Wirtschaftsinformatiker 9 Einf hrung 9 1 bersicht Einf hrungskonzept Ausbildungskonzept WW Informatiksystem a ar Migrationsverfahren Sachmittelbedarf em 7 Systemintegrationsplans Betriebshandbuch Organisationshandbuch Rahmenorganisation abnahme sehlussbericht 9 2 Rahmenorganisation Einf hrungskonzept erstellen Organisationsstruktur anpassen Aktualisierung von Stellenbeschreibungen Personelle Voraussetzungen schaffen Personalbeschaffungs bzw Personalfreistellungsmassnahmen durchf hren Erforderliche neue Sachmittel Mobiliar Ger te etc beschaffen und installieren R umliche Anpassungen planen und vornehmen Benutzerhandb cher Arbeitsanweisungen erstellen Ausbildungsunterlagen Informationsmaterial konzipieren und erstellen 9 3 Phasenabh ngige Aktivit ten Grob Detailkonzept Konzeption der Daten bernahme Erstellung Sachmittelkonzept Einf hrungskonzeption Schulungskonzeption Schnittstellenkonzeption Realisierung Entwicklung der Migrationsprogramme Stammdaten Bewegungsdaten neue Daten Entwicklung der Schnittstellen Sachmittelbeschaffung Installation detaillierte Einf hrungsplanung Ins
79. likte behoben werden indem er die entsprechenden Teilnehmer unter Umst nden direkt anspricht am Ende der Sitzung das weiter Vorgehen T tigkeiten Termine usw festlegt 8 2 Projektsitzungen siehe PRMA Seite 141 Die Betroffenen fachkompetenten Personen einladen Traktanden mit ausf hrlicher Pendenzenliste fr hzeitig bekannt geben Sitzung P nktlich beginnen und z gig durchf hren F r ein entspanntes Diskussionsklima sorgen Aufgaben und Beschl sse an der Sitzung von den Betroffenen selbst diktieren lassen Protokoll noch am gleichen Tag schreiben und verteilen lassen Projektstartsitzung Kick Off Kontrollsitzungen Problem l sungsbezogene Sitzungen Periodische Meetings Projektabschlusssitzung Details zu den Sitzungsarten siehe PRMA Seite 141 ff Marco amp Roger 05 07 05 PRMA 57 88 Eidg Dipl Wirtschaftsinformatiker 8 3 Projektreview siehe ZF_QUAL 8 3 1 Zweck Stansortbestimmung aus einem ganz bestimmten Blickwinkel definieren durch das jeweilige Ziel 8 3 2 Einsatz Bei jedem Phasenende oder bei Auftraggeberwechsel PL Wechsel etc 8 3 3 Ablauf Planung Wer kontrolliert Wann wird kontrolliert Tag Zeit Wo wird diese Kontrolle durchgef hrt Ort Was wird kontrolliert Welches Ziel wird mit dieser Kontrolle verfolgt Vorbereitung Gutachter Formulierung der Fragen und Erstellen der Checklisten PL Team Informationen zu den bisherigen Ereignissen auf de
80. ll CAT Dem Dprittinstitut wird eine angepasste Version des bestehenden und im Einsatz stehenden Kreditvergabe Tools zur Verf gung gestellt und die produzierten Hypotheken werden von der HYPOBANK auf Einzelbasis unter Verrechnung eines Total Cost Satzes bernommen Dem Drittinstitut wird damit eine vollst ndige Auslagerung des Verwaltungsprozesses erm glicht Die HYPOBANK bernimmt in dessen Namen zus tzlich den Zahlungsverkehr und die Kundenkorrespondenz White Labelling Ansatz F r das Drittinstitut entfallen somit Bestandesf hrung und Kontoabschl sse und die Systemanforderungen reduzieren sich auf ein rudiment res Kontrollsystem Projektkosten Wie die folgende Abbildung zeigt werden die gesamten Projektkosten auf rund CHF 4 Mio gesch tzt wobei rund CHF 1 5 Mio auf die Definitionsphase und rund CHF 2 5 auf die Realisierungsphase fallen Maximal CHF 2 5 Mio sind Prim rkosten die v a durch Definition und Entwicklung des Kreditvergabetools verursacht werden 2 externe Marco amp Roger 05 07 05 PRMA 85 88 Eidg Dipl Wirtschaftsinformatiker Phase 1 Definition Phase 2 Reclisierung Prim rkosten Sekund rkosten Les 1600000 880236 Prim rkosten Sekund rkosten mau 900000 572292 Phase 2 Kreditvergabe T ool Ausbau b
81. ll man grunds tzlich die geforderten Funktionalit t und Sytemqualit t sichern und festigen Es ist nicht das Ziel der Einf hrungs Nachbearbeitung neue Anforderungen oder Benutzerw nsche umzusetzen 10 1 6 Projektteam Aufl sung Die wohl wichtigste Frage Wohin mit den Projektmitarbeitern Dies ist ein zentrales Problem mit dem sich der Projektleiter und Projekttr gerinstanz schon Monate vor dem Projektabschluss auseinandersetzen sollten Aus betriebswirtschaftlicher Sicht ist ein sukzessiver Abbau des Projektteams und eine Nahtlose Integration in ein neues Projekt w re am vorteilhaftesten 10 1 7 Projektaufl sung Checkliste Ein Projekt kann erst dann aufgel st werden wenn alle f r den Systemunterhalt erforderlichen Grundlagen erstellt wurden bzw wen alle in den vorherigen Punkten aufgef hrten Arbeiten erledigt sind Es ist wichtig dass jeder einzelne Arbeitsschritt vom Projektleiter in Zusammenarbeit respektive in konkreter Abstimmung mit den Mitarbeitern und den Auftraggeber vorgenommen wird Marco amp Roger 05 07 05 PRMA 71 88 Eidg Dipl Wirtschaftsinformatiker Folgende Arbeiten m ssen ausgef hrt werden Projekterfahrungen Die strukturierte Sammlung aller Erfahrungswerte aus dem Projektverlauf wird ausgewertet Die Erfahrungen m ssen in eine vorhandene Erfahrungs DB abgespeichert werden Fehler oder Fehlintepretationen sollten ebenfalls abgespeichert werden Siehe Kap 10 1 4 Systemabnahm
82. m ein Projekt erfolgreich abwickeln zu k nnen Die Gew hr f r einen Erfolg k nne nur ein qualifiziertes Team respektive m ndige Beteiligte bieten Personen die von der Projektproblematik sowie von den Projektmethoden eine Ahnung haben Personenbezogene Erfolgsfaktoren sind Fachkenntnisse des PL s Der Projektleiter muss ber gen gend Methoden Fach und Betriebskenntnisse verf gen um diese mit seinen guten F hrungsqualit ten umsetzen zu K nnen Kompetentes Fachteam In einem Projektteam muss die notwendige Fachkompetenz Erfahrung und Teamf higkeit vorhanden sein Motivationsf higkeit des PL s Der Projektleiter sowie der Projektauftraggeber m ssen die Teammitarbeiter und sich selbst immer wieder von neuem motivieren k nnen Dabei m ssen sie f hig sein das Teamverhalten so zu beeinflussen dass deren Mitglieder ber eine l ngere Zeit eine hohe Leistung bringen k nnen Teamf hrung Der Projektleiter muss f hig sein das Team situativ auf Aufgabe und Person bezogen zu f hren Konfliktmanagement Der Projektleiter muss f hig sein mit Konflikten umzugehen 2 2 5 Organisation siehe Unterlagenordner siehe PRMA Aufgrund der Einmaligkeit eines jeden Projektes sollte die Organisation unb rokratisch gestaltet werden Sie muss jedoch Stabilit t aufweisen und nur der Projektleiter darf gezielte personelle Ver nderungen vornehmen Die im Projekt verwendete Projektstruktur muss s
83. ment Handbuches Erstellen von Stellenbeschreibungen Erweitern und Anpassen des Systementwicklungs Handbuches Erweitern und Anpassen des Qualit tssicherungs Handbuches Erweitern und Anpassen des Katastrophen Handbuches produktionsbezogen Risikominimierung des Projektablaufes Projektplanung in Frage stellen Checklisten einsetzen Unabh ngige und erfahrene Personen berpr fen das Projekt Erfahrungen von fr her entwickelten Projekten einfliessen lassen Offenes Ohr f r Warnungen von beteiligten Mitarbeitern haben Durchf hren von Audits und Reviews Risikominimierung des Projektfortschrittes z B zeitliche Restriktionen Anordnung von berzeit Ferienstopp der Projektmitarbeiter verh ngen Dotationserh hung von externen und internen Projektressourcen z B vom 60 auf 100 Pensum Marco amp Roger 05 07 05 PRMA 16 88 Eidg Dipl Wirtschaftsinformatiker 3 6 Motivation Projektmitarbeiter Zeigen sie jedem Projekt Mitarbeiter genau seine Aufgaben Kompetenzen Verantwortung und Funktionen im Projekt Machen sie jedem Mitarbeiter seine Stellung in der Gesamtorganisation und die Bedeutung seiner Arbeit f rs Projekt klar Erkl ren sie jedem Mitarbeiter nicht nur das WAS und WIE sondern auch das WARUM seiner Aufgaben Geben sie jedem Mitarbeiter deutlich zu erkennen was von ihm erwartet wird Geben sie jedem Mitarbeiter d
84. min ergebnisorientierte Berichtstermine zeitorientierte Berichtstermine Berichtsempf nger Entscheidungsgremien Beratungsgremien zuk nftige Anwender Projektteam Projektleiter Teammitglieder andere Projektteams div Interessenvertretungen Berichtsform formlose m ndliche Berichte schriftliche Berichte Pr sentationen Berichtsinhalt Der Berichtsinhalt h ngt sehr stark von den Berichtsempf ngern ab Neben der Frage was berhaupt der Informationsbedarf der Empf nger ist muss beachtet werden wieviel dem Empf nger quantitativ zugemutet werden kann bzw was er erwartet wie qualitativ die Inhalte aufbereitet werden m ssen und welche Argumentationen die Zielgruppen besonders anspricht Ein hierarchischer Aufbau der Berichte erleichtert das Lesen und hilft die bersicht zu wahren Marco amp Roger 05 07 05 PRMA 54 88 Eidg Dipl Wirtschaftsinformatiker 7 11 4 Beispiele von Berichten Bezeichnung Inhalt des Berichts Empf nger Periode Beschreibung der Relevanz Statusbericht wo steht das Projekt Steuerungs 1xMonat Dient dem Abweichung ausschuss Begr ndung f r die PSA Abweichung Steuerungsausschuss zur Kontrolle des Projekts Der PL verf gt ber alle n tigen Informationen zur Erstellung des Berichts Die PSA ist informiert ber den Fortschritt die Probleme und Risiken des Projekts Der Bericht wird periodisch und in Abh ngigkeit zu den Phasen erstellt Pl
85. n ee 16 3 5 Risik Entsch rfung u 16 3 6 Motivation Projektmitarbeiter u 17 3 7 Ablauf einer Risikoanalyse Graphisch 19 3 8 Zeitpunkt der Risikoanalyse 19 3 93 RISIKodHaly S 20 3 9 1 Risikenkatalog Bereiche 23 4 Projektmanagement 27 4 1 Steuerungsmassnahmen bei Projektverzung 27 4 2 Projektkosten und Budget 28 4 2 1 Betriebskostenplanung 28 4 3 Zieldefinition Zielformulierung 30 4 4 Evaluatio EE 30 4 5 Requirement Traceability Liste transp 31 4 6 Information sb schaffu inguu u uu aan 32 4 6 1 Sinn und Zweck eneskonzentse a 32 4 6 2 Fragestellungen zur Informationsbeschaffung 32 4 6 3 lntormatonsbeschattungskonzent 32 2 65 2lel des EE 32 4 6 5 Vorgehen einer Beschaftung 33 5 Projekt Controlling berwachung 34 5 1 Aufgaben des Projektcontrollings
86. n neusten Stand bringen Moderator Informieren aller Verantwortlichen ber das geplante Vorgehen Durchf hrung Pr sentation des Projektstatus Fragen betreffend Pr sentation Projektstatus Zusatzfragen aufgrund Checklisten Risikobeurteilung Analyse Analyse der Resultate aus Review Sitzung Aktionsplanung durchf hren nderung der Priorit ten Termine Budget Aufgabenverteilung Umsetzung 8 4 Pr sentation siehe PRMA Seite 394 Methode Technik Seite 351 8 4 1 Zweck Die Pr sentation ist eine spezielle Form der Kommunikation die es erm glicht Wort Schrift Bild sowie die ganze Vielfalt menschlicher Ausdrucksf higkeit einzusetzen um den Teilnehmern die eigenen Ideen nahezu bringen oder andere beabsichtigte Wirkungen zu erzielen Pr sentation zur Entscheidungsfindung Sind einer Verkaufssitzung vergleichbar Der Pr sentator stellt den Entscheidungstr gern ein konzeptionell erarbeitetes Ergebnis eine Variante oder eine L sung vor um gr nes Licht f r die Fortf hrung des Projektes zu erhalten Pr sentation zur reinen Information Diese Pr sentationen dienen lediglich dazu den Teilnehmern verabschiedete L sungen vorzustellen sowie diese zu erl utern und zu begr nden Pr sentation zur Meinungsbildung Workshop Die Teilnehmer werden mit L sungsans tzen und offenen Fragen konfrontiert W hrend offen gestalteter Diskussionen wird eine gemeinsame Meinung gebildet Pr sentation zur berzeu
87. n verglichen mit den Erwartungen aus der Benutzersicht aus Sicht des Rechenzentrums oder der Systembetreuer Aussagen ber tats chliche Kosten und Nutzen des Systems Produktes im Vergleich zu den geplanten Kosten und Nutzen Welche Arbeiten m ssen noch erledigt werden damit das Projekt als abgeschlossen betrachtet werden kann wird vor allem f r die Nachbearbeitung ben tigt siehe Kap 10 1 5 Einf hrungs Nachbearbeitung 10 1 4 Erfahrungssicherung F r den Projektleiter Dieser Punkt gilt f r den pers nlichen Nutzen des Projektleiters als der wichtigste Je mehr Erfahrungen er festhalten kann desto bessere Leistungen genauere Sch tzungen konkretere Massnahmen etc kann er in den n chsten Projekten einbringen Dabei m ssen auch alle Fehlentscheide allgemeine Fehler oder Fehlinterpretationenen festgehalten werden 1S Architektur oder Projektportfolio Verwaltung Die gesammelten Daten sind aber auch u erst wichtig f r die Aufwandsch tzverfahren und Kennzahlsysteme die in der IS Architektur oder IS Projektportfolio Verwaltung ben tigt werden f r die Verwendung in sp teren Projekten 10 1 5 Einf hrungs Nachbearbeitung Die Einf hrungs Nachbearbeitung muss 3 6 Monate nach der Systemeinf hrung abgeschlossen sein M ngelbehebung Die bei den Abnahmetests und in den ersten Betriebsmonaten festgestellten M ngel sollten w hrend der Nachbearbeitungsphase berarbeitet werden Mit einer Nachbearbeitung wi
88. nd Massnahmen welche ergriffen werden damit das Ereignis vermieden werden kann hme VeiM gt Reduktion Eintretenswahrscheinlichkeit VM Status Der Status der Massnahme wird in drei Kategorien eingeteilt 1 leicht einzuf hrende Massnahme enspricht gr n 2 aufwendig einzuf hrende Massnahme entspricht gelb 3 sehr schwierig einzuf hrende Massnahme entspricht rot Verminderungsmass Verminderungsmassnahmen sind Massnahmen welche eingeleitet werden um bei eingetretenem Ereignis die Folgen zu vermindern nahme VinM gt Reduktion Schadenausmass VinM Status Der Status der Massnahme wird in drei Kategorien eingeteilt 1 gr n leicht einzuf hrende Massnahme 2 gelb aufwendig einzuf hrende Massnahme 3 rot sehr schwierig einzuf hrende Massnahme Durchschnitt der Dieser Wert ist entweder das gewichtete Mittel zwischen Vermeidungs und Verminderungs massnahme oder aber der Status der Massnahmen Vorsorgemassnahme Marco amp Roger 05 07 05 PRMA 21 88 boch 0 0 N 5 d mittel niedrig Marco amp Roger 05 07 05 Eidg Dipl Wirtschaftsinformatiker Risikoverteilung im Projekt Ki niedrig mittel hoch Eintretenswahrscheinlichkeit PRMA 22 88 O Fremdsysteme SvAuftrag O E2E Prozess OBFS OCR SvLear SvKuzu O OLU 4 0 open items Ressouren
89. ng Forming Norming Performing Kick off mit allen Beteiligten Gemeinsame Abstimmung im Team zum Erfolg Motivation aller Beteiligten Spielregeln definieren Soft facts ber cksitigen Projektantrag kritisch w rdigen Ziele weiteres Vorgehen und Termine gemeinsam definieren Kontaktliste erstellen Abwesenheitsliste erstellen Bussiness Case erstellen Situationsanalyse L sungsvarianten Kunde Markt Produkte und Dienstleistungen e Kommunikationskonzept Gesch ftsprozesse ORG und IT Aspekte Ausbreitung Projektstruktur festlegen auch Projektmanagement Support einbinden Aufwand sch tzen Zeit und Kostenplanung erstellen Projektorganisation festlegen Standards auf Projekt adaptieren Projektinformationswesen festlegen etc Projektauftrag erstellen e Unterschrift Auftraggeber und Projektleiter f r Projekt einleiten Marco amp Roger 05 07 05 PRMA 73 88 11 3 bersicht Institutionelles PM Organisationsform der Projektgruppe Reine Projektorganisation 2 2 2 5 105 Stab Linien Projektorganisation 2 2 3 85 106 Matrix Projektorganisation 2 2 4 5 108 Gemischte Organisationen 2 2 6 S 111 Instanzen und Stellen Auftraggeber 2 3 1 5 117 Projektleiter 2 3 3 5 120 Projektgruppe 2 3 4 15 124 Fachbeteiligte 2 3 5 15 128 Gremien 2 3 6 S 130 Eidg Dipl Wirtschaftsinformatiker Institutionelles PM Projektinformationsy stem
90. ng stehende Ressourcen Mitarbeiter mit entsprechendem Know how Hard und Software R ume etc Priorit ts Tabellenver Partner Berechtigungs Offert Vertrags level 1 waltung systeme system system system Priorit ts level 2 System XY System XY System XY System XY System XY 2 System System System System System 6 4 4 3 Aufstellung des applikatorischen Migrationsplans Mit gr sster Wahrscheinlichkeit wird die unternehmerische Reihenfolge nicht mit der betrieblichen Reihenfolge bereinstimmen Projekt 2 Personalkosten Betriebsmiitelkosten Kosten extern Beratung Wartung Personalkosten Betriebsmiitelkosten Kosten extern Beratung Summe Personalkosten Betriebsmiitelkosten Kosten extern Beratung Marco amp Roger 05 07 05 PRMA 43 88 Eidg Dipl Wirtschaftsinformatiker 7 Dokumentation eines Projektes PRMA Buch 153ff 7 1 Sinn und Zweck des Dokumentationssystems Als Grundlage f r die gezielte Durchf hrung eines Projekts gilt f r alle betroffenen Stellen das Dokumentieren und Zusammenstellen von Arbeitsergebnissen Dies ist notwendig e das neu zu entwickelnde System bis zur bergabe an den Benutzer nderungen unterliegt und auch nach der Einf hrung st ndig neuen Gegebenheiten anzupassen ist Maintenance e eine berpr fbarkeit durch externe Stellen zu jedem Zeitpunkt sicherzustellen die Vermeidung von Missverst ndnissen eine konkrete Diskus
91. nisationen usw Informationsbeschaffung zur Kl rung der Soll Situation z B Organisations Funktionsbed rfnisse intern extern Erhebung von Kundenw nschen Verbesserungsvorschlage von Mitarbeitern Informationsbeschaffung dient Der Zieldefinition Der Anforderungsdefinition Als Entscheidungsgrundlage 4 6 4 Ziel des Konzepts Die Informationsbeschaffung ber die Ist Situation Zufriedenheit der Benutzer mit einer Supportstelle in einem Betrieb Benutzerfreundlichkeit einer firmenweit eingesetzten Applikation Umfrage ber die Zufriedenheit von Mitarbeitern Wirtschaftlichkeitsvergleiche Benchmarking versch Firmenzweige Die Informationsbeschaffung zur Anforderungs oder Zieldefinition Priorisierung von Funktionalit ten zuk nftig eingesetzter IT Tools Erhebung von Kundenw nschen bez glich neuer Dienstleistungen Review von Pflichtenheften und Anforderungskatalogen Verbesserungsvorschl ge von Mitarbeitern Die Informationsbeschaffung als Entscheidungsgrundlage Einf hrung einer Workflow L sung als firmeninternes Arbeitsinstrument Aufhebung von Tele Arbeitspl tzen zugunsten Marco amp Roger 05 07 05 PRMA 32 88 Eidg Dipl Wirtschaftsinformatiker 4 6 5 Vorgehen einer Beschaffung Vorbereitung Ergebniss Darstellung Ziele kl ren zweckbezogen messbar Grenzen festlegen Sicherstellung Zielorientiertheit Umfang festlegen Personen suchen finden bedarf ggf ein
92. nish J s 5 j M uU 5 N J Tue 01 01 02 22 04 02 Stage 1 0 66 Mio 23 04 02 Wied 31 07 02 Mon 01 0702 Fri28 02 03 Stage 2 0 05 Mio Fri02 08 02 Thu 31 10 02 Stage 3 9 14 Mio Fri01 11 02 27 02 04 Lieferobjekte der Phasen Phase I II Phase li Phase IV Phase V Business Case einheitlicher SLA Ausbildung Rollout IT Offerte Leasing Modell Pilot ganze Schweiz Benuntzer Detailkonzept Einf hrung 5 Organisation Die Projektorganisation sieht wie folgt aus Es wird sehr grossen Wert darauf gelegt dass m glichst viele Risiken und Anregungen von der Projektorganisation abgedeckt werden k nnen Ebenfalls sollen m glichst alle involvierten Personen in der Projektorganisation vertreten sein 6 Nutzen Es handelt sich hier um ein Infrastruktur Erneuerungs Projekt Einen Break Even wird kaum erreicht Die Einsparungen sind vorallem von nicht finanziellem Nutzen erh hte Mobilit t der Notebookbenuzter Mandantenf higkeit Reduktion der Server Komplexit t Zeitersparnisse beim Aufstarten Die einmaligen Einsparungen aus finanzieller Sicht gesehen belaufen sich auf 1 75 Mio CHF de j hrlich wiederkehrenden Einsparungen auf CHF 1 27 Mio 7 Empfehlung Es wird empfohlen dieses Projekt anzunehmen Aus Sicht der Unternehmensstrategie und dem kommenden Zusammenschluss mit Kontinental Europa ist dies ein erster Schri
93. nnen folgende Gebiete betreffen Ver nderungserlaubnis Vorgehensvorgaben z B empirisch konzeptionell e Vorgaben bez glich der erlaubten Konsequenzen des Projektes z B kein Personalabbau e Termine die zu ber cksichtigen sind e Kosten die einzuhalten sind Personal das im Projekt eingesetzt werden darf Firmenbezogene Restriktionen k nnen folgendermassen aussehen Das Projekt muss mit dem CASE Tool XYL entwickelt werden Das Projekt muss am tt mm jjjj beendet sein Dies ist nur dann eine Restriktion wenn das Datum durch eine abh ngige Gr sse vorgegeben ist 1 2 3 Risikobezogene Restriktionen Da das Risiko eine von aussen gegebene und nicht zu kontrollierende Gr sse darstellt wird es nat rlich auch als Restriktion aufgef hrt In der Umwelt in der Firma und in einer Organisations oder Informatikabteilung k nnen unz hlige Risiken auftreten Der Projektleiter muss speziell auf drei Teilrisiken Acht geben e Managementrisiko e Technisches Risiko e Soziales Risiko 1 2 4 Systembezogene Restriktionen Systembezogene Restriktionen k nnen darin bestehen dass z B vor oder nachgelagerte Stellen Arbeitsprozesse Gr ssen vorgeben die unbedingt eingehalten werden m ssen Vorgegebener Systemstandard Performance z B die Durchlaufsgeschwindigkeit des Gesch ftsvorfalles darf maximal 3 Tage betragen e Prozessabl ufe z B der Gesch ftsvorfall darf h chstens 2 Arbeitsstellen durch
94. o Das Applikations Entwicklungsrisiko tritt ein wenn z B L sungen vergoldet werden wenn durch eine mangelhafte Auslegung der geplanten Leistungen Menge Umfang Funktionen und Qualit t des Produktes nicht im richtigen Umfang erstellt wird Im weiteren besteht dieses Risiko wenn Gesetze Vorschriften und Richtlinien nicht eingehalten werden Oder wenn neben all den Produkteinnovationen innerhalb einer Projektdurchf hrung neue Methoden und Techniken eingesetzt werden deren Nutzungsm glichkeiten nicht ausgesch pft werden k nnen Materialzulieferungs Risiko Ein Materialzulieferungs Risiko kann dann eintreten wenn die Zulieferungsanforderungen nicht exakt publiziert werden und dadurch die extern ausgef hrten Arbeiten nicht den notwendigen Qualit tsnormen entsprechen Durch ungenaue Eingangskontrollen steigern die Projektrisiken da bei solchen Fehlern weitgehend unbeeinflussbare Reaktionsfristen f r die Fehlerbehebung bestehen Das heisst man wird von weiteren usseren unbeeinflussbaren Faktoren abh ngig Einf hrungsrisiko Dieses tritt vielfach dann ein wenn die Planung von den Entwicklern zuwenig konsultiert wurde oder wenn ihr mangelhafte Prozess Unit Einzeltests oder Integrationstest zugrunde liegen Dies hat zur Folge das SW technische Komponenten nicht in das System integriert werden K nnen 3 3 Managementrisiken Unter Managementrisiken werden Risiken verstanden die in folgenden Bereichen eines Projektes
95. o gestaltet sein dass alle Beteiligten ber ihre entsprechenden A K V s aufgekl rt sind und aufgrund dieser Kriterien auch zur Rechenschaft gezogen werden k nnen Die Projektorganisation muss der Gr sse des Projektes angepasst sein Dabei ist speziell zu beachten dass der Anwender respektive der Benutzer von Anfang an miteinbezogen wird Projektorganisation m ssen flexibel sein damit die Ver nderungsdynamik und die Besonderheiten eines Projektes ber cksichtigt werden k nnen Eine durchdachte strukturierte und klare Projektorganisation ist usserst wichtig f r das Gelingen eines Projektes Die Projektorganisation ist zum einen von der Art des Projektes und zum anderen von der Gr sse des Projektes abh ngig Die folgende Grafik zeigt ein Beispiel f r eine Projektorganisation eines kleinen bis mittleren Projektes auf Marco amp Roger 05 07 05 PRMA 11 88 Eidg Dipl Wirtschaftsinformatiker Lenkundgsausschuss gibt Vorgaben b e mua cht berichtet berichtet A ber t benwacht nsprechparner des Projektleiter Ex Aufraggebers konsultie rt konsultie rt gibt Arbeitsauftr ge berichtet berichtet berichtet konfigurations NM gibt Arbeitsauftr ge berichtet Tester In diesem Beispiel gibt es nur ein Gesamtprojekt und keine Teilprojekte Bei gr sseren Projekten ist es jedoch ratsam Teilprojekte zu definieren und daf r Teil Projektleiter e
96. onsmanager 13 Projektabschlusssitzung 56 Contingency Planning 17 Kontaktliste 72 Projektabwicklung controlling Kontrollsitzungen 56 Restriktionen 7 siehe ZE 5 34 Kontrollverfahren 35 Projektabwicklung 7 10 Controlling EE 34 47 7 D Koordinationsrisiko 15 Projektantrag 48 Datenbankarchitekt 13 Kosten een 28 Projektaufl sung Checkliste 70 Deckblatt nee 50 Kostenarten 29 47 Detailkonzept 48 Kostenindex 37 Projekt Controller 13 Direkte Einsparungen 74 Kreativit tszirkel 40 Projekterfolg 9 Dokumentation Kriterien 41 Projektfortschrittes 16 E GE 44 Kriterienkatalog 11 48 Projekthandbuch 13 Antorderungen sses 44 DEE 28 Projektkontrolle 22 36 49 Kulturbezogene 27 Planungskontrolle 35 Ordungssystem 44 Kundenzufriedenheitsbewertu Realisierungskontrolle
97. pfung von Skalenertr gen bieten sie kleineren Anbietern Kooperationsl sungen im Kreditbereich an Mit ihrem sog CAT Credit Asset Transfer Modell verfolgen sie exemplarisch die Strategie indem sie potentiellen Kooperationspartnern eine volle bernahme von Hypothekarkrediten und den damit verbundenen Risiken anbietet Auftrag und Ziele des Projekts F r die HYPOBANK als f hrende Hypothekarbank im Wirtschaftsraum Z rich ist die oben kurz dargestellte Entwicklung von vitaler Bedeutung In Anbetracht ihres Gesch ftsvolumens ist sie dazu pr destiniert eine f hrende Rolle bei der sich abzeichnenden Spezialisierung in der Hypothekarproduktion d h der Aufteilung des Produktionsprozesses auf die jeweiligen Kostenf hrer zu spielen In der letzten Zeit h ufen sich zudem die Anfragen von Drittinstituten Banken und Nichtbanken nach diversen Kooperationsmodellen Hypotheken Vermittlung Hypotheken Servicing White Labelling etc Unter diesem Aspekt wurde das Projektteam beauftragt einen Business Case f r ein HYPOBANK Gesch ftsmodell mit folgenden Schwerpunkten zu erstellen Analyse der bestehenden Kooperationsmodelle der HYPOBANK und deren Erg nzungsbedarrf e Definition eines HYPOBANK Gesch ftsmodells bei dem die Kundenschnittstelle vom Drittinstitut behalten wird e Wirtschaftlichkeit des HYPOBANK Gesch ftsmodells e Technische Machbarkeit des vorgeschlagenen HYPOBANK Gesch ftsmodells Neues Gesch ftsmode
98. ps zum Einsatz damit sich die Aufmerksamkeit auf den Referenten richtet F r bis zu 20 Teilnehmer Dicke Stifte Kernaussagen Inhalts bersicht spontane Grosse und leserliche Schrift Beitr ge der Teilnehmer Stichw rter oder kurze S tze Wenige Farben einsetzen z B berschrift rot Stichpunkte blau Teilnehmerbeitr ge w hrend der gesamten Pr sentation sichtbar lassen u U an die Wand h ngen Beim Schreiben nicht sprechen sonst redet der Pr sentator mit dem R cken zum Publikum an das Flipchart F r bis zu 20 Teilnehmer Dicke Stifte grosse und leserliche Schrift Als Begleitung des Vortrages Nur Stichw rter oder kurze S tze Als Ideenspeicher z B f r genannte aber in dem Nur wenige Farben einsetzen Rahmen nicht behandelbare Themen Teilnehmerbeitr ge w hrend der gesamten Als Visualisierung Strukturierungshilfe f r Pr sentation sichtbar lassen u U an die Wand Beitr ge der Teilnehmer h ngen Kann mit Digitalkamera fotografiert und als Kopie Beim Schreiben Anpinnen Strukturieren an die Teilnehmer abgegeben werden Clustern nicht sprechen d h Stichwort schreiben lesen Anschliessend anpinnen Wenn Karten mit Teilnehmerbeitr gen umsortiert werden beim Autor nachfragen Wichtig ist dass eine klare Struktur sichtbar ist 8 4 8 Experten Gespr ch Antworten im Top Down verfahren strukturieren Achtung Wenn der Experte jede Antwort dem Referent aus der Nase ziehen muss ist dies eher sch
99. r Produktiontests eingereicht werden EE Bei Wartung Der Inhalt des Release bestimmt ob das Ergebnis Integrationsplan IG Plan aufgef hrt i amp 05 07 05 6 88 Eidg Dipl Wirtschaftsinformatiker 1 Einflussgr ssen eines Projektes Ein Projekt das in der Regel losgel st von den meisten allgemeing ltigen Unternehmensnormen abgewickelt wird hat viele Einflussgr en Die Einflussgr ssen lassen sich wie bei anderen System in Restriktionen und Rahmenbedingungen unterteilen Buch PRMA Seite 81 ff 1 1 Rahmenbedingungen f r die Projektabwicklung Der Projektleiter muss seine Rahmenbedingungen eines Projektes sehr gut kennen Die Rahmenbedingungen lassen sich in f nf Gebiete unterteilen Kriterien Entwicklungsbezogen H ufigkeit von nderungen auf der Entwicklungsbasis Nutzung der Entwicklungsmethoden Vorhandensein von Entwickungstools Bearbeitungszyklus Unterst tzung durch Test und Pr fverfahren QS Durchdringung Qualit tssicherung Dimension der Entwicklungszeit Rahmen des Entwicklungsetats Entscheidungskraft der Leitung Arbeitsaufteilung der Projektstruktur Qualit t des Projektmanagements Einsatz von Projektmanagement Methoden und Verfahren Leitbild Unternehmensstruktur strategie Standards und Richtlinien Entwicklungsstand des Produktes Wirtschaftlichkeitsvorgaben Betroffene Gruppen soziales Verhalten Verf
100. renzung des zu ver nderden Ist System Kurze Beschreibung des Ist Systems Ursache des Auftrags Motivation warum das Projekt realisiert werden soll Systemziele Muster Modell der neuen L sung St rken Schw chen der neuen L sung Systembezogenen Restriktionen Abh ngigkeiten Chancenf Risiken des neuen Systems Einsatzperiodizit t zeit ereignism ssig Erwartete Resultate Der Auftraggeber hat meistens konkrete Erwartungen an das neue System Gelten aber nicht als Ziele oder Einflussgr ssen sondern nur Erwartungen Projektmanagementbereich Projektpriorit t wird vom Portfoliomanagement zugewiesen Besonderheiten Abweichungen Ablauforganisation Abwicklungsziele Wirtschaftlichkeit quantifizierbarer Nutzen Imponderabilien nicht nachweisbare Vorteile Gef hlswerte Kosten einmalig periodisch Kosten Nutzen Pay Back Periode Budget Terminierung Dokumentations und Informationsverfahren Aufbauorganisation Datum der Genehmigung Name der welche Auftrag genehmigt Unterschriften der Vertreter Systembereich 9 oo o 7 7 2 Vorstudien Dokument Mit der Vorstudie kann ein Projektleiter die Voraussetzungen f r den Entscheid ber die Durchf hrung eines Projektes durch Ermittlung und Analyse der anstehenden Probleme schaffen L sungsideen entwickeln und die Wirtschaftlichkeit der L sung feststellen 7 7 3 Konzept Dokument Basierend auf dem Entscheid der Vorstudie
101. rgebnisse der Phasen Vorstudie und Hauptstudie die Entwicklungsunterlagen der Phasen Systemspezifikation und Implementierung sowie die Projektmanagement Unterlagen Projektauftrag Phasendokumente Pflichtenheft abh ngig Kriterienkatalog Berichte phasen Projektabschlussbericht etc Abwicklungs dokumentation Stellenbeschreibung Projektorganisations Dokument Vorgehensziele Budget Antr ge phasen unabh ngig Zeitpl ne und Personalpl ne Konfigurations Aufzeichnungen Arbeitsauftr ge Sitzungsprotokolle etc Abb Gliederung der Abwicklungsdokumentation Marco amp Roger 05 07 05 PRMA 46 88 Eidg Dipl Wirtschaftsinformatiker 7 7 1 Projektauftrag Siehe auch Buch Projektmgmt in der Wirtschaftsinformatik S 157 ff Wird ein Projektantrag Abstract gutgeheissen so muss der Projektleiter den sogenannten Projektauftrag erstellen Synonyme f r Projektauftrag k nnen z B Mandat Planungsofferte oder Projektvertrag Kontrakt sein Der Projektauftrag enth lt folgende Punkte Projektidentifikation Bereich Bezeichnung des Projektes gem ss offizieller Projektliste Projektnr gem ss offizieller Projektliste Abteilungen die in die Projektbearbeitung direkt involviert sind Organisationseinheiten in denen das Projekt bearbeitet wird Name des Projektverantwortlichen Auftraggeber Auftragsempf nger Ausgangslage Es wird die momentane Situation festgehalten Umfang Abg
102. rm zu erfolgen hat Somit ist die Aufbewahrung auf einem normalen Datentr ger Band oder Diskette nicht zul ssig 2 Sinn und Zweck eines optischen Archives Hauptgrund f r die Einf hrung eines optischen Archives sind Einsparungen und die nichtmonet re Nutzen Insbesondere der grosse Nutzen der schnellen Wiederauffindbarkeit von Informationen darf nicht untersch tzt werden Zudem verhindert eine optische Archivierung dass Dokumente entfernt oder vernichtet werden 3 Vorgehen bis Projektantrag Im langfristigen Informatik Projektportfolio ist vorgesehen bei nachweislichem Nutzen eines Optoarchives dass eine Realisierung anzustreben ist Die Anforderungen mussten nicht nochmals in einem Pflichtenheft definiert werden da dies bereits bei der Ausschreibung des Druckerkonzeptes umfangreich geschehen ist Damals wurde eine Komplettl sung Druckerkonzept Optoarchiv angestrebt Aus Kosten und Termin Gr nden wurde in einer ersten Phase nur das Druckerkonzept realisiert 4 Mengenger st f r Optoarchiv 27 Verschiedene Belegarten mit insgesamt 970000 Seiten pro Jahr Die Wachstumrate betr gt ca 5 pro Jahr Die Optische Platten im Optical Disc Server sind so angelegt dass sie f r ca 5 Jahre reichen Danach m ssen sie ausgelagert werden Marco amp Roger 05 07 05 PRMA 83 88 Eidg Dipl Wirtschaftsinformatiker 5 Kosten Die Kosten sind aufgeteilt in einmalige Kosten extern durch den Offertsteller die Firma IMTF Givisi
103. rtschaftsinformatiker 7 11 Projekt Berichtswesen 7 11 1 Einleitung Bei kleinen Projekten Auftr gen ist es vielfach m glich auf formale Regelungen des Informationsaustausches zu verzichten Je gr sser die Projekte und Anzahl der Beteiligten sind die an einer gemeinsamen Aufgabe beteiligt sind desto wichtiger ist die Regelung des formalen Informationsaustausches Bei solchen Vorhaben ist das Projekt Berichtswesen bereits bei Projektbeginn zu regeln Projekt Besprechungen Projektfortschrittsbericht Pendenzenberichte Planungsberichte Auslastungsberichte Qualit tsberichte Reviewberichte Auditberichte Management Summary Projektabschlussbericht ete Projekt Informationssystem Projekt Berichtswesen 7 11 2 Aufbau des Berichtswesens Wer welche Gremien Institutionen etc ben tigt Informationen Welche Informationen werden ben tigt Wann werden diese ben tigt 7 11 3 Berichtsplan Das Ergebnis dieser Analyse ist ein projektspezifischer Berichtsplan in dem nachfolgende Punkte geregelt werden Berichtsart T tigkeitsbericht Projektstatusbericht Monatsbericht Projektabschlussbericht Entwicklungsbericht etc Berichtster
104. rung des Kundendienstes Straffung des Verwaltungsapparates Geringere Personalabh ngigkeit durch besser organisierte Abl ufe Erh hung der Einnahmen Fr here Zahlungseing nge durch fr hzeitiges Fakturieren und termingerechtes Mahnen _Umsatzerh hung durch schnellere Auslieferung 11 4 2 Indirekter Nutzen Eidg Dipl Wirtschaftsinformatiker Ein indirekter sekund rer Nutzen entsteht bei Dritten Man unterscheidet zwischen technischem neueste Maschinen die anderweitig auch genutzt werden k nnen usw und marktm ssigem mehr Ansehen usw indirektem Nutzen Marco amp Roger 05 07 05 PRMA 75 88 Eidg Dipl Wirtschaftsinformatiker 12 Anhang 12 1 Statusbericht Project Kwick2000 und Prodkonfig Project number X 000942 Project start 01 01 2002 Project end 31 07 2003 Release Major Milestones Deliverables original actual Plan end date end date act 001 Freeze Bankfach Spezifikation 31 03 2002 03 2002 C001 Service testbereit im MIT Lenze 05 09 2002 001 Test im MIT abgeschlossen 21 12 2002 001 Test im abgeschlossen 26 05 2003 D001 Inbetriebnahme 30 06 2003 Project Delivery Status gt mark with Reasons Implications Reasons Implications Measures G Y R for IT for Business Yes Nr No Assessment plan actual Expected milestone achievement Liste der zur ckgestellten Change Requests muss nach PSG Entscheid verifiziert werden Liste der zur ckgest
105. rungslehre gr tenteils durch Motivation erbracht Sind die Projektmitarbeiter demotiviert so fallen ihre Leistungen ab Demotivation Dies trifft immer dann ein wenn die verantwortlichen F hrungspersonen die F hrungsaufgaben missachten So f hrt z B eine schlechte Planung zur st ndigen berbelastung der Projektmitarbeiter mit sich Politisches Risiko Projekte k nnen dadurch bedroht werden dass durch Bilden von Interessengruppen nicht mehr die Sachziele sondern nur noch pers nliche Ziele verfolgt werden Geraten Projekte zwischen die Fronten solcher Machtk mpfe werden sie zu Spielb llen von M chten auf die weder der Projektleiter noch der Auftraggeber einen Einfluss haben Mitarbeiterrisiko Der Mitarbeiter stellt mit seiner F higkeit Fertigkeit und Einsatzzeit ein Risiko dar da er mit bewussten oder unbewussten Handlungen auslassen von Dokumentationen K ndigung fehlendes Fachwissen usw eine negative Wirkung erzeugen kann Dieses Risiko wird oft durch fehlende Kontrollen oder durch ein schlecht organisiertes Stellvertreterwesen stark erh ht 3 5 Risiko Entsch rfung Die meisten Risiken k nnen durch den permanenten Gebrauch von Erfolgsfaktoren und durch das Anwenden neuer Richtlinien oder durch das Einsetzen von entsprechenden Unhnterst tzungsverfahren entsch rft werden Risikominimierung von Institutionalisierung von Richtlinien Anpassen des Methodenhandbuches Erweitern und Anpassen des Projektmanage
106. s antrag Projektantrag Aufwand gt 2 PJ Aufwand lt 2 PJ Projekt Y Projekt X Statusbericht zur Umsetzung des IS Entwickl plans Abschluss Bericht Projekt Auftr ge Phasenauftr ge Statusbericht Abschluss Bericht IS Entwicklungskontrolle Projektabwicklung Projekt Nachkontrolle Das IS Projektportfolio verwaltet die aus der Unternehmung Fachbereich stammenden die ber die IS Architektur koordinierten Projekten und die ber die Kreativit tszirkel Erfahrungsgruppe eingereichten Antr ge 6 3 Prozessschritte Marco amp Roger 05 07 05 PRMA 39 88 Eidg Dipl Wirtschaftsinformatiker 6 4 Das Projektportfolio zeigt auf Welche Projekte durchzuf hren sind Wann mit welchen Projekten begonnen werden kann Wann ein Projekt abgeschlossen sein muss Welche Projekte parallel zu andern Projekten realisiert werden k nnen In welcher Reihenfolge die Projekte zu realisieren sind Wann welche Investitionen get tigt werden m ssen Wie hoch der j hrliche Realisierung Aufwand in Wochen ist Das globale Ziel des IS Projektportfolios ist Das richtige Projekt zur richtigen Zeit im richtigen Unternehmungsbereich mit den erforderlichen Ressourcen zu initialisieren 6 4 1 IS Antrag Drei Wege zum IS Antrag Top Down aus den Architekturen aus dem Fachbereich Kreativit tszirkel 6 4
107. sbericht 54 75 Systemabnahme 67 71 Systemanalytiker 13 Systemarchitekt 13 Systemdokumentation 49 T Team aufbauen 72 Alle angebotenen Inhalte dienen ausschliesslich zu pers nlichen Information Eine kommerzielle Nutzung der Inhalte ist nicht gestattet Eidg Dipl Wirtschaftsinformatiker Teamf hrung 11 Tester ie 13 berstunden 27 V Vermeidbare Kosten 74 EE 47 W Wartungsdokumeri 49 2 Zeitpunkt der Risikoanalyse 19 Zieldefinition 30 Zielformulierung 30 Die hier ffentlich zug nglich gemachten Dokumente inklusive weiterer dazugeh riger Daten wie z B Bilder Grafiken sind urheberrechtlich gesch tzt Verantwortlich f r die Inhalte sind die jeweiligen Autoren siehe jeweilige Quellen Einzelne Vervielf ltigungen z B Kopien und Ausdrucke d rfen nur zum privaten und sonstigen eigenen Gebrauch angefertigt werden Alle Inhalte auf diesem Server werden ohne Gew hr f r ihre Richtigkeit Aktualit t und Vollst ndigkeit wiedergegeben In keinem Fall wird f r Sch den die sich aus der Verwendung der abgerufenen Informationen ergeben eine Haftung bernommen F r die Inhalte der ber Hyperlinks verbundenen Angebote auf anderen Servern sind die jeweiligen B
108. schaftsinformatiker Der GB IT vermittelt relevante Informationen sowie ihr Know How ber die IT Projekte effizient zum Business Die GB IT Mitarbeiter werden als flexibel kundenorientiert stabil kompetent und professionell wahrgenommen Durchschnitts Bewertung 5 6 teils teils zufrieden 9 10 sehr zufrieden PRMA 79 88 Eidg Wirtschaftsinformatiker Customer Satisfaction Rating Protokoll Messkriterien Hier werden die Gr nde aufgef hrt die zur Beurteilung gef hrt haben Bewertung Budgeteinhaltung Kostentransparenz_ Bewertung _ Flexibilit t Bewertung__ Fachkompetenz Bewertung _ Sozialkompetenz Bewertung _ Innovation Beitrag neuer Ideen 222 2 Bewertung _ Einbezug der Benutzer Kunden und Auftraggeber ___ewertung__ Informationsvermittlung______ ___ __ _ Bewertung _ Marco amp Roger 05 07 05 PRMA Erl uterung und Schwerpunkte pro Messkriterium On Time gilt f r alle zugesagten Termine und bezieht sich auf den jeweils vereinbarten Lieferumfang Die Ergebnisse entsprechen den vereinbarten Anforderungen Die GB IT Mitarbeiter sind stets bem ht ihre Dienstleistungen so auszurichten dass f r ihre Kunden ein Mehrwert entsteht GB IT strebt eine hohe Kosten und Planungs transparenz an Weisen die Reports auf gr ssere Abweichungen hin so wird die Situation unmittelbar den Betroffenen kommuniziert Das Verhalten
109. sionsbasis erfordert um eine weitgehende Personenunabh ngigkeit zu erreichen das neu entwickelte System nach der Einf hrung laufend er sich ver ndernden Umgebung anzupassen da f r mehrere Anwender unterschiedlicher Fachrichtung und Funktionen dieselben Informationsunterlagen verf gbar sein m ssen da zur Vermeidung von Widerspr chen eine verbindliche Dokumentation notwendig ist 7 2 Anforderungen an ein Dokumentationssystem Die projektbegleitende Dokumentation sollte gem ss der Institutionalisierung folgenden Anforderungen gen gen e Vollst ndigkeit Zuverl ssigkeit des Inhaltes Wahrheitsgehalt e Aktualit t des Inhalts neuster Projektstand Darstellung einheitliche Gliederung nderungsfreundlichkeit Eindeutigkeit der Aussagen 7 3 Ablage und Ordungssystem Die einzelnen Dokumente k nnen nach unterschiedlichen Gesichtspunkten geordnet und archiviert werden Wichtig ist dass bei der Festlegung des Ordnungssytems Art und Zweck der Dokumente ber cksichtigt werden Jedes Dokument muss folgende Angaben ob in form eines Schl ssels oder eines Freitextes f r jeden Leser gut ersichtlich enthalten Gebiet Projekt Titel Thema Identifikation Zugriffspfad e Verantwortung z B Autor _Ansprechpartner Kontaktstelle _Dokumentversion geschichte Lagerort bei gedruckten Versionen e Status e Erstellungs und nderungsdatum Gesamtseitenzahl A
110. sm glichkeiten im Projekt Auftrag erfolgt nicht Konkrete Anforderungen sind termingerecht nicht in Sicht Kunde dr ngt trotzdem auf Beginn Neue Kundenvertreter Neue Personen bringen neue Perspektiven und grosse Aenderungen f r s Projekt Kein Know how vorhanden Kunde warnt vor Komplexit t hnliche Projekte beim Kunden oder der Konkurrenz sind gescheitert Kunde verlangt unbekanntes Vorgehen neue Methoden Projektumfang komplexit t bersteigt den Anwendungsbereich der Methoden Kein spezifisches Know how erkennbar Bereitschaft zum Lernen fehlt der zu leistende Aufwand ist gr sser als die Personalkapazit t Zeit Produktivit tsfaktor 0 6 0 8 je nach Gr sse des Zeitraums keine M glichkeit vorhanden kurzfristig zus tzliche Wir verstehen die Problemstellung nicht oder untersch tzen sie massiv Wir beherrschen dieses Projekt methodisch nicht Die Qualifikationen und oder die Menge der Projektmitarbeiter sind ungen gend Marco amp Roger 05 07 05 PRMA Diskussionen ber die Aufgaben Aenderungsverfahren einf hren Projektmitarbeiter zu rekrutieren Leistungsabh ngige Zahlungsmeilensteine vereinbaren Vorrauszahlungen Konkrete Planung Dokumentation u offizialisierung der Rechte und Pflichten Rollen Terminplan in der Offerte relativ tO Auftragserteilung etc gestalten Beschl sse und Entscheidungen schriftlich festhalten Reviews durchf hren
111. splanung 42 Moderation 56 Projektverzung 27 Entwicklungsrisiken 15 Moderatorenkarten 62 Prozess der Projektbewertung 40 Erfahrungssicherung 70 Motivation 17 Q Erfolgsfaktor Motivation Projektmitarbeiter 17 Qualit tsbericht 55 11 Motivationsf rderung 27 Qualit tsmanager 12 ProjAbwicklung 10 Motivationsrisiko 16 Marco amp Roger 05 07 05 PRMA R Rahmenbedingungen 7 Rangfolge Kiran 42 Realisierungskontrolle 35 Realisierungskosten 28 LHeourement 31 7 57 Review in ZF_QUAL 57 Reviewbericht 55 Risiken 14 Soziale 14 14 Entbwicklungs 14 Disclaimer 23 16 Risikominimierung 16 S schlagartige Einf hrung 65 schrittweise Einf hrung 65 Sitzungsleitung 56 Soziale Risiken 16 Spickzettel 62 Statu
112. t IVIKAT I Set E HVH 1 Eidg Dipl Wirtschaftsinformatiker Big Picture Wartung bersicht mit Phasen je Release Sign off Prozessen und Ergebnissen Initialisierung pro Release Planurvg und Funktionale und nicht Entwurf Release Implementierung und Applikations Ausbreitung BAD Rahmen f r funktionale Anforderungen Relsase integratiorstest Ralsass die Wartung den Release Produktionstest Aequiramante Sign off Speeification Sign aff Production Sign off E durch Auftraggeber Planung und Wartungsplan Risikomanagement Statusbericht Gesch ftsprozessmodel Order Release lierung Anforderungen IT Analyse und IT Design Implementierung Change Management Report un runde Management Ausbreitung Qualit tsmanagement Qualit tsplan und Test Testdrehbuchl bericht Umgebung Legende BSO SSO PSO Das Ergebnis geht durch den entsprechenden Sign off RSO Der Auftraggeber best tigt explizit die Anforderungen an die IT L sung Ergebnis mil Federf hrung im Business BTC Mitarbeit durch Ergebnis mit Federf hrung in der IT Mitarbeit durch Ergebnis in mehreren Auspragungen Die Federf hrung ist fallweise durch den Projeklleiter festzulegen Das Ergebnis muss zwischen 3 Wochen 15 Arbeitstage bis 2 Tage vor dem Start des Applikations Integrationstests AIT ode
113. tallationsprozedere Migration Daten bernahme Lebensversicherung Fallback L sung Katastrophenplanung Schulung Entwicklung der Schulungsunterlagen Referenzkarten Arbeitsanweisungen Aufbau der Schulungsdatenbank Marco amp Roger 05 07 05 PRMA 65 88 Support Hotline Konzept Applikation Entwicklung Test der Applikationen Installation der Applikationen Durchf hrung der Migration Schulung der Anwender Fehlerbereinigung Systemabnahme Eidg Dipl Wirtschaftsinformatiker Projektabschlussbericht 9 4 Einf hrungsstrategie 9 4 1 Einflussfaktoren Techn Ranmenbedingungen Komplexit t Datenmengen Risiko Ressourcen Kosten 9 4 2 Arten von Einf hrungen Einmalige einfache Daten bernahme gt Datenkonsistenz Integrit t Keine Doppelbelastung f r den Anwender Geringer Abl sungsaufwand Einfachere Einf hrungskoordination Sachmittel EDV Mittel etc Anwender kann sich langsam an das neue System gew hnen Erfahrungen k nnen stufenweise gesammelt und in nachfolgenden Komponenten ber cksichtigt werden berschaubare einfache Einf hrung Step by step Teilresultate sind schneller beim Anwender verf gbar Marco amp Roger 05 07 05 PRMA Einf hrungsstrategie Management Organisation Schnittstellen Aufwand Nach Systemeinf hrung oftmals kein Weg mehr zur ck Fehlgeschlagene Einf hrung 9 Datenverlust m gli
114. teine Kosten Budget Fr 20 000 a Rechnungen von total Fr 14 000 b 15 Steine verlegt Fr 10 000 Fr 10 000 14 000 Fr 4 000 Fr 14 000 7 500 Fr 6 500 Arbeitswert 40 Steine Fr 20 000 15 Steine 27 500 Arbeitswert 7500 Budget bis Stichtag 10000 0 75 Arbeitswert 7500 IST Kosten bis Stichtag 14000 0 53 PRMA 37 88 Eidg Dipl Wirtschaftsinformatiker 6 Projektportfolio siehe ZF_ISMA Projektportfolio Leitbild IS Konzept IS Architektur Markt Produkt Finanz Personal Strategie Strategie Strategie Strategie IS Projektportfolio IS Projekt IS Betreuung Informationen bestimmen oder unterst tzen jedes wirtschaftliche Handeln und Entscheiden Informationen bzw ihre Anwendung dient der L sung einer Aufgabe eines Problems oder der Erreichung um eines Zieles Kr fte e Politische e Milit rische e Wirtschaftliche e Religi se e Information Medien Presse 6 1 1 Informationen Informationen als Produktionsfaktor grenzen sich von den anderen Produktionsfaktoren durch folgende Merkmale ab Information kann nicht physisch abgenutzt werden Information kann beliebig vervielf ltigt werden Information kann verloren gehen Information kann fehlerhaft sein Information kann obwohl richtet wertlos sein wenn zur falschen Zeit bereitgestellt Information kann inhaltlich altern Hinderungsgr nde dass
115. tionsgerecht eingesetzt werden Diese Methoden und Werkzeuge situationsgerecht einzusetzen heisst sie je nach Problemstellung so zu gebrauchen dass sie bezogen auf die Projektziele am meisten Nutzen bringen Daraus k nnen folgende Erfolgsfaktoren abgeleitet werden Richtlinien Die aus der eingesetzten Methode resultierenden Richtlinien f r die Projektdurchf hrung m ssen umfassend und f r alle verst ndlich sein berblickbare Phasen Projekte sind gem ss des angewandten Denkmodells innerhalb eines Gesamtkonzeptes berblickbare Phasen zu gliedern Ber cksichtigung von S mtliche Aspekte einer Phase m ssen ber cksichtigt werden Aspekten einer Phase respektive auf die Situation bezogen angewendet werden Qualifizierte Sachmittel Einsetzen der Methoden oder Techniken bedingt das Vorhandensein von qualifizierten Sachmitteln Nutzung von Sachmitteln Eingesetzte Hilfsmittel m ssen einwandfrei funktionieren und die Benutzer m ssen mit ihnen professionell umgehen k nnen Marco amp Roger 05 07 05 PRMA 10 88 Eidg Dipl Wirtschaftsinformatiker 2 2 4 Personen Trotz allen Regeln scheitern Projekte eher an falschen Eins tzen oder mangelnden Engagement der Beteiligten als an der Unl sbarkeit der Probleme Es braucht deshalb neben formellen Regeln und Vorschriften bestimmte Voraussetzungen beim Projektteam Fachwissen Durchsetzungsverm gen Identifikation mit der Aufgabe usw u
116. tt zur Vereinheitlichung Ebenfalls k nnen somit ev entstehenden hohen Folgekosten und Kosten f r bergangsl sungen entgegengewirkt werden Marco amp Roger 05 07 05 PRMA 82 88 Eidg Dipl Wirtschaftsinformatiker 12 4 Projekt Management Summary Optisches Archiv Investitionsantrag Einf hrung eines Optischen Archives Management Summary 1 Einleitung Die John Lay Electronics AG ist Generalimporteur der Weltmarken Panasonic und Technics Vor vier Jahren wurde bei John Lay Electronics ein neues Druckerkonzept eingef hrt Die zu druckenden Informationen werden vom Hauptrechner IBM AS 400 auf einen UNIX Rechner IBM RS 6000 weitergeleitet Die Formulare sind in elektronischer Form gespeichert und werden mit den variablen Daten aus dem AS 400 gemischt und ausgedruckt Die archivrelevanten Belege werden zwischengespeichert einmal t glich ausgedruckt und manuell Abgelegt Mit der Einf hrung dieses elektronischen Drucksystems wurden bereits einige Vorarbeiten f r eine elektronische Archivierung geleistet Die zwischengespeicherten Belege k nnen k nftig statt ausgedruckt direkt ber einen weiteren Rechner Optical Disc Server auf optische Platten geschrieben und archiviert werden Dieses Medium ist neben der Papierform oder Mikroverfilmung das einzige rechtlich anerkannte und zugelassene Archivierungsmedium Die gesetzliche Auflage schreibt vor dass die Archivierung in einer unver nderbarer und nicht manipulierbarer Fo
117. ufbauend auf einem Schl sselsystem ben tigt das einzelne Dokument neben der Laufnummer ein zus tzliches eindeutiges Identifikationskriterium Hierf r muss man einen Projekt Dokumentationsschl ssel der folgende Angaben enthalten kann bilden e Projektnummer z B Kostenstelle e Art der Dokumentation Abwicklungs Systemdokumentation oder Produktnummer Kennzeichen f r die Entwicklungsphase e Identifikation des Arbeitspakets aus dem Produktstrukturplan Marco amp Roger 05 07 05 PRMA 44 88 Eidg Dipl Wirtschaftsinformatiker 7 4 Sicherstellung der Projektdokumentation Im Institutionellen Projektmanagement werden keine Dokumentationen erstellt sondern lediglich die Ordnungskriterien und ihre Definition festgelegt sowie folgende Fragen gekl rt e Wer schreibt was klare Zuteilung der Verantwortlichkeit e Wie wird dokumentiert Darstellungsmethoden und techniken Richtlinien festlegen Tools zur Verf gung stellen e Was muss dokumentiert werden e Wann soll dokumentiert werden e Wie lange werden die Dokumente aufbewahrt e Wo werden die Dokumente aufbewahrt e Wie geschieht die Nachf hrung Des weiteren muss folgendes beachtet werden _Rahmenbedingungen schaffen Kontrollsystem einrichten 7 5 Massnahmen zur Sicherstellung der Projektdokumente Ger t ein Projekt in Zeitnot so wird vielfach wenn kein entsprechendes Tool eingesetzt wird an der Informations und
118. um ein gesichertes gemeinsames Verst ndnis zu erzeugen Projekt evtl mit Hilfe Dritter strukturieren und ad quate Meilensteine zus zu den ERL einfuehren Know how aneignen Beurteilung der klare Zielvorgaben mit Best tigungen verlangen Schulung Prujektumfang anpassen 24 88 Eidg Dipl Wirtschaftsinformatiker Die vorgesehene Schlechte Kommunikation Stop Think Act Projektorganisation ist ineffizient Transparenz fehlt unbefriedigende IST Situation Projektmitarbeiter sind nicht Kommunizieren und Wege zur informiert Verbesserung implementieren Andere Projekte haben einen Verf gbarkeit geringer als Managementattention f rdern negativen Einfluss z B wichtige geplant eigene Ressourcen Lobbying Info Workshop Ressourcen absorbieren werden st ndig angefragt Veranstaltungen durchfuehreren Projekt geniesst keine Unterst tzung Pers nliche Probleme im Unfreundlicher Tonfall bei Aussprachen durchf hren Projektteam st ren das Projekt Sitzungen Anweisungen werden eruiren ignoriert starke Gruppenbildung motivationshemmende Faktoren schlechte Leistungen versteckte eliminieren oder offene Konflikte Mobbing Gleiche Typen von Mitarbeitern motivationshemmende Faktoren unn tig lange Diskussionen eliminieren Teamstruktur keine Diskussionen wenig verbessern Impulse von aussen Teamgef hl iniziieren Aufgabenteilung ndern Wir nehmen Risiken nicht Gew hnung an unzureichende Risikoman
119. vorhanden Technologie oder Branche ist f r Unterlieferanten Neuland Termine bei Projektbeginn werden laufend verschoben Einsch tzungen des Unterlieferanten erstaunen bzw erscheinen unrealistisch Marco amp Roger 05 07 05 PRMA 25 88 Eidg Dipl Wirtschaftsinformatiker Die Rechte den Ergebnissen Keine schriftlichen Abmachungen Vorlagen Vertr ge verbessern bez glich Urheberrechen an Ergebnissen Software oder Methoden Abh ngigkeit von externen Monopolsituationen Zahlungs Meilensteine mit Lieferanten oder MA Auftragnehmer beginnt mit der dokumentierten Leistungen Ausf hrung ohne rechtliche koppeln Dokumentationsumfang Grundlage Dokumentation des und Inhalt nachpr fbar festlegen Lieferanten erm glicht die eigene Konkurrenzsituation schaffen Weiterentwickling nicht Know how Erhalt nach Keine ad quate Dokumentation Dokumentation aktualisieren vorhanden keine brauchbaren Relevanz von Dokumenten Strukturen Informationen nicht definieren Weiterentwicklung auf dem aktuellen Stand lange Einarbeitungszeiten Dokumente und Applikation sind nicht kongruent Entscheidungsgrundlagen fehlen Fehlende Transparenz klare Infomationsstrukturen Art und oder sind ungen gend Informationen k nnen nicht innert Inhalt festlegen sich auf n tzlicher Frist gegeben werden sinnvolle Dokumentation widerspr chliche Informationen beschr nken keine Papiere die nicht gebraucht werden Marco amp
120. wicklungsplanung ist es die Reihenfolge der Projekte Zeithorizont 3 5 Jahre mit Hilfe von Priorisierungskriterien festzulegen und die Ressouren Personen Infrastruktur und Finanzen f r die Realisierung der Projekte zu bestimmen 6 4 4 1 Ermittlung der unternehmerischen Rangfolge Projektrangfolge wird ermittelt mit Blick auf e Wichtigsten Unternehmensziele Kosten Nutzen berlegungen Die strategischen Erfolgsposition ihre Wirtschaftlichkeit UN Ziele Amortisations Firmenziele Kundenziele Mitarbeiterziele RANG Folge dauer in Georg em E _ Projekt 4 Ye L Berechnungstechniken Kostenvergleichsrechnung Gewinnvergleichsrechung Rentabilit tsrechnung Amortisationsrechung Barwertmethode F r alle diese Verfahren werden quantitative Angaben ber die zu erwartenden Kosten und Nutzen ben tigt die zu diesem fr hen Zeitpunkt eines Projektes nicht immer ganz einfach zu beschaffen sind Aus diesem Grunde wird die Wirtschaftlichkeit eines Projektes laufend z B von Phase zu Phase neue berpr ft Marco amp Roger 05 07 05 PRMA 42 88 Eidg Dipl Wirtschaftsinformatiker 6 4 4 2 Ermittlung der betrieblichen Reihenfolge F r die betriebliche Reihenfolge sind folgende Punkte massgebend Sachlogischer betriebswirtschaftliche Aufbau der IS Architektur Wichtigkeit Dringlichkeit der Systeme Zur Verf gu

Zusammenfassung PRMA - roger

Contents

Download Pdf Manuals

Related Search

Related Contents