Mittwoch, Oktober 15, 2014

So geht das ja gar nicht .....

Herr M. ist empört. "Ein Projektteam, das für 2 Tage einfach verschwindet. Keiner weiß, was die da tun. Und vor allem, wo sie sind. Als ob die Besprechungsräume im Unternehmen nicht gut genug wären. Die sollen arbeiten, so daß man sie auch sieht."

Herr M. redet sich in Rage. Eines seiner wichtigsten Projektteams gibt sich gerade der Arbeitsverweigerung hin. Für 2 Tage! - alle weg. Irgendwo in irgendwelchen Tagungsräumen. Was soll das bringen? Außerdem ist da immer noch das ungeklärte Problem mit der Datenbank-Anbindung. Seit 3 Monaten ist das Projekt nicht imstande, dafür eine Lösung zu finden. Stattdessen machen die einen Ausflug…

Herr P. dagegen ist sehr zufrieden. Die Unklarheiten und Probleme im Projekt klären sich langsam. Das Team überarbeitet konzentriert die Aufteilung der Arbeitspakete und diskutiert die Abhängigkeiten, die sich daraus ergeben. Endlich sind einmal alle in Ruhe bei der Arbeit, und zwar so lange bis alles geklärt ist, und nicht bis der nächste Besprechungstermin ruft oder ein dringender Anruf stört.

Nebenbei entwickelt das Team gemeinsam Ideen um die ständige Überlastung aller Beteiligten in den Griff zu bekommen. Aufgaben werden anders verteilt, Prioritäten hinterfragt. Auf einer großen Tafel werden alle Ideen gesammelt und so lange wieder neu sortiert, bis alle im Team zufrieden sind.

Ein 2 - tägiger Planungsworkshop scheint sich zum Katalysator für die kreative Lösungsfindung zu entwickeln.

An die Stimmung, in der Herr M, sein Chef vermutlich gerade ist, denkt Herr P lieber nicht. Es reicht, wenn er sich übermorgen das Donnerwetter abholt. Da er dann konkrete Lösungsvorschläge für die akuten Performance-Probleme und Datenbank-Anbindungen vorlegen kann, hofft er, ihn zu besänftigen. Immerhin schleppen sie das ungelöste Datenbank-Problem schon seit 3 Monaten mit sich herum. Eine intensive Diskussion der Experten unter sich, ausgestattet mit dem richtigen Arbeitsmaterial, hat hier Wunder gewirkt.

Herr P gilt als Exot unter seinen Projektleiter-Kollegen. Er legt Wert auf gemeinsame Workshops, in denen mit Stift und Papier gearbeitet wird (nicht nur, aber zum großen Teil). Visualisierungen sind ein wichtiger Aspekt. Papiertischdecken zum Beschreiben, Skizzieren von Ideen, das Weiterentwickeln von zunächst unrealistisch wirkenden Lösungsansätzen führt über die Tage hinweg zu durchaus sinnvollen Lösungen – das Team ist begeistert.

Warum Herr P auch noch Tagungsräume außerhalb des Unternehmens gesucht hat, hatte mehrere Gründe.

1. ungestört arbeiten - das liegt auf der Hand.

2. eine andere Umgebung bringt das Team automatisch auf andere Gedanken. Menschliche Gehirne funktionieren nun mal so. Sie nehmen Impulse der Umgebung auf und beeinflussen sich damit selbst. Eine Umgebung in der man sich gerne aufhält, regt dazu an, konstruktiv zu arbeiten und auch mal etwas Neues auszuprobieren.

3. Funktionierendes Arbeitsmaterial hält Herr P für sehr wichtig. Flip Charts ohne Papier, Whiteboards, die nicht mehr zu reinigen sind, Stifte, die aufgebraucht sind, Moderationskoffer, die leer oder im besten Fall minderwertig ausgestattet sind - das ist zwar Alltag im Unternehmen, aber nichts, mit dem man gerne arbeitet. Was umgehend wieder zu Punkt 1 und 2 führt.

Herr M. hat sich nach dem 2 tägigen Workshop tatsächlich wieder besänftigen lassen. Das lag auch daran, dass sich die Ergebnisse des Teams wirklich sehen lassen konnten. Und es wurde ja alles protokolliert und dokumentiert. Schließlich will das Projektteam auf den Arbeitsergebnissen aufbauen.

Montag, Oktober 06, 2014

Unsere Lieblingsbücher - Tools im Problemlösungsprozess

Wenn man Geschichten mag, ist man oft ein Bücherwurm. Meine These, und ich bin das beste Beispiel dafür. Der Bücherschrank im Büro ist permanent an seiner Leistungsgrenze.

Ich habe heute mal eines meiner Lieblingsbücher aus dem Schrank gezogen. das ist ein Lieblingsbuch nicht weil es so viele spannende Geschichten enthielte, sondern weil dieses Buch tatsächlich bei uns im Dauergebrauch ist. Für jedes Meeting, für jeden Workshop, den wir für Kunden (oder auch für uns selbst) vorbereiten, findet sich eine Anregung dazu.



Das Buch beschreibt eine mittlerweile zu den Klassikern zu rechnenden Methode zur Problemlösung – KULT . Nach einer Einführung zum Thema stellen die Autoren Christian Berndt, Claudia Bingel und Brigitte Bittner 27 Tools die in den unterschiedlichen Phasen ihre Anwendung finden dar. Das letzte Kapitel befasst sich mit der Moderation eines Problemlösungsprozesses.
Ein echter Klassiker – dieses Buch besticht durch klare Darstellung und einer Menge nützlicher Methoden für die Praxis. 

Ein kurzer Blick ins Buch:

Donnerstag, September 18, 2014

Warum „ein bisschen agil“ auch der richtige Weg ist

Es war einmal… - so fangen doch die meisten Geschichten an – und hören mit einer hoffentlich verblüffenden Pointe auf. So oder so ähnlich laufen auch viele Projekte ab. Sie beginnen, werden durchgeführt und mit Ergebnis und einigen schlauen Erkenntnissen abgeschlossen. (Hoffentlich)

Das ist ein Bericht, in dem sich ein Projektteam, gewöhnt an klassische Wasserfall-Methodik auf den Weg hin zu einer beweglicheren, flexibleren und reaktionsfähigeren Vorgehensweise machte.


Was in Projekten gerne zu kurz kommt sind Fragen wie: Aber was werden wir bei nächsten Mal besser (anders) machen? Was haben wir gelernt? Welche Fehlentscheidungen wollen wir in der Zukunft vermeiden? Es ist schon lobenswert wenn eine Reflektion bei den Beteiligten am Ende einer jedes Projektes statt findet :-) Die Praxis sieht oft anders aus.

Es war einmal - besser gesagt es gibt es noch, ein traditionsgeprägtes Unternehmen, das bis vor kurzem seine IT- Projekte ebenso klassisch (Wasserfall - Methode) wie traditionell abgewickelt hat: Analyse, Planung, Durchführung, Abschluss, und wenn die Zeit es noch erlaubt hat oder der Projektleiter mutig genug war: Lessons Learned. Diese wurde für das Management dokumentiert und verschwand im Nirwana. Bis man bei der Vorbereitung eines Projektes zu der Erkenntnis kam, es könnte doch auch anders gehen. Man stellte sich einfache, aber wichtige Fragen: was können wir tun damit wir Fehler schneller identifizieren können und noch währen des Projektes aus den Erkenntnissen profitieren können –denn nach dem Projekt ist es meistens zu spät und das Interesse gering.

Da das neue Langzeit-Projekt praktisch vor der Tür stand, wollte man diesen Gedanken umsetzen. Aber wie? Der arme Projektleiter stimmte mit gemischten Gefühlen der ersten Lessons Learned - Runde zu, obwohl es ihm seltsam vorkam, diese gleich nach der Initialphase des Projektes zu veranstalten. Das anfangs ebenso skeptische Projektteam machte einen 2 sündigen Workshop brav, aber etwas reserviert mit – soll sich hier etwas ändern? Die Skeptiker überwogen. Schließlich waren sie anderes gewohnt.

Als zweiten Schritt führte man ein Projektbarometer ein: eine kurze, regelmäßige und anonyme Umfrage innerhalb des Projektteams zu Stand und Stimmung des Projektes. Das erste Feedback überraschte sogar das Management: zu viele Meetings ohne brauchbares Ergebnis, unklare Erwartungen und Aufgaben, zu wenig Zeit zur Umsetzung. Es gab Lob für die gute Zusammenarbeit, offene Kommunikation und den Wunsch nach weiteren Lessons Learned. Der Grundstein für eine nachhaltige Veränderung wurde damit gelegt.

Die Projektleitung, obwohl konstruktives und offenes Feedback nicht gewöhnt, wollte den neuen und ungewöhnlichen Weg dann gehen. Der Schlüssel zum Erfolg liegt/lag natürlich in der ersten Linie bei Management selbst, dass die Vorschläge angenommen hat. Man schaffte kurzerhand ein paar „langatmige“ Meetings ab und verschaffte dadurch dem Team Zeit zum produktiven Handeln. Ebenso wurde ein weiteres Lessons Learned terminiert. 


Also ein Lob nicht nur an das Team, das sich "ahnungslos" und mit einigen Vorbehalten auf eine Veränderung eingelassen hat, sondern auch an das Management, das den Raum für die kleinen, aber entscheidenden Veränderungsschritte gegeben hat. (und das Management wird ja in der Regel nicht gelobt)

Agil heißt für mich vor allem kontinuierlich und interaktiv: Planen, Umsetzen, Reflektieren, um die Erkenntnisse in den nächsten Projektschritten zu implementieren. Bis zu einer Agilen Projektorganisation ist es hier noch ein laaaanger Weg – wobei das nicht unbedingt das Ziel sein muss. Auch kleine Schritte können positive und nachhaltige Veränderungen in einer Projektorganisation bringen. 
Ein bißchen agil eben. Hauptsache beweglich bleiben.

Jolanta Czagin, @wowolek

Montag, September 08, 2014

Gastartikel: 10 Tipps, wie Sie Ihre Kollegen für Ihr Projekt begeistern


Wenn Ihr Projekt reibungslos verlaufen soll, müssen Sie Ihre Kollegen von Ihrem Vorhaben begeistern. Dazu gehört zunächst einmal, dass Sie selbst hinter Ihrem Projekt stehen. Aber auch die Motivation Ihrer Kollegen ist ein wichtiger Faktor auf dem Weg zum erfolgreichen Projektabschluss. Nachfolgend finden Sie zehn Tipps, mit denen Sie Ihre Teammitglieder begeistern.


1. Schaffen Sie eine gute Arbeitsatmosphäre
Niemand arbeitet motiviert und gerne, wenn die Arbeitsatmosphäre nicht stimmt. Sorgen Sie dafür, dass die Kollegen sich untereinander respektieren und einen angenehmen Umgang ermöglichen.

2. Reden Sie offen über alles
Damit Ihre Kollegen Ihnen vertrauen, sollten Sie offen kommunizieren. Berufen Sie regelmäßige Meetings ein und versorgen Sie Ihre Teammitglieder transparent mit allen wichtigen Informationen.

3. Loben Sie Ihre Teammitglieder
Wann immer es geht: Loben Sie Ihre Kollegen und sagen Sie Ihnen nicht nur, wie gut Sie ein Ergebnis finden, sondern honorieren Sie auch den Einsatz. Loben Sie Kollegen direkt und lassen Sie dabei Emotionen sprechen.
 

4. Verteilen Sie Arbeitspakete
Es ist besonders wichtig, die Arbeit in einzelne Schritte zu untergliedern. Versuchen Sie, niemanden zu überlasten und verteilen Sie die Pakete sinnvoll. Auch hier ist die Kommunikation das A und O.

5. Arbeiten Sie im Team
Niemand sollte sich alleine fühlen oder ausgegrenzt werden. Machen Sie deutlich, dass Sie als Team arbeiten und stellen Sie die Wichtigkeit eines jeden einzelnen Mitgliedes heraus.

6. Feiern Sie Teilerfolge

Präsentieren Sie Ihren Kollegen Teilerfolge und zeigen Sie ihnen in regelmäßigen Abständen, wie weit das Team schon gekommen ist. Das motiviert und spornt an.
 

7. Stellen Sie den Nutzen heraus
Machen Sie immer wieder deutlich, welchen Nutzen das Projekt für andere und für das Team selbst hat. Stellen Sie die Vorteile des Projekts heraus.
 

8. Planen Sie richtig
Damit das Projekt überhaupt reibungslos ablaufen kann, sollten Sie unbedingt planen. Wissen Sie bereits, welche Ziele Sie verfolgen, können Sie Ihre Kollegen zielführender begeistern.
 

9. Sprechen Sie sich ab
Auch wenn Sie Projektleiter sind, sollten Sie Ihrem Team nicht das Gefühl geben, über die Köpfe der anderen hinweg zu entscheiden. Diskutieren Sie und sprechen Sie sich ab. Denken Sie hierbei vor allem an den Teamgeist.
 

10. Gehen Sie auf jeden ein
Versuchen Sie, die Stärken und Schwächen eines jeden Mitglieds herauszustellen und gehen Sie so individuell auf jeden Kollegen ein. Verteilen Sie insbesondere die Aufgaben entsprechend der Qualifikation und Expertise eines jeden Mitarbeiters.


Haben Sie noch weitere Tipps aus der Praxis, die Sie weiterempfehlen könnten?


Der Autor
Steffen Jung ist Leiter Marketing bei braintool software GmbH, www.braintool.com, Anbieter von Projektmanagement Software. Er verfügt über umfangreiche Berufspraxis in den Bereichen Projektmanagement, Zeitmanagement, Software und E-Commerce. braintool bietet mit A-Plan ein PM-Tool, welches im Hinblick auf anwenderfreundliche und für den Nutzer praxistaugliche Aspekte entwickelt wurde.

Dienstag, August 26, 2014

Frauen im Projektmanagement - Oje? oder Ah ja!


Wir diskutieren (mal wieder):
Die GPM-Region München lädt am 23.09. ein:

"Der Anteil der Frauen im Projektmanagement nimmt kontinuierlich zu. Studien zeigen, dass heterogene, gemischte Team weitaus innovativer, produktiver und erfolgreicher sind als homogene Gruppen. Doch Frauen arbeiten, kommunizieren und führen anders als Männer. Dies führt immer wieder zu Spannungen und Konflikten in Projektteams.

Was machen Frauen anders? Wie werden Projektleiterinnen wahrgenommen? Ist es ein kleiner oder doch ein großer Unterschied?"

Ich wünsche mir für dieser Runde kontroverse Meinungen und möglichst viele Erfahrungen zu dem Thema - oder ist das gar kein Thema?


Allerdings:
.... Auf meine Frage bei einem Unternehmen neulich, wie hoch denn deren Frauenquote in Projekten sei, kam die Antwort: "Wir haben die Bettina!" ....

Mittwoch, August 13, 2014

Konzept-Überarbeitung, die 93. Runde....

".... vielen Dank für die Zusendung des überarbeiteten Konzeptes. Ich habe noch folgende kleine Anmerkungen ....[es folgt eine Liste mit 35 detaillierten Punkten, die zu beachten sind].... Außerdem bitte ich Sie, bei der Erstellung der Grafiken zukünftig auf folgendes zu achten .... [es folgen 12 neue Regeln, die ab sofort einzuhalten sind] .... bitte übernehmen Sie dieses als Regel in unser Projekthandbuch [ ... das erst 138.237 unterschiedliche Regeln enthält] ..."

Das ist ein Auszug aus einer eMail eines gründlichen Auftraggebers, ergänzt um meine Gedanken beim Lesen.

Es gibt Tage, da bin ich versucht, die Frage nach dem Sinn des Lebens zu stellen. Oder etwas ähnlich tiefgründiges. Oder ich überlege, den Beruf zu wechseln. Oder das Projekt.

Nichts scheint so schwierig zu sein, wie eine Balance zwischen Regelungsbedarf und Gestaltungsfreiheit zu finden. Was für den einen völlig in Ordnung ist, ist für den anderen viel zu viel.

Was der eine als Orientierung braucht, um sorgfältig arbeiten zu können, empfindet der andere als unzulässige Einmischung.

Mir geht es öfter so:
Es gibt Tage, da bin ich für Gestaltungsfreiheit. Absolut und zu 100 %. Und es gibt Tage, da finde ich Regeln völlig in Ordnung. Warum ist das manchmal schwierig und manchmal nicht, habe ich mich gefragt. Es liegt nicht an der "Tagesform". Es liegt an etwas anderem. Nämlich an dem, was hinter der Regel liegt.
Hinter jeder Regel liegt ein Wert. Werte sind interpretierbar. Damit das einfacher wird im täglichen Arbeiten und damit alle in etwa in die gleiche Richtung laufen (oder arbeiten), gibt es Regeln. Regeln erklären einen Wert in einer verkürzten Form, könnte man sagen. Also ist es ganz gut, dass es sie gibt. Aber wie bei den meisten Dingen im Leben, kommt es auf die Dosierung an, und auf den dahinter liegenden Wert.

Oben erwähnter Auftraggeber regelt gerne und viel. Er möchte Qualität. Das ist verständlich. Allerdings vertraut er seinem Projektteam nicht wirklich. Ein Fehler löst dort große Diskussionen und die Frage nach dem Schuldigen aus. Die Nichteinhaltung einer Regel zieht unweigerlich die Definition weiterer Regeln nach sich, die helfen sollen, nichteingehaltene Regeln einzuhalten. Dahinter steht der Wert "Kontrolle". Ganz im Sinne von "Vertrauen ist gut..."

Oje. Wenn jemand noch nicht so ganz sicher Fahrrad fährt (meistens Kinder), können Stützräder helfen. Wenn die Stützräder nicht helfen, helfen Stützräder für die Stützräder auch nicht.

Anderer Tag, anderes Projekt. Wir arbeiten uns im Workshop durch eine Vielzahl an Regelungen. Was ist für den Start des Projektes notwendig, was würde dem Team nur unnötige Mehrarbeit bescheren? Wir definieren auch Regeln. Erstaunlicherweise möchte das Projektteam eine ganz Menge an Regeln im Projekthandbuch verankert wissen. "Braucht Ihr das auch? Haltet Ihr das auch so ein?", das ist die Frage des Projektleiters. Für ihn ist weniger mehr. Er verlangt die Einhaltung weniger Regeln, die dafür konsequent. Wenn etwas nicht klar erscheint oder jemand im Team nach einer Regel ruft, stellt er in paar Fragen. Zum Beispiel "Dient das dem Projektziel?" oder "Was brauchst Du, damit Du das im Sinne des Projektes entscheiden kannst?" "Wenn Du Dich mit der Aufwandsschätzung vertan hast, was müssen wir tun, damit Du beim nächsten Mal genauer sein kannst?" Dahinter steht der Wert "Vertrauen" und "Zusammenarbeit"

Man kann Fahrradfahren auch ohne Stützräder lernen. Am Anfang erscheint das wackelig und gefährlich, aber man lernt schneller, auf was man achten muss, um die Balance zu halten. Und am Anfang hält ja jemand den Sattel, damit man nicht gleich umfällt.


Montag, Juli 28, 2014

PMCamp MUC - DAS PMCamp in München

Das Camp-Wochenende ist vorbei. In München fand zum ersten Mal das PM Camp statt - die Barcamp Veranstaltung für alle Projekt-Interessierten. Es gab Vorträge, Workshops, Lern- und Diskussionsstoff vom feinsten und natürlich in Wiedersehen mit PMCamp Fans.

Unglaublich, wieviel Input eine Konferenz ohne Programm bringen kann.
Meine Highlights waren
1) das BarCamp Phänomen: sich leiten lassen von den Menschen und Ideen, die zusammenkommen und spontan an Themen arbeiten. Ohne lange Vorbereitung in die Tiefe gehen und neue Perspektive entdecken. Effizienter als jedes Seminar und jede "vorbereitete" Konferenz.

(Nicht dass Barcamps keine Vorbereitung brauchen, es gab ein sehr engagiertes Orga-Team, dass keine Wünsche offen gelassen hat! Danke dafür)

2) Diskussionen jenseits von Methoden und Tools im Projektmanagement: es ging um Geisteshaltung und Augenhöhe - 2 wichtige Themen, die sich phantastisch ergänzt haben.Über die Links sind Infiormationen zu den Initiatoren und Impulsgebern zu finden.

3) die Erkenntnis, das wir schon viel von dem umsetzen, was unter Punkt 2 vorgestellt wurde und trotzdem noch viel zu tun ist. Das motiviert weiterzumachen. Es wird neue Projektgeschichten dazu geben.

Soviel als kurzes Blitzlicht auf das vergangene Wochenende - Ich habe viel mehr daraus mitgenommen, denn viele Details kann man im Nachhinein gar nicht berichtetn, man muss es einfach erlebt haben. Und ein Teilnehmer hat es treffend formuliert: "Das ist ein Motivationsschub - der hält bis zum nächsten PMCamp".

Dienstag, Juni 17, 2014

Wie engagiert sind Ihre Projektleiter?

Montag Morgen, 8:00 Uhr. Die Anwendung steht und zwar still. Am Freitag Abend wurde die neue Version aufgespielt. Heute Morgen sollte getestet werden. Die Anwendung steht. Der Testmanager Herbert ist nervös, das sieht man ihm an. 10 Anwender, die von entfernten Standorten angereist sind, um die neue Anwendung zu testen, können nicht arbeiten. Irgendwas ist am Freitagabend schief gegangen, das erst am Montag entdeckt wurde. Dabei wurde doch alles genau geplant. Herbert ist ein kluger Kopf, er kennt die Anwendung genau und weiß, was zu tun ist. Er hat einen Plan erstellt und sich genau vorbereitet.

Doch am Montag Morgen ist Herbert hilflos. Der Plan hat nicht geklappt. Schließlich kann der Test doch starten. Die Kollegen haben improvisiert und Zugriff auf einen Testrechner ermöglicht, auf dem normalerweise kein Anwender arbeiten darf. Zwar verspätet, aber ganz erleichtert startet Herbert den Test mit den Anwendern. Der kleine Nachteil der improvisierten Lösung zeigt sich im Laufe des Vormittags. Die Daten, mit denen die Anwendung getestet wird, sind blanker Unfug. Die Anwender sind verärgert. Und vor lauter Ärger monieren sie einen Mangel nach dem anderen. Was eigentlich gar kein Mangel ist, sondern ursprünglich so gewünscht worden war, wird während des Tests flugs ins Gegenteil verkehrt. 

Herbert kann sich vor Beschwerden kaum retten. Er muss bei seinem Projektleiter "antreten" und den Verlauf der Tests erklären. Das fällt ihm schwer – schließlich kann er nichts dafür, dass die neue Version nicht zur Verfügung stand. Und das Recht, den Kollegen im Rechenzentrum auf die Sprünge zu helfen hat er schließlich auch nicht. Der Projektleiter ist genervt….

Peter, Testmanager im Nachbar-Projekt hatte neulich ein ganz ähnliches Problem. Peter plant nie besonders genau. Das Aufspielen der neuen Version seiner Software hatte nicht funktioniert. Über  Nacht arbeiteten er und sein Team an der Lösung, um den Anwendern am nächsten Tag die versprochenen Funktionen zeigen zu können. Peter hatte bei den Kollegen im Rechenzentrum angerufen, und Hilfe organisiert. Jenseits aller Absprachen, Sicherheitsvorgaben und Pläne, aber es hatte geklappt. Alle waren durchgeschwitzt und müde, aber am nächsten Morgen war der Fehler behoben. Die Freischaltung der Software kann pünktlich erfolgen. 

Der Projektleiter hat inzwischen für solche Fälle ein Budget für Extra-Rationen Cola und Pizza.
 


Mit welchem Testmanager würden Sie lieber zusammen arbeiten? Mit Herbert, der alles akribisch plant und sich auf die Kollegen verlässt? Oder mit Peter, dessen Pläne durchaus auch Lücken aufweisen können, der aber kreative Lösungen findet, wenn es drauf ankommt?
Peter hat immer einen lockeren Spruch auf den Lippen. Aber bei allen flotten Sprüchen merkt man, dass er ein begeisterter Testmanager ist. Bei Herbert ist den Kollegen nicht so ganz klar, wofür er sich begeistert. Er erzählt ja auch wenig. Aber seine Pläne sind immer ganz akribisch.
 

Was ist das Fazit dieser Geschichte?
 

In etwa so:
 

a)    Ein Projekt ist ein komplexes, dynamisches System: irgendetwas geht immer schief. Pannen müssen ausgebügelt werden, um doch noch ans Ziel zu kommen. Regeln helfen da oft nur bedingt weiter. Das Zusammenspiel der Beteiligten ist genauso wichtig wie der Rahmen, der durch einen Meilensteinplan oder Termin vorgegeben ist. Manchmal sogar wichtiger.

b)    Pläne neigen dazu, sich nicht an die Realität zu halten. D. h. es kommt sehr oft irgendetwas, meistens etwas Banales dazwischen, das niemand vorhergesehen hat. Die beste Planung nutzt nichts, wenn ich mich nur auf den einen Plan verlasse.

c)    Es gibt Menschen die kommen damit besser klar als andere. Das hat nichts mit der fachlichen Kompetenz zu tun, wohl aber mit der Leidenschaft, mit der sich der Mensch für ein Thema engagiert und Lösungen abseits des Projektplans sucht.

Montag, Juni 02, 2014

Auf gehts zum PMCamp München - Anmelde-Start!

Das erste PMCamp in München legt los.
Termin: 24.- 26.07.2014
Ab sofort sind die Anmeldungen möglich.

Das EBH-Team unterstützt das PM Camp in München. Für uns ist es eine wertvolle Plattform zum Know How- und Erfahrungsaustausch, zum Diskutieren, Philosophieren, Sinnieren zu allem Themen im und um´s Projektmanagement.
Leute, schaut vorbei, es lohnt sich wirklich.