• Software-Projektmanagement überschneidet sich mit anderen Themengebieten der Softwareentwicklung
  • 
• Sotware-Engineering
  • die Anwendung wissenschaftlich begründeter Prinzipien bei der Entwicklung und Pflege komplexer Softwaresysteme
  • die Entwicklung umfangreicher Softwaresysteme unter Berücksichtigung von Kosten, Terminen und Qualität
  • die Menge aller Methoden, mit denen man Software entwerfen, prüfen, testen, ändern, sanieren, kapseln, verwalten usw. kann
  • umfasst den kompletten Lebenszyklus der Software: Entwicklung, Erhaltung, Betrieb, Migration
• Studie über Projektabschlüsse 2002: 16% erfolgreich, 52% zu hohe Kosten/zu lange Zeit, 32% scheitern
• Projekt: ein Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist (DIN 69901)
  • Beispiele für Bedingungen
    • Zielvorgabe
    • zeitliche/personelle/finanzielle Begrenzungen
    • Abgrenzung ggü. anderer Vorhaben
    • projektspezifische Organisation
    • Komplexität
  • 
    • Unterschiede in den Phasen: durchgeführte Tätigkeiten, unterschiedliche Teamarbeit
  • Qualitätsmaßnahmen sollten in jede Phase eingearbeitet werden
• Projektmanagement: die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mittel für die Abwicklung eines Projekts
  • Aufgaben
    • Projektplanung und -steuerung (PROPS): Zeiten, Kosten und Ressourcenverfolgung
    • Projektführung: Führung der Mitarbeiter, Motivation, Teamarbeit usw.
    • Projektfrühwarnsystem: Verfolgen von Risiken, Beobachten von Umwelt und Trends usw.
  • bei Scrum: Planung und Durchführung werden häufiger durchlaufen → iteratives Vorgehen
• Interaktion im Projekt
  • Bezugspunkt ist immer das (menschliche) Subjekt (Anwender und andere Stakeholder)
  • 
  • wir müssen uns bewusst sein, dass wir lediglich die Projektumwelt für den Anwender/Kunden darstellen und diese seinen Ansprüchen gerecht werden muss
  • zentrale Aufgabe im Projekt ist die Gestaltung der Interaktion mit dem Anwender/Kunden
• Softwareprojekt-Lebenszyklus
  • 

• mangelhafte Kommunikation trägt oft zum Scheitern von Projekten bei → wichtiger Faktor
• menschliche Kommunikation ist subjektiv → Missverständnisse sind häufig
• Definition des Begriffs Kommunikation ist schwierig
• Watzlawik: Man kann nicht nicht kommunizieren.
• Modell Sender/Empfänger
  • Personen übermitteln Botschaften mit enthaltenen Absichten
  • Sender muss Nachricht in ein übermittelbares Zeichensystem codieren
  • Beispiel Gespräch: Sender spricht → Empfänger, der die Sprache kennt, empfängt die Botschaft
• Menschen können nicht exakt kommunizieren, da bei der Decodierung des Gehörten immer auch die subjektiven Erfahrungen eine Rolle spielen
• jeder Mensch hat ein individuelles kognitives System: Erfahrungen, Wissen und Fertigkeiten, die seine Gedanken, Absichten, Gefühle und sein Verhalten steuern
• wechselseitige Interaktion: bei Gesprächen wird jeder Teilnehmer mal Sender und mal Empfänger
  • das Gesagte führt zu Reaktionen des Empfängers, die wiederum Reaktionen beim Sender auslösen
  • nicht nur Worte, sondern auch alle anderen Kommunikationsformen (Gesten, Gesichtsausdruck etc.) rufen Reaktionen hervor und beeinflussen die Antwort
  • die Rückmeldungen sind wiederum Botschaften, deren Idee sich aus dem eigenen kognitiven System und der Idee der ursprünglichen Botschaft des Senders ergbit
  • selbst beim Beginn eines Gesprächs wird man bereits von den subtilen Reaktionen des Angesprochenen beeinflusst
• Kommuniktationsmedien
  • das direkte Gespräch ist nicht die einzige Möglichkeit zu kommunizieren, es gibt auch weitere Kommunikationsmedien
  • Beispiele: Telefon, Internet, E-Mail, Bücher, Briefe, Fernsehen
  • dabei wird die Nachricht des Senders zusätzlich zur Codierung durch sein kognitives System noch einmal durch die medienspezifische Codierung ergänzt
  • mögliche Vorteile: Überwindung von räumlichen Entfernungen, anschaulichere Darstellung von Inhalten
  • Nachteile: mögliche Fehlerquellen
• Störungen bei der Kommunikation: Rauschen und Subjektivität der Wahrnehmung
  • Rauschen: Beispiele Funk (tatsächliches Rauschen), Telefon (fehlende Frequenzen), Brief (unleserliche Schrift)
  • Subjektivität: jede Botschaft wird vom Empfänger subjektiv verändert → Missverständnisse
    • dieser Prozess ist sinnvoll, weil die fremden Informationen leichert verarbeitet werden können, wenn sie an das eigene Gedankengebilde angepasst werden
  • mögliche Ursachen für gestörte Kommunikation
    • die subjektive Verarbeitung aller eingehenden Botschaften durch das individuelle kognitive System des Empfängers
    • eventuelle Einseitigkeit der Kommunikationssituation
    • Besonderheiten oder Beschränkungen des Kanals, über den die Informationen übertragen werden
    • das Rauschen als Unschärfe bei der Übertragung und Wahrnehmung der Informationen
    • das Wechselspiel zwischen den 4 Seiten einer Botschaft (→ 4-Seiten-Modell)
  • die Störungen kann man nie komplett ausschalten, aber versuchen sie zu vermeiden, um Missverständnissen vorzubeugen
• Gespräche
  • Anlässe zur Kommunikation, die in einer bestimmten Situation mit bestimmten Gesprächspartnern über bestimmte Themen tatsächlich stattfinden
  • kommunikativer Austausch von Botschaften zwischen Gesprächspartnern
• das 4-Seiten-Modell von Schulz von Thun hilft,
  • Gespräche leichter zu analysieren und ihren Verlauf zu verstehen
  • auf Fehler im Gespräch hinzuweisen, die für einen unerwünschten Effekt verantwortlich sind
  • auf die psychologischen Vorgänge in einem Gespräch aufmerksam zu machen
  • die Probleme und Risiken in einer Gesprächssituation zu erkennen und zu bewältigen
  • positive Gesprächshaltungen zu beschreiben und zu fördern
  • die Anwendung einzelner Gesprächstechniken im Gesamtzusammenhang des Gesprächs zu fördern
• 4-Seiten-Modell
  • Inhalt: sachliche Informationen und Fakten
    • Beispiele: Vermittlung einer Information, Erklärung einer Aufgabe, Beschreibung eines Problems
    • Sender: Sache verständlich darlegen, sachlich bleiben
    • Empfänger: gut zuhören, versuchen das zu verstehen, was gemeint ist
  • Beziehung: emotionales Verhältnis zwischen Sender und Empfänger
    • wie ist das Klima, die Qualität des Kontakts, die Rollenverteilung?
    • Sender kann dies durch Worte, aber auch durch Tonfall, Mimik und Gestik zeigen
    • Beispiele: Sympathie, Anerkennung, Respekt, Wut, Dominanz, Hass, Ablehnung
    • Signale sind meist nonverbal → häufige Fehlinterpretationen
  • Selbstoffenbarung: gibt Aufschluss über die Person des Senders
    • seine Ziele, Motive, Werte, augenblickliche Befindlichkeit und Persönlichkeit werden offenbart
    • Beispiel: erhöhte Stressbelastung
    • was man sagt und wie man es sagt, enthüllt immer etwas über die eigene Persönlichkeit
  • Appell: Aufforderung an den Gesprächspartner, etwas zu tun
    • Sender fordert den Empfänger auf, etwas zu tun
    • Möglichkeiten: Bitte, Wunsch, Befehl, indirekte Anspielung, subtile Manipulation
• in jedem Gespräch sind prinzipiell alle vier Seiten wirksam
  • der Sender kann (nicht muss) auf jeder Ebene direkt (Sprache) oder indirekt (nonverbal, Untertöne, Anspielungen) senden
  • dem Sender muss nicht immer bewusst sein, was er alles sendet
• Probleme
  • der Empfänger nimmt auf bestimmten Seiten etwas anderes wahr, als der Sender beabsichtigt
  • der Sender erkennt nicht, auf welchen Seiten seine Botschaft interpretiert wird
• erfolgreiche Gesprächsführung setzt voraus, dass alle Gesprächspartner erkennen, welche Bedeutung die vier Ebenen für ihr Gegenüber haben

• häufig ist Zeitmangel ein Problem in Projekten → alle Beteiligten sollten ihr Zeitmanagement im Griff haben
• Berufstätige klagen meist über Zeitnot → Arbeit wird in der Freizeit gemacht, was zu Problemen im Privatleben führt
• es gibt viele Ansätze zum Zeitmanagement
• wichtig ist: Planung und Durchführung werden von Zielen und Prioritäten geleitet
  • ohne Vorausschau greifen die Mittel zu kurz und dienen bestenfalls der Bewältigung der aktuellen Aufgaben
  • Was sind die nächsten Handlungen? Was ist wichtig?
• jeder muss die passenden Methoden und Hilfsmittel für sich selbst finden
• notwendige Rahmenbedingungen
  • Überblick über die Aufgaben und bekannte Prioritäten
  • aktiv Freiraum schaffen, statt nur zu reagieren
  • Stressoren abbauen und vermeiden
  • Zeit für sich selbst, die Familie etc. nehmen anstatt die eigenen Bedürfnisse zu vernachlässigen
  • eigene Ziele definieren und kennen
• Zeit verschaffen
  • Zeitfresser: Telefon, Besprechungen, Besucher, Kleinigkeiten, Unvorhergesehenes, Posteingang, mangelnde Ordnung, nicht Nein sagen
• zielorientiert arbeiten
  • immer fragen: Was will ich mit dieser Tätigkeit erreichen?
  • Vorteile, wenn man seine Ziele kennt
    • Entscheidung zwischen Handlungsalternativen (direkter, effektivster, kürzester, bester Weg)
    • Ziele geben den Tätigkeiten einen Sinn
    • Ziele zu erreichen vermittelt Erfolgserlebnisse
    • Ziele liefern einen Maßstab zur Beurteilung von Leistungen
    • Ziele vermitteln Antrieb und Motivation, etwas zu erreichen
  • realistische Ziele setzen
    • Grobziele: Visionen, Lebensziele, Sinnfragen → geben allgemeine Richtung vor
    • Feinziele: Grobziele müssen in erreichbare kleinere Ziele unterteilt werden, zu hohes Anspruchsniveau führt zu Misserfolgserlebnissen
  • Ziele definieren: Übung 5 Jahre in die Zukunft denken, Ziele und Gefühle ermitteln, 4 realistische Ziele auswählen, Ziele analysieren: Situation, Gedanken, Gefühle, Verhalten
• Prioritäten setzen
  • Ziele müssen priorisiert werden, immer nur an einem Ziel arbeiten
  • mit dem Leichtesten zu beginnen führt meist zu einem schlechten Gewissen, da die wichtigen Sachen liegenbleiben
  • womit anfangen: leicht/schwierig, aufwändig/unaufwändig, wichtig/unwichtig, dringlich/nicht dringlich?
    • Prioritäten hängen von Dringlichkeit und Wichtigkeit ab! → Eisenhower-Matrix (wichtig/dringend)
    • 1-0: besondere Aufmerksamkeit, werder oft vernachlässigt, lassen uns zum Strategen werden, agieren statt reagieren, neue Möglichkeiten, planerische Tätigkeiten, Orientierung an Visionen und Perspektiven
    • 1-1: Krisen, dringende Probleme, wenn man nur noch solche Aufgaben bearbeitet, brennt man aus
    • 0-0: Papierkorb/Ablage, häufig angenehme Tätigkeiten, lenken ab, wenn annehmlich dann in der Pause, ansonten Mut zum Papierkorb
    • 0-1: hinterlistige Zeitfresser, man wird zum kurzfristigen Troubleshooter ohne Ziel, aufgeben, aufschieben oder knapp abhandeln, delegieren
• Aufgaben delegieren
  • Vorteile: zeitliche Entlastung, Aufgaben an Fachleute übertragen, Förderung/Forderung der Mitarbeiter, Fachkenntnisse und Selbstständigkeit der Mitarbeiter werden gestärkt, Motivation der Mitarbeiter wird gestärkt
  • Nutzen: eigene Entlastung, Förderung der Mitarbeiter, Qualität des Ergebnisses
  • Vorgehen
    • Was ist die Aufgabe (Inhalt und Ziel)?
    • Welche Priorität hat die Aufgabe?
    • Wer kann die Aufgabe übernehmen? (muss ich selbst ran? wer hat Zeit/Kompetenz/Motivation? was spricht für/gegen einen Mitarbeiter?)
    • Wie soll die Aufgabe erledigt werden (Qualitätsanforderungen)?
    • Bis wann muss die Aufgabe erledigt sein (Termine)?
  • regelmäßige Kontrolle der Zwischenergebnisse einplanen!
• den Tag strukturieren (Metapher vom Eimer, der mit Steinen, Sand und Wasser gefüllt wird)
  • positiver Start: nicht mit dem Unangenehmsten starten, kleiner Erfolg am Morgen
  • beginnen mit der Planung: was muss ich heute wie und wie lange machen?
  • schriftlich planen: Zeitplanbuch, mehr als nur Kalender: Terminplaner, Tagebuch, Notizzettel, Erinnerungshilfe, Adressregister, Nachschlagewerk, Ideensammler, Kontrollwerkzeug für die Zielerreichung
  • Zeit für aufwändige Aufgaben reservieren: erst die "Steine", dann den Sand, keine Zeit mit kleinen Aufgaben vertrödeln → ungutes Gefühl
  • Prioritäten beachten: 1-0 und 1-1 zuerst, Delegieren einplanen
  • vorausplanen: vor Ende des Arbeitstages den nächsten planen, ggfs. Wochen-/Monats-/Jahresplanung machen
  • nur die Hälfte der Zeit verplanen: verplante Zeit für hochpriore Aufgaben, Rest insb. als Führungsperson für spontane Aufgaben, kreative Prozesse und soziale Verpflichtungen reservieren
  • stille Stunde reservieren: keine Störungen zulassen um hochkonzentriert arbeiten zu können
  • Pausen einplanen: nur mit Pausen bleiben wir leistungsfähig, lange Mittagspause, kurze Kaffeepausen zwischendurch, mal aufstehen, strecken etc.
  • Tagesrhythmus beachten: persönliche Leistungskurve vs. Betriebsamkeitskurve am Arbeitsplatz
  • Ordnung halten: jeden Tag Zeit nehmen um aufzuräumen
  • konsequent sein: Planung hilft nur, wenn sie auch eingehalten wird, wehren gegen inneren Schweinehung, ewiges Aufschieben führt zu schlechtem Gewissen, "alle Dinge sind schwer, bevor sie leicht werden"

• Press1 2001, Marktstudie: Warum IT-Projekte scheitern!
  • Projektmanagement, Implementierung und die Integration bestehender Systeme
  • Kommunikation zwischen Entwicklern und Anwendern
• GULP 2002, Woran scheitern IT-Projekte?
  • unpräzise Vorgaben
  • Starrheit und Dogmatik
  • Kommunikationsprobleme
  • fehlendes Know-how
  • Mangel an Zeit und Geld
  • mangelnde Soft Skills
• procontext.com 2004, Fiscus, Toll Collect, virtueller Arbeitsmarkt-Warum scheitern viele IT-Projekte kläglich?
  • Missmanagement der Anforderungen → Zeit- und Kostenrahmen werden gesprengt
• Computerwoche 2006, IT-Projekte scheitern
  • Zeitrahmen nicht eingehalten, Budget überschritten oder Inhalt des Vorhabens maßgeblich verändert
  • Unternehmen gehen vom Idealfall aus und beziehen negative Einflüsse nicht in ihre Projektplanung mit ein
  • mangelnde Zusammenarbeit zwischen Fach- und IT-Abteilungen
• CIO.de 2007, IT-Projekte in Deutschland sind meist erfolgreich
  • mangelnde Kommunikation mit dem Kunden
  • fehlende Unterstützung durch Management
  • zu große Teams
• InfoWeek 2007, IT-Projekte scheitern oft
  • Schwächen im Projektmanagement
  • veränderte Anforderungen, die im Projektverlauf zutage traten
  • Einschränkungen beim Budget

Das Thema Projektmanagement sollte einen hohen Stellenwert bei der Entwicklung von Software vor allem bei der Teamarbeit einnehmen. Aber auch bei Soloprojekten sollte sich der Entwickler von Anfang an Gedanken über eine sinnvolle Planung und Durchführung seiner Aufgaben machen. Insbesondere auf Grund der zahlreichen Entwicklungsmethoden und Lösungsansätze für die Unterstützung der reinen Programmierung, ist es wichtig, sich gleich zu Beginn für die passende (!) Vorgehensweise zu entscheiden und diese auch im Verlauf des Projekts zu befolgen. Dadurch kann verlorene Arbeitszeit vermieden werden, die zu Lasten eines fehlenden "roten Fadens" ginge, und die Vorteile der jeweiligen Methode kommen zum Tragen.

• Ein Projekt ist ein zeitlich begrenztes Vorhaben zur Schaffung eines einmaligen Produktes, einer Dienstleistung oder eines Ergebnisses. (Projekt: Eine Definition)
• Ein zeitlich befristetes, komplexes Vorhaben, das einen übergreifenden hauptamtlichen Personaleinsatz erfordert. Es sollte deshalb in besonderer Projektorganisation außerhalb der normalen Struktur (= Aufbauorganisation) durchgeführt werden. (Projekt / Projektmanagement)
• Ein Projekt ist ein einmaliges Vorhaben auf Zeit. (Projekt)
• abgrenzbares Einzelvorhaben mit definiertem Anfang und Ende (Ziel), neuartig: Vorstoß an Grenzen des Machbaren, risikoreich (technisch, wirtschaftlich, terminlich), komplex, im Laufe der Abwicklung sich ändernde organisatorische Bedürfnisse, große Bedeutung für Unternehmen / Organisation, Termindruck (Projekte: Definition und Nutzen)
• Ein Projekt ist ein Vorhaben basierend auf der Planung einer Problemlösestrategie, um effektiv und effizient zu einem vorher definierten realistischen Ziel (bzw. Unterziel) innerhalb eines (festgelegten) zeitlichen Rahmens zu gelangen. Projekte werden auch definiert als Vorhaben, die durch eine zeitliche Befristung, eine relative Neuartigkeit und Komplexität sowie durch eine interdisziplinäre Aufgabenstellung gekennzeichnet sind. Die Neuartigkeit dieser Projekte kann sich sowohl auf das Vorgehen bei der Problemlösung als auch auf das gewünschte Ergebnis beziehen. Die Projektarbeit erstreckt sich meist über verschiedene Hierarchieebenen und bindet dabei mehrere Abteilungen ein. Dies führt zu einer hohen Komplexität der Projektarbeit. (ProjektManagement)

Gemeinsamkeiten der Definitionen

• zeitlich begrenzt
• einmalig
• interdisziplinar

Unterschiede

• weit gefasste Definitionen <> sehr spezifische Definitionen
• Komplexität
• Definition von Zielen
• Agilität

• Projektmitarbeiter untereinander
• Projektmitarbeiter und -leiter
• Projektleiter und Kunde
• (optimalerweise) Projektmitarbeiter und Kunde bei konkreten Fragen

• Die Gesamtkosten sollten in der Planungsphase ermittelt (geschätzt) und als Richtlinie für den weiteren Projektverlauf vorgegeben werden.
• Die höchsten Kosten dürften nach Fertigstellung der Software anfallen, also während des Betriebs (durch Wartung, Optimierung etc.).

• Kommunikation sollte möglichst sachlich (inhaltliche Ebene) erfolgen, um missverständliche Aussagen zu vermeiden.
• Man sollte sich stets aller Wirkungen seiner Aussagen bewusst sein, sich in den Gesprächspartner hineinversetzen und überlegen, wie er die Nachrichten auffassen könnte.
• Appelle müssen auch als solche verstanden werden, wenn es um die Delegierung von Aufgaben geht.
• Für eine optimale, offene Kommunikation sollte die Beziehungsebene stets mit einbezogen werden, um die Gespräche nicht zu "kühl" und distanziert wirken zu lassen.
• Hat man das Gefühl, das Gesagte könnte falsch verstanden werden, sollte offen auf einer Metaebene über das Gespräch geredet und die eigenen Ziele verdeutlicht werden.

• Projekte beginnen mit einer Idee (meist um ein Problem zu lösen) eines Entscheiders bzw. Initiators
• meistens sind nicht alle Projektmitarbeiter von Anfang an mit im Boot
  • idealerweise schon, da sich so Fehler und Verzögerungen vermeiden lassen
• gibt es mehrere Projektideen, gilt es zu entscheiden, womit begonnen werden soll → Entscheidungsmatrix
  • Entscheidung anhand gewichteter Kriterien (z.B. Wertschöpfung, Kundennutzen, Notwendigkeit, Spaß, Kosten, Machbarkeit)
  • eigene Kriterien finden und definieren (Was heißt "Spaß"?), um sich ggfs. ggü. anderen (z.B. Bank, neuer Mitarbeiter) rechtfertigen zu können
  • auch der Projektleiter muss für sich selbst bewerten, welches Projekt am besten zu seinen eigenen Zielen passt
  • eine Entscheidungsmatrix kann auch gemeinsam befüllt werden → Konsens über Entscheidung
• eigene Vorüberlegungen zu Beginn des Projekts sparen später Zeit
  • Wer hatte die Idee zum Projekt?
  • Warum wurde das Projekt gestartet?
  • Was soll erreicht werden?
  • Wie soll das Ergebnis aussehen (Form)?
  • Wie wichtig ist das Ergebnis?
  • Wie soll es erreicht werden?
  • Welche besonderen Mittel werden benötigt?
  • Welches sind die Erfolgsfaktoren?
  • Was sind die Risiken?
  • Welche Besonderheiten sind zu beachten?
  • Wer ist wofür verantwortlich?
  • Wer bearbeitet das Projekt?
  • Warum gerade diese Personen?
  • Für wen ist das Projekt wichtig?
  • Wem schadet das Projekt womöglich?
  • Was passiert, wenn es ein schlechtes oder kein Ergebnis gibt?
  • Wie hoch ist das Budget?
  • Wann startet und endet das Projekt?
  • Wovon hängen Start und Ende ab?
  • Ist das Projekt Teil eine größeren Projekts?
  • Sind andere Projekte Teil dieses Projekts?
  • Wie hängen die Projekte zusammen?
  • Wie lässt sich das Projekt abgrenzen?
  • Wie heißt das Projekt?
  • Welche Abkürzung wird für das Projekt verwendet?
  • Gab es schon einmal solch ein Projekt?
• LOP führen, die spätestens beim Erreichen von Meilensteinen mit denen anderer Projektbeteiligter abgeglichen wird
• Arbeitszeiten protokollieren → wichtig für spätere Auswertungen und den eigenen Umgang mit Zeit
• die Vision des Projekts ist enorm wichtig

• komplexe Dienstleistungen erfordern komplexe Kommunikation zwischen Anbieter und Kunden
  • Kunde kennt die Möglichkeiten nicht → Anforderungen können nicht klar formuliert werden → Anbieter entwickelt am Kunden vorbei
• kritische Ausgangspunkte der Kommunikation
  • Auftraggeber irrt sich
    • weil er die Möglichkeiten nicht kennt
    • weil er sich bestimmte Motive nicht eingesteht
  • verdeckte Interessen/Motive und unklare Kommunikation der Anforderungen, Auftraggeber ist auch nur ein Mensch
  • Auftragnehmer interpretiert unklare Anforderungen auf Basis seiner Interessenskonstellationen (kognitives System)
  • die Anforderungen verändern sich im Laufe des Projekts
  • es ist nicht klar, wer der wirkliche Auftraggeber ist
  • Entwickler wird als Buhmann bei Konflikten auf Seiten des Auftraggebers genutzt
  • wenn die neue Technik zu sozialen und organisationalen Veränderungen beim Auftraggeber führt, werden Ängste, Hoffnungen, Befürchtungen und Konflikte sehr wahrscheinlich
• Beratung als angemessene Kommunikationsform
  • Ziele der Beratung
    • konkrete, gültige Verabredungen über offene Anforderungen
    • verdeckte Anforderungen erarbeiten
  • Definition: Art der Kommunikation zwischen Subjekten (oder auch eines Subjekts mit sich selbst), die der Vorbereitung von Handlungen zur Bewältigung praktischer Probleme oder Aufgaben dient
    • Beratung orientiert sich an Kundenzufriedenheit, Zufriedenheit und Leistungsfähigkeit der Projektgruppe, wirtschaftlichem Erfolg
    • bei Scrum übernimmt der Product Owner diese Aufgabe
  • 
    • Grundsätze für alle Beratungen
      • in jeder Beratung kommen sämtliche Formen der Beratung vor
      • Voraussetzung: wahrhaftige Kommunikation miteinander
        • bei Beratung mit sich selbst
          • Subjekt ist eine Person: Berücksichtigung von ins Unterbewusstsein verdrängten Motiven
          • Subjekt ist eine Gruppe: Konflikte, Machtkämpfe usw. aufbrechen
      • damit die Ergebnisse gültig sind: andere Motive als das der sachadäquaten Verständigung (Wahrheit, das bessere Argument zählt) ausschalten
  • Aufgaben des Beraters
    • Gestaltung der Kommunikation
    • Analysieren der Situation (Ist- und Soll-Situation), Moderation der Selbstklärung des Auftraggebers
    • darstellen der alternativen Möglichkeiten (sachlichen Rat geben)
    • sich ergebende Situationsveränderungen durchspielen (Szenarien)
  • all dies muss für alle Betroffenen durchgeführt werden
    • unterscheiden nach Rolle/Funktion
    • unterscheiden nach Individuen, die diese Rollen einnehmen
  • Ziele
    • Messgrößen für die Zielerreichung definieren
    • Entscheidungen treffen (unter Berücksichtigung der einsetzbaren personellen, organisationalen, sachlichen und zeitlichen Ressourcen)
    • Entscheidungen im fortlaufenden Prozess überprüfen (bei Abweichungen wieder beraten)
    • immer auf der Ebene der offenen und auch der verdeckten Anforderungen agieren
    • nicht nur die Einzelpersonen sehen, sondern immer auch ihre Eingebundenheit in Beziehungen zu anderen Personen
  • Möglichkeiten zur Definition von Anforderungen: BPMN und UML
  • Rollen des Beraters
    • Moderator bei der Klärung der Kundenwünsche
    • Auftragnehmer
    • Anbindungen im Projekt und im eigenen Unternehmen
  • genau zu überlegen
    • wer muss in die Beratungskommunikation einbezogen werden
    • auf welche Weise (z.B. Umfragen, Repräsentanten von Gruppen einladen) muss dies geschehen
    • auf welche Weise werden die verschiedenen Ergebnisse zu einem Gesamtbild der Anforderungen zusammengefasst (z.B. Workshop)
  • der Berater benötigt
    • Fachkompetenz (Alternativen kennen usw.)
    • Methodenkompetenz (Gesprächsführung, Moderation, Problemlösung, Präsentation)
    • Sozialkompetenz (praktisch umsetzbares Wissen über die psychosozialen Vorgänge in Organisationen, Einfühlungsvermögen, Konfliktfähigkeit, kommunikative Kompetenz)
  • Konsequenzen
    • Verhandlungsdelegation aufstellen (am besten 2 Personen, bei Bedarf zusätzliche Spezialisten)
    • verschiedene Kommunikationskontexte nutzen (z.B. Bier trinken oder Essen gehen)
    • Gespräche vor- und nachbereiten (am besten wieder zu zweit, da hochkomplexe Aufgabe)
    • Methoden zur Verständigungssicherung nutzen (Rückkopplungen, Visualisierungen)

• mögliches Vorgehensmodell (Beratung ist immer dynamisch): SALVE-TE
  • Start
    • Begrüßung, Vorstellung, Warming-up
    • Vorgehen, Regeln, Erwartungen klären
    • Was wollen wir erreichen? Vision klären
  • Analyse
    • konkrete, detaillierte Beschreibung Ist-Zustand
    • umfassende Informationssammlung und -auswertung
    • zusammenfassende Beschreibung der Anforderungssituation
  • Lösungssammlung
    • kreative Ideensammlung (Brainstorming)
    • ggfs. zurück zum Start
  • Verhandlung
    • Bewertung der Lösungsansätze, Feedback
    • Diskussion und Abstimmung
    • Abgleich kontroverser Interessen, Konfliktmanagement
    • ggfs. zurück zur Lösungssammlung
  • Entscheiden
    • zwischen Alternativen entscheiden
    • Vorgehen vereinbaren
    • Commitment sicherstellen (sonst zurück zu Verhandlung, Lösungssammlung, Analyse oder Start)
    • Verabschiedung von Maßnahmen (wer, wie, was, wann)
  • Transfer
    • Durchführung in der Praxis
  • Ergebnissicherung
    • Verfolgen der Umsetzung in der Praxis
    • Bewertung der Veränderungen
    • Abgleich mit Vereinbarungen der Entscheidung
    • Vergleich mit Situation aus der Analyse
    • Vergleich mit Vision vom Start
    • ggfs. zurück zu einer anderen Stufe

• 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
• 
• 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)
  • 

• 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

• 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?

• 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
  • 
• Teambildung
  • zunächst Herausarbeiten eines Qualifikationsprofils aus der Aufgabenstellung
  • bei kreativen Aufgaben zahlt es sich aus, viele verschiedene Persönlichkeiten ins Team aufzunehmen

• 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

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.

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.

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).

• 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.)

• EDV-Abteilung
  1. Kontakt: (wochen)täglich
  2. Zeitraum: mehrere Jahre (?)
  3. Struktur: Hierarchie abhängig von Positionen (Abteilungsleiter etc.)
  4. Regeln: Stellenbeschreibungen, Anweisungen von Vorgesetzten, Absprachen etc.
  5. Wir-Gefühl: Auftreten als Abteilung
• Studenten SE
  1. Kontakt: Internet, Mail, regelmäßige Treffen vor Ort
  2. Zeitraum: 2 Jahre
  3. Struktur: muss sich noch entwickeln
  4. Regeln: Studienordnung
  5. Wir-Gefühl: Studenten eines Jahrgangs

• 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

• 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)

• 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

• 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.

• Ergebnis der Planung: Projektplan (auch Feinplan, Projektsteuerungsvorgabe)
  • Aufgaben
    • Steuerung des Projekts über die gesamte Laufzeit
    • Fortschritt beobachten und dokumentieren
    • Reaktion auf Risiken und Unvorhergesehenes
  • kann jederzeit an neue Erkenntnisse angepasst werden
  • vor Erstellen des Plans findet das Kick-Off mit allen Projektbeteiligten statt → der Plan kann dann leichter erstellt werden (alle Beteiligten liefern Input)
• Kick-Off (mit allen Teilnehmern)
  • Aufgaben
    • Kennenlernen der Teilnehmer (→ später kurze Kommunikationswege, man kennt sich)
    • einheitliche Informationen über Ziel und Inhalte des Projekts an alle Beteiligten vermitteln
    • allen Beteiligten die eingesetzten Kommunikationswege/-medien näherbringen
    • Verpflichtung der Teilnehmer zur Dokumentation
  • Ziel: Absprachen gemeinsam treffen
    • alle Teilnehmer unterschreiben, dass sie teilgenommen haben und erhalten ein Protokoll
  • Vorbereitung ist sehr wichtig (was mache ich? was erarbeiten wir gemeinsam?)
    • Tagesordnung aufstellen
      • Einführung in Ziele durch Projektleiter
      • Vorstellung aller Beteiligten
      • Zusammenstellen und Verteilen der Aufgaben
      • Kommunikations- und Informationswege festlegen
      • Festlegen der konkreten nächsten Schritte
      • Offene Fragen klären
    • der Projektleiter sollte nicht als Moderator agieren (externer Moderator behält Zeit im Auge und greift bei ausschweifenden Diskussionen ein)
    • Protokollführer und -form festlegen
      • muss auf der Projektmanagementplattform veröffentlich werden
      • sollte wenig Aufwand machen
      • jede Sitzung muss protokolliert und allen Beteiligten zur Verfügung gestellt werden

• Phasen: Vorbereitung, Durchführung, Nachbereitung
• Vorbereitung
  • klar werden über sachlichen Anlass der Besprechung (Sachebene)
    • Informationsinput
    • Informationsoutput
    • Problemlösungen
    • anstehende Entscheidungen
  • psychosoziale Aspekte
    • Stimmung der Gruppe (konfliktgeladen, konstruktiv)
    • kennt sich die Gruppe bereits?
  • Fragestellungen (der Besprechungsleiter muss diese vorab klären)
    • Besprechungsanlass: warum, warum jetzt, fand vorher schon etwas statt, wer hat welches Interesse
    • Besprechungsziele: mess- und prüfbare Ziele formulieren, sekundäre Ziele
    • Zusammensetzung der Gruppe: wer, warum
    • Ziele der Teilnehmer: Ziele, Absichten, Erwartungen der Teilnehmer, wer leistet Widerstand/Unterstützung
    • Vorwissen der Teilnehmer: Kenntnisstand, Hintergründe, Fachwissen, Problemlage
    • formales Ziel der Besprechung: wann ist sie ein Erfolg, was darf nicht passieren, was ist nicht Thema, Erfahrungsaustausch/Problembewusstsein/Lösungsansätze/erste Schritte
    • Hindernisse
    • Vorbereitung der Teilnehmer: wer, wie
    • Konflikte: objektive/subjektive Ziel-/Interessendivergenzen
    • Tabus
    • Konsequenzen
    • Gestaltung der Besprechung: Stil, Methodik, Zeit, Teilnehmer
    • Rahmenbedingungen: Ort, Zeit, Pausen, Raumausstattung
    • Lösungsdruck: schnelle Lösung oder langfristige Verbesserung
    • Entscheidungsbefugnisse
    • Besprechungsstil: kennen die Teilnehmer den Stil
  • wenn die Moderation delegiert wird, sind die Fragen mit dem Verantwortlichen zu klären, insbesondere Anlass, Ergebniserwartung, Tabus, Entscheidungsbefugnis
  • Einladung
    • Bezug, Projekt, Arbeitsbereich
    • Zweck/Grund der Besprechung
    • Einlader
    • Ansprechpartner und Form für Wünsche zur Besprechung
    • Besprechungsziel
    • Verteiler
    • Datum, Uhrzeit, Beginn, Ende
    • Ort und Raum
    • Protokollführer
    • geplante Tagesordnungspunkte einschließlich notwendiger Beiträge
  • Materialien bereitstellen
    • Tische/Stühle
    • Pinnwände/Flipcharts
    • Beamer/OHP
• Durchführung
  • Besprechungen sind Prozesse (vorher andere Situation als nachher)
    • immer sowohl auf der sachlichen als auch auf der psychosozialen Ebene
    • Differenzen zwischen den Ebenen führen zu Problemen
    • Ergebnisse werden meist nur erreicht, wenn Konflikte beigelegt werden und auf der sachlichen Ebene diskutiert wird
  • Protokolle sind meist vorgefertigte Formulare (Ergebnisliste)
    • Qualifizierung des Ergebnisses
      • Feststellung: Tatbestand/Sachverhalt, Auswirkungen stehen fest
      • Beschluss: bindende Einigungen der Teilnehmer, zukunftsbezogen
      • Empfehlung: wenn kein Beschluss möglich oder Externe betroffen sind, zukunftsbezogen
      • Auftrag: verpflichtet zum Handeln (Tun oder Unterlassen), inhaltlich fixiert, zukunftsbezogen, erfordert eine Einigung zwischen Auftraggeber und -nehmer
    • betroffene Teilnehmer
    • Erläuterungen
    • Terminfestlegung
    • sollten sofort nach Ende der Besprechung verteilt werden
• Nachbereitung
  • Reflexion
    • sachlich: Ziele prüf-/messbar erreicht?
    • psychosozial: Klimaänderungen, unberücksichtigte Themen/Beteiligte?
  • Checkliste für Reflexion
    • äußere Bedingungen
      • Besprechungsraum
      • technische Hilfsmittel
      • Besprechungszeit
    • Besprechungsdurchführung
      • Zielorientierung
      • Gesprächsklima
      • dominante/zurückhaltende Teilnehmer
      • Kommunikationsstörungen
      • Konflikte
    • Dokumentation
      • sind alle Ergebnisse fixiert?
      • wurde das Protokoll an alle Teilnehmer verteilt?
      • wurden alle Besprechungsunterlagen verteilt?

• Kern des Projektmanagements, ist immer zu erstellen
• enthält detailliert alle durchzuführenden Aktionen im Projekt
• bei agiler Entwicklung werden die Termine nicht geplant, sondern nur priorisierte Aufgaben
• Ziel ist eine Grundlage zum Zusammenstellen des Teams
• Aufgaben für den Projektleiter
  • Ziele und Teilziele verständlich und treffend formulieren
  • mehrere Möglichkeiten (Alternativen) zur Zielerreichung erarbeiten und gegenüberstellen
  • abschätzen, was zu tun sein wird, wie lange es dauert, wie aufwändig es ist
  • gemeinsam mit dem Team einen Projektplan erarbeiten, der beim Projekstart von der Leitung/dem Team freigegeben wird
  • Form wählen, die das gesamte Projekt begleitet und eine Steuerung ermöglicht
  • ggfs. Software auswählen
• Projektleiter erstellt ersten Plan, stellt das Team auf und überarbeitet mit ihm den Plan
  • es muss nicht beim ersten Versuch die Endfassung entstehen
  • Phantasie spielen lassen, es gibt kein richtig und falsch
  • Projektdeckblatt, -fragebogen und LOP verwenden und abgleichen
  • zuerst ohne Software arbeiten, um die einzelnen Schritte zu verstehen
  • Zielkonflikte separieren, beschreiben und mit Team diskutieren
  • nur das Projekt beschreiben, nicht die Lösung (z.B. Softwarearchitektur) entwickeln
  • einfach gestalten, damit er laufend gepflegt werden kann
    • einfach zu lesen (auch für Externe)
    • einfach zu pflegen (vor allem schnell)
    • einfach weiterzuverwenden (z.B. als Präsentation)
    • als einfaches Projektcontrollinginstrument
• Modellbildung/Modellierung
  • Möglichkeiten: UML, BPMN, Prototyping, agile Entwicklung
  • abhängig von Auftraggeber, Projekt, Kenntnissen des Teams, Vorlieben des Projektleiters, vorhandene Software
• Inhalte
  • 
• Strukturplan
  • Zerlegung des Projekts in eine Struktur und grobe Zeitplanung
  • Darstellung als Strukturdiagramm
  • schafft Übersicht über die größeren Einheiten und ihre Beziehungen untereinander
• Netzplan
  • stellt auch zeitliche und logische Zusammenhänge dar
  • Dauer einer Aufgabe, spätester/frühester Beginn/Ende, Bearbeiter, benötigte Ressourcen
  • kritischer Pfad: Tätigkeiten, die keinerlei Verschiebung erlauben
  • Anordnung nach Wichtigkeit, muss etwas vor etwas anderem fertig sein?
  • hilft, die Einträge im Strukturplan und in der Vorgangsliste zu ordnen
• Meilensteine
  • wichtige Termine innerhalb des Projekts (Start, Ende, Präsentation, Test etc.)
  • meist werden hier wichtige Entscheidungen für den weiteren Projektverlauf getroffen
• die Vorgangsliste
  • erstellen mit Projektmanagementsoftware oder Excel
  • alle wesentlichen Informationen sind in einer Datei verfügbar
  • Nachhaltigkeit: immer alles sofort aufschreiben
  • 
  • einfach zu erstellen, wenn Netzplan/Strukturplan vorhanden
    • Überschriften aus Strukturplan als Trennzeilen
    • Vorgänge aus Netzplan eintragen
    • Meilensteine ergänzen
    • fehlende Spalten füllen, Kommentare bei Unklarheiten erzeugen
• Balkendiagramme können zur Darstellung zeitlicher Zusammenhänge verwendet werden
• finalen Projektplan erstellen
  • einer bereitet vor, alle lesen und arbeiten gemeinsam Änderungen ein (meist höchster Nutzen bei geringem Zeitaufwand)
  • einer bereitet vor, alle lesen und reichen Änderungen zentral ein (meist viele Rückfragen nötig, bei allen bleibt weniger hängen)
  • alle arbeiten gemeinsam am Ergebnis (höchster Nutzen, dauert aber lange)
  • jeder erarbeitet einen Teil und einer macht ein Ganzes daraus (schwierig, da Teilbereiche sehr unterschiedlich ausfallen können)
• empfängergerechte Aufbereitung
  • Hauptempfänger: Auftraggeber (entscheiden über Durchführung) und Team (lesen ihre Aufgaben ab)
  • für Externe wird meist eine gekürzte Version des Plans erstellt
  • der Plan muss sorgfältig erstellt werden, er ist das erste Dokument des Projekts und sollte stellvertretend für die Arbeitsweise im Projekt stehen
  • das Format sollte sich in späteren Berichten wiederfinden, damit man Inhalte 1 zu 1 übernehmen kann (z.B. PowerPoint)
• Unterschiede bei Scrum
  • kein fixierter Projektplan wie im klassischen Projektmanagement
  • Elemente
    • schriftlich formulierte Vision
    • Product Backlog: priorisierte Anforderungsliste
    • Sprint Backlog: Aufgaben für die Sprints
    • Sprint: Zeiteinheit, über die konzentriert gearbeitet wird
    • Burndown Chart: Darstellung des Projektfortschritts als Grafik
    • Produktinkrement: potentiell lieferbares Produkt
    • Rollen: Scrum Master, Product Owner, Team
  • Selbstorganisation und Eigenverantwortung der Projektbeteiligten werden wichtiger
• Kostenschätzung
  • Grundlage können Listen mit häufigen Projektschritten sein
  • mögliche Vorgehensweisen
    • alles selbst machen
    • Berater/externe Programmierer einbinden
    • Experten für Spezialthemen einbinden
    • alles fremd vergeben
  • Vorgehen lohnt sich, wenn wenig Informationen zum Projekt vorliegen oder dem Unternehmen die Kostenzusammenhänge noch nicht klar sind

• 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)

• 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.

• 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. (Strukturierte Programmierung)
• Programme werden modularisiert
• Nur bestimmte Kontrollstrukturen sind erlaubt: Sequenzen, Schleifen, Bedingte Verzweigungen
• Grafisches Hilfsmittel: Struktogramm/Nassi-Shneiderman-Diagramm (Strukturierte Programmierung)
• Vorteile
  • Programmierung von Bibliotheken, Modulen
• Nachteile
  • schwierige Fehlerbehandlung und Datenmodellierung
• Einsatzgebiet: Einfache Programme, prozedurale Programmierung

• 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. (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. (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

• 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. (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.
• 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

• 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. (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. (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 software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project. (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. (Extremely Agile Programming)
• AP is a collection of principles and techniques that try to overcome the inflexibility of the strictly-design-based development cycle. (Agile Programming)
• Vorteile
  • schnelle Ergebnisse, trotzdem folgt das Vorgehen einem klaren Plan mit bestimmten Methoden
• Einsatzgebiete: Webentwicklung (Ruby on Rails), Softwareentwicklung

• 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

• Projektsteuerung
  • der Projektplan im Dauereinsatz: jemand muss ihn ständig pflegen
    • bei langen Projekten wöchentlich aktualisieren, monatlich reporten
    • wichtig um die Projektbeteiligten bei der Stange zu halten (Zeiten eintragen etc.)
    • in kleinen Projekten wird der Projektleiter selbst den Plan pflegen
  • es gibt viele Verfahren zur Fortschrittsermittlung in Softwareprojekten, die sich allerdings in der Praxis nicht bewährt haben
    • bei Scrum: Daily Scrum, Retrospective
• Teamentwicklung
  • Förderung der Teambildung
    • gemeinsam Aufgaben lösen, Not bewältigen, Gegner besiegen
    • Gruppenidentität durch Symbole ausdrücken (Slogan, Namen, Zeichen, Sprache)
    • die Gruppe kann sich meist nicht aus sich selbst heraus verbessern → externe Unterstützung
  • Ziele
    • Probleme lösen, die die Gruppe belasten
    • die Gruppe soll zu einem kooperierenden Team werden
  • Gruppendruck
    • führt dazu, dass im Team eine einhellige Meinung (egal ob falsch oder richtig) herrscht und Zweifler unterdrückt werden
    • Indizien für group-thinking
      • Teammitglieder haben das Gefühl, in der Gruppe unverwundbar zu sein → übertriebener Optimismus, gehen Risiken ein, übersehen Warnzeichen
      • Gruppe bildet plausible Scheinerklärungen um ihre Annahmen nicht hinterfragen zu müssen
      • die Teammitglieder haben einen unhinterfragten Glauben an die moralische Integrität der Gruppe → moralische Folgen von Entscheidungen werden ignoriert
      • die Teammitgliedern haben ein stereotypes Bild von den Leitern gegnerischer Gruppen
        • entweder als starrsinnig und andersdenkend, sodass keine Diskussion möglich ist
        • oder als schwach und inkompetent, sodass keine Entscheidungen möglich sind
      • die Mitglieder machen sich Illusionen über die Einmütigkeit der Gruppe → fast alle Meinungen von Teammitgliedern werden für Mehrheitsmeinungen gehalten
      • die Gruppe erzeugt Druck gegenüber jedem, der Zweifel an den Illusionen der Gruppe hat oder Argumente anzweifelt, die die Mehrheitsentscheidungen stützen
      • Selbstzensur findet in großem Ausmaß statt: die Mitglieder weichen nicht vom Gruppenkonsens ab und spielen ihre eigenen Befürchtungen herunter
      • die Mitglieder schirmen unliebsame Informationen, die die Selbstzufriedenheit der Gruppe beeinträchtigen könnten, von der Gruppe ab
    • Maßnahmen gegen group-thinking
      • der Projektleiter muss Kritik explizit einfordern
      • Projektleiter und einflussreiche Teammitlglieder dürfen nicht zu früh zu erkennen geben, welchen Weg sie bevorzugen
      • bei wichtigen Entscheidungen wird eine Planungsgruppe eingerichtet
      • jedes Gruppenmitglied wird veranlasst, die Entscheidungen auch außerhalb der Gruppe zu diskutieren
      • Experten von außerhalb der Gruppe werden um eine Einschätzung gebeten
      • wenn ein Konsens der Gruppe abzusehen ist, sollte ein advocatus diaboli bestimmt werden
      • die Entscheidungsgruppe trennt sich in zwei Gruppen auf, die getrennt diskutieren und am Ende ihre Ergebnisse vorstellen
      • nach einer Einigung sollte diese immer noch einmal gezielt in Frage gestellt werden
  • Aushandeln von Rollen
    • Rollen betreffen nicht nur die Arbeitsverteilung, sondern auch Macht, Abhängigkeit, Konflikt und Konkurrenz im Team
    • das Aushandeln von Rollen erfordert die Bereitschaft, Strukturen im Team zu verändern
    • die Rolle, über die verhandelt wird, schließt nicht nur die formale Stellenbeschreibung ein, sondern auch informelle Ansichten und Erwartungen, die sich im Laufe der Zeit gebildet haben
      • diese Verfestigungen des Rollenverständnisses führen zu dauerhaften Konflikten
    • Vorgehen
      • Schritt 0: Konfliktpositionen klären
        • emotionale Konfliktlage klären, damit anschließend auf Sachebene verhandelt werden kann
      • Schritt 1: Regeln beschließen
        • es geht nicht um Gefühle, sondern um die Arbeit
        • Erwartungen und Forderungen an das Verhalten anderer müssen schriftlich fixiert werden
        • Forderungen werden nur erfüllt, wenn der Fordernde im Gegenzug auch etwas gibt
        • über diese Leistungen und Gegenleistungen wird verhandelt, die Ergebnisse werden aufgeschrieben
      • Schritt 2: Problemdiagnose
        • jedes Teammitglied muss darüber nachdenken, was sich ändern müsste, damit es produktiver wird
        • Rollenwunschzettel für die anderen Teammitglieder ausfüllen
          • Es würde mir helfen, meine Effektivität zu steigern, wenn Sie Folgendes mehr oder besser tun würden…
          • Es würde mir helfen, meine Effektivität zu steigern, wenn Sie Folgendes weniger oder gar nicht mehr tun würden…
          • Mit folgenden Verhaltensweisen haben Sie mir geholfen, meine Effektivität zu steigern, und ich hoffe, dass Sie sie in Zukunft beibehalten…
        • jede Person bekommt dann alle aus sie bezogenen Wunschzettel und erstellt einen Gesamt-Wunschzettel für sich selbst
        • alle Gesamt-Wunschzettel werden aufgehängt und von der Gruppe begutachtet (Fragen nach dem Was, Warum, Wie sind erlaubt)
      • Schritt 3: Rollen aushandeln
        • zwei ausgewählte Teilnehmer führen den Prozess vor
        • jeder sagt, was er sich am anderen wünscht und wo er ihm entgegenkommen kann
        • Aushandeln: "Wenn Sie X tun, tue ich Y", bis beide zufrieden sind
        • Ergebnis schriftlich fixieren, Sanktionen bei Nichteinhalten festlegen
        • alle Übereinkünfte werden der gesamten Gruppe mitgeteilt
• Frühwarnsystem
  • der Projektplan dient zunächst als Frühwarnsystem, da er alle Aufgaben, Meilensteine, Termine etc. enthält und ständig mit der Realität abgeglichen wird
    • wird der Plan zu umfangreich, ist er nicht mehr pflegbar und wird zum Zeitfresser
  • daher lohnt sich ein zusätzliches Frühwarnsystem
  • Checklisten, die zu wichtigen Terminen geprüft werden
  • Projektteilnehmer bekommen Themen zugewiesen, auf die sie achten sollen
    • Umgangston der Projektbeteiligten
    • Häufigkeit der Zeiterfassung
    • bestimte Qualitätsmerkmale
    • Krankheitstage
    • Themen, mit denen sich die Entscheider befassen
    • Gesetzesänderungen
  • ideal sind wenige Messpunkte, die Details verbergen
    • Beispiel Zeiterfassung deutet auf → Motivation, Arbeitsbelastung, Fortschritt, destruktive Kraft
  • das Projektmanagement beobachtet die Vergangenheit und das Ist → Frühwarnsystem beobachtet die Zukunft
• Führung
  • der Projektleiter hat explizit die Aufgabe, seine Mitarbeiter zu führen
    • einzelne Mitarbeiter fordern und fördern
      • Führen durch Ziele mit Kontrolle, Lob und Tadel
    • die gesamte Gruppe fördern und fordern
      • Konfliktmanagement
    • die Außenbeziehungen pflegen

inkl. Vor- und Nachteile sowie die Art von Projekten, für die sie geeignet sind (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

• 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.

• 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

• Vorbereitung des Abschlusses
  • bevor das Ergebnis an den Kunden geht, sollte eine interne Retrospektive durchgeführt werden
    • Unterlagen, die zu Beginn des Projekts erstellt wurden, und der letzte Stand werden bereitgelegt
  • Fragen
    • Ist das ursprüngliche/zuletzt definierte Ziel erreicht worden?
    • Sind alle Qualitätskriterien erfüllt?
    • Sind alle Vorgaben des Kunden erfüllt?
    • Wurde der Zeitplan eingehalten?
    • Wurde der Kostenplan eingehalten?
    • Entspricht der Bericht den Bedürfnissen des Lesers?
    • weitere projektspezifische Fragen, die während des Projekts gesammelt wurden
  • während der Bearbeitung der Fragen, sollte die Präsentation für den Kunden erarbeitet werden (Argumente festhalten)
  • Chancen der Retrospektive
    • gute Leistungen offensichtlich machen
    • Glücksgefühl aufgrund des erreichten Plans
    • nicht erreichte Ziele begründen (ggü. Kunden und Management)
    • aus Fehlern lernen
    • auch bei abgebrochenen Projekten wichtig, da auch aus den Teilergebnissen gelernt werden kann
• Abschluss
  • jedes Projekt hat zwei definierte Abschlüsse
    • die Übergabe an den Empfänger
      • danach Abnahme durch den Kunden → Rechnung schreiben
      • selbst Checkliste vorbereiten, die der Kunde noch ergänzen kann
    • der interne Projektabschluss
      • Auflösen des Teams, Archivierung der Dokumentation, Abschlussfeier
    • jedem muss klar sein, dass das Projekt nun beendet ist
      • ansonsten frisst es unnütz Zeit, wird unfertig beendet oder verlängert sich selbst immer weiter
  • Übergabe an den Empfänger
    • nicht nur PowerPoint, auch das Produkt muss gezeigt werden
    • je besser die begleitende Dokumentation war, umso weniger Zeit geht für die Abschlussberichte drauf
    • auch beim Abschluss steht der Kunde im Mittelpunkt → er kann uns weiterempfehlen
  • Nachbereitung des Projekts
    • die Auflösung des Teams sollte in einem eigenen Meeting stattfinden
      • Spannungen und Ängsten entgegenwirken
      • Moderator würdigt noch einmal angemessen alle Leistungen
      • dann ggfs. eine Party
• Betrieb
  • der Betrieb ist die entscheidende Phase einer Software
  • Sicherheit ist gerade bei technischen Systemen zu beachten
  • unnötige Arbeitsfolgen (zu viele Klicks) sind zu vermeiden
  • Entwickler könnten durch ein Kennenlernen ihres Produkts im Arbeitsalltag viel für ihr nächstes Produkt lernen
  • auch die Übernahme der Daten in das Nachfolgesystem kann schon von Anfang an eingeplant werden
• Zusammenfassung
  • das Gesamtergebnis hängt davon ab, wie gut die Anforderungen abgedeckt sind
  • eine wichtige Anforderung sind immer die Kosten → Projekte müssen also wirtschaftlich ablaufen
  • auch wichtig ist die Zeit → der Zeitplan muss eingehalten werden und die Zeit des Benutzers geschont werden

• Einsicht in die Notwendigkeit, durch Einsatz von Managementmethoden und -techniken Projektaufgaben sicher und erfolgreich zu bewältigen
• Kenntnis von Konzepten, Verfahren und Instrumenten für eine rationelle Projektabwicklung
• Fähigkeit, ein technisches Projekt effizient und zielgerichtet zu leiten
• Fähigkeit zur Teamarbeit
• Fähigkeit, Mitarbeiter kompetent zu führen
• Was bedeutet Projektmanagement im Umfeld von Software-Engineering und Informationstechnologie?
• Was ist ein Projekt?
• Wie sieht der Projektlebenszyklus eines Software-Projekts aus?
• Welche Interaktionen finden statt?
• Welche Bedeutung hat Kommunikation im Projekt?
• Wie unterscheidet sich erfolgreiche Kommunikation von nicht erfolgreicher?
• Wieso erfordert die Projektidee besondere Aufmerksamkeit?
• Wie wird das Projekt als Ganzes formuliert - und insbesondere das Ergebnis?
• Wie entsteht eine professionelle Präsentation mit der gewünschten Wirkung?
• Wie erkennen Sie die Beziehungsdynamik in Ihrer Gruppe und wie gestalten Sie diese?
• Was beinhaltet eine Vorstudie und welchen Zweck hat sie?
• Wie entsteht der grobe Projektplan?
• Was ist bei Struktur und Prozess von Softwareprojekten zu beachten?
• Inwiefern spielt die Organisationsstruktur eine Rolle bei der Projektgestaltung?
• 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?
• Was ist bei der Projektsteuerung zu beachten?
• Wie ist mit dem Team umzugehen?
• Wozu wird ein Frühwarnsystem benötigt?
• Wie wird es gestaltet?
• Wie wird das Eintreten von Risiken behandelt?
• Was bedeutet Führung in einem Projekt?
• Warum ist ein konkreter Abschluss wichtig?
• Wie wird ein Software-Engineering-Projekt abgeschlossen?
• Was passiert mit dem Projektteam?
• Wieso ist der Betrieb mit zu beachten?
• Was bringt ein reibungsloser Betrieb und kostengünstiges Aussteigen?