Wenn von „Beratern“ die Rede ist, wenn zudem auch noch die Namen großer und teurer Beratungsunternehmen genannt werden, dann haben viele Menschen schnell die Vorstellung, dass da Herren in blauen Anzügen mit wichtigen Blicken Excel-Sheets präsentieren und womöglich andere Leute von der Arbeit abhalten, indem sie Plattheiten verkünden, die jeder schon weiß. Ein bekannter Witz über Unternehmensberater illustriert diese Vorstellung sehr schön und sicher nicht zu Unrecht.[1]

Beraterleistungen sind aber zum großen Teil etwas ganz anderes. Immer, wenn eine Behörde oder ein großes Unternehmen für ein Projekt auf begrenzte Zeit zusätzliches Know How benötigt, werden externe Berater engagiert, die oft von Unternehmen, die diese Experten haben, bereitgestellt werden.

Beispiel Softwareprojekt

Im Bereich von Softwareprojekten können das z.B. Anforderungsanalysten, Systemarchitekten, Softwareentwickler, Tester, Datenbankexperten, Adminsistratoren, Projektleiter und Projektassistenten sein.

Gehen wir mal davon aus, dass die Beratungsunternehmen etwa die gleichen Stundensätze verlangen wie INDAL, vielleicht auch etwas höher. Rechnen wir der Einfachheit halber mit 1.000 € / Tag, bedenkend, dass die Mehrwertsteuer inkludiert ist. Sagen wir, dass ein Berater im Jahr 225 Tage arbeitet, macht in 2 Jahren 450 Tage. Dann ergibt das 444 Berater, die im Verteidigungsministerium tätig sind. Das kann bei einer Behörde mit knapp 3.000 Mitarbeitern, die eine Bundeswehr mit 180.000 Soldaten zu führen hat, durchaus angemessen sein.

Die Praxis, für Projekte das Spezial-Know-How extern zu beziehen, ist bei der Komplexität der benötigten Expertise, die nach Ablauf des Projekts im gleichen Umfang nicht mehr gebraucht wird, durchaus effektiv. Dass ein Berater dann „mehr kostet“ als ein interner Mitarbeiter, ist einerseits verständlich, denn er muss das Know-How ja zuvor erworben haben, andererseits bezahlt man ihn eben nur während der Projektlaufzeit. Hinzu kommt, dass Expertise schnell veraltet. Über externe Berater kann man sich immer das aktuelle, gerade benötigte Wissen einkaufen.

Politische Notwendigkeiten

Natürlich stürzt sich die Opposition im Bundestag gern auf solche Zahlen von mehreren 100 Mio. Euro, die das alltägliche Vorstellungsvermögen übersteigen. Und da die Medien bereits eifrig berichtet hatten, muss es für eine Parlamentsopposition selbstverständlich sein, darauf einzusteigen und einen Untersuchungsausschuss einzurichten. Es kann aber gut sein, dass dieser Ausschuss vielleicht ein paar Ungereimtheiten oder Fehler in der Auftrags-Vergabepraxis feststellt, im Übrigen aber nichts gegen den Umfang der Beratungsleistungen einzuwenden hat.

Und hier der Witz:

[1] Ein Schäfer steht auf einer Weide mit seiner Herde. Plötzlich fährt ein riesiger SUV vor, ein junger Mann springt heraus, blauer Anzug, italienische Schuhe, Krawatte, sorgsam frisiertes Haar. Er sagt zum Schäfer: „Wenn ich Ihnen genau sagen kann, wie viele Schafe Sie haben, geben Sie mir dann ein Schaf?“ Der Schäfer sagt, etwas amüsiert: „OK“. Der junge Mann klappt sein Notebook auf, verbindet sich mit dem Internet, scannt per GPS die Gegend, öffnet 30 Excel-Sheets und verkündet schließlich: „Es sind exakt 2.365 Tiere“. Der Schäfer grinst und sagt: „Stimmt.“ Der junge Mann greift sich ein Tier, stopft es ins Auto und will abfahren. „Halt halt,“ ruft der Schäfer, „wenn ich Ihnen sage, was Sie von Beruf sind, bekomme ich das Tier dann zurück?“ Der junge Mann lächelt und willigt ein. Der Schäfer sagt: „Sie sind Unternehmensberater“. Der junge Mann ist erstaunt: „Woher wissen Sie das?“ Darauf der Schäfer: „Sie kommen hier her, ohne dass Sie jemand gerufen hat, erzählen mir Dinge, die ich längst weiß und haben keine Ahnung davon, was ich mache. Und nun geben Sie mir meinen Hund zurück.“

Der Beitrag Externe Berater im Verteidigungsministerium erschien zuerst auf INDAL Software-Spezialist.

Aber auch das Messnetz muss überwacht werden. Dafür ist unser Kunde, ein Landesamt in Düsseldorf, zuständig. Für diese Überwachung ist es weiterhin notwendig, dass hin und wieder ein Mensch zur Messstation fährt und sie ganz herkömmlich “in Augenschein nimmt”. Dass er dann vor Ort eine Internet-Verbindung hat, über die er sich mit einer zentralen Datenbank verbinden kann, ist nicht immer sicher.

Deshalb entwickeln wir bei INDAL derzeit in einem individuellen Softwareprojekt eine Lösung, bei der die Mitarbeiter, welche die Messstationen kontrollieren, die Stationsdaten in eine kleine lokale Datenbank “auschecken”. Diese lokale Datenbank nehmen sie auf die Dienstreise mit, in ihr nehmen sie draußen an den Stationen ihre Änderungen vor. Nach der Rückkehr des Mitarbeiters werden die geänderten Daten in die zentrale Datenbank zurück übertragen.

Wichtig ist einerseits, dass der Mitarbeiter vor Ort über eine klare, intuitiv und einfach zu nutzende Benutzeroberfläche verfügt. Vor allem kommt es aber auch darauf an, dass beim “einchecken” in die zentrale Datenbank Konflikte erkannt und beseitigt werden. Es kann nämlich sein, dass zwei Kollegen kurz nacheinander die gleiche Station besuchen um unterschiedliche Kontrollen vorzunehmen. Diese Daten dürfen natürlich nicht gegenseitig überschrieben werden, vielmehr müssen sie im Normalfall einfach zusammengeführt werden können.

Die Lösung wird bei INDAL mit Microsoft Access erstellt, wobei eine Anbindung an eine Client-Server-Datenbank wie MS-SQL-Server jederzeit möglich ist.

Der Beitrag Die Überwachung der Umwelt überwachen erschien zuerst auf INDAL Software-Spezialist.

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

Der Beitrag Die Unsicherheiten im Softwareprojekt beherrschen erschien zuerst auf INDAL Software-Spezialist.

Zeit, die Blickrichtung zu wechseln. Wir sollten, gerade, wenn das Softwareprojekt durch ein externes Softwarehaus realisiert wird, die Vertragsbeziehung zwischen dem Kunden und dem Softwarehersteller in den Blick nehmen. Ist das Scheitern des Projektes vielleicht oft schon in der Vertragsbeziehung angelegt? Werden Pflichten und Anreize möglicherweise schon dort so festgeschrieben, dass das Projekt in Gefahr geraten muss, sobald auch nur “Kleinigkeiten” schief gehen? Das ist die Frage, der das Forschungsprojekt von Cornelia Gaebert nachgeht. Die ersten Ergebnisse wurden von ihr im August auf einer Internationalen Konferenz in Wien vorgestellt. Die Resultate gelten prinzipiell auch für Projekte, die innerhalb des Unternehmens durchgeführt werden, wenn die Verantwortlichkeiten und die zu tragenden Kosten durch klare Regeln (einen Vertrag) zwischen den Abteilungen festgelegt sind.

Anforderungslücken in der Softwarespezifikation

Anforderungslücken, also die unvollständige Spezifikation und die Änderung von Anforderungen, werden von allen Studien als wichtige Gründe des Scheiterns von Softwareprojekten angesehen. Deshalb wird auch viel Kraft in die Verbesserung der Methoden des Requirement Engineering investiert. Es ist aber plausibel, dass Anforderungen niemals zu Projektbeginn vollständig spezifiziert werden können. Deshalb muss man sich fragen, wie mit Anforderungslücken während des Projekts umgegangen wird. Wer ist für das Schließen der Lücken verantwortlich? Wer muss den Aufwand leisten?

Es sagt sich leicht hin, dass am besten beide Partner, Kunde und Softwarehersteller, diesen Aufwand am besten gemeinsam tragen. In der Praxis müssen beide Seiten Kosten sparen, insbesondere, wenn ein Festpreis für die Erstellung sdes Systems vereinbart wurde, und das Schließen von Anforderungslücken verursacht kosten, Experten werden benötigt, die oft keine Zeit haben, Informationen müssen beschafft werden. Um Kosten zu sparen, versuchen oft beide Seiten, den eigenen Aufwand zu reduzieren und die Arbeit den anderen Partner machen zu lassen.

Das Dilemma zwischen Softwarehersteller und Kunden

Man kann zeigen, dass die Projektpartner sich in einer so genannten Dilemmasituation befinden, die in der ökonomischen Forschung als Gefangenendilemma bekannt ist. Im Ergebnis findet im Projekt keine Kooperation zwischen den Parteien statt – obwohl Kooperation zum besten Ergebnis für beide führen würde. Am Ende stehen beide Seiten mit leeren Händen da, weil das Projekt scheitert.

Die Forschung zum Gefangenendilemma kann aber auch den Ausweg weisen. Sie können Wege aufzeigen, wie der Vertrag zu gestalten ist, damit beide Seiten zur Kooperation bereit sind. Das ist natürlich besonders schwierig, wenn es sich um einen autoritären Festpreisvertrag handelt, den der Kunde dominiert. Aber auch dann gibt es Wege, die Beistellungen des Kunden so zu bestimmen und die Anreize so zu setzen, dass Kooperation nicht ausschließlich auf dem guten Willen der Beteiligten basiert, sondern auf ökonomischen Nutzenskalkülen. Dann legt der Vertrag den Grundstein für den Projekterfolg, und ist nicht länger ein Risiko.

Cornelia Gaebert (2014). Dilemma Structures between Contracting Parties in Software Development Projects Proceedings of the 9th International Conference on Software Engineering and Applications DOI: 10.5220/0004996405390548

Den kompletten Text des Forschungsartikels als PDF finden Sie hier.

Der Beitrag Das Scheitern von Softwareprojekten ist oft schon im Vertrag angelegt erschien zuerst auf INDAL Software-Spezialist.