Effektivität ist, die richtigen Dinge (richtig) tun. Effektivität ist ein Maß für die Zielerreichung (Wirksamkeit, Qualität der Zielerreichung), also die strategische Komponente. Effektivität ist wichtiger wie Effizienz. Das verlangt Weitsicht, wissen wohin die Reise geht, wissen wie die Reise vonstatten geht, wissen was und wo das Ziel ist, wissen wer diese Reise initiiert und warum, wissen was in jedem Schritt des Prozesses z.B. eines IT-Projekts die richtigen Dinge sind. Einige Vorgehensmodelle wie RUP, CMMI, SCRUM geben hier Antworten. Erfahrung ist wohl die beste Antwort.
Wie lässt sich erkennen ob die Dinge auch die Richtigen sind? Hier gibt es einfache Prüfmuster, die man zuerst nehmen sollte. Effizienz-Messungen geben teilweise Auskunft. Die wichtigen Fragen ergeben sich aus dem Studium von RUP, SCRUM und CMMI. Hier einige Fragen aus der Praxis:

  • Wie stabil ist die Highlevel-Sicht der Projektplanung (die richtigen Dinge sind im Plan)
  • Wie häufig muss das Risiko Management nachgearbeitet werden (die richtigen Risiken sind erfasst)
  • Wie gut ist der Grad der gemeldeten Fertigstellung mit der effektiv geleisteten Fertigstellung (Deckungsgleiche Plan=Soll – Projekt=Ist) (die richtige Methode zur Messung des Fortschritts ist etabliert)
  • Wie volatil sind die Requirements; wie inkrementell / iterativ ist mein Business und wie reagieren wir darauf (andere wichtige Dinge priorisieren)
  • Wie häufig kommen Missverständnisse zwischen Requirements Engineering und Analyse & Design vor (die richtige Schnittstelle zur Transformation)
  • Wie ist die Werkzeugunterstützung für alle Disziplinen und wo gibt es Brüche; sind die Brüche gemanagt (das richtige Toolset)
  • Haben die Entwickler eine stabile Platform zum entwickeln, testen, prototypen und ist diese allen vollständig bekannt (das richtige Setup für die Produktion)
  • Funktioniert die Entwicklung und das Deployment von Releases oder gibt es jedes mal Abstimmungsprobleme (die richtige Kommunikation)
  • Wissen die Tester was sie testen, erhalten sie die Use Cases in der Form, das Test Cases formulierbar sind (die richtige Einbindung von Spezialisten)
  • Ist der Abdeckungsgrad des User Acceptance Test mit dem Business problematisch und woran liegt das (die richtigen Requirements)
  • Wie ist der Abdeckungsgrad der Anwendererfahrungen mit den Nichtfunktionalen Anforderungen (die richtigen Betriebsfälle)
  • Wie werden Fehler und Probleme gemanagt. Kommen die Probleme ohne Umweg zum Experten (den richtigen Prozess aufgesetzt)
  • Hat der Experte überhaupt Zeit diese Probleme zu lösen (Widerspruch Releaseplanung ./. Produktionsissue) (die Planungsphase richtig gemacht)