Projektmanagement: Lastenheft, Pflichtenheft, Statusreport etc.

[Bruce Willis]

Hallo,

wer hat eine echt coole und moderne Vorlage fürs Lastenheft? 
Oder für andere PM-Doks?

Als Word, Excel o.ä.?

Gruß
Leo

[animate]

Vorlagen vom V-Modell XT
Sollten auch verwendbar sein, wenn du nicht nach V-Modell gehst.

[flaite]

Der Link, den Thomas geschickt hat interessant. Imho wird dann aber einen Haufen von Dokumentation erzeugt, der a) nicht gebraucht wird und b) eine Menge Arbeit erzeugt, um ihn im Verlauf des Projektes mit der Realität zu synchronisieren.

Ich halte das nämlich für unprofessionell.
- Es widerspricht dem Mainstream der betriebswirtschaftlichen Organisationsforschung der letzten 30 Jahre.
- Es widerspricht der Forschung bzgl. der Wahrnehmung komplexer Systeme der letzten 20 Jahre.
- Es widerspricht dem Mainstream der Management-Literatur der letzten 30 Jahre.

Meine Erfahrung:
Kunden können meistens in 1) gar nicht wissen, was sie genau wollen. Sie vergessen die Hälfte. Sie überbetonen Dinge, die gar nicht wichtig ist. Nach meinen Menschenbild ist das auch nur natürlich.
Es wird in 1) und 2) viel zu viel Papier produziert. Und jeder wird angenervt, dass er das alles lesen muß. Ich habe selbst so einen Unsinn produziert.
Da man in 3) eigentlich bereits weiss, dass 1) nicht dem wahren Bedarf entspricht und 2) schlecht geschrieben sein wird, legt man den Preis rein arbiträr fest (ich habe das oft genug gemacht).
Motivation von Mitarbeitern ist ein wichtiger Forschungsgegenstand der betriebswirtschaftlichen Organisationstheorie. Man hat festgestellt, dass a) die Motivation von Mitarbeitern wichtig für die Effektivität der Arbeit ist und b) Menschen stärker motiviert sind, wenn sie das Gefühl haben in den Gesamtprozess zu partizipieren und nicht nur eine kleine für sich selbst sinnlos aussehende Teilaufgabe ausfüllen sollen. Also funktioniert 4) nicht.
Da 1) nicht funktioniert, wird der Kunde in 5) etwas erhalten, für das er direkt Folgeprojekte anfordern muß.
Hört sich toll an, oder   
Leider gilt: There is no such thing as a free lunch.
Es besteht nämlich ein großes Risiko, dass sich Kunden dann für andere Projekte einen anderen Dienstleister suchen.

Fazit:
- Leute, die an solche Prozesse glauben, beschleunigen den Nord-Süd-Ausgleich vor dem Hintergrund von

The global economic playing field is being leveled.

Da ich eine große Sympathie für den Nord-Süd (Teile Osteuropas gehören zum Süden) Ausgleich habe, bin ich solchen Leuten gegenüber noch nicht einmal mehr sauer. Indische outsourcer haben übrigens extra Leute eingestellt, die darauf spezialisiert sind, den aus den Westen kommenden Dokumentationswust auf ein goutierbares Maß zu kürzen. Ich kann leider den Link nicht wiederfinden, aber ich suche weiter.

Lange Rede kurzer Sinn
Da diese Sachen mit den Pflichten/Lastenheften nicht funktioniert, mache es so, wie es Consultings im Notes Bereich immer gemacht haben:
- rede mit dem Kunden
- schreibe einen kurzen, lesbaren Text, in dem auf strukturierte Art und Weise dargelegt wird, was das System machen wird. Schreibe Angebot drüber und besorg dir irgendwo eine Vorlage für die legalen Aspekte.
- vereinbare mit dem Kunden Rapid Prototyping. Dh.: Deine Organisation schickt während der Entwicklung Teile der Anwendung an die Organisation und du bittest die um Feedback. Besser sind Meetings zwischendurch oder schicke zumindest Screenshots.

Leute, die ihr Gehirn zum Denken und nicht für Opium-vernebeltes Tagträumen benutzen, arbeiten übrigens an Prozessen, die unserem Zivilisationsgrad würdig sind.
Ich benutze das: 
http://www.ambysoft.com/unifiedprocess/agileUP.html

Gruß Axel

[flaite]

In Projekten unter diesen Bedingungen konnte man in den letzten Jahren ein Auskommen finden. Ich übrigens teilweise auch.
Das einzige, was mich wundert ist, dass das sehr reale Leute noch für professionelles Arbeiten halten.
Jemand sollte mal deren interne Marihuana-Produktion medizinisch untersuchen.
Wenn du es macht: Produziere so wenig Dokumentation wie gerade nötig. 

[animate]

Der agile Prozess ist z. B. bei unseren Auftraggebern und wahrscheinlich noch bei etlichen anderen noch nicht angelangt. Deren Prozess schreibt ein Lastenheft und Pflichtenheft und noch mehr vor. Diese Dokumente sind auch nur mit großem Aufwand nach einer Freigabe noch änderbar.
Mir gefällt das nicht. Es gibt nämlich genau die Probleme, die du beschreibst, die auch logisch sind.
Ein erschreckender Eindruck, den ich habe, ist, dass diese Probleme zum Teil bewusst in Kauf genommen werden -  vielleicht aus Gewohnheit.

Ich finde aber, es ist schwierig jemandem, der diesen Prozess tagein, tagaus lebt, davon zu überzeugen, dass es "agil" doch viel besser wäre.
Vor allem wenns noch ums Geld geht. Denn wenn die Anforderungen erst nach und nach detaillierter werden, ist es IMHO nicht möglich, einen Gesamtpreis festzulegen. Der Aufwand kann erheblich variieren.

[flaite]

Wasserfall hab ich in verschiedenen Ausprägungen erlebt. Es gibt eine Art, in der Leute, die das "fachliche" Modell erstellen, sehr viel Zeit eingeräumt wird und den Programmierern nur noch sehr wenig Zeit bleibt. Obwohl bei den Proggern Interesse besteht, mit sowas wie Junit-Tests zu arbeiten, wird argumentiert, dass dies nicht gebraucht wird. Und es würde helfen.
Politisch sieht es dann so aus, dass ein fachliches Modell niemals eine Error-Meldung erzeugt, Programmcode aber schon.
D.h.: auch wenn der Fehler im Lastenheft liegt, sind letztlich die Programmierer für die Ausbügelung des Fehlers verantwortlich, da dem oberen Management die Verfolgung eines Fehlers auf das Lastenheft zu abstrakt ist.

Ein erschreckender Eindruck, den ich habe, ist, dass diese Probleme zum Teil bewusst in Kauf genommen werden -  vielleicht aus Gewohnheit.

Es ist zumindest gut, dass die (aus Erfahrung) die grundsätzlichen Probleme des Prozesses kennen. Ich habe mit unerfahrenen Projekt-Managern zusammengearbeitet, denen das nicht klar war, und das ist definitiv schwerer zu ertragen.
Die Alternative besteht darin, praktisch ganz ohne Prozess zu arbeiten. Das ist oft in Projekten so, die keine besondere Priorität (mehr) haben. Sprich: Maintainance-Programmierung. Da wird oft auf Zuruf gearbeitet, ohne dass sich die Zeit genommen wird, die Auswirkungen von Änderungen auf das Gesamtsystem zu analysieren.
Oder Programmierer haben so viel Macht, dass sie jederzeit ungestraft die "in dem Programm ist es aber so"-Karte spielen können. Und sie glauben ihren Teil des Vertrags - also eine bestimmte Funktionalität in einer gegebenen Zeit zu liefern - jederzeit brechen zu können.

Nur ist dieser Ausstoß an letztlich unnötigen Dokumenten und Unflexibilität etwas, dass in der Betriebswirtschaft bekämpft wurde. Das ist der Kern von sowas wie Just in time Produktion und Total Quality Management. Ich hab deshalb Interesse an agilen Prozessen, weil ich mir ernsthaft die Frage stelle, wie lange das eigentlich noch so gut geht.

Ich hab genug traditionelle Projekte erlebt, in denen früh klar wurde, dass das Ergebnis etwas sein wird, dass nicht den Anforderungen entsprechen wird. Also gab es Nachverhandlungen. Man kann also auch nicht sagen, dass mit einem Wasserfallmodell gewährleistet ist, dass der Gesamtpreis früh quantifizierbar wäre.
Prozessinnovationen haben sich in anderen Branchen auch nicht sehr schnell durchgesetzt. Ich hab aber für mich beschlossen, mich damit zu beschäftigen.
In diesem Land wird genug in andere Länder outgesourced. Ich kann über die "bösen" Manager schimpfen, die im Grunde nur Agenten der Angleichung von Lebensverhältnissen unter den Bedingungen von

The global economic playing field is being leveled.

sind.
... oder ich kann schauen, ob es nicht vielleicht doch bessere Wege gibt. Unser komparativer Vorteil besteht hauptsächlich in der Nähe zum Kunden. Für agile Prozesse ist das ein bedeutenderer Vorteil als im Wasserfallmodell. 
Wenn man mit traditionellen Prozessen arbeitet, sollte man zumindest die Schwachstellen gut kennen. Das war die Intention meines vorangegangenen Postings.

Gruß Axel

[Bruce Willis]

Hallo,

danke an alle Beteiligten!

Gruß
Leo