Item Tracking

Ziel

Das BABOK setzt das Ziel der Technik: die Probleme und die Anliegen der Anspruchsgruppen erfassen, die auf die Lösung wirken, und die Verantwortung dafür zuweisen. Ein im Workshop geäussertes und nicht festgehaltenes Anliegen kommt später und teurer zurück, bei der Freigabe der Anforderungen, beim Abnahmetest oder in der Produktion. Erfassen ohne Zuweisen ergibt eine Liste, die niemand vorantreibt; Zuweisen ohne Erfassen ergibt eine Zusage, deren Spur sechs Wochen später niemand mehr findet.

Die Technik ist das allgemeine Gefäss für alles, was eine Anspruchsgruppe vorbringt. Das BABOK nennt sieben Item-Typen: die Aktion, die auszuführen ist, die Annahme, die mangels Information getroffen wurde und noch zu bestätigen ist, die von aussen gesetzte Einschränkung, die Abhängigkeit von einem Dritten, den festgestellten Fehler, die gewünschte Verbesserung und das Problem (issue), das blockiert. Diese Allgemeinheit ist gewollt: Sie schafft einen einzigen Ort, an dem jedes Anliegen landet, welcher Art es auch sei, und die Triage entscheidet danach, in welchen Prozess das Item eintritt.

Das Ergebnis ist ein Item-Register, ausgefüllt, geteilt und nachgeführt: eine Tabelle, deren jede Zeile ein Anliegen trägt, die Person, die es vorgebracht hat, eine bewertete Auswirkung, eine Priorität, einen Eigentümer, einen Bearbeiter, eine vereinbarte Strategie, einen Status und eine Frist zur Lösung. Das BABOK ergänzt, dass das Register mit den Anspruchsgruppen geteilt werden kann: Sie sehen Stand und Fortschritt der Items und ordnen das Offene nach Wichtigkeit.

Das Register klärt eine Frage: wer für ein offenes Anliegen einsteht und bis wann. Der Analyst zeigt es der Anspruchsgruppe, die nachfragt, was aus ihrem Anliegen geworden ist. Das BABOK nennt diese Stärke zuerst: Die Anliegen der Anspruchsgruppen zu den Anforderungen werden erfasst, verfolgt und zu ihrer Zufriedenheit gelöst. Die Technik erzeugt eine Tabelle. Ihre Wirkung ist eine Anspruchsgruppe, die aufhört, ihr Anliegen in jeder Sitzung zu wiederholen, weil sie es eingetragen sieht, mit einer Frist und einem Namen daneben.

Einsatz

Wann einsetzen

• Workshop oder Interview zur Elizitation: jedes geäusserte Anliegen sofort festhalten, in den Worten dessen, der es vorbringt.
• Anforderungen vor der Freigabe: ein benannter blockierender Punkt mit Eigentümer und Frist macht die Unterschrift möglich.
• Viele Anspruchsgruppen mit auseinandergehenden Interessen: sichtbar machen, was offen ist und wer entscheiden muss.
• Annahme mangels Information: als zu bestätigendes Item festhalten, mit dem Datum, bis zu dem sie es sein muss.
• Abhängigkeit von einem Dritten ausserhalb des Teams: mit Frist und vereinbartem Eskalationsweg verfolgen.
• Verteiltes Team oder asynchrone Arbeit: Das geteilte Register ersetzt das Gedächtnis des Raums, das kein Chatverlauf hält.
• Langes Mandat mit wechselnden Personen: Das Register ist das Gedächtnis, das den Weggang dessen überdauert, der Bescheid wusste.
• Vertrauen zum Fachbereich beschädigt: Ein geteiltes Register stellt die Transparenz schneller wieder her als ein Statusbericht.
• Auditiertes oder reguliertes Umfeld: Die Spur, wer was vorbrachte, wer entschied und wann, wird verlangt.

Wann nicht einsetzen

• Anliegen zu einem künftigen und ungewissen Ereignis: als Risiko behandeln (§10.38).
• Arbeit, die wartet, weil die Kapazität fehlt: ins Backlog geben (§10.2), das nach Wert ordnet.

Beschreibung

Was ein Item-Eintrag trägt

Das BABOK zählt fünfzehn Attribute auf und leitet sie mit einer Formel ein: Jedes erfasste Item kann alle oder einen Teil dieser Attribute tragen. Ein Register mit fünfzehn Spalten ist für die meisten Vorhaben eine Übung in Konformität, und sechs nachgeführte Spalten sind mehr wert als fünfzehn, die nach einem Monat liegen bleiben. Die Wahl der Spalten wird einmal getroffen, wenn die Regeln des Registers gesetzt werden, und sie richtet sich danach, was das Vorhaben pflegen wird.

Die Attribute der Identifikation sagen, worum es geht und woher es kommt. Die Kennung unterscheidet ein Item von allen anderen und ist die Referenz in den Protokollen. Die Zusammenfassung beschreibt das Item in einem Satz, nahe genug an den Worten dessen, der es vorbrachte, dass er sich darin wiedererkennt. Die Kategorie gruppiert Items mit verwandten Eigenschaften. Der Typ ist einer der vom BABOK genannten, und er steuert, in welchen Prozess das Item eintritt. Das Identifikationsdatum und die Angabe identifiziert durch verankern das Item in einem Moment und vor einer Person. Das Alter des Items berechnet sich aus diesem Datum.

Die Attribute der Qualifikation sagen, was das Item kostet, solange es offen bleibt. Die Auswirkung nennt die möglichen Folgen, wenn das Item nicht bis zu seiner Frist gelöst wird, und das BABOK gibt ihr vier Achsen: Termin, Kosten, Umfang, Qualität. Eine Auswirkung wird auf einer dieser Achsen ausgedrückt, mit einer Grösse. Die Priorität ist die Wichtigkeit des Items für die betroffenen Anspruchsgruppen. Diese setzen sie deshalb selbst. Der Analyst, der das Register führt, trägt die Priorität nur ein, und der Bearbeiter, für den das Item eine Last ist, arbeitet in der Reihenfolge, die diese Priorität vorgibt. Die Frist zur Lösung ist das Datum, bis zu dem das Item gelöst oder geschlossen sein muss.

Die Attribute der Verantwortung und der Lösung sagen, wer was tut. Der Eigentümer ist die Anspruchsgruppe, die das Item bis zum Abschluss führt; der Bearbeiter ist damit beauftragt, es zu lösen. Das BABOK macht daraus zwei getrennte Attribute, und diese Unterscheidung ist die erste, die die Praxis einebnet. Der Eigentümer hakt nach, entscheidet, eskaliert; der Bearbeiter führt aus. Wer beide vermengt, erhält Items, die bei der Person liegen, die am wenigsten Befugnis hat, sie zu bewegen. Die vereinbarte Strategie hält fest, was entschieden wurde, im Vokabular, für das das BABOK die Beispiele gibt: akzeptieren, weiterverfolgen, ignorieren, mindern, vermeiden. Das BABOK lässt die Liste offen. Ein geschlossenes Vokabular macht das Register sortierbar und zählbar, und diese fünf Werte genügen, um es zu schliessen. Ignorieren ist eine legitime, getroffene und festgehaltene Entscheidung, und sie unterscheidet sich von einem Item, das still stehen bleibt. Der Status verortet das Item in seinem Lebenszyklus. Das Lösungsprotokoll hält den Fortschritt der Lösung und die Genehmigung ihres Abschlusses fest. Die Eskalationsmatrix legt schliesslich die Stufe fest, die gilt, wenn das Item bis zur Frist nicht gelöst ist: Sie ist ein Feld des Eintrags.

Der Lebenszyklus des Items

Das BABOK gibt die Status als Beispiele: offen, zugewiesen, gelöst, abgebrochen. Die Formulierung ist illustrativ, und die Organisation legt ihre eigenen fest; das BABOK setzt dafür eine feste Regel in seinem Element zur Item-Führung: Jedes Item wird bis zu seiner Lösung oder seinem Abschluss verfolgt. Daraus folgt ein Modell mit sieben Zuständen. Den vier Status des BABOK fügt es in Arbeit hinzu, zwischen Zuweisung und Lösung, denn angefangene Arbeit ist eine Lage, in der das Item verweilt. Es trennt geschlossen von gelöst, denn der Abschluss ist ein Akt der Genehmigung, verschieden vom Erzeugen einer Lösung. Es trennt schliesslich abgelehnt von abgebrochen, während das BABOK nur abgebrochen kennt: Die Ablehnung ist ein lesbarer Zustand, verschieden vom Abbruch eines Items, das verfällt, zurückgezogen oder mit einem anderen zusammengeführt wird. Vier dieser sieben Zustände sind Schritte der Bearbeitung; drei beenden das Leben des Items: abgelehnt, abgebrochen und geschlossen.

Ein vorgebrachtes Anliegen durchläuft zuerst eine Prüfung der Zulässigkeit, die das BABOK schon bei seiner ersten Äusserung ansetzt. Das Register behält das abgelehnte Item: Es wird als abgelehnt festgehalten und nicht gelöscht, denn wer es vorbrachte, muss sehen können, was daraus wurde. Das zulässige Item wird offen, dann zugewiesen, sobald es einen Eigentümer und einen Bearbeiter hat, in Arbeit, wenn die Arbeit beginnt, gelöst, wenn eine Lösung vorgeschlagen ist, und geschlossen, wenn die Person, die das Anliegen vorbrachte, oder die betroffene Anspruchsgruppe diesen Abschluss genehmigt. Der Zustand abgebrochen ist terminal und bleibt aus offen, zugewiesen und in Arbeit erreichbar.

Die Eskalation als bewachter Übergang

Die Eskalation löst aus, wenn die Frist zur Lösung verstreicht und das Item nicht gelöst ist. Sie leitet das Item auf die nächste Stufe der Eskalationsmatrix und bringt es in Arbeit zurück, mit einer neuen entscheidenden Instanz, einer neuen Frist, einem neuen Bearbeiter oder einem Entscheid zum Abbruch. Das eskalierte Item bewegt sich also weiter.

Das normierte Vokabular dieser Konstruktion ist jenes der Zustandsmaschinen der UML (OMG, UML 2.5.1, Klausel 14): Ein Zustand ist eine Lage, während der eine invariante Bedingung gilt, ein Übergang führt die Ausführung von einem Zustand in einen anderen, ein Auslöser stösst ihn an, eine Wächterbedingung ist eine boolesche Bedingung, die wahr sein muss, damit der Übergang genommen wird, und ein Effekt ist das, was dabei ausgeführt wird. Die Eskalation liest sich so: Auslöser, das Verstreichen der Frist; Wächterbedingung, [Frist überschritten UND Status nicht gelöst]; Effekt, der Wechsel der Entscheidungsstufe. Die Eskalation als Status zu modellieren, mit einem Zustand «eskaliert», in dem das Item verweilen würde, ist der naheliegende Fehler: Ein eskaliertes Item ist weiterhin in Bearbeitung, und das Register verliert dann die Unterscheidung zwischen dem, was ein Item ist, und dem, was ihm gerade widerfahren ist.

Der Analyst vereinbart die Eskalationsmatrix mit dem Sponsor vor der Eröffnung des Registers. Die Matrix nennt für jede Stufe einen messbaren Auslöser, die entscheidende Instanz und deren Mandat. Der Kanal gehört zur Regel: Ein kritisches Item wird mündlich oder telefonisch gemeldet, ein Item der laufenden Stufe geht durch die periodische Sitzung. Ein in Arbeitstagen gezählter Auslöser setzt einen Kalender voraus: In der Schweiz ist dieser kantonal, und der Bettagsmontag ist im Kanton Waadt kein Arbeitstag.

HERMES, die Projektmanagementmethode des Bundes, bündelt diesen Übergang in einer einzigen Aufgabe. Probleme behandeln und Erfahrungen nutzen (5.4.3.29) hält fest, dass der Bearbeitende ein Problem, das er nicht oder nicht rechtzeitig lösen kann, umgehend innerhalb der Projektorganisation eskaliert. Der Eskalationsprozess wird projektspezifisch im Projektmanagementplan geregelt. Was aus der Lösung gelernt wird, fliesst in das Ergebnis Projekterfahrungen (4.4.1.32), das über die ganze Projektdauer gesammelt wird. Wo das BABOK das Item Tracking von den Lessons Learned (§10.27) trennt, macht HERMES daraus die zwei Hälften einer einzigen Aufgabe.

Die Technik von der Erfassung bis zum Abschluss führen

1. Die Regeln setzen, bevor das Register eröffnet wird
   Welche Item-Typen im Einsatz sind, wer eines vorbringen darf, welche Status es gibt, in welcher Kadenz die Sitzung stattfindet, wie die Eskalationsmatrix lautet und wo das Register lebt. Man lässt diesen Schritt aus, und die meisten Register sterben nach einem Monat. Er wird im Business-Analyse-Ansatz oder im Governance-Plan dokumentiert.
2. Sofort erfassen
   Das Anliegen im Workshop, im Interview oder in der Sitzung festhalten: Kennung, Zusammenfassung, Identifikationsdatum, identifiziert durch.
3. Zulässigkeit prüfen
   Ablehnen, was ausserhalb des Umfangs liegt, zusammenführen, was schon erfasst ist, und die Ablehnung festhalten.
4. Einordnen
   Kategorie und Typ. Ein Fehler geht in den Korrekturablauf des Realisierungsteams, eine Annahme in eine Bestätigungsaktivität, eine Abhängigkeit zu dem, der das andere Ende hält.
5. Auswirkung bewerten und Priorität setzen
   Die Auswirkung auf den vier Achsen des BABOK, Termin, Kosten, Umfang, Qualität, mit einer Grösse. Die Priorität bei den betroffenen Anspruchsgruppen, nach dem Ordnungsschema, das das Vorhaben bereits anwendet: An diesem Schritt greift die Priorisierung (§10.33). Die Frist zur Lösung setzen.
6. Einen Eigentümer und einen Bearbeiter benennen
   Zwei benannte Personen und ein Eigentümer, dessen Stellung ihm erlaubt, beim Bearbeiter nachzuhaken.
7. Die Strategie vereinbaren
   Akzeptieren, weiterverfolgen, ignorieren, mindern, vermeiden. Die Strategie wird mit der betroffenen Anspruchsgruppe entschieden und dann festgehalten.
8. In fester Kadenz verfolgen und durchgehen
   Das Lösungsprotokoll hält den Fortschritt laufend fest. Die Sitzung geht das Register Item für Item durch, mit den Anspruchsgruppen, in vereinbartem Abstand, und das Register bleibt zwischen zwei Sitzungen geteilt. Das BABOK warnt, dass ein Item ein weiteres erzeugen kann und dass Lösungsanstrengungen dann nicht doppelt geleistet werden dürfen: Die Sitzung ist der Ort dieser Abstimmung.
9. Eskalieren, was stehen bleibt
   Die Eskalationsmatrix löst beim Verstreichen der Frist aus. Der Weg ist im Voraus festgelegt, und er führt zu einer Instanz, die entscheiden kann.
10. Auf Genehmigung schliessen
    Das BABOK legt die Genehmigung des Abschlusses in das Lösungsprotokoll: Der Abschluss wird genehmigt, in der Regel von der Person, die das Anliegen vorbrachte, oder von der betroffenen Anspruchsgruppe.

Die Kennzahlen des Registers

Das Register erzeugt Kennzahlen, und das BABOK macht sie zu einem Element der Technik: Sie sagen, ob die Items von den richtigen Ressourcen gelöst werden, ob das Vorhaben vorankommt und ob der Tracking-Prozess gelebt wird. Vier oder fünf genügen. Jede wird an einem Schwellenwert gemessen, und ein überschrittener Schwellenwert löst eine benannte Handlung aus: Eine Kennzahl, die nichts auslöst, ist eine Zahl im Bericht. Jede Sitzung sortiert zuerst nach dem Alter; es berechnet sich aus dem Identifikationsdatum. Ein Bündel wöchentlicher Indikatoren kostet mehr als die Items, die es beschreibt.

Die Technik unter ihren Nachbarn verorten

Item Tracking ist die allgemeine Technik, und zwei Techniken des BABOK spezialisieren sie je für eine Art von Item. Die Risikoanalyse und das Risikomanagement (§10.38) spezialisieren sie für Items, die künftige und ungewisse Ereignisse sind. Sie behalten das Register und fügen ihm eine Wahrscheinlichkeit hinzu, ein Risikoniveau, das diese Wahrscheinlichkeit mit der Auswirkung verbindet, und ein eigenes Behandlungsvokabular.

Die beiden Vokabulare teilen einen Kern: akzeptieren, mindern, vermeiden. Sie weichen dort voneinander ab, wo die Natur des Items es erzwingt. Die Risikobehandlung fügt übertragen und erhöhen hinzu, die nur vor einem noch nicht eingetretenen Ereignis Sinn ergeben: Man überträgt eine Exponierung an einen Versicherer, man erhöht eine Exponierung, um eine Chance zu ergreifen. Die vereinbarte Strategie des Item Tracking fügt weiterverfolgen und ignorieren hinzu, die nur vor einem bereits auf dem Tisch liegenden Anliegen Sinn ergeben. Die Übergabe zwischen den beiden Registern folgt derselben Logik: Ein Risiko, das eintritt, hört auf, ein Risiko zu sein, und wird zu einem Problem, das zu führen ist, also zu einem Item. Das Teal Book der britischen Regierung nennt denselben Umschlag: Ein erkanntes Risiko bleibt ein Restrisiko, oder es tritt ein und wird zu einem issue.

Das Backlog-Management (§10.2) spezialisiert die Technik für Arbeit, die wartet, weil die Kapazität fehlt. Das BABOK definiert es: Ein Backlog entsteht, wenn das Volumen der zu leistenden Arbeit die Kapazität übersteigt, sie zu leisten. Es fügt also eine Ordnung nach Wert und einen Pull-Mechanismus hinzu: Die Spitze des Backlogs ist die Arbeit, die als Nächstes getan wird. Ein Item-Register priorisiert, um zu entscheiden, was zuerst gelöst wird, während ein Backlog, ausgestattet mit einem Kapazitätsmodell und einem Pull-Mechanismus, priorisiert, um zu entscheiden, was als Nächstes gebaut wird. Ein Item, das sich als Stück Produkt erweist, geht ins Backlog.

Die Priorisierung (§10.33) liefert das Ordnungsschema, das das Prioritätsfeld des Registers verwendet. Das Item Tracking speist im Gegenzug die Lessons Learned (§10.27) beim Abschluss des Vorhabens, mit den Items, die sich wiederholt haben, und jenen, die eskaliert werden mussten.

Eine Werkzeugverwechslung bleibt zu klären: die Fehlerverfolgung des Realisierungsteams. Der Fehler ist einer der sieben Item-Typen des BABOK, ein Fehler kann also ein Item sein, doch das Werkzeug des Teams ist nach Version, Testumgebung und Testfall strukturiert, und Entwickler lesen es. Das Register des Business Analyst ist nach der Lösung und den Anforderungen strukturiert, und die Anspruchsgruppen lesen es; die Items des Business Analyst durch das Schema eines Fehlerwerkzeugs zu treiben, zwingt jedes Anliegen in die Form eines Bugs.

Die zweite Verwechslung betrifft das Problemjournal des Projekts, geführt von der Projektleitung. Das Glossar der Association for Project Management definiert ein issue über die Überschreitung einer delegierten Toleranz, was die Unterstützung des Sponsors verlangt. Dieser Begriff ist enger als das Item des BABOK, und das Projektjournal rahmt darum die Lieferung, ihre Termine, ihr Budget und ihren Umfang. Das Register des Business Analyst rahmt die Anliegen der Anspruchsgruppen zu den Anforderungen und zur Lösung, und sein Erfolgskriterium ist, dass die Person, die das Anliegen vorbrachte, es vorankommen sieht. Wo ein Problemjournal bereits besteht, eröffnet man darin einen Item-Typ oder eine Sicht und behält dort die Attribute des Business Analyst, angefangen bei Identifikation, Eigentümer, Bearbeiter und vereinbarter Strategie.

In Projekten nach HERMES kommt eine Nachbarin aus der Methode selbst: die Änderungsstatusliste (Ergebnis 4.4.1.3), erzeugt durch die Aufgabe Änderungen managen (5.4.3.2). Die Methode gibt dem Item vom Typ Änderung ein eigenes Dokument, das HERMES in der klassischen wie in der agilen Vorgehensweise als Mindestdokument fordert. Klassisch trägt jede Zeile die Nummer des Änderungsantrags, den Antragsteller, das Antragsdatum, den Entscheidungsverantwortlichen, den Status, das Änderungsdatum, den Änderungsverantwortlichen, den Aufwand, die Kosten und die Auswirkungen; agil hält die Liste mindestens die Identifikation des Antrags, sein Datum, seinen Status und das Änderungsdatum fest. Das Item-Register des Business Analyst verweist deshalb für jeden Änderungsantrag auf diese Liste.

Ebenso führt HERMES die Entscheide in zwei Ergebnissen, eines je Hierarchieebene: die Liste Projektentscheide Führung (4.4.1.20) und die Liste Projektentscheide Steuerung (4.4.1.21). Jede dokumentiert die Ergebnisse der Entscheidungsaufgaben ihrer Ebene während der ganzen Dauer des Projekts, mit dem Entscheid, dem erreichten oder nicht erreichten Meilenstein, den zugrundeliegenden Dokumenten, den Entscheidungsträgern und dem Datum. Der Auftraggeber entscheidet auf der Hierarchieebene Steuerung, der Projektleiter auf der Hierarchieebene Führung (§5.1.2.2 und §5.1.2.3).

Was das Register scheitern lässt

Das Register, das niemandem gehört

Die Items haben einen Eigentümer, das Register hat keinen. Niemand führt die Sitzung, niemand hakt bei den alternden Zeilen nach und die Datei liest nach sechs Wochen niemand mehr. Das Register braucht einen Hüter, verschieden von den Eigentümern der Items.

Das Item ohne Eigentümer oder «das Team» als Eigentümer

Ein Item, das allen gehört, gehört niemandem. Der Eigentümer des BABOK ist eine Anspruchsgruppe, im Singular, und sie trägt einen Namen.

Das seit einem Jahr «offene» Item

Die fehlende Eskalationsmatrix ist der Mangel: Eine Frist ohne Folge bei ihrer Überschreitung ist ein Wunsch. Das Alter des Items legt sie offen.

Das Schattenregister

Ein Item-Register des Business Analyst, parallel zum Tracking-Werkzeug des Realisierungsteams oder zum Projektjournal geführt. Zwei Register ergeben zwei Wahrheiten, und die Anspruchsgruppen lesen jenes, das die Entwickler nicht speisen.

Das Verfolgen, das an die Stelle des Entscheidens tritt

Das Item, in jeder Sitzung nachgelesen, neu diskutiert und neu priorisiert, nie entschieden. Das ist der Ausfallmodus der Technik, und sein Mechanismus lautet: Das Register lässt Unentschlossenheit wie Fortschritt aussehen. Das Lösungsprotokoll füllt sich, die Sitzung wirkt produktiv, die Zeile wirkt aktiv. Der Status hat sich nicht um eine Stufe bewegt. Ein alterndes Item mit einem reich gefüllten Lösungsprotokoll ist deshalb der schlimmste Fall des Registers. Der Melder ist bereits da, in den Kennzahlen: das Alter, gekreuzt mit einem über drei Sitzungen unveränderten Status. Diese Kreuzung verlangt eine Entscheidung, auch die Entscheidung zu ignorieren, festgehalten als vereinbarte Strategie.

Die überbordende Erfassung

Das BABOK nennt die Grenze: Die ausgiebige Datenerhebung zu den Items kann den erzielten Nutzen überwiegen, und die Anspruchsgruppen können in den Details und den Statistiken versinken. Die Formel «alle oder ein Teil» der fünfzehn Attribute erlaubt es, sechs zu führen.

Die fehlende Triage der Zulässigkeit

Alles Gesagte wird zum Item, das Register schwillt an und die Priorität hört auf, etwas zu bedeuten, weil alles darin steht.

Die in Adjektiven geschriebene Auswirkung

«Hoch», ohne Skala dahinter. Eine Auswirkung wird auf einer Achse ausgedrückt, mit einer Grösse.

Der stille Abschluss

Ein Item zu schliessen, an dem die Person, die es vorbrachte, noch hängt, oder ein abgelehntes Item zu löschen, zerstört das Vertrauen, für dessen Aufbau das Register eröffnet wurde. Der Abschluss wird genehmigt, die Ablehnung wird festgehalten.

Die als Status modellierte Eskalation

Ein Zustand «eskaliert», in dem das Item verweilen würde, vermengt die Lage des Items mit dem Ereignis, das ihm gerade widerfahren ist. Die Eskalation ist ein bewachter Übergang: Das eskalierte Item bleibt in Arbeit, und die Stufe, die über es entscheidet, wechselt.

KI-Überlegungen

Item Tracking ist eine Technik, deren eine Hälfte Schreibarbeit ist. Die künstliche Intelligenz greift diese Hälfte an: Die KI macht das Erfassen billig, und billiges Erfassen ist das, wovor das BABOK warnt. Ein Register, das auf vierhundert Items angewachsen ist, weil die Erfassung gratis wurde, ist ein Register, das niemand mehr durchgeht. Die einzige Frage, die vor einem Item zählt, lautet deshalb: Wird jemand handeln?

Die Erfassung aus der Sitzung: Ein Sprachmodell auf der Transkription eines Workshops schlägt für jedes geäusserte Anliegen eine Zusammenfassung, das Datum, den Urheber und einen Typ vor. Die Nachbereitung des Workshops ist der teuerste Posten der Technik: eine Zusammenfassungsaufgabe, die diese Modelle gut beherrschen. Der Business Analyst korrigiert, und wer das Item vorbrachte, bestätigt die Formulierung in der nächsten Sitzung. Die Klassifikation in die sieben Typen des BABOK: ein kurzer, stabiler Etikettensatz auf einem kurzen Text, wobei ein Fehler billig ist, weil die Sitzung das Etikett korrigiert. Die Erkennung von Doubletten und Verknüpfungen: Semantische Ähnlichkeit findet in einem Register von zweihundert Zeilen das mit anderen Worten bereits erfasste Item, und eine Person bestätigt die Übereinstimmung, bevor aus zwei Items eines wird. Die Erkennung des Stillstands: Items melden, deren Status sich seit einer gegebenen Zahl von Tagen nicht bewegt hat, deren Frist verstrichen ist oder deren Lösungsprotokoll den vorherigen Eintrag mit anderen Worten wiederholt. Das ist die mechanische Hälfte der Eskalationsmatrix. Das Formulieren der Auswirkung auf den vier Achsen geht vom Item und vom Plan des Vorhabens aus; der Eigentümer genehmigt den Vorschlag, bevor er ins Register kommt.

Den Eigentümer zu benennen ist ein Akt der Verantwortung: Ein Modell kann aus der Stakeholder-Landkarte einen Namen vorschlagen, es kann niemanden verantwortlich machen. Ein von einem Werkzeug zugeteilter Eigentümer ist ein Eigentümer, der nichts angenommen hat. Die Priorität zu setzen gehört den betroffenen Anspruchsgruppen, und es ist eine Verhandlung zwischen auseinandergehenden Interessen: Ein Modell, das das Register nach abgeleiteter Schwere ordnet, hat sein Urteil an ihre Stelle gesetzt und die Rangfolge erzeugt, die niemand genehmigt hat. Die Strategie zu vereinbaren und das Item zu schliessen sind Entscheidungen mit politischer Reichweite, und der Abschluss wird erst ausgesprochen, wenn er genehmigt ist. Ein Item, das automatisch geschlossen wird, weil ein Modell es für gelöst hielt, ist ein stiller Abschluss, ausgesprochen auf der Ebene des ganzen Registers.

Die Sensibilität der Daten ist der harte Punkt, den das Item-Register selbst mitbringt. Die Zusammenfassungen der Items nennen Personen, halten fest, wer sich über wen beklagt hat, und tragen die Konflikte des Vorhabens im Klartext. Ein Register in ein öffentliches Modell zu giessen, heisst die interne Politik der Organisation zu exportieren und Personendaten mit ihr. In der Schweiz gilt das revidierte Datenschutzgesetz (revDSG), in Kraft seit dem 1. September 2023: Ein Item-Register mit Namen darin ist eine Bearbeitung von Personendaten. Die praktische Folge: ein Modell einsetzen, das die Organisation beherrscht, oder die Namen vor dem Prompt entfernen.

Beispiele

Eine Vorsorgeeinrichtung nach BVG mit Sitz in Lausanne (PLZ 1003), die die Angestellten von rund 120 angeschlossenen Arbeitgebern versichert, ersetzt ihr Arbeitgeberportal. Das Register trägt die Items, die in den ersten beiden Elizitation-Workshops vom 6. und 9. Juli 2026 vorgebracht wurden, mit der Anschlussverwaltung, dem Betrieb, einer Anwendergruppe von Arbeitgebern und der Finanzleitung. Es wird gezeigt, wie es sich am 30.09.2026 liest: An diesem Datum prüfen sich Status, Fristen und Eskalation gegenseitig.

Das Register führt zwölf der fünfzehn Attribute des BABOK. Kategorie und Lösungsprotokoll leben hinter jeder Zeile, im Werkzeug, und die Eskalation lebt in ihrer eigenen Matrix.

ITM-003 wurde auf Stufe 3 eskaliert. Am Stichtag 30.09.2026 ist das Item in Arbeit: Gewechselt hat die Instanz, die über es entscheidet, vom Projektleiter zum Lenkungsausschuss. Kein Zustand «eskaliert» erscheint in der Statusspalte.

Visualisierungen

Das Register, die Eskalationsmatrix und die Kennzahlen sind Objekte aus Zeilen und Spalten, gelesen, sortiert und gefiltert von Anspruchsgruppen: zwölf Attribute für sechs Items, vier Eskalationsstufen, fünf Kennzahlen und ihre Schwellenwerte. Sie werden zu Tabellen.

Der Lebenszyklus des Items ist ein räumliches Objekt: sieben Zustände, gerichtete Übergänge, drei Endzustände, eine Wächterbedingung auf einer Kante und ein Zweig, der den Zustand «in Arbeit» verlässt und zu ihm zurückkehrt. Das ist eine Zustandsmaschine. Eine Tabelle «aktueller Status, nächster Status» verlöre, was die Technik lehrt und was eine Tabellenkalkulation nicht gibt: die Wächterbedingung, die die Eskalation auslöst, und die Rückkehr des Items in Arbeit.

Der Lebenszyklus dient auch im Alltag: Neben ein reales Register gelegt, macht er daraus ein Prüfinstrument.

• Ein Item, das «offen» blieb, ohne je auf «zugewiesen» zu wechseln, hat keinen Eigentümer, und das Register hat es durchgehen lassen.
• Ein Item, dessen Status «eskaliert» lautet, verrät ein schlecht gesetztes Zustandsmodell, denn die Eskalation ist ein Übergang.
• Ein Item, das von «gelöst» auf «geschlossen» wechselte, ohne Spur einer Genehmigung im Lösungsprotokoll, wurde vom Hüter des Registers geschlossen: Das ist der stille Abschluss.

Aufwand

Werkzeuge

Das Protokoll mit Pendenzenliste ist die günstigste Form: eine Kennung, eine Zusammenfassung, ein Eigentümer, eine Frist. Sie passt zu einem kurzen Mandat mit einer Handvoll Anspruchsgruppen, und sie ist mehr wert als ein regelkonformes Register, das niemand pflegt.

Die Tabellenkalkulation funktioniert. Ihr üblicher Ausfall ist die Kopie: fünf Versionen und ein Mailverlauf, wo ein einziger Hüter und eine einzige geteilte Kopie genügen. Sie bietet dafür die Sortierung nach Alter in einer Formel, die die meisten Register nicht haben. Kollaborative Seiten und Listen (eine Confluence-Tabelle, eine SharePoint-Liste, eine Notion-Basis) beheben diesen Mangel: geteilt, versioniert, nach Status und Eigentümer filterbar, ohne Installation. Das ist die pragmatische Wahl, wenn das Realisierungsteam kein Tracking-Werkzeug hat.

Ticket-Tracking-Werkzeuge (Jira, Azure DevOps, GitLab, Redmine) geben gratis, was die Technik andernorts von Hand aufzubauen verlangt: das Zustandsmodell, die Zuweisung, die Berechnung des Alters und die durch eine Dienstleistungsvereinbarung gesteuerte Eskalation. Die sieben Item-Typen des BABOK übersetzen sich direkt in Ticket-Typen. Diese Wahl drängt sich dort auf, wo das Realisierungsteam bereits arbeitet, und sie entschärft die Falle des Schattenregisters. Plattformen für Service-Management und Compliance (ServiceNow und Gleichwertige) rechtfertigen sich, wenn eine Dienstleistungsvereinbarung die Eskalationsmatrix durchsetzen soll, statt dass eine Person an sie denken muss, und wenn Items Organisationsgrenzen überschreiten. Für ein Register im Massstab eines einzelnen Vorhabens sind sie schwer.

Werkzeuge für das Anforderungsmanagement mit einem verknüpften Item- oder Problemobjekt (Jama Connect, IBM DOORS Next, Polarion, Visure) bieten, was eine Tabellenkalkulation nicht gibt: die Rückverfolgbarkeit vom Item zur Anforderung, die es bedroht, sodass eine blockierte Anforderung in der Traceability-Matrix als blockiert erscheint. Das ist im regulierten Umfeld seinen Preis wert, wo der Auditor diese Spur verlangen wird. Welches Werkzeug es auch sei, die Regel ändert sich nicht: ein einziges Register, geteilt, dessen Status eine Anspruchsgruppe lesen kann, ohne fragen zu müssen.

Quellen

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.26 Item Tracking: die Ankerquelle, das Ziel, die sieben Item-Typen, die fünfzehn Attribute des Eintrags, die als Beispiele gegebenen Status, die Eskalationsmatrix, die Item-Führung, die Kennzahlen, die Stärken und die Grenzen.
• UK Government Project Delivery Function, The Teal Book, Kapitel 21: Issue management: der Umschlag vom Risiko zum Problem (ein eintretendes Risiko wird zum issue), die Toleranzen als Eskalationsauslöser und die Abfolge erkennen, bewerten, reagieren, überwachen und berichten, dann schliessen, mit einem benannten Eigentümer je issue.
• Association for Project Management, Glossary of project management terms: die Definitionen von issue, issue log und issue management durch einen Berufsverband, gegründet auf die Überschreitung einer delegierten Toleranz, enger als das Item des BABOK.
• Object Management Group, Unified Modeling Language (UML) v2.5.1, Klausel 14 StateMachines und §13.3.4 zum Auslöser: das normierte Vokabular der Zustandsmaschinen, Zustand, Übergang, Auslöser, Wächterbedingung und Effekt, das die Lesart der Eskalation als bewachtem Übergang und die Notation des Lebenszyklus begründet.
• Schweizerische Eidgenossenschaft, Bundeskanzlei, HERMES 2022, Referenzhandbuch Projektmanagement, Aufgabe 5.4.3.29 Probleme behandeln und Erfahrungen nutzen, Ergebnis 4.4.1.32 Projekterfahrungen: die umgehende Eskalation des Problems, dessen Lösung durch den Bearbeitenden nicht oder nicht rechtzeitig möglich ist, der im Projektmanagementplan geregelte Eskalationsprozess und die laufende Sammlung der Erfahrungen als einziges Ergebnis der Aufgabe.
• Schweizerische Eidgenossenschaft, Bundeskanzlei, HERMES 2022, Referenzhandbuch Projektmanagement, Ergebnis 4.4.1.3 Änderungsstatusliste, Aufgabe 5.4.3.2 Änderungen managen: das Register zur Verfolgung der Änderungsanträge, in der klassischen wie in der agilen Vorgehensweise als Mindestdokument gefordert, mit dem für jede von beiden verlangten Inhalt.
• Schweizerische Eidgenossenschaft, Bundeskanzlei, HERMES 2022, Referenzhandbuch Projektmanagement, Ergebnis 4.4.1.20 Liste Projektentscheide Führung, Ergebnis 4.4.1.21 Liste Projektentscheide Steuerung: die zwei Entscheidregister, eines je Hierarchieebene, mit ihrem Inhalt (Entscheid, Meilenstein erreicht ja/nein, zugrundeliegende Dokumente, Entscheidungsträger, Datum). Das Referenzhandbuch verteilt die Ebenen in §5.1.2 Entscheidungsaufgaben: Die Entscheide der Steuerung sind jene des Auftraggebers, die Entscheide der Führung jene des Projektleiters.