Project Management

- Zusammenfassung von geplanten und laufenden Projekte in eionem Bereich
- Gemeisname Abhängigkeiten
PP ist zeitlich nicht befristet (Daher kein Projekt)
 

Die Grenze zwischen Projektportfolio-Management und Programm-Mmanagement sind fliessend. Beide werden als Multi-Projekte bezeichnet.

SW-Projekte werden meist als «agiles» Projekt geführt. Sofern es sich nicht um eine SW-Eintwicklung handelt, gehen wir meist sequentiell vor.

Sequentielles Vorgehen

• Die Phasen werden nach Projektbedarf definiert
• Beliebige Ausprägungen (2-Stufig bis n-Stufig)

Wasserfallmodell mit Rücksprungsoption

• Verfeinerung des allgemienen sequentiellen Phasenmodells
• Zusätzlich zur Qualitätskontrolle die Möglichkeit, am Ende einer Projektphase, in die vorhergehende Phase zu gehen, wenn nötig.
• Kann sinnvoll sein, wenn ein Projektergebnis mit vorgegebenem Qualitätsanspruch «um jeden Preis» erzielt werden muss
• Für betriebswirtschaftliche Projekte nicht möglich, da sonst time und budget aufgrund der beliebigen Rücksprungspotion nicht definierbar wäre

• Projekt wird auf einzelne Entwicklungseinheiten herabgebrochen, wenn nötig auch in separat projektierbare Einheiten.
• Jede EE, für die im Vorfeld der Aufwand geschätzt wurde, wird eigenständig umgesetzt
• Kontrolle im Anschluss schafft Erfahrungen, auf deren Basis neu geplant und Zielkorrekturen durchgeführt werden können
• Häufig Scrum als Vorgehensmodell

• Priorisiert die Product Backlog Items
  • Business Value des Produkts im Fokus
  • Releaseplanung: Erreichung des MVP, Einhaltung des Go-Live
• Vertritt die fachliche Auftraggeberseite und die User
• Mitrglied im Scope-Authority-Board
• Kann an einem Sprint-Review teilnehmen und Ergebnisse zurückweisen

• Cross-Functional
  • Alle erforderlichen Skills vorhanden um die Increments zu entwickeln (Software-Engineers, / Programmers, architects, testers, UI Designers, ...)
• Selbstorganisiert
  • Niemand (auch nicht Scrum-Master) sagt dem Team wie sie etwas umzusetzen haben
• Bricht User-Stories in Tasks herab
• Schätzt die Story-Points
• Plant den Sprint
• Daily Scrum
  • Exakt 15 Minuten
• Sprint Review
  • 4 Stunden am Ende des Sprints
  • Showcase of completed work

• Sollte Physisch vorhanden sein, nicht nur durch eine App
• Bedient durch Sprint-Team Mitglieder
• Daily-Scrum-Meeting sollte stehend vor dem Scrum Board geführt werden

• Increment ist die Summe aller Completed Tasks eines Sprints (done)
• Anwendbarkeit muss gewährleistes sein (Definition of done DoD)
• Beispiele DoD
  • Akzeptanzkriterien (FR/NFR)
  • Code Review
  • Unit Tests

Dokumentation Update

• Die erste, minimale aber funktionsfähige Summe von Increments, die bereits einen User-Nutzen erzeugen, genug gross um zu testen oder anzuwenden
• MVP ist eine Zwischenstufe zum angestrebten Produkt

• Von UI zu UX
• UI als Schnittstelle zwischen Mensch und Maschine
  • Schriftgrösse, Zeilenabstand, Farben, ...)
• UX ist die Wahrnehmung/Reaktionen einer Person
  • Emotionen, Vorstellungen, Vorlieben, Wahrehnung, Reaktionen, ...)

• Kombination von klassischen (Sequentiell) und agilem Vorgehen
  • SW-Entwicklung, die in einem Geschäftsprozess eingebettet sind
  • Komplexe SW-Projekte, die mehrere Themen umfassen
  • Programme
    • Wenn Sprints parallel ablaufen, wird ein Projekt zum Programm

Projektantrag oder Projektauftrag -->  oft Synonyme

Ausgalgslage / Problem:

• Bezug zur Wertschöpfung des Unternehmens
• Verständnis des GFeschäftsmodells
• Problkem wirtschaftlich bewerten

Ziel / Mehrwert

• für wen soll ein Mehrwert generiert werden
• Mehrweret muss für mich klar sein
• quantifizierbar oder qualifizierbarer Mehrwert

Von Ausgangslage zum Ziel

• Scope (Mehrwert) auf planbare Einheiten herunterbrechen (meist Wochenscopes)
• Auch im Fall eines agilen Projektplanes mit 2 Wochensprints braucht es Wochenscopes, die Oft ein Wochenversetztes testing haben.

Ressourcen/Kosten

• Haupt-Kostenblock sind meist die Personalkosten
• Überlegen, welche Aktivitäten wir zum Wochenscope dazunehmen
• Zeitaufwand der budgetrelevanten Projektmitarbeiter so genau wie möglich schätzen
• Honorar der MA wird meist auf Tagesbasis abgerechnet

Mitwirkleistung / organisatiorische Auswirkung

• Die erwähnten Aufgaben zur erreichung des Wochenscopes müssen im Projektvertrag benannt werden und den MA zugewiesen. Wir sagen dem Kunden ein Projektergebnis zu, das vertraglich bindend ist.
• Zugriff auf Daten und Räumlichkeiten
• Wichtige Termine und abnahmen

Risikomanagement

• Es genügt nicht, Risiken nur anzusprechen. Mit dem Projektvertrag müssen wir eine Verpflichtung einhalten
• Da Projektvertrag auf den Auftraggeber bindet, à gute Möglichkeit um im Risikofall den AG zu einer Kooperation zu verpflichten.
• Ausgangsbasis à Wochenscopes

Nächste Schritte (falls dem Projektantrag entsprochen wird)

• Projektablauf / Meilensteine
• Termine für Mielensteine festlegen

Vertraglich belastbares Komittment (Unterschrift, Zusage, schlüssiges Handeln)

• Auftragggeber
• Auftragnehmer

Hat Projektantrag / Projektauftrag einen schlüssigen roten Faden?

• Wo wird begonnen?
• Klarer Weg von Problemstellung zur Lösung
• Klar, wer wann wie mitwirkt
• Klar, wann das Projektergebnis abgenommen werden muss (verbindliches Projektergebnis und Abnahmeform)

Konsens zwischen Auftraggeber und Auftragnehmer?

• Alle Punkte, die nicht eindeutig artikuliert sind, wird der Vertragspartner zu seinen gunsten anders verstehen

Wird mit dem Projektbeginn wirklich bis zum vertraglich belastbaren Kommittent des Projektantrags / Projektauftrags gewartet ?

• Auch unternehmensinterne Projekte benötigen eine Verbindlichkeit
• Wenn vor Unterzeichnung begonnen wird, hat der Auftraggeber evtl. Das wirtschaftliche Interesse, die Unterschriftserbringung zu verschleppen

Basis ist die vertragliche Grundlage

• Wir brechen den Scope herab, nicht die Tätigkeiten
• Herabbrechen und wording auf Projekt ausrichten
• Planungs-Periode ist zugleich Management Periode und Berichts-Periode
• Durch die Zuordnung zur Kalenderwoche ergiebt sich die Time zu dem herabgebrochenen scope
• Es wird festgelegt, wer zur erreichung des WochenScopes mitwirkt. Daraus errechnen wir das budget und definieren die Mitwirkungsleistung
• Wir leiten daraus das Risikomanagement ab

Projektplanung ist zentraler Bestandteil der Verantwortung des Projektleiters. Projektleiter darf die verantwortung nicht einem Tool übertragen! Projektplanung ist Bestandteil einer Führungsaufgabe.

• Selbstüberschätzung
• Man weiss nicht, was man eigentlich will
• Unrealistische Leistungszusage in der Vorprojektphase
• Unterschätzen der Komplexität der Aufgabenstellung
• Fehlende Normen und Standards für Analyse und Programmierung
• Mangelnde bzw. fehlende Dokumentation des abzulösenden Systems
• Ungenügend strukturierte Projektorganisation
• Qualifikation der Projektmitarbeiter
• Fehlende Motivation des Projektteams
• Die Illusion des Maurerdreisatzes: Eine Verdoppelung der Projektmitarbeiter führt nicht zu einer Halbierung
  der Projektlaufzeit.
• Mangelnde Standfestigkeit gegenüber dem Erwartungsdruck des Anwenders
• Diskontinuität in der Projektdetaillierung
• Nichteinfrieren der Projektspezifikation
• Nichteinhalten des festgelegten Phasenplans
• Wider den Methodenzwang (zu viel duskutieren statt anwenden)
• Fehlende Software-Werkzeuge
• Mangelhaftes Datendesign
• Unterschätzen der softwaretechnischen Sicherheitsaspekte
• Nicht verbindlich festgelegte Abnahmeprozedere
• Fehlender Durchgriff auf die Organisationsentwicklung

Risiken können in unterschiedlichen Projektphasen eine unterschiedliche Bedeutung haben

Risiken können in unterschiedlichen Projektphasen aber auch unterschiedlich
wahrgenommen werden

Sowohl Fachliche als auch disziplinarische Leitung liegt im Projektbereich. Projekt-MA werden aus Stammorganisation genommen und vollständig in Projekt integriert.Nach beendigung des Projekts wieder zurück an ursprüngliche Aufgabe.

Vorteile: eindeutige Weisungsverhältnisse, klare Verantwortlichkeiten, Verfügbarkeit der Projektleiter, MA identifizieren sich stark mit dem Projektziel

Nachteile: Ausgliederung / Wiedereingliederung aus Stammorganisation

MA nicht vollständig aus der Organisation, aber dennoch mit Projektmitarbeit beauftragt.  MA bleiben der Linie unterstellt. Fachlich aber von zwei Vorgesetzten weisungsabhängig.

Vorteile: Verfügbarkeit von Fachwissen, vorhandenes «Heimatgefühl» der MA

Nachteile: Kompetenzstreitigkeiten, Interessenskonflikte, zu geringe/hohe einbindung der MA

Projektleitung besitzt keine weisungsbefugnis. Weder fachlich noch disziplinarisch, nur sachlich terminlich und kostenmässig koordinierend. PL kann Entscheidungsvorschläge ausarbeiten, entscheiden kann aber nur die Linie

Vorteile: schnelle Einrichtung, hohe Flexibilität

Nachteile: fehlende Kompetenz

Sprache kann helfen, Konflikte zu lösen

• diskussionsfähige Konstruktionen fördern eine Konsensfindung z.B. "Würde dies bedeuten, dass ... ?" z.B. "Möglicherweise könnten wir also ..."
• offene Wünsche fördern eine Konsensfindung
• laute Stimme und monotones Wiederholen von Positionen stehen einer Konsensfindung entgegen
• Killerphrasen, Belehrungen, Ironie und Sarkasmus stehen einer Konsensfindung entgegen

Zuhören kann helfen, Konflikte zu lösen

• nicht bereits nach den ersten Worten des Gesprächspartners eine Gegenantwort vorbereiten und dabei die Ohren auf Durchzug stellen
• die Intermediation (Projektleiter ?) sollte auf ausreichend Zeit achten, um Stellungnahmen aussprechen - und deren Inhalte auch verarbeiten zu können (gegebenenfalls rückfragen)

Gespräche müssen dem Verständnis dienen - nicht dem sich überreden lassen

• Selbstbild vs. Fremdbild (eigene Stärken und Schwächen kennen)
• Respekt und konstruktives Feedback
• Perspektive des Gesprächspartners einnehmen
• Teamfähigkeit
• Emotionale Intelligenz
• Umgang mit Stress
•