Team-Blueprints: Wie Beratungen Teams statt einzelner Berater verkaufen

Kurzantwort: Ein Team-Blueprint ist eine standardisierte Beschreibung eines Beratungsteams: Rollen, Verantwortlichkeiten, Kapazität, Arbeitsweise und Ergebnisse. Damit verkauft eine Beratung nicht mehr einzelne Profile, sondern ein eingespieltes Team mit klarer Leistung. Für Kunden entstehen „kaufbare Teams“, für die Beratung planbares Staffing und bessere Margen.

Viele Beratungen verkaufen formal Projekte, faktisch aber einzelne Personen. Im Angebot stehen Profile mit Tagessätzen, und das Team entsteht erst, wenn die Verfügbarkeiten feststehen. Das ist flexibel, führt aber zu wechselnden Teamzusammensetzungen und schwankender Qualität. Team-Blueprints setzen an diesem Punkt an und machen Teams zu einem reproduzierbaren Angebot. Der Kunde kauft dann nicht mehr eine Sammlung von Einzelpersonen, sondern ein eingespieltes Team mit klarer Leistung. Dieser Artikel zeigt, was ein Team-Blueprint enthält, wie typische Beispiele aussehen und wie Beratungen eigene Blueprints entwickeln. Er ist Teil der Serie Transformation von Consulting-Firmen und beschreibt den zweiten von vier Ansätzen.

Das Problem: Staffing Person für Person

In vielen Beratungen entsteht ein Projektteam nach einem ähnlichen Ablauf. Der Kunde fragt Kapazität an, und das Staffing sucht nach Personen, die im passenden Zeitraum verfügbar sind. Am Ende arbeitet eine Gruppe von Einzelnen zusammen, die sich oft erst im Projekt richtig kennenlernt. Jedes Team ist anders zusammengesetzt, und jede Rolle wird von der jeweiligen Person etwas anders interpretiert. Die Folgen sind in vielen Projekten zu beobachten: lange Anlaufphasen, unklare Verantwortlichkeiten und eine Qualität, die stark von einzelnen Personen abhängt. Für den Kunden ist schwer vorhersehbar, was er bekommt. Für die Beratung ist schwer planbar, wie viel Aufwand das Projekt tatsächlich verursacht. Und im Angebot steht am Ende wieder eine Liste von Profilen mit Tagessätzen, die mit anderen Anbietern direkt verglichen wird.

Was ein Team-Blueprint ist

Ein Team-Blueprint ist eine standardisierte Beschreibung eines Projekt- oder Service-Teams. Er legt fest, wie ein Team für eine bestimmte Art von Aufgabe zusammengesetzt ist und wie es arbeitet. Der Begriff ist bewusst aus der Architektur entlehnt, denn ein Blueprint ist ein Bauplan, nach dem sich immer wieder dasselbe Ergebnis erzeugen lässt. Im Unterschied zu einem Organigramm beschreibt er nicht nur Positionen, sondern auch Verantwortung, Zusammenarbeit und Ergebnisse. Ein guter Blueprint ist so konkret, dass ein Staffing-Verantwortlicher danach ein Team zusammenstellen kann. Gleichzeitig ist er verständlich genug, um ihn einem Kunden im Angebot zu erklären. Typische Bestandteile sind:

• Rollen: Welche Rollen gehören ins Team, und welche Seniorität braucht jede Rolle?
• Verantwortlichkeiten: Wer entscheidet was, wer ist Ansprechpartner für den Kunden?
• Kapazität: Mit wie viel Zeit ist jede Rolle im Team, und welche Rollen sind geteilt?
• Arbeitsweise: Welche Termine, Rituale und Artefakte gehören dazu, etwa Sprint-Reviews, Statusberichte oder Architekturentscheidungen?
• Ergebnisse: Was liefert das Team typischerweise in welchem Zeitraum?
• Skalierung: Wie sieht das Team in einer kleinen, mittleren und großen Ausprägung aus?
• Vertretung: Wie wird sichergestellt, dass das Team auch bei Ausfall einzelner Personen arbeitsfähig bleibt?

Beispiel 1: Delivery-Team für eine Plattform-Einführung

Ein erstes Beispiel ist ein Team für die Einführung einer Enterprise-Lösung, etwa im Bereich Strategic Portfolio Management. Solche Vorhaben verbinden fachliche Prozessarbeit mit technischer Umsetzung und brauchen deshalb unterschiedliche Kompetenzen. Die Gesamtverantwortung und die Kundenbeziehung liegen bei einer klar benannten Person. Technische Entscheidungen werden von einer Architekturrolle getroffen, die die Qualität der Lösung im Blick behält. Fachliche Anforderungen werden von einer Prozessrolle erhoben und mit den Fachbereichen abgestimmt. Umsetzung und Qualitätssicherung sind eigene Rollen, damit Tests nicht unter Zeitdruck wegfallen. Ein entsprechender Blueprint könnte so aussehen:

Rolle	Verantwortung
Engagement Lead	Gesamtverantwortung, Kundenbeziehung, Steuerung von Budget und Zielen
Solution Architect	Lösungsdesign, technische Entscheidungen, Qualität der Architektur
Business Process Consultant	Prozessanalyse, Anforderungen, Abstimmung mit Fachbereichen
Developer	Konfiguration, Entwicklung, Integrationen
QA / Test	Teststrategie, Testfälle, Abnahmevorbereitung

Beispiel 2: Service-Team für den Plattformbetrieb

Für den dauerhaften Betrieb einer Plattform, etwa im IT Service Management, eignet sich eine andere Zusammensetzung. Hier stehen nicht Einführung und Konzeption im Vordergrund, sondern Stabilität, Servicequalität und kontinuierliche Weiterentwicklung. Die Verantwortung für die Servicelevels liegt bei einer eigenen Rolle, die auch das Reporting gegenüber dem Kunden verantwortet. Fachliche Beratung und technische Umsetzung werden getrennt, damit beide Aufgaben ausreichend Raum bekommen. Eine technische Rolle kümmert sich speziell um Wartung, Upgrades und Performance. So bleibt die Plattform stabil, während gleichzeitig neue Anforderungen umgesetzt werden. Ein möglicher Blueprint sieht so aus:

Rolle	Verantwortung
Service Lead	Verantwortung für Servicelevels, Reporting und Service Reviews
Senior Consultant	Fachliche Weiterentwicklung, Beratung zu Prozessen und Best Practices
Developer	Umsetzung von Changes und Erweiterungen
Platform Engineer	Wartung, Upgrades, Performance und technische Stabilität

Dieses Team ist die organisatorische Grundlage für einen Managed Service als Produkt. Ohne ein fest definiertes Team hängt ein Service schnell an einzelnen Personen und wird bei Ausfällen oder Wechseln instabil. Mit einem Blueprint lässt sich dagegen festlegen, wie Vertretungen geregelt sind und welche Rollen auf mehrere Kunden verteilt werden können. Gerade bei Plattform-Engineering und Architektur ist eine solche Verteilung oft wirtschaftlich sinnvoll. Nicht jeder Kunde braucht eine Architekturrolle in Vollzeit, aber jeder profitiert von ihrer Erfahrung. Der Blueprint macht diese Aufteilung transparent und kalkulierbar. Beide Beispiele zeigen, dass es nicht den einen richtigen Blueprint gibt, sondern passende Muster für unterschiedliche Aufgaben.

Teamgrößen: S, M und L

Ein Blueprint sollte nicht nur eine einzige Teamgröße beschreiben. Kunden unterscheiden sich in Umfang, Budget und Dringlichkeit, und ein starres Team passt nicht zu allen Situationen. Sinnvoll sind deshalb mehrere Ausprägungen desselben Blueprints, etwa in den Größen S, M und L. In der kleinen Variante übernehmen einzelne Personen mehrere Rollen, in der großen werden Rollen mehrfach besetzt. Die Grundstruktur und die Verantwortlichkeiten bleiben dabei gleich. Für den Vertrieb entsteht so ein Baukasten, mit dem sich Angebote schnell an den Kundenbedarf anpassen lassen. Am Beispiel des Delivery-Teams könnte das so aussehen:

Größe	Besetzung	Geeignet für
S	Engagement Lead und Solution Architect in einer Person, ein Consultant, ein Developer mit Testanteil	Kleinere Einführungen, Quick Starts, Pilotprojekte
M	Alle fünf Rollen jeweils einfach besetzt	Typische Einführungsprojekte mit mehreren Fachbereichen
L	Zusätzliche Developer und Consultants, eigene Testrolle in Vollzeit	Große Vorhaben mit vielen Integrationen oder Standorten

Preislogik für Teams

Mit einem Blueprint verändert sich auch die Art, wie ein Team bepreist wird. Statt einzelne Tagessätze aufzulisten, kann die Beratung einen Preis für das gesamte Team pro Sprint, pro Monat oder pro Phase angeben. Für den Kunden wird das Angebot dadurch übersichtlicher und leichter mit dem erwarteten Nutzen vergleichbar. Für die Beratung entsteht Spielraum, die interne Besetzung zu optimieren, solange die vereinbarte Leistung erbracht wird. Eine gute Mischung aus erfahrenen und jüngeren Kolleginnen und Kollegen verbessert dabei die Marge und schafft Lernmöglichkeiten. Wichtig ist, dass die Qualität darunter nicht leidet und die Seniorität der Schlüsselrollen gesichert bleibt. Teampreise sind außerdem die Grundlage für den nächsten Ansatz, den agilen Festpreis.

Nutzen für Kunde und Beratung

Team-Blueprints schaffen Vorteile auf beiden Seiten der Zusammenarbeit. Der Kunde bekommt mehr Sicherheit, weil er vorab versteht, welches Team mit welchen Rollen für ihn arbeitet. Die Beratung gewinnt Planbarkeit, weil Staffing, Angebotserstellung und Kalkulation auf festen Mustern beruhen. Beide profitieren davon, dass das Team schneller arbeitsfähig ist und Verantwortlichkeiten von Beginn an klar sind. Hinzu kommt ein Effekt, der oft unterschätzt wird: Wissen bleibt im Team und hängt weniger an einzelnen Personen. Das macht die Zusammenarbeit robuster gegenüber Ausfällen und Wechseln. Im Einzelnen lassen sich folgende Vorteile unterscheiden:

Für den Kunden:
– Ein Team, das weiß, wie es zusammenarbeitet, statt einer Gruppe von Einzelpersonen
– Klare Ansprechpartner und Verantwortlichkeiten
– Vergleichbare Angebote und nachvollziehbare Kosten
– Schnellerer Projektstart

Für die Beratung:
– Staffing wird planbarer, weil Rollenprofile feststehen
– Angebote lassen sich schneller erstellen
– Junior- und Senior-Rollen können bewusst gemischt werden, was die Marge verbessert
– Wissen bleibt im Team und hängt weniger an Einzelnen

Typische Fehler bei Team-Blueprints

So einfach das Prinzip klingt, so häufig scheitert es in der Umsetzung an denselben Punkten. Viele Beratungen haben bereits Teamstrukturen in Präsentationen, die im Projektalltag aber keine Rolle spielen. Andere definieren Blueprints so detailliert, dass sie auf kaum ein Projekt passen. Wieder andere beschreiben Rollen, ohne ihnen echte Entscheidungsbefugnisse zu geben. In allen Fällen bleibt der Nutzen deutlich hinter den Möglichkeiten zurück. Die gute Nachricht ist, dass sich diese Fehler mit etwas Disziplin vermeiden lassen. Die typischsten sind:

• Blueprint nur auf der Folie: Das Angebot beschreibt ein Team, im Projekt arbeiten dann doch wechselnde Einzelpersonen. Der Blueprint muss auch im Staffing verbindlich sein.
• Zu starre Vorgaben: Ein Blueprint ist ein Standard, keine Zwangsjacke. Abweichungen sind erlaubt, sollten aber bewusst entschieden werden.
• Rollen ohne Verantwortung: Wenn nicht klar ist, wer entscheidet, entstehen dieselben Probleme wie ohne Blueprint.
• Kein Lernen: Blueprints sollten nach jedem Projekt überprüft und bei Bedarf angepasst werden.

So entwickeln Sie Ihre ersten Team-Blueprints

Die ersten Team-Blueprints entstehen am besten aus der eigenen Projekterfahrung und nicht aus theoretischen Modellen. Jede Beratung hat erfolgreiche Projekte, deren Teamzusammensetzung gut funktioniert hat. Diese Erfahrungen sind der beste Ausgangspunkt, weil sie realistische Rollen und Aufwände abbilden. Wichtig ist, mit wenigen Blueprints für die häufigsten Projekttypen zu beginnen. Weitere Blueprints können folgen, wenn die ersten im Alltag angekommen sind. Die Entwicklung sollte gemeinsam mit erfahrenen Projektleitungen und dem Staffing erfolgen. Ein pragmatisches Vorgehen umfasst fünf Schritte:

1. Vergangene Projekte analysieren: Welche Teamzusammensetzungen haben in erfolgreichen Projekten funktioniert?
2. Muster erkennen: Welche Rollen tauchen immer wieder auf, in welchem Verhältnis?
3. Blueprints beschreiben: Rollen, Verantwortung, Kapazität und Arbeitsweise dokumentieren.
4. Angebotsbausteine ableiten: Teambeschreibung, typische Ergebnisse und Preislogik für den Vertrieb aufbereiten.
5. Pilotieren und verbessern: Mit den nächsten passenden Projekten starten und Erfahrungen zurückspielen.

Die Leitfrage für diesen Prozess lautet: Welche Team-Setups können wir als feste, verständliche und wiederholt einsetzbare Delivery-Modelle beim Kunden anbieten? Die Antwort sollte konkret genug sein, um daraus Angebote zu bauen. Gleichzeitig sollte sie offen genug bleiben, um Blueprints nach den ersten Erfahrungen anzupassen. Ein Blueprint ist kein fertiges Produkt, sondern ein Standard, der mit jedem Projekt besser wird. Deshalb lohnt es sich, nach jedem Einsatz kurz zu prüfen, was funktioniert hat und was nicht. Diese Rückmeldungen gehören zum festen Ablauf. So entsteht über die Zeit ein Katalog erprobter Teammodelle, der für Vertrieb und Delivery gleichermaßen wertvoll ist.

Einordnung

Team-Blueprints sind ein zentraler Schritt vom Einzelberater zum Team- und Service-Modell. Sie verändern nicht nur, was verkauft wird, sondern auch, wie Projekte organisiert und gesteuert werden. Für Kunden entsteht eine verlässliche Leistung, für die Beratung eine planbare Delivery. Außerdem sind Blueprints die Voraussetzung für weitere Ansätze der Transformation. Managed Services brauchen stabile Teams, damit sie nicht an einzelnen Personen hängen. Ein agiler Festpreis funktioniert nur, wenn das Team fest definiert und seine Kapazität bekannt ist. Wer mit Blueprints beginnt, legt damit das Fundament für die nächsten Schritte.

FAQ

Was ist ein Team-Blueprint?

Ein Team-Blueprint ist eine standardisierte Beschreibung eines Projekt- oder Service-Teams mit Rollen, Verantwortlichkeiten, Kapazität, Arbeitsweise und typischen Ergebnissen. Er macht Teams reproduzierbar und verkaufbar.

Was bedeutet „Teams verkaufen statt Berater“?

Die Beratung bietet dem Kunden ein komplettes Team mit gemeinsamer Verantwortung für ein Ergebnis an, statt einzelne Profile mit Tagessätzen. Der Kunde kauft damit eine Leistung, nicht Personen.

Welche Rollen gehören in ein Delivery-Team?

Typisch sind Engagement Lead, Solution Architect, Business Process Consultant, Developer und QA/Test. Die genaue Zusammensetzung hängt vom Thema und der Projektgröße ab.

Wie flexibel darf ein Team-Blueprint sein?

Ein Blueprint sollte kleine, mittlere und große Ausprägungen vorsehen. Abweichungen im Einzelfall sind möglich, sollten aber bewusst entschieden und dokumentiert werden.

Unterstützung bei Ihren Team-Blueprints

Gute Team-Blueprints entstehen aus einer ehrlichen Analyse vergangener Projekte und aus dem Wissen, welche Rollen in der Praxis wirklich gebraucht werden. Als Freelancer unterstütze ich Beratungen und IT-Dienstleister dabei, ihre Projekt- und Service-Teams zu analysieren und daraus tragfähige Blueprints zu entwickeln. Dazu gehören Rollenprofile, Verantwortlichkeiten, Teamgrößen und die passende Preislogik für den Vertrieb. Aus meiner Arbeit im ServiceNow-Umfeld kenne ich die typischen Rollen in Einführungs- und Betriebsteams aus eigener Anschauung. Dieses Praxiswissen verbinde ich mit einem strukturierten, methodischen Vorgehen. Ziel ist ein Katalog von Teammodellen, den Ihr Vertrieb versteht und Ihre Delivery tatsächlich lebt. Wenn Sie Ihre Teams reproduzierbar aufstellen möchten, freue ich mich über Ihre Nachricht.

Unverbindliches Erstgespräch vereinbaren · Dr. Dominic Lindner

Alle Artikel dieser Serie

1. Transformation von Consulting-Firmen
2. Zielbild: Vom Einzelberater zum Team- und Service-Modell
3. Managed Services als Produkt
4. Team-Blueprints (dieser Artikel)
5. Agiler Festpreis
6. Product Lines als Factory
7. Transformation umsetzen