Als Prüfer freue ich mich immer, wenn Prüflinge in der Projektdokumentation eine Nutzwertanalyse anfertigen. Denn die kann man immer schön auseinandernehmen, weil sie meist völlig falsch verwendet wird oder nicht korrekt umgesetzt ist. Irgendwo im Internet steht anscheinend, dass jede gute Projektdokumentation eine Nutzwertanalyse enthalten muss. Das ist natürlich völliger Quatsch, aber anders kann ich mir den häufigen Einsatz dieser Methodik nicht erklären. Deswegen ist es an der Zeit, dass ich hier einmal meine Meinung zu Nutzwertanalyse darlege.

Sinn einer Nutzwertanalyse

Der Sinn einer Nutzwertanalyse ist, mehrere Alternativen miteinander zu vergleichen, die nicht (nur) durch harte Kriterien verglichen werden können. Harte Kriterien sind in diesem Fall meist monetäre Aspekte, also ein Geld- oder Zeitaufwand (der letztlich in Geld umgerechnet werden kann).

Wenn ich z.B. einen neuen Server kaufen soll, kann ich für die gleiche Hardware mehrere Angebote von Verkäufern einholen und entscheide mich dann für das günstigste. Oder wenn ich mich für eine bestimmte Implementierung entscheiden muss, wähle ich einfach diejenige, die am schnellsten umzusetzen ist, also die wenigsten Personentage Aufwand produziert. Dabei bedarf es keiner Nutzwertanalyse, sondern lediglich der Anwendung von Math.min(). 😉

Sobald ich aber Alternativen habe, die sich nicht nur durch den Preis unterscheiden, brauche ich ein Werkzeug, um diese Alternativen nicht aus dem Bauch heraus voneinander abzugrenzen, sondern möglichst objektiv meine Entscheidung zu unterstützen. Wenn ich also nicht den gleichen Server bei verschiedenen Anbietern anfrage, sondern um eine Lösung für meinen Mailserver bitte und mir die Anbieter unterschiedliche Hardware und darüber hinaus noch SLAs, Garantie, Support usw. anbieten, dann wird die Entscheidung relativ schwierig, weil der Vergleich sehr komplex ist und ich mich nicht nur auf ein Kriterium – nämlich den Preis – beschränken kann.

Sobald also – meist mehrere – weiche Faktoren in die Entscheidung einspielen, benötige ich ein Werkzeug, um diese möglichst objektiv zu bewerten und zu vergleichen. Und das ist die Nutzwertanalyse.

Allerdings ist die Nutzwertanalyse ein standardisiertes Verfahren, das genau vorgegebenen Regeln folgt. Einfach eine Tabelle zu zeichnen und ein paar Zahlen einzutragen, reicht also nicht. Deswegen kann man als Prüfer die Nutzwertanalyse auch so schön auseinandernehmen und den Prüflingen – dann meist im Fachgespräch – um die Ohren hauen.

Ich gehe im Folgenden davon aus, dass du schon grundsätzlich weißt, wie eine Nutzwertanalyse aussieht und insb. was Kriterien und der Nutzenkoeffizient sind. Wenn das nicht der Fall ist, schau mal in die Wikipedia (Nutzwertanalyse) oder noch besser ins IT-Handbuch*.

*

Nutzwertanalyse für das eigene Projekt

Sehr häufig sehe ich in Projektdokumentationen – insbesondere wenn die Prüflinge Probleme haben, ihr Projekt monetär zu bewerten – eine Nutzwertanalyse für das eigene Projekt. Dort wird dann die Ist-Situation mit der zukünftigen Soll-Situation, die das eigene Projekt herstellen soll, verglichen. Hier wird also eine fiktive Situation dem Ist-Zustand gegenübergestellt. Da frage ich mich schon immer direkt, wie das möglich sein soll. Denn wer kann eine nicht vorhandene zukünftige Situation so bewerten, dass sie mit dem heutigen Zustand vergleichbar ist? Das sieht für mich immer danach aus, dass man irgendwo im Internet gelesen hat, dass man eine Nutzwertanalyse braucht, auch wenn sie – wie in diesem Beispiel – völlig sinnfrei ist.

Da wird dann z.B. als Kriterium für den Vergleich die Ergonomie angeführt. Die neue Anwendung wird (natürlich) viel ergonomischer sein als die alte. Also bekommt die neue Anwendung hier mehr Punkte.
Aber wie soll z.B. der Fachbereich die Ergonomie der heutigen Anwendung mit einer zukünftigen vergleichen, die er noch nie zu Gesicht bekommen hat? Das ist doch völliger Quatsch! Hier wird offensichtlich einfach eine Begründung für das Projekt gesucht und mit der Nutzwertanalyse eine Pseudo-Rechtfertigung geschaffen, die die eigentliche Bauchentscheidung irgendwie methodisch unterstützen soll.

Nutzwertanalysen sind ein gutes Werkzeug, um Entscheidungen im Verlauf des Projekts zu begründen – was ein wichtiger Bestandteil jeder Projektdokumentation ist. Aber sie eignen sich nicht dazu, die Durchführung des eigenen Projekts zu begründen. Jedenfalls nicht, wenn man die Ist-Situation mit der Soll-Situation vergleicht. Stattdessen wäre die Nutzwertanalyse hilfreich, um die Eigenentwicklung von der Fremdfertigung abzugrenzen. Hier gibt es mehrere weiche Faktoren, die man gut bewerten kann, z.B. Reaktionsfähigkeit bei Änderungen, Abhängigkeit von fremden Unternehmen, Einhaltung von Programmierstandards, Schnittstellen zu Umsystemen usw.

Scheinbare Pflicht zur Nutzwertanalyse

Was ich schon in mehreren Projektdokumentationen gelesen habe, ist ein Satz wie dieser:

Da sich das Projekt bereits aufgrund der gezeigten wirtschaftlichen Vorteile für das Unternehmen lohnt, wird auf das Erstellen einer Nutzwertanalyse verzichtet.

Schön! Das ist aber selbstverständlich! Warum sollte ich eine bereits objektiv begründete Entscheidung (monetärer Vorteil) noch ein zweites Mal subjektiv (weiche Kriterien) begründen? Ich spare viel Geld mit dem Projekt! Diskussion beendet! Es wird umgesetzt! Dieser Satz kann eigentlich nur daher stammen, dass „im Internet“ jede zweite Projektdokumentation eine Nutzwertanalyse enthält.

Wie bereits geschildert dient eine Nutzwertanalyse nicht dem Selbstzweck, sondern soll Entscheidungen begründen, die nicht allein aufgrund harter Fakten getroffen werden können. Wenn es also nichts zu entscheiden gibt, weil der Chef die Programmiersprache vorgibt oder die Einführung des 37. Webframeworks ins Unternehmen einfach nicht sinnvoll ist, wird auch keine Nutzwertanalyse benötigt. Und erst recht nicht für die Frage, ob das Projekt überhaupt realisiert werden sollte!

Auswahl der Bewertungskriterien

Eine gute Nutzwertanalyse setzt voraus, dass die Bewertungskriterien sinnvoll ausgewählt werden und auch objektiv und nachvollziehbar bewertet werden können. Wer die Bewertung durchführt ist dabei erstmal zweitrangig und hängt vom Projekt bzw. den Alternativen ab. Vergleiche ich ein Programmierframework, sollte der Entwickler die Kriterien festlegen und die Bewertung vornehmen. Wenn es um den Vergleich zweier Softwareprodukte geht, muss der Endanwender – also z.B. der Fachbereich – die wichtigen Kriterien festlegen und Punkte vergeben. Hier folgen ein paar mögliche weiche Kriterien für beide genannten Fälle.

• Auswahl eines Frameworks oder einer Programmiersprache

  • Dokumentation
  • Stabilität des Frameworks
  • Kenntnisstand der Entwickler
  • Zukunftssicherheit/Langlebigkeit
  • Community
  • Angebotene Features
  • Verständlichkeit für andere Entwickler
  • Nötige Einarbeitungszeit
  • Übereinstimmung mit Architekturanforderungen
  • Integration in Systemumfeld
  • Angebotene Schnittstellen
  • Verfügbare Werkzeuge
  • Verfügbare Lernmaterialien

• Auswahl einer Software für den Endanwender

  • Ergonomie
  • Geschwindigkeit
  • Fehlertoleranz
  • Selbsterklärend/intuitiv bedienbar
  • Konfigurierbarkeit der Oberfläche
  • Ähnlichkeit zu bekannten Anwendungen
  • Notwendigkeit von Schulungen
  • Unterstützung von Power Usern

Aber auch die Kosten (einmalig und laufend) können ein Kriterium in der Nutzwertanalyse sein. Denn viele Entscheidungen werden eben nicht nur auf Basis der Geldes getroffen, sondern ein teureres Produkt bietet z.B. auch eine bessere Benutzerfreundlichkeit. Daher ist ggfs. genau abzuwägen, ob sich die Anschaffung eines teureren Produkts trotzdem lohnt, weil die anderen Kriterien besser umgesetzt sind.

Gewichtung der Kriterien

Eine Gewichtung der ausgewählten Kriterien ist nicht zwangsläufig nötig. Wenn alle Kriterien gleich wichtig sind, kann man darauf verzichten. Aber das wird in der Praxis selten der Fall sein. Bei der Auswahl eines Programmierframeworks werden die meisten Entwickler z.B. wahrscheinlich die Integrierbarkeit in das eigene System als wichtiger erachten als die verfügbare Dokumentation. Und der Fachbereich gewichtet bei Programmen zur Massenbearbeitung wahrscheinlich eine vorhandene Tastatursteuerung höher als eine intuitive Oberfläche.

Diese Gewichtung gilt es in einer vernünftigen Nutzwertanalyse zu berücksichtigen, um die Subjektivität bei der Entscheidung möglichst zu eliminieren. Die Gewichtung wird daher auch vor der Durchführung des eigentlichen Vergleichs festgelegt und nicht danach. Sonst ist die Gefahr groß, dass die Kriterien, in denen die Lieblingsalternative gut abschneidet, magischerweise höher gewichtet werden.

Die Gewichtung der Kriterien sollte in der Projektdokumentation begründet werden. Das ist eine wichtige Prüfungsleistung! Es muss erkennbar sein, dass die Kriterien mit Bedacht gewählt wurden – also zum gestellten Entscheidungsproblem passen – und die Gewichtung zu den gesteckten Zielen passt. Kein Prüfer kann entscheiden, wie wichtig die einzelnen Kriterien für das Unternehmen des Prüflings sind. Es ist die Aufgabe des Prüflings, das Verständnis dafür zu vermitteln.

Für die Gewichtung sollte abschließend auch eine realistische Werteskala verwendet werden. Ein Kriterium mit 1 zu gewichten und ein anderes mit 100 ist sinnfrei. Denn das mit 100 bewertete wird damit definitiv zum KO-Kriterium, das alle anderen dominiert. Sollte es KO-Kriterien geben, werden diese bereits im Vorfeld der Nutzwertanalyse dazu genutzt, die Alternativen für den Vergleich einzuschränken. Es ist sinnlos, Alternativen in der Nutzwertanalyse zu vergleichen, die ein KO-Kriterium nicht erfüllen, denn diese Alternativen können ja in der Praxis niemals eingesetzt werden.

Festlegung der Bewertungsskala für die Kriterien

Nachdem die Gewichtung der Kriterien festgelegt wurde, müssen die Alternativen nun bewertet werden. Für diese Bewertung ist eine Skala mit erlaubten Punktwerten und die möglichst exakte Begründung für die vergebene Punktzahl sehr wichtig. Es soll wieder eine subjektive Bewertung verhindert werden, sodass klare Vorgaben nötig sind, wann welche Punkte zu vergeben sind.

An der Bewertungsskala sieht man relativ schnell, ob die Nutzwertanalyse korrekt durchgeführt wurde. Häufig verwenden Prüflinge hier eine riesige Skala, z.B. von 1 bis 100. Das mag auf den ersten Blick toll aussehen, weil man sehr detailliert Unterschiede darstellen kann. Die Frage, die sich dabei stellt, ist allerdings, wer eine so genaue Unterscheidung überhaupt objektiv vornehmen kann. Denn wie kann ein Mensch, der ein Kriterium bewertet, z.B. sinnvoll begründen, warum die eine Alternative 47 Punkte und die andere 48 Punkte bekommen hat bzw. warum er der einen Alternative 37 und nicht 35 Punkte gegeben hat. Das ist nicht nachvollziehbar, sondern eine reine Bauchentscheidung. Hier wird also mit einer vorgegaukelten Objektivität eine (wahrscheinlich bereits feststehende) Entscheidung begründet.

Eine sinnvolle Skala wäre eher klein, z.B. von 1 bis 3, und definiert exakt, wann welcher Wert vergeben wird. Beispiel: Die Dokumentation einer anzuschaffenden Software wird bewertet. Hier könnte eine Skala von 1 bis 3 (mit 1 als schlechtestem und 3 als bestem Wert) bedeuten, dass bei

• 1 überhaupt keine Dokumentation vorhanden ist,
• bei 2 eine englischsprachige Dokumentation vorhanden ist
• und bei 3 eine deutschsprachige Dokumentation vorhanden ist.

Diese Werte sind unmissverständlich und ohne Interpretationsspielraum durch einen beliebigen Mitarbeiter zu bestimmen. Diese Festlegung der zu vergebenen Werte erwarte ich als Prüfer bei jeder Nutzwertanalyse in einer Projektdokumentation. Natürlich ist es ein gewisser Aufwand, für jedes Kriterium so eine Skala vorzubereiten. Aber ohne diese Vorbereitung kann man sich die Nutzwertanalyse auch sparen und sich wahllos irgendwelche „Nutzwertkoeffizienten“ ausdenken.

Wie im Beispiel zu sehen ist, muss auch unbedingt angegeben werden, welche Werte gut und welche schlecht sind. Bedeutet z.B. ein höherer Wert „mehr“ Punkte? Oder wird nach dem Schulnotenprinzip vorgegangen und kleinere Werte sind besser? Das ist nicht immer so eindeutig erkennbar. Wichtig ist dann natürlich, dass alle Bewertung einheitlich sind und nicht der eine Punkte mit kleinen Werten und der andere mit großen arbeitet. Denn dann ist eine Kumulierung der Werte nicht möglich.

Nutzenkoeffizient oder Nutzwertkoeffizient oder einfach Nutzwert

Am Ende der Nutzwertanalyse steht eine Zahl, die jeder Alternative zugeordnet ist, und anhand derer die Entscheidung gefällt wird. Für diese Zahl gibt es verschiedene Bezeichnungen, z.B. Nutzenkoeffizient, Nutzwertkoeffizient, Nutzenziffer oder einfach nur Nutzwert. Sie stellt das Endergebnis der Nutzwertanalyse dar und repräsentiert die kumulierten bewerteten Kriterien der einzelnen Alternativen.

Ja nach gewählter Werteskala kann man aus dem Nutzwertkoeffizienten direkt eine Aussage ablesen oder nicht. Wird die Skala z.B. von -1 bis 1 festgesetzt und -1 bedeutet „nicht erfüllt“, 0 steht für „neutral“ und 1 für „erfüllt“, kann ein positives Gesamtergebnis schon für sich alleine aussagekräftig sein (da die Anforderungen im Mittel eher erfüllt als nicht erfüllt werden). Werden aber nur positive Werte zugelassen, ist ein Wert größer 1 wenig aussagekräftig, da alle Koeffizienten größer 1 sein werden. Letztlich müssen alle Koeffizienten mit denen der anderen Alternativen verglichen werden, um den Gewinner zu bestimmen. Der kleinste oder größte Nutzwertkoeffizient (abhängig von der gewählten Werteskala) repräsentiert dann die beste Alternative. Häufig lese ich in Projektdokumentationen, dass aufgrund eines positiven Nutzenkoeffizienten die Entscheidung getroffen wurde. Aber wie gesagt ist das nicht ausreichend, da der einzelne Nutzwert nicht aussagekräftig ist, sondern immer ins Verhältnis zu den anderen Ergebnissen gesetzt werden muss.

Häufige Fehler bei der Nutzwertanalyse

Hier fasse ich noch einmal kurz die häufigsten Fehler bei Nutzwertanalysen im Projektdokumentationen zusammen:

• Legende fehlt: Die Kriterien werden nur als ein Wort aufgeführt, ohne zu erläutern, was damit gemeint ist. Beispiel: „Effizienz“. Was ist damit gemeint? Geht es um die Rechen- oder Speichereffizienz? Warum ist das überhaupt wichtig?
• Bewertungsskala fehlt: Welche Werte sind überhaupt erlaubt? Wann wird welcher Wert vergeben (detailliert zu jedem Kriterium beschrieben)?
• Begründung für die Gewichtung fehlt: Kriterien werden munter gewichtet, ohne zu erklären, warum sich das Unternehmen oder der Prüfling dafür entschieden hat. Warum ist die Ergonomie der Webanwendung wichtiger als die Sicherheit? Warum ist die Tastatursteuerung viermal so wichtig wie die intuitive Bedienbarkeit? Wer hat das überhaupt entschieden?
• Falsche Schlüsse aus dem Nutzwertkoeffizienten: Ein positiver Nutzwert bedeutet nicht automatisch eine gute Bewertung. Ein Koeffizient allein ist meist nicht aussagekräftig und muss mit den anderen ins Verhältnis gesetzt werden. Die Bewertung anhand absoluter Zahlen (z.B. größer 1) ist meist ebenso sinnlos.

Beispiel für eine vollständige Nutzwertanalyse

Zum Abschluss habe ich hier noch eine kleine, aber vollständige Nutzwertanalyse für die Auswahl einer Programmiersprache für die Umsetzung des Projekts als Anschauungsbeispiel.

Auswahl der Programmiersprache für das Projekt Zeiterfassung

Im Folgenden soll die bestmögliche Programmiersprache zur Umsetzung der Zeiterfassung als Webanwendung ausgewählt werden. Hierbei wurden die in Frage kommenden Sprachen aufgrund mehrerer Kriterien miteinander verglichen, die vom Entwickler bewertet wurden. Im Unternehmen wurden bislang die Sprachen Java, C#, Ruby, ABAP und VBA eingesetzt. Da in der Infrastruktur des Unternehmens Webanwendungen nicht mit ABAP und VBA umgesetzt werden können oder sollen, wurden nur Java, C# und Ruby verglichen. Als KO-Kriterium für die Auswahl der Sprache wurde vom Softwarearchitekten die statische Typisierung vorgegeben, sodass auch Ruby nicht weiter betrachtet wurde. Somit beschränkt sich der Vergleich auf die Sprachen Java und C#.

Kriterien für die Auswahl

Folgende Kriterien für die Auswahl der Programmiersprache wurden vom Softwarearchitekten des Unternehmens vorgeben:

• Langlebigkeit: Kann die Lösung auch in einigen Jahren noch angepasst und erweitert werden?
• Build-Prozess: Ist ein automatisierter Build-Prozess für die Sprache möglich oder gar schon im Unternehmen etabliert?
• Testframeworks: Gibt es für die Sprache etablierte Frameworks für Unit-, Integrations- und Oberflächentests?
• Features: Bietet die Sprache moderne Features, die ein produktives Entwickeln ermöglichen (z.B. Lambda-Ausdrücke oder Generics)?

Zusätzlich ergänzte der Autor diese Liste um die folgenden Kriterien:

• Kenntnisstand: Wurde die Sprache bereits in anderen Projekten des Autors verwendet oder muss sie neu erlernt werden?
• Entwicklungsumgebung: Sind alle nötigen Programme für die Entwicklung vorhanden und dem Autor bekannt?

Gewichtung der Kriterien

Die Gewichtungsskala für die Kriterien reicht von 1 (weniger wichtig) bis 4 (sehr wichtig). In Zusammenarbeit mit dem Softwarearchitekten wurde für das Projekt Zeiterfassung die folgende Gewichtung vorgenommen:

• 4 Kenntnisstand: Da es sich um das Abschlussprojekt des Autors mit fester Zeitvorgabe handelt, ist besonders wichtig, dass die Sprache ihm bereits bekannt ist.
• 3 Testframeworks: Dem Unternehmen sind automatisierte Tests sehr wichtig und gerade bei Neuentwicklungen sind sie Pflicht.
• 3 Build-Prozess: Für moderne Konzepte wie Continuous Deployment muss gerade im Webumfeld eine Build-Pipeline vorhanden sein.
• 2 Features: Gerade im Webumfeld setzt das Unternehmen auf neue Technologien und möchte neue Entwicklungen zeitnah einsetzen.
• 1 Entwicklungsumgebung: Die IDE kann theoretisch durch einen guten Texteditor abgelöst werden. Daher ist dieses Kriterium nicht ganz so wichtig.
• 1 Langlebigkeit: Da es sich um eine Webanwendung handelt, die wahrscheinlich häufig an neue Möglichkeiten angepasst werden muss, ist die Langlebigkeit von geringerer Wichtigkeit.

Bewertungsskala für die Kriterien

Als mögliche Werte für die genannten Kriterien werden die Zahlen 1 (schlecht) bis 3 (gut) verwendet. Im Folgenden wird festgelegt, wann welcher Wert bei den einzelnen Kriterien vergeben wird.

• Kenntnisstand
  1. Die Sprache ist dem Autor bislang völlig unbekannt.
  2. Die Sprache ist dem Autor aus der Schule oder aus Übungsprojekten bekannt.
  3. Der Autor hat die Sprache bereits mehrfach in echten Projekten verwendet.
• Testframeworks
  1. Es sind keine Testframeworks für die Sprache verfügbar.
  2. Es sind Testframeworks verfügbar, aber es werden nicht alle gewünschten Testverfahren abgedeckt.
  3. Es sind etablierte Testframeworks mit allen gewünschten Features vorhanden.
• Build-Prozess
  1. Der Build kann nicht automatisiert werden.
  2. Der Build kann mit einigem zusätzlichen Aufwand automatisiert oder zumindest teilautomatisiert werden.
  3. Ein komplett automatisierter Build inkl. Deployment ist möglich.
• Features
  1. Die Sprache bietet keine modernen Konzepte an.
  2. Die Sprache bietet einige moderne Konzepte.
  3. Die Sprache erlaubt die Arbeit mit modernsten Konzepten.
• Entwicklungsumgebung
  1. Die Entwicklungsumgebung ist dem Autor bislang unbekannt und muss neu aufgesetzt werden.
  2. Die Entwicklungsumgebung ist teilweise vorhanden und ausprobiert worden bzw. bereits im Unternehmen in anderen Projekten im Einsatz.
  3. Die Entwicklungsumgebung ist bereits vorhanden und vom Autor in echten Projekten erprobt worden.
• Langlebigkeit
  1. Die Sprache ist noch im Entwicklungsstadium und erfährt häufig nicht abwärtskompatible Änderungen.
  2. Die Sprache ist relativ stabil und führt nur selten nicht abwärtskompatible Änderungen ein.
  3. Die Sprache ist über mehrere Jahre hinweg stabil und bleibt langfristig abwärtskompatibel.

Nutzwertanalyse

Entscheidung für Java

Die Bewertung der beiden Programmiersprachen zeigt, dass Java die bessere Wahl für das Projekt Zeiterfassung ist. Insbesondere die Tatsache, dass die Sprache dem Autor bereits bekannt ist und es bereits einen etablierten Buildprozess mit automatisierten Tests im Unternehmen gibt, hat die Entscheidung deutlich zugunsten von Java ausfallen lassen. Dies zeigt der Nutzwert von insg. 43 Punkten ggü. 33 für C#. Somit wird die Zeiterfassung mit Java umgesetzt.

Meine Empfehlung

Eine Nutzwertanalyse ist ein tolles Werkzeug, um schwierige Entscheidungen zu begründen und subjektives Empfinden zu objektivieren. Aber leider wird das Verfahren von sehr vielen Prüflingen falsch angewendet oder unvollständig dokumentiert. Das muss nicht sein! Mach dir bei deinem Projekt im Vorfeld Gedanken, ob du überhaupt eine Nutzwertanalyse brauchst und halte dich an meine Tipps. Hier noch einige Daumenregeln zum Abschluss:

• Du musst in deiner Projektdokumentation die von dir getroffenen Entscheidungen begründen! Das ist ein wichtiger Bewertungspunkt für deine Note.
• Die Nutzwertanalyse ist ein sehr gutes Werkzeug und sie sollte jedem Prüfling geläufig sein.
• Die Nutzwertanalyse wird benutzt, wenn es keine harten Kriterien für eine zu treffende Entscheidung gibt.
• Die Nutzwertanalyse für das eigene Projekt ist in 99% der Fälle unnötig (weil bereits monetäre Gründe für das Projekt sprechen) oder unmöglich (weil eine fiktive Situation mit dem Ist verglichen werden soll).
• Schließe Alternativen von der Nutzwertanalyse aus, die aufgrund von KO-Kriterien gar nicht in Frage kommen.
• Erläutere die ausgewählten Kriterien. Wer hat sie aufgestellt und warum?
• Nutze eine sinnvolle Gewichtung der Kriterien und erläutere sie für Außenstehende nachvollziehbar.
• Verwende eine kleine Bewertungsskala (z.B. von 1 bis 4).
• Erkläre, was die einzelnen Werte bedeuten (z.B. 0 nicht vorhanden, 1 schlecht umgesetzt, 2 mittelmäßig umgesetzt, 3 hervorragend umgesetzt).
• Erläutere, wer die Bewertung durchführt und wie die (wichtigsten) Werte zustandekommen.
• Interpretiere den Nutzwertkoeffizienten nicht für sich allein, sondern immer im Zusammenhang mit den anderen.

Hast du noch Fragen oder Hinweise zur Nutzwertanalyse? Dann freue ich mich auf deinen Kommentar zum Artikel!

Weitere Infos zur Projektdokumentation

Du suchst noch mehr Tipps rund um die Projektdokumentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektdokumentation.

Kennst du schon meine Microsoft Word-/LibreOffice-Vorlage für die Projektdokumentation? Unter dieperfekteprojektdokumentation.de kannst du sie herunterladen.

Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektdokumentation herunterladen.

---

Jetzt anmelden!