Projektarbeit als konkretes Anwendungsbeispiel für Microsoft Teams (Teil 1)

Viele Anwender sind sich unsicher, wie sie ihre Teams aufbauen sollen und welche Dienste bei der inhaltlichen Arbeit am besten weiterhelfen können. Die gute Nachricht: So richtig falsch kann man inhaltlich bei Teams eigentlich nichts machen. Was an Daten da ist, ist da. Trotzdem wird hier einmal ein Anwendungsbeispiel für die Arbeit in einem größeren Projekt zum Inspirieren und Abgucken gezeigt.

Grundsätzlich gilt immer noch alles, was beim initialen Artikel Microsoft Teams und wie man damit arbeitet. Teil 2: Ein konkretes Beispiel beschrieben worden ist. Der Client hat in der Zwischenzeit zwar zahlreiche Updates und Funktionserweiterungen bekommen, die grundsätzliche Ordnung von Teams und Kanälen hat sich aber nicht geändert. Kümmern wir uns also erst einmal um die Anforderungen!

Praxisbeispiel Projektarbeit

Das Szenario, für welches ein Team eingerichtet werden soll, spiegelt vielfach meinen aktuellen Arbeitsalltag wieder bzw. die Situation, in der sich einige meiner Projekte befinden. Nehmen wir an dieser Stelle an, dass ein mittelgroßes Unternehmen mit ~2000 Arbeitsplätzen eine Office 365 Einführung plant. Gleichzeitig soll der gesamte Arbeitsplatz auf Version „3.0“ gehoben werden, da hier sowieso schon seit einiger Zeit eine Modernisierung ansteht. Also: Neue Clients, neues Betriebssystem, neue Officeversion mit Office 365, Lotus Notes mit vielen Anwendungsfällen ablösen, neue Arbeitsweisen einführen und viele notwendige Änderungen im Netzwerk. Das Gesamtprogramm ist entsprechend groß ausgelegt und hat diverse handelnde Personen und Dienstleister.

Wir sehen hier also eine Aufteilung in Programmmangement, einigen Stabstellen und die Unterteilung der Unterprojekte. Hier hat es jeweils eine Mischung aus internen Mitarbeitern des Konzern und externen Mitarbeitern von verschiedenen Dienstleistern, die ihren Input zu den jeweiligen Workloads geben. Auch auf den oberen Ebenen gibt es interne und externe Besetzungen. Die kleine Skizze des Projekts oben zeichnet jeweils nur einen Ausschnitt aller Instanzen nach.

Die Anforderungen an einen digitalen Arbeitsplatz zur Toolunterstützung sind damit

• Bereitstellung Gesamtdokumentation an das Management
• Festhalten aller relevanten Entscheidungen nebst finaler Ablage
• Dokumentation des Programmanagements und der Teilprojekte
• Unterstützung der Stabstellen bei ihrer Arbeit samt Dokumentation
• Einbindung aller Akteure (intern wie extern)
• Bereitstellen von Kollaborations-, Planungs- und Kommunikationstools

Nun ist der Vorteil bei einem solchen Projekt natürlich, dass sich die Beteiligten selbst als Versuchskaninchen opfern und mit den neuen Mitteln und Wegen gleich arbeiten wollen. Also werden einige Clients bereits so früh wie möglich einmal manuell hochgezogen um beispielsweise Teams als Client bereits in der Projektgruppe einsetzen zu können.

Die Alternativen für das Anwendungsbeispiel

Geht man durch die Services von Office 365, bleibt man hier bei den obligatorischen üblichen Verdächtigen hängen. Das sind vor allem SharePoint Online, Groups und Teams. Etwas abgeschlagen gibt es noch OneDrive for Business, Yammer und Emailpingpong mit Outlook/Exchange. Die zweite Garde passt auf die Ausrichtung einer konkreten Projektarbeit weniger, da sie grundlegende Voraussetzungen nicht berücksichtigt (OneDrive for Business ist benutzerzentriert) oder einfach am Anwendungsfall vorbeischießt (Yammer, Email).

SharePoint erfordert wie immer ein selbstbewusstes Maß an Vorwissen beim Endanwender. Zwar hat Microsoft die Website-Vorlagen für Team- und Projektsites deutlich entschlackt, nichtsdestotrotz ist SharePoint auch mit den reduzierten Modern Views immer wieder ein wunderbares Bermudadreieck. Die Schachtelung von Sites, Handhabung von Berechtigungen sowie im Vollausbau die verwirrenden Möglichkeiten der Metadaten sind anfangs für Ungeübte gruselig. In unserem Beispiel ist das interne Projektteam neu in der Benutzung der Tools. Ferner sind die Möglichkeiten der Kommunikation mit dem Microfeed auf SharePoint Sites nur schwach ausgeprägt.

Etwas anders verhält sich Groups. Die Kommunikation ist da, es gibt Ablagen und die Möglichkeit, beispielsweise Planner im Kontext der Group zu benutzen. Zentrum ist hier das gemeinsame Postfach. Da in unserem Beispiel die Komplexität durch die Teilprojekte aber entsprechend hoch ist, wäre eine Nutzung von Groups in diesem Fall mit dem Umstand verbunden, dass die Organisation dieser Unterteilung in weiten Teilen manuell ablaufen würde. Das bedeutet unter anderem: Emails und Kommunikationen sortieren (lassen) und entsprechende Ordnerstrukturen in der Dateiablage selber pflegen. So richtig schön ist das auch nicht.

Bliebe Teams.  Die Kommunikation ist chat-getrieben, Kanäle können Unterteilungen bieten, eine Dateiablage gibts auch, Emails kann man ebenfalls an ein Projekt schicken, andere Services können mit unter das UI-Dach schlüpfen und externe Benutzer sind mittlerweile auch kein Problem mehr. Klingt gut, da nehmen wir ein Pfund von, darf auch gerne etwas mehr sein. Allerdings macht die Anforderung der Bereitstellung an das Management leichte Sorgen, darum muss sich gekümmert werden.

Grundsätzliche Überlegungen für das Team

Alles startet wie gehabt mit einem neuen Team. Dieses wird nicht als öffentliche Gruppe angelegt, sondern privat.

Die Überlegung ist hier, eine Steuerung aus dem Projekt heraus zu haben, wer als Teammitglied aufgenommen werden soll. Wäre das Team auf „öffentlich“ gestellt, könnte jeder in der Organisation das Team über die Suche finden und sich als Mitglied hinzugesellen. Aufgrund der Natur des Projekts gehen wir hier diesen Weg nicht, auch wenn man sonst immer offen dafür sein sollte, seine Inhalte zu teilen, solange sie nicht strictly confidential sind.  Im vorliegenden Fall soll einfach zum aktuellen Zeitpunkt des Projekts noch keine (evtl. verfrühte) Information an die Belegschaft gelangen.

Im zweiten Schritt wird vom frisch gebackenen Teambesitzer die grundsätzliche Projektstruktur nachempfunden. Damit jedes Teilprojekt seinen eigenen Bereich bekommt, welcher für die jeweiligen Anforderungen individualisierbar ist, geschieht das durch Kanäle.

In den Abstimmungsrunden im Projekt wird von Seiten des Programmmanagers stark mit einem Projektstrukturplan gearbeitet. Mit Hilfe dessen sind die einzelnen Teilprojekte und Aufgabenfelder erarbeitet worden. Dieser Projektstrukturplan liegt damit auch den Kanälen zugrunde, welche so die erste Ebene abbilden. Somit können sich die Mitarbeiter eines Teilprojekts unabhängig von den anderen die für ihre Arbeit notwendigen Strukturen schaffen. Übergreifende Projekte wie eben jener besagte Strukturplan liegen dabei dann im Allgemein- bzw. Programmmanagement-Kanal.

Externe Benutzer und Überlegungen zu Rechten

Sind die grundlegenden Strukturen erst einmal eingerichtet, können nun die Mitarbeiter eingeladen werden, die für das Gesamtprojekt benötigt werden:

• Das IT-Management
• Die interne IT-Abteilung
• Zusätzliche interne technische Experten
• Projektmitarbeiter aus Fachabteilungen und „Friendly Key User“
• Der externe Programmmanager
• Die extenen Fachexperten der jeweiligen Dienstleister (Netz, Hosting, Office 365,…)
• Einkauf Lizenzen und Hardware

Das ergibt eine erkleckliche Anzahl von ca. 20 Personen, welche an dem Gesamtprojekt vom Anwendungsbeispiel zum jetzigen Zeitpunkt arbeiten. Besitzerrechte erlangen dabei lediglich der technische Administrator, der Programmmanger und das IT-Management (die dürfen ja eh immer alles).

Wichtig ist an dieser Stelle, sich noch einmal die Einschränkungen von Teams beim Thema Rechtemanagement im Gegensatz zu einer voll ausgebauten Featurerakete wie SharePoint vor Augen zu halten: Es gibt nur Besitzer und Mitglied als Rollen, sowie die Abstufung „Gast“, die weitgehend übergreifend im Rahmen der Tenant-Governance konfiguriert wird. Das bedeutet, dass es beispielsweise kein „Nur-Lesen“ gibt, wer Mitglied eines Teams ist, kann rigoros aktiv mitgestalten. Auch die Definition eigener Berechtigungsstufen analog des SharePoint-Konzepts ist nicht in Teams möglich.

Weiterhin lässt die Möglichkeit, einzelne Kanäle rechtemäßig einzuschränken, weiter auf sich warten. Aktuell hat der Wunsch nach privaten Kanälen in der UserVoice sagenhaft viele Upvotes, befindet sich aber nach wie vor in der Entwicklung. Das bedeutet hier für unser Anwendungsbeispiel, dass alle Projektmitglieder vollen Zugriff auf die Dokumente und Informationen im gesamten Team haben. Wo beispielsweise SharePoint es erlaubt, einzelne Unterwebs in der Berechtigungsvererbung zu unterbrechen, ist das hier in Teams derzeit nicht vorgesehen.

Wie gehts weiter?

Dieser Artikel ist Teil 1 einer zweiteiligen Betrachtung dieses Anwendungsfall. Im nächsten Teil werden die Kanäle mit Leben gefüllt und die Möglichkeiten gezeigt, gezielt bestimmte Aspekte in den Teilprojekten in den Vordergrund zu rücken.

Schließlich wird gezeigt, wie in diesem konkreten Fall durch die Kombination mit SharePoint eine Ablage der Entscheidungsdokumente für das Management geschaffen wird, die für das Projektteam schreibgeschützt gehalten wird und damit einen strukturierteren bzw. gelenkten Unterbau besitzt.

Titelbild: https://pixabay.com/de/bau-helm-bunte-muster-industrie-1160260/