Projektmanagement - Begriffe und Teilprozesse PDF

Projektmanagement Begriffe und Teilprozesse Prof. DI Dr. Erich Gams htl‐[email protected] Informationstechnische Projekte - Theorie HTL-Wels  Motivation  “Zeit haben” ‐ der Luxus unserer modernen Welt...

Projektmanagement Begriffe und Teilprozesse Prof. DI Dr. Erich Gams htl‐[email protected] Informationstechnische Projekte - Theorie HTL-Wels  Motivation  “Zeit haben” ‐ der Luxus unserer modernen Welt  mehr Leistung  Kürzere Zeit  Top‐Qualität  Projektmanagement hilft! Prof. DI Dr. Erich Gams Seite 2/51  Motivation  Professionelles Projektmanagement fällt nicht vom Himmel!  Es muss erlernt werden ‐ und weiterentwickelt. + Ständiges Optimieren, Adaptieren und Verbessern der Arbeitsweise ist das Um- und Auf professioneller Projektmanager. Prof. DI Dr. Erich Gams Seite 3/51  Projekte und Projektarten  Projekte können unterschiedlich wahrgenommen werden, und zwar als  komplexe Aufgaben  temporäre Organisationen  soziale Systeme Prof. DI Dr. Erich Gams Seite 4/51  Projekteigenschaften  Brainstorming Prof. DI Dr. Erich Gams Seite 5/51  Projekteigenschaften  komplex  meist neuartig  riskant  für das projektdurchführende Unternehmen bedeutend  zieldeterminierte Aufgaben  Ziele werden unter Konkretisierung des Leistungsumfangs, der Termine, der Ressourcen und der Kosten zwischen dem Projektauftraggeber und dem Projektleiter vereinbart werden Prof. DI Dr. Erich Gams Seite 6/51  Typische Merkmale eines Projekts Prof. DI Dr. Erich Gams Seite 7/51  Projekt und Programme Prof. DI Dr. Erich Gams Seite 8/51  Es gibt auch Definitionen….Projekt  Nach DIN 69 901 versteht man unter einem Projekt " ein Vorhaben, das im wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, z.B. ‐ Zielvorgabe ‐ zeitliche, finanzielle, personelle und andere Begrenzungen ‐ Abgrenzung gegenüber anderen Vorhaben ‐ projektspezifische Organisation". Prof. DI Dr. Erich Gams Seite 9/51  Was ist Projektmanagement?  Projektmanagement ist nach DIN 69901 die  "Gesamtheit von Führungsaufgaben, ‐ organisation, ‐techniken und ‐mittel für die Abwicklung eines Projekts" Prof. DI Dr. Erich Gams Seite 10/51  Projektmanagement  Planung, Koordination, Controlling und Organisation von Projekten  Ziele  Leistungen, Termine,  Ressourcen, Kosten  Organisation, Kultur  Kontext (Vor‐, Nachprojektphase, Umwelten; andere Projekte) Prof. DI Dr. Erich Gams Seite 11/51  Projektmanagementprozess Prof. DI Dr. Erich Gams Seite 12/51  Projektmanagementprozess  Der Projektmanagementprozess startet mit der Projektbeauftragung und endet mit der Projektabnahme. Prof. DI Dr. Erich Gams Seite 13/51  Projektmanagementprozess  Teilprozesse  Projektstart, Projektcontrolling und Projektabschluss.  „Mögliche“ Teilprozesse  Projektmarketing  Bewältigung einer Projektkrise. Prof. DI Dr. Erich Gams Seite 14/51  Projektstart ‐ Aufgaben  Vereinbarung von Projektzielen  Erstellung von Projektplänen  Design einer adäquaten Projektorganisation, die Teambildung  die Planung von Maßnahmen zur Krisenvermeidung und – vorsorge  die Planung der Gestaltung von Projekt‐Kontext‐ Beziehungen,  Projektmanagement‐Dokumentation! Prof. DI Dr. Erich Gams Seite 15/51  Projektcontrolling ‐ Aufgaben  Ziele des Projektcontrolling sind die Feststellung des Projektstatus  die Vereinbarung bzw. die Vornahme steuernder Maßnahmen,  die Weiterentwicklung der Projektorganisation und der Projektkultur  die Erstellung von Fortschrittsberichten  die Durchführung von Projektmarketingmaßnahmen Prof. DI Dr. Erich Gams Seite 16/51  Projektmarketing  Folder  Newsletter  Zeitungen  Infoblätter  Vernissagen  etc Prof. DI Dr. Erich Gams Seite 17/51  Projektkoordination ‐ Aufgaben  laufende Sicherung des Projektfortschritts,  laufende Sicherung der adäquaten Informationen für Projektteammitglieder  laufende Unterstützung der Erfüllung einzelner Arbeitspakete.  Laufende Qualitätssicherung der (Zwischen‐)Ergebnisse von Arbeitspaketen  Laufende Kommunikation des Projektmanagers mit Projektteammitgliedern und dem Projektauftraggeber,  laufende Gestaltung der Beziehungen zu relevanten Umwelten und die Disposition von Projektressourcen. Prof. DI Dr. Erich Gams Seite 18/51  Projektabschluss ‐ Aufgaben  inhaltliche Restarbeiten  Erstellung der "As‐is"‐Dokumentation  die letztgültige Version des Projekthandbuchs  das Treffen von Vereinbarungen für die Nachprojektphase und die Erstellung von Projektabschlussberichten,  der Transfer des gewonnen Know‐hows  der „emotionale Abschluss“  Auflösung des Projektteams  Abschlusstreffen  endet mit der Abnahme des Projekts durch den Projektauftraggeber. Prof. DI Dr. Erich Gams Seite 19/51  Projekterfolgskriterien  Das professionelle Management ist als zentrales Erfolgskriterium von Projekten zu sehen  die Projektgrenzen und die Projektziele adäquat zu definieren  Projektpläne zu entwickeln und einem periodischen Controlling zu unterziehen  Projekte prozessorientiert zu strukturieren  die Projektorganisation und Projektkultur projektspezifisch zu designen.  eine spezifische Projektkultur zu entwickeln und  die Beziehungen des Projekts zum Projektkontext zu gestalten. Prof. DI Dr. Erich Gams Seite 20/51  Methode nach PMA Prof. DI Dr. Erich Gams Seite 21/51  Methode nach PMA Prof. DI Dr. Erich Gams Seite 22/51  Projektstart “Sage mir wie Dein Projekt beginnt und ich sage Dir, wie es endet” Prof. DI Dr. Erich Gams Seite 23/51  Die Bedeutung der frühen Phasen Prof. DI Dr. Erich Gams Seite 24/51  Projektmanagementprozess Prof. DI Dr. Erich Gams Seite 25/51  Methoden zum Projektstart (laut PMA)  Projektziele  Projektplanung  Projektkontext Analysen  Objektstrukturplan,  Projektumweltanalyse Betrachtungsobjekte  Projekt und Business Case  Projektstrukturplan  Projektmarketing  Arbeitspaketspezifikationen  Design der Projektorganisation  Projektphasen  Projekttermine  Projektorganigramm  Projektressourcen  Projektrollen  Projektkosten  Projektteamarbeit  Projektfinanzmitteln  Führung in Projekten  Projektrisiken  Kommunikation im Projektstart  Funktionendiagramm  Projektkultur Prof. DI Dr. Erich Gams Seite 26/51  Und wo lege ich meine Ergebnisse ab? Prof. DI Dr. Erich Gams Seite 27/51  Gesammelte Ablage im Projekthandbuch Prof. DI Dr. Erich Gams Seite 28/51  Projekthandbuch 1.Teil ‐ Projektauftrag  Basis: Projektabgrenzung und Projektkontextanalyse  Formale Beauftragung zum Start eines Projekts  Nachvollziehbare Zielvereinbarung  Schriftlich  Konstruktion des „Big Project Picture“  Definition von Projektzielen / Nicht‐Zielen, Aufgaben,  Budget, Start, Ende und Projektrollen  Beschreibung des Projektkontext  Unterschriften Projektleiter und Projektauftraggeber Prof. DI Dr. Erich Gams Seite 29/51  Beispiel Prof. DI Dr. Erich Gams Seite 30/51  Projektabgrenzung Dauer  Zeitliche Projektabgrenzung  Projektstarttermin & ‐ereignis Projekt  Projektendtermin & ‐ereignis  Sachliche Projektabgrenzung  Ziele / Nicht‐Ziele Ziel  Hauptaufgaben Ziel  Budget (Erstansatz) Ziel Hauptaufgaben  Soziale Projektabgrenzung  Projektauftraggeber PAG  Projektleiter  Projektteam PL PTM1 PTM2 PTM2 Prof. DI Dr. Erich Gams Seite 31/51  Projektkontext  Zeitlicher Projektkontext  Vorprojektphase ‐ Geschichte  Nachprojektphase ‐ Konsequenzen  Sachlicher Projektkontext  Zusammenhang zu anderen Projekten  Maßnahmen Projekt  Zusammenhang zu Unternehmensstrategien  Sozialer Projektkontext  relevante Umwelten Prof. DI Dr. Erich Gams Seite 32/51  Methoden zum Projektstart (laut PMA)  Projektziele  Projektplanung  Projektkontext Analysen  Objektstrukturplan,  Projektumweltanalyse Betrachtungsobjekte  Projekt und Business Case  Projektstrukturplan  Projektmarketing  Arbeitspaketspezifikationen  Design der Projektorganisation  Projektphasen  Projekttermine  Projektorganigramm  Projektressourcen  Projektrollen  Projektkosten  Projektteamarbeit  Projektfinanzmitteln  Führung in Projekten  Projektrisiken  Kommunikation im Projektstart  Funktionendiagramm  Projektkultur Prof. DI Dr. Erich Gams Seite 33/51  Methoden zum Projektstart 1. Projektziele 4. Projektplanung 2. Projektkontext Analysen  Objektstrukturplan,  Projektumweltanalyse Betrachtungsobjekte  Projektmarketing  Projektstrukturplan 3. Design der Projektorganisation  Arbeitspaketspezifikationen  Projektphasen  Projektorganigramm  Projekttermine  Projektrollen  Projektressourcen  Projektteamarbeit  Projektkosten  Führung in Projekten  Projektfinanzmitteln  Kommunikation im Projektstart  Projektrisiken  Projektkultur  Funktionendiagramm Prof. DI Dr. Erich Gams Seite 34/51  Fragen? Prof. DI Dr. Erich Gams Seite 35  Was ist Projektmanagement?  Anm.: Projektmanagement lässt sich freilich auch bei kleineren Vorhaben mit großem Nutzen einsetzen. Dabei kann man sich freilich mit einem weniger anspruchsvollen Instrumentarium begnügen. Prof. DI Dr. Erich Gams Seite 36/51  Projektmanagement Anforderungsanalyse und Pflichtenheft Prof. DI Dr. Erich Gams htl‐[email protected] Projekte und Projektmanagement Theorie HTL-Wels  Zielsetzung –Warum?  Zielgerichtetes Arbeiten ist notwendig  Ohne Zielsetzung Ergebnis ist zufällig Prof. DI Dr. Erich Gams Seite 2/51  Anforderungen vs. Ziele  Ziel:  ein zu erreichender Zustand, meist in umfassendem Sinn gemeint  Anforderung:  eine zu erreichende Eigenschaft, meist auf Detailebene  Häufig geben Ziele auf einer Ebene (z.B. Geschäftsebene) den Rahmen für Anforderungen auf einer tiefer liegenden Ebene (z.B. System‐ oder Softwareebene) vor. Prof. DI Dr. Erich Gams Seite 3/51  Anforderung (Requirements)  „Eine Bedingung oder Fähigkeit, die von einer Person zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.“  „Eine Bedingung oder Fähigkeit, die eine Software erfüllen oder besitzen muss, um einen Vertrag, eine Norm oder ein anderes, formell bestimmtes Dokument zu erfüllen. (IEEE 610.12‐1990)“ Prof. DI Dr. Erich Gams Seite 4/51  Anforderungsspezifikation (requirements specification) = Die Zusammenstellung aller Anforderungen an eine Software (anderes System).  Synonyme:  Anforderungsdokument, Software Requirements Specification, Pflichtenheft. Prof. DI Dr. Erich Gams Seite 5/51  Requirements Engineering  Das systematische, disziplinierte und quantitativ erfassbare Vorgehen beim Spezifizieren, d.h. Erfassen, Beschreiben und Prüfen von Anforderungen an Software.  Verstehen und Beschreiben, was die Kunden wünschen oder brauchen.  Spezifikation und Verwaltung von Anforderungen mit dem Ziel, das Risiko zu minimieren, dass Software entwickelt wird, welche den Kunden nicht nützt oder gefällt. Prof. DI Dr. Erich Gams Seite 6/51  Ablauf von Kundenprojekten (Jonas Keith) © Prof. DI Dr. Erich Gams 2008. No reproduction without 18.04.2016 7 written permission.  Merkmale einer guten Anforderungsspezifikation  Adäquat – beschreibt das, was der Kunde will bzw. braucht  Vollständig – beschreibt alles, was der Kunde will bzw. braucht  Widerspruchsfrei – sonst ist die Spezifikation nicht realisierbar  Verständlich – für alle Beteiligten, Kunden wie Informatiker  Eindeutig – vermeidet Fehler durch Fehlinterpretationen  Prüfbar – feststellen können, ob das realisierte System die Anforderungen erfüllt  Risikogerecht – Umfang umgekehrt proportional zum Risiko, das man eingehen will Prof. DI Dr. Erich Gams Seite 8/51  Pragmatisch  Was soll das System tun?  Funktionale Anforderungen  Unter welchen Bedingungen soll das System das tun?  Nicht‐Funktionale Anforderungen Prof. DI Dr. Erich Gams Seite 9/51  Klassifikation Prof. DI Dr. Erich Gams Seite 10/51  Anforderungen spezifizieren  Gewinnung (elicitation)  Analyse (analysis)  Dokumentation (documentation)  Prüfung (validation) Prof. DI Dr. Erich Gams Seite 11/51  Informationsquellen  Mit Leuten reden / Leute befragen  Welche Beteiligten (stakeholders) gibt es, die Anforderungen stellen können?  Häufig nicht Individuen, sondern Rollen  Typische Beteiligtenrollen: Endbenutzer, Auftraggeber, Betreiber, Entwickler, Projektleitung,...  Diverse Gesprächs‐ und Befragungstechniken  Prozessabläufe beobachten  Wie wird heute gearbeitet?  Was ist gut und was soll anders werden?  Wer verwendet wo welche Daten?  Unterlagen studieren  Ausschreibungstexte, Visionsdokumente,... Prof. DI Dr. Erich Gams Seite 12/51  Techniken der Informationsbeschaffung  Interviews ‐ Beteiligte werden einzeln oder in Gruppen befragt  Umfragen/Fragebogen ‐ Erfassung von Begriffswelt und Bedürfnissen einer größeren Gruppe von Beteiligten  Beobachtung ‐ Beteiligte bei der Arbeit beobachten  Gemeinsame Arbeitstagungen ‐ Gemeinsame Erarbeitung von Anforderungen in einer Gruppe ausgewählter Beteiligter und Anforderungsingenieure  Prototypen ‐ Gewinnen von Anforderungen durch Erprobung möglicher Lösungen Prof. DI Dr. Erich Gams Seite 13/51  Anforderungen priorisieren  Nicht alle Anforderungen sind gleich wichtig:  Muss‐Anforderungen – unverzichtbar  Soll‐Anforderungen – wichtig, aber bei zu hohen Kosten verzichtbar  Wunsch‐Anforderungen – schön zu haben, aber nicht essenziell  Priorisierung nötig bei  harten Terminen  harten Preisobergrenzen  Beschaffung  Priorisierung nützlich bei  Festlegung von Inhalt und Umfang der Inkremente bei inkrementeller Entwicklung  Releaseplanung bei der Weiterentwicklung bestehender Systeme Software Engineering Prof. DI Dr. Erich Gams Seite 14/51  Inhalt einer Anforderungsspezifikation  Funktionaler Aspekt  Daten: Struktur, Verwendung, Erzeugung, Speicherung, Übertragung, Veränderung  Funktionen: Ausgabe, Verarbeitung, Eingabe von Daten  Verhalten: Sichtbares dynamisches Systemverhalten, Zusammenspiel der Funktionen (untereinander und mit den Daten)  Fehler: Normalfall und Fehlerfälle Prof. DI Dr. Erich Gams Seite 15/51  Inhalt einer Anforderungsspezifikation  Leistungsaspekt  Zeiten „...Reaktionszeit < 0,5 s...“  Mengen „...verwaltet bis zu 10 000 Kunden...“  Raten „...verarbeitet maximal 100 Transaktionen/s...“  Ressourcen „...benötigt 2 GByte Hauptspeicher...“  Genauigkeit„...berechnet auf vier Nachkommastellen genau...“  Wo immer möglich:  ➤ messbare Angaben machen  ➤ Durchschnitts‐ und Extremwerte angeben  Qualitätsaspekt  Geforderte besondere Qualitäten (zum Beispiel Zuverlässigkeit, Benutzbarkeit, Änderbarkeit, Portabilität,...) Prof. DI Dr. Erich Gams Seite 16/51  Inhalt einer Anforderungsspezifikation  Randbedingungsaspekt  Einzuhaltende/zu verwendende Schnittstellen, Plattformen, Nachbarsysteme,...  Normen und Gesetze  Datenschutz, Datensicherung  Kulturelles: zum Beispiel internationale Verständlichkeit von Symbolen  Explizite Vorgaben des Auftraggebers ... Prof. DI Dr. Erich Gams Seite 17/51  Anforderungsspezifikation = Pflichtenheft  Ein Pflichtenheft dokumentiert schriftlich die Ergebnisse der Problemanalyse und dient als Grundlage für das weitere Vorgehen auf beiden Seiten.  Es stellt später die einzige vertragliche Beschreibung des Auftrages dar.  Es sagt der Entwicklungsgruppe möglichst genau, welche Anforderungen gestellt werden und dem Auftraggeber, welche Erwartungen er haben darf.  Das Pflichtenheft ist das Ergebnisdokument einer Anforderungsdefinition. Beschrieben wird was geleistet werden soll, nicht wie die Leistung entsteht. Prof. DI Dr. Erich Gams Seite 18/51  Pflichtenheft  Beispiel vorzeigen Prof. DI Dr. Erich Gams Seite 19/51  Aufgaben  Ticketverwaltung: Pflichtenheft erstellen Prof. DI Dr. Erich Gams Seite 20  Auf die Plätze …. Prof. DI Dr. Erich Gams Seite 21  Fertig ….. Prof. DI Dr. Erich Gams Seite 22 Und ….looooos…. Prof. DI Dr. Erich Gams Seite 23  Aus Kurs Software Engineering in PPM3 Ordner Prof. DI Dr. Erich Gams Seite 24/51  Probleme mit Anforderungen an große Systeme  Auftraggeber, Nutzer, Betreiber etc. sind häufig verschiedene Personen, unterschiedliche Personen haben teilweise widersprüchliche Anforderungen  die Effekte des angestrebten Systems sind schwer vorhersehbar  Anforderungen ändern sich im Laufe der Entwicklungszeit  großer Umfang der Anforderungen  komplexe Interaktion mit anderen Systemen  Erste Aufgabe: Ermittlung der Stakeholder Definition: Jemand der Einfluss auf die Anforderungen hat, da er vom System betroffen ist (Systembetroffener) Prof. DI Dr. Erich Gams Seite 25/51  Zweite Aufgabe: Ermittlung der Ziele des Systems Aus Grundkurs Software Engineering mit UML in PPM3 Prof. DI Dr. Erich Gams Seite 26/51  Checkliste zum Finden von Stakeholdern (1/3) [RS]  Endanwender  Die größte und wichtigste Gruppe, liefert Großteil der fachlichen Ziele  Durchdachtes Auswahlverfahren für die Anwenderrepräsentanten nötig (Vertrauensbasis der gesamten Anwendergruppe berücksichtigen!)  Management des Auftragnehmers (wir)  Gewährleisten die Konformität mit Unternehmenszielen und Strategien, sowie der Unternehmensphilosophie  Sind die Sponsoren!  Käufer des Systems  Wer ist für die Kaufentscheidung verantwortlich?  Liefer‐Vertrags‐Zahlungskonditionen?  Prüfer, Auditoren  sind für Prüfung, Freigabe und Abnahme notwendig,  Entwickler  Entwickler nennen die technologiespezifischen Ziele Prof. DI Dr. Erich Gams Seite 27/51  Checkliste zum Finden von  Wartungs‐ und Servicepersonal Stakeholdern (2/3)  Wartung und Service muss unkompliziert und zügig durchzuführen sein  Wichtig bei hohen Stückzahlen  Produktbeseitiger  Wichtig, wenn ausgeliefertes Produkt nicht nur Software umfasst, Frage der Beseitigung (z.B. Umweltschutz), kann enormen Einfluss auf die Zielsetzung einer Produktentwicklung haben  Schulungs‐ und Trainingspersonal  Liefern konkrete Anforderungen zur Bedienbarkeit, Vermittelbarkeit, Hilfesystem, Dokumentation, Erlernbarkeit,  Marketing und Vertriebsabteilung  Marketing und Vertrieb als interne Repräsentanten der externen Kundenwünsche und der Marktentwicklung Prof. DI Dr. Erich Gams Seite 28/51  Checkliste zum Finden von  Systemschützer Stakeholdern  Stellen Anforderungen zum Schutz vor Fehlverhalten von (3/3) Stakeholdern  Standards und Gesetze  vorhandene und zukünftige Standards/Gesetze berücksichtigen  Projekt‐ und Produktgegner  Die Klasse der Projekt‐ und Produktgegner ‐ vor allem zu Beginn des Projekts wenn möglich mit einbeziehen, sonst drohen Konflikte  Kulturkreis  setzt Rahmenbedingungen, z.B. verwendete Symbolik, Begriffe, …  Meinungsführer und die öffentliche Meinung  beeinflussen oder schreiben Ziele vor, Zielmärkte berücksichtigen Prof. DI Dr. Erich Gams Seite 29/51 Projektmanagement Ziele Prof. DI Dr. Erich Gams htl‐[email protected] Projekte und Projektmanagement Theorie HTL-Wels  Methoden zum Projektstart 1. Projektziele 4. Projektplanung  Objektstrukturplan, 2. Projektkontext Analysen Betrachtungsobjekte  Projektstrukturplan  Projektumweltanalyse  Arbeitspaketspezifikationen  Projektmarketing  Projektphasen 3. Design der Projektorganisation  Projekttermine  Projektorganigramm  Projektressourcen  Projektrollen  Projektkosten  Projektteamarbeit  Projektfinanzmitteln  Führung in Projekten  Projektrisiken  Kommunikation im Projektstart  Funktionendiagramm  Projektkultur Prof. DI Dr. Erich Gams Seite 2/51  Zielsetzung –Warum?  Zielgerichtetes Arbeiten ist notwendig  Ohne Zielsetzung Ergebnis ist zufällig Prof. DI Dr. Erich Gams Seite 3/51  Zieldefinition Projektziel ist es, bis Oktober 2015 ein Haus zu bauen. 4 Prof. Dr. Jürgen Polke | Fachhochschule Vorarlberg  Zielformulierung Prof. DI Dr. Erich Gams Seite 5/51  Zielvereinbarung mit SMART S Spezifisch M Messbar A Ausführbar R Realistisch T Terminierbar Prof. DI Dr. Erich Gams Seite 6/51 © www.VorWissenschaftlicheArbeit.info, 2011  Zielvereinbarung mit SMART S Spezifisch Ziele müssen eindeutig definiert sein (nicht vage, sondern so präzise wie möglich). Prof. DI Dr. Erich Gams Seite 7/51 © www.VorWissenschaftlicheArbeit.info, 2011; Quelle: de.wikipedia.org/wiki/SMART_(Projektmanagement) [Stand: 25.9.2011]  Zielvereinbarung mit SMART M Messbar Ziele müssen messbar sein (Messbarkeitskriterien). Prof. DI Dr. Erich Gams Seite 8/51 © www.VorWissenschaftlicheArbeit.info, 2011; Quelle: de.wikipedia.org/wiki/SMART_(Projektmanagement) [Stand: 25.9.2011]  Zielvereinbarung mit SMART A Ausführbar Ziele müssen von den Empfängern akzeptiert werden/sein (auch: angemessen, attraktiv oder anspruchsvoll) Prof. DI Dr. Erich Gams Seite 9/51 © www.VorWissenschaftlicheArbeit.info, 2011; Quelle: de.wikipedia.org/wiki/SMART_(Projektmanagement) [Stand: 25.9.2011]  Zielvereinbarung mit SMART R Realistisch Ziele müssen möglich sein. Prof. DI Dr. Erich Gams Seite 10/51 © www.VorWissenschaftlicheArbeit.info, 2011; Quelle: de.wikipedia.org/wiki/SMART_(Projektmanagement) [Stand: 25.9.2011]  Forschungsfrage – Zielvereinbarung mit SMART T Terminierbar zu jedem Ziel gehört eine klare Terminvorgabe, bis wann das Ziel erreicht sein muss Prof. DI Dr. Erich Gams Seite 11/51 © www.VorWissenschaftlicheArbeit.info, 2011; Quelle: de.wikipedia.org/wiki/SMART_(Projektmanagement) [Stand: 25.9.2011]  Prioritäten von Projektzielen  Bewährt hat sich in der Praxis die Unterscheidung in  Mussziele  und  Kannziele Prof. DI Dr. Erich Gams Seite 12/51  Wann ist ein Ziel erreicht?  Die Erreichung eines Ziels repräsentiert einen Wert für die Beteiligten und ist mit Kosten verbunden  Zwei Arten von Zielerreichung Prof. DI Dr. Erich Gams Seite 13/51  Messung von Zielen  Ziele messbar formulieren  „Das System muss bei Übersäuerung schnell reagieren.“ ➪ Schlecht, da nur subjektiv beurteilbar  „Reaktionszeit < 0,1s von Erkennung pH‐Wert < 4 bis Stellbefehl an Schließventil.“ ➪ Gut, da objektiv messbar und direktes Maß (Dauer in s) verfügbar Prof. DI Dr. Erich Gams Seite 14/51  Feststellen der Zielerreichung  Prüfen  Bei Software durch Test oder Durchsicht (Review)  bei harten Zielerreichungskriterien  Messen  Objektiv  Abweichungen quantifizierbar  Oft aufwendig  bei weichen Zielerreichungskriterien  Beurteilung  Subjektiv  Problem der Einigung bei mehreren Beteiligten  bei abstrakt / vage formulierten Zielen Prof. DI Dr. Erich Gams Seite 15/51  Probleme mit Anforderungen an große Systeme  Auftraggeber, Nutzer, Betreiber etc.  sind häufig verschiedene Personen  unterschiedliche Personen haben teilweise widersprüchliche Anforderungen  die Effekte des angestrebten Systems sind schwer vorhersehbar  Anforderungen ändern sich im Laufe der Entwicklungszeit  großer Umfang der Anforderungen Prof. DI Dr. Erich Gams Seite 16/51  Probleme mit Anforderungen an große Systeme  Erste Aufgabe: Ermittlung der Stakeholder Definition: Jemand der Einfluss auf die Anforderungen hat, da er vom System betroffen ist (Systembetroffener)  Zweite Aufgabe: Ermittlung der Ziele des Systems Prof. DI Dr. Erich Gams Seite 17/51  Projektziele  Die Projektziele sollen den Sinn eines Projekts erklären und den angestrebten Sollzustand zum Projektende definieren.  Es kann in Hauptziele (Ergebnisziele) und Zusatzziele (Prozessziele) unterschieden werden. Prof. DI Dr. Erich Gams Seite 18/51  Beispiel Prof. DI Dr. Erich Gams Seite 19/51