Das Teamwork-Blog

Eine große Menge an teaminternem E-Mail-Verkehr entsteht, weil man sich über ein bestimmtes Dokument austauscht. Möglichweise auch noch das betreffende Dokument als Anlage mitschickt. die unguten Folgen dieses Vorgehens wurden hier schon öfter erläutert (/1/).  Heute stelle ich eine sehr einfache Funktion von OneNote vor, die erlaubt, Notizen zu einer Word- oder PowerPoint Datei an zentraler Stelle zu erstellen und diese direkt mit der bearbeiteten Stelle des betreffenden Dokumentes zu verknüpfen.

Eine bewusst zweideutige Formulierung einer gar nicht eindeutigen Frage. Jedoch liebt Teamworkblog die zweideutigen Fragen, denn sie erleichtern ihm seine chamäleonhaften Antworten.

Kanban, esp. Personal Kanban is very popular. Last year we published a short description how to build a Kanban system in Microsoft Outlook. In general we post our ideas here in German language. One of our readers suggested to translate the original German post into English language (credits to M. B.). So, here it is. I appreciate any comments (and corrections of my spelling). ( Von diesem Beitrag gibt es eine deutsche Version .)

In der letzten Woche habe ich etwas über agile Projektverträge geschrieben (/1, 2, 3, 4/). Es fehlt noch die Rollenbeschreibung für denjenigen, der auf Lieferantenseite den Vertrag ausarbeitet und sich um die Workshops kümmert. Hier ist mein Vorschlag. 

Ein Thema, mit dem agile Projektmanager Abende füllen können, ist die Frage: Wie gestalte ich die Vertragsbeziehung zwischen Kunde und agilem Dienstleister? Im ersten Teil haben wir uns die möglichen Vertragsarten angesehen. Im zweiten Teil haben wir festgestellt, dass es in den meisten Projektsituation gar nicht möglich ist, Anforderungen und Design früh festzulegen. Im dritten Teil habe ich gezeigt, dass wir uns auf die betrieblichen Änderungen konzentrieren müssen, wenn wir über IT-Systeme verhandeln. Hier nun meine Empfehlungen für einen Projektvertrag.

Ein Thema, mit dem agile Projektmanager Abende füllen können, ist die Frage: Wie gestalte ich die Vertragsbeziehung zwischen Kunde und agilem Dienstleister? Im ersten Teil haben wir uns die möglichen Vertragsarten angesehen (/1/). Im zweiten Teil haben wir festgestellt, dass es in den meisten Projektsituation gar nicht möglich ist, Anforderungen und Design früh festzulegen (/2/) . Es gibt dennoch eine Methode, mit der beide Seiten herausfinden, was das Projekt genau liefern soll. Und zwar unabhängig von der IT-Lösung. Wie das geht, erkläre ich in diesem Teil.

Ein Thema, mit dem agile Projektmanager Abende füllen können, ist die Frage: Wie gestalte ich die Vertragsbeziehung zwischen Kunde und agilem Dienstleister? Im ersten Teil haben wir uns die möglichen Vertragsarten angesehen (/1/). Für ein Projekt ist ein Dienstvertrag an guter Startpunkt. Aber wie gehen wir denn nun genau vor, wenn wir Leistungen nicht von vorn herein spezifizieren können? Dazu sollten wir erstmal einen Blick auf die Natur des Projekts werfen, dass beide Parteien planen. Darum geht es in diesem Beitrag.

Ein Thema, mit dem agile Projektmanager Abende füllen können, ist die Frage: Wie gestalte ich die Vertragsbeziehung zwischen Kunde und agilem Dienstleister? Wie gehe ich mit Leistungen um, die (eigentlich) als Festpreis ausgeschrieben werden müssen? In der agilen Community gibt es in paar Ideen. Hier sind meine.

Nur wenige Projekte zur Einführung von Dokumentenmanagement-Systemen bringen ihren Kunden den Nutzen, den diese sich davon erhoffen. Im zweiten Teil unserer Serie beschäftigen wir uns mit dem Thema „Workflow von Rechnungen und Belegen“, auch oft als „digitale Rechnungsbearbeitung“ bezeichnet. Unsere These: Der Belegworkflow spielt in den Werbeschriften der DMS-Hersteller zwar immer eine große Rolle. Darauf aber die Auswahl eines DMS-Produkts zu stützen, wäre eine völlige Fehlentscheidung.

In meinem letzten Blogartikel //1// habe ich Ihnen die Kategorien in Outlook vorgestellt. Technisch ist das Thema wenig aufregend (abgesehen von der bedauerlichen Tatsache, dass die Kategorien nicht zentral gesteuert werden können). Wie aber kategorisiert man klug? Welche Begriffe eignen sich und was genau nützen die Kategorien? <

Darüber wie man ein Unternehmen, Team oder Projekt führt, gibt es bekanntlich viele Meinungen. Es gibt Methoden und praktische Erfahrungen, über die sich vortrefflich debattieren lässt. Selbst wenn sich ein Team auf ein Vorgehen geeinigt hat, können uns der Kontext und kognitive Verzerrungen (/1/) einen Strich durch die Erfolgsrechnung machen. Wie kommen wir aus diesem Dilemma heraus?  Aus meiner Sicht ist ein Erfolgsfaktor von Scrum, dass dort Wert auf ein empirisches Vorgehen gelegt wird. Das bedeutet, dass man arbeitet, sich verbessert und dann misst. Ändert sich die Produktivität oder nicht? Wenn ja, geänderte Arbeitsweise beibehalten; wenn nein, weiter anpassen (inspect and adapt). Zu solch einem Vorgehen gibt es gute Anregungen in Buchform.

Liebe Leser und Freunde des Teamworkblogs, wir würden gern mehr darüber erfahren, wie es Euch in Euren Teams geht. Dazu haben wir eine kleine Umfrage bei Tricider angelegt, die bis zum 19.04.2013 läuft.

Projekte treibt man voran, indem das Team Ergebnisse liefert (/1/). Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich Beispiele vor.

Nach dem Studium habe ich bei einer Unternehmensberatung angefangen.  Ich war von  dynamischen Projektmanagern beeindruckt. Ständig riefen sie jemanden an und machten Druck, damit alle Beteiligten ihre Termine einhalten. Inzwischen habe ich eine andere Meinung darüber, wie man in Projekten für Fortschritte sorgt. Man treibt Projekte voran, in dem man Ergebnisse liefert.

Projekte zur Einführung von Dokumentenmanagement- bzw. ECM-Software /1/ haben zur Zeit wieder Konjunktur. Aber nur wenige Projekte bringen den Anwendern (und damit den Unternehmen oder Verwaltungen) den Nutzen, den diese vorher erwarten. Teamworkblog startet heute eine Serie, in denen wir Projektleitern aus IT und Orga konkrete Ratschläge für gelingende Projekte geben.  Heute: Warum die IT (die meistens die Projekt-Ownership hat) etwas anderes bestellt, als die Anwender später brauchen.

Gestern (am 25.03.2013) brachte das heute journal einen Beitrag über den E-Mail-Wahnsinn (/1/). Jetzt hat es das Thema von der Titelseite (siehe Handelsblatt-Ausgabe vom 27.11.2012, /2/) bis in die Hauptnachrichtensendung eines großen Fernsehsenders geschafft. Unserer Erfahrung nach können Teams den Wahnsinn schon mit ein paar gemeinsamen Regeln eindämmen. Hier ist unser Vorschlag für E-Mail-Regeln als Grundlage für Ihre Diskussion in Ihrem Team.

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Sicher haben Sie schon davon gehört, wie gutes Zuhören die Teamproduktivität erhöht. Sie wissen wie man aktiv zuhört, streuen hier und da ein „Mh“ oder „Hm“ bei der nächsten Powerpointpräsentation oder beim Mitarbeitergespräch ein? Sie haben in einem NLP-Training schon gelernt wie man Rapport herstellt? Aber wie sicher sind Sie, dass Ihr Gegenüber wirklich das Gefühl hat, dass Sie ihm zuhören?

Wie oft haben wir schon erlebt, dass ein dummer Spruch vom Chef das Team demotiviert. Andersherum kann eine einfühlsame Sprache Teams helfen, kritische Situationen zu meistern. Was sind die kritischen Punkte, auf die Teams beim Sprechen achten sollten? Müssen wir alle Psychologen werden, um richtig zu sprechen? Nein. Ich finde dazu das Konzept der gewaltfreien Kommunikation nützlich.

Es gibt Probleme, die nur komische Leute wie Blogger oder Autoren haben. Es geht darum, dass man zu einer bestimmten Zeit einen Text fertig haben will und es fällt einem nichts ein. Entweder hat man keine richtige Idee oder man landet in Trivialitäten, die völlig uninteressant sind. Übertragen gilt das auch für andere Bereiche. Man will an etwas arbeiten und macht nur wenig Fortschritte. Nach einer Experimentierphase haben wir eine Lösung für uns gefunden.

Immer wenn es um neue Projekte geht, wird der Ruf nach einer ausführlichen Anforderungsanalyse laut. Und wenn es in laufenden Projekten Ärger gibt, heißt es schnell: "Hätten wir uns mal mehr Zeit für die Anforderungen genommen ...". PRINCE2, Scrum oder SAFe sagen wenig zum Umgang mit Anforderungen. Merkwürdig, wo es doch so viel ausführliche Literatur darüber gibt, wie man an die Kundenwünsche kommt und die Anforderungen erhebt, verarbeitet, validiert und testet. Verzichtet man bei agiler Arbeitsweise auf Anforderungsmanagement? In diesem Beitrag zeige ich, wie PRINCE2, Scrum und das Scaled Agile Framework (SAFe) mit Anforderungen umgehen.

Unvorbereitet(?) sprechen müssen?  Einfache Erfolgsformeln für spontane Redesituationen im Beruf

Die Verbesserung unserer Büroprozesse muss neue Wege gehen. Aber der Ruf nach „neuen Wegen“ ist ein alter Hut. Das Teamworkblog hat ein paar Ideen. Aber sind die wirklich neu? Dazu brauchen wir das Feedback unserer Leser.

Times are not easy for data center managers. The clients have strong opinions about pricing, cycle time, and quality of the services. At the same time they struggle to keep good team members, to tame their budgets, and to keep pace with technological progress. " The Phoenix Project", a new novel by Gene Kim and his colleagues, offers some solutions. ( Es gibt eine deutsche Version dieses Artikels ).

Die Zeiten sind nicht einfach, um ein Rechenzentrum zu führen. Die Kunden haben hohe Anforderungen an Preis, Geschwindigkeit und Qualität. Gleichzeitig muss man aufpassen, dass gute Mitarbeiter dabei bleiben, dass die Kosten nicht aus dem Ruder laufen und dass man mit der Technik Schritt hält. Der neue Roman "The Phoenix Project" von Gene Kim und Co. zeigt einen Lösungsweg auf. ( There is an English version of this post. )

Gantt-Diagramme sind  schlecht für die Projektplanung (/1/). Was soll denn der brave Projektmanager tun ? Er braucht doch ein Werkzeug zur Planung und Kontrolle der Ergebnisse (/2/). Nicht die Hoffnung verlieren, lieber Projektmanager! Es gibt moderne Instrumente, die gut für Projekte geeignet sind: Burndown-Charts und Produkt-Checklisten.  Heute nehmen wir Burndown-Charts unter die Lupe (in einigen Wochen Produkt-Checklisten).

Ich bearbeite gerade Fragebögen und andere Dokumente. Fragebögen und Checklisten sind nützlich, um Prozesse zu steuern. Sie helfen beim Aufnehmen von Informationen. Mit ihnen behält man kritische Punkte im Auge. Checklisten sind das Prozessgedächtnis von Teams. Früher habe ich meine wichtigen Dokumente „Checkliste“ genannt. Aber eigentlich waren es auch Pläne und Fragebögen. Ich war stolz auf meine Listen. Leider habe ich sie selbst gar nicht benutzt. Entweder waren sie viel zu lang. Oder mir war gar nicht mehr klar, in welcher konkreten Situation ich das Dokument zu raten ziehen musste. Worauf sollte man achten, wenn man Checklisten erstellt?

Manchmal finden wir Blockaden für ein gutes Miteinander im Projektteam in den Begrenzungen der Technik. Manchmal aber ist auch Gewohnheit, Angst oder Besitzstandswahrung der Name des Steines, der im Weg liegt. Ein Bericht auch der Beratungspraxis.

Wie organisiert man viele Teams, die auf ein gemeinsames Ziel hin arbeiten (z. B. ein neues Produkt erstellen oder ein großes Softwarepaket entwickeln)? Mit dem Scaled Agile Framework legt Dean Leffingwell ein umfassendes Organisationsmodell vor. Es zeigt, wie die Anforderungen großer Unternehmen und die Prinzipen von agilen und Lean-Methoden praktikabel vereint werden können. SAFe macht Vorschläge, wie die verschiedenen Ebenen im Unternehmen (Team, Programm, Portfolio) organisiert werden können. Ziel ist, möglichst schnell aus strategischen Ideen marktfähige Produkte zu machen. Das Modell ist frei im Netz verfügbar. Grund genug, uns damit näher zu beschäftigen.

Im alltäglichen Zusammenspiel verschiedener Abteilungen treten stark verzahnte Prozesse auf, die in kurzer Zeit ein unentwirrbares Knäuel bilden können. Plötzlich weiß kein Beteiligter mehr, in welcher Rolle er mit jemand redet und was eigentlich genau das Thema ist. Das Flughöhenmodell hilft, Klarheit zu schaffen.