Tag Archives: Projektmanagement

KADEV09: Entwicklertag: Juristisch Aktuelles vom Software Engineering – Projektmanagement-Recht

Posted on by

Von offenen Quellen und Wasserfällen – juristisch Aktuelles vom Software Engineering

RA Prof. Dr. Rupert Vogel

PDF Dokument
Ein sehr interessanter und unterhaltsamer Vortrag über rechtliche Aspekte des Urheberrechts und des IT-Projektmanagement wurde von RA Prof. Dr. Rupert Vogel gehalten. Nicht alles habe ich im Detail verstanden, aber dies ist schließlich auch die Aufgabe eines Juristen ;-)

Teil2: Projektmanagement-Recht

Leistungsbeschreibung

Eine wichtige Fragestellung in der Praxis ist: Wer muss definieren, was die Software tun muss? Grundsätzlich muss dies der Kunde/Auftraggeber tun, es besteht jedoch Beratungspflicht des Auftragnehmers. Hier bei ist das Wissensgefälle zwischen Kunde und Softwarehaus maßgeblich.

Hinsichtlich Qualität der zu erbringenden Leistung gilt, dass (falls nichts anderes vereinbart wurde), eine ist mittlere Art & Qualität (Stand der Technik) zu erbringen ist. Es gibt drei grundlegende Qualitätsstufen:

  • gering: Regeln der Technik
  • mittel: Stand der Technik
  • sehr hoch: Stand von Wissenschaft und Technik

TIPP: Verfahrenstandards konkretisiert undVertragsbedingungen prüfen hinsichtlich geforderter Qualitätsstandards

Beweis und Dokumentation

Es wurde hervorgehoben, dass die Dokumentation eine der Hauptpflichten des Softwareherstellers ist. Ein Softwarehaus hat bis zur Abnahme die Beweislast, dass die gelieferte Software dem vereinbarten Qualitätsstandard entspricht. Falls es zu Verzögerungen kommt, sollte man vor Behinderungsanzeigen nicht zurückschrecken: Hier gilt es eine Aktenlage zu schaffen! Gerade bei kritischen Projekten ist es wichtig, eine Claim-Liste zu führen. Bei Verhandlungen im späteren Projektverlauf kann der Projektleiter dann “seinen Stapel” mitbringen. Viele große Auftragnehmer haben eigene Claim-Manager, deren Hauptaufgabe es ist etwaige Mängel zu finden. Damit soll der Preis gedrückt werden.

TIPP: Stärkerer Position durch Protokollierung von Besprechungen, Redaktion von Verträgen, durchgängige Dokumentation der Softwareerstellung und des Projektverlaufs. Etwaige Beweismittel im Prozess (z.B. Mails) frühzeitig und konsequent sammeln.

Abnahme

Eine Abnahme erfolgt nur bei einer Individualentwicklung, markiert rechtlich den Beginn der Gewährleistung und führt zur Zahlungspflicht des Kunden.Laut BGH liegt eine stillschweigende Abnahme nach 6 Monate produktiver Nutzung vor, jedoch nur wenn keine Mängelrügen erhoben wurden.

TIPP: Teilabnahmen anstreben, die Testmodalitäten frühzeitig klären (Vorschlag: Teil Angebot) und hierbeidie Fehlerklassen definieren.

Gewährleistung und Haftung

Ein Softwarehaus muss im Rahmen der Gewährleistung etwaige Mängel in seiner Sotfwarebeseitigen. Ohne individuelle Regelung gilt eine Gewährleistungsfrist von zwei Jahren nach Abnahme. Ein Softwarehaus muss für Schäden haften, ohne individuelle Regelung ist die Haftung unbeschränkt. Produkthaftung und Haftung für Körperschäden können nicht ausgeschlossen werden.

TIPP: Ein Hersteller/Dienstleister sollte die Frist verkürzen auf ein Jahr (per AGB) bzw. wenn möglich noch kürzer im Rahmen individueller Absprachen regeln. Es ist sinnvoll individuelle Haftungsbeschränkung/Ausschluss  im Rahmen eines Individualvertrags festzulegen. Haftungsbegrenzung in AGBs sind kaum wirksam, deshalb muss dies in individuellen Verträgen geschehen.

SW-Hinterlegung

Idee: Die Hinterlegung von Software soll im Falle der Insolvenz des Auftragnehmers den Schaden für den Auftraggeber begrenzen.Das Probleme für Kunden in der Praxis ist meist, dass sie die Vollständigkeit der Sourcen/Artefake nicht einschätzen können. Zudem ist die Insolvenzfestigkeit nicht geklärt. Probleme für SWH ergeben sich aus der Regelung des Herausgabegrundes und -verfahren.

TIPP: Genaue Regelungen, indivduelle Vertragsgestaltung

Fazit

Insgesamt ein sehr spannendender und lehrreicher Vortrag. Viele der angesprochenen Aspekte werden im Projektalltag häufig nicht ausreichend bedacht.

Wer mit agilen Methoden und den damit verbundenen Wertvorstellungen arbeitet, muss jedoch an der einen oder anderen Stelle schlucken. “So” möchte man nicht arbeiten, wird sich der eine oder andere wohl gedacht haben….

KADEV09: Entwicklertag: Juristisch Aktuelles vom Software Engineering – Urheberrecht

Posted on by
Reply

Von offenen Quellen und Wasserfällen – juristisch Aktuelles vom Software Engineering

RA Prof. Dr. Rupert Vogel

PDF Dokument
Ein sehr interessanter und unterhaltsamer Vortrag über rechtliche Aspekte des Urheberrechts und des IT-Projektmanagement wurde von RA Prof. Dr. Rupert Vogel gehalten. Nicht alles habe ich im Detail verstanden, aber dies ist schließlich auch die Aufgabe eines Juristen ;-)

Teil 1: Urheberrecht

Zum Urheberrecht wurden verschiedene Aspekte erläutert:

Zweckübertragungsgrundsatz

Im Zweifelsfall bleiben Nutzungsrechte beim Urheber, er hat viele Rechte. Entweder sind alle Nutzungsrechte (Arten) ganz genau aufgeführt oder es kommt auf den Zweck der Übertragung an. Nur das, was genau im Vertrag als Zweck genannt wird, gilt. Der Einkäufer muss sich sehr genau überlegen, welche Nutzungsarten er erwerben möchte und muss dies vertraglich fixieren.

TIPP: Nutzungsrechte möglichst genau regeln

Nutzungsrecht

Eine Lizenz ist ein Nutzungsrecht, es muss unterschieden werden zwischen einfachem und ausschließlichem Nutzungsrecht

  • Ausschließliches Nutzungsrecht: Nur Lizenznehmer (LN) darf Software (SW) nutzen
  • Einfaches Nutzungsrecht: Lizenzgeber (LG) darf Nutzung weiteren LN einräumen

Im Grundsatz wird immer ein einfaches Nutzungsrecht erworben, der LG darf beispielsweise Anpassungen (finanziert durch ersten LN) an einen zweiten LN veräußern.

TIPP: Vorsicht bei Einräumung ausschließlicher Lizenzen

Erschöpfungsgrundsatz

Konkrete SW-Kopie darf 1:1 weitergegeben werden, das Verbreitungsrecht erlischt jedoch sobald Original/Kopie veräußert wurde. Dieser Grundsatz gilt im Gebiet der EU / europäischer Wirtschaftsraum; nicht jedoch international.In der aktuelle Diskussion um Gebrauchtsoftware wird darüber debattiert, ob eine Online-Übertragung einer Übertragung mit Datenträger entspricht? Eine Fragestellung aus der Praxis ist beispielsweise, ob Kontingente zum Teil weiter verkauft werden dürfen.

TIPP: Software auf Datenträger bestellen

Verwertungsrechte bei festen und freigen Mitarbeitern

In der EU gilt, dass der Mitarbeiter (MA) Urheber bleibt, dies ist in den USA anders.Ein fest angestellter MA überträgt jedoch Rechte an SW automatisch an Arbeitgeber (AG). Für Freiberufler gilt: Es gibt keinen automatischen Rechtsübergang! Übertragung der Nutzungsrechte muss genau geregelt werden, was oft nicht geschieht. Freie Mitarbeiter haben deshalb in der Praxis sehr häufig Ansprüche, nutzen diese jedoch sehr selten. Verjährungsfrist für Ablauf dieser Ansprüche beträgt 30 Jahre, es gibt keinen gutgläubigen Erwerb bei Nutzungsrechte

Beispiel: Freier Mitarbeiter entwickelt Schnittstelle für Projekt P1. Schnittstelle fließt in Produkt ein, Produkt wird Marktführer. Freier hat nun Recht von allen Lizenznehmern nachträglich Lizenzgebühren für seine Schnittstelle zu fordern!

Dies kann potentiell eine sehr große Einnahmequelle für Freie sein!

TIPP:

  • Nutzungsrechte sehr genau regeln beim Einsatz von freien Mitarbeitern
  • Als freier Mitarbeiter sollte man seine Ansprüche prüfen (lassen)

Open Source Software (OSS)

Die Open Source Lizenzen haben unterschiedliche Effekte. Ein Ausschluss von Haftung und Gewährleistung ist jedoch immer unwirksam.

TIPP: Überprüfung, welche OSS eingesetzt werden und welche Lizenzen damit verbunden sind. Die Lizenzen dann hinsichtlich etwaiger juristischer Probleme bewerten (lassen).

Nach dem Überblick über einige Themen aus dem Urheberrecht wurden noch auf Aspekte aus dem Projektmanagement eingegangen. Leider war die Zeit bereits weit fortgeschritten und deshalb wurden viele interessanten Punkte nur sehr flüchtig besprochen.

Im zweiten Teil der Zusammenfassung geht es um Recht beim Projektmanagement …

KADEV09: Entwicklertag: Agil & PMBOK

Posted on by
3

Agil &PMBOK-konform – das passt doch nicht zusammen, oder doch?

Stefan G. Gfrörer (PRODYNA AG)
PDF Dokument

Der Vortrag stellt die These vor, dass agiles und traditionelles Projektmanagement teilweise vereinbar sind, wobei im Vortrag der Fokus auf Vorstellung des traditionellen Projektmanagements gelegt wurde. Grund hierfür war, dass sich die meisten Anwesenden sehr gut mit agilen Methoden auskennen, weniger gut  mit dem traditionellen Projektmanagement.
Stefan Gfrörer hat als CSM und PMP sowohl Erfahrung mit agilen Methoden als auch mit dem traditionellen Projektmanagementansatz.

PMBOK = Project Management Body of Knowledge

  • Sammlung von Standards für das Projektmanagement
  • Inhalte ändern sich mit der Zeit, genau wie sich das Projektmanagement über die Zeit verändert
  • Projektmanagement für verschiedene Einsatzzwecke – nicht nur IT
  • PMBOK Guide ist nur ein Auszug der “good practice” beschreibt
  • PMBOK ist kein Prozessmodell
  • PMBOK != Wasserfall

Einen kurzen Überblick über den PMBOK findet ihr bei Wikipedia.

Herausgegeben wird das PMBOK von der PMI (Project Management Institute) , dem weltweit größten Verband für Projektmanagement, welches auch Zertifikate wie das PMP (Project Management Professional) vergibt.

ANMERKUNG: In Deutschland ist die IPMA (International Project Management Association) mit der GPM (Gesellschaft für Projektmanagement) als deutschem Chapter populärer als das PMI.

Es wurde auch der PSP (Projektstrukturplan, engl. WSB/Work Breakdown Structure) als das zentrale Steuerungsmittel im Projektmanagement vorgestellt. Hat dieser einen konzeptionellen Fehler, so zieht sich dieser durch alle abgeleiteten Artefakte.

Nach dem Überblick über PMI und PMBOK folgte ein kurzer Überblick über agile Methoden / Scrum.

Schließlich wurde dargestellt, dass aus Kundensicht das traditionelle Projektmanagement zunächst eine bessere Verlässlichkeit mit seinen GANTT-Charts und anderen Artefakten darstellt, während agile Methoden mit “schwammigen Wolken” arbeiten. Ein unerfahrener Kunde neigt in diesem Fall dazu, dem traditionellem Projektmanagement mehr zu vertrauen als dem agilen Vorgehen.

Auf den folgenden Folien wurde schließlich aufgeführt, wie sich agile Praktiken bestimmten Prozessgruppen im traditionellen Projektmanagement zuordnen lassen. Anhand verschiedener Parallelen aufgezeigt: Scrum und PMBOK passen zusammen.

Es wurden einige Vorschläge gemacht, wie eine Integration von Scrum & PMBOK aussehen könnte:

  • PSP nutzen als Ausgangsbasis, dann davon Feature-Bundles und Arbeitspakete ableiten
  • Planung mittels Projektplan bis auf Team-Ebene, Teams dann für die Details verantwortlich
  • Scoping der Fetaures
  • enge Zusammenarbeit Team <-> PO
  • gutes Changes Management
  • PO + PL müssen Scope des Projektes managen

Mein Fazit: Wenn ich PMBOK-Wissen habe, dann kann ich Themen bewusst berücksichtigen und kompatibel zur Scrum-Welt berücksichtigen.
Meine grundlegende Kritik an Scrum:  Starke Verallgemeinerung in bestimmten Bereichen:  Der PO soll alle “geschäftlichen Aspekte” handhaben, der ScrumMaster soll die Prozesse immer durchsetzen können.

Das Publikum war in dieser Hinsicht geteilt: Es wurde sogar darauf hingewiesen, dass das traditionelle Projektmanagement noch nie funktioniert hat und es gefährlich ist, die agilen Vorgehensweisen mit Ideen/Artefakten aus dem raditionellen Projektmanagement zu verschmutzen.

Meine Meinung dazu: Natürlich gilt, dass gerade durch die Reduzierung der komplexen Zusammenhänge durch Scrum die Möglichkeit sich richtig zu fokussieren verbessert wird. Es gilt also abzuwägen und zu entscheiden, was man tun möchte und was eben nicht.

Kombination von agien Methoden & traditionellem Projektmanagement wird intensiv diskutiert …

Die Kombination von agilen Methoden und traditionellem Projektmanagement wird zunehmend in der Projektmanagement-Community diskutiert, eine sehr interessante Reihe an Postings hierzu wurde von Andreas Heilwagen in seinem Blog veröffentlicht:

… weitere Themen findet ihr, indem ihr nach “PMBOK” in seinem Blog sucht.

Scrum User Group Karlsruhe – Multiprojektmanagement und Scrum

Posted on by
Reply

Eine kleine Erinnerung:

Das nächste Treffen der Scrum User Group Karlsruhe findet am 3. Juni im Restaurant Großer Kurfürst (Sophienstraße 80, 76135 Karlsruhe) ab 20:00 Uhr statt.

Diesmal referiert Heiko darüber, wie Multiprojektmanagement und Scrum zusammen passen. Heiko leidet als PO eines zentralen Teams unter extrem vielen (parallelen) Projektanfragen und kann sicherlich den einen oder anderen Tipp geben wie man eine solche Situation übersteht ;-)

Mal sehen, ob ich etwas Zeit habe mich für die Diskussion ordentlich vorzubereiten. Die typische Literatur zu Scrum sagt ja letztendlich “Multiprojektmanagement ist böse”, während der typische Vorgesetzt sagt “das müssen wir unbedingt auch noch machen!”. Beim Multiprojektmanagement spielen auch immer eine Vielzahl von externen Terminen und Projektzwänge eine Rolle und eine Optimierung auf Produktivität hilft nicht immer.

Beispiel aus der Fußballwelt: Dem KSC hat es nicht geholfen in den letzten Spielen schön produktiv gewesen zu sein. Er hätte die Tore besser verteilen müssen – jetzt ist eben 2. Liga angesagt. Wachablösung durch den SC Freiburg klappt aber wenigstens ;-)

Anmeldung wie üblich via Xing, Gäste sind jederzeit willkommen ;-)

Symptome für Projekte die scheitern werden

Posted on by
5

Im Blog PM Hut gibt es einen interessanten Artikel von Satya Narayan Dash, in dem er einige Symptome beschreibt, wie man erkennen kann, ob ein Projekt zum Scheitern verurteilt ist.

Over 50% of IT projects fail. Most of the time, there are a number of early signs that the project will fail. We will discuss some of the symptoms for a project doomed to fail.

Though the concepts here are in more in sync with IT projects, the applicability of them is universal.

via 11 Signs That Your Project Will Fail – Part I – PM Hut //11 Signs That Your Project Will Fail – Part II – PM Hut .

Es werden folgende 11 Symptome benannt:

  • Es existiert keine echte Projektbeauftragung/-zielsetzung (no project charter): Es ist nicht klar, was die Ziele des Projektes sind und wie/ob das Projekt begonnen hat. Egal, wird fangen trotzdem an und ignorieren die (fehlende) Beauftragung. “Wer hatte eigentlich vor zwei Jahren die (dumme) Idee dieses Projekt zu starten?!”.
  • Keine Unterstützung durch das Top-Management (lack of senior management involvment):  Es interessiert die Entscheidungsträger nicht, was in dem Projekt passiert. In Folge werden Entscheidungen nicht gefällt bzw. verschleppt. Projekt findet sich in einer Sackgasse, es ist nicht klar, wie Projekte zu priorisieren sind. Keiner weiss, was das Top-Management genau will, da dieses nie Zeit investiert dies zu erklären. Ergebnis ist vorprogrammiert.
  • Unerfahrene und/oder überhebliche Projektleiter (unexperienced or ego-driven project managers): Entweder gibt es keine formale (und gute) Ausbildung oder die Projektleiter sind ob dieser Ausbildung überheblich. Oder die Person des Projektleiters leidet ganz einfach an unbegründeter und unheilbarer Überheblichkeit (“hier komme ich, Platz da, mein Projekt als erstes, meine Meinung zählt”).
  • Zentrale Projektmitarbeiter sind überlastet (over-allocated key team members):  Überlastung von Schlüsselpersonen wird ignoriert und im Effekt stoppt das ganze Projekt. Ist aber egal, sollen die Jungs doch die Wochenenden durcharbeiten, oder?
  • Risiken werden nicht aktiv bearbeitet (no risk management plan): Risiken? Nein, Risiken gibts hier nicht ;-)
  • Keinen Prozess für Änderungsmanagement (no change management plan): Änderungen? Sowas darf nicht vorkommen!
  • Fehlendes technisches Wissen im Projektteam (lack of technical expertise in the team): Jaja, können wir alles. Ist doch keine Raketenwissenschaft, da lest ihr euch ein. Jemand muss der erste sein (und Aufbau des Wissens immer schön auf das Projekt buchen).
  • Umfang des Projektes nicht formal geklärt (not having a formally accepted project scope): Jeder interpretiert seine persönliche Zielsetzung in das Projekt hinein, keine weiss wann das Projekt abgeschlossen ist. Umfang des Projektes wird durch das Top-Management schneller geändert, als dass die Änderungen dokumentiert werden können.
  • Projektplan ist nicht aktuell (not having an properly updated project plan): Keiner weiss, was der Plan ist und wo das Projekt steht. Schön.
  • Qualitätssicherung vernachlässigt (no quality management plan): Keiner kennt die Qualitätskriterien und die Anwendung geht mit ein paar “husch-husch” Tests in Produktion. Eine Planung und ein Management von Qualitätskriterien wird nicht konsequent durchgeführt.
  • Große Widersprüche bei der Projektinitiierung (problems in early take-off): In der Initialisierungsphase  wird kein Konsens hergestellt, jeder behält seine Position und Projekt wird trotzdem gestartet. Ausbaden darf es dann der Projektleiter und das Projektteam. Top-Management, welches strategische Richtungsfindungen in ein Realisierungsprojekt verschiebt und dann über explodierendes Budget klagt. Nettes Spiel.

Wer von euch hat diese Erfahrungen nicht schon selbst machen müssen? Es ist für mich immer wieder erstaunlich wie sich bekannte Probleme immer wieder wiederholen.

Verträge für agile Softwareentwicklung

Posted on by
Reply

Als angestellter Projektleiter und Product Owner hatte ich es bisher in den meisten Projekten mit Festpreis-Verträgen zu tun: Fester Lieferumfang, fester Funktionsumfang und meist recht fixe Qualitätsanforderungen.

Dies hat stets verhindert, dass die agilen Methoden ihre voll Wirkung entfalten konnten. In vielen Fällen ist es im Projektverlauf zu heftigen Diskussionen über (kostenpflichtige) Änderungswünsche gekommen. Das übliche Problem bei Festpreisverträgen in Projekten mit einem gewissen Innovationsgrad.

Wenn man sich nun die “agilen Werte” bzw. die “Scrum Values” in Erinnerung ruft, so wird klar, dass Festverträge ein erhebliches Konfliktpotential zu diesen Werten aktivierten können. Vor diesem Hintergrund gehen viele Vordenker der agilen Bewegung in prinzipielle Opposition zu Festpreiskontrakten. Scott Ambler bezeichnet solche Verträge beispielsweise als unethisch.

Trotzdem sind Festpreisverträge die Norm, Verträge nach Aufwand selten und Mischformen kommen kaum vor.

Peter Stevens hat sich vor diesem Hintergrund mit der Problematik der Vertragsgestaltung näher beschäftigt:

In seinem Artikel Contracting for Agile Software Projects, Part 1 beschreibt er zunächst die Zielsetzung eines Vertrages, was ein Vertrag enthalten sollte und wie Vertragsformen verglichen werden können. In seinem lesenswerten Beitrag 10 Contracts for your next Agile Software Project vergleicht er schließlich die verschiedenen Vertragsformen und ihre “Kompatibilität” mit Scrum:

This week, let’s look at a number of possible contracts, and see how they work with agile and Scrum development projects:

  1. the “Sprint Contract”
  2. Fixed Price / Fixed Scope
  3. Time and Materials
  4. Time and Materials with Fixed Scope and a Cost Ceiling
  5. Time and Materials with Variable Scope and Cost Ceiling
  6. Phased Development
  7. Bonus / Penalty Clauses
  8. Fixed Profit
  9. “Money for Nothing, Changes for Free”
  10. Joint Ventures

Quelle

Ein wirklich wichtiger Beitrag, auch wenn man nicht jedem Argument zustimmen möchte.

UPDATE:

Der Vollständigkeit halber noch der Hinweis auf einen Artikel von Bernd Oestereich: “Der agile Festpreis und andere Preis- und Vertragsmodelle, Objekt-Spektrum, 01/2006, 4 Seiten, Seite 30“. Bernd beschreibt dort Preismodelle wie:

  • Festpreis
  • Aufwandspreis
  • Aufwand mit Obergrenze
  • Mehrstufiger Festpreis
  • Anforderungseinheitspreis
  • Agiler Festpreis

und vergleich diese unter Berücksichtgung verschiedener Aspekte (z.B. Budgetsicherheit, Kalkulationstransparenz, Verhandlungsaufwand, etc.). Obwohl der Artikel mittlerweile einige Jahre alt ist (2006) immer noch lesenswert.

Veranstaltung: Treffen Fachgruppe IT-Projektmanagement Stuttgart – Ziele & Randbedingungen

Posted on by
Reply

Am Freitag (24.04.2009) fand in Stuttgart wieder ein Treffen der regionalen Fachgruppe IT-Projektmanagement Stuttgart mit fast 30 Anwesenden statt.

Ziele

1. Vortrag: Die Magie der Ziele (Markus Maier, comundus GmbH)
Die Definition von guten Zielen wurden als der Erfolgssfaktor #1 benannt (Projekterfolgsfaktoren aus GPM „Der Projektmanager“), auf Ziele als Führungsinstrument wurden kurz eingegangen (Peter Drucker, Management by Objectives).
Die bekannte SMART-Formel wurde um SAP ergänzt: sinnvoll, attraktiv, positiv formuliert (nicht verneinend, da Gehirn dies nicht kann).

Ein passendes Zitat in diesem Zusammenhang:

„Sobald der Geist auf ein Ziel gerichtet ist, kommt ihm vieles entgegen.“

Johann Wolfgang von Goethe

Es wurde herausgestellt, dass Ziele immer erklärbar und begründbar sein müssen. Es ist wichtig Ziele zu hinterfragen, in der Diskussion die sich daraus ergibt, kommt es auf beiden Seiten (Fragender, Erklärender) oft zu wichtigem Erkenntnisgewinn.

Die dann folgende Diskussion war zu erwarten: Was passiert, wenn der Projektleiter Ziele vorgegeben bekommt, die er nicht teilen kann? Kann ein Projektleiter ein Projekt als „Job“ leiten oder muss er hinter den Zielen stehen? Kritische Frage in diesem Zusammenhang: Wenn der Projektleiter nicht für Projekt „brennt“ – wer dann?

Diese Diskussion war gut als Überleitung zum zweiten Vortrag geeignet:

Randbedingungen

Um richtige Randbedingungen kämpfen – Erfolgsfaktor für IT-Projekte (Dr. Karsten Hoffmann, Steinbeis-Transferzentrum IT-Projektmanagement)

vortrag

Karsten Hoffmann, erfahrener Projektleiter und Trainer/Berater für Projektmanagement konnte einiges über die erste Phase in einem Projekt erzählen: Die Übergabe eines Projektes (einer Projektidee) an einen Projektleiter. Bei der Übergabe muss der PL sehr genau prüfen, ob er das Projekt übernehmen kann (es realistisch ist). Es müssen sofort viele Fragen gestellt werden. Der PL muss sich innerhalb Minuten(!)/Stunden einen Überblick über das Projekt verschaffen.

Sofort bei der Übergabe muss der PL für das Projekt kämpfen. Diesen Kampf (um Zeit, Budget, Ressourcen, Zusagen) auf später zu verschieben funktioniert nie. In einem Projekt ist meist das 1. Zehntel entscheidend. Hier werden die wichtigen Weichen gestellt. Der PL muss die Forderungen demnach gleich zu Beginn stellen. Falls auf später verwiesen wird, sofort nach haken.

Beispiel: Personal wird auf später zugesagt, PL muss sofort nachfragen: Wann, Wer/Namen, Vorgehen, Arbeitsplatz.

Damit signalisiert PL, dass er sich nicht mit leeren Versprechen abspeisen lässt. Austausch mündlich beginnen, dann per E-Mail für Verbindlichkeit sorgen.

Eine typische Falle für junge Projektleiter ist das folgende Vorgehen:

  • Auftraggeber: Fang erst einmal mit dem Projekt an, wir sehen dann weiter.
  • später: Warum bekommst du das nicht hin? Schaffst du das nicht? Bist du ein schlechter Projektleiter?

Wichtige Einschränkung: In Kundensituationen können nicht immer alle Fragen gestellt werden.

Falls der Projektleiter bei der Übergabe des Projekt nicht die Möglichkeit hat zu verhandeln und Forderungen zu stellen, die die Erfolgsaussichten des Projektes verbessern, ist dies eindeutig schlecht. Es ist ein Indiz, dass das Projekt die genannten Ziele nicht erreichen wird. Das Aufzwingen eines Projektes ist die denkbar schlechteste Methode für ein Projekt einen PL zu bekommen.

Der PL erhöht seine Chancen für die Verhandlungen und damit den Projekterfolg stark, wenn es ihm gelingt sehr schnell einen Überblick über ds Projekt zu bekommen. Hier geht es eher um Minuten als um Stunden.

  • schnell verstehen um was es geht
  • Auftraggeber, Umfeld, Stakeholderanalyse
  • Zieldreieck abklopfen, PL muss Chancen auf Erreichbarkeit von über 50% annehmen
  • Projektauftrag
  • Ressourcen prüfen

Wichtig hierbei ist es, sofort Fragen zu existierenden Dokumenten stellen. Dies hilft nicht nur bei der Klärung von inhaltlichen Fragen sondern zeigt auch welche Kommunikationskanäle existieren, Engstellen werden erkannt. Beispiel: Ansprechpartner kann/will keine bindende Aussage treffen.

Bei der Projektübergabe muss der Projektleiter klar machen, dass eine gemeinsame Verantwortung für das Projekt besteht. Nur wenn der Auftraggeber eng mitarbeitet hat das Projekt eine Chance auf Erfolg. Handelt es sich um einen komplizierten Kunden, dann hat dies sofort Auswirkungen auf den Aufwand. Komplizierte Kunden erhöhen den Aufwand stark.

In Diskussionen mit höherem Management muss der PL bedenken, dass diese Manager gewohnt sind mit Stärke&Macht ihren Willen durchzusetzen. Dies erzeugt sehr oft einen starken Druck auf den PL, den dieser aushalten muss. Im Zweifel sollte ein Projektleiter die Übernahme ablehnen und die Konsequenzen tragen statt jahrelang an schlechten Randbedingungen zu scheitern.

Auch im Projektverlauf kommt es immer wieder zu Störungen. Diese müssen mit dem Auftraggeber beseitigt werden. Beispiele hierfür:

Änderungen Scope, fehlende Beistellungen, weniger Ressourcen

  • sofort kommunizieren: Wir haben ein GEMEINSAMES Problem
  • vor schneller Eskalation nicht zurückschrecken
  • darauf drängen gemeinsam zu steuern

Bereitstellungen Kunden fehlen

  • sofort Problem identifizieren und an Kunden melden
  • Auswirkungen auf Funktionsumfang klären: Wir warten, d.h. wir können nicht entwickeln, d.h. wir werden weniger Funktionen liefern. Hart bleiben.

Podiumsdiskussion

Im dritten Teil wurde schließlich eine Podiumsdiskussion durchgeführt.
Ein schönes Zitat verdeutlicht sehr gut die „weiche Seite“ des Projektmanagement:

„Ein großer Teil meiner Arbeit ist Kaffee trinken am Kaffeeautomaten. So komme ich zu einem offenerem Feedback, erhalte viele wichtige Informationen.“

Schließlich wurde über Vertrauen als Basis für eine funktionierende und effektive Zusammenarbeit diskutiert und wie dieses aufgebaut werden kann.

Insgesamt eine sehr interessante und spannende Veranstaltung in Stuttgart.

stuttgart

Stuttgart Fußgängerzone.

Das nächste Mal gerne wieder!

Perlen von Scott oder: Scott Ambler on Agile

Posted on by
Reply

Scott ist dafür bekannt zu polarisieren. Im Blog Scrum Sense habe ich eine Sammlung interessanter Aussagen gefunden, die Scott bei einer Veranstaltung in Cape Town getroffen hat:

Scott Ambler on Agile.

Einige Beispiele:

Erstmal Basing auf das traditionelle Projektmanagement:

Traditional project management is based on lying, and stakeholders know this.
Earned value management is another lie – there is no value until the software is delivered. It is just not the right metric.

Der folgenden Satz ruft bei mir Erinnerungen an die “Möbel-Polizei” wach. Aktuell dürfen wir auch nicht aufhängen. Drum kleben wir fleissig ;-)

Fire the evil bastards who hang art on the wall in your IT department! Fill all walls with white boards or whote board wallpaper.

Es läuft in eurer Organisation einiges schief? Dann passt:

You can change your organisation [fix it] or you can change your organisation [move to another]!

Und schließlich noch eine Aussage zu Festpreis-Projekten:

Fixed price work is unethical. As wannabe professionals we need to stand up to the bureaucratic treadmill.

Scott Ambler – unterhaltsam wie immer ;-)

Projektmanagement im Mittelstand – Zusammenfassung einer Studie

Posted on by
Reply

Seit kurzem bin ich Mitglied der GPM (Deutsch Gesellschaft für Projektmanagement e.V.) und erhalte aus diesem Grund das Magazin „projektMANAGEMENT aktuell“. In der aktuellen Ausgabe 2/2009 befindet sich S.17ff unter der Überschrift ‘„PM-Wüste“ Mittelstand?’ eine sehr interessante Zusammenfassen einer Studie von parameta Projektberatung zum Projektmanagement im Mittelstand.

Beispiele für Ergebnisse der Studie sind:

  • Nur bei jedem vierten Mittelständler werden Projekte nach einem Vorgehensmodell abgewickelt (vgl. auch DIES)
  • Der Mittelstand steht dort, wo die Großunternehmen vor ca.  zehn Jahren standen. Die Ausbildung der Projektleiter ist mangelhaft:

Viele Mittelständler meinen, sie wissen, wie man Projekte durchführt; ihre Mitarbeiter haben dies schon immer so gemacht.

Wie problematisch dies ist, zeigen ebenfalls Ergebnisse der Studie: Die Durchschnittsnoten für das Projektmanagement verbessern sich spürbar, wenn Projektverantwortliche ausgebildet werden:

Die Aus- und Weiterbildung ist für den Mittelstand der größte Hebel, das Projektmanagement zu verbessern.

Die Argumentation vieler Topmanager im Mittelstand, dass ihr Unternehmen Geld mit Produkten verdient wird, greift zu kurz:

[...] Projekte aber helfen, neue Produkte schneller zu entwickeln und auf den Markt zu bringen – diese Einsicht ist kaum verbreitet. Projektmanagement wird noch nicht mit Wettbewerbsvorteil verbunden.

Ein weit verbreitetes Problem im Mittelstand ist zudem, dass Projekte ohne ausreichende Zieldefinition und Projektaufträge begonnen werden:

Häufig werden Projektaufträge einfach in die Organisation gekippt – nach dem Prinzip „Machen Sie mal“.

Im Ergebnis werden die Fehler im Projektmanagement häufig durch Nachtschichten und Wochenendarbeit korrigiert. Die Projektmitarbeiter leiden darunter und das Management behauptet zum Schluss:

Bei uns laufen doch die Projekte [...] was wollen wir mit Projektmanagement?

Die Studie zeigt, dass es im Mittelstand einen großen Nachholbedarf hinsichtlich professionellem Projektmanagement gibt. Ein Bewusstseinswechsel muss jedoch beim Topmanagement beginnen damit die richtigen Weichen gestellt werden.