Schlagwort: Werkzeuge

Ein kurzes Wort zum Sonntag: Ordentliches Handwerk

Ein kurzes Wort zum Sonntag: Ordentliches Handwerk

Diese Woche hatte ich einen spannenden und erfolgreichen Workshop mit einer Software-Entwicklungsabteilung. Dieser Workshop hat mich an wichtige Grundsätze und einen alten Beitrag erinnert. Es wird viel über Management-Methoden und Philosophien debattiert, manchmal liegt der Schlüssel zum Erfolg jedoch viel näher – und zwar in ordentlicher handwerklich gut ausgeführter Arbeit. Für den Bereich der Software-Entwicklung habe ich Grundsätze ordentlicher Arbeit vor längerer Zeit schon einmal formuliert: “15 Punkte für gute Software (…)” Den Gedanken der “ordentlichen Arbeit” werde ich im Laufe der nächsten Woche auch auf das Projektmanagement übertragen…
Lektion gelernt? Ein persönlicher Rückblick.

Lektion gelernt? Ein persönlicher Rückblick.

Vor längerer Zeit hatte ich schon einmal einen Beitrag über meine persönlichen “Lessons Learned” der Projektarbeit geschrieben. Dieser alte Beitrag ist mir während der Arbeit an einem Grundlagenartikel für #openPM noch einmal in die Hände gefallen. Bis auf kleine redaktionelle Korrekturen würde ich meine persönlichen Lektionen wieder so niederschreiben. In diesem Sinne: Meine ganz persönlichen “Lektionen” sind die folgenden:
  • Misstraue großen Projektorganigrammen!
  • Das ultimative PM-Werkzeug gibt es nicht.
  • Druck und Angst sind die Sargnägel eines Projektes.
  • Projekt Kultur ist wichtig(er).
Misstraue großen Projektorganigrammen! Der Projektleiter berichtet an den Lenkungsausschuss. Der Lenkungsausschuss ist Teil des Projekt-Kommitees und wird vom Projektsteuerungsausschuss beraten. Alle Gremien berichten an das Projekt-Management-Steuerungsboard, dieses gleicht mir den Berichten aus dem Projekt-Controlling-Panel ab und berichtet an die Geschäftsführung, die wiederum dem Aufsichtsrat berichtet. Der für Projekte zuständige Aufsichtsrat sitzt wiederum im Steuerungsboard um die Anforderungen der zentralen Unternehmensentwicklung in Personalunion abzugleichen. Wehe dem Projektleiter, der in diesem bermudianischem Vieleck ein Projekt leid(t)en muss. Ausufernde Projektorganigramme mit einer Vielzahl von Kontroll- und Steuerungsgremien sind oft Ausdruck einer Verunsicherung bzw. spiegeln das große Risiko und das vorhandene Bedürfnis zur Absicherung wider. Solche Kontrollstrukturen können zur Quelle überbordender und unklarer Anforderungen oder als Nährboden für Auseinandersetzungen dienen. Auseinandersetzungen, die nicht originär mit dem Projekt zusammen hängen aber dennoch in diesem ausgetragen werden können. Das Projekt kann gewissermaßen zum Schauplatz dieser Auseinandersetzungen werden. Die Einsetzung und Existenz dieser Gremien liegt oft außerhalb der Verantwortung des Projektleiters. Allerdings lassen sich diese Schnittstellen der Gremien zum Projekt durchaus beeinflussen. Mit der Gestaltung des Informationsflusses lassen sich Schnittstellen in Organisationen gestalten. Der Informationsfluss und damit auch die Schnittstellen sollten so klar und schlank wie möglich gestaltet werden. Standardisierte, klar strukturierte und regelmäßige Informationen können hier sehr viel helfen. Dies kann z.B. ein wöchentliches Projektjournal ggf. mit verschiedenen Zusammenfassungen für unterschiedliche Gremien sein. Dies trägt wesentlich dazu bei, dass die Informationshoheit bei der Projektleitung liegt und der Projektleiter nicht zum Spielball der Auseinandersetzungen zwischen den Gremien wird. Das ultimative PM-Werkzeug gibt es nicht. Die Ãœberschrift ist die Essenz aus vielen Experimenten mit jeglichen Formen von Projektmanagement Werkzeugen. Ich habe viele Kombination von Werkzeugen erlebt und konnte für keines eine besondere Korrelation mit dem Projekterfolg feststellen. Jedes Werkzeug, das ich kenne, wird in erfolgreichen und nicht erfolgreichen Projekten eingesetzt. Die Schlussfolgerung, die ich aus vielen Projekten gezogen habe lautet, jedes Projekt braucht sein eigenes Werkzeug mit dem gearbeitet werden kann und mit dem die Beteiligten arbeiten wollen. Ein Beispiel aus einem Softwareentwicklungsprojekt: Das schönste Bugtracking System nutzt nichts, wenn der Auftraggeber regelmäßig (s)eine Excel-Liste mit allen offenen Bugs haben möchte. Jetzt kommt es darauf an ob das Tool einen Excel Export in eine Vorlage unterstützt – wenn nicht steht Doppelpflege oder der Verzicht auf das Tool ins Haus. Für die Wahl von Projektmanagement Werkzeugen habe ich mir folgenden Satz hinter die Ohren geschrieben: “Nimm das Tool, das die wichtigen Menschen im Projekt nutzen können und wollen.” Ein bestimmtes Werkzeug – und sei es noch so gut – zu “erzwingen” verursacht nur unnötigen Stress. Und noch ein Merksatz mit schmunzelndem und leicht resigniertem Unterton: “Die ganz persönlichen Vorlieben des Projektleiters müssen in der Werkzeug-Frage oft zurück stehen”. Druck und Angst sind die Sargnägel eines Projektes. Menschen unter Druck arbeiten nicht schneller, sie machen lediglich mehr Fehler und vermeiden Risiken. Beides ist für Projektarbeit sehr hinderlich. Jeder Fehler muss irgendwann korrigiert werden und verbraucht dann noch mehr der knappen Zeit. Problemlösung und die Suche nach neuen Lösungen funktioniert nur mit Kreativität, die untrennbar mit einer gewissen Risikobereitschaft verbunden ist. Wenn niemand sich traut Risiken einzugehen sieht es schnell sehr düster aus. In vielen Projekten kommt dieser Zeitpunkt an dem die verbleibende Zeit aussichtslos knapp erscheint. Und wenn die Ãœberstunden noch so naheliegend erscheinen sind andere Strategien besser:
  •     Abhängigkeiten überprüfen und Aufgaben neu priorisieren
  •     Aufgaben ggf. umverteilen
  •     Mit dem Auftraggeber verhandeln
Mit dem Druck kommt auch die Angst: Angst der Mitarbeiter vor Fehlern, Angst die Verantwortung für Terminüberschreitungen aufgedrückt zu bekommen. Ein Klima der Angst verhindert auch ein wirksames Risikomanagement. Wenn die Angst und das Misstrauen Einzug gehalten haben, werden potentielle Risiken gerne verschwiegen, schließlich will keiner der Buh-Mann sein, wenn das Risiko zur Wahrheit wird. Die Angst kommt meistens auf leisen Sohlen kündigt sich aber mit folgenden Anzeichen an:
  • Kollegen werden schweigsamer.
  • Es wird zunehmend über die Aufgaben anderer und nicht über die eigenen gesprochen.
Dem möglichen Klima der Angst sollte so gut wie möglich präventiv begegnet werden. Ein sehr wichtiger Baustein dieser Prävention ist ein stabiles Wohl-Gefühl der Zugehörigkeit zum Projekt. Mit anderen Worten – und damit komme ich zum letzten Punkt – im Projekt sollte eine “echte” Projektkultur vorhanden sein. Projektkultur ist wichtig! Wichtiger, noch wichtiger, am wichtigsten … um keine Missverständnisse aufkommen zu lassen möchte ich den Begriff der Kultur genauer fassen. Unter einer Projektkultur verstehe ich einen Konsens aus den individuellen Kulturbeiträgen der Projektmitarbeiter sowie der firmen- bzw. abteilungsspezifischen Subkulturen. Ich spreche also von der konkreten Subkultur jedes einzelnen konkreten Projekts und nicht von einer ggf. in der Organisation definierten Projektvorgehensweise, die häufig auch als Projektkultur bezeichnet wird. Wenn in einer Projektgruppe eine eigene Kultur entsteht, entsteht auch ein Gefühl für Heimat, eine Identifikation mit dem Projekt. Nichts Besseres kann einem Projekt passieren, dass die Mitarbeiter sich mit dem Projekt identifizieren. Es ist eigentlich leicht zu sehen, wenn eine Gruppenkultur entsteht, man muss nur die Augen offen halten um nicht versehentlich das wachsende Kultur Pflänzchen im Keim zu ersticken. Es lohnt sich nach den folgenden oder ähnlichen Dingen Ausschau zu halten:
  •     Es werden Witze erzählt.
  •     Alle können mitlachen, wenn Witze erzählt werden.
  •     Nach einer Weile gibt es Insider Witze, die Außenstehende nicht verstehen.
  •     Es entsteht eine gemeinsame Arbeits- und Pausenorganisation z.B. ein gemeinsames Whiteboard mit Zetteln oder eine gemeinsame Keks-Schublade.
Es gibt Rituale oder Symbole z.B. Begrüßungsformen. Projektlogo, Türschilder. Jedes noch so kleines Anzeichen einer wachsenden Kultur sollte gepflegt werden. Und wenn die ersten Witze noch so lahm sind, ist es dennoch wichtig den Raum und die Zeit dafür zu geben. Diese Zeit ist gut investiert. Eine Gruppe, die eine eigene Kultur entwickelt ist auf dem besten Weg zum Team und ein funktionierendes Teams ist ein wichtiger Erfolgsfaktor für Projekte. Zum Schluss möchte ich die oben genannten “Lessons” noch ein Mal mit anderen Worten in Form von kurzen ToDo-Anweisungen zusammenfassen:
  • Mache die Schnittstellen zu Gremien so klar wie möglich. Ãœbernehme die Informationshoheit.
  • Nimm das PM-Werkzeug, das halbwegs funktioniert und den geringsten Stress verursacht.
  • Achte auf die Zeichen der Angst.
  • Pflege das Projekt-Kultur Pflänzchen. Gib ihm eine Chance. Achte auf das Lachen.
Und zu guter Letzt möchte ich einen ehemaligen Projektleitungskollegen zitieren – er war für ein größeres Gesamtprojekt verantwortlich, ich für das technische Teilprojekt. Auf die Frage wie er den technischen Projektfortschritt immer richtig einschätzen konnte, antwortete er: “Ich habe nur gelauscht ob ihr lacht” – Projekte machen Spaß!  
target hopping

target hopping

Heute eine kleine Anekdote zum Wochenende. Das heißt es ist ein kurzer Aufschrei einer geplagten Projektleiterseele, die nach 25 Jahren Projektarbeit eine völlig neue Erfahrung machen musste durfte. Auch bei noch so gründlicher Vorarbeit sind in der Regel zu Beginn eines (Software-) Projektes nicht alle Anforderungen bekannt (siehe Bild bzw. Beitrag: agil ist besser?! ). Dass sich die bekannten Anforderungen dann auch noch verändern gehört zum Alltag. Nicht umsonst gibt es den Begriff des “moving target” – das Ziel bewegt sich, das Treffen wird erschwert. Agiles Vorgehen ist eine Antwort auf das “moving target”. Solange sich das Ziel nur bewegt besteht wenig Grund zur Sorge. Mit gründlicher Beobachtung und etwas Ãœberlegung lässt sich erahnen wohin der Hase läuft. Fatal wird es jedoch wenn der Hase einen Superkräfte-Möhrensaft-Cocktail trinkt und mit Riesenkräften einen Sprung in die andere Richtung macht und plötzlich verschwunden ist. In dieser Situation befinde ich mich gerade. Eine SW-Entwicklung kurz vor dem Abschluss, dann kommt ein Anruf, dass eine grundlegende Konzeptänderung notwendig ist. Wie das neue Konzept aussehen wird ist aber noch nicht klar. Klar ist nur, dass das alte nicht passt. Innerhalb von Minuten sitzt man vor einem scheinbaren Scherbenhaufen:
  • möglicherweise ist ein großer Teil des Codes für den Mülleimer
  • Projektpläne und Berichte haben nur noch Altpapierwert
  • das Gefühl “gleich haben wir es geschafft” ist weg
  • ein (Schuld)-Gefühl “warum ist das nicht aufgefallen” kommt hoch
  • Budget(planungen) sind im Eimer
Tief durchatmen – keine Panik. Was ist zu tun?
  • Ordentliches Release fertig bauen,
    vielleicht wird der Umbau doch nicht so schlimm wie befürchtet.
  • Erste spontane Ideen für den Konzeptumbau sichern.
  • Mit anderen Aufgaben, zu denen keine Abhängigkeiten bestehen, weiter arbeiten.
  • Pläne werden erst angepasst wenn der Hase wieder sichtbar ist.
Dann nochmal durchatmen und in Ruhe eine Tasse Heißgetränk (in meinem Falle Kräutertee) konsumieren. Was ich aus dieser unerwarteten Wendung lerne, weiß ich noch nicht, sie hat mir aber deutlich gezeigt, wie wichtig eine gewisse Ordnung, Dokumentation und Werkzeugeinsatz sind. Der Zielwechsel wird auf Basis einer geänderten Spezifikation, den bisher im Bugtracker dokumentierten Fällen und den lauffähigen Releases im Versionsmanagementsystem halbwegs stressfrei möglich sein. Nicht auszudenken, wenn der Code unversioniert und nicht lauffähig wäre. Wie dem auch sei, auf jeden Fall ist mein Anekdotenschatz wieder um eine Geschichte reicher.
Projekte lassen sich nicht managen

Projekte lassen sich nicht managen

Die Ãœberschrift klingt provozierend. Definitiv! Vielleicht kann ich aber doch den einen oder die andere bewegen meinen Gedankengängen zu folgen. So viel sei versprochen, am Ende werde ich die Ãœberschrift zumindest ein wenig relativieren können. Im Zusammenhang mit Projekten beschäftigen mich die Begrifflichkeiten Leitung und Management schon länger. An anderer Stelle hatte ich bereits folgende Sätze formuliert:
Management hat von der begrifflichen Bedeutung viel mit Verwaltung und Steuerung nach Parametern zu tun. Die Ãœberhöhung des Manager-Begriffs im deutschen Sprachraum hat keine deckungsgleiche Entsprechung in der Herkunftssprache. Im englischen Sprachraum gibt es auch den Facility Manager den man in Deutschland vielleicht Hausmeister nennen würde. Sicher ist die Ãœbersetzung etwas überzogen, dennoch zeigt sie auf, dass der Begriff Management ursprünglich anders verwendet wurde. Siehe Projekte leiden, leiten oder managen
Eine weitere “Unsinnigkeit” des Management-Begriffs ist mir kürzlich wieder aufgefallen als ich im Epic.graphic Blog ein Bild sah, das eindrucksvoll den Unterschied zwischen Daten, Information und Knowledge aufzeigt. data cake Die Daten entsprechen den reinen Zutaten, Information und Präsentation dem zubereiteten Kuchen. Knowledge hingegen ist der gegessene Kuchen. Knowledge ist in gewisser Weise die erprobte Information oder Erfahrung. Für mich ist dieses Bild eine sehr treffende Metapher. Es stellt sich im Anschluss aber die Frage: “Was kann dann Knowledge-Management sein? Verwaltung von Erfahrung, Verwaltung von Aha-Effekten, die sich beim Lernen eingestellt hatten. Verwaltung der Sinneserfahrung beim Essen eines Kuchens? Knowledge – das heißt das Essen des Kuchens – lässt sich nicht verwalten. Nur die Zutaten und die Rezepte lassen sich verwalten. Im Laufe der Jahre komme ich immer mehr zu der Ãœberzeugung, dass es sich mit dem Managen von Projekten ähnlich verhält. Materielle Ressourcen, Planzahlen, Aufwandschätzungen lassen sich problemlos verwalten. Dass die Verwaltung dieser Aspekte wichtig ist stelle ich nicht in Abrede. Zum Erfolg eines Projektes gehört aber immer noch etwas mehr. Selbst wenn alles perfekt bereitgestellt wird, alle Zeitpläne sich als realistisch heraus gestellt haben, niemand aus dem Projektteam abgezogen wurde oder überlastet ist bleibt immer noch die “Kleinigkeit” eine fruchtbare Zusammenarbeit zu ermöglichen. Dann kommen die Begriffe Führung, Inspiration, Motivation, Leadership usw. ins Spiel. Ich fasse das alles unter dem simplen Begriff Leitung zusammen. Leiten bedeutet: Begleiten, einen Weg weisen, bei Bedarf an die Hand nehmen oder eben wenn alles läuft nur noch leise mitgehen und aufpassen. Zur Leitung gehört definitiv eine gute Vorbereitung und auch eine Portion Management. In der Sprache der Mathematik würde ich demnach Management als notwendig aber nicht hinreichend bezeichnen. Es ist bei diesem Verständnis der Begriffe auch nicht zwingend notwendig, dass der Manager das höchste Gehalt bezieht – spätestens hier schmerzt die Provokation. Ich wünsche mir, dass Management etwas kleiner wahrgenommen wird. Der Projekt-Manager im Projekt erfüllt nur einen Teil der Aufgaben im Projekt. Es gibt Projekte in denen Management sehr wichtig ist – es gibt aber auch Projekte in denen Management nur eine marginale Bedeutung hat. Die Ãœberbewertung des Managements führt gelegentlich auch zu unpassendem Methodeneinsatz. Manche Projekte werden unter einem Berg von Management-Methoden regelrecht begraben. Ich wünsche mir mehr Leitung und mehr Fingerspitzengefühl beim Einsatz von Management (=Verwaltung). Lasst uns Schrauben mit Schraubendrehern und Nägel mit Hämmern bearbeiten. Manchmal – so scheint es mir – werden in Projekten Nägel mit den Griffen von Bohrmaschinen eingeklopft.
Schau auf die Schreibtische

Schau auf die Schreibtische

Vor einiger Zeit hatte ich über die Legende der Web 2.0 Werkzeuge geschrieben. Der Kern des Beitrages lässt sich in folgenden Sätzen zusammenfassen:
Informationsaustausch war noch nie ein Problem des Werkzeuges und wird nie durch den Einsatz eines Werkzeuges gelöst werden. Entscheidend ist die Bereitschaft jedes Mitarbeiters sein Wissen preis zu geben. … Die Bereitschaft der Menschen zu teilen ist wichtiger als jedes Werkzeug.
In einer Diskussion wurde ich auf einen weiteren Punkt aufmerksam gemacht, den ich bisher übersehen hatte. Vorausgesetzt die Bereitschaft zum Teilen der Information und ein Werkzeug sind vorhanden verbleiben immer noch die individuellen Unterschiede der Menschen im Umgang mit Informationen. Ein Zitat aus der erwähnten Diskussion:
… dass übergestülpte Wissensmanagementkonzepte … den eigenen, gedanklichen Ablagestrukturen widersprechen. Man sehe sich nur mal die Schreibtische von zehn beliebigen Mitarbeitern an und vergleiche diese 😉1
In der Tat – ein Blick auf die Schreibtische offenbart vieles. Wuchernde Stapel, Post-it Collagen, fein säuberlich beschriftete Ordner und Register, Notizbücher mit und ohne Post-it Anreicherungen. Das lässt sich natürlich anekdotisch schmunzelnd betrachten – das halte ich aber für zu kurz gegriffen. Der persönliche Umgang mit Information hängt eng mit den kognitiven Vorlieben und Fähigkeiten zusammen. Jede(r) lernt anders. Einen “richtigen” Weg gibt es nicht. Das Verordnen von Vorgehensweisen, die den eigenen kognitiven Vorlieben widersprechen, kann leicht Unwohlsein und nachfolgend eine Verweigerungshaltung hervorrufen. Gerade das Beispiel mit dem Schreibtisch ist hier sehr lehrreich. Ich schlage ein Gedankenexperiment vor: Jede(r) möge seinen Schreibtisch genau anschauen und sich dann einen Schreibtisch eines Kollegen oder einer Kollegin vorstellen, der völlig anders aussieht. Und nun das Experiment: Stellt Euch vor eine Woche am anderen Schreibtisch zu arbeiten ohne ihn verändern zu dürfen. Eine gruslige Vorstellung! So geht es vielleicht vielen wenn sie gezwungen wird Informationen in ein System einzugeben. Dieses Unbehagen befällt den Zettel-Stapel-Wirtschafter, der Daten in ein Formular mit Kategorien und Schlagworten eingeben muss in gleicher Weise wie den Ordnerregister-Beschrifter, der formlos in ein Microblogging Tool tippen soll.
  1. Diskussion auf Facebook, nur mit facebook Login erreichbar:Informationsaustausch war noch nie ein Problem des Werkzeuges []
© pentaeder 2019 / 2020