5.3 Modellieren: Was sind mögliche Lösungen?

Wenn das Problem erkannt ist, kann man anfangen, etwas dagegen zu tun. In einem ersten Schritt müssen wir unsere Analyse bestimmt nochmal mit dem Auftraggeber, z.B. dem Teamlead oder der Geschäftsführung, teilen und dafür sorgen, dass sie uns zustimmen :)

Das ist oft das erste Mal, dass ich den teamdecoder überhaupt zeige. Vorher verwirrt das immer nur. Jetzt aber kann ich zeigen: "Schaut mal: So sieht Euer Team heute aus, und hier, hier und hier zeigen sich Auswirkungen Eures Problems!".

Jetzt kann man entweder gleich Lösungsvorschläge dabei haben, oder aber erstmal Einigkeit über das Problem herstellen, und die Lösungsvorschläge im nächsten Meeting ansprechen. Dazu gibt es keine klare Regel - mach das, wie Du denkst, dass es für den Auftraggeber am besten ist.

Lösungen im td Framework modellieren

Wenn wir dem Team mit dem teamdecoder helfen wollen, die aktuellen Probleme zu lösen und zukünftig besser in der Lage zu sein, Probleme schnell selbst lösen zu können, weil gelernt wurde, wie man Verbesserung und Veränderung einfach in den Alltag integriert, müssen wir auch unsere Problemlösung so bauen, dass wir sie mit teamdecoder implementieren können.

Was heißt das?

Das bedeutet, dass wir das teamdecoder Framework für rollenbasiertes Arbeiten nutzen, um die erkannten Probleme zu adressieren. Also Lösungen in Form von

• People

• Skills

• Roles

• Domains

• Links

• Circles

• Projects

bauen und anbieten.

Welche Listen Du benutzt, und wie Du diese nennst, ist Dir überlassen. Aber Deine Lösung muss operationalisierbar sein mit dem Framework, das Du für das Team gebaut hast. 

Denn hier definiert sich die gesamte Arbeit des Teams, die Kollaboration, die Ziele, etc. 

Das kann dann z.B. so aussehen:

• Problem X lösen wir mit einer neuen Rolle.

• Für Eure neue Strategie braucht ihr andere Skills, ich empfehle Skills A und B.

• Um die Kollaboration zu verbessern, führen wir einen Circle Y ein, in dem die Rollen 1,2 und 3 zusammen X,Y und Z machen.

• Damit der CEO besser "in the Loop" ist", kreieren wir einen Link.

• etc. pp

Größer denken

Die genannten Ideen klingen jetzt eher wie schnelle "Pflaster" für kleinere "Problemchen" - das macht sie nicht weniger wichtig, denn oft steckt der Teufel im Detail. Und wenn 99 Kleinigkeiten nicht richtig funktionieren, leidet garantiert der gesamte Betrieb.

Aber je nachdem wie tief das gefundene Problem sitzt, muss auch mal eine größere Lösung her - eine neue Strategie, eine neue Struktur, eine komplett neue Sortierung der Aufgaben, o.ä.

In einem solchen Szenario empfehle ich, die Lösung außerhalb des teamdecoders zu entwickeln, z.B. in Miro, und erst dann zu übersetzen, wenn eine grundsätzliche Einigkeit mit allen Beteiligten hergestellt worden ist. Der Entwurf sollte zeigen, welche grundsätzliche Struktur es geben sollte und wie die einzelnen Bausteine verbunden sind.

Bei mir entstehen dann oft Bilder wie z.B. dieses (stark vereinfacht!):

Hier noch ein paar mehr Beispiele.

Wenn man sich hierzu geeinigt hat, kannst Du das Konstrukt im teamdecoder erstellen. Du entscheidest dann, was "Circles" sind, und wie die heißen sollen, was "Projects" sind, wie "Skills" und "Rollen" eingesetzt und verteilt werden, usw.

In dem oberen Bild könnte man z.B. "Circles" für "Strategy Teams" benutzen und "Projects " für "Skill Teams" - oder man will "Projects" für wichtige Projekte aufheben, dann macht man beides in der "Circles" Liste und vergibt entsprechende Tags.