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.

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.

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.

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 ¹

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

• I – wie Information
• B – wie Beratung
• E – wie Entscheidung

Information – wird in der Regel von einem Teilnehmer mitgeteilt, die anderen hören zu. Nachfragen zum Verständnis sind erlaubt, Diskussionen sollten vermieden werden. Wenn sich Diskussionsbedarf abzeichnet sollte dies vertagt werden und in einen neuen Beratungspunkt münden. Im Protokoll kann die Information nochmals wiederholt und ggf. durch die Antworten auf die verständnisfragen ergänzt werden.

Beratung – hier darf diskutiert werden. Meinungen werden ausgetauscht, Meinungen verändern sich. Im Protokoll sollten die geäußerten Meinungen und Ansichten dokumentiert werden.

Entscheidung – der Diskussionsstand wird nochmals zusammengefasst und eine Entscheidung getroffen. Im Protokoll wird die Entscheidung und nichts anderes dokumentiert.

Was bringt diese Typisierung der Tagesordnungspunkte. Sie erhöht die Verbindlichkeit. Ohne die explizite Unterscheidung der Punkte gehen Information, Diskussion und Beratung leicht ineinander über. Im Protokoll stehen dann viele unterschiedliche Aspekte ohne dass klar ist, welche Punkte nur diskutiert und welche wirklich entschieden wurden. Manchmal beruft sich jeder auf einen anderen Halbsatz im Protokoll, irgendwie haben dann alle recht und alle machen weiter wie sie denken.

Lassen sich mit einer Typisierung alle Besprechungen effizient gestalten? Nein, nicht immer – das liegt daran, dass wir Menschen sind und auch im ernsten Business Alltag nach Austausch suchen. Bei der Vorbereitung von Terminen sollte man das immer im Hinterkopf behalten und auch in der Planung der Besprechung berücksichtigen (Zeitstruktur, Pausen, Smalltalk).

Es spricht übrigens nichts dagegen die Typisierung auch mit einem Augenzwinkern zu erweitern. Ich selbst hatte auch in wichtigen Besprechungen als ersten Tagesordnungspunkt schon Nachbesprechungen von Fußballspielen stehen.

Zu guter letzt ein Bild wie ein Protokoll einer derartigen Besprechung aussehen könnte und ein Word-Dokument als Protokollvorlage.

1. Auch wenn man Scrum macht, heißt das noch nicht, dass man keine normalen Besprechungen mehr benötigt. Spätestens dann wenn der Scrum-Master sich um die Beseitigung von impediments kümmert wird er auch Besprechungen mit team-fremden Teilnehmern benötigen.

• Klares Ziel festlegen
• aus dem Ziel eindeutigen Teilnehmerkreis ableiten
• Agenda erstellen
• sich an Agenda halten, Zeit begrenzen

hält sich das formlos ausufernde Meeting hartnäckig am Leben.
Müssen deshalb die Regeln besser eingeübt werden? Ich denke “Nein”. Es gibt Gründe und Tagesordnungspunkte für ein Meeting, die sich tatsächlich nur schwer als Ziel formulieren lassen. Das ist mir deutlich geworden als mir das erste Mal der Begriff der “Beratung” begegnet ist. Im ersten Moment war ich verwundert, dass zu einem Beratungs-Termin eingeladen wurde und nicht das gebräuchliche englische Wort verwendet wurde. Mit dem zweiten Gedanken entdeckte ich die tiefere Bedeutung. Es macht Sinn sich über schwierige oder komplexe Themen zu beraten um z.B. eine Entscheidung vorbereiten zu können. Dann ist es nur logisch das Kind auch beim richtigen Namen “Beratung” zu nennen. Inzwischen verwende ich den Begriff der Beratung auch für einzelne Tagesordnungspunkte – das hat den Vorteil, dass der Punkt nicht zwingend zu einen Ergebnis kommen muss. Ein weiterer Vorteil ist, dass eine klare Abgrenzung zu einem Entscheidungspunkt, vorhanden ist. Ein im Protokoll dokumentierter Beratungsstand ist (noch) keine Entscheidung.

Fortsetzung folgt

1. Office-Textverarbeitung und Tabellenkalkulation gleichauf mit 70 %
2. dicht dahinter Stift und Papier mit 65 %
3. MS Project 50 %
4. Mindmapping 35 %
5. Webbasierte PM Systeme 34 %
6. andere SW 22 %

In den meisten Projekten werden unterschiedliche PM-Werkzeuge eingesetzt. Beruhigend ist, dass die Option “keine Werkzeuge” inzwischen unter 2% liegt.