Warum ein traditioneller Ausschreibungsprozess nicht mehr zeitgemäß ist

Welches größere Unternehmen bzw. welcher Dienstleister kennt sie nicht, die sog. RFPs. Dabei steht der Begriff als Abkürzung für „Request for Proposal“ und bezeichnet im Softwareauswahlprozess ein Dokument mit inhaltlich bindenden Angaben über Vertragsspezifikationen und weiteren Verhandlungsgegenständen, die vor der Ausarbeitung des eigentlichen Vertragswerkes (Softwareerstellungsvertrag, Lizenzvertrag etc.) definiert werden. In der heutigen Zeit ist eine solche Vorgehensweise aufgrund zunehmender Komplexität und Dynamik nicht mehr zeitgemäß. Wir erläutern warum dies so ist und wie man diesem Umstand begegnen kann.

Bei einem traditionellen Ausschreibungsprozess geht dem RFP meist ein sog. RFI (Request for Information) voraus, in dem unverbindliche Preis- und Leistungslisten möglicher Dienstleister eingeholt werden. Anhand dieser Information kann – zumindest in der Theorie – bereits eine erste Vorauswahl (für den nachfolgenden RFP) vorgenommen werden. Soviel zur Theorie: Hierbei muss jedoch zwingend beachtet werden, dass moderne Softwareentwicklung und hier insbesondere der Bereich eCommerce mitunter einer einer enormen Komplexität und Dynamik unterliegt und ein solch starres Korsett weder für eine Evaluierung noch für die spätere Implementierung zeitgemäß erscheint. Dass dies jedoch nicht nur für Software gilt, beweisst auch das Dilemma des neuen Berliner Flughafens.

Früher verwendete man meist das sog. Wasserfallmodell, bei dem im Rahmen einer umfassende Konzeptphase Lasten- und Pflichtenhefte erstellt wurden, in denen die genauen Anforderungen und Lösungsansätze vorab definiert wurden. Diese Dokumente bildeten dann die Basis für etwaige Verträge, Angebote sowie die finale Umsetzung. Sobald während der Implementierung Änderungen notwendig wurden – was in den überwiegenden Fällen so war/ist und auch vollkommen normal ist – mussten sog. Change-Requests ausgelöst werden, die quasi als Ergänzung zu den bisherigen Dokumenten gesehen wurden und entsprechend berücksichtigt werden mussten. D.h. man hat früher, wissentlich der Tatsache, dass das Endergebnis vermutlich deutlich anders aussehen wird als es die Planungen und Ausarbeitungen im Vorfeld vorgaben, dennoch über viele viele Jahre an diesem Ansatz festgehalten.

Gerade Web-Projekte werden immer komplexer und unterliegen einer immer größeren Dynamik. Zudem sprechen wir hier häufig von Projektlaufzeiten im Bereich von 3 bis 7 Monaten ggf. auch noch deutlich länger. Dies hat zur Folge, dass ein Web-Projekt – selbst nach bestem Wissen und Gewissen – nicht mehr im Detail und im Voraus geplant werden kann. Es werden sich während des Projektes mitunter signifikante Änderungen ergeben, auf die möglichst flexibel reagiert werden muss. So haben mittlerweile immer mehr Unternehmen ein agiles Projektvorgehen für sich entdeckt.

Inzwischen werden Web-Projekte überwiegend agil realisiert, wobei sich hier zwei Ansätze etabliert haben: Scrum und Kanban. Im wesentlichen geht es bei diesen Ansätze darum, ein Projekt nicht mehr im Vorfeld bis ins Detail zu planen, sondern die wesentlichen Anforderungen anhand von sog. Epics mit allen relevanten Stakeholdern (Projektbeteiligten) zu diskutieren, zu erfassen und zu priorisieren. Das Ziel besteht dann darin, möglichst schnell ein erstes lauffähiges Produkt zu implementieren (ein sog. Minimal Viable Product), das dann im weiteren Projektverlauf sukzessive erweitert und ausgebaut wird. Dabei liegt der entscheidende Vorteil von agilem Projektmanagement darin, schneller ans Ziel zu kommen und etwaige Fehlentwicklungen frühzeitig zu erkennen und gegensteuern zu können.

Sofern Sie sich intensiver mit diesem Thema beschäftigen möchten, sei an dieser Stelle auf das TechDivision-Whitepaper „Agiles Projektmanagement“ verwiesen, das unter nachfolgendem Link kostenlos zum Download bereitsteht: www.techdivision.com/projektmanagement-whitepaper

Die Erfahrung der letzten Jahren sowohl auf Kunden als auch Dienstleisterseite hat gezeigt, dass insbesondere eCommerce-Projekte heutzutage eigentlich nur noch agil mit entsprechenden Erfolgsaussichten realisiert werden können. Im übrigen gilt dies mittlerweile nicht nur für eCommerce- oder IT-Projekte. So verwundert es auch nicht, dass gemäß aktuellen Informationen der Autobauer Volkswagen  in den kommenden drei Jahren 150 Scrum Professionals ausbilden sowie 500 Mitarbeiter in der Scrum-Methodik schulen möchte. Diese Entscheidung kommt sicherlich nicht von ungefähr....

Agile Managementmethoden sind erfolgreich(er) und weiter auf dem Vormarsch

Dass agile Projektmanagementverfahren sehr erfolgreich sind und auch immer häufiger zur Anwendung kommen, belegen Ergebnisse einer Studie der Hochschule Koblenz in Zusammenarbeit mit der GPM Deutsche Gesellschaft für Projektmanagement e.V. und der IPMA – International Project Management Association, die im Frühjahr 2014 durchgeführt wurde. An der Studie nahmen 612 Personen aus über 30 Ländern teil, wobei mehr als 60% der Teilnehmer aus Deutschland kamen.

„Eine Verbesserung bei den Ergebnissen und der Effizienz sowie die Verbesserungen im Vergleich zum Aufwand der Einführung agiler Methoden wurden von den Teilnehmern größtenteils positiv beantwortet. Auch in der Eigeneinschätzung der Erfolgsquote der durchgeführten Entwicklungsprozesse haben sich die befragten Anwender agiler Methoden besser bewertet als die Anwender des klassischen Projektmanagements. Die Erfolgsquote der mit agilen Methoden durchgeführten Entwicklungsprozesse lag bei einem Median von 80-89% höher als die Erfolgsquote im klassischen Projektmanagement.“

Der agile Evaluierungsprozess

Was hat dies alles jetzt mit der Ausschreibung und Evaluierung eines eCommerce-Projektes zu tun. Jede Menge, wenn man bedenkt, dass die Implementierung – wie wir gehört haben idealerweise über agile Managementmethoden erfolgen wird – die Ausschreibung und Evaluierung jedoch „klassische“ Bewertungsmaßstäbe und Vorgehensweisen ansetzt, wodurch es zwangsläufig sehr schnell zu Inkompatibilitäten kommen kann bzw. unvermeidlich kommen wird. Was liegt also näher, als auch den Evaluierungsprozess zu „agilisieren“ und mehr Flexibilität und insbesondere Kommunikation anzusetzen. Gerade letzteres ist von entscheidender Bedeutung und die Praxis zeigt es jedes Mal auf Neue: Ein direkter Dialog zwischen Auftraggeber und Dienstleister und sei er auch nur kurz und knackig ist meist deutlich wertvoller als seitenweise Dokumente und Beschreibungen. Das Ergebnis der Weiterentwicklung des Evaluierungsprozesses nennen wir – Trommelwirbel – agilen Evaluierungsprozess.

Die vier Phasen der agilen Software-Evaluierung

Analog zu anderen agilen Managementansätzen besteht auch die agile Software-Evaluierung aus mehrere aufeinanderfolgenden Phasen, die sich wie folgt darstellen:

• Discovery-Phase
• Translation-Phase (User-Stories/Epics)
• Auswahl- und Präsentationsphase
  a) Einreichung der Evaluierungsfragen (max. 8 Anbieter)
  b) Vor-Ort-Präsentation (max. 4 Anbieter)
• Implementierungsphase für Testprojekt (2 Anbieter)

Was es damit im Detail auf sich hat, erläutern wir nachfolgend.

1. Discovery Phase

Zu Beginn ist es von entscheidender Bedeutung sich ein möglichst genaues und umfassendes Bild des Unternehmen, der bestehenden Prozesse, Tools und Probleme sowie der Projektbeteiligten zu verschaffen. Darüberhinaus dient diese Phase dazu, die angedachten Ziele und damit einhergehenden Chancen sowie etwaige Risiken zu beleuchten und mit allen relevanten Parteien zu diskutieren.

Dazu sollte auf Auftraggeberseite zu Beginn ein schlagkräftiges Evaluierungsteam inkl. eines Projektverantwortlichen (PO) gebildet werden. Wichtig ist hierbei, dass alle relevanten Bereiche durch einen Mitarbeiter abgedeckt sind, der zudem auch die dafür notwendige Zeit aufbringen kann und von den Vorgesetzten die notwendige Rückendeckung erhält. Je nach Projektumfang und spezifischen Gegebenheiten kann dieser Aufwand von mehreren Tagen bis hin zu mehreren Wochen reichen. Der eingesetzte Projektverantwortliche sollte sich in der Zukunft idealerweise zum überwiegenden Teil ausschließlich mit dem eCommerce-Projekt beschäftigen und von den ersten, internen Gesprächen an in alle Vorgänge involviert sein.

Typischerweise sollten nachfolgende Abteilungen und Bereiche (sofern vorhanden und relevant) in den Prozess von Beginn an eingebunden werden:

• Projektmanagement
• Marketing
• IT
• Vertrieb
• Design (sofern vorhanden/relevant)
• UX (sofern vorhanden/relevant)
• Kundenservice/Support
• Operations
• ggf. weitere Bereiche

Dies hat zum einen den großen Vorteil, dass die Bereiche und Mitarbeiter frühzeitig abgeholt und in Entscheidungen, die sie später sicherlich auch betreffen werden, eingebunden sind und zum zweiten können hier die notwendigen Informationen sowie das entsprechende Feedback bereichsübergreifend und direkt „an der Basis“ eingesammelt werden. Zudem hat die Praxis gezeigt, dass zwei wesentliche Faktoren Projekte gefährden können:

• Silo-Denken der einzelnen Abteilungen, die nur auf sich und Ihre Anforderungen/Besonderheiten achten. Durch einen offenen und agilen Evaluierungsprozess müssen die involvierten Parteien frühzeitig miteinander sprechen und sich abstimmen.
• Durch bewusstes oder unbewusstes Übergehen von Fachabteilungen fühlen sich diese ausgegrenzt und es wäre nicht das erste Mal, dass Projekte in der Folge dann „boykottiert“ oder zumindest nicht entsprechend supported werden.
•  

Fragen, Fragen, Fragen

Das wichtigste innerhalb der Discovery-Phase sind Fragen. Hierbei gilt die alte Weisheit, dass es keine dummen Fragen gibt, nur dumme Antworten. Hier sollte im Prinzip jeder Stein umgedreht werden und grundsätzlich möglichst viel in Frage gestellt werden. Sie müssen sich für Ihr Unternehmen und eCommerce ernsthaft interessieren. Wenn Sie viele Fragen stellen werden Sie selber immer neugieriger:

• Sie hören dann mehr zu als dass Sie selbst sprechen
• Sie bekommen sehr wertvolle und ungefilterte Informationen
• Sie erhalten einen Blick über den Tellerrand
• Optimalerweise können Sie sich einen ersten Eindruck über das „große Ganze“ verschaffen.

Dabei sollte man sich zuerst auf die grundlegende Philosophie sowie die Ziele des Projektes und nicht bereits vorab auf etwaige Features oder Lösungen stürzen. Darüberhinaus sollten auch im Vorfeld noch keinerlei Architekturentscheidungen getroffen werden, da damit etwaige Lösungsansätze beeinflusst werden können. Beachten Sie hierbei immer: „The more you dictate, the less agile the project is.“

Menschen tendieren sehr häufig dazu, vorschnell eine Lösung zu suchen und anzuwenden. Wenn Sie also bei einem Dienstleister eine Projektanfrage stellen und um eine Demo bitten, wird Ihrem Wunsch in vielen Fällen entsprochen werden – auch wenn diese Vorgehensweise absolut nicht zielführend ist. Der Dienstleister weiß, selbst wenn er von Ihnen Unterlagen erhalten hat, noch nichts bzw. kaum etwas über Sie und Ihre Anforderungen. Die entsprechenden Informationen lassen sich auch meist nicht alleine über einen Fragenbogen, sondern erst im Dialog mit Ihnen beantworten. Ein professioneller Dienstleister wird Sie daher unabhängig von Art und Umfang Ihrer Anfrage erstmal mit Fragen „löchern“.

Wie Sie den richtigen Dienstleister finden können, haben wir bereits in einem ausführlichen Blogbeitrag erläutert. An dieser Stelle sei wieder auf den ersten Eindruck und die ersten Reaktionen und Fragen des Anbieters hingewiesen. Sofern voreilig Entscheidungen getroffen werden – und zwar unabhängig von der Auswahl der Technologie oder dem Dienstleister – kann dies in der Folge massive nachteilige Auswirkungen haben:

• Sie verschwenden unnötig Ressourcen
• Tatsächliche Probleme werden mitgeschleppt und haften an einem Unternehmen über Jahre
• Aktionismus anstatt verbesserter Produktivität
• Es entstehen Anforderungsdokumente mit jeder Menge Wünsche (die häufig nicht zielführend sind)
• Sie werden über kurz oder lang (neue) Probleme bekommen – im schlimmsten Fall jede Menge davon

Discovery Fragen

Die nachfolgenden Fragen sollten Sie zuerst von den Mitgliedern Ihres Evaluierungsteams beantworten lassen und die Ergebnisse dann im Rahmen eines Workshops mit allen Beteiligten diskutieren und priorisieren:

• Was sind Ihre Beweggründe für eine (neue) eCommerce-Plattform? Kunden, Wettbeweber, First-Mover?
• Welche aktuellen Markttrends beeinflussen ihr Business am stärksten?
• Wie verändert sich ihr Business?
• Wie verändert das Internet ihr Business?
• Was würden Sie sich als Kunde von Ihrem Unternehmen wünschen?
• Welche Kanäle nutzen Sie aktuell um Ihre Produkte oder Dienstleistungen zu verkaufen (Internet, Katalog, Direktvertrieb, Partner etc.)
• Wie unterscheiden sich ihre Online-Aktivitäten und -Erfahrungen vom Offline-Bereich?
• Wer sind aktuell ihre Kunden? Welche Kunden sind am profitabelsten?
• Was ist ihr derzeit spannendstes Produkt bzw. Produktlinie? Womit werden die größten Gewinne erzielt?
• Wer sind ihre Hauptkonkurrenten (online und offline)?
• Warum kaufen Kunden bei Ihnen und nicht bei Ihren Konkurrenten und umgekehrt?
• Wie differenzieren Sie sich vom Wettbewerb?
• Was funktioniert in ihrem bestehenden Shop bereits gut und was nicht? (sofern vorhanden)
• Welche Shops sehen Sie als Vorbilder (in ihrem Umfeld und ganz Allgemein)?
• Haben Sie eine internationale Unternehmensstrategie (mehrere Sprachen und mehrere Währungen)?
• Wie sind Sie personell aufgestellt und wo sehen Sie das Online-Business (zukünftig) angesiedelt?
• Wenn Sie sich ihre aktuellen Anforderungen ansehen – beurteilen Sie diese eher als komplex oder eher als Standard?
• Woher kommen ihre Produktdaten aktuell? Sind diese kundenfreundlich aufbereitet und entsprechend verwendbar?
• Welche Online-Marketing-Maßnahmen nutzen Sie aktuell (SEO, SEM, Display, Affiliate, Email etc.)?
• Was muss passieren, dass das Projekt nach Abschluss von Ihnen als erfolgreich bewertet wird? Welche Kriterien sind hier für Sie ausschlaggebend?

Wie finden Sie die Schlüsselthemen und größten Potentiale?

Zum Einstieg sollten die unternehmensweiten Ziele und Vorgaben als Ausgangsbasis genommen und mit den folgenden Fragestellungen gematched werden. Die Beantwortung und Diskussion dieser Fragen sollte dann ebenfalls vom gesamten Projektteam im Rahmen eines Workshops erfolgen:

• Wie stellt sich die aktuelle Situation dar und wie werden etwaige Probleme heute gelöst?
• Wie sollte die Situation durch den Online-Shop zukünftig aussehen?
• Wer sind die primären User / Usergruppen?
• Was bedeutet der geplante Online-Shop für die User (intern und extern)?
• Was bedeutet der geplante Online-Shop für das Unternehmen?
• Was wurde in der Vergangenheit falsch gemacht und wie kann verhindert werden, dass die zukünftig weiterhin passiert? Was sind die größten nicht funktionalen Probleme die zwingend gelöst werden müssen.
• Wie sieht das Projektmanagement in der Praxis aus? Wer hat welche Rolle und Befugnisse?
• Wie viel ist das Projekt dem jeweiligen Bereich in Abhängigkeit der Mehrwerte die damit einhergehen Wert?

Die Discovery-Phase dient also dazu, die Anforderungen und Besonderheiten möglichst aller involvierten Stakeholder zu erfassen und eine „Short-List“ mit potentiellen Dienstleistern zu erstellen. Hier empfiehlt es sich - auch aus Kosten-/Nutzensicht – den Umfang auf max. 8 Dienstleister zu beschränken. Beachten Sie hierzu auch unseren Blogbeitrag mit Tipps zur Auswahl eines passenden Web-Dienstleisters.

2. Translation-Phase (User-Stories/Epics)

Während die Discovery-Phase – wie der Name bereits suggeriert – dazu dient, den Status Quo, das Umfeld und die Besonderheiten sowie die Ziele intensiv zu hinterfragen und mit den einzelnen Stakeholdern abzugleichen, dient die Translation-Phase dazu, die gewonnenen Informationen zu clustern, zu priorisieren, mit den allgemeinen Unternehmenszielen nochmals zu matchen und am Ende dann High-Level User-Stories/Epics für die wichtigsten Bereiche/Anforderungen zu formulieren. In der Praxis hat sich gezeigt, dass auch hier zu detaillierte Vorgaben und zu granular ausgearbeitete User-Stories/Epics nicht notwendig sind bzw. eher kontraproduktiv wirken, da sie die Vorteile und den Charme der agilen Vorgehensweise unterdrücken und Dienstleister ggf. unnötig und frühzeitig in ein Korsett gedrängt bzw. mögliche Lösungsansätze bereits im Vorfeld ausgeklammert werden.

Aus Kosten-/Nutzensicht reicht es unserer Erfahrung nach auch aus, die Anforderungen in sog. Epics zu formulieren, da sich im weiteren Prozess und Dialog häufig – wie dies bei agilem Projektmanagement auch vorgesehen ist - mitunter noch massive Änderungen ergeben können:

User-Story vs. Epic

„Eine User-Story („Anwendererzählung“) ist eine in Alltagssprache formulierte Software-Anforderung. Sie ist bewusst kurz gehalten und umfasst in der Regel nicht mehr als zwei Sätze, in folgender Form: "Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>“. Dabei sollte die User-Story eine Implementierungszeit von 8 Stunden nicht überschreiten. Ggf. muss eine Aufsplitterung erfolgen.

Beispiel: Als Kunde möchte ich ein Konto erstellen können, damit ich meine Käufe des letzten Jahres sehen kann, um mein Budget für nächstes Jahr zu planen.

Unter einem Epic versteht man im Kontext des Anforderungsmanagements die Beschreibung einer Anforderung an eine neue Software auf einer hohen Abstraktionsebene. Die Beschreibung der Anforderung geschieht dabei in der Alltagssprache (analog zu User Stories). Epics dienen dabei zur Entwicklung eines Product Backlogs im Rahmen von Scrum. Sie geben dem Autor die Möglichkeit, zunächst eine aggregierte, grobgranulare Sicht auf neue Produktanforderungen zu entwickeln, ohne auf die Details einer Anforderung eingehen zu müssen.“ (Quelle: Wikipedia) Demnach sind Epics Aufgaben auf Feature-Ebene, die viele User Storys umfassen.

Beispiel: Im obigen Beispiel würde ein Epic möglicherweise das gesamte Kontomanagement-Feature und die Funktion zum Anzeigen vorheriger Käufe umfassen.

Die nachfolgenden Parameter sollten dabei als erste grobe Orientierung für etwaige Epics dienen und stellen lediglich eine Diskussionsgrundlage für ihr Evaluierungsteam dar:

• Startseite
• Kategorieübersichtsseite
• Produktdetailseite
• Suche und Navigation
• Content/Contentmanagement
• Suchmaschinenoptimierung (SEO)
• B2B Login
• Warenkorb
• Checkout
• Kundenkonto
• Marketingtools
• Schnittstellen zu Drittsystemen
• etc.

Um die entsprechenden Epics festzuhalten kann beispielsweise nachfolgende Tabelle verwendet werden, die von jedem Bereich/Stakeholder ausgefüllt und am Ende mit allen Stakeholdern nochmals diskutiert und finalisiert wird:

3. Auswahl- und Präsentationsphase

In die Auswahlphase sollten Sie aus Kosten-/Nutzensicht maximal 8 Anbieter aufnehmen und Sie bitten, die nachfolgenden Agendapunkte 4 und 5 möglichst umfassend zu beantworten. Die grünen Teile werden vom Auftraggeber übernommen.

Darüberhinaus sollten vom Dienstleister die folgenden Punkte bearbeitet und beantwortet werden

• Stellen Sie ihr Unternehmen auf max. 20 Folien mit Historie und etwaigen Besonderheiten (Auszeichnungen etc.) vor.
• Wie sieht Ihre Mitarbeiterstruktur aus? Haben Sie die für dieses Projekt benötigten Skills und Ressourcen? Haben Sie Erfahrung mit vergleichbaren Projekten (Projektumfang und Komplexität)?
• Welche Referenzen können Sie nennen und besteht hier die Möglichkeit eines direkten Kontaktes?
• Wie würde ein mögliches Projektteam aussehen? Wieviel Erfahrung hat dieses Team mit agiler Softwareentwicklung? Wie lange arbeitet das Team bereits zusammen?
• Sie haben von uns bereits entsprechende User-Stories/Epics erhalten. Bitte schätzen Sie hierfür die Story Points. Wie beurteilen Sie die Komplexität des Projektes anhand von Story Points?
• Wie beurteilen Sie die erwartete Velocity des vorgesehenen Teams in Story Points pro Sprint?

Sofern ein Dienstleister Erfahrung mit agiler Softwareentwicklung hat, sollten insbesondere die Fragen Nr. 4 bis 6 relativ problemlos beantwortbar sein. Nach Versand der Ausschreibungsunterlagen sollten vom Dienstleister typischerweise jede Menge Rückfragen – entweder in Form eines standardisierten Fragebogens – oder „freestyle“ zurück kommen. Die Reaktion sowie Art und Umfang der Rückmeldung sollte für Sie bereits als erster Gradmesser für die weitere Auswahl berücksichtigt werden:

• Wie schnell erfolgt eine erste Rückmeldung?
• In welcher Form erfolgt die Rückmeldung (Standard-Email, spezifische Email, Telefonat)?
• Welche grundsätzlichen Fragen werden gestellt? Wie viele Fragen werden gestellt und wie zielgerichtet sind die Fragen?
• Bringt der Dienstleister bereits hier aktiv Vorschläge ein und Ergeben sich aus den ersten Rückmeldungen bereits konkrete Änderungsansätze oder neue Ideen auf Ihrer Seite?
• Wer bzw. welche Mitarbeiter/Positionen werden bei etwaigen Telefonaten auf Dienstleisterseite in die Gespräche involviert?
• Bietet der Dienstleister an, das Projekt und etwaige Fragestellungen im Vorfeld bei einem persönlichen Termin zu besprechen?

Gerade für letzteren Fall sollten Sie sich mit den relevanten Kollegen im eigenen Interesse Zeit nehmen.

Danach sollte der Dienstleister in der Lage sein, eine erste Projektabschätzung in Form eine Kostenkorridors – aufgrund noch fehlender Spezifikationen natürlich auch noch mit entsprechenden Unschärfen – abgeben zu können. Hier sollten Sie zudem darauf achten, dass der Anbieter ggf. noch Annahmen trifft bzw. Erläuterungen zur Schätzung angibt um das Ganze besser verifizieren zu können.

Anhand der erfolgten Vorabgespräche sowie der gelieferten Unterlagen sollten Sie in der Lage sein, vier Anbieter für eine Präsentation bei Ihnen vor Ort auszuwählen. Hierbei empfiehlt es sich, als primäres Entscheidungskriterium jedoch nicht die genannten Aufwände, sondern die Qualität und den Umfang der übersandten Unterlagen sowie die Fragestellungen und das „Feeling“ im Vorfeld heranzuziehen.

Die vier Favoriten präsentieren dann ihre Unterlagen und Vorüberlegungen bei Ihnen vor Ort. Hierzu kommt jetzt etwas, für das Sie „ganz stark sein müssen“ und das Ihnen – während Sie das hier lesen, vermutlich bereits ihr Gesicht erröten lässt. Es wird sich am Ende jedoch auszahlen!

Lassen Sie die Hosen runter!

Vermutlich werden Sie jetzt denken, dass das ja kommen musste, da der Artikel von einem Dienstleister verfasst wurde. Dem kann und will ich auch nicht widersprechen, allerdings führt die Vorgehensweise nachweislich zu besseren Endresultaten. Und jetzt kommt´s: Nennen Sie den vier präsentierenden Unternehmen das Budget auf Dienstleisterseite. Ich erkläre Ihnen auch warum! Wir haben im Vorfeld bereits mehrfach das Thema Transparenz angesprochen und sie wünschen sich vermutlich von einem möglichen Dienstleister auch weitestgehende Transparenz – und zwar zu Recht. Im umgekehrten Fall ist es da doch nur fair und auch absolut zielführend, wenn sie hier „die Hosen runter lassen“ und dem Dienstleister mitteilen, welches Projekt- bzw. Dienstleistungsbudget auf Ihrer Seite eingeplant wurde. Dann wissen alle Beteiligten was Sache ist und können sich entsprechend darauf einstellen. D.h. die Dienstleister können ggf. technischen „Schnick-Schnack“ weglassen und einen pragmatischeren Ansatz wählen oder im umgekehrten Fall die Premium-Lösung mit Rocket-Science anvisieren. Wichtig dabei ist, dass die grundsätzliche Qualität unabhängig von Scope und Komfortgrad der Implementierung gewährleistet wird. Dies kann am zielführendsten durch größtmögliche Transparenz auf beiden Seiten geschehen.

Wenn Sie ein Haus bauen möchten, haben Sie in der Regel auch einen Budgetrahmen vor Augen, innerhalb dessen Ihr Traum vom Eigenheim verwirklicht werden soll und dies ermöglicht es einem Architekten die richtige Größe und die passenden „Features“ einzuplanen. Ein Millionenbudget wird „zwangsläufig“ (und hoffentlich!) zu einem anderen Endergebnis führen als ein Budget von EUR 500.000.-. In beiden Fällen bekommen Sie idealerweise das Optimum für ihr Geld, allerdings jeweils auf einem anderen Level und mit Unterschieden in den Details.

Neben Transparenz ist Vertrauen eine weitere Grundvoraussetzung für eine erfolgreiche Zusammenarbeit (Partnerschaft). Natürlich ist es nicht einfach oder auch kaum machbar, einem unbekannten Dienstleister blind zu vertrauen. Auf der anderen Seite ist es aber doch auch so, dass man mangelndes Vertrauen mit Mißtrauen gleichsetzen kann – dies ist wiederum eine denkbar ungünstige Basis für eine Zusammenarbeit. Dies gilt im übrigen für beiden Seiten, da der Dienstleister auch darauf vertrauen muss, dass etwaige Fehleinschätzungen o.ä. vom Auftraggeber nicht ausgenutzt werden und er am Ende entsprechend entlohnt wird. Wie hieß es in einem früheren Werbespot aus meiner Sicht sehr treffend: „Vertrauen ist der Anfang von Allem!“

WICHTIG: Transparenz, Vertrauen und Fairness reduzieren den administrativen Overhead, was in der Konsequenz bedeutet, dass der Großteil des Budgets auch wirklich für die Implementierung und nicht für vermeintlich „absicherndes Beiwerk“ verwendet wird; die Effizienz im Projekt steigt damit signifikant und das Endergebnis verbessert sich! Wie schafft man es also, eine bessere Basis für entsprechendes Vertrauen zu schaffen? Unser Ansatz: Man startet eine Testphase der Zusammenarbeit!

4. Implementierungsphase

Im Vorfeld wird Ihnen jeder Dienstleister erzählen wie gut und erfolgreich eine Zusammenarbeit laufen wird und welche Projekte und Referenzen in der Vergangenheit erfolgreich implementiert wurde. Dies ist soweit auch vollkommen in Ordnung. Allerdings muss hier einmal mehr gesagt werden, dass jedes Projekt und jeder Kunde anders ist und es hier auf eine Vielzahl von Komponenten ankommt um am Ende erfolgreich zu sein und alle Beteiligten zufrieden zu stellen:

• Die grundsätzliche Chemie zwischen den Beteiligten muss passen.
• Das „Mindset“ (Arbeitsweise und grundlegende Vorstellungen) muss zueinander passen.
• Die Art der Kommunikation und Zusammenarbeit muss funktionieren.
• Es muss eine vergleichbare Augenhöhe gewährleistet werden.
• Ehrlichkeit, Fairness und Transparenz in den relevanten Bereichen muss möglich sein.
• Konstruktive Kritik muss von beiden Seiten akzeptiert werden.
• Man muss lernen, wie der jeweils Andere „tickt“ (Do´s und Dont´s)

=> Es muss ein vertrauensvolles, faires und angenehmens Zusammenarbeiten möglich sein!

Dies alles wird man nicht durch fancy Präsentationen und etwas „Small-Talk“ herausfinden. Die tatsächliche Wahrheit wird erst während der Arbeit zum Vorschein kommen. Insofern empfehlen wir eine testweise Zusammenarbeit der beiden Gewinner aus der Präsentationsphase über einen Zeitraum X. Dabei sollte der Zeitraum nicht zu kurz, aber auch nicht zu lang gewählt werden um möglichst effizient vorgehen zu können, da eine solche, parallele Testphase mit zwei Dienstleister natürlich auch vermehrten Aufwand sowohl auf Zeit- als auch auf Kostenseite bedeutet.

Das Testprojekt

WICHTIG!!! Um hier wirklich eine vernünftige Beurteilungsbasis zu schaffen, ist es aus unserer Erfahrung heraus wichtig, dass dieses Testprojekt „normal“ vergütet wird und hier nicht kostenlose Entwicklungsleistung als in der Regel knappstes und daher wertvollstes Gut vom Dienstleister verlangt wird. Nur so kann auch sichergestellt werden, dass der Dienstleister auch wirklich die entsprechenden Mitarbeiter mit den notwendigen Skills einsetzt bzw. einsetzen kann (und nicht ein „Demo-Team mit den besten Leuten) und nur so kann dann auch eine wirkliche verlässliche Vergleichsgrundlage geschaffen und eine praxisorientierte Bewertung vorgenommen werden. Der Gewinner des Testprojektes erhält dann den Zuschlag für das komplette Projekt sowie ggf. spätere Weiterentwicklungen. Der Verlierer wird für die geleisteten Stunden gemäß vorher vereinbarter Vergütung entlohnt.

Das Testprojekt sollte dabei ein oder mehrere Arbeitspakete bzw. Epics aus dem Backlog enthalten und sich daher bereits mit dem tatsächlichen Projekt beschäftigen um möglichst wenig Waste zu produzieren. Zu Beginn erhalten beide Teilnehmer gleichzeitig ein Backlog mit entsprechenden Aufgaben, das Ihnen vor Beginn des Projekts vom Kunden nochmals detailliert vorgestellt wird. Hierzu muss auch gewährleistet sein, dass genügend Zeit und Ressourcen für etwaige Rückfragen bereitgestellt werden. Nach dem „Briefing“ und der Klärung offener Fragen, wird der Startschuss für die parallele Implementierung gegeben. Als Umfang könnte hier beispielsweise eine klassische bzw. häufig angewendete Sprintlänge von 2 Wochen gewählt werden. Am Ende des Testzeitraums erfolgt dann einzeln die Vorstellung der Implementierung vor dem kompletten Evaluierungsteam.

Ob und inwiefern man sich hier z.B. für eine teilweise Anrechnung der Aufwände oder ein sonstiges „Goodie“ für den späteren Gewinner einigt, bleibt dabei den beiden Verhandlungspartnern überlassen. Es sollte nur gewährleistet werden, dass der Verlierer für die erbrachten Aufwände angemessen entlohnt wird. Auch hier sollte wieder das Thema Ehrlichkeit und Fairness zum tragen kommen.

Rahmenbedingungen

Beim Testprojekt wird ein Dienstleistungsansatz nach Time & Material gewählt. Hierzu kann bzw. sollte im Vorfeld der Umfang (Anzahl Mitarbeiter, Stunden, Stundensatz) sowie die Zahlungsmodalitäten definiert werden. Darüberhinaus sollten Sie sich absichern, was mit den erstellten Implementierungen in beiden Fällen passiert, d.h. wer das Eigentum daran erhält und wie es mit einer etwaigen Weiternutzung aussieht. Ein zentraler Punkt sollte hier aber im Vorfeld noch geklärt und fixiert werden: Das Testprojekt muss zwingend mit dem tatsächlich vorgesehenen Team realisiert werden!

Beurteilung

Zur Beurteilung der beiden Ergebnisse können verschiedenen Parameter und Skills herangezogen werden. Nachfolgend die aus unserer Sicht offensichtlichsten Kriterien:

• Qualität der Implementierung
• Umfang der Implementierung (Basisfaktoren sowie ggf. Begeisterungsfaktoren)
• „Company-Fit“, d.h. wie passt die Chemie zwischen den beiden Unternehmen und den involvierten Personen
• Effizienz und Kosten

Zur skizzierten Vorgehensweise noch ein kleines Rechenbeispiel:

Gehen wir mal davon aus, dass das vorliegende Projekt mit einer initialen Kostenschätzung bzw. einem Budget von EUR 400.000.- belegt wurde und gehen wir weiter davon aus, dass ein Team von 4 Entwicklern an diesem Projekt arbeitet. Wenn wir nun ein Testprojekt über einen Sprint von 2 Wochen ansetzen würde die Rechnung für das Testprojekt unter den genannten Annahmen wie folgt aussehen:

Annahmen

• Stundensatz: EUR 100.-
• Teamgröße: 4 Entwickler, 1 Product Owner
• Arbeitszeit Entwickler: 80%
• Arbeitszeit PO: 50% (auf Kundenseite wird ebenfalls ein Projektverantwortlicher gestellt)
• Wochenarbeitszeit: 40 Std.
• aus Vereinfachungsgründen verzichten wir auf einen Scrum-Master
• Aufwände auf Seiten des Auftraggebers wurden hier ausgeblendet, da entsprechende Aufwände bei jeder vernünftigen Ausschreibung anfallen und die Kosten hierfür bei klassischer Vorgehensweise ggf. auch noch deutlich höher ausfallen können.

Kosten für das Testprojekt: (((4 Entwickler x 8 Std. x 10 Tage) x 0,8) x EUR 100.-) + (((1 PO x 8 Std. x 10 Tagen) x 0,5) x EUR 100.- = EUR 25.600.- + EUR 4.000.- = EUR 25.600.-

Da die Lösung des Gewinnerteams bereits einen ersten Teil des Projektes darstellt, muss „nur“ der Aufwand für das zweite Team, also die errechneten EUR 25.600.- als externe bzw. zusätzliche Kosten für das Testprojekt angesetzt werden. Wenn man jetzt noch nach folgende Fakten heranzieht, kann sich dieses Investment als äußerst sinnvoll darstellen:

• Durch ein überschaubares, einmaliges Investment (in unserem Beispiel in Höhe von lediglich 6,4% der externen Projektkosten) erhält man ein Höchstmaß an Anbietersicherheit (Company-Fit)
• Man verliert keine zusätzliche Zeit, da die Implementierung bereits Teil des Projektes ist.
• Man erhält verlässliche Zahlen und Daten zur Effizienz des Dienstleisters sowie echte Ergebnisse zur Beurteilung der Qualität
• Ggf. erhält man noch wichtige Impulse und Ideen für die weitere Entwicklung
• Das Projektteam kann sich bereits im Vorfeld aufeinander einstellen, einarbeiten und sich besser kennenlernen.
• Durch die Zusammenarbeit kann bereits der erste Schritt für den Aufbau von unbedingt notwendigem Vertrauen erfolgen.
• Im Worst-Case hat man mit dem zweitplatzierten Dienstleister noch einen Plan B in der Hinterhand.
• Durch die Wettbewerbssituation sind beide Anbieter gezwungen (wie auch im späteren Projekt) bestmögliche Leistung abzuliefern.

Wenn man dazu noch berücksichtigt, dass ein nicht unwesentlicher Teil von IT-Projekten aufgrund von falsch gewählter Technologie und/oder Dienstleister scheitert bzw. in Schieflage gerät und dadurch enorme Mehraufwände produziert werden, erscheint der vorgestellte Ansatz noch plausibler und ökonomischer. Sie müssen nur bedenken, was es bedeuten würde wenn in unserem Beispiel erst zur Hälfte des Projektes ersichtlich wird, dass man die falsche(n) Entscheidung(en) getroffen hat. In diesem Fall wären dann möglicherweise bereits EUR 200.000.- investiert worden und es hieße im Worst-Case „zurück auf Los“. Dann wäre nicht nur ein enormer Kostenaufwand enstanden, sondern man hätte zudem massiv Zeit verloren, die sich im schlimmsten Fall zusätzlich negativ auf die weitere Unternehmens-/Umsatzentwicklung auswirken würden. Darüberhinaus müsste man hier sicherlich auch intern zusätzlich die eine oder andere Schramme „kitten“!

=> Am Ende bedeutet dies unter dem Strich Kosteneinsparungen bei gleichzeitiger Risikominimierung! Letzteres gilt zudem für beide Partner, was wiederum auf das Konto „Transparenz, Ehrlichkeit und Fairness“ einzahlt. Einmal mehr ein Invest in eine echte und erfolgsversprechende Partnerschaft!

Fazit

Agile Arbeitsweisen erobern nicht umsonst seit einigen Jahren die Wirtschaft – und zwar nicht nur im IT-Sektor. Die Ansätze agiler Methoden zielen auf eine schnellere Time-to-Market, bessere sowie passendere, flexiblere Lösungen und einen höheren Business Value anstatt auf vorab fest definierte und fixierte Wunschszenarien, die durch hohen administrativen Aufwand und diverse Strafen gesteuert werden. Zu agiler Softwareentwicklung passt am besten auch ein agiler Evaluierungsprozess, der in der Regel deutlich günstiger und praxisorientierter machbar sein wird und bei konsequenter Anwendung auch die besseren/passenderen Ergebnisse bzw. höhere Sicherheit für den Auftraggeber bietet.

Insofern kann dieses Vorgehen nur jedem Unternehmen zur Evaluierung möglicher Software-Lösungen und Dienstleistungspartner nahegelegt werden. Sollten Sie noch Fragen zur vorgestellten Vorgehensweise haben oder Unterstützung bei der Durchführung dieses Prozesses benötigen, stehen wir Ihnen natürlich jederzeit gerne zur Verfügung! An dieser Stelle auch nochmals der Hinweis zu unserem kostenlosen Whitepaper"Agiles-Projektmanagement mit Scrum, Kanban, Management 3.0 & Co.".