Wer ein Software-Projekt startet, tut das doch besser mit einer Nutzenbewertung des Projekts, bevor ihm hinterher der Spott um die Ohren fliegt!
Software-Projekte werden ja nicht zum reinen Selbstzweck durchgeführt, sondern sie sollen einen konkreten Nutzen für eine oder mehrere Anwendergruppen schaffen. Erfolg oder Scheitern lässt sich nur definieren und messen in Bezug auf diesen Nutzen.
Was soll dabei herauskommen?
Was soll nach der Einführung der neuen Software-Lösung besser laufen? Wie besser und wie viel besser? Bei vielen Unternehmen stellt sich heraus, dass eine Nutzenbetrachtung für Software-Projekte nicht erfolgt.
Vielmehr werden Projekte immer wieder aufs Neue gestartet, aber nur wenige werden tatsächlich bewertet: Hat sich das jetzt gelohnt? Wie viel haben wir dafür an Personen-/Projekttagen ausgegeben und hat das Projekt das wieder eingespielt? Warum fällt die Antwort darauf vielen so schwer?
Nutzenlose und sinnlose Projekte
Da wird zum Beispiel ein neues CRM-System (CRM = Customer Relationship Management) für die Kundenbetreuung eingeführt. Dass es bestimmt was nutzt, ist allen irgendwie klar – aber was? Und wie viel? Also fragt der interne Projektauftraggeber nach und bekommt von den IT-Mitarbeitern als Antwort: "Wir haben das Projekt abgeliefert – aber keine Ahnung, was das jetzt im Endeffekt bringt. Woher sollen wir das denn wissen? Es waren doch Sie, der den Auftrag dazu gegeben hat! Wir dachten, Sie wüssten, was das bringen soll!" Vielleicht nutzt es ja wirklich was – aber konkret wissen beide Parteien es nicht.
Deshalb sagen Endanwender auch oft: "Das war ein Projekt für die Tonne. Das bringt uns nichts. Die alte Lösung war viel besser." Das ist noch nicht einmal das Schlimmste. Das Schlimmste ist: Ohne Projektbewertung erkennt niemand im Voraus die Sinnlosigkeit eines Projekts. Deshalb werden so viele Software-Projekte gestartet, die man von vornherein lieber hätte bleiben lassen sollen.
Wobei immer irgendein schlauer Kopf von Anfang an mutmaßt, dass „das Ganze sowieso nichts bringt". Aber ohne aussagefähige Nutzenbewertung hört keiner auf ihn, weil man ihm nicht wirklich widersprechen kann.
Nutzen schätzen
Natürlich ist der Nutzen von derartigen Software-Projekten oft nur schwer zu fassen. Aber soll man seine Nutzenbetrachtung deshalb aufgeben? Bloß weil es "schwer" ist? Man kann jeden Nutzen zumindest näherungsweise bestimmen. Eine seriöse Schätzung ist in jedem Fall besser als das beste Bauchgefühl.
Dabei gelten zwei Prämissen:
1. Was man nicht messen kann, kann man schätzen.
2. Eine Annahme ist besser als keine Annahme. Denn: Annahmen lassen sich überprüfen – Bauchgefühl nicht.
Handlungsmaxime: Vor Projektstart – immer erst "die Eingeborenen" fragen!
Aber wer tut das schon? Hand aufs Herz: Bei wie vielen Software-Projekten in Ihrem Unternehmen wurden die Endanwender bislang ernsthaft und fundiert nach ihrer Nutzenerwartung befragt? Natürlich frisst das Zeit und natürlich wollen Anwender meist Widersprüchliches und Maximales. Aber sie deshalb a priori zu ignorieren ist Vabanque.
Das zweite Hindernis für eine verlässliche Nutzenschätzung: Welche ehrgeizige Führungskraft lässt sich schon von einem "kleinen Anwender" sagen, dass sein Projekt doch nicht so toll ist wie er es am grünen Tisch angenommen und bereits lauthals vor der Geschäftsleitung verkündet hat?
Alle müssen den Nutzen kennen!
Vorgehensweise, Lieferergebnisse und Aktivitäten im Projekt müssen an diesem Nutzen ausgerichtet sein. Jeder Mitarbeiter muss diesen Nutzen kennen und verstanden haben, um seinen Beitrag dazu beitragen zu können. Da jeder Mitarbeiter täglich Entscheidungen in seinem Fachgebiet treffen muss, ist es von enormer Bedeutung, dass bei allen ein gemeinsames Verständnis vom Nutzen des Projekts herrscht.
Die folgenden 5 typischen Fragen zum Projekt-Nutzen sollen Ihnen einen ersten Eindruck vermitteln und Sie zum Nachdenken über das eigene Projekt anregen:
1. Wer sind die Anwender? Welche Anwendergruppen gibt es?
2. Was benötigen diese Anwender tatsächlich, um mit der angedachten Software-Lösung täglich gerne und effektiv zu arbeiten?
3. Was tragen die einzelnen Lieferergebnisse zum Nutzen bei?
4. Was könnte den Nutzen gefährden?
5. Wie würden die einzelnen Mitarbeiter, ihren jeweiligen Beitrag zum Nutzen beschreiben?
Die Fragen zielen darauf, die Anwender zu identifizieren und sich in ihre Situation zu versetzen. Insbesondere die zweite Frage ist hilfreich, um den Nutzen zu erkennen. Kein Projektauftraggeber beauftragt die Implementierung eines neuen Software-Systems zum Selbstzweck. Er kauft immer den Nutzen, den er sich von der Software-Lösung verspricht.
Die Fragen zum Nutzen sind zu Projektbeginn obligatorisch, lohnen sich aber auch zwischendurch: einerseits zur Rückbesinnung und andererseits zur Kurskorrektur.
