Das Softwareprojekt ist ein Arrangement zwischen zwei Partnern: Der Kunde braucht eine Softwarelösung, um einen individuellen Geschäftsprozess zu unterstützen, und der Lieferant ist in der Lage, ein solches System zu entwickeln. Oft sind Kunde und Lieferant zwei verschiedene Unternehmen, manchmal sind es auch zwei verschiedene Abteilungen innerhalb einer Organisation. In jedem Fall müssen Vereinbarungen getroffen werden, wer welchen Beitrag zu leisten hat, damit das Projekt gelingt.
Informationen, die die eine Seite hat, damit die andere zu einem guten Ergebnis kommt, sind im Softwareprojekt von besonderer Bedeutung. Solche Situationen beschreibt die ökonomische Forschung mit dem Prinzipal-Agent-Ansatz: Der Agent verfügt über Informationen, die er zum Nutzen des Prinzipals einbringen soll – allerdings kann der Prinzipal das Verhalten des Agenten nicht jederzeit komplett beobachten. So weiß er nicht, ob der Agent wirklich alles tut, um das vereinbarte Ziel bestmöglich zu erreichen. Daraus entstehen Verhaltensunsicherheiten, die der Prinzipal beherrschen möchte. Das soll über ein geeignetes Vertragsdesign geschehen.
In der ökonomischen Forschung zu Softwareprojekten wird bis heute zumeist der Kunde als Prinzipal angesehen, während dem Lieferanten die Rolle des Agenten zufällt. Das scheint auch nahe liegend, denn der Lieferant soll für den Kunden eine Software entwickeln, er verfügt dazu über Informationen, die der Kunde nicht hat, und er kann während der Softwareentwicklung nicht jederzeit beobachtet werden.
Der Kunde als Agent
Allerdings – und das ist der zentrale Punkt der Arbeit von Cornelia Gaebert – gibt es im Softwareprojekt auch den umgekehrten Fall: Der Kunde wird zum Agenten, und zwar dann, wenn die Anforderungsspezifikation nicht vollständig ist, eine Situation, die uns bei komplexen Softwareprojekten zu Beginn zumeist begegnet. Dann verfügt der Kunde über Informationen, die er für den Erfolg des Lieferanten ins Projekt einbringen muss. Das ist grundsätzlich auch klar, aber es gibt eine reihe von Gründen, die dazu führen, dass der Kunde dies nicht ausreichend tut.
Sowohl für die Wissenschaft als auch für die Praxis ist die Frage interessant, welche Möglichkeiten der Vertragsgestaltung es gibt, um dieses Problem beherrschbar zu machen und das Projekt zum Erfolg zu bringen. Die Antwort hängt von den Gründen ab, die dazu führen, dass der Kunde seinen Beitrag nicht leistet. So kann es sein, dass er dazu schlicht nicht in der Lage ist, weil ihm das Know How oder das Wissen um die Notwendigkeit seines Beitrags fehlen. Es kann aber auch sein, dass er seinen Beitrag bewusst nicht leistet, weil er Ziele verfolgt, die dem Projekterfolg entgegenstehen. Dementsprechend unterscheiden sich auch die Möglichkeiten, die konkrete Situation richtig zu beurteilen und die richtigen Maßnahmen abzuleiten.
In diesem Paper (hier der vollständige Text als PDF), die dieser Tage auf einer Konferenz im schwedischen Lund vorgestellt wird, werden die Wege zu einem geeigeneten Vertragsdesign aufgezeigt.
Cornelia Gaebert (2014). Contract Design and Uncertainty in Software
Development Projects Proceedings of the 13th International Conference on Perspectives in Business Informatics Research DOI: 10.1007/978-3-319-11370-8_16
Man könnte auch – ganz ketzerisch – behaupten, dass der “Prinzipal-Agent-Ansatz” in den hier genannten Fällen, wie auch in vielen anderen Fällen einfach nicht anwendbar ist.
Diese Theorie ist eben doch nur ein sehr wager Denkansatz, mehr nicht.