10 Tipps, um Softwareprojekte erfolgreich durchzuführen

CINTELLIC begleitet Kunden bei sämtlichen Digitalisierungsinitiativen im CRM Umfeld. Dazu bedarf es einer ausgewogenen Kompetenz in technischen und fachlichen Fragestellungen, um den Mehrwert von Projekten fortlaufend sicherzustellen und Kunden zu ihrem Ziel zu führen. Die Unterstützung von Softwareprojekten ist dabei eine Kernkompetenz, weshalb CINTELLIC sowohl in den Kompetenzaufbau der Berater als auch in strategische Partnerschaften zu Software Vendoren investiert.

• Vorsprung durch Kompetenz: CINTELLIC zertifiziert Berater sowohl im Bereich des Anforderungsmanagement zum Certified Professional for Requirement Engineering (CPRE) als auch im agilen Projektmanagement zum Professional Scrum Master (PSM I). Beide Fähigkeiten werden benötigt, um in agilen Softwareprojekten Anforderungen zu definieren (User Stories), die Abstimmung mit Entwicklerteams zu steuern und die Umsetzungspakete im Rahmen von Tests zu verifizieren. Neben den notwendigen Methodenkenntnissen können CINTELLIC Berater auf ein umfangreiches Referenzprojektportfolio aus unterschiedlichen Branchen zurückgreifen, um beim Kundenprojekt Erfahrungen und Best-Practices einfließen zu lassen.
• Mit Partnern gemeinsam ans Ziel: CINTELLIC setzt von Beginn an auf Kooperationen mit Software Vendoren, die CRM Software Lösungen bieten, die für unsere Kunden relevant sind. Dadurch hat CINTELLIC die Möglichkeit Berater auf modulbezogene Trainings der Vendoren zu schicken und hat zudem Zugriff auf umfangreiches Schulungsmaterial. Dadurch profitieren CINTELLIC Kunden direkt von dem vorhandenen Detailwissen unserer Experten und den verfügbaren Ressourcen vom Software Vendor. CINTELLIC schließt dabei die Lücke zwischen Vendor und Auftraggeber, da unsere Experten tiefgreifende Kenntnisse sowohl vom Vendor als auch vom Auftraggeber mit einbringen und somit Reibungsverluste minimieren.

Softwareprojekte werfen bei Kunden zunächst vor allem zahlreiche Fragen auf, als dass sie schnelle Antworten liefern. Es geht bereits bei der Entscheidung für oder gegen ein Softwareprojekt los. Nachdem Kunden Vertriebsunterlagen zu neuen Modulen oder einem neuen Tool erhalten haben, ggf. waren auch Vertriebsmitarbeiter des jeweiligen Softwareanbieters vor Ort, stellen sich verschiedene Fragen:

• Welchen dieser Versprechungen kann ich wirklich vertrauen?
• Welche der Funktionen bringen mein Geschäft wirklich weiter?
• Welche Ziele möchte ich mit dem Projekt eigentlich erreichen?
• Wie bettet sich die neue Softwarelösung in die Infrastruktur ein?
• Wen muss ich von der Organisation einbinden?
• Wie stelle ich sicher, dass das Projekt auch in-Time und in-Budget durchgeführt werden kann?

CINTELLIC ist darauf spezialisiert genau diese Fragen zu beantworten. In den nachfolgenden Abschnitten erhalten Sie von uns Praxistipps, die Sie verwenden können, um die richtigen Weichen zu stellen.

10 Praxistipps, um erfolgreiche Softwareprojekte durchzuführen

1.Von Beginn an ein Ziele festlegen

Inhalt: Viele Kunden sehen einen Handlungsdruck gegeben und möchten instinktiv zunächst sämtliche Informationen zusammentragen, eine IST Analyse durchführen und im Anschluss entscheiden, was das Ziel einer Initiative sein soll. Es macht allerdings Sinn direkt von Beginn an Ziele zu definieren, die sich weniger auf mögliche Umsetzungsschritte beziehen („Ich brauche ein neues Kampagnen Tool“) sondern vielmehr auf ein strategisches Zielbild („Ich möchte den durchschnittlichen Kundenertrag um 5% steigern“). Basierend auf dieser Zielsetzung wird der Weg dorthin wesentlich klarer und man kann erkennen, dass es neben dem Softwareprojekt vielleicht weitere Maßnahmen gibt, die angegangen werden müssen. Zudem hilft eine Zielsetzung zu Beginn, im Nachhinein den Erfolg des Projektes objektiv bewerten zu können. Wurde das Ziel nicht erreicht, trägt dies zum Lernprozess des Unternehmens bei und man hat die Möglichkeit weitere Maßnahmen zu ergreifen, um die Lücke zu schließen.

Empfehlung: Die Ableitung strategischer Ziele erfolgt immer in Bezug zur Unternehmensvision. Wo möchte Ihr Vorgesetzter, bzw. Ihr Unternehmen im aktuellen Geschäftsjahr hin und welche Initiative würde dazu einen sinnvollen Beitrag leisten?  Wenn Ihre Projektidee diesen Fragen standhält, ist der erste Schritt getan. Basierend auf dem strategischen Ziel – CRM Strategie – können anschließend operative Ziele (bspw. die Einführung eines bestimmten Tools) abgeleitet werden.

2. Stakeholderanalyse durchführen

Inhalt: Sowohl von der Fachseite, als auch von der IT-Seite, müssen entlang des Projektes die richtigen Personen eingebunden werden. Man sollte dabei berücksichtigen, welche Rolle die einzelnen Personen im Projektkontext einnehmen. Typischerweise gibt es

1. 1. 1. Entscheider / das Management
      2. Fachbereiche / Product Owner

• IT Bereiche / Application Owner

Bei den Fach- und IT-Bereichen ist darauf zu achten, welche Personen entweder nur zuliefern, welche direkt in der Umsetzung der Projektmeilensteine involviert sind und welche Personen lediglich fortlaufend informiert werden müssen.

Empfehlung: Es macht Sinn eine Stakeholdermatrix zu pflegen, in der u.a. Name, Position, Bereich (siehe drei Punkte zuvor), Rolle und wichtige Kontaktdaten der jeweiligen Personen aufgenommen werden. Das schafft im Projektverlauf Transparenz und macht für alle Projektteilnehmer die Verantwortlichkeiten eindeutig.

3. Liefergegenstände definieren

Inhalt: In Projekten bestehen viele Abhängigkeiten zu verschiedenen Fach- und IT-Bereichen. Damit Projektmeilensteine erreicht werden können, werden im kompletten Projektverlauf aus diesen Bereichen Liefergegenstände benötigt, damit das Projekt erfolgreich fortschreiten kann. So braucht man bspw. zur Definition der Use Cases ggf. Informationen zu Prozessabläufen vom Fachbereich, zur Erstellung der Testfälle vorhandene Testdaten von der IT oder zur Vorbereitung des Go-Lives Freigaben von beiden Bereichen. Man kann davon ausgehen, dass nicht jedem Projektteilnehmer vollständig bewusst ist, wer was zu welchem Zeitpunkt liefern muss. Dies sollte zu Projektbeginn bereits geklärt werden, um Ressourcenengpässe bei der Umsetzung zu vermeiden und die Einhaltung geplanter Meilensteine sicherzustellen.

Empfehlung: Es empfiehlt sich zumindest auf Bereichsebene (siehe Punkt 2) Liefergegenstände, ggf. im Rahmen der Erstellung der Stakeholder Matrix, aufzulisten. Man kann diese den einzelnen Projektphasen zuordnen, um zusätzlich die zeitliche Komponente mit einzubringen. Es empfiehlt sich zudem vor- und nachgelagerte Abhängigkeiten der Liefergegenstände untereinander zu beschreiben. Vorgelagert: Was muss vorliegen, damit ein Liefergegenstand geliefert werden kann? Nachgelagert: Welche nachgelagerten Schritte benötigen diesen Liefergegenstand?

4. Rahmenbedingungen definieren

Inhalt: In der operativen Umsetzung von Softwareprojekten ist dieser Punkt mitunter der wichtigste! Die Hauptfrage die es hierbei zu beantworten gilt: Was benötige ich in den einzelnen Projektphasen/-schritten, um diese erfolgreich abschließen zu können? Einen Teil der Antwort sollte man bereits aus der Zusammenstellung benötigter Liefergegenstände haben. Allerdings umfasst dieser Punkt mehr. Es geht auch bspw. um Verfügbarkeiten (von Daten, Systemen oder Personen), Freigaben, Prioritäten (auch vom Senior Management!) oder Bedingungen für einen erfolgreichen Go-live.

Empfehlung: Als Ausgangsbasis können hierfür die unterschiedlichen Projektphasen verwendet werden. Als Beispiel: Zieldefinition, Anforderungsdefinition, Testing, Go-live, Einführung. Übergreifend sollten zudem Projekt-, Test- und Change Management Phasen berücksichtigt werden. Die identifizierten Rahmenbedingungen sollten, genau wie die Stakeholdermatrix und Liefergegenstände, in einem Kick-off zum Projektbeginn mit dem Kernteam diskutiert und abgenommen werden.

5. Commitment einholen

Inhalt: Wenn die zuvor genannten Punkte berücksichtigt wurden, sollte sich dieser Punkt von alleine ergeben. Allerdings kommt es trotzdem häufig in Projekten vor, dass von einzelnen Personen oder Bereichen ein Commitment zu Zielsetzungen (was?), Aufgaben (wie?) oder Verantwortlichkeiten (wer?) fehlt. Daraus können erfahrungsgemäß schnell Verzögerungen entstehen, weil nachgelagert Klärungen stattfinden müssen oder umpriorisiert werden muss. Dieser Punkt bezieht sich sowohl auf die Projektsponsoren, die die notwendigen Ressourcen für das Projekt bereitstellen, als auch die Personen, die an der operativen Umsetzung beteiligt sind.

Empfehlung: Ein Commitment muss zu Beginn eines Softwareprojektes eingeholt werden. Hierbei muss aktiv Verantwortungsübernahme eingefordert werden und es dürfen keine Missverständnisse aufkommen! Es empfiehlt sich, in Kick-off Meetings Protokoll zu führen und Entscheidungen zum Vorgehen als diese zu protokollieren und im Anschluss an alle Teilnehmer zu verschicken. Das Protokoll dient dann als Haltepunkt, sollten im Projektverlauf Konflikte in diesem Bereich entstehen.

6. Projektkernteam bilden

Inhalt: Gerade in Softwareprojekten kann aufgrund der Relevanz für zahlreiche Fach- und IT-Bereiche die Stakeholderliste schnell sehr lang werden. Es macht daher Sinn aus den unterschiedlichen Abteilungen, die an der Umsetzung des Projektes beteiligt sind, Hauptansprechpartner zu identifizieren. Idealerweise sind dies Personen, die ein breites fachliches und technisches Verständnis mitbringen (egal ob sie für die Fach- oder IT-Seite arbeiten) und idealerweise ein gewisses Eigeninteresse haben, dass das Projekt erfolgreich umgesetzt wird. Diese können in das Projekt-Kernteam aufgenommen werden und sind sowohl für ihr jeweiliges Team, als auch für das Projekt Single-Point-of-Contact (SPOC). Dadurch werden Informationsflüsse gebündelt und Kommunikationsprobleme reduziert, da der SPOC in beide Teams jeweils ansprachengruppengerecht kommunizieren kann und bei Bedarf notwendigen Kontext ergänzt.

Empfehlung: Besprechen Sie in den Kick-off Meetings wer sich aus den unterschiedlichen Bereichen als SPOC eignet und klären Sie genau die Erwartung an die Involvierung und den notwendigen zeitlichen Invest ab. In jedem Fall sollte der Vorgesetzte der Person mit ins Boot genommen werden. Im Projektverlauf empfiehlt es sich zudem Status Meetings mit dem Kernteam abzuhalten (bspw. wöchentliche Status JF) um das Kernteam auf dem Laufenden zu halten, sodass die SPOCS jeweils Infos an ihr Team durchreichen können.

7. Change Embassador bestimmen

Inhalt: Der Change Embassador kann als Ergänzung zum SPOC definiert werden. Der Change Embassador repräsentiert einen Fachbereich, der vom Softwareprojekt betroffen, allerdings nicht direkt in der Umsetzung involviert ist. In vielen Softwareprojekten werden betroffene Fachbereiche zu Beginn des Projektes im Rahmen der Anforderungsdefinition involviert, bspw. über Interviews, bekommen dann aber über den weiteren Projektverlauf wenig von der Umsetzung mit und können darauf wenig Einfluss nehmen. Wurden Anforderungen falsch interpretiert, fällt dies im schlimmsten Fall erst nach dem Go-live auf. Er kann den Umsetzungsstatus mit seinem Team syndizieren und bei Notwendigkeit noch während dem Projekt gegensteuern. Dadurch wird sichergestellt, dass das Endergebnis tatsächlich den fachlichen Anforderungen entspricht und auch Akzeptanz findet. Der Change Embassador muss nicht in das Kernteam eingebunden werden, er kann aber bspw. bei Change Management Maßnahmen eingebunden werden oder auch gezielte Trainingsmaßnahmen erhalten, um nach dem Go-live als dezentraler Experte für Rückfragen zur Verfügung zu stehen.

Empfehlung: Ähnlich zum SPOC sollte beim Change Embassador darauf geachtet werden, dass dieser ein bereites fachliches und technisches Verständnis mitbringt und dass bei ihm vor allem eine Überzeugung vorliegt, dass das Softwareprojekt sinnstiften ist. Sollte die Identifikation einer geeigneten Person schwierig sein, ist dies ein Indiz dafür, dass bereits früh im Projekt Kommunikationsmaßnahmen für den Fachbereich notwendig sind, um entweder Fragen auszuräumen oder sogar die Projektzielsetzung zu überarbeiten.

8. Realistisch planen

Inhalt: Die Standard Herausforderung jeden Projektes ist es, realistisch zu planen. Bei Software Projekten sind viele unbekannte Variablen im Spiel, die zu einer Verzögerung im Projekt führen können. Im ersten Schritt mach es Sinn, sich für das konkrete Projekt mögliche Stolperfallen zu vergegenwärtigen. Dazu sollte der Kontext betrachtet werden, in dem das Projekt stattfindet und gefragt werden, was hierbei zu Problemen führen kann und wie diese mit in die Planung einkalkuliert werden können. Ein Ansatz:

1. Unternehmen: Jedes Projekt bettet sich neben dem eigentlichen Kerngeschäft des Unternehmens und ggf. weiteren Projekten ein. Werden außerhalb des Projektes Meilensteine geplant, die einen Einfluss haben? Gibt es ggf. Ressourcenkonflikte?
2. Personen: Sind alle notwendigen Kapazitäten zur Projektumsetzung vorhanden? Insbesondere sollte hier berücksichtigt werden, dass möglichst zu jedem Zeitpunkt pro Bereich eine Person verfügbar ist.
3. Projekt: In welchen Projektphasen können Probleme antizipiert werden? Hierzu können kurze Interviews mit den verantwortlichen Bereichen durchgeführt werden, um auf Erfahrungswerte zurückzugreifen. Die kritischsten Phasen sind typischerweise die Testphase und das Produktionsdeployment.

Empfehlung: Planen Sie grundsätzlich die Projektphasen großzügig, sodass Raum für Nacharbeiten bleibt. In der Testphase gibt es häufig Probleme mit der Test Readyness (bspw. wegen fehlenden Daten, Zugängen oder Deployments) und in der Vorbereitung des Go-live (bspw. wegen Differenzen zwischen Test- und Produktionsumgebung oder Firewall Freigaben), planen Sie also insbesondere hier Puffer ein. Zudem gibt es bestimmte Präventivmaßnahmen, um die Sie sich kümmern können. Erstellen Sie bspw. einen Urlaubsplan, um einen Überblick zu haben, ob absehbare Kernressourcenengpässe entstehen werden. Zudem sollte eine Vertretungsregelung gegeben sein, sodass auch bei unabsehbaren Abwesenheiten (bspw. Krankheit) keine signifikante Projektverzögerung entsteht.

9. Demo basiertes Fokusgruppen Feedback

Inhalt: Die Weichenstellung von jedem Projekt findet im Rahmen der Anforderungsdefinition statt. Dokumentierte Anforderungen sind immer eine Interpretation der Aussagen der Anforderer, eine Sicherstellung der fehlerfreien Übernahme kann nur durch wiederholte Feedbackloops sichergestellt werden. In Projekten bricht der Kontakt zu den Anforderern nach der initialen Anforderungsaufnahme häufig ab, was das Risiko stark erhöht nach Fertigstellung der Umsetzungspakete ein unzufriedenstellendes Ergebnis zu haben. Es sollten also über den Projektverlauf verteilt Rücksprachen stattfinden, bspw. mit den Change Embassadors (siehe Punkt 7), um Feedback in den Entwicklungsprozess einfließen lassen zu können.

Empfehlung: Es sollten bereits während er Anforderungsaufnahme mehrere Schleifen mit den Anforderern durchgeführt werden, um die korrekte Aufnahme bzw. Dokumentation der Anforderungspakete sicherzustellen. Ein zusätzliches, sehr sinnvolles Mittel, um im späteren Projektverlauf die korrekte Umsetzung der Anforderungen sicherzustellen, sind Demos erster Software Entwürfe. Vereinbaren Sie dazu mit dem Entwicklerteam im Rahmen der Deployments erster Softwarepakete auf der Testumgebung dedizierte Demo Termine, in denen ein Entwickler dem Projektkernteam und einem oder mehreren Anforderern (ggf. Change Embassador) die Zwischenergebnisse vorstellt. Es muss sich dabei explizit nicht um ein Endergebnis handeln, sondern soll dazu dienen, dass das Endprodukt besser verstanden werden kann und die Entwickler noch in der Entwicklungsphase Feedback erhalten und berücksichtigen können.

10. Kommunikation an “Betroffene”

Inhalt: Der Erfolg eines Softwareprojektes bemisst sich nicht nur nach der Güte der gelieferten Funktionen, sondern vor allem auch durch die Vermarktung der Mehrwerte, die eine neue Lösung mit sich bringt. Ohne Awareness und Akzeptanz bei den Fachbereichen, die am Ende mit der Software arbeiten sollen, bringt die Beste Softwarelösung nichts. Daher ist ein Change Management Konzept mit entsprechenden Kommunikationsmaßnahmen so wichtig, rum relevante Stakeholder während des Projektes mitzunehmen und am Ende des Projektes einen möglichst reibungslose Übernahme der neuen Prozesse zu ermöglichen. In der Regel sind für nicht direkt involvierte Personen Softwareprojekte in erster Linie unangenehm. Entweder kommen neue Prozesse auf die bereits bestehenden hinzu (mehr Arbeit) oder es werden bestehende Prozesse abgelöst (andere Art der Arbeit). In beiden Fällen muss man sich anpassen und hatte am Ende evtl. „keine andere Wahl“. Jeder möchte individuell abgeholt werden, bei den meisten Softwareprojekten ist dies aus Kapazitätsgründen aber schlichtweg nicht leistbar. Zudem kann sich die Erwartungshaltung an eine Softwarelösung stark unterscheiden, deshalb muss unbedingt transportiert werden welche Probleme die Software löst und welche nicht!

Empfehlung: Versetzen Sie sich in die Bedürfnisse und ggf. Sorgen der Nutzer, der neuen Softwarelösung. Befragen Sie dazu einzelne Personen und zeigen Sie dadurch Wertschätzung Mitarbeitern gegenüber, egal wie berechtigt oder scheinbar unberechtigt die Einwände auch sein mögen. Bei den Kommunikationsmaßnahmen sind persönliche Kontaktmöglichkeiten immer zu bevorzugen, bspw. Bereichsmeetings oder zumindest Online Q&A Sitzungen. Unpersönliche Maßnahmen wie E-Mailings oder Intranet Posts helfen strukturiert Informationen zu übermitteln, unterstützen aber nicht den notwendigen Dialog mit den Mitarbeitern. Machen Sie in der Kommunikation zudem klar, wie die Schritte nach dem Go-live aussehen. Werden Schulungen angeboten? Sind weitere Releases mit neuen Funktionen geplant? Für solche und weitere Rückfragen kann man zudem nach Bedarf eine Kontaktstelle (bspw. ein Business Support Postfach) einrichten, an die sich Mitarbeiter wenden können.

Fazit

Mit der richtigen Vorbereitung und dem gewissen Auge für die Stolpersteine eines Softwareprojektes, können die größten Probleme vermieden werden! Wichtig sind hierbei vor allem Verständnis und Einfühlungsvermögen in die involvierten Stakeholder, egal ob Software Vendor, unternehmensinterne IT oder der Fachbereich. Wenn an diesen Schnittstellen die Kommunikation gut funktioniert und alle die gleiche Sprache sprechen, steht dem erfolgreichen Softwareprojekt (fast) nichts mehr im Weg!