Seite 3: Organisations- & Verantwortlichkeitsstruktur II

Inhaltsverzeichnis

Produktanbieter

Beim dieser Projektart ist der Verkauf der entwickelten Software der eigentliche Geschäftszweck, ansonsten sind die Eigenschaften ähnlich wie bei der internen Linienaufgabe oder gegebenenfalls beim internen Projekt. Beispielhaft sei ein Medizingerätehersteller genannt, der Beatmungsgeräte samt zugehöriger Software herstellt, die er an Krankenhäuser verkauft.

Sofern es sich um eine neue Produktart handelt, ist die frühe Lieferung funktional abgespeckter Artikeln wie iPhone und iPad. Nachahmer haben es dann schon schwieriger. Deren minimaler marktgängiger Funktionsumfang ist durch den Marktführer gesetzt, sofern sie nicht besondere eigene Innovationen zufügen können. Andererseits ist es ab der zweiten Produktversion prinzipiell wieder einfacher, inkrementell zu arbeiten.

Typische Herausforderungen für diese Projektart sind:

• Die Endkunden und Endbenutzer sind nur indirekt zu beteiligen;
• sie sind einflussarm;
• repräsentative Beta-Testsituationen sind zu schaffen;
• eine inkrementelle Lieferung und sinnvolle Teillösungen sind zu schaffen.

Koordinator

Die Gesamtverantwortung für ein Vorhaben verbleibt beim Auftraggeber. Er entwickelt aber nicht mit, sondern vergibt dafür Aufträge an externe Lieferanten. Die Eigenschaften sind ähnlich wie beim Gewerk, wobei der Auftragnehmer wichtige koordinierende und überwachende Aufgaben verantwortet, vor allem dass sich die Gewerke in einer (bestehenden oder durch andere Gewerke weiterentwickelten) Systemlandschaft integrieren und betreiben lassen.

Damit verbleibt ein signifikantes Risiko beim gesamtverantwortlichen Auftraggeber. Es kann ihm passieren, dass alle Zulieferer beanstandungsfrei liefern und trotzdem die Gesamtlösung nicht zum Laufen kommt, weil er Schnittstellen oder Rahmenbedingungen unzureichend koordiniert oder spezifiziert hat. Ein Beispielszenario für diesen Projekttyp wäre ein Versandhändler, der eine neue Bestellverwaltungssoftware vom externen Anbieter A herstellen lässt, die in einer Hard- und Softwareumgebung laufen soll, die der externe Anbieter B betreibt.

Das Versagen eines Einzellieferanten kann das Gesamtsystem gefährden. Einzelne Mängel haben das Potenzial, unkalkulierbar große Negativwirkungen zu zeigen, da Workarounds und andere Risikominimierungsmaßnahmen gegebenenfalls wiederum mit anderen Lieferanten zu verhandeln sind.

Typische Herausforderungen für Koordinator-Projekte sind:

• Einzelverträge sind so zu gestalten, dass das Koordinationsrisiko minimiert wird;
• Rückstellungen und Puffer zur Behebung von Koordinationsfehlern müssen bereitgehalten werden;
• eine frühzeitige und regelmäßige Integration über Lieferantengrenzen hinweg.

Kooperative (Open Source)

An der Entwicklung einer Open-Source-Software sind gewöhnlich viele Personen oder Firmen beteiligt, die sich den Entwicklungsaufwand auf zumeist freiwilliger und jederzeit abbrechbarer Basis teilen und sich selbst kooperativ organisieren. Die Basis bilden lizenzrechtliche Vereinbarungen, technische Infrastruktur und die Verteilung von Rollen und Rechten. Eclipse ist ein Beispiel eines Open-Source-Projekts, das durch die Freigabe eines ursprünglich IBM gehörenden Produkts (Visual Age) entstand, das später in die rechtlich eigenständige Eclipse Foundation übergegangen ist.

Allerdings ist zu bedenken, dass normale, das heißt Nicht-Open-Source-Projekte manchmal einfach entscheiden, ihre Arbeitsergebnisse zu veröffentlichen, es aber ansonsten unverändert das gleiche Projekt ist. Deswegen ist der Begriff "Open Source" nicht immer das richtige Unterscheidungsmerkmal.

Besondere Eigenschaften kooperativer Projekte sind:

• Die Teilnehmer kennen sich oft nicht persönlich.
• In vielen Projekten gibt es eher weniger Schätzungen und Metriken.
• Es ist gewöhnlich transparent, wer etwas zu machen plant, aber weniger, wer tatsächlich wann wie intensiv an etwas arbeitet.
• Die Arbeit wird meistens nebenbei erledigt und kann auch mal ein paar Wochen liegen bleiben.

Viele erfolgreiche Open-Source-Projekte haben eine oder wenige Führungsfiguren, die dem Projekt eine klare Richtung geben, ansonsten fehlt oftmals die Erarbeitung oder Kommunikation einer Vision.

Typische Herausforderungen für kooperative Projekte sind:

• unstete und weniger zuverlässige Verfügbarkeit und Kapazitäten der Beteiligten;
• uneinheitliche Qualität der Arbeitsergebnisse, Ergebnisse werden öfter auch mal wieder verworfen beziehungsweise nicht akzeptiert;
• die Selbstverpflichtungen der Teilnehmer sind oft anders als in anderen Projektarten;
• die Kommunikation komplexer Sachverhalte ist aufwendiger und anfälliger.