Projekte starten: Erst den Auftrag wirklich verstehen

Das Problem beschreiben, bevor die Lösung feststeht

„Wir brauchen ein Serviceportal“ klingt zunächst wie ein Auftrag. Tatsächlich steht damit vor allem eine Lösung im Raum. Unklar bleibt, welches Problem sie beheben soll: Gehen Anfragen verloren, fehlen Zuständigkeiten oder warten Beschäftigte zu lange auf eine Rückmeldung? Diese Ursachen können verschiedene Maßnahmen erfordern. Wer sofort eine Software auswählt, legt sich auf eine Antwort fest, bevor die Frage ausreichend verstanden ist.

Als durchgängiges fiktives Beispiel dient hier ein Unternehmen, das interne Serviceanfragen bisher über mehrere Postfächer bearbeitet. Beschäftigte fragen wiederholt nach dem Bearbeitungsstand; das Serviceteam überträgt Informationen zwischen Listen. Für den Start werden einige typische Vorgänge betrachtet: vom ersten Anliegen bis zur abschließenden Antwort. Dabei interessieren Übergaben, Wartezeiten und fehlende Angaben, nicht die Suche nach einer schuldigen Person.

Beschreiben Sie anschließend das beobachtete Problem in wenigen Sätzen und trennen Sie Beobachtungen von Vermutungen. „Bei diesen geprüften Vorgängen fehlte eine erkennbare Zuständigkeit“ ist etwas anderes als „Das Team arbeitet unorganisiert“. Der erste Satz lässt sich prüfen; der zweite erschwert vor allem das Gespräch. Die Problembeschreibung sollte auch den bisherigen Weg erklären, damit eine Verbesserung später einen nachvollziehbaren Vergleichspunkt hat.

Den Nutzen aus Sicht der Beteiligten konkret machen

Ein neues Portal ist zunächst ein Ergebnis des Projekts. Der erhoffte Nutzen entsteht erst, wenn Anfragen leichter bearbeitet werden oder Beschäftigte verlässlich sehen, was als Nächstes passiert. Diese Unterscheidung verhindert, dass ein erfolgreich installierter Dienst mit einem erfolgreich veränderten Arbeitsablauf verwechselt wird. Beides kann zusammenfallen, muss es aber nicht. Für den Auftrag sind deshalb Ergebnis und gewünschte Wirkung getrennt zu beschreiben.

Im Beispiel könnte das Ziel lauten: Anfragen einer ausgewählten Kategorie erhalten eine nachvollziehbare Zuständigkeit, und Rückfragen zum Bearbeitungsstand werden seltener. Vor dem Versuch wird festgehalten, wie der Ausgangszustand erhoben wird. Eine kleine, nachvollziehbar ausgewählte Stichprobe kann für den Einstieg genügen. Sie sollte typische Vorgänge enthalten und nicht nur die Fälle, die besonders gut zur geplanten Lösung passen.

Fragen Sie auch nach der Perspektive der Bearbeitenden. Ein Portal kann den Eingang vereinfachen und gleichzeitig zusätzliche Pflegearbeit erzeugen. Wenn jeder Vorgang in zwei Systemen geführt werden muss, ist die Belastung lediglich umgezogen. Zum Nutzen gehört deshalb der gesamte Ablauf einschließlich Rückfragen, Ausnahmen und laufender Betreuung. Eine Kennzahl ist dann hilfreich, wenn die Beteiligten erklären können, welche wirkliche Verbesserung sie damit erkennen.

Umfang und bewusste Nichtziele festhalten

Ein begrenzter Auftrag beschreibt ebenso deutlich, was nicht dazugehört. Für das Serviceportal könnte der erste Schritt nur eine Anfragekategorie und eine kleine Nutzergruppe umfassen. Eine zentrale Wissensdatenbank, die Ablösung sämtlicher Postfächer und die automatische Verteilung aller Anliegen wären eigene Erweiterungen. Sie müssen nicht grundsätzlich falsch sein. Sie verändern aber Aufwand, Risiken und die Frage, was am Ende abgenommen wird.

Nichtziele sind keine Liste unerwünschter Wünsche. Sie schützen die erste sinnvolle Lieferung und halten spätere Möglichkeiten offen. Schreiben Sie bei einer wichtigen Abgrenzung kurz dazu, warum sie gilt. „Im Pilot keine vertraulichen Personalvorgänge, weil dafür ein gesondertes Zugriffskonzept erforderlich wäre“ ist verständlicher als ein unbegründetes Verbot. So kann eine spätere Änderung auf ihre Voraussetzungen geprüft werden.

Auch Schnittstellen verdienen Aufmerksamkeit. Wenn das Portal Anfragen annimmt, muss geklärt sein, wo die Bearbeitung erfolgt und welches System den maßgeblichen Status enthält. Sonst endet der vereinbarte Umfang genau dort, wo das praktische Problem beginnt. Lassen Sie beteiligte Teams ein oder zwei vollständige Vorgänge gemeinsam durchgehen. Dabei werden Lücken häufig schneller sichtbar als in einer langen Funktionsliste, in der jede Abteilung nur ihren eigenen Teil betrachtet.

Beteiligte früh mit ihrem tatsächlichen Beitrag einbeziehen

Wer später mit einem Ergebnis arbeiten soll, gehört nicht erst zur Vorstellung der fertigen Lösung in den Raum. Beim Serviceportal betrifft das die anfragenden Beschäftigten, das Serviceteam und den späteren Betrieb. Weitere Personen werden gezielt einbezogen, wenn Daten, Zugriffe oder bestehende Vereinbarungen betroffen sind. Dabei geht es nicht darum, möglichst viele Namen in einen Verteiler aufzunehmen. Benötigt wird ein konkreter Beitrag zur Klärung.

Fragen Sie jede beteiligte Gruppe nach typischen Fällen, Schwierigkeiten und Bedingungen für eine brauchbare Lösung. Eine Person kann gut erklären, warum Vorgänge liegen bleiben; eine andere kennt Einschränkungen der Anmeldung. Diese Perspektiven ergänzen sich. Nicht alle Beteiligten müssen jedes Detail entscheiden. Sichtbar sein sollte aber, wer fachlich beiträgt, wer eine Entscheidung vorbereitet und wer sie verbindlich treffen darf.

Prüfen Sie außerdem, wessen Sicht noch fehlt. Ein Portal, das am großen Bildschirm gut funktioniert, kann für Beschäftigte mit anderer Ausstattung unpraktisch sein. Vertretungen benötigen unter Umständen andere Informationen als die reguläre Bearbeitung. Solche Unterschiede werden nicht durch eine allgemeine Zustimmung aller Abteilungsleitungen abgedeckt. Ein kleiner Kreis mit passenden Erfahrungen kann für die Klärung wertvoller sein als eine große Auftaktveranstaltung ohne konkrete Arbeitsbeispiele.

Annahmen, Unsicherheiten und Voraussetzungen sichtbar machen

Zu Beginn ist vieles noch nicht bekannt. Das ist normal und kein Anlass, einen Auftrag künstlich genau zu formulieren. Problematisch wird es, wenn Vermutungen unbemerkt zu festen Zusagen werden. Im Portalbeispiel könnte angenommen werden, dass vorhandene Benutzerkonten verwendet werden können. Solange die technische und organisatorische Einbindung nicht geprüft ist, bleibt das eine Annahme mit möglichen Folgen für Termin und Aufwand.

Eine kurze Übersicht genügt: Was nehmen wir an, warum ist es wichtig, wer klärt es und bis wann benötigen wir das Ergebnis? Ergänzen Sie die mögliche Konsequenz. Fällt eine notwendige Schnittstelle aus, muss vielleicht eine andere Lösung gewählt oder der Pilot enger begrenzt werden. Damit wird aus einer unscharfen Sorge eine bearbeitbare Frage. Nicht jede offene Kleinigkeit braucht dagegen einen förmlichen Risikoeintrag.

Priorisieren Sie Klärungen nach ihrer Wirkung auf die nächste Entscheidung. Die Farbe eines Formulars kann warten; eine fehlende Zugriffstrennung möglicherweise nicht. Testen Sie zunächst mit geeigneten Beispieldaten, wenn echte Vorgänge dafür nicht erforderlich sind. So lassen sich grundlegende Annahmen prüfen, ohne zusätzliche Daten unnötig zu verteilen. Der Zweck der Klärung ist eine belastbarere Entscheidung, nicht eine möglichst beeindruckende Sammlung von Risiken.

Abnahme und spätere Verantwortung vorab vereinbaren

Abnahme bedeutet hier die vereinbarte Entscheidung, ob das gelieferte Ergebnis für seinen vorgesehenen Zweck geeignet ist. Welche vertragliche oder rechtliche Bedeutung eine Abnahme im Einzelfall hat, ist gesondert zu klären. Für die praktische Zusammenarbeit hilft schon früh eine konkrete Beschreibung: Welche Fälle sollen funktionieren, welche Einschränkungen sind akzeptabel und wer bewertet das Ergebnis anhand welcher Nachweise?

Beim Serviceportal reicht die Feststellung „Die Seite lässt sich öffnen“ nicht aus. Eine Testanfrage muss bei der richtigen Stelle ankommen, einen verständlichen Status besitzen und abgeschlossen werden können. Berechtigte Personen müssen zugreifen können, unberechtigte Personen dürfen den Vorgang nicht sehen. Auch Fehlermeldungen und Vertretungssituationen gehören zu einem brauchbaren Testumfang. Die Beispiele werden mit den künftigen Nutzenden und dem Betrieb abgestimmt.

Klären Sie gleichzeitig, wer nach dem Projekt Inhalte, Zugriffe und technische Änderungen betreut. Ein Projekt kann seine Ergebnisse übergeben; es kann laufende Verantwortung nicht durch einen Abschlussbericht ersetzen. Wenn niemand Zeit für die spätere Pflege hat, fehlt bereits eine wesentliche Voraussetzung. Diese Frage vor dem Bau zu stellen wirkt manchmal unbequem. Nach der Einführung wird sie dadurch allerdings nicht bequemer.

Mittel und Termine mit dem Auftrag zusammenbringen

Ein Ziel kann fachlich sinnvoll und trotzdem unter den verfügbaren Bedingungen nicht erreichbar sein. Deshalb gehören personelle Verfügbarkeit, Budget und wichtige Termine in denselben Blick. Eine gewünschte Einführung vor einem internen Termin ist zunächst eine Anforderung. Erst nach einer ersten Einschätzung lässt sich beurteilen, welcher Umfang bis dahin verantwortbar geliefert werden kann. Der Kalender ersetzt diese Prüfung nicht.

Unterscheiden Sie außerdem die Zusage für eine Vorbereitung von der Zusage für die vollständige Umsetzung. Es kann vernünftig sein, zunächst nur die wichtigsten Voraussetzungen zu prüfen und danach über weitere Mittel zu entscheiden. In diesem Fall braucht auch die Vorbereitung einen begrenzten Auftrag: Welche Fragen werden beantwortet, welche Unterlagen sollen vorliegen und wer bewertet das Ergebnis? Sonst wächst aus einer unverbindlich begonnenen Klärung schleichend ein bereits laufendes Projekt. Bereits entstandener Aufwand ist anschließend kein ausreichender Grund, an einer ungeeigneten Lösung festzuhalten. Die nächste Entscheidung sollte weiterhin am erwarteten Nutzen und an den noch bevorstehenden Aufwendungen ausgerichtet werden.

Im Beispiel stehen die Fachleute des Serviceteams nur an bestimmten Tagen für Tests zur Verfügung. Das muss in der Planung berücksichtigt werden, auch wenn die technische Umsetzung schnell gehen könnte. Gleiches gilt für Entscheidungen, Beschaffung und den späteren Betrieb. Die benötigte Mitarbeit sollte mit den jeweiligen Verantwortlichen vereinbart werden. Ein Name im Projektplan ist noch keine zugesagte Kapazität.

Bleibt eine Lücke, werden Alternativen vorbereitet: kleinerer Umfang, anderer Termin, zusätzliche Unterstützung oder zunächst nur eine begrenzte Klärungsphase. Ich halte es für sinnvoll, diese Möglichkeiten offen auszusprechen. Ein scheinbar einvernehmlicher Start auf widersprüchlicher Grundlage verschiebt den Konflikt lediglich. Die Entscheidung muss erkennen lassen, welche Einschränkung bewusst akzeptiert wurde und welche Voraussetzung vor der weiteren Arbeit noch erfüllt werden muss.

Den Start mit einer überschaubaren Entscheidung abschließen

Am Ende der Vorbereitung sollte ein kurzer Auftrag vorliegen, den die Beteiligten in eigenen Worten erklären können. Er enthält Problem, Ziel, Umfang, Grenzen, Zuständigkeit, wesentliche Voraussetzungen und den nächsten Entscheidungspunkt. Umfangreiche Anhänge sind möglich, aber die Kernaussage muss ohne Sucharbeit verständlich bleiben. Für ein kleines Vorhaben kann das deutlich weniger sein als für eine Veränderung mit vielen Abhängigkeiten.

Im fiktiven Portalprojekt wird zunächst ein begrenzter Pilot vereinbart. Das Serviceteam liefert typische Fälle, die technische Rolle prüft Anmeldung und Zugriffstrennung, die Auftraggeberin entscheidet über die bereitgestellte Zeit. Nach dem Pilot werden Wirkung, Nacharbeit und Betriebsaufwand gemeinsam betrachtet. Erst dann fällt die Entscheidung über eine Erweiterung. Diese Festlegung verspricht keinen späteren Erfolg, schafft aber einen überprüfbaren Arbeitsrahmen.

Methodische Orientierung bietet beispielsweise PM² der Europäischen Kommission mit Rollen, Phasen und Arbeitshilfen. Das britische Service Manual zur Discovery betont die Klärung des Problems vor dem Bau einer Lösung. Die hier beschriebenen Portalbeispiele und Entscheidungen sind meine praktische Einordnung. Entscheidend ist, dass die Organisation tatsächlich weiß, was sie beginnen will und unter welchen Bedingungen sie weiterarbeitet.