Seite 2: Organisations- & Verantwortlichkeitsstruktur I

Inhaltsverzeichnis

Unterscheidung nach Organisations- und Verantwortlichkeitsstruktur

Werden Projekte nach Organisations- und Verantwortlichkeitsstruktur unterschieden, ergeben sich ganz andere Projektarten, mit anderen Risiken, Chancen und Herausforderungen.

Das betrifft vor allem den Product Owner und seine Stakeholder. Für den Product Owner und das Requirements Engineering sind die Unterschiede in der Aufteilung der Verantwortlichkeiten zwischen den Beteiligten besonders relevant, und sie führen in der Praxis zu unterschiedlichen Arbeitsweisen, weswegen der Unterscheidung besondere Aufmerksamkeit gewidmet sei.

Die in der Tabelle näher beschriebenen Projektarten "internes Projekt", "interne Linienaufgabe", "Gewerk", "Produktanbieter", "Koordinator" und "Kooperative" sind lediglich prototypische Ausprägungen. Tatsächlich gibt es beliebig viele Mischformen und Extreme. Beispielsweise sind Automobilhersteller sowohl Anbieter von Publikumsprodukten und gleichzeitig Koordinatoren einer Unmenge von Zulieferern. Sie bieten damit wahrscheinlich die größten Herausforderungen im Kontext des agilen Requirements Engineering.

Projektart "Entwicklung als …"	Vertragsart & Abrechnung	Vertrags­- partner	Organisation	Produktart & Empfänger	externe Lieferanten
A) internes Projekt (Projekt- organisation zur Individual- Produkt- entwicklung);	interne Kostenstelle, ggf. interne Verrechnung	interner Auftragnehmer	temporär (Projekt)	Individual- produkt oder beschränkter Kundenkreis	keine oder wenige Gewerke
ggf. inkl. Arbeitnehmer- überlassung (Dienst­leistungs- verträge mit Externen)	Dienstleistung (Abrechnung nach Aufwand)	externer Auftragnehmer			ergänzende Dienstleister
B) interne Linienaufgaben (dauerhafte Entwicklungs- organisation zur Individual- Produkt­- ent­wick­lung)	interne Kostenstelle, ggf. interne Verrechnung	interner Auftragnehmer	dauerhaft (Linie)	Individual- produkt oder beschränkter Kundenkreis	keine oder wenige Gewerke; oft ergänzende Dienstleister
C) Gewerk (Projekt- organisation mit externem Auftragnehmer als Werkvertrag)	Werkvertrag (ggf. Festpreis, ggf. Ausschreibung)	externer Auftragnehmer	temporär (Projekt)	Individual- produkt oder beschränkter Kundenkreis	ein Auftragnehmer, ggf. Sub- unternehmer
D) Produkt- anbieter (Dauerhafte Entwicklungs- organisation zur Publikums-Produkt- entwicklung)		interner Auftragnehmer	dauerhaft	Publikums- produkt	keine oder wenige
E) Koordinator (Projekt- organisation mit internem General- auftragnehmer und vielen externen Lieferanten)	intern Dienstleistung; mit externen Werkverträge (diese ggf. Festpreis und Ausschreibung)	beides	temporär (Projekt)	Individual- produkt oder beschränkter Kundenkreis	viele
F) Koperative (OpenSource)	freiwillige Einwilligung in Rahmen -bedingungen	Kooperation	oft dauerhaft, aber Beteiligte wechseln	Publikums- produkt	viele

"Unterscheidung nach Organisations- und Verantwortungsstruktur"

Internes Projekt

Alle Beteiligten arbeiten für das gleiche Unternehmen – entweder für die Linienorganisation oder für das Projekt. Die Projektmitglieder haben zeitlich befristet die Projektleitung als fachlichen Vorgesetzten. Das Team gehört in jedem Fall zur Projektorganisation, der Product Owner ebenfalls.

Bei dieser Projektart wird in den meisten Fällen die Software für den eigenen Bedarf des Unternehmens entwickelt, weiterentwickelt oder angepasst. Gegebenenfalls trifft es zu, dass sie zusätzlich für kooperierende Geschäftspartner programmiert wird. Die Software unterstützt gewöhnlich indirekt den eigentlichen Geschäftszweck des Unternehmens. Beispielsweise entwickeln die Programmierer einer Krankenversicherung in einem Projekt eine Software für die eigene Verwaltung. Zusätzlich erhalten sie Unterstützung durch externe Entwickler und Berater.

Gewöhnlich sind viele Beteiligte angestellte Mitarbeiter, die durch Externe Unterstützung erhalten (in Form von Arbeitnehmerüberlassung, auch "Body-Leasing" oder "Consulting" genannt), sobald interne Kräfte nicht ausreichend verfügbar sind. Im Extremfall können aber alle Beteiligten Externe sein – maßgeblich ist, dass die Projekt- und Gesamtverantwortung beim beauftragenden Unternehmen liegt. Auch hierfür sei ein Beispiel gebracht: Ein Mobilfunkunternehmen wird mehr oder weniger auf der grünen Wiese gegründet, fast ausschließlich durch externe Berater aufgebaut, die die Firma schließlich nach und nach durch angestellte Mitarbeiter ersetzt.

Einige Besonderheiten sind im Kontext des agilen Requirements Engineering besonders: Entwicklungsteam, Product Owner und Scrum Master arbeiten angestellt oder mit Dienstleistungsvertrag für ein Unternehmen, das gleichzeitig Auftraggeber und -nehmer ist. Dadurch vereinfachen sich viele Aspekte in der Zusammenarbeit. Beispielsweise sind die meisten Benutzer ebenfalls Mitarbeiter im gleichen Unternehmen. Allerdings sind die Anforderungen gebenden Organisationseinheiten (vor allem Fachabteilungen und Geschäftsstellen) oftmals verstreut und verfolgen möglicherweise unterschiedliche Interessen, Prioritäten und widersprüchliche Anforderungen.

Ein agiles Projekt sollte daher bemüht sein, die Anforderungen gebenden Einheiten zusammenzubringen und mit ihnen ein gemeinsames Bild zu kreieren. Es sollte die Zusammenarbeit so gestalten, dass sich die potenziell widersprechenden Parteien anleiten lassen, ihre Widersprüche konstruktiv und miteinander zu erkennen und zu klären.

Soweit das nicht gelingt, ist das Projektteam gefährdet, permanent als Mittler und Stellvertreter auftreten zu müssen und zwischen den Parteien zerrieben oder gar ausgespielt zu werden. Eine nicht nur undankbare, sondern auch selten erfolgreiche Rolle. Ein dediziertes Stakeholder-Management sollte von Anfang an dazu gehören. Unabhängig davon braucht man in jedem Fall eine über allem stehende Eskalations- und Entscheidungsinstanz. Der Product Owner ist prädestiniert hierfür.

Typische Herausforderungen für ein internes Projekt sind:

• einflussreiche und sich widersprechende Interessenvertreter;
• verstreute Interessenvertreter;
• Stellvertreterkonflikte.

Interne Linienaufgabe

Eine interne Linienaufgabe unterscheidet sich vom internen Projekt im Wesentlichen dadurch, dass man die Software nicht in Form von Projekten, sondern durch eine dauerhafte Entwicklungsorganisation programmiert. Oftmals ist der Betrieb der Software auch der primäre Geschäftszweck.

Nicht selten gibt es auch Mischformen dergestalt, dass ausgewählte Teile als Projekt und die übrigen durch die Dauerorganisation entwickelt werden. Häufig ist auch eine Entwicklung in Form zahlreicher Klein-"Projekte" anzutreffen. Ein Internetportal entwickelt etwa die eigene Internetanwendung permanent weiter. Der Betrieb der Anwendung ist der unmittelbare Geschäftszweck. Die Weiterentwicklung orientiert sich an neuen Funktionen, die projektunabhängige Einheiten produzieren. Sofern nicht der Betrieb, sondern die Herstellung und der Vertrieb der Software primäre Geschäftszwecke sind, handelt es sich meistens um Produktanbieter.

Im Kontext des agilen Requirements Engineering sind wieder einige Besonderheiten zu beachten: Wie beim internen Projekt arbeiten Entwicklungsteam, Product Owner und Scrum Master als Angestellte oder mit Dienstleistungsvertrag für ein Unternehmen, das Auftraggeber und -nehmer ist. Sofern auch noch der Betrieb der Software mit dem Geschäftszweck des Unternehmens korrespondiert, ist die Zusammenarbeit der Beteiligten meistens einfacher als bei internen Projekten.

Im Unterschied zu ihnen befinden sich die Benutzer häufig außerhalb des Unternehmens, und es sind meistens deutlich mehr Anwender. Dafür haben einzelne weniger Macht und Einfluss und vertreten ihre Interessen gewöhnlich nicht direkt.

Typische Herausforderungen für den zweiten Projekttyp sind:

• Benutzer lassen sich nicht oder nur indirekt beteiligen;
• Benutzer mit geringem Einfluss.

Gewerk

Wie beim internen Projekt oder bei der internen Linienaufgabe wird eine Individualsoftware für den Eigenbedarf programmiert. Die Entwicklung ist jedoch ergebnisverantwortlich an Externe ausgelagert. Gewöhnlich schreibt man die Vorhaben aus und realisiert sie als Werkvertrag durch einen externen Auftragnehmer – oftmals zum Festpreis. Der Auftraggeber ist einerseits Zulieferer von Anforderungen und Entscheidungen des Auftragnehmers und zum anderen gegebenenfalls Koordinator der internen und externen Beteiligten.

Verantwortung und Kompetenzen (zum Beispiel Haftung, Gewährleistung, Zahlungsmodalitäten, Vorgehensweise) sind maßgeblich anders verteilt als bei Dienstleistungsaufträgen. Der Auftraggeber bestimmt die gewünschten Eigenschaften des herzustellenden Produkts, gewöhnlich aber kaum, wie sie herzustellen sind. Beispielsweise schreibt ein Seehafen auf Basis einer groben Anforderungsspezifikation die Entwicklung eines Hafenlogistiksystems öffentlich aus und beauftragt einen externen Auftragnehmer mit der schlüsselfertigen Herstellung (in Form eines inhaltsvarianten Festpreises).

Gerade die Festpreis-Variante, wie sie etwa für öffentliche Auftraggeber und andere stark haushaltsplanende Organisationen wichtig ist, prädestiniert ein Vorgehen, das regelmäßig brauchbare Vorversionen liefert und die Anforderungen nach absteigendem Geschäftswert sortiert umsetzt. Die Einhaltung eines Kostenziels ist bei der agilen Vorgehensweise vergleichsweise einfach, und der geschäftliche Nutzen lässt sich gut optimieren. Ein Wasserfallvorgehen kann nichts Vergleichbares bieten, auch wenn der Irrglaube, Wasserfallprojekte eigneten sich gut für Festpreise, immer noch populär ist.

Typische Herausforderungen für Gewerkentwicklungen sind:

• Auftragnehmer und Auftraggeber sind getrennt, die Projektbeteiligten haben unterschiedliche, sich auch widersprechende Interessen;
• aufwendige Auftragsklärung vor Vertragsschluss;
• nur wenige Einfluss- und Eskalationsmöglichkeiten zwischen Auftraggeber und -nehmer und nur indirekte zwischen Projektbeteiligten unterschiedlicher Parteizugehörigkeit.