Scrum Cooking: Eine geschmackreiche Einführung zur agilen Projektmanagementmethode

P1050066Jeder, der im Softwarebereich arbeitet wird früher oder später mit Scrum in Berührung kommen. Es gibt heute bereits zahlreiche Zertifizierungen, z.B. zum Scrum Master und Product Owner, Literatur und Vorträge, die sich mit Scrum[1] beschäftigen.

Doch, wie lernt man möglichst schnell, effektiv und auch mit ein wenig Spaß, was hinter der Methode Scrum steckt?
Müssen Mitarbeiter erst alle auf eine teure Schulung geschickt werden, bei der sie zwar die Theorie vermittelt bekommen, aber die Übertragung in die Praxis unklar bleibt? Was ist, wenn ich nur verstehen möchte, was hinter Scrum steckt, um mir dann erst zu überlegen, inwieweit die Methode für mein Team geeignet ist? Vielleicht machen wir schon Scrum, merken aber dass es noch nicht bei allen Beteiligten verstanden worden ist?Mehr…

Tatort Projekt – eine Spurensuche

Tatort_Fußabdruck„Man kann ein Projekt sezieren wie eine Leiche “ – so begann Jochen Wörner, Dornier Consulting, seinen GPM-Vortrag[1] am vergangenen Donnerstag bei doubleSlash. Die CSI-Forensiker[2] ermitteln jetzt auch im Projekt? So klang es im Vortrag tatsächlich. Ziel dieser Sezierarbeit ist die Schuldzuweisung bei riesigen „Titanic“ Projekten, d.h. Projekten, die bereits gescheitert und vor einem Schiedsgericht gelandet sind. Und wenn dann noch Anwälte von Auftragnehmer und Auftraggeber im Spiel sind, wird es hässlich, hat Wörner in seiner Praxis als Projekt-Forensiker bereits erfahren. Mit etwas Sensibilität im Vorfeld kann man sich aber durchaus für den Ernstfall wappnen.

Es ist nicht sehr spannend, die Dokumentenlage immer sauber zu halten und alle Zusatzvereinbarungen mit dem Auftraggeber schriftlich zu fixieren. Auch scheint es selbstverständlich, fehlende Zulieferungen rechtzeitig schriftlich einzufordern. Das ist das Grundhandwerkszeug jedes Projektmanagers. Genau wie das Risikomanagement und ein realistisches, zeitnahes Reporting. In größeren Projekten werden über die Projektlaufzeit aber oft genug viele Basisfehler gemacht, so Wörner. Das Problem: Der Nachweis für eine Einhaltung der Sorgfaltspflicht wird im Nachhinein schwierig.Mehr…

Hilfe, Umzug in das virtuelle Projektbüro

virtuelles TeamIch gehe gerne zur Arbeit. Ein kurzer Plausch an der Kaffeemaschine, schnelle Hilfe mit einer störrischen Exceldatei, meine Kollegen sind immer für mich da. Was wäre, wenn sich die Kollegen über den Globus verteilen und das Team in ein virtuelles Projektbüro umzieht? Wäre das noch das Gleiche? Wenn man Ralf Friedrich von der GeProS – German Project Solutions GmbH – glauben darf, dann ist die Antwort: Nein. Aber virtuelle Projektarbeit muss deswegen nicht schlechter sein.

„Tyler? … Haben wir Tyler verloren?“ Diese Frage des Moderatos aus dem Video „a conference call in real life“ fasst viele der Erfahrungen zusammen, die wir im Laufe unseres Berufslebens mit Telefonkonferenzen machen. Wir gehen verloren im Stimmengewirr oder durch Zusammenbruch der Leitung. Bedenkt man, dass mehr als 50 Prozent der Informationen in einem face-to-face Gespräch durch Mimik und Gestik ausgetauscht werden, dann hat die Telefonkonferenz schlechte Karten den Beliebtheitswettbewerb der Konferenzformate zu gewinnen.Mehr…

Was hat XAVER mit Softwareprojekten zu tun?

Wassertropfen_kleinAnfang Dezember wütete der Orkan XAVER über Deutschland und ich hörte im Nachgang  zufällig im Radio einen Bericht darüber. War er vielleicht doch nicht so heftig? Ist ja nicht viel passiert. Weit gefehlt. Der Bericht hat deutlich gemacht, mit welchen Maßnahmen verhindert wurde, dass die Jahrhundertflut an den Küsten große Schäden anrichtet.

Land unter. Menschenleben in Gefahr. Flugzeugabsturz.

Das waren die drei wesentlichen Katastrophen, die in dem Bericht betrachtet wurden. Schon nach den Fluten in den letzten Jahrzehnten wurden die Deiche ausreichend verstärkt. Die Vorhersage des Orkans und seiner möglichen katastrophalen Folgen kam ausreichend früh. Die Menschen auf den Halligen konnten ihre Häuser schützen. Die Patrouillen am Deich kontrollierten auf Schäden, bevor das Wasser durchbrach. Der Flughafen Hamburg wurde geschlossen, bevor wieder eine vollbesetzte Maschine in Gefahr einer Bruchlandung geriet.

Was hat das nun mit Softwareprojekten zu tun? Der Katastrophenschutz in Zusammenhang mit dem Orkantief XAVER ist ein Paradebeispiel für gelungenes Risikomanagement.

Das falsche Produkt. Zu spät. Zu teuer.

Auch in Software-Projekten müssen drei große Katastrophen mit Risikomanagement verhindert oder gemindert werden: Das falsche Produkt. Zu spät. Zu teuer. Hier haben wir viele Erfahrungen mit Risiken, die sich im Vorfeld schon erahnen lassen. Auch Software-Projekte müssen in puncto Risiken bewertet, mit Maßnahmen belegt und permanent beobachtet werden. Es braucht Frühwarnsysteme, um das Eintreffen der Risiken rechtzeitig zu erkennen und Schutzmaßnahmen zu definieren.

Vielleicht motivieren die positiven Ergebnisse des Risikomanagements beim Orkantief XAVER dahingehend, das eine oder andere Handwerkszeug für das eigene Projekt noch einmal zu überprüfen. Dann kann sich der Projektleiter eines komplexen Projektes auf die Frage: „Das war doch gar nicht so schwierig, oder? Ist ja gar nichts passiert…“ gemütlich zurücklehnen und mit einem Grinsen antworten: „Da habe ich wohl alles richtig gemacht.“

In diesem Sinne wünsche ich Ihnen allen einen guten und gesunden Rutsch ins neue Jahr, keine Katastrophen und immer „Happy Projects“ – auch in 2014.

10 Erfolgsfaktoren für das Anforderungsmanagement in agilen Software-Großprojekten

Prozess_ScrumEine der Hauptaufgaben des Product Owners in agilen Softwareprojekten ist es, die Produktanforderungen mit dem Kunden abzustimmen und in sogenannten User Stories zu beschreiben. Diese werden dann von den Entwicklern Stück für Stück in Form von darin heruntergebrochenen Tasks umgesetzt. Nach jeder Entwicklungsiteration – dem Sprint – entsteht ein auslieferfähiges Ergebnis. Die Abstimmung der User Stories und Akzeptanzkriterien ist ein zentraler Prozess der agilen Entwicklungsmethodik, der in der Praxis meist mehrere Abstimmungschleifen durchläuft.

Was aber, wenn der Product Owner und sein Team nicht alleine an einem Softwareprodukt arbeiten, sondern 17 weitere Teams mit vielen Abhängigkeiten untereinander beteiligt sind? Wenn es auch viele Kunden mit konkurrierenden Zielen gibt, die teilweise international verteilt sind und zum Teil selbst große Softwareprojekte mit eigenen Zeitplänen repräsentieren? Dann wird das Anforderungsmanagement im Projekt zu einer besonderen Herausforderung auf dem Weg vom Wunsch zur Wirklichkeit.

Mit unseren Erfahrungen aus der agilen Entwicklung webbasierter Softwareanwendungen haben wir die 10 wichtigsten Erfolgsfaktoren zusammengefasst, damit das Anforderungsmanagement auch in agilen Großprojekten gut und effizient funktioniert:

1. Die Scrum-Rollen „Kunde“ und „Product Owner“ werden beide ausgefüllt.

In Filmsprache übernimmt der Kunde die Rolle des Produzenten und der Product Owner die Rolle des Drehbuchautors. Der eine fordert das Produkt an, der andere gestaltet es. In vielen Projekten werden diese beiden Rollen vermischt bzw. eine davon wird gar nicht gelebt. Das führt zu einem Vakuum bei der Entwicklung der Produkt-Vision und der fachlichen Prioritäten.

2. Der Kunde trägt die Produkt-und Release-Vision mit.

Die Produkt-Vision ist sowohl fachliche Klammer als auch Motivationsfaktor für die Teams. Deswegen ist es eine wichtige Aufgabe des Product Owners, diese Vision permanent dem Team zu vermitteln. Aber nur wenn der Kunde diese Vision voll mitträgt, wird das Produkt letztendlich seine Anforderungen treffen.

3. Die Teams kennen die übergreifende Produkt- und Release-Vision.

Die Teams sollen nicht nur die Vision für das eigene Team, sondern für das ganze Produkt kennen. Nur so verstehen sie sich als Teil des Ganzen und unterstützen im Bedarfsfall auch gerne andere Teams.

4. Der Kunde steht für das Review zur Verfügung.

Agile Projekte leben von einem ständigen Lernzyklus. Wird das Review vom Kunden nicht wahrgenommen, fehlt eine wichtige fachliche Feedbackschleife zum Produkt und damit zum Entwicklerteam.

5. Scrum of Scrum wird für Product Owner, Scrum Master und technische Architektur gelebt.

Wenn viele Scrum Teams an einem Produkt arbeiten, werden Product Owner und Scrum Master jeweils in eigenen Gruppen – im sogenannten Scrum of Scrum – organisiert. In diesen Gruppen werden teamübergreifende Fragen geklärt. Nur wenn das Konzept des Scrum of Scrum auch die technische Architektur umfasst, können softwarearchitektonische Inkonsistenzen verhindert werden.

6. Es gibt nicht zu viele Teams.1

Nach unserer Erfahrung sind mehr als 7 Teams in einem Projekt nicht effizient mit klassischen Scrum-Methoden steuerbar. Die Gruppe der Product Owner und Scrum Master überschreitet dann die optimale Teamgröße. In einem Software-Großprojekt ist allerdings oft eine größere Skalierung notwendig. In diesem Fall sind die Teams in einzelnen Zellen z.B. nach Features oder Produktkomponenten zu organisieren, um die Komplexität beherrschbar zu machen und die Teamgrößen immer übersichtlich zu halten.

7. Die Abhängigkeiten zwischen den Teams sind gering.

Starke Abhängigkeiten zwischen den Teams führen zu ungeplanten Anforderungen, die außerhalb des Backlogs vorbeigesteuert werden. Das ist Gift für eine effiziente Abarbeitung der User Stories und demotiviert die Teams.

8. Anforderungen von abhängigen Teams werden über die Product Owner eingesteuert.

Wenn sich größere Abhängigkeiten zwischen den Teams nicht vermeiden lassen, sind diese im Scrum of Scrum über die Product Owner einzusteuern. Das bremst zwar scheinbar die schnelle Hilfe für das Nachbarteam aus, sichert aber auf Dauer eine bessere Planbarkeit des Gesamtprojekts.

9. Es gibt ein übergreifendes Anforderungsmanagement für Großprojekte mit vielen Anforderern

Wenn es nicht mehr den einen Kunden gibt sondern viele Anforderer aus unterschiedlichen Initiativen und Projekten, dann ist für große strategische Anforderungen ein vorgeschaltetes Anforderungsmanagement sinnvoll. Nur so bekommen die Product Owner die Anforderungen mit ausreichender Stabilität und fachlicher Tiefe.

Die Aufgaben eines solchen Anforderungsmanagements sind:

a.    Sicherstellung der Ende-zu-Ende-Betrachtung der Anforderungen über alle Projekte hinweg.
b.    Prüfung der unternehmerischen Relevanz angeforderter Themen.
c.    Herbeiführung der Entscheidungen im Change Control Board.
d.    fachliche Aufbereitung von Themen für die Product Owner.
e.    Verdichtung der Sprintergebnisse und Schaffung von Transparenz über den Stand der Anforderungen für die anfordernden Projekte.

10. Das übergreifende Anforderungsmanagement ist Teil des Multiprojektmanagements bei sehr großen anfordernden Initiativen.

Das Multiprojektmanagement sorgt für die richtige Auswahl und den richtigen Schnitt der Projekte. Dazu leistet das übergreifende Anforderungsmanagement einen zentralen Beitrag, da es die verschiedenen Fachbereichsanforderungen aus Unternehmenssicht strategisch zusammenführt.

Beliebte Fallen im Projektmanagement – Klassiker der Projektarbeit jenseits von Methoden- und Modelldiskussionen

FotoWer innerhalb seines Unternehmens viel mit Projekten konfrontiert ist sollte dabei nie außer Acht lassen dass mit simplen Techniken der Projekterfolg stark beeinflusst werden kann. Unser Gastautor Thomas Schäfer berichtet über beliebte Fallen im Projektmanagement.

Innerhalb eines interaktiven Vortrags der GPM (Deutsche Gesellschaft für Projekt-management) zu Gast bei der Firma doubleSlash Net-Business GmbH ging Thomas Schäfer, Geschäftsführer der Trans-form! Consulting Gesellschaft für Beratung, Projektarbeit und Coaching mbH in Kempten auf den Umgang mit Projektfallen ein. Dabei wurden  Faktoren von alternativen Entscheidungsmöglichkeiten bis hin zu dem Einfluss von übertriebenem Wertschätzungsverlangen thematisiert.

Schon seit längerem lässt sich beobachten, dass die Grundlagen des Projektmanagements (PM) in den Unternehmen solide ausgebaut werden. Hinweise darauf geben insbesondere die Vielzahl der eingesetzten IT-gestützten PM-Werkzeuge sowie die Statistiken zum zertifizierten Projektpersonal.

Ergebnisse der McKinsey Studie

Der Blick auf aktuelle Studienergebnisse zeigt, dass diese Anstrengungen allein allerdings noch kein Garant für den Projekterfolg sind. Zwei Jahre lang werteten Forscher der Universität Oxford und des Beratungshauses McKinsey rund 1500 IT-Projekte mit einem durchschnittlichen Volumen von 170 Millionen US-Dollar aus. Das Ergebnis: Immer noch jedes sechste IT-Projekt sprengte das vorgegebene Budget um durchschnittlich 200 Prozent. Im Durchschnitt wurde der geplante Zeitrahmen um 70 Prozent überschritten.

Fallen im Projektverlauf

Die Vermutung liegt nahe, dass hier ein spezieller Mechanismus die Erfolgsaussichten von Projekten trübt. Kann es sein, dass Aufraggeber, Leiter und Mitarbeiter in Projekten im Projektverlauf immer wieder in dieselben Fallen treten – und zwar völlig unabhängig von der jeweils gewählten Projektmethode?

In Diskussion mit der GPM-Regionalgruppe Friedrichshafen, zu Gast bei der doubleSlash Net-Business GmbH ging ich dieser Frage nach. Sind die Fallen vielleicht sogar selbst gestellt? Eine sehr pikante und dennoch naheliegende Vermutung. Es zeigt sich, dass diese selbst gestellten Fallen in Projekten immer wieder aus Situationen entstehen, in denen sich die Beteiligten für ein Vorgehen entscheiden, von dem sie selbst nicht überzeugt sind. Dabei ist man sich bewusst dass die erhofften Effekte meist weniger wahrscheinlich als die längst bekannten und unerwünschten Folgen sind. Anhand von Praxisbeispielen konnte gezeigt werden wo Fallen im Verlauf von Organisations- und IT-Projekten auftauchen – und warum Erfahrungsgemäß die meisten davon selbst aufgestellt werden.

Vorschnelle „Macher“

Die Versuchung lauert schon im frühen Stadium der Projekte. Da gibt es die Projektleiter, die „schon einmal anfangen“, ohne dass die Ziele des Projektes feststehen. Oder jene, die direkt den Ablauf- und Terminplans erstellen „weil es ja schon so viele Vorarbeiten gibt“. Obwohl in Theorie und Praxis hinlänglich bekannt ist, dass ein Start ohne klaren Projekt-/ Arbeitsauftrag zu permanenten Grundsatzdiskussionen und Orientierungsschwierigkeiten im weiteren Projektverlauf führen kann, ist genau das dennoch ein immer wieder zu beobachtendes Phänomen. Für Projektleiter ist es sehr zeitaufwändig, die Validierung der bisherigen Arbeiten vorzunehmen und sicherzustellen, dass Ziel- und Liefergegenstände definiert sind. Da erscheint oft die Verlockung zu groß, lieber als „Macher“ gleich durchzustarten um zu vermeiden als Bedenkenträger oder Bremser angesehen zu werden.

Auch die Auftraggeber der Projekte sind nicht davor gefeit, in selbst gestellte Fallen zu tappen. Häufig treten sie am Anfang des Projektes in Erscheinung, binden alle ein, treffen alle notwendigen Vereinbarungen – und lassen das Projekt dann laufen. Die Verantwortung liegt ja nun „bei den anderen“. Die damit verbundene Hoffnung, im weiteren Verlauf keine Probleme mehr zu haben und am Ende auch die Unterstützung von allen für das Ergebnis zu bekommen, bleibt allerdings immer wieder unerfüllt.

Die Alternativen dazu wären da: Den Business Case mit den entscheidenden Stakeholdern permanent abstimmen und falls notwendig anpassen – in Verbindung mit einem wirksamen Nutzencontrolling. Das würde aber Zeit erfordern, die jeder Manager dann lieber woanders einsetzt, wenn er nicht mehr in der offensichtlichen Verantwortung ist.

Unklarheit und PM-Standards

Laufen die Projekte erst mal, finden sich auch Projektteams in solchen pikanten Situationen wieder, nämlich dann, wenn es um das Arbeiten mit Projektmanagement-Standards geht. Denn wer kennt den Ausspruch nicht:  „Wenn das PMO möchte, dass wir uns an die internen PM-Standards halten, dann machen wir das halt – sicher ist sicher.“ Oft sehen Teams in den PM-Standards einen gewissen Ersatz für fehlende Klarheit im Projekt, getreu dem Motto:  „Es ist mir zwar nicht ganz klar, was wir genau wollen – aber wenn wir unseren PM-Standards treu bleiben, wird das schon klappen.“
Die damit einhergehenden Probleme werden gerne übersehen:

  • Es wird sich lieber auf Vorlagen verlassen, anstatt selbst klärend tätig zu werden.
  • Vorlagen wie z.B. die Risikoliste, werden mit Unwesentlichem und Unscharfem Input gefüllt. Das wirklich Wichtige wird nicht erkannt bzw.  dadurch verschüttet.

Auch bei diesen Beispielen spielt der Wunsch eine große Rolle, im Unternehmen nicht als Verweigerer wahrgenommen zu werden, sondern als jemand der „so arbeitet, wie sich das gehört.“

Der schnelle Überblick

Auch einer der Klassiker der Projektarbeit blieb an diesem Abend nicht unerwähnt. Es sind die bekannten Forderungen des Auftraggebers: „Wir brauchen schnell einen Überblick, wo das Projekt steht! Schauen wir uns die bisher verbrauchte Zeit und/oder die bislang entstandenen Kosten an.“ Projektleiter folgen dieser Aufforderung zum Teil sehr bereitwillig. Die Aussicht, schnell einen groben Überblick zu bekommen, ohne zu viel Aufwand für das Controlling zu betreiben, erscheint verführerisch. Es ist zwar jedem klar, dass so keine verlässliche Aussage über den Fortschritt möglich ist, aber wenn die Planung stimmt – und daran möchte man nicht rütteln – dann müssen diese Rückschlüsse auch valide sein. Warum also genauer hinschauen? Um Fehlsteuerungen aufgrund von „Melonenampeln“ (außen grün und innen rot) zu vermeiden, wäre das einzig richtige Vorgehen Fortschrittsaussagen immer an dem festzumachen, was das Projekt leisten soll und was davon schon geleistet wurde. Aber, die Verlockung ist sehr groß . . .

Das Fazit des Abends:

Es ist erkennbar, dass die Handlungen von Auftraggebern, Projektleitern und Teams stark davon beeinflusst sind, wie sie in ihrer Organisation gesehen und wertgeschätzt werden wollen und welche Erfahrungen sie darin gemacht haben. Ihr Verhalten führt unter den verbreiteten Rahmenbedingungen leider noch zu häufig nicht zu den gewünschten Ergebnissen.

Um das zukünftig zu ändern (denn in jeder der erlebten Situationen hätte es Alternativen gegeben), müssen Unternehmen genau dort ihre Hebel ansetzen:

  • Rahmenbedingungen für Projekte verlässlich machen.
  • Ein Vertrauensklima in den Projekten schaffen.
  • Den Erfolg und Nutzen eines Projektes in den Vordergrund stellen.
  • Sich ernsthaft mit den Interessen der Stakeholder und den Bedingungen (Bedrohungen und Chancen) beschäftigen, die den Erfolg eines Projektes ausmachen.
  • Die Werkzeuge einsetzen, die zur vorhandenen Aufgabenstellung passen

Die theoretische Grundlage zur Verbesserung zukünftiger Erfolgsstatistiken ist geschaffen und deren Ansatzpunkte sind zu genüge definiert. Jedoch wird die Umsetzung dabei die größte Herausforderung darstellen, da es für Projektleiter nicht leicht ist, sich von Entscheidungen aus der Intuition und Erfahrung heraus zu lösen und das „Schema F“ zu verfolgen – welches vermeintlich erprobter ist und statistisch gesehen zu mehr Projekterfolgen führt. Wenn sich jedoch Projektleiter dazu entscheiden alternative Vorgehensweisen stärker in Betracht zu ziehen und gleichzeitig deren eigene Wertschätzung unter den Projekterfolg priorisieren, so erhält das Projekt einen anderen, erfolgsorientierteren Charakter. Dieser ist wichtig für das Unternehmen, und im Umkehrschluss für die Wertschätzung . . . So schließt sich der Kreis.

Projektportfolio Management – das ganze Universum der Projekte beherrschen

Die steigende Anzahl an Projekten macht es vor allem großen Unternehmen immer schwerer, im Makrokosmos aller Projekte den Überblick zu bewahren. Das kostet nicht nur Zeit und Geld, sondern kann auch zu vermeidbaren Misserfolgen führen bestätigt die deutsche Gesellschaft für Projektmanagement (GPM) in ihrer Studie „Misserfolgsfaktoren im Projekt“.

Deep space nebulae

Der größte Teil der 151 befragten Teilnehmer sieht es als kritisch für ihre Projekte an, dass das Top Management das Projektportfoliocontrolling nicht zur Steuerung der gesamten Unternehmensentwicklung nutzt. Große Unternehmen wie die ZF Friedrichshafen AG stellen sich dem Problem und starten Initiativen zur Abbildung der gesamten Projektlandschaft im Projektportfolio Management.
Mehr…

Mit wenig Aufwand den Projekterfolg sichern

Im Gespräch mit Rolf Schröder und Sabine Rossbach„Jede regionale Fußballmannschaft hat einen Coach“, sagt Rolf Schröder, verantwortlich für das Projektmanagement bei der Deutschen Telekom Technik GmbH in Bonn. „Aber Projektleiter von komplexen Großprojekten sollen es alleine können?“ Ganz ähnliche Überlegungen stellt Sabine Rossbach, Senior Project Managerin bei der doubleSlash Net-Business GmbH an. „Und dabei ist der Aufwand für das Coaching von Projektleitern überschaubar, im Verhältnis zum Projektvolumen.“

Im Gespräch diskutieren beide über ihre Erfahrungen mit dem Coaching von Projektleitern aus der Sicht von Konzern und Mittelstand.Mehr…

Projekterfolg durch Coaching von Projektleitern

ProjektmanagementErfolgreiche Projekte mit zufriedenen Kunden sind das A&O für doubleSlash. Deswegen ist uns die Entwicklung der Kompetenzen unserer Projektleiter besonders wichtig. Und diese Entwicklung darf nicht nur auf die Vermittlung von Wissen in Schulungssituationen beschränkt sein. Erst wenn die Projektleiter ihr Wissen auch in den unterschiedlichsten Situationen sicher anwenden können, ist der Projekterfolg gesichert. Das Coaching von Projektleitern ist für uns daher ein wesentlicher Bestandteil der Qualifizierung im Projektmanagement.

Und damit sind wir nicht alleine. Auch unsere langjährigen Partner haben längst das Coaching der Projektleiter als Erfolgsfaktor der Projektarbeit erkannt. Rolf Schröder von der Telekom Technik GmbH hat in seinem kurzweiligen Vortrag auf dem PM Forum 2012 dieses Thema bereits beleuchtet. Nun führt er uns am Donnerstag, den 4. Juli 2013 in Friedrichshafen von der Theorie zur Praxis des Projektleitercoachings im Rahmen einer Abendveranstaltung der GPM Regionalgruppe.Mehr…