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.

In Communities wird geteilt

Communities werden dazu gebildet, etwas zu teilen: Ein Interesse, Wissen, Erfahrungen. Diese Communities sind somit für den Alltag unterstützend, ohne direkt in die tägliche Arbeit einzugreifen. Allerdings wissen gerade Entwickler, welche große Rolle sie heute beim schnellen Finden von Problemlösungen spielen können. Für Organisationen kann es deshalb ein Produktivitätsgewinn sein, den Mitarbeitern die Möglichkeit der Teilnahme an Communities zu geben. Andererseits befürchten manche Unternehmen zu recht, dass Know How abfließen könnte, welches einen Wettbewerbsvorteil darstellt. (Dieses Thema werde ich demnächst bei der Diskussion eines weiteren Papers aus diesem Umfeld aufgreifen).

Eine Ausnahme bilden Communities of Practice, darunter werden diejenigen Strukturen verstanden, die gemeinsam an offenen Systemen arbeiten, etwa an Open Source Projekten.

Allen Communities gemeinsam ist, dass die Mitglieder recht einfach und ohne Zutrittsregeln Mitglied werden können, und dass sie die Community genauso einfach wieder verlassen können. Entscheidungsprozesse sind in einer Community, wenn überhaupt, nur durch die Ausbildung einer impliziten Kultur möglich.

Netzwerke nutzen Technik

Das wichtigste Merkmal eines Netzwerkes ist die Sicherstellung einer gegenseitigen Erreichbarkeit. Tamburri verweist deshalb darauf, dass Netzwerke zumeist an Technologien (E-Mail, Soziale Medien, Kollaborationsplattformen) gebunden sind. Netzwerke bilden letztlich die Infrastruktur für andere kollektive Strukturen. Andererseits, und das ist für die Frage der kollektiven Entscheidungsfindung bedeutsam, erlauben Netzwerke, vorgegebene und definierte Entscheidungswege zu umgehen, Entscheidungsmechanismen, die unserer eigenen Forschung nach die Rationalität der Organisation ausmachen, können durch Netzwerke ausgehebelt werden.

Teams und Gruppen

Die eigentliche Arbeit wird in Teams und Gruppen durchgeführt, diese werden überhaupt zu dem Zwecke gebildet, die Projektarbeit zu organisieren. Tamburri unterscheidet zwischen ihnen: Gruppen werden projektunabhängig und langfristig gebildet, sie bieten den Rahmen, in dem die Arbeit organisiert wird. Abteilungen, aber auch Entwickler- und Testteams können dazu gezählt werden. Das, was Tamburri als Teams, oder Projektteams bezeichnet, sind kollektive Strukturen, die innerhalb des Projekts aus Personen zusammengesetzt werden, die gemeinsam eine bestimmte Aufgabe innerhalb des Projekts lösen sollen.

Entscheidungsfindung und Rationalität

Für unsere Forschung bei INDAL ist diese Klassifikation insofern interessant, dass die verschiedenen kollektiven Strukturen jeweils eine bestimmte Art von Rationalität in der Entscheidungsfindung zeigen, deshalb können sie in der Perspektive der ökonomischen Theorie unterschiedlich als rationale Akteure angesehen werden, für deren Beschreibung und Erklärung ökonomische Theorien herangezogen werden können. Gruppen haben durch ihre langfristige Struktur feste kulturelle regeln der Entscheidungsfindung, die entweder durch Autorität von Führungspersonen oder durch Regelwerke abgesichert sein können. Allerdings kann ihre Rationalität durch Netzwerke, aber auch durch Communities unterlaufen werden. Teams bilden selten eine kollektive Rationalität aus, da sie zu kurzzeitig existieren und die Teilnehmer oft aus unterschiedlichen Kulturen kommen. Ihre Entscheidungen sind deshalb im Sinne der ökonomischen Theorie selten als rational zu betrachten.

Auch für die unmittelbare Unternehmenspraxis können die Ergebnisse sinnvoll genutzt werden, indem auf ihrer Basis eine systematische Analyse der kollektiven Strukturen im Unternehmen und in Projekten durchgeführt wird. Letztlich ist das immer ein Teil der Anforderungsanalyse für komplexe Individualsoftware. Im Ergebnis können Schwachstellen erkannt und Optimierungen in den Entscheidungsstrukturen vorgenommen werden.

Tamburri, D., Lago, P., & Vliet, H. (2013). Organizational social structures for software engineering ACM Computing Surveys, 46 (1), 1-35 DOI: 10.1145/2522968.2522971

Der Beitrag Kollektive Strukturen im Software-Engineering erschien zuerst auf INDAL Software-Spezialist.

Manchmal glaubt man, dass solche Herausforderungen durch eine klare Trennung der Verantwortlichkeiten gelöst werden können. Das ist aber vor allem bei der Erfüllung nicht-funktionaler Anforderungen zumeist nicht der Fall. Beispiel Performance: Ob die Reaktionszeit einer Programmfunktion durch Optimierung der Algorithmen oder durch Aufrüsten der Hardware verbessert werden kann, ist dem Nutzer letztlich egal, demjenigen, der das Projekt finanzieren muss, allerdings vielleicht nicht. Welche Lösung optimal ist, können die Beteiligten nur gemeinsam herausfinden.

Zumeist ist gerade weniger Verantwortungstrennung besser als zu starke Abgrenzung. Am besten ist es, wenn frühzeitig, noch bevor das erste Problem überhaupt auftritt, offen über die Felder gesprochen wird, auf denen es Konflikte geben kann, und Mechanismen vorgesehen werden, nach denen im Fall des Falls gehandelt wird. Regelmäßige Abstimmungs-Meetings werden oft vorab zwar vereinbart, aber so lange alles ganz gut läuft, nicht wahrgenommen. Dabei könnte man gerade in Zeiten der ruhigen See ganz gut darüber sprechen, welche Risiken bestehen könnten, und wie man mit ihnen umgehen will.

Lieferanten neigen manchmal dazu, unterschwellig und in Anspielungen die Kompetenzen und Fähigkeiten anderer Lieferanten gegenüber dem Auftraggeber in Frage zu stellen. Handelt es sich etwa um einen großen Konzern, macht man schon gern mal einen Scherz über mangelnde Flexibilität und bürokratische Entscheidungswege. Gern wird auch durch Nebensätze das Know How des anderen Lieferanten bezweifelt, vor allem dann, wenn es sich um einen Wettbewerber handelt.

Solche Spielchen sind allerdings nie eine gute Idee. Sie schaden vielleicht dem Ansehen des anderen Lieferanten, aber sie nützen nie dem, der sie spielt. Beim Auftraggeber bleibt immer nur der Eindruck zurück, dass er sich auf die Kompetenz seiner Lieferanten nicht verlassen kann und dass er nicht einschätzen kann, wo die Ursachen für Probleme wirklich liegen. Am Ende wächst das Misstrauen im Projekt insgesamt. Besser ist, dass jeder zunächst davon ausgeht, dass alle Projektbeteiligten einen guten Job machen, und dass Schwierigkeiten nur selten in der Unfähigkeit der Anderen, sondern in der Komplexität der Materie begründet sind.

Der Beitrag In einer Dreiecksbeziehung erschien zuerst auf INDAL Software-Spezialist.

Wie viel Zeit etwas braucht im Projekt, das ist eine wichtige Frage, denn Projekte müssen geplant werden, nicht nur hinsichtlich des Datums, zu dem die Lösung einsatzbereit sein wird, sondern auch hinsichtlich des Einsatzes personeller Ressourcen. Wann muss diese Expertin für Interviews zur Verfügung stehen und in welchem Umfang,wann wird jener Spezialist mit seinem Wissen und seinen Fähigkeiten gebraucht und wie lange? Das muss rechtzeitig geplant werden, damit die Menschen dann auch da sind, wenn sie gebraucht werden. Und dazu muss man wissen, wie viel Zeit all die Dinge noch benötigen, die zuvor erledigt werden müssen.

Auch wenn also die Frage, wie lange etwas dauert, vielleicht die wichtigste Frage im Projekt ist, so ist die Antwort darauf häufig entweder ein ehrliches “ich weiß es nicht” oder es stellt sich im Nachhinein heraus, dass sie falsch war. Woran liegt das?

Oft meint man, das es so schwer wäre, in Softwareprojekten Zeitschätzungen abzugeben, weil fast jede Aufgabe einzigartig ist, und jedes Problem sich so, wie es auftaucht, zu ersten Mal gelöst werden muss. Daran ist natürlich viel wahres, und umso individueller eine Lösung ist, desto ungewisser ist, welche Herausforderungen sich auf dem Weg zu ihr zeigen.

Aber aus Erfahrung müssten die Beteiligten eigentlich auch dafür ein Gefühl entwickeln können und das Unvorhersehbare mit einrechnen, sodass sie mit ihren Zeitschätzungen wenigstens “im Mittel” richtig liegen.Warum klappt das nicht?

Das Problem ist, dass wir uns nie merken, wie lange wir wirklich für eine Sache gebraucht haben. Das kann man ausprobieren, wenn man sich einmal für eine ganz alltägliche Sache fragt, wie viel Zeit man dafür benötigt. Wie lange brauche ich etwa für einen Wochenendeinkauf, wie viel Zeit vergeht von dem Moment, wo ich den Einkaufswagen von der Kette vor dem Supermarkt löse bis zu dem Zeitpunkt, an dem ich ihn zurückstelle? Es passiert nicht überraschendes,alle Artikel liegen am richtigen Ort, die Schlange an der Kasse ist nicht länger als sonst. Aber wenn ich die Zeit stoppe, dann staune ich, wie weit meine Schätzung von der tatsächlich benötigten Zeit abweicht.

So ist es auch im Softwareprojekt. Ich weiß oft schlicht nicht, wie lange ich brauche, um eine Funktion zu schreiben. Ich weiß – ehrlich gesagt -im Moment nicht genau, wann ich begonnen habe, an diesem Text zu schreiben, und so kann ich auch nicht sagen, wie viel Zeit er mich gekostet hat.

Erfahrung bauen wir aber nur auf, wenn wir uns beobachten und uns merken, wie lange uns eine Aufgabe in Anspruch nimmt. Wenn ich weiß, wie lange ich beim letzten Mal gebraucht habe,dann kann ich auch beurteilen, wie es beim nächsten Mal sein wird. Prognose fängt beim Selbstversuch an.

Der Beitrag Wie lange dauert das denn? erschien zuerst auf INDAL Software-Spezialist.

Gut ist, wenn die Entwicklungsaufwände, welche in die Software seit ihres Bestehens geflossen sind, bekannt sind, etwa durch die Stundenerfassung in der Softwareentwicklung. Von der Entwicklung der ersten Version sollte der Aufwand für die Anforderungsanalyse separiert werden. Sodann werden die einzelnen Releases sowie die Wartungsaufwände daraufhin bewertet, zu welchem Anteil sie Neuentwicklung von Funktionalität waren und welcher Anteil Änderungen der bestehenden Software waren. So erhält man eine erste Vorstellung davon, was eine Neuentwicklung der gleichen Anforderungen kosten würde.

Dieser Gesamtaufwand ist in Entwicklungsaufwand und Testaufwand zu separieren. Während der Entwicklungsaufwand im Migrationsprojekt durch Wiederverwendung zum Teil erheblich reduziert werden kann, ist der Testaufwand kaum zu reduzieren. Allenfalls bei der Erstellung von Testfällen kann Aufwand gespart werden, wenn auf bestehende Dokumente zurückgegriffen werden kann.

Im nächsten Schritt widmet man sich dem Thema Wiederverwendbarkeit. Wenn die verwendeten Entwicklungswerkzeuge auf der Zielplattform ebenfalls verwendet werden können, kann man beurteilen, ob Teile des Codes (eventuell nach einem Refactoring) wiederverwendet werden können, das gilt nicht nur für Programmiersprachen, sondern auch für Frameworks, Reportingtools u.a.

Im Allgemeinen ist allerdings das Migrationsprojekt mit einem Versionswechsel bei den Werkzeugen verbunden. Wenn man zu dem Ergebnis kommt, dass z.B. 70% des Codes wiederverwendet werden kann, beträgt die tatsächliche Einsparung in der Entwicklung wahrscheinlich weniger als 50%, abhängig von der Weite des Versionssprungs, der Sauberkeit der Architektur und der Codequalität.

Die ursprünglichen Aufwände der Anforderungsanalyse können nicht vollständig abgezogen werden, da während der verschiedenen Releases oft die Anforderungen nur unvollständig dokumentiert und aktualisiert worden sind. Ein intensiver Review ist geboten, und das Motto “Der Code ist die Dokumentation” führt oft zu lückenhafter oder falscher Umsetzung in der neuen Software.

Alles in allem sind die Aufwände für eine Migration oft höher als erwartet. Es ist gut, eine Top-Down-Schätzung, wie hier kurz skizziert, an den Anfang zu stellen, und gegen eine Bottom-Up-Schätzung, die auf einer Stückliste (Object Points, Function Points o.ä.) basiert, zu verproben. Das zeigt frühzeitig nicht nur, welches Budget, sondern auch, welcher Zeitrahmen für die Migration einzuplanen ist.

Der Beitrag Wie kalkuliert man ein Migrationsprojekt? erschien zuerst auf INDAL Software-Spezialist.

Wer Softwareprojekte auch in schwierigem Umfeld zum Erfolg führen will, muss zweierlei klären:

• Wie bemerke ich frühzeitig, dass etwas schief läuft?
• Was ist zu tun, wenn relativ spät gravierende Probleme erkannt werden?

Dummerweise kann man den Fortschritt eines Softwareprojektes nicht sehen wie den Baufortschritt beim Eigenheim. Aus der Menge des erstellten Codes lässt sich selten auf den Fertigstellungsgrad schließen. Erst wenn die Software in den Test geht, fällt auf, dass manches noch fehlt oder nicht richtig funktioniert, dass Anforderungen falsch verstanden wurden oder die Performance der Routinen nicht den Anforderungen des Alltags genügt.

Fortschritt muss man sehen

Eins ist klar: der beste Projektplan nützt nichts, wenn man die Fortschrittsmeldungen der Analysten, Designer und Entwickler nicht nachprüfen kann. Da hilft nur, von Anfang an eine parallele Qualitätskontrolle zu implementieren. Schon die Spezifikations- und Designdokumente können während ihrer Erstellung einem regelmäßigen Review unterzogen werden. Die Qualitätssicherung dieser Dokumente erst kurz vor der geplanten Fertigstellung vorzusehen, führt oft nur dazu, dass sie ganz weggelassen wird und dass in den Entwicklungsprozess dann mit unfertigen Vorgaben gestartet wird. Mancher mag das “agile Entwicklungmethodik” nennen – meist ist es nur ein Zeichen dafür, dass schon am Anfang des Projekts vieles falsch gelaufen ist.

Die Implementierung sollte so geplant werden, dass schon früh Teile des Systems in die Testumgebung ausgeliefert werden können. Darauf ist die Erstellung der Testfallkataloge zu synchronisieren. Entwickelertests müssen nachvollziehbar dokumentiert werden – und im Zweifel sollten sie auch nachvollzogen werden. So kann man zumindest ein Gefühl dafür bekommen, wie es um den Projektfortschritt wirklich bestellt ist.

Kein Vertrauen?

Mancher meint, solche Maßnahmen schaffen eine Atmosphäre des Misstrauens. Aber das Gegenteil ist der Fall. Wenn keine Zwischenergebnisse vorweisbar sind und für Qualitätssicherung und Tests nichts zur Verfügung steht, dann entsteht Misstrauen – zu Recht.

Was aber ist zu tun, wenn Verzögerungen und Qualitätsmängel auftreten, die nicht mehr ausgeglichen werden können, und der Terminplan des Projektes ernsthaft in Gefahr gerät?

Oft meint man, durch erhöhten Ressourceneinsatz (Überstunden, zusätzliches Personal) das Projekt auf Kurs halten, gegensteuern, zu können. So hofft man, irgendwie in der geplanten Zeit doch noch das Projekt zum Erfolg zu bringen. Aber mit den Überstunden steigt die Fehlerquote, die Produktivität sinkt. Und zusätzliche Entwickler verkürzen selten die Entwicklungszeit, wenn sie noch eingearbeitet werden müssen. Außerdem steigt der Koordinationsaufwand.

Gegensteuern oder neuer Kurs?

Gegensteuern bedeutet, das Schiff auf Kurs zu halten, auch wenn die Umstände sich ändern. Das ist lobenswert, kostet aber zusätzliche Kraft und funktioniert immer nur begrenzte Zeit. Frühzeitig muss man sich deshalb fragen, ob ein anderer Kurs gewählt werden sollte, oder ob ein neues Ziel angesteuert werden kann.

Neuer Kurs, das heißt, das Vorgehensmodell im Projekt wird überarbeitet. Getaktetes Liefern von Zwischenergebnissen, Umorganisieren der Teams, das sind mögliche Maßnahmen.

Ein neues Ziel ansteuern, das bedeutet, über Prioritäten bei den Projektzielen zu sprechen. Dazu ist ein offensives Anforderungsmanagement notwendig: Anforderungen müssen von Anfang an zerlegt und unterschiedlich priorisiert werden, Umsetzungsalternativen müssen bekannt und bewertet sein. Dann kann auch während des Projektes noch neu bestimmt werden, was zu welchem Termin auszuliefern ist, damit die Fachseite ihre Geschäftsziele erreicht.

Externe Unterstützung, etwa durch die INDAL-TaskForce, wird in solchen Situationen vor allem gebraucht, um effektiv die Möglichkeiten des Umsteuerns zu prüfen und umzusetzen. Externe Entwicklerressourcen, die dann zusätzlich zum Einsatz kommen können, unterstützen zielgerichtet diese Schritte. Nicht einfach mehr Ressourcen, sondern an den richtigen Stellen die richtigen Kompetenzen, dass ist die Methode, das “Ruder herumzureißen” – So wie bei einer Erkrankung manchmal eben akut nicht mehr Obst und Gemüse, sondern eine kleine Dosis bittere Medizin hilft.

Der Beitrag Das Ruder herumreißen erschien zuerst auf INDAL Software-Spezialist.

Der Beitrag Studie: IT-Projekte in der Krise erschien zuerst auf INDAL Software-Spezialist.

Der Beitrag PodCast: Vertrauen ist nicht der Anfang erschien zuerst auf INDAL Software-Spezialist.

Es muss ja nicht sein, dass man das ganze Unternehmen in einen ständig gepflegten ITSM-konformen Ablauf presst, aber alleine das man mal hingeht und die diversen Systeme/Tätigkeiten eines Unternehmens als Service umdefiniert und mal aus dieser Sichtweise prüft, ob vorhandene Handlungs-, Kommunikations- und Sicherheitsmassnahmen ausreichend sind oder ob mit einem geringen Mehraufwand Risikosituationen besser, schneller und günstiger zu meistern sind.

Also “ständig gepflegt” eher in dem Sinne, dass man z.B. halb-/vierteljährlich einfach mal den Ist-Zustand betrachtet und daraus mögliche Verbesserungen ableitet.

Wikipedia: http://de.wikipedia.org/wiki/IT-Service-Management

Der Beitrag ITSM auch bei KMUs von nutzen erschien zuerst auf INDAL Software-Spezialist.

Es ist nicht immer falsch, auf einen zügigen Abschluss der Konzeptionsphase eines Projektes zu drängen. Allen beteiligten muss aber klar sein, dass das Risiko für Fehlentwicklungen umso großer ist, desto weniger ausgereift die Analyse- und Designdokumente bei Beginn der Implementierung sind.

Die Frage ist, wieviel Risiko das Projekt verträgt. Das ist von verschiedenen Faktoren abhängig. Manche Projekte, die nicht den Kernbereich der Geschäftsprozesse betreffen, und bei denen eine kurzfristige Verschiebung des Produktivstarts oder eine Kostenüberschreitung nicht für das Kerngeschäft des Unternehmens kritisch ist, vertragen ein höheres Risiko, bei anderen muss das Risiko jeder Planungsabweichung extrem minimiert werden.

Nur die nüchterne Risikoabwägung kann zur Festlegung des richtigen Konzeptionsaufwandes führen.

Der Beitrag Risikoabwägung bei begrenztem Analyseaufwand erschien zuerst auf INDAL Software-Spezialist.