Wann und wozu ein externer Business Analyst?

Im klassischen Software-Projekten sind Lastenhefte oder Spezifikationen, sowie das Handbuch für eine erstellte Software Dienstleistungen, die der Software-Hersteller mit anbietet. Lastenhefte und Spezifikationen, weil der Kunde davon ausgeht, dass es sich hierbei um eine beim IT-Dienstleister angesiedelte Kompetenz handelt, und das Handbuch, weil der Dienstleister es in der Regel als Auftragsbestandteil schuldet.

Im agilen Umfeld ist es meistens genauso: Das Entwicklungsunternehmen bringt den Product Owner mit und/oder hat einen Business Analysten im Entwicklungsteam, der die User Stories so aufbereitet, dass sie in den Sprint passen und am Ende ein sinnvolles und werthaltiges Inkrement ergeben.

Wenn der Software-Hersteller nicht nur über IT-Spezialisten, sondern auch über enstprechend kaufmännisch und sprachlich geschulte Consultants (möglichst mit einer Ausbildung zum „Certified Professional for Requirements Engineering“ gemäß IREB® und einer psychologischen und/oder linguistischen Zusatzqualifikation) verfügt, ist diese Vorgehensweise in der Regel auch in Ordnung; wenn eine dieser Kompetenzen fehlt (insbesondere bei kleineren Dienstleistern) können sich Verständigungs- und organisatorische Probleme ergeben.

Weiterhin kann es unter Umständen aus Interessensicht problematisch sein, wenn bei kritischen Projekten der Requirements Engineer, also der Überwacher und „Anwalt“ der Kundenwünsche, aus dem Unternehmen kommt, welches das Projekt umsetzen soll. Hinzu kommt eine gewisse Betriebsblindheit, die dazu führen kann, dass das Projekt unter seinen tatsächlichen Möglichkeiten bleibt. Manchmal sieht ein externer Consultant, der ganz bewusst nichts von der Branche und/oder den verwendeten Technologien versteht, eine Lösung, auf die alle anderen, tief im Projekt steckenden, Beteiligten nicht gekommen wären. Im NLP nennen wir das den „White-Screen-Effekt“.

Häufig ist das aber auch alles bekannt und der gute Wille da – es fehlt einfach nur an der nötigen Ressource, der Manpower, für ein konkretes Projekt – insbesondere wenn die Stakeholderanzahl größer ist und damit der Anspruch an kommunikative und organisatorische Fähigkeiten den Anspruch an technische Skills übersteigt.

Hier springe ich gern ein: Ich verfüge über ein kaufmännisches Studium, einen praktischen Informatik-Hintergrund mit nun 26 Jahren Arbeit in der Branche, Management-Erfahrungen sowie eine Zusatz-Ausbildung in Kommunikations- und Kreativtechniken (NLP-Master-Abschluss).

Bisher habe ich Aufträge für verschiedenste Branchen realisiert, einige Beispiele:

– Facility Management System in einer Bank, mit Migration aus einem Altsystem

– ERP-System für einen geschlossenen Immobilienfonds, mit Anleger- und Vermittlerverwaltung

– ERP-System für einen privaten Postzusteller

– Konzept für eine anbieterneutrale Beratungssoftware für Finanz-Anlageberater

– Benutzerhandbuch für eine Open-Source-Groupware (Tine 2.0)

– Zutrittskontrolle/Gebäudeautomation für Kurzzeit-Wohnen mit Carsharing und anderen added values