Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- se:projektmanagement [2009-04-07 20:47]
stefan
+++ se:projektmanagement [2009-04-13 18:46]
stefan
@@ Zeile 282: / Zeile 282: @@
   * Arbeitszeiten protokollieren -> wichtig für spätere Auswertungen und den eigenen Umgang mit Zeit
   * die Vision des Projekts ist enorm wichtig
 ==== Auftragsklärung durch Beratung ====
   * komplexe Dienstleistungen erfordern komplexe Kommunikation zwischen Anbieter und Kunden
@@ Zeile 342: / Zeile 343: @@
       * Gespräche vor- und nachbereiten (am besten wieder zu zweit, da hochkomplexe Aufgabe)
       * Methoden zur Verständigungssicherung nutzen (Rückkopplungen, Visualisierungen)
+==== Grobplan ====
+  * Machbarkeit prüfen
+    * die Machbarkeit ist in jedem Projekt eine wichtige Frage (reichen Zeit und Ressourcen?)
+    * wichtig ist, die Ressourcen zu betrachten -> Kosten ermitteln (auch die eigenen Arbeitskosten)
+    * nach Scrum ist jedes Projekt machbar, aber erst im Projektverlauf stellt sich heraus, welche Funktionalitäten am Ende zur Verfügung stehen
+    * nach dem ersten Sprint steht schon eine lauffähige Software zur Verfügung (z.B. Datenbank mit rudimentärer Eingabeoberfläche)
+      * der Kunde erhält schnell etwas, womit er arbeiten kann
+      * weitere Verbesserungsmöglichkeiten fallen durch den frühen Einsatz schnell auf
+      * der Kunde wird zufriedengestellt
+      * das Team ist zufrieden (es läuft etwas)
+      * der Product Owner ist zufrieden (ROI -> Halbprodukt kann schon eingesetzt und bezahlt werden)
+  * der Grobplan beginnt nach dem Commitment für das Projekt ("Ja, wir wollen es!")
+  * Hilfsmittel
+    * Fragebogen aus Initiierung
+    * PM-Software
+    * Projektmanagementhandbuch des Unternehmens (-> QM-Abteilung fragen)
+  * Ziel: Weichen stellen, benötigte Teammitglieder, Ressourcen und Qualifikationen festlegen
+    * der Projektleiter muss die wichtigsten Vorbereitungsschritte durchführen und notwendige Entscheidungen bei den Verantwortlichen einholen
+    * nicht: Details klären, Grobplan unterliegt noch Änderungen
+  * Einfluss auf die Planung: Arbeitsweise des Teams (räumlich/zeitlich getrennt?)
+  * der Grobplan ist wie eine Gliederung des Projekts
+  * der Plan ist nur gut, wenn jeder im Team seinen Teil beiträgt (PL führt nur die einzelnen Pläne zusammen)
+  * Vorgaben des Auftraggebers beachten
+    * Prozessmodell
+    * Termine
+  * {{:se:VergleichProzessmodelle.jpg|}}
+  * Inhalte (Basis kann Fragebogen aus Initiierung sein)
+    * Eigenschaften des Projekts (Gegenstand, Funktion, Ziel, Anforderungen, Qualität)
+    * Rollen des Teams
+    * SE-Modell
+    * Kostenschätzung und Budgetrahmen
+    * Zeiten und Meilensteine
+    * Risiken
+  * Grobplanung bei Scrum umfasst vor allem Einteilung in Sprints
+  * Form: Präsentation, wenn er vorgetragen werden muss (z.B. beim Kick-Off), oder Punktliste
+  * Erster Schritt: (vertraulichen) Fragebogen aus Initiierung in veröffentlichbare Form bringen
+  * Projektdeckblatt als Standardformular (schnelle Informationsmöglichkeit über das Projekt)
+    * {{:se:Projektdeckblatt.jpg|}}
+==== Präsentieren ====
+  * Adressaten klären
+    * Wer sind meine Zuhörer und warum kommen sie? Welche Vorlieben haben sie?
+    * Passt das Thema zu meinen Zuhörern?
+    * Passt der Vortragsstil zur Redesituation?
+    * Wie viel Zeit habe ich?
+    * Welche Redesituation ist zu erwarten (Hörerzahl, Raumgröße, Interesse am Thema)? Unterstützt die Raumaufteilung und Sitzordnung meine Pläne und Ziele?
+    * Was passiert vor/nach meinem Vortrag mit den Zuhörern?
+  * Ziele und Inhalte darstellen
+    * (meist zu umfangreiches) Themengebiet eingrenzen und Schwerpunkte wählen
+    * Was will ich erreichen? Was soll der Zuhörer nachher machen, können, wissen?
+    * Was sind meine Kernpunkte, die unbedingt rüberkommen müssen?
+    * zugkräftigen Titel auswählen
+    * Bin ich Feuer und Flamme für mein Thema?
+    * Was will ich selbst mit dem Vortrag erreichen?
+  * den Zuhörernutzen herausstellen
+    * Präsentationen verkaufen ein Thema -> Nutzenorientierung ist ausschlaggebend
+    * Was haben meine Zuhörer davon, wenn sie zuhören?
+    * zu Beginn den Nutzen herausstellen -> kommen die Argumente bei den Zuhörern an? sonst ist der Vortrag "nutzlos"
+  * ein roter Faden führt die Zuhörer
+    * Habe ich überhaupt selbst einen roten Faden?
+    * Wie hoch ist die Chance, dass meine Zuhörer den roten Faden erkennen?
+    * maximal 7 Punkte
+    * Gliederung
+      * Einstieg mit Anmacher und Orientierer
+      * Hauptteil mit den einzelnen Unterpunkten (pfiffige Übergänge, Mini-Einstiege und -Abschlüsse)
+      * Schluss mit Rückgriff auf Einstieg und Gliederung, Ausblick, Spannungsbogen schließen
+    * Sind Einstieg und Schluss gründlich genug geplant und ausformuliert?
+    * Wo sind Knautsch- und Pufferzonen des Vortrags?
+  * Einstieg
+    * 5 Funktionen
+      * Athmosphäre schaffen
+      * eigene Unsicherheit abbauen
+      * orientieren
+      * Regeln vereinbaren
+      * Einstieg ins Thema
+    * Kontakt zu den Zuhörern aufbauen
+    * Anmacher (Fragen, aktuelle Ereignisse, Probleme, unerwartete Aktionen)
+    * frühzeitig Vortragsziel und -botschaft verraten
+    * Grobgliederung auf Dauermedium schreiben
+    * Formelles/Organisatorisches klären
+  * Zuhörer fesseln
+    * mache ich die Zuhörer betroffen?
+    * interaktive Phasen und Aktivphasen einplanen
+    * positive Reaktion auf Zuhörerfragen, wenn auch nur speichern für später
+    * Aufmerksamkeitswarner verwenden
+    * aktive Verben und praktische Beispiele halten wach
+    * Zuschauer namentlich/direkt ansprechen
+    * lebendige Medien verwenden und Medienwechsel
+    * Vorgehen anpassen, wenn Unruhe/Unaufmerksamkeit entsteht (nach dem Grund fragen)
+  * Botschaften verankern
+    * an Bekanntes anknüpfen (Metaphern, Analogien, Symbole, Storys, Beispiele)
+    * Vorgeschichte der Zuschauer einbeziehen: Pausengespräche, Vorredner
+    * Teilzusammenfassungen und Wiederholungen am Ende von Unterpunkten
+  * anregend und verständlich sprechen
+    * akustisch und inhaltlich gut verständlich
+    * langsam sprechen, nicht alle Informationen einfach abladen
+    * Sprechpausen = Denkpausen für die Zuhörer
+    * nicht über Füllwörter und Versprecher aufregen -> das Thema zählt
+    * Artikulation und Modulation mit Kamera prüfen
+    * rhetorische Stilmittel sind Salz in der Suppe
+    * die vier Verständlichmacher
+      * Einfachheit (Wortwahl, Satzbau)
+      * Gliederung und Ordnung (übersichtlich, folgerichtig)
+      * Kürze und Prägnanz (mittlerer Informationsgehalt)
+      * Stimulans (anregende Zusätze)
+  * mit dem ganzen Körper sprechen
+    * Wen schaue ich an? -> Heiliger, Pilzsucher, Manuskriptverehrer, Medienhäftling, Linker/Rechter, Hypnotiseur
+    * Woran halte ich mich fest? -> Saftpresse, Korkenzieher, Adamskostüm, Barriere, Manuskriptknüller
+    * Wie groß ist mein Aktionsraum? -> Pattex-Referent, Wanderprediger
+  * erleben und sehen statt nur hören
+    * Zuhörer, die etwas sehen oder erleben, merken sich mehr
+    * mehrere Sinne ansprechen (Videos, Experimente, Bewegung, Beispiele, Storys, Bilder, Diagramme)
+    * grundsätzliche Modelle des Medieneinsatzes
+      * Fertigprodukt
+      * Halbfertigprodukt
+      * Geburtsmodell
+    * Handwerkszeug des Referenten: OHP, Flipchart, Tafeln, Pinnwände
+    * viele Referenten verwenden zu viele fertig mitgebrachte Folien
+    * wichtige Folien vor Auflegen ankündigen
+    * Handouts sind wichtig für das Publikum
+    * Medienwechsel! (auch die beste Idee nutzt sich ab)
+    * Medienkonkurrenz vermeiden
+  * der Böller am Schluss
+    * nie auf den Schluss verzichten, lieber Zwischenteile weglassen
+    * eine Gesamtzusammenfassung hilft den Zuschauern beim Einsortieren ins Gedächtnis
+    * Ausblicke und Prognosen regen Diskussion und Weiterdenken an
+    * Eingangsgedanken wieder aufgreifen (runder Vortrag)
+    * weiterführende Tipps geben (Adressen, Literatur, Anschlussthemen)
+    * Fragen zulassen
+    * einprägsame, gefühlvolle, kraftvolle Worte wählen
+    * jeder muss erkennen, dass Schluss ist
+  * die Zuhörer in den Dialog bringen
+    * Zuhören macht passiv -> Diskussion einplanen und Feedback einholen
+    * vorher klären, wer die Abschlussdiskussion leiten wird
+    * evtl. erst alle Fragen sammeln und dann beginnen
+    * viele Frager sind mit einer kurzen, prägnanten Antwort zufrieden
+    * nicht zu lange bei einem Frager/einer Frage hängenbleiben
+    * Hintergrund mit Gegenfragen klären
+    * den Fragern und Zuschauern immer danken
+=== Publikumsanalyse ===
+  * Situation der Zuhörer
+    * Wer sind sie und welches Vorwissen bringen sie mit?
+    * Welche Stellung/Funktion/Einflussmöglichkeiten haben sie im Unternehmen?
+    * Wie ist ihr Bezug zum Thema?
+    * Welchen Wissensstand haben sie bezogen auf die Funktion und Zielsetzung der Präsentation?
+    * Welche Ansprüche haben sie an das Niveau der Präsentation?
+  * Interessen der Zuhörer
+    * Was erwarten sie?
+    * An welchen Inhalten/Ergebnissen/Konsequenzen sind sie interessiert?
+    * Welche Erwartungen haben sie an die Inhalte/Ausführlichkeit?
+    * Welche Wiederstände und Argumente könnten aufkommen?
+  * Einstellungen der Zuhörer
+    * Wie betroffen sind sie von der Präsentation?
+    * Welche Einstellungen haben sie zum Präsentationsanlass und dem Ziel des Vortrags?
+    * Welche Einstellungen haben sie zum Vortragenden?
+==== Team aufstellen ====
+  * wenn Menschen in Gruppen zusammenarbeiten entsteht immer eine Beziehungsdynamik
+  * Definition Gruppe/Team
+    * die Mitglieder stehen in irgendeiner Weise zueinander in Kontakt
+    * besteht über eine längere Zeit
+    * hat eine innere Struktur (Rollen, Aufgaben, Verantwortlichkeiten, Hierarchien)
+    * es bestehen (formelle oder informelle) Regeln, die das Handeln der Mitglieder steuern
+    * ein Zusammengehörigkeitsgefühl verbindet die Mitglieder und grenzt sie nach außen ab
+  * Rollen
+    * ein Team ist ein heterogenes Gebilde mit einer eigenen spezifischen Struktur
+    * Teammitglieder bekommen Rollen auf den Leib geschrieben
+    * die Teammitglieder verhalten sich dann entsprechend den Erwartungen des Teams an ihre Rolle
+    * Rollen werden gebildet, weil das Team sie braucht, oder durch persönliche Präferenzen
+    * bei unattraktiven Rollen muss ggfs. jemand in diese Rolle gedrängt werden
+    * die Gruppenerfordernisse erzeugen einen Rollensog, der stärker sein kann als die individuellen Bedürfnisse der Teammitglieder
+      * die Rollen haften meist sehr lang an den Personen
+      * dies kann ungünstig sein, wenn an Rollenverteilungen festgehalten wird, die nicht mehr sinnvoll sind
+      * Aufgaben des Teamleiters (durch offenes Ansprechen der Situation und klare Aufgabenzuweisungen)
+        * völlig starre Rollenfestlegungen verhindern
+        * verfestigte Rollen, die dem Team schaden, auflösen
+  * Lebenszyklus eines Teams
+    * {{:se:LebenszyklusTeam.jpg|}}
+  * Teambildung
+    * zunächst Herausarbeiten eines Qualifikationsprofils aus der Aufgabenstellung
+    * bei kreativen Aufgaben zahlt es sich aus, viele verschiedene Persönlichkeiten ins Team aufzunehmen
+==== Berücksichtigung der Organisationsform ====
+  * jede Organisation ist einmalig, daher ist immer die Organisationsform zu berücksichtigen
+  * der Unternehmenserfolg hängt vom Zusammenspiel der Mitarbeiter ab, nicht von der Organisationsform
+  * laufende Organisationsveränderungsprojekte berücksichtigen
+    * Was ist das Ziel der Veränderung?
+    * eigenes Projektziel und -durchführung auf diese Veränderung anpassen
+    * Team kann dann Erfahrungen in die Abteilungen tragen
+    * Ergebnis passt dann zu zukünftigen Zielen
+  * Organisationsformen
+    * funktional
+    * prozessorientiert
+    * projektorientiert
+  * funktional aufgebaute Unternehmen
+    * Trennung nach Funktionen (Einkauf, Verkauf, Controlling etc.)
+    * Aufteilung in operativen und planende Aspekte (Ford und Taylor)
+    * erkennbar an den üblichen Organigrammen -> strenge Hierarchien
+    * in den einzelnen Abteilungen entstehen unterschiedliche Sichtweisen auf das Unternehmen
+    * zentrales Objekt ist die Abteilung mit detaillierten Stellenbeschreibungen
+    * spezialisierte Fachleute mit wenig Verständnis für Belange anderer Abteilungen, nur höhere Ebenen denken abteilungsübergreifend
+    * untere Ebenen haben wenig Verantwortung
+    * Kommunikation entlang der Hierarchie
+    * Vorteil: der Einzelne hat einen überschaubaren Aufgabenbereich und muss nur ein überschaubares Maß an Informationen beherrschen
+    * Nachteil: Zeitverlust durch Suchen nach an den Stellen nicht vorhanden Informationen
+    * häufig gibt es hier informelle Hierarchien
+    * Projekte
+      * Entscheidungsträger müssen dahinter und für Entscheidungen zur Verfügung stehen
+      * Kompetenzgerangel muss verhindert werden (Projektleiter braucht Weisungsbefugnis -> Widerstand der Linienvorgesetzten)
+      * für Entscheidungen muss viel Zeit eingeplant werden
+      * häufig entscheidet die höchste Führungsebene und die darunterliegenden müssen damit leben
+  * prozessorientiert aufgebaute Unternehmen
+    * Ursprung "zweite Revolution der Automobilindustrie" in den 90er Jahren
+    * in den Mittelpunkt rückten die einzelnen Tätigkeiten, ihre logische und zeitliche Reihenfolge, ihre Steuerung und ihr Wert
+    * Aufteilung der Verantwortung nach Prozessen
+    * funktionale Teams, die für die Prozesse verantwortlich sind
+    * SE-Prozess muss klar von Geschäftsprozess getrennt werden
+    * Ziel ist Erfüllen der Kundenwünsche durch Reduktion auf sachlich notwendige Prozesse und Unterstützung durch Hilfsmittel wie Software
+    * der Kunde (Endkunde, nächster Bearbeiter, Lieferant etc.) steht im Mittelpunkt
+    * geringstmöglicher Ressourceneinsatz, Verschwendungen sollen vermieden werden
+    * häufige Projekte zum Optimieren der wertschöpfenden und Abschaffen der nicht-wertschöpfenden Prozesse
+    * nicht das Optimum für den einzelnen, sondern der reibungslose Fluss steht im Mittelpunkt
+    * die Software muss flexibel sein, wie auch der Prozess
+    * der einzelne Mitarbeiter sieht sich als Bestandteil des Gesamtsystems und hat im eingeschränkten Ausmaß Entscheidungsbefugnis -> erfordert Qualifizierung der Mitarbeiter
+    * aufgrund der hohen Verantwortlichkeit der Mitarbeiter, werden diese auch bei der Softwareentwicklung mitreden wollen
+    * Führungskräfte sind Coaches, die für die optimale Teamzusammenarbeit sorgen
+    * Teamarbeit ist hier bereits etabliert, was zu einem schnelleren Projektstart führt
+    * Mitarbeiter halten direkt Kontakt mit den Kunden, Esakalation nur im Notfall
+    * viele Prozesse lassen sich durch Workflow-Software steuern
+    * zum Erfassen von Prozessen wurde das Supply-Chain-Operations-Reference-model (SCOR) entwickelt
+      * Prozess-Referenz-Modell mit einheitlicher Sprache für alle Partner
+      * umfasst die 5 Aufgabenfelder Planung, Beschaffung, Produktion, Distribution, Rückführung
+      * jedes Aufgabenfeld wird beschrieben durch einen Prozess mit Prozesselementen (Level 1)
+        * es existiert ein Toolkit mit verschiedenen Varianten der Aufgabenfelder
+      * Prozesselemente enthalten Aufgaben (Level 2)
+      * Aufgaben umfassen Tätigkeiten (Level 3)
+      * Tätigkeiten können dann umgesetzt werden (Level 4)
+      * zur Abbildung von Prozessen auf Level 3 und 4 kann z.B. die BPMN und UML verwendet werden
+    * Projekte
+      * beginnen meist mit Betrachtung der entsprechenden Prozesse
+      * Mitarbeiter werden stark einbezogen und haben viele Ideen (sie leben die Prozesse)
+      * der Projektleiter muss die Zusammenarbeit fördern, sorgt für Ressourcen und hält Kontakt mit den Entscheidern
+      * die Führung kann die Ergebnisse eigentlich nur akzeptieren, es sei denn, sie bringt gute Argumente dagegen -> Macht führt zur Störung der Prozesskultur
+      * oft werden auch Externe Partner direkt miteinbezogen
+  * projektorientiert aufgebaute Unternehmen
+    * das zentrale Strukturelement ist das Projekt, das abläuft wie ein Prozess
+    * für jedes Projekt wird eine Institution eingerichtet, die sich nach Beendigung des Projekt wieder auflöst (Beispiele: Baugewerbe, Softwareentwicklung, Beratung)
+    * einige Unternehmen definieren Produkte als Projekte -> Produktlebenszyklus ist Kern der Organisationsstruktur
+    * die Organisation wird nur für die Projektlaufzeit aufgebaut
+    * im Projekt zählt nur die laufende Projektphase und nur kurzfristige Verbesserungen werden eingebracht
+    * längerfristige Verbesserungen greifen erst beim nächsten Projekt -> Wissensmanagement und Dokumentation sind wichtig
+    * bei sehr langfristigen Projekten (z.B. Marsbesiedelung) ist die Dokumentation so durchzuführen, dass sie auch von jemandem verstanden wird, der nur fortschrittlichere Technologie kennt
+    * die Unterscheidung zwischen Projekt und Tagesgeschäft fällt vielen Mitarbeitern schwer, daher:
+      * einen eigenen Projektraum schaffen
+      * gut vorbereitete Unterlagenvorlagen mit Logo des entsprechenden Kunden schaffen
+      * Projektmeetings zu regelmäßigen Zeiten
+      * zügige Projektbearbeitung
+      * laufende Zeiterfassung
+    * häufig werden Standards für die Projektbearbeitung definiert, um die Qualität der Arbeit zu verbessern und Wissen verfügbar zu machen
+    * nach den Projekten werden die Teams neu gemischt, daher wäre es Verschwendung, die gemachten Erfahrungen nicht für alle verfügbar zu machen
+    * jedes Projekt hat eine eigene Hierarchie
+    * mehr Verantwortung und Kompetenzen für Projektbearbeiter führen zu besseren Ergebnissen
+    * Projekte brauchen durchsetzungsstarken Befürworter, der
+      * voll und ganz hinter dem Projekt steht
+      * sich aktiv dafür einsetzt, dass es fristgerecht umgesetzt wird
+      * vieles dazu tut
+    * gute Projektleiter schaffen es vielleicht, ihre Mitarbeiter kurzfristig zu Höchstleistungen anzuspornen
+      * langfristig kann ein Unternehmen aber nur bestehen, wenn Projektmannschaften ausgetauscht werden oder ihnen genügend Zeit zum Abschalten und dann neue Herausforderungen gegeben werden
+    * Projekte
+      * klar trennen zwischen Projekten für Kunden und solchen, die das Unternehmen verbessern sollen
+      * Bearbeiter müssen noch stärker als in anderen Unternehmen die Grenze ziehen können
+      * Trennung z.B. durch stark abweichende CI oder zeitlich zwischen anderen Projekten
+  * bei Mischformen muss die dominante Form ermittelt oder bei Gleichverteilung ein eigenes Verfahren entwickelt werden
 ==== Übungen ====
@@ Zeile 347: / Zeile 624: @@
 Der Projektauftrag sollte in Form einer Beratung geklärt werden. Der Berater muss hierzu über Fachkompetenz verfügen, die er benötigt um dem Kunden Hilfestellung bei der Entscheidung für bestimmte Produkte oder Lösungen geben zu können (Was ist machbar? Was sind die jeweiligen Vor- und Nachteile?). Aber auch Methoden- und Sozialkompetenz ist wichtig, um die korrekten Informationen bzgl. der Wünsche des Kunden erarbeiten zu können. Der Berater steht mit seinen Fähigkeiten dem Kunden zur Seite und hilft ihm bei der exakten Formulierung von Anforderungen (etwa mit Hilfe von UML oder BPMN), um späteren Missverständnissen vorzubeugen. Nur auf Basis einer fundierten Anforderungsanalyse kann ein Projekt erfolgreich durchgeführt werden.
+==== 2.5: Wann ist keine Vorstudie nötig? ====
+Eine Vorstudie ist bei jedem Projekt nötig, um abzuklären, ob dieses überhaupt durchzuführen ist. Je nach Umfang des Projekts kann sich die Vorstudie zwar auf einige kurze Überlegungen beschränken, dennoch ist sie stets Teil des Projektverlaufs.
+==== 2.6: Wie detailliert wird ein Grobplan? ====
+Der Grobplan des Projektverlaufs enthält analog zur Grobgliederung einer Diplomarbeit o.ä. lediglich die zentralen Punkte des Projekts, etwa wichtige Meilensteine. Er dient als Basis für die detaillierte Feinplanung und kann im Extremfall sogar komplett umgeändert werden, wenn sich Anforderungen ändern. Auch bei der Erstellung eines Grobplans ist stets der Umfang des Projekts zu berücksichtigen (bei größeren Projekten wird der Grobplan im Verhältnis zu kleineren natürlich viel oberflächlicher sein).
+==== 2.7: Persönliche Checkliste für Präsentationen ====
+  * Zuhörer- und Situationsanalyse
+  * Angemessener Umfang der zu vermittelnden Informationen
+  * Ziele des Vortrags und Nutzen für Zuhörer klar herausarbeiten (im Fazit noch einmal aufgreifen)
+  * Großen Wert auf einen guten Beginn und Schluss legen
+  * Langsamer sprechen
+  * Zusätzliche Medien einsetzen
+  * Zuhörer aktiv einbinden (direkt ansprechen, Aufgaben lösen lassen etc.)
+==== 2.8: Beispiele für Teams ====
+  * EDV-Abteilung
+    - Kontakt: (wochen)täglich
+    - Zeitraum: mehrere Jahre (?)
+    - Struktur: Hierarchie abhängig von Positionen (Abteilungsleiter etc.)
+    - Regeln: Stellenbeschreibungen, Anweisungen von Vorgesetzten, Absprachen etc.
+    - Wir-Gefühl: Auftreten als Abteilung
+  * Studenten SE
+    - Kontakt: Internet, Mail, regelmäßige Treffen vor Ort
+    - Zeitraum: 2 Jahre
+    - Struktur: muss sich noch entwickeln
+    - Regeln: Studienordnung
+    - Wir-Gefühl: Studenten eines Jahrgangs
+==== 2.9: Team zur Durchführung einer Vorstudie zur Entwicklung einer Projektmanagement-Software aufstellen ====
+  * Softwareentwickler, da letztendlich eine Software zu erstellen ist
+  * Projektleiter/-mitarbeiter, die praktische Erfahrung mit der Durchführung von Projekten haben und Hilfestellung bei der Anforderungsanalyse geben können
+  * Zukünftige Benutzer der Software, da sie am ehesten die Zwischenergebnisse auf Tauglichkeit bewerten können
+==== 2.12: Worauf ist bei der Übernahme von Projekten in funktionalen Unternehmen besonders zu achten? ====
+  * Kompetenzgerangel: Abteilungsleiter <> Projektleiter
+  * Die Projektmitarbeiter sind meist noch im Tagesgeschäft eingespannt
+  * Geschäftsleitung ist unbedingt einzubinden und muss hinter dem Projekt stehen
+  * Mitarbeiter sind evtl. mit der Projektorganisation nicht vertraut (an Abteilungsdenken gewöhnt)
+==== 2.13: Was bringt der Einsatz von Prozessbeschreibungsstandards für die Softwareentwicklung und die Informationstechnologie? ====
+  * Eindeutige Prozessbeschreibungen mit weniger Interpretationsspielraum als bei Freitext
+  * Erstellte Prozessbeschreibungen können evtl. zur automatischen Codegenerierung verwendet werden oder sind als Software lauffähig (z.B. in einer SOA)
+  * Grafische Prozessbeschreibungen sind von den Mitarbeitern meist einfacher und schneller zu verstehen und zu erfassen
+  * Bei der Modellierung von Prozessen mit Hilfe von Prozessbeschreibungssprachen muss von Anfang an eindeutig und umfassend modelliert werden, was die Qualität der Modelle erhöht
+==== 2.14: Was ist die Hauptaufgabe des Projektleiters in prozessorientierten Unternehmen? ====
+  * Der Pojektleiter ist in der bereits gut auf Projektarbeit vorbereiteten prozessorientierten Unternehmenskultur hauptsächlich für die Rahmenbedingungen (z.B. Arbeitsräume, Werkzeuge aber auch Kenntnisse von Methoden) zuständig.
+  * Des Weiteren hält er Kontakt zur übergeordneten Führungsebene und steuert das Projekt in die richtige Richtung.
 ===== Lernziele =====
@@ Zeile 370: / Zeile 696: @@
   * Welche Aufgaben sind bei der Projektplanung im Einzelnen durchzuführen?
   * Wie sind die Kosten eines Projekts abzuschätzen?
+  * Wie organisieren Sie eine Kick-Off-Veranstaltung?
+  * Wie wird jede Besprechung zu einer effektiven Veranstaltung? Was können Sie dazu beitragen?
+  * Was gehört zu einem Projektplan?
+  * Wie können Sie einen Projektplan mit einfachsten Mitteln aufstellen?
+  * Wie werden Kosten und Leistungen abgeschätzt?
 ===== ToDo =====
   * Bilder der Flipcharts anschauen
   * eigene Aufzeichnungen während der Vorlesung anschauen
+  * Beispielfragen durchgehen
+===== Planung =====
+==== Übung 3.1 ====
+Warum ist ein gut moderiertes Kick-Off-Meeting wichtig für das Projekt?
+  * Das Projektteam muss auf das gemeinsame Ziel eingeschworen werden
+  * Die Teilnehmer lernen sich besser kennen
+  * Alle Teilnehmer bedürfen klarer Anweisungen bzgl. ihrer Aufgaben
+  * Die Formalien (Protokolle, Besprechungen etc.) müssen verbindlich festgelegt werden
+  * Die Vorgehensweise wird zusammen erarbeitet (Grobplan durchgehen, Feinplan aufstellen)
+==== Übung 3.3 ====
+Warum stellt man einen Projektplan auf, anstatt einfach loszulegen?
+  * Eine Planung der benötigten Zeit und Ressourcen, sowie der Kosten ist ohne Projektplan nicht möglich.
+  * Ein Projektplan weist jedem Projektmitarbeiter seine Aufgaben zu. Nur so ist eine spätere Kontrolle der erreichten Ziele möglich.
+  * Der Projektplan bietet stets eine gute Übersicht zum aktuellen Stand des Projektes (wenn er gut gepflegt wird) und zeigt eventuelle Engpässe auf.
+  * Nur mit Hilfe eines zentralen Projektplans lassen sich die zu erledigenden Aufgaben der einzelnen Projektmitarbeiter so abstimmen, dass nicht redundant gearbeitet oder etwas vergessen wird.
+  * Auf Basis eines Projektplans, der vom Team gemeinsam erstellt und verabschiedet wird, ist eine optimale Zusammenarbeit ohne Interessens- oder Kompetenzkonflikte möglich.
+==== Übung 3.4 ====
+Mögliche Vorgehensweisen/Hilfsmittel zur Modellierung.
+=== Strukturierte Programmierung ===
+  * Größere Probleme werden in mehreren Schritten in Teilprobleme zerlegt. Verfeinere diese Teilprobleme weiter (eventuell mehrfach), bis nur noch elementare algorithmische Grundstrukturen vorliegen: Top-Down-Vorgehen. ([[http://www.saar.de/~awa/verfein.htm|Strukturierte Programmierung]])
+  * Programme werden modularisiert
+  * Nur bestimmte Kontrollstrukturen sind erlaubt: Sequenzen, Schleifen, Bedingte Verzweigungen
+  * Grafisches Hilfsmittel: Struktogramm/Nassi-Shneiderman-Diagramm ([[http://www.mi.uni-koeln.de/c/mirror/f7alpha1.informatik.fh-muenchen.de/~schieder/programmieren-1-ws96-97/struktpgm.html|Strukturierte Programmierung]])
+  * Vorteile
+    * Programmierung von Bibliotheken, Modulen
+  * Nachteile
+    * schwierige Fehlerbehandlung und Datenmodellierung
+  * Einsatzgebiet: Einfache Programme, prozedurale Programmierung
+=== UML ===
+  * Die Unified Modelling Language ist eine Sprache zur Spezifikation, Visualisierung, Konstruktion und Dokumentation von Modellen für Softwaresysteme, Geschäftsmodelle und andere Nicht-Softwaresysteme. Sie bietet den Entwicklern die Möglichkeit, den Entwurf und die Entwicklung von Softwaremodellen auf einheitlicher Basis zu diskutieren. Die UML wird seit 1998 als Standard angesehen. Sie lag und liegt weiterhin bei der Object Management Group (OMG) zur Standardisierung vor. ([[http://ivs.cs.uni-magdeburg.de/~dumke/UML/index.htm|Unified Modelling Language]])
+  * UML ist keine Methode, sondern definiert eine Notation und Semantik zur Visualisierung, Konstruktion und Dokumentation von Modellen für die Geschäftsprozessmodellierung und für die objektorientierte Softwareentwicklung. ([[http://www.torsten-horn.de/techdocs/uml.htm|UML Unified Modeling Language]])
+  * Grafische Hilfsmittel: Mehrere (13) Diagrammtypen für unterschiedliche Anforderungen
+  * Vorteile
+    * Quasi-Standard, leicht zu verstehen/erlernen
+    * Diagramme können zur Codegenerierung verwendet werden
+  * Nachteile
+    * Nicht alle Anforderungen der Objektorientierung werden abgedeckt (aber durch die leichte Erweiterbarkeit von UML sind eigene Erweiterungen möglich)
+  * Einsatzgebiet: Objektorientierte Programmierung, Entwurf umfangreicher Software
+=== BPMN ===
+  * The Business Process Modeling Notation (BPMN) is a graphical notation that depicts the steps in a business process. BPMN depicts the end to end flow of a business process. The notation has been specifically designed to coordinate the sequence of processes and the messages that flow between different process participants in a related set of activities. ([[http://www.bpmn.org/Documents/FAQ.htm|Business Process Modeling Notation (BPMN) Information]])
+  *  The unified modelling language (UML) takes an object-oriented approach to the modeling of applications, while BPMN takes a process-oriented approach to modelling of systems.
+  * [[http://www.omg.org/docs/dtc/06-02-01.pdf|Spezifikation]]
+  * Vorteile
+    * kann in BPEL umgewandelt werden -> lauffähige Prozesse
+    * was UML für die Objektorientierung, ist BPMN für Prozessorientierung
+  * Einsatzgebiet: Definition und Automatisierung von Geschäftsprozessen, SOA
+=== Rapid Prototyping ===
+  * Das Prototyping ist eine Methode der Softwareentwicklung, die schnell zu ersten Ergebnissen führt und frühzeitiges Feedback bezüglich der Eignung eines Lösungsansatzes ermöglicht. ([[http://de.wikipedia.org/wiki/Prototyping_%28Softwareentwicklung%29|Prototyping (Softwareentwicklung)]])
+  * In rapid prototyping interactive prototypes are developed which can be quickly replaced or changed in line with design feedback. This feedback may be derived from colleagues or users as they work with the prototype to accomplish set tasks. ([[http://www.usabilitynet.org/tools/rapid.htm|Rapid prototyping]])
+  * Vorteile
+    * Schnelle Ergebnisse und Anpassbarkeit während der Erstellung
+  * Nachteile
+    * Gefahr, "unsauber" zu programmieren
+    * oftmals mangelnde Dokumentation, da Konzentration auf Entwicklung
+  * Einsatzgebiet: Maschinenbau, jegliche Programmierung (nicht praktikabel für große Anwendungen)
+=== Agile Programming ===
+  * Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project. ([[http://en.wikipedia.org/wiki/Agile_software_development|Agile software development]])
+  * Although the various agile approaches are different, they have some things in common. They're intended to produce software that can be changed quickly, and all specify short iterations and maximize the amount of time spent face to face. They also focus on team morale. ([[http://www.computerworld.com/softwaretopics/software/appdev/story/0,10801,67950,00.html|Extremely Agile Programming]])
+  * AP is a collection of principles and techniques that try to overcome the inflexibility of the strictly-design-based development cycle. ([[http://www.codeproject.com/gen/design/agileprogramming.asp|Agile Programming]])
+  * Vorteile
+    * schnelle Ergebnisse, trotzdem folgt das Vorgehen einem klaren Plan mit bestimmten Methoden
+  * Einsatzgebiete: Webentwicklung (Ruby on Rails), Softwareentwicklung
+==== Übung 3.6 ====
+  * Entwicklung der Projektmanagementsoftware
+    * Planung
+      * Fachliche Funktionalitäten festlegen
+      * Programmierkonzept festlegen
+        * Zu unterstützende Betriebssysteme festlegen
+        * Programmiersprache auswählen
+        * Groben Aufbau des Programms modellieren
+      * Voraussetzungen klären
+        * Benötigte Ressourcen ermitteln
+        * Benötigte Projektmitarbeiter ermitteln
+    * Implementierung
+      * Programmierung der Software
+      * Erstellen des GUI
+    * Dokumenation erstellen
+      * Anwenderdokumentation erstellen
+      * Technische Dokumentation erstellen
+    * Test
+      * Automatische (Fehler-)Tests durchführen
+      * Fachliche Tests durch Anwender durchführen lassen
+      * Usability-Test durchführen
+      * Endabnahme durchführen
+    * Schulungen
+      * Benutzerschulung durchführen
+      * Administratorenschulung durchführen
+    * Betrieb
+      * Installation der Software beim Kunden
+      * Parametrisierung vor Ort
+==== Übung 4.1 ====
+Möglichkeiten der Fortschrittsermittlung in (Software-)Projekten, ihre Vor- und Nachteile sowie die Art von Projekten, für die sie geeignet sind. ([[http://help.sap.com/printdocu/core/Print46c/de/data/pdf/PSPRG/PSPRG.pdf|SAP Projektfortschritt]])
+  * Start-Ende (Vergleich der geplanten Zeiten)
+    * Vorteile: schnell, einfach
+    * Nachteile: ungenau
+  * Meilensteine (Erreichen der geplanten Meilensteine)
+    * Vorteile: sehr aussagekräftig, objektiv prüfbar
+    * Nachteile: detaillierte Zergliederung der Aufgaben nötig
+  * Funktionsumfang (Implementierungsgrad der benötigten Funktionen)
+    * Vorteile: objektiv messbar, geringer Planungsaufwand
+    * Nachteile: benötigte Zeit je Funktion teils sehr unterschiedlich
+  * Schätzen
+    * Vorteile: jeder Mitarbeiter kann schätzen, liefert schnell einen ersten Richtwert
+    * Nachteile: ungenau, subjektive Werte können erheblich von tatsächlichen abweichen
+==== Übung 4.3 ====
+Wieso wird zusätzlich zum Projektplan noch ein Frühwarnsystem benötigt?
+  * Der Projektplan behandelt das Ist und die Vergangenheit. Für die Zukunft ist das Frühwarnsystem zuständig.
+  * Der Projektplan sollte auf jeden Fall ständig aktualisiert werden, jedoch nicht selbst zum Zeitfaktor werden, was durch eine überbordende Erfassung möglicher Risiken schnell eintreten kann.
+  * Ein Frühwarnsystem, das die Projektmitarbeiter einbezieht, fördert deren Kompetenz und Einsatzbereitschaft und gibt ihnen das Gefühl, mitzubestimmen bzw. eine gewisse Kontrolle zu haben.
+  * Ein separates Frühwarnsystem entlastet den Projektleiter.
+==== Übung 4.5 ====
+Was wirkt motivierend auf Projektmitarbeiter?
+  * Interesse am Themengebiet (etwa Programmierung)
+  * Der messbare Erfolg beim Erreichen von Zielen
+  * Ein methodisch und fachlich fähiger Projektleiter
+  * Die gute Zusammenarbeit im Team
+  * Anerkennung der erbrachten Leistungen
+  * Hoher Grad an Eigenverantwortung

Stefans Wiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge