t3n News Marketing

Unterschiede zwischen Lastenheft & Pflichtenheft

Was? Pflichtenheft und Lastenheft sind nicht dasselbe?

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

Was? Pflichtenheft und Lastenheft sind nicht dasselbe?

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

Lastenheft und Pflichtenheft: Grundlage für die Zusammenarbeit

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 unter anderem durch Nacharbeiten oder Nachbesserungen die Projektlaufzeit verdoppeln oder verdreifachen und somit andere Projekte gefährden, indem 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 klar gemacht zu haben.

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 darauffolgende Pflichtenheft bieten sowohl dem Auftraggeber, als auch dem Auftragnehmer eine Grundlage für die weitere Zusammenarbeit. Somit ist „Lastenheft“ kein Synonym für „Pflichtenheft“, aber sehen wir uns an, wo die Unterschiede liegen.

Mit Pflichtenheft und Lastenheft lassen sich auch größere Projekte stemmen. (Foto: simononly / flickr.com, Lizenz: CC-BY)

Lastenheft: Die Sicht des Auftraggebers

Der Auftraggeber beschreibt alle Anforderungen in einem Dokument. 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 (Wie 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 potentielle 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.

Pflichtenheft: Der Plan des Arbeitnehmers

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 essentiell, 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 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.

Ansonsten könnte es, wie beim vorherigen Beispiel, zu Meinungsverschiedenheiten über den Erfüllungsgrad kommen. In das Pflichtenheft gilt es, mehr Zeit zu investieren, denn sie kann bei der Durchführung und Abnahme des Gesamtvorhabens mit hoher Wahrscheinlichkeit wieder eingespart werden.

Lastenheft vs. Pflichtenheft

Die Erhebung der Anforderungen ist für Kunden meist eine nicht ganz triviale Aufgabe. Der Kunde kann bei diesem Schritt durch einen Workshop und Beratungsgespräche unterstützt werden. 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.

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.

Folgt ihr schon diesem Workflow? Oder arbeitet ihr anders?

Vielleicht auch interessant: Hier findet ihr eine Auswahl kostenloser Projektmanagement-Tools von agil bis klassisch

Newsletter

Bleibe immer up-to-date. Sichere dir deinen Wissensvorsprung!

Vorheriger Artikel Zurück zur Startseite Nächster Artikel
17 Antworten
  1. von Olaf Barheine am 27.01.2014 (10:23 Uhr)

    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 Teilen
  2. von aysberg am 27.01.2014 (10:24 Uhr)

    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 Teilen
  3. von sebs am 27.01.2014 (10:36 Uhr)

    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 Teilen
  4. von Christian Händel am 27.01.2014 (11:20 Uhr)

    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 Teilen
  5. von Michael Ulm am 27.01.2014 (11:23 Uhr)

    @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 Teilen
  6. von Pierre am 27.01.2014 (11:44 Uhr)

    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 Teilen
  7. von Joey am 27.01.2014 (11:53 Uhr)

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

    Antworten Teilen
  8. von Thomas am 27.01.2014 (12:00 Uhr)

    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 Teilen
  9. von Joey am 27.01.2014 (12:04 Uhr)

    @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 Teilen
  10. von Mara am 27.01.2014 (12:11 Uhr)

    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 Teilen
  11. von Thorsten am 27.01.2014 (15:07 Uhr)

    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 Teilen
  12. von sebs am 27.01.2014 (16:39 Uhr)

    @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 Teilen
  13. von Karsten am 27.01.2014 (16:51 Uhr)

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

    Antworten Teilen
  14. von Stephan Jäckel am 27.01.2014 (17:13 Uhr)

    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 Teilen
  15. von Christoph am 28.01.2014 (11:57 Uhr)

    @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 Teilen
  16. von Diercks am 30.01.2014 (08:59 Uhr)

    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 Teilen
  17. von HZprojektmensch am 19.08.2014 (13:06 Uhr)

    Kompakt zusammengefasst. Dankeschön!

    Antworten Teilen
Deine Meinung

Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Mehr zum Thema
„Was für eine Scheißidee!“ Wie ihr am besten mit schlechten Vorschlägen umgeht
„Was für eine Scheißidee!“ Wie ihr am besten mit schlechten Vorschlägen umgeht

Nicht jede Idee ist gut. Manche sind sogar wirklich schlecht. Allerdings bedarf es Fingerspitzengefühl, um mit schlechten Vorschlägen umzugehen. Wir verraten euch, wie ihr schlechte Ideen … » weiterlesen

Wann, wo, wer, was? Das wahre Businessmodell von Uber
Wann, wo, wer, was? Das wahre Businessmodell von Uber

Uber ist Milliarden wert, dabei tut das Unternehmen eigentlich nichts Besonderes. Doch was hat es auf sich mit dem Geschäftsmodell des Startups? Wir haben es unter die Lupe genommen. » weiterlesen

Ostdeutschland als Gründer-Region? Doch, da geht was! [Startup-News]
Ostdeutschland als Gründer-Region? Doch, da geht was! [Startup-News]

Auch heute bringen wir euch wieder auf Stand – mit vier Artikeln unter anderem zur Privatinsolvenz von Gründern und Ostdeutschland als Gründer-Region. » weiterlesen

Alle Hefte Jetzt abonnieren – für nur 35 €

Kennst Du schon unser t3n Magazin?