In Teil 1 ging es um ein paar Grundlagen zum Aufbau des Modells und in Teil 2 um die Definition des Soll-Zustandes. Teil 3.1 stellte die verschiedenen Assessment-Typen und die Auswahl der Assessoren sowie den Ablauf der Assessments vor; Teil 3.2 die detaillierte Analyse des IST-Zustandes, also v.a. um die Phase “Performing” am Beispiel eines TPI Light-Assessments und eines Self-Assessments.

In diesem letzten Teil geht es nun um die Auswertung der Assessmentergebnisse und die Initiierung der Verbesserungen.

Ein beispielhaftes (Teil-)Ergebnis

Beispiel: Sie haben u.a. den Kernbereich Engagement der Stakeholder (Stakeholder Commitment) assessiert und ihre Ergebnisse sehen so aus:

1. Als Stakeholder wurden Ihnen folgende Rollen benannt und dies auch von alle befragten Testern überwiegend gleichartig:
   Der Endkunde <xyz> wobei allen deutlich klar war, dass es hier um zwei unterschiedliche Parteien geht:
   • den tatsächlich Zahlenden und
   • die tatsächlichen Nutzer des Systems. Zusätzlich wurde manchmal auch noch das
   • Testmanagement genannt.
2. Der Testplan verweist auf den Projektplan und in diesem sind diese, aber auch weitere Stakeholder definiert (z.B. Vertrieb, weitere mitbetroffene Projekte, die die Projektergebnisse nutzen werden, …)
3. Die Ressourcen für das Testen werden vom Testmanagement budgetiert und im Rahmen des Gesamtbudgets des Projektes vom Projektleiter bei der Projektbeantragung/-beauftragung als eigener Posten dargestellt und von dem entsprechenden Gremium genehmigt.
4. Das Testmanagement kann im Rahmen des genehmigten Budgets frei verfügen und hat eigenes Personal, eigene Räumlichkeiten und eigene Testmittel zur Verfügung.
5. Das zu testende System kann optimal nur auf der Zielhardware getestet werden von der für Entwicklung und Test zusammen nur eine sehr geringe Anzahl zur Verfügung steht, um die sich Entwicklung und Test immer wieder streiten.
6. Es wird im Projektkontext eine FMEA durchgeführt, an der auch Tester beteiligt werden. Diese wird im Test nach Aussage des Testmanagers zur Priorisierung der Tests benutzt. Darüber sind aber keinerlei Dokumentationen verfügbar und die Priorisierung von einzelnen Testfällen ist nicht explizit begründet und nicht nachvollziehbar.

Kontrollpunkte und darauf basierende Empfehlungen der TPI NEXT Autoren

Die zugehörigen Kontrollpunkte sind für den Level Controlled:

1. Der hauptsächliche Stakeholder ist definiert (wenn auch nicht unbedingt dokumentiert) und den Testern bekannt.
2. Das Budget für die Testressourcen ist durch den hauptsächlichen Stakeholder garantiert und kann mit ihm verhandelt werden.
3. Alle Stakeholder sorgen für die Ressourcen zu denen sie sich committet haben.
4. Der hauptsächliche Stakeholder ist für die dokumentierte Produktrisikoanalyse verantwortlich (als Eingangsdokument für die Teststrategie).

Nutzen Sie dabei für den schnellen Überblick die TPI Matrix zur Darstellung der gewünschten und der tatsächlich erreichten Ziele und notieren Sie die gefundenen Ergebnisse in den Kommentarspalten, so dass Ihre Bewertung nachvollziehbar wird.

Was denken Sie, welcher Kontrollpunkt wurde erreicht? Ich mache es mal spannend – meine Einschätzung werde ich in als Kommentar nachreichen. Hier geht es mir um die Nutzung des Buches [TPI NEXT].

Das angenehme und besondere dieses Modells sind die recht konkreten Empfehlungen, die zum angegebenen Beispiel wie folgt lauten (Übersetzung aus [TPI NEXT] S. 59):

“Der erste Schritt hin zu einem stärkeren Engagement kann darin bestehen, die Person zu ermitteln, die den Auftrag für die Testaktivitäten erteilt und/oder selbst stark auf die Testergebnisse angewiesen ist.

Ein wichtiger Aspekt in diesem Kernbereich ist das Bewusstsein, z.B. für die Konsequenzen inkorrekt ausgeführter Tests. Untersuchen Sie die Folgen unzureichender oder ungenauer Tests für die Produktion (wie  z.B. Qualitätsprobleme und mögliche Schäden für das Unternehmen), aber auch die Auswirkungen auf das Produkt selbst.

Zeigen Sie den Stakeholdern, wie das Testen zum Vermeiden solcher Probleme beitragen kann. Führen Sie konkret auf, welche Fehler früher hätten gefunden werden können und wie viele Probleme hätten vermieden werden können.

Verdeutlichen Sie, welche Voraussetzungen das Testen braucht, um solche Probleme zu vermeiden. Was hätten die Stakeholder tun können, umd idese konkreten Probleme zu vermeiden, und was können die Stakeholder jetzt tun, um ähnliche Probleme in Zukunft zu vermeiden?

Wählen Sie pragmatische, realisitsche Beispiele und konzentrieren Sie sich auf kurzfristige Investitionen und kurzfristige Ergebnisse.”

Und an diesem Beispiel zeigen sich auch die Schwächen der gegebenen Empfehlungen (und – nebenbei bemerkt – auch manchmal der Formulierungen im Englischen bzw. dem verwendeten Stil): Diese Verbesserungsvorschläge passen mitunter nicht oder nicht besonders gut zu den tatsächlichen Assessmentergebnissen.

Daher empfehle ich grundsätzlich folgendes Vorgehen: Lesen Sie im Anschluss an das Assessment noch einmal das gesamte Kapitel zu dem jeweiligen Kernbereich durch, vor allem auch die Enabler und auch die Verbesserungsvorschläge. Bedenken Sie, was die Erreichung des jeweiligen Levels des Kernbereiches bedeutet, welchem Zweck es dient und welche Ziele erreicht werden sollen. Dann vergleichen Sie dies mit Ihren Ergebnissen und beantworten folgende Fragen:

• “Welche Kontrollpunkte wurden nicht (ausreichend) erfüllt?”
• “Woran liegt das vermutlich?”
• “Was müsste getan werden, um diese Situation zu verbessern?”
• “Welche Schritte sind als Erstes zu tun, damit die Kontrollpunkte erfüllt werden können?”
• “Welche der Ermöglicher müssten noch verbessert werden?”

Je nachdem, welchen Fokus das Assessment hat, können Sie sich diese Fragen zu allen assessierten Kernbereichen stellen, die den gewünschten Level nicht erfüllen, oder aber auch hier noch einmal priorisieren entsprechend der Vorarbeiten zu dem Assessment oder entsprechend dem Motto: “Zuerst die schwächsten Schwächen beseitigen”. Achten Sie dabei vor allem auf die Abhängigkeiten.

Die Benennung aller gefundenen Schwächen und das Aufzeigen entsprechender Verbesserungsvorschläge bei der Erstellung des Assessmentberichtes bietet den Vorteil, dass sich das Management bei der Präsentation einen vollständigen Überblick verschaffen kann und sich in der Phase Aktionen planen an der Diskussion über die Priorisierung der nächsten Aktivitäten eher objektiv beteiligt und dazu dann auch möglicherweise bereitwilliger entsprechende Ressourcen zur Verfügung stellt. In einem Verbesserungsworkshop können Kosten-Nutzen-Relationen ausgearbeitet und kurzfristig wirksame Lösungen initiiert werden.

Gerne wiederhole ich dabei noch einmal den Satz aus Teil 3.1 : Die Berechnung von ROIs ist wichtig und hilft dabei, dass dies keine traurige Einmalaktion bleibt, sondern dass weitere zukünftige Verbesserungen gerechtfertigt werden können.

Fazit

TPI NEXT ist ein Modell, dass sich sowohl für ausführliche mehrtägige Assessments durch externe Assessoren eignet, als auch für Self-Assessments und gesteuerter Quick- oder Light-Assessments.

Das Tool zu TPI NEXT V 1.0 lief bei mir (Windows XP, MS Excel 2003) leider nicht fehlerfrei. Mittlerweile gibt es aber eine verbesserte Version, die sehr gut funktioniert.

Ich hoffe, diese Artikelreihe hat Ihnen einen Einblick in die Verwendung von TPI bzw. TPI NEXT gegeben und ermutigt, das Modell aktiv zu nutzen.

Ich freue mich über Ihre Fragen und Anmerkungen – hier als Kommentar oder gerne auch per Mail.

Viel Erfolg bei der Anwendung!