Inhalt : Abnahmeprotokoll (Excel)

Der Auftraggeber und die Auftragnehmer sollten besser von vornerein die Abnahmekriterien festlegen. Dann weiß der Auftragnehmer was zu tun, der Auftraggeber was er bestellt.

Wenn nicht geliefert wird was "bestellt" wurde, sind meistens beide Parteien schuld. Einer der nicht klar "bestellte", und einer der trotzdem mitmachte.

Die ideale Welt sieht so aus, die Praxis leider meist anders. Großes Beispiel: Neuer Berliner Flughafen. Kleines Beispiel: fast jedes kleine Projekt.

Das hat nichts mit idealer Welt zu tun sondern mit Rückgrat.

Es gibt hier zunächst 3 Möglichkeiten

1) Der Auftraggeber/Projektinhaber ist ehrenhaft und weiß was er will. Dann bekommt man die Abnahmekriterien.

2) Der Auftraggeber/Projektinhaber ist ehrenhaft und weiß nicht genau was er will. Dann kann man sich der Sache inkrementell nähern (Prototypen und Co). Eventuelle Sackgassen werden dann akzeptiert als notwendiger Aufwand zum richtigen Weg. Das ist ein Stück weit die Idee hinter Scrum.

3) Der Auftraggeber/Projektinhaber ist ehrlos. Dann bleiben folgende Möglichkeiten

a) Projekt ablehnen

b) Eskalation in der vagen Hoffnung den Auftraggeber/Projektinhaber zu ehrenhaften Verhalten zu bewegen. Gelingt in speziellen Fällen.

c) Neuen Job suchen. Nein, das ist kein Davonlaufen. Es macht nur keinen Sinn mit solchen Auftraggeber/Projektinhabern einen Krieg auszufechten. Letztlich gewinnt keiner. Das Projekt schon gar nicht.

Erfolgreiche Projekte erfordern EIN Team in dem ALLE mitmachen, auch und gerade die Projektinhaber.

Beim Berliner Flughafen gab/gibt es ganz offensichtlich kein funktionierendes Projektmanagement. Mit noch so tollen Abnahmeprotokollen ist das Projekt nicht zu retten.

Viele kleine Projekte sind in Grunde eine Mobbinggelegenheit für unreifes Management, ja, das sehe ich auch so 

Eine Excel Liste hilft, aber am Ende führt an einer Projektskizze oder einem ähnlichen Dokument mit vorab definierten Abnahmekriterien nichts vorbei.

Ich durfte schon einige Projekte erben, indem keine Abnahmekriterien festgelegt waren. Und bei jedem Einzelnen gab es am Ende umfangreiche Nacharbeiten ohne Nachberechnung. Der Kunde will das was er (seiner subjektiven Meinung nach) bestellt hat. Wenn diese Meinung nicht objektivierbar ist, ist der Dienstleister immer der Blöde.

"Viele kleine Projekte sind in Grunde eine Mobbinggelegenheit für unreifes Management", das ist super.

Geduld, ich muss die anderen Templates ja noch auf openPM rüberziehen und meine Sammlung vervollständigen ,-)

Der Auftraggeber/Projektinhaber weiß aber i.d.R. doch nicht so genau was er will oder was er will ändert sich im Zeitverlauf. Das hast auch nichts mit Boshaftigkeit oder mangelnder Professionalität zu tun, sondern mehr mit Eventualitäten, fehlender Vorstellungskraft, Unabwägbarkeiten, fehlender Transparenz oder kommunikativen Missverständnissen.

Dann sollte sich der Projektinhaber gemäß Punkt 2) verhalten

Wenn der Projektinhaber nicht genau weiß bzw. formuliert was er will, kann er seriöserweise nicht erwarten, dass er es geliefert bekommt.Er kann nur erwarten, dass zu bekommen, was er verständlich, widerspruchsfrei formuliert hat. Selbstverständlich wird ein guter Projektumsetzer dem Projektinhaber dabei helfen, gute Abnahmekrieterien zu finden und Strategien aufzuzeigen, wie mit Unsicherheiten umgegangen werden kann. Stichwort: Inkrementelles Entwickeln, z.B. Scrum (nochmals siehe Punkt 2)

Nur gibt es leider auch sehr viele unreife und boshafte Projektinhaber, die versuchen den Projektumsetzer zu überfordern, zu übervorteilen und auszuplündern. Siehe Punkt 3)

Die Projektproduktivität (und damit ein großes Stück des Erfolges) hängt maßgeblich vom Vertrauen zwischen Projektinhaber und Projektumsetzer ab. Zur Vertrauensbildung müssen beide Parteien beitragen. Machtspiele und Tricksereien führen zum Krieg. siehe auch Punkt 3c)

Es ist natürlich wünschenswert von Anfang an klar definierte Liefergegenstände und Abnahmekriterien zu haben, nur häufig erweisen sich diese im Zeitverlauf als weit weniger eindeutig oder sinnvoll als von allen Beteiligten erhofft.

Der Vertrauensvolle Umgang miteinander ist ein hehrer Ansatz, aber zunächst einmal muss man das AG/AN-Verhältnis auch als Konfliktsituation charakterisieren, alles andere wäre utopisch. Ich kann natürlich auch in Konfliktsituationen vertrauensvoll miteinander umgehen, bloss fällt es da den meisten schon erheblich schwerer.

Ich weiß auch nicht, ob uns die ethisch/moralische Diskussion an dieser Stelle weiter hilft. Fakt ist: Auch bei bestmöglicher Vorklärung geraten Projekte immer wieder in ein "Abnahmedilemma" und für die Beteiligten stellt sich die Frage, wie gehen wir damit um.

zum Thema folgendes (für Softwareprojekte und auch sonst):

a) Aus einer produktbasierter Planung resultieren Ergebnisse die insgesamt abgenommen werden (die haben einen Termin kleiner Projektende)

b) aus jedem einzelnen Ergebnis lassen sich Anforderungen ableiten die Gegenstand der Qualitätssicherung sind, ergo ist bereits die QS Bestandteil der abnahmeprozedur

Nicht umsonst ist das erste Kapitel in einem Konzept die detaillierte Auflistung der Anforderungen (wie die Excelliste von Herrn Heilwagen) inkl. Hinweisen warum Anforderungen nicht enthalten sind (weil nicht sinnvoll, Changes etc.) und warum bei den einen oder anderen abgewichen wurde (gem. Beschluss des Facharbeitskreises x-y).

c) Wenn das Endprodukt nicht das bestellte ist, haben alle "geloost"......

Und wenn jemand ein Endprodukt aus einem Projekt nicht abnimmt dass nach SCRUM durchgerführt wurde, ......

P.S. ...darf ich meine Vorlagen hier auch Veröffentlichen und wenn ja wo ?

...und jetzt stellen Sie sich vor, sie haben nicht einen Kunden sondern 12.....vermeintlich wollen alle das Gleiche, aber irgendwie doch nicht.....ich finde solche Abstimmungsrunden immer sehr abenteuerlich.....vor allem wenn Vertreter von Fachbereichen meinen, sie müssten auch noch über Architektur reden...Vermischung von Rollen und Verständis einzelner zu ihrer Rolle in solchen Facharbeitskreisen ist hoch interessant und mitunter anstrengend.

Hallo Reiner, nur her mit deinen Vorlagen! Integriere sie doch in die Methoden-Seite. Wenn du auch ein Abnahmetemplate hast gerne auch hier als alternatives Angebot. Wenn wir mal mehr Templates eingesammelt haben, können wir unter den Methoden auch mal eine eigene Unterseite für Templates anlegen.

Schwierig ist es immer dann, wenn die Anforderungen schwammig sind. In meinem Fall nämlich keine Software die klare Features hat, sondern Kommunikations- und Marketinganforderungen. 

Bei solchen Projekten gibt es natürlich Ziele, nur sind diese schwierig so zu definieren, dass eine Erfüllung klar beurteilbar ist. Auch bei Webseiten und Software gibt es solche Fälle, z.B. bei Usability Anforderungen.

Wie beschreiben Sie solche Ziele? Gibt es da Methoden oder Best Practices? Ich schreibe seitenweise Projektskizzen, die dennoch oft zu schwammig sind..... 

Gnerelle Frage in die Runde: Sind BestPractices der Anforderungsanalyse Gegenstand von openPM und wenn JA wie gliedern wir diese ? Nach Branchen ? Nach Endergebnis ?

@pascalswelt Was sind Projektskizzen ? Skizzen ihres Projektes oder Skizzen des Endergebnisses das durch das jew. Projekt erstellt werden soll?

Ein BestPractices kann ich schon 'mal vorweg nehmen: Schreiben sie ein Glossar damit die Begrifflichkeiten klar sind. Habe aktuell einen solchen Fall, ein Klassiker: Wir schreiben ein IT-Konzept. Reaktion des Produktmanagements: "...das versteht ja keiner, da ist ja nur technisches drin. Wir brauchen Screenshots, Prozessbeschreibungen usw." Antwort von den Entwicklern: "Definieren Sie keine Parameter oder Strukturen, das machen wir im IT-Konzept:" Frage meinerseits: "Wenn der Facharbeitskreis das Fachkonzept schreibt, das IT-Konzept das wir schreiben sollen aber eigentlich ein Fachkonzept ist, was erstellt dann der Facharbeitskreis für ein Dokument (Inhalt, Tiefe)?" Auflösung: Der Facharbeitskreis erstellt ein Dokument, welches Projekthintergrund, auftrag, Businesscase und die groben Anforderungen und eine erste Lösungsskizze enthält. Das Fachkonzept ist ein klassisches Fachkonzept, heißt aber, weil es die IT schreibt, ITKonzept, und das eingetliche IT-Konzept mit Architektur usw. heißt Architekturkonzept, und Schnittstellenkontrakte heißen einfach nur Dokumentation.

 @pascalswelt

Nur so als Idee, weil ich keine konkreten Anhaltspunkte zur Aufgabenstellung habe. Wenn die Erfüllung der Ziele nicht klar beurteilbar (technisch messbar) ist, dann erfolgt die Beurteilung fast zwangsläufig über "Meinungen". Je nach Zielgruppe (interne Abteilung, definierter Kundenkreis, offene Community, ...) wäre ein "Beurteilungskommitee" oder eine Befragung über Beta-Tests, Foren oder ähnliches denkbar.

Entsprechend gestaltet sich die Beschreibung der Projekt-Ziele. Diese müssen so beschrieben sein, dass die Gruppe, die für die abschließende Beurteilung zuständig ist, die Ziele versteht und die Umsetzung bewerten kann.

Also: Jedes Ziel solange konkretisieren und hinterfragen, bis klar ist, wer die Erfüllung am Ende beurteilt und mit welchen Methoden dies geschieht.

@Rainer Schindler: Projektskizzen beschreiben genau wie ihr Fachkonzept die Prozessschritte, die Ausgangssituation und grob die Lösung, sowie die damit zu erreichenden Ziele. 

@Tobias Hahn Ich denke auch, dass den Projektzielen die wichtigste Bedeutung zukommt. Die meisten Entscheider sind in meinem Fall relativ fachfremd. Sprich "Nicht Gestalter" müssen z.B. Designentwürfe beurteilen. Die Entscheidungskriterien dürfen dabei nicht Geschmack sein (Vereinfacht z.B. "ich mag kein weiß, das ist so langweilig.") sondern möglichst objektive definierte Ziele ('es soll eine professionelle, präzise und technische Umgebung gezeigt werden"). 

Das Glossar (im Sinne einer Begriffsdefinition) finde ich daher sehr interessant und werde es beim nächsten Mal probieren. In meinem vereinfachten Beispiel: "Wir verstehen unter professionell: sauber (quasi Reinraum), hell und aufgeräumt.. Dementsprechend ist das Layout sehr clean, stark überleuchtet und hat viel Weißraum". Desto genauer ich die Begriffe definiere, desto einfacher mach ich mir am Ende den Projektabschluss. 

Danke für den Tip 

@pascalswelt:

Vielen Dank für die konkreten Beispiele. Ich gewinne daraus den Eindruck, dass es im Moment mehr um das Design als um technische Funktionen geht.

"Meinung" und "Geschmack" sind für mich verschiedene Dinge. Mir kann ein Design sehr gut gefallen und trotzdem bin ich der Meinung, dass es im konkreten Fall ungeeignet ist. Auch die Meinungen, was "professionell", "technisch" oder "präzise" ist, können auseinander gehen. Hier ist sicherlich eine genauere Definition, gerade mit den späteren Entscheidern erforderlich, um zu klaren Kriterien zu kommen.

Auch wenn ich eher aus der technischen Ecke komme: Mit Designentscheidungen verbinde ich auch immer die Stichworte "Botschaft" und "Werte". Was soll durch das Design vermittelt werden? Frage für die Abnahme: "Werden die beabsichtigten/beauftragten Botschaften und Werte (im angestrebten Maß) übermittelt?" Auch hier sind Geschmack und Meinung der Entscheider verschieden: "Ja, ich bin der Meinung, dass die Oberfläche einen sterilen Eindruck vermittelt, aber sie gefällt mir trotzdem nicht". Was ist hier wohl die entscheidende Aussage für die Abnahme? 

Ich habe mal die Diskussion von dieser Seite aufgegriffen und einen Überblicksartikel "Abnahme" angelegt. Helft doch in bester Wiki-Manier mit den Artikel zu verbessern!