Anzeige
Anzeige
Ratgeber
Artikel merken

Was? Lasten- und Pflichtenheft sind nicht dasselbe?

Jeder Unternehmer hat es schon mal erlebt: Kunden äußern ihre Wünsche und sind sich selbst noch nicht im Klaren darüber, was sie eigentlich genau wollen. In diesem Artikel lest ihr, warum ihr ein Pflichtenheft und ein Lastenheft benötigt.

Von Michael Ulm
4 Min. Lesezeit
Anzeige
Anzeige

Fry ist sich auch nicht sicher. (Montage: t3n.de)

Lastenheft und Pflichtenheft: Grundlage für die Zusammenarbeit

Sie sind ein wichtiger Teil der Auftragsvergabe und Verhandlung mit Kunden: Im Lastenheft und im Pflichtenheft wird festgehalten, worin der Kundenwunsch und der Auftrag im Detail besteht.

Anzeige
Anzeige

Obwohl Kundenwünsche meistens sehr umfangreich sind, werden sie im ersten Kontakt nur verbal geäußert. Dieser Austausch von Anforderungen kann bei falscher Vorgehensweise fatal enden. So kann sich zum Beispiel durch Nacharbeiten oder Nachbesserungen die Projektlaufzeit verdoppeln oder verdreifachen und somit andere Projekte gefährden, weil wichtige Personalressourcen bei anderen Projekten nicht zum Einsatz kommen können.

Stellen wir uns dieses Szenario am Beispiel einer Pkw-Bestellung vor: Der Kunde beschreibt einen Wagen mit allen gewünschten Extras. Der Unternehmer hinterfragt im ersten Gespräch die geäußerten Wünsche und in seiner Vorstellung entsteht das Bild eines Kombis. Der Auftragnehmer „baut“ dieses Auto und liefert es dem Auftraggeber. Der hat sich jedoch eine Limousine erhofft und ist fest der Meinung, diesen Wunsch dem Auftragnehmer auch deutlich klargemacht zu haben.

Anzeige
Anzeige

Selbstverständlich gäbe es noch viele weitere Beispiele mit ähnlicher Problematik. Gemeinsam haben sie jedoch alle die Möglichkeit, durch relativ simple Instrumente des Software-Engineerings solchen Missverständnissen vorzubeugen. Das Lastenheft und das darauf aufbauende Pflichtenheft bieten sowohl dem Auftraggeber als auch dem Auftragnehmer eine Grundlage für die weitere Zusammenarbeit. Sie sollten formuliert werden, bevor der Vertrag über den Auftrag abgeschlossen wird. Dabei ist Lastenheft kein Synonym für Pflichtenheft. Sehen wir uns an, wo die Unterschiede liegen.

Anzeige
Anzeige

Lastenheft: Die Sicht des Auftraggebers

Der Auftraggeber beschreibt alle Anforderungen in einem Dokument. Dieses Lastenheft heißt manchmal auch Anforderungskatalog, Produktskizze oder Kundenspezifikation. Dabei wird der Auftraggeber zum ersten Mal selbst mit der Aufgabe konfrontiert, sich umfangreiche Gedanken zum Gesamtvorhaben zu machen. Durch ein strukturiertes Dokument entsteht somit ein Anforderungskatalog. Inhaltlich sollte das Lastenheft zumindest folgende Punkte umfassen:

  • Aktueller Ist-Zustand: Worauf soll das Gesamtvorhaben aufsetzen und welche Voraussetzungen sind schon gegeben?
  • Gewünschter Soll-Zustand: beschreibt somit die Zielsetzungen des Gesamtvorhabens. Was soll das Produkt nach Fertigstellung beinhalten?
  • Definition von Zuständigkeiten und Schnittstellen: Wer ist in dem Projekt für welche Bereiche zuständig und wo treffen diese Zuständigkeiten aufeinander?
  • Funktionalen Anforderungen: Was soll das Produkt funktional beherrschen (zum Beispiel eine Benutzeranmeldung)?
  • Nicht-funktionale Anforderungen: zum Beispiel Zuverlässigkeit, Wartbarkeit, Benutzbarkeit und so weiter.

Ein Lastenheft erleichtert es dem Auftraggeber, vergleichbare Angebote verschiedener Anbieter einzuholen, da jeder potenzielle Auftragnehmer dieselbe Grundlage für ein Angebot vorliegen hat. Bei verbalen Formulierungen direkt beim Auftragnehmer entstehen unterschiedliche Dialoge und Ergebnisse. Vielleicht hat der eine Anbieter eine andere Frage gestellt, vielleicht wurden auch verschiedene Antworten bei den einzelnen Anbietern geliefert. Mithilfe eines Lastenhefts bleibt die Informationsgrundlage stets dieselbe.

Anzeige
Anzeige

Es ist nicht zwingend nötig, dass der Auftraggeber das Lastenheft ganz auf sich gestellt formuliert. Oft können potenzielle Auftragnehmer schon in dieser Phase mit ihrer Expertise helfen und gemeinsam mit dem Kunden herausfinden, was er eigentlich braucht. Ist diese Tätigkeit umfangreicher, ist es angebracht, ein Beratungshonorar in Rechnung zu stellen.

Pflichtenheft: Der Plan des Auftragnehmers

Dem Auftragnehmer ist es nun dank Lastenheft möglich, ein Pflichtenheft zu erstellen. Das Pflichtenheft beschreibt, wie und womit der Auftragnehmer das Gesamtvorhaben umsetzen wird. Es stellt – oft auch in Kombination mit einem Angebot – die vertragliche Grundlage der zu erfüllenden Leistungen dar. Daher ist es essenziell, eine gründliche Ausformulierung von Zielen und auch Nicht-Zielen durchzuführen.

Positive Abgrenzungen (Ziele), also die Frage, was das Produkt können wird, stehen hier negativen Abgrenzungen (Nicht-Zielen) gegenüber, also der Frage, was das Projekt nicht können wird. Beide sind gleichermaßen wichtig für die Erfüllung der Leistungen. Nur durch die Formulierung beider Aspekte ist es möglich, eine klare Aussage über die Erfüllung der Leistungen zu treffen und eine spätere Produktabnahme diskussionsfrei durchzuführen.

Anzeige
Anzeige

Ansonsten könnte es – wie bei unserem Pkw-Beispiel – zu Meinungsverschiedenheiten über den Erfüllungsgrad kommen. Es ist empfehlenswert, in das Pflichtenheft etwas mehr Zeit zu investieren, denn sie kann bei der Durchführung und Abnahme des Gesamtvorhabens mit hoher Wahrscheinlichkeit wieder eingespart werden.

Auch eine Detaillierung des Abnahmeprozesses, das Qualitätsmanagement und der Umfang möglicher Nacharbeiten sollte im Pflichtenheft enthalten sein. So können sich beide Seiten das vereinbarte Procedere im Blick behalten und sich bei Unregelmäßigkeiten darauf berufen.

Lastenheft vs. Pflichtenheft

In der Praxis ist die Grenze zwischen Lastenheft und Pflichtenheft meist als fließender Übergang zwischen den beiden Dokumenten zu sehen. Jedenfalls gilt es, genügend Zeit in die sorgfältige Erstellung eines Pflichtenhefts zu investieren, da im Normalfall einerseits die komplette Projektdurchführung mit vordefinierten Zielen gut vorangetrieben und andererseits zu Projektende die Projektabnahme deutlich unterstützt wird.

Anzeige
Anzeige

Nun liegt es an dir! Lastenheft, Pflichtenheft und Angebot. Diese Reihenfolge und zwischendurch das eine oder andere Gespräch zur Abklärung solltest du dir für zukünftige Projekte verinnerlichen.

Das könnte dich auch interessieren:

Dieser Artikel wurde zuletzt am 7. August 2019 von Anton Weste aktualisiert.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
21 Kommentare
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Olaf Barheine

Soweit die Theorie. In der Praxis liegt leider, wenn der Kunde auf mich zukommt, noch gar kein Lastenheft vor. Ich stelle ihm dann ein Produktmuster für ein Lastenheft zur Verfügung, damit er weiß, was ich von ihm brauche. Dabei kommt dann meistens etwas Lastenheftähnliches heraus. Parallel arbeite ich am Pflichtenheft, in das schon erste grobe Designaspekte der zu entwickelnden Software einfließen. Das evaluiert der Kunde und macht seine Änderungswünsche und Ergänzungen. Wenn ich immer erst warten würde, bis der Kunde das Lastenheft fertiggestellt hat, hätte ich einen erheblichen Leerlauf. Und Zeit ist schließlich Geld.

Antworten
aysberg

Ach, das klingt doch so schön einfach – ok, zwischen den Zeilen schreibt Ihr, dass es „nicht ganz trivial“ sei.

Dabei ist das für einen Dienstleister (Internetagentur, Webdesigner) das schwierigste, dem Unternehmer das Lastenheft herauszukitzeln. Oft gibt es leider gar nix in der Richtung – dann zieht man dem Unternehmer in einem oder mehreren Vorgesprächen alles aus der Nase – oder es gibt ein Dokument in dem steht, wie viele HTML-Seiten der neue Auftritt haben wird..

Schwierig wird es aber nicht nur dann, wenn statt der Limousine der Kombi als Ergebnis rauskommt. Pflichten- und Lastenheft sind auch die Basis für die Kalkulation. Und da kann man auch gewaltig auseinander liegen…

Antworten
Sebastian

Sind wir im Jahr 1998? Da gehört der Artikel nämlich irgendwie hin.
In der immer steigenden Anzahl an wirklich agilen Projekten, wo auch immer neue Anforderungen oder Änderungen auftreten können und dies aber auch akzeptiert wird, ist das Prinzip des „totalen“ Lasten-/Pflichtenheft total daneben.
Oder will man neue Anforderungen oder Änderungen ins Lastenheft einpflegen und dann einfach hoffen dass es auch in Pflichtenheft wandert und diese nicht einfach abgelehnt werden?

Wer heute noch so arbeitet oder arbeiten kann, der muss den Staat oder ehemalige Staatsunternehmen als Kunden haben.

Natürlich müssen auch in agilen Projekten vertragliche Gegebenheiten vereinbart werden, und natürlich wird dort auch von einem System gesprochen das am Ende gewisse Aufgaben lösen muss, aber viel mehr muss der Kunde „ständig“ in Kontakt mit dem umsetzenden Unternehmen sein.
Denn was man aus 30 Jahren Projektumsetzung weiß, ist dass der Kunde sein System nie im Ganzen von vornherein planen kann. Egal wie gut etwaige Workshops sind. Er muss Teile des Systems arbeiten sehen um die nächsten Anforderungen auch gut zu beschreiben.

Es kommt daher am Anfang eher ein abgeschwächtes Lastenheft bei raus, das nur manche Keyfeatures genau beschreibt und die gewisse äußere Umstände, wie einzusetzende Technologien (das ist leider zu häufig der Fall) festlegt.

Antworten
Christian Händel

Erstmal ein Danke an den Autor. Ich persönlich finde es wichtig dass es solche Artikel gibt. Und damit bin ich auch gleich bei @sebs Kommentar.
Dieser Artikel gehört zwar auch in das Jahr 1998 aber gerade heute ist es wichtig, sich an dieses Prinzip zu erinnern. Was nämlich das ganze agile Projektmanagement momentan sehr fördert, ist die Einstellung, ach wir fangen doch einfach mal an. Und am Ende stellt sich heraus, dass ein bisschen Plan zu haben doch gar nicht schlecht gewesen wäre. Deshalb gibt es Workshops und ähnliches um den Unternehmen zu helfen, selbst zu erkennen, was Ihre Aufgabe ist und was Aufgabe der Agentur ist. Das abgeschwächte Lastenheft ist eine Praxis, die mir persönlich immer wieder mehr sauer aufstößt und vielen Agenturen immer wieder den so gehassten Rechtsstreit beschert. Mag agiles Projektmanagement noch so schön sein, so ist es noch nicht mal bei mehr als der Hälfte aller Agenturen angekommen, wie sollen denn da schon der Großteil aller Kunden so agieren. Die Arbeit mit Lasten- und Pflichtenheft, hat meines Erachtens nach völlig seine Daseinsberechtigung ich finde es gut, dass die Unterschiede hier so klar auch beleuchtet werden.

Antworten

@Olaf: ja Theorie und Praxis ist manchmal schon etwas weit voneinander entfernt, jedoch finde ich es wichtig zu versuchen den Kunden auf bestimmte Punkte in der Software Entwicklung aufmerksam zu machen und damit theoretisch gute Ansätze in der Praxis zu verwirklichen. Da gehört einmal auch dazu, dass sich der Kunde selbst mit seinen Wunschvorstellungen detaillierter auseinandersetzt. Damit bekommt der Kunde dann auch ein besseres Gefühl für die Wertigkeit der Arbeit, die wir als Softwareentwickler leisten.

Wir haben uns im Unternehmen auch schon öfters damit beschäftigt und stehen meist vor ähnlichen Problemen, wie du sie auch beschreibst. Meiner Meinung nach sind aber jene Projekte, die wirklich gut beschrieben wurden, durch Lastenheft und Pflichtenheft, auch die Projekte, die reibungsloser ablaufen.

@sebs: Danke dass du auf die Agilen Entwicklungsmethoden eingehst. Doch du schreibst am Schluss auch, dass hierbei ein abgeschwächtes Lastenheft herauskommt. Durch die Schnelllebigkeit in der IT ist es wirklich oftmals schwer bestimmte Punkte einzuschätzen, ebenso bei längerfristigen Projekten können sich Anforderungen ändern. Da gebe ich dir Recht.

In welchem Detailgrad alles erfolgt, liegt natürlich beim Unternehmen selbst. Meine Empfehlung ist hierbei trotzdem etwas mehr Zeit in die Projektplanung mittels Lastenheft und Pflichtenheft zu investieren, um zu einem späteren Zeitpunkt eine Ausgangssituation mit klar vereinbarten Zielen zu besitzen.

Im Projektmanagement z.B. wird auch laufend auf Projektänderungen eingegangen und mitdokumentiert wie sich welche Elemente der Projektplanung verändert haben. So wird ja auch schließlich zur Projektabrechnung bei agilen Projekten die Entscheidungen und Wünsche der Kunden mitdokumentiert. Das könnte doch auch durch Adaptierung des Pflichtenhefts erfolgen oder durch Anhänge zum Pflichtenheft.

Gerne kann ich in weiterer Folge auf die agile Entwicklung eingehen. Das wäre ein gutes Thema für einen weiterführenden Artikel.

Antworten
Pierre

Man kann den Kunden nicht mit dem Lastenheft alleine lassen!!
Das ist ein großer Fehler. Ich lese hier in den Kommentaren: Ich bekommen oft kein ordentliches Lastenheft o.ä.. Natürlich musst du es mit dem Kunden Erarbeiten. Und man muss vor allem (m.E. der häufigste Fehler) Anforderungen aus NUTZERSICHT schreiben und verhindern, dass man technisch wird. Denn genau dann verliert das Lastenheft seinen Sinn. Das Lastenheft muss für beide Seiten 100% verständlich sein. Es ist de facto ein Tool, um eine gemeinsames Verständnis für die Anforderungen zu bekommen. Ich habe aber schon X Lasterhafte in der Hand gehabt, die eigentlich teilweise Pflichtenhefte waren. Das kommt davon wenn man bei Meeting-Einladungen immer schön „Workshop“ schreibt, es aber ein unstrukturiertes bla bla ist. Es fehlt sehr häufig Kompetenz im Bezug auf Methoden, um Anforderungen z.B. in Workshops zu erarbeiten. Immer noch eine SEHR große Baustelle bei Agenturen.

Antworten
Joey

Kleine Korrektur in der Zwischenüberschrift: Der Plan des Arbeitnehmers => Der Plan des Auftragnehmers

Antworten
Thomas

Zur Formulierung der Anforderungen an eine Software finde ich User Stories (http://de.wikipedia.org/wiki/User_Story) extrem hilfreich. Der Kunde bleibt „in seiner Sprache“ und ich kann daraus die Anforderungen dieser für mich definieren.

Antworten
Joey

@sebs: Lasten-/ und Pflichtenheft sind auch in Zeiten der „agilen“ Entwicklung insbesondere bei größeren Projekten immer noch wichtig. Die Kunst liegt darin, das Projekt in entsprechende Teilabschnitte zu zerlegen, bei denen der Kunde z.B. genau das kann, was Du beschreibst: Das System schon mal arbeiten sehen. Bis zu diesem Punkt gibt es aber genauso konkrete Lasten/Pflichten und in den folgenden Schritten ebenso.

Es ist daher wichtig immer alle Anforderungen und eventuelle Änderungen daran in schriftlicher Form zu fixieren (Lastenheft), damit die Entwickler daraus die entsprechende Arbeitsschritte ableiten können (Pflichtenheft), die dann vom Kunden abgenickt werden.

Kunden, die das ab einer bestimmten Projektgröße immer noch ablehnen, schicken wir gern zur Konkurrenz, weil die uns oft entweder Geld gekostet haben oder von vornherein kein ausreichendes Budget hatten ;-)

Antworten
Mara

Guten Morgen!
Aus Auftraggebersicht kann ich sagen, dass ich außerordentlich dankbar gewesen wäre, wenn wir bei Erstellung unserer neuen HP gezwungen worden wären, uns mal schriftlich Gedanken zu machen. Das hätte eine Menge Missverständnisse vermieden. Denn branchenfremd kann man manchmal gar nicht erkennen, welchen Empfängerhorizont der Gesprächspartner hat, merkt also gar nicht, dass man aneinander vorbeiredet. Und der Vorteil von Zettel und Stift in der Hand ist doch, dass man sich tatsächlich auch mal zwischen den amorph durch den Geist wabernden Ideen und Vorstellungen – manchmal sogar mehrerer Beteiligter- entscheiden muss. Das ist heute noch genauso wie 1998. Als Auftraggeber muss man sich natürlich bewußt sein, dass so ein Lastenheft tatsächlich eine Last sein kann-auch für den Geschäftspartner, wenn man nicht schnell genug damit überkommt.

Antworten
Thorsten

Ist es nicht oft so, dass manche Unternehmen bewusst auf Pflichtenheft & Co. verzichten um den Kunden nicht die wirklichen Kosten mitteilen zu müssen?
Bezahlt wird nach Arbeitszeit. Erlebe ich zumindest sehr oft, da so Kunden geködert werden. Das Betrifft jetzt nur Kunden die nicht aus der selben Branche kommen.

Antworten
Sebastian

@Mara
Auch wenn ihr als Auftraggebersicht gezwungen gewesen wert etwas schriftlich zu formulieren, dann hätte es nämlich genauso geendet, wie es wohl auch zur Zeit bei euch aussieht.

Ein Kunde kommt in der Regel nur mit einer Idee, die ganz abstrakt ist, und sich dann auch noch in der jeweiligen fachlichen Domäne befindet.
Ein Lastenheft hilft da ohne notwendige fachliche Betreuung, aber auch technische Betreuung nichts. Denn oft ist es so, dass der IT-Leiter des Auftraggebers für das Lastenheft und die Kommunikation mit dem Auftragnehmer verantwortlich ist, aber nicht alle fachlichen Aspekte kennt und beschreiben kann.
Das (fehlerhafte) Lastenheft wird dann technisch auch häufig perfekt umgesetzt, wobei die entstandene Lösung dann häufig nicht den fachlichen Anforderungen entspricht.
Hier setzen aber auch schon guten Auftragnehmer an und bieten einfach nur sehr gute fortlaufende Beratung an und tun dies auch ohne Hinblick auf eine Umsetzung. Und wenn die Beratung und Umsetzung von einem Unternehmen geschieht, dann sollten diese Bereiche möglichst sehr getrennt ablaufen.
Einfache Workshops helfen da nicht, da die Erhebung von Anforderungen ein laufender Prozess ist, wo Teile des Auftraggebers (Stakeholder) an unterschiedlichen Punkten in einem unterschiedlichen Umfang und

Es werden aber bei der Pflichten-/Lastenheft-Lösungen einfach noch immer viel zu wenig die fachlichen Anforderungen bedarfsgerecht umgesetzt.
Und wenn ich die Kritik von @Christian mal aufnehmen, wird in einem bestimmten Rahmen mit vorher definierten Aufgaben auch einfach mal angefangen, weil es das beste ist. Besonders bei Neuentwicklungen.
Aber dass dies in einem unbestimmten Rahmen abläuft, sollte nicht der Fall sein. Eher sollte der Kunde die Möglichkeit haben zu jedem Zeitpunkt, und nicht nur nach Abschnitten (Sprints usw.) Änderungswünsche direkt mitzuteilen, die dann entweder direkt umgesetzt werden können, oder zu einer späteren Aufgabe formuliert werden.
Dies sorgt einfach dafür, dass keine unnötigen und fachlich falschen Module erzeugt werden und die Entwickler mit in die fachliche Domäne eingebunden werden.
So entsteht überhaupt erst ein System was für sich zu jedem Zeitpunkt möglichst einen Teil der Anforderung sehr gut erfüllt.

Bei Pflichten-/Lastenheft-Lösungen kommt es bei den vertraglich vereinbarten Zwischenabnahmen oft erst zum großen Knall zwischen den Vertragspartnern, weil das System vorne und hinten nicht zusammenpasst. Die „Lücken“ im Lasten und Pflichtenheft, die immer vorhanden sind, wurde auf beiden Seiten so interpretiert wie es gerade passt, anstatt den Gegenpart zu fragen.
Und wer kennt es nämlich als Entwickler nicht, dass kurz vor einem Abgabetermin sich noch mal die Arbeit staut und dadurch die Qualität es Systems leidet.
Sollte nicht lieber gute Software rauskommen, anstatt schlechte zu einem festen Termin?

Daher plädiere ich immer dafür das es nur eine Projekt-Dokumentation gibt, wo beide Vertragsnehmer mit und dran arbeiten, um Geheimnisse zu verhindern. Dann wissen wirklich alle was der Stand der Dinge ist.
Und wenn von einer Seite die Erwartungen nicht erfüllt werden können, was man mit der agilen Lösung auf beiden Seiten relativ schnell entdeckt, können und müssen proaktiv Lösungen gefunden werden. Die Faktoren Zeit und Geld können häufig dadurch verändert werden, das bestimmte Module mit einem geringeren Funktionsumfang umgesetzt werden, anstatt wie bei einer Pflichten-/Lastenheft-Lösungen, die letzten Anforderungen komplett unter den Tisch fallen und somit die Software meist komplett unbrauchbar ist.

Ich habe dazu persönlich noch nie ein System erlebt, was 100%ig den Vorstellungen des Kunden entsprach oder auch noch nie ein System gesehen bei dem der Auftragnehmer nicht ein wenig von dem anfänglichen Budget, auch auf seine Kosten, abweichen musste.
Daher vergesst doch einfach mal dass eine Software mängelfrei sein kann und versucht einfach das bestmögliche System für den Kunden zu entwickeln und öffnet euch auch dem Kunden gegenüber. Aber eine Pflichten-/Lastenheft-Lösung ist da der falsche Weg.

Antworten
Karsten

Ich habe die beiden in meiner Abschlussprüfung vertauscht :(

Antworten
Stephan Jäckel

Ein schönes Plädoyer für das Nachdenken, das überlegte Handeln. Für mich als Unternehmensberater zwischen unternehmerischer Seite und IT-Seite steht in meiner Arbeit immer noch das gute alte Fach- und Orgakonzept vorne an. Nicht weil ich mit über 40 zum nicht-agilen Altmetall gehöre, sondern weil nicht eineindeutig formulierte Ziele aus unausgesprochenen Umständen heraus nicht erreichbar sind.

Es ist erschreckenderweise meist so, dass Fachabteilungen in Unternehmen kein klares Zielbild haben. Ohne dieses wird jeder IT-Auftrag zu einer Art Suizid-Kommando, denn wie soll eine Dienstleistung erbracht werden, wenn der Kunde Null Ahnung hat von dem wo er steht und wo er hin will? Lastenheft und dann Pflichtenheft sind in der IT (betriebsintern oder für Dienstleister) die notwendigen Rettungsanker geworden, die verhindern sollen, dass man am Ende immer der Schuldige ist (was ohnehin aber immer vorprogrammiert zu sein scheint).

Der Fehler liegt m.E. daran, in der BWL viel zu spät auf umfassendes IT-Verständnis in Studium und Fachhochschulstudium gelegt zu haben. In Zeiten von Big Data und Multikanal sitzt man „Marketingspezialisten“ gegenüber, deren größte Fähigkeit eisiges Schweigen ist, wenn es um IT-Fragen geht. Der Vertrieb kann einem ja meist noch sagen, was nicht funktioniert und er gerne alles so hätte. Aber man wird nie ganz den Eindruck los, alle würden viel lieber mit der Werbefirma zusammen sitzen und Bilder für Prospekte oder Webseiten aussuchen.

Dass zu all diesem Irrsinn dann noch die Modeerscheinungen der IT mit immer kürzeren Marketing-Zyklen im Markt für Consumer-IT hinzukamen, musste ins Chaos stürzen. BYOD und schon dürfte die IT jedem Vorstand sein eigenes API stricken und die Top-Verkäufer bekamen Sonderlösungen für ihren neuesten Tablet geschrieben, um beim Kunden gut auszusehen. Kosten statt Nachdenken? Bei dem Ansatz werde sogar ich zum Erbenzähler!

Und die Lösung soll es dann sein zu schaffen, was mit den genehmigten Budgets möglich ist und dann zu warten bis neue Budgets oder neue Sonderwünsche nachkommen? Das ist dann wie beim BER- Flughafen: Ständig hat wer was und will was und am Ende ist das Projekt fertig – ausgenommen die 30.000 substantiellen Nachbesserungsarbeiten, die auf einem neuen Budget noch zu erledigen sind, bevor man in den Regelbetrieb gehen kann.

Nein! Wer irgendwo hin will, sollte wissen wo er / sie steht, wo man am Ende angekommen sein will. Und ja, die Anforderung fachlicherseits an Führungskräfte ist es zu wissen wie sie dahin kommen wollen, bzw. auf welcher Gesamtreise diese Reiseetappe liegt und dabei die einfache Befähigung zu abstraktem Denken sowie zu Denken in Prozessen, Systemen und Szenarien an den Tag zu legen. Neudeutsch nennt sich das heute Leadership!

Ohne ein fachliches Grundlagenpapier ist jedes IT-Projekt zur Verbesserung oder Erneuerung wie ein Jonglierakt mit Fleischermesser, Bowlingkugel und einem rohen Ei. Es kann gut gehen, aber die Chancen hierfür, sind weder für den Jongleur noch die Objekte wirklich gut, insbesondere, wenn es sich nicht um Alltagsgeschäft handelt, welches erfahrene Hasen abwickeln, die schon „jeden“ Murks gesehen haben und wissen, dass es bei Weitem noch nicht alles war, was das Leben zu bieten hat.

Zur Überraschung der meisten IT-Leute ändert sich an den grundlegenden Gedanken der BWL, an den Geschäftsmodellen von Unternehmen und den Kernprozessen von Betriebseinheiten relativ selten etwas. Die muss man nicht in monatliche Releases packen, die per Definition unvollständig sind, sondern nur ein „Was-gerade-aus dem-wünsch-Dir-was-Reigen-budgetiert-um-umsetzbar-war“ darstellen und wo sich schlimmstenfalls die Endanwender aus dem Non-IT-Umfeld die Kugel geben, wenn sich allenthalben etwas ändert und sie nie etwas zum Anwenden haben, was dem natürlichen menschlichen Bedürfnis nach Konstanz und Beständigkeit entspricht, der Grundvoraussetzung für betriebliche Übung und damit für Qualität gegenüber dem Kunden.

Und da sind wir dann am anderen Ende der Skala: Haben wir als Gesellschaft in den 1980ern und 1990ern zu IT-ferne BWL-Absolventen produziert, so stehen wir nun einer „Generation IT“ gegenüber, für die Unternehmen nur aus Budget und Kosten bestehen, nicht aber aus den langlebigen Faktoren die einen Betrieb als sozio-technisches System, bzw. als System-aus-Systemen ausmachen. Das können sich beide Seiten jetzt die nächsten 20 Jahre lang gegenseitig um die Ohren hauen. Oder sie können sich Michelangelo (nicht den Turtle) zum Vorbild nehmen und erkennen, dass man mehr Energie braucht, um Fehler und Irrtümer zu kaschieren (oder Upgrades und Patches zu fahren), als wenn man von Anfang an die Dinge richtig macht.

Und richtig heißt aus meiner Sicht: Wissen wovon man redet, indem man für alle transparent schriftlich in einem Konzept darstellt wo man steht, wo man am Ende (der Etappe) stehen will sowie was dabei nicht eintreten darf, was eintreten soll und was gerne eintreten kann. Und wenn dann noch zu dem Etappenziel parallel immer der Gesamtzusammenhang aufgezeigt wird, in dem sich auch jede noch so kleine Arbeit bewegt, dann ist die Grundlage für offenherzige Kommunikation geschaffen, jene Kommunikation, die unverzichtbar für jeden Erfolg ist, weil sie völlig unformalisiert die Arbeit eines jeden Beschäftigten in einem Projekt besser werden lässt.

Und erst dann sind m.E. Projekte wirklich agil, weil Dank Transparenz niemand mehr einen toten Winkel in seiner Betrachtung der (Gesamt)Lage hat und der gesamte Handlungsraum offen für alle daliegt, offen ihn gemeinsam, kreativ und talentiert zu nutzen!

Antworten
Christoph

@Thorsten: Du schreibst: „… bezahlt wird nach Arbeitszeit“. Aber ist etwas schlecht daran? Natürlich möchte der Auftraggeber Kostensicherheit. Aber das fairste für beide Seiten ist trotzdem nach Aufwand abzurechnen. Schließlich war der Aufwand ja auch da. Es ist nämlich unmöglich bei größeren Projekten vorab einen Pauschalpreis nennen zu können. Man muss ein bisschen Flexibilität beim Preis zulassen haben, sonst hat man am Projektende 50 Mehr-Stunden beim Projekt, ohne das diese bezahlt werden. Das kann in richtig großen Projekten fatal enden.

Antworten
Diercks

Herzlichen Dank für den Artikel und die Diskussion hier in den Kommentaren dazu. Beides inspirierte mich nämlich dazu, dass Thema auf dem Social Media Recht Blog unter rechtlichen Aspekten einmal aufzunehmen. Der Blogpost trägt den Titel „Von Lastenheften, Pflichtenheften und was das gerade bei agilen Projekten mit Verträgen zu tun hat“ und ist hier http://www.socialmediarecht.de/2014/01/29/von-lastenheften-pflichtenheften-und-was-das-gerade-bei-agilen-projekten-mit-vertraegen-zu-tun-hat/ zu finden.

Meinungen sind auch dort (oder hier dazu) herzlich willkommen!

Antworten
Holger Zimmermann

Kompakt zusammengefasst. Dankeschön!

Antworten
Strätz

Lastenheft, Pflichtenheft > Angebot

Disese Vorgehen macht bei individualentwicklung den Aufwand sowohl für den Auftraggeber wie auch den Auftragnehmer transparent.

Festpreisangebote in der Projektarbeit sind Meisterwerke. Mit einem % Risikozuschlag aber zu realisieren :-)

Antworten
YUHIRO.DE

Sehr spannend geschrieben.

In den meisten IT Projekten sieht es immer noch so aus, dass die Programmierungen ohne grosse Planung gestartet werden.

Auch weil der IT Dienstleister weiss, dass der Kunde kein wirkliches Interesse hat lange auf die ersten Ergebnisse zu warten.

Und „Ergebnis“ wird gleich auch mal mit einem funktionierenden Teil Code gleichgesetzt.

Aber wie in Eurem Beitrag auch beschrieben. Sollte eine genaue Beschreibung fehlen, dann werden besonders bei Nicht-IT’lern (Kunde) und IT’lern (Dienstleister) meistens unterschiedliche Auffassungen zum Projektumfang entstehen.

Hier auch ein paar weitere Informationen zu den Unterschieden: http://www.yuhiro.de/lastenheft-und-pflichtenheft-was-ist-der-unterschied/

Meiner Meinung nach, kann auch der Kunde mitwirken, wenn es darum geht das Pflichtenheft zu erstellen. Natürlich mit der Moderation des Dienstleisters, ansonsten können auch Anforderungen in das Dokument, die so gar nicht umsetzbar sind.

Auch macht es eventuell auch mehr Sinn, solche elaboraten Dokumente niederzuschreiben, wenn die Projekte eher komplex sind.

Danke nochmals für Eure tollen Informationen.

Antworten
Sammy Zimmermanns

Ich habe hier eine sehr schöne Erklärung zum Thema Lastenheft vs. Pflichtenheft gefunden.
https://www.dreher-consulting.com/lastenheft-versus-pflichtenheft/

Antworten
Titus von Unhold

„Definition von Zuständigkeiten und Schnittstellen: Wer ist in dem Projekt für welche Bereiche zuständig und wo treffen diese Zuständigkeiten aufeinander?“

Nein, Projektanforderungen gehören grundsätzlich nicht in ein Lastenheft.

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Anzeige
Anzeige