Das Beste aus einer Software-Demo herausholen

 

Das Transkript lesen:

Wir probieren gerade die Transkription unserer Podcasts mit einem Softwareprogramm aus. Bitte entschuldigen Sie eventuelle Tippfehler – der Bot ist nicht immer zu 100 % korrekt.

Galen Low: Nun, wieder einmal scheitert die Software-Demo eines weiteren Anbieters kläglich. Ihr Technologiedirektor und der DevOps-Leiter spielen anscheinend Buzzword-Bingo mit allen Marketingfloskeln, die der Präsentator erwähnt. Die Augen Ihres Geschäftsführers werden glasig, sobald die Themen zu technisch werden. Und auch wenn die präsentierende Person wirklich Ahnung zu haben scheint, spricht niemand das Offensichtliche an: Dass sie in Wahrheit der Cousin Ihres CEOs ist.

Gibt es keine Möglichkeit, daraus eine bessere Nutzung der Zeit aller zu machen?

Wenn schwache Demos bisher ein Hindernis für Sie waren, eine fundierte Entscheidung über neue Software für Ihre Organisation zu treffen, hören Sie weiter zu.

Wir werden einige der effektivsten Strategien aufzeigen, wie Sie die Demo-Phase Ihres Softwareauswahlprozesses deutlich relevanter für die spezifischen Bedürfnisse Ihrer Organisation gestalten können.

Hallo zusammen, schön dass Sie eingeschaltet haben! Mein Name ist Galen Low vom Digital Project Manager. Wir sind eine Community von Digitalprofis mit der Mission, uns gegenseitig zu fördern, selbstbewusster zu machen und zu vernetzen, damit wir den Wert des Projektmanagements in einer digitalen Welt steigern. Wenn Sie mehr darüber erfahren wollen, besuchen Sie thedigitalprojectmanager.com.

Also gut. Heute sprechen wir über den Prozess, neue Software für Ihre Projektteams auszuwählen, und speziell darüber, wie Sie die Verkaufsshow einer Software-Demo durchschauen und sicherstellen, dass das Tool nicht nur das beste, sondern auch das richtige für die Arbeitsweise Ihrer Teams ist. Bei mir ist heute Olivia Montgomery, Associate Principal Analyst bei Capterra und ehemalige IT-PMO-Leiterin, die nun kleine und mittelständische Unternehmen zur Softwareauswahl berät.

Hallo Olivia!

Olivia Montgomery: Hallo Galen! Danke, dass ich da sein darf.

Galen Low: Es ist großartig, dich wieder in der Sendung zu haben. Wie läuft es bei dir in Austin?

Olivia Montgomery: Hier ist einiges los. South by Southwest findet gerade statt, und es ist das erste Mal wieder in Präsenz seit 2020. Die Stadt ist lebendig, es gibt so viele Veranstaltungen, Vorträge und alles Mögliche. Es ist diese Woche ziemlich aufregend.

Galen Low: Wieder dabei, wieder dabei. South by Southwest, das begeistert mich sehr. Es taucht ständig in meinen Social-Media-Feeds auf. Ich war noch nie in Austin, aber es ist so eine lebendige, musikalische Community. Es passiert so viel, es gibt so viele Konferenzen und Möglichkeiten für Menschen, sich zu treffen und gemeinsam eine gute Zeit zu haben.

Jetzt habe ich also keine Ausrede mehr. Es sieht so aus, als wäre das mein Jahr. Vielleicht ist dies das Jahr, in dem ich es schaffe.

Olivia Montgomery: Und es ist wirklich cool. Es gibt definitiv Tech-Tracks. Ich konnte Talks von Supply-Chain-Führungskräften besuchen, den CEO von Amtrak hören, John Deere ist da und treibt wirklich den Technikfokus voran. Es gibt VR-Erlebnisse, die neue Wege des Storytellings eröffnen, von sehr ernsten Themen bis hin zu leichter Unterhaltung und einfach, wie wir mit Inhalten und miteinander anders interagieren können.

Galen Low: Sehr cool. Was war dein bisheriges Highlight?

Olivia Montgomery: Abgesehen von der ganzen Technik und Innovation habe ich das neue Batmobil in Echt gesehen. Das ist für mich definitiv ein Highlight. Ich bin ein Filmfan. Ich schaue eigentlich keine Trailer, deshalb habe ich auch den Batman-Trailer nicht gesehen und auch den Film noch nicht – wegen South by – aber das Batmobil könne ich erstmals live sehen. Das war echt cool.

Galen Low: Das ist wahrscheinlich besser als ein Trailer.

Olivia Montgomery: Finde ich auch. Jetzt habe ich das Feeling bekommen, bin richtig gespannt auf den Film.

Galen Low: Genau das erwarte ich jetzt, wo wieder mehr möglich ist – die Begegnung mit dem Unerwarteten, Dinge, mit denen du nicht rechnest, stehen plötzlich vor dir.

Klasse. Gut, steigen wir ein.

Lassen Sie uns über die stressigste und zweifelhafteste Phase der Softwareauswahl sprechen – die Demo. Lassen Sie mich die Szene beschreiben.

Angenommen, Sie haben die Aufgabe, ein neues Tool für Ihre Organisation zu finden, ob als Alleinentscheider oder als Leiter des Auswahlgremiums. Sie haben unzählige Stunden in die Erarbeitung von Anwendungsfällen gesteckt, Anforderungen im Team gesammelt, Budgets mit der Führung erarbeitet und viel Recherche betrieben. Endlich haben Sie eine Shortlist mit Tools, die passen könnten, und wollen diese jetzt in Aktion sehen.

Warum ist das so stressig und von Zweifeln geprägt? Weil es die eigentliche Essenz Ihrer bisherigen Arbeit ist. Sie koordinieren alle Stakeholder. Sie versuchen, alle Anforderungen an die Softwareanbieter zu vermitteln. Sie müssen unglaublich viele Informationen aufnehmen und sofort reagieren – und das alles in einer der stressigsten Situationen: einem Meeting.

Deshalb würde ich gerne mit den skeptischen Stimmen beginnen. Sollte sich ein Team oder eine Organisation überhaupt die Mühe einer Demo machen? Ist das nicht nur eine Verkaufsshow?

Olivia Montgomery: Bitte, machen Sie die Demos! Ich verstehe die Skepsis. Ich habe schon jede Menge Demo-Präsentationen gesehen, die sehr vertriebsgetrieben waren. Genau da begannen bei mir die Überlegungen, wie man das besser machen kann. Ich glaube wirklich an den Demo-Prozess, und es liegt vor allem beim Projektmanager, in der Vorbereitung dafür zu sorgen, dass sie eines der wichtigsten Elemente des Auswahlprozesses werden.

Also: Ja zu Demos. Aber es reicht nicht, dem Anbieter einfach zu folgen. Genau da liegen oft die Fehler. Sie müssen als Organisation bestimmen, was sie in der Demo sehen möchten.

Galen Low: Das ist absolut richtig. Diese Tools sind oft sehr komplex und sollen viele unterschiedliche Anforderungen abdecken. Aber ist es überhaupt realistisch, in einer Demo mehr als einen oberflächlichen Blick auf die Standardfunktionen zu werfen? Wie stellt eine Organisation sicher, dass sie wirklich alle Antworten erhält, die sie braucht?

Olivia Montgomery: Sehr gute Fragen.

Zuerst: Nein, Sie können nicht alles in einer Software-Demo abdecken. Das ist der Punkt, an dem Ihre vorherige Recherche – zum Beispiel eine RFP-Phase – wichtig wird. Wenn Sie bei Ihren letzten zwei oder drei Anbietern angekommen sind, lassen Sie sich alle Details in einem Dokument zuschicken. Die Demo ist nicht der Ort, um jede einzelne Funktion zu begutachten.

Konzentrieren Sie sich auf die Benutzeroberfläche und die wichtigsten User Stories, die Ihr Team abbilden muss. Welche Geschäftsprozesse müssen von dem Tool abgedeckt werden? Und: Gefällt den Nutzern die Bedienung? Oft ist das der erste Berührungspunkt mit dem Tool und seiner Oberfläche.

Das Look & Feel ist jetzt entscheidend. Die vollständige Funktionsliste sollten Sie vor Vertragsunterschrift schriftlich haben.

Galen Low: Das ist wichtig und danke für die Aufklärung, denn oft denkt man ja, die Demo wäre der Höhepunkt all der Recherche – aber in Wirklichkeit füllt sie die letzten Lücken.

Es ist eher ein Teil der Recherchephase. Manches muss man erleben, um ein Gefühl dafür zu bekommen, wie du sagst, die Benutzeroberfläche, bestimmte Anwendungsfälle. Es geht nicht darum, alles auf Papier zu lesen und dann innerhalb zweier Stunden jede Funktion zu sehen. Das würde schiefgehen.

Vielmehr: Wir wissen alles Wichtige, haben Details erhalten, und jetzt vereinbaren wir eine Demo, in der wir tief in einige entscheidende Punkte eintauchen.

Olivia Montgomery: Genau. Und ich empfehle tatsächlich, zwei Demos zu vereinbaren.

Eine geschäftsorientierte Demo und eine technische Demo. Beides in einer Sitzung zu kombinieren, würde alles extrem in die Länge ziehen und viele Teilnehmer langweilen sich bei den jeweils fachfremden Aspekten. Deshalb spalten Sie die Demos auf, um die Zeit Ihrer Stakeholder zu respektieren.

Es sollten sowieso unterschiedliche Leute teilnehmen. Es dient der weiteren Überprüfung, aber auch einer Detailerhebung beim Anbieter. Egal, ob Projektmanagement-Tool, Buchhaltungssoftware oder neues ERP – das Grundgerüst der Demo bleibt gleich.

Erstens: Die geschäftsorientierte Demo. Hier ist der Business Owner dabei – das ist naheliegend. Aber auch Ihr Power User darf nicht fehlen, meist ein leitender Mitarbeiter, der das Tool täglich nutzt. So stellen Sie sicher, dass Sie das Tool sowohl unter strategischen als auch unter operativen Gesichtspunkten bewerten.

Der Business Owner prüft, ob das Tool das Unternehmenswachstum unterstützt. Der Power User muss wissen, ob sein Schlüsselprozess abgebildet ist und wie sich das anfühlt. Häufig gelingt es PMs nicht immer, Power User frühzeitig einzubinden, aber gerade diese Nutzer werden das Tool später testen und sind oft die QA-Verantwortlichen in der Implementierung.

Sie liefern die wichtigsten Anforderungen. Das Team muss mit dem Look & Feel zufrieden sein – und dafür ist die Demo da. Deshalb: Beide sollten teilnehmen.

Holen Sie User Stories systematisch vom Team, vor allem vom Power User, und senden Sie diese dem Anbieter Tage vor der Demo zu. So kann der Anbieter genau diese Anwendungsfälle zeigen, zum Beispiel: „Als Buchhalter*in muss ich im Tool den Monatsabschlussbericht in 24 Stunden erstellen können.“ Genau das sollten Sie dann sehen.

User Stories definieren nicht alle Abläufe bis ins Detail – vielleicht hat das Tool innovative Lösungen, die Sie noch gar nicht kennen. Bleiben Sie offen dafür, aber auch bei den Kernfunktionen müssen Sie Klarheit bekommen, vor allem für die Power User.

Geschäftsführer wollen meist das Executive Dashboard sehen. Also: Wie sieht das Tool für mich als Führungskraft aus, wie ziehe ich die Berichte? Bitten Sie den Anbieter, Testdaten in die Demoumgebung zu importieren – so bekommen Sie tatsächlich ein Gefühl für die Reporting-Struktur.

Galen Low: Das gefällt mir, die Idee, die Teilnehmer zu splitten. Oft wirkt Gruppenarbeit im Auswahlprozess logischer, aber zwei Demos führen einfach zu besseren, spezifischeren Gesprächen.

Das spart Zeit und fokussiert auf das Wesentliche. Leute sagen oft: Die Power-User frühzeitig einbinden, das ist noch zu früh – aber genau das ist der strategische Moment, um die späteren Nutzenden einzubinden und den Auswahlprozess mitzugestalten.

Es hilft auch, aus einem Demo-Showcase mit hands-on-Elementen den Power-User zum Fürsprecher zu machen – andernfalls wird er hinterher schnell zum größten Kritiker.

Die Sandbox-Idee ist klasse: Erst Demo, dann ausprobieren. Gibt es auch Hands-on-Demos?

Olivia Montgomery: Viele Power User würden sich das wünschen. Denn die Gefahr ist: Sie kaufen ein Tool, das für den zukünftigen Zielprozess taugt – aber klappt es auch im jetzigen Alltag?

Manchmal sieht eine Demo aus: Unser Prozess wird sich mit dem Tool automatisch weiterentwickeln. Aber das passiert natürlich nicht von heute auf morgen. Der Power User sieht direkt: Kann ich damit heute arbeiten? Geht das wirklich?

Vielleicht hilft es sogar, schon vorab im Sandbox-Modus zu testen, dann weiß der Power User: Das Tool nutze ich von Tag eins an effizient. Für die Techniker ist das weniger spannend, aber wichtig ist: Mit allen Stakeholdern und dem Anbieter offen kommunizieren! Nicht die Demo komplett vom Anbieter steuern lassen – aber dessen Input wertschätzen, vielleicht gibt es ja einen innovativen Ansatz.

Galen Low: Sehr gut. Lassen Sie uns über die Vorbereitung auf diese beiden Demos sprechen: Haben Sie Best Practices für Use Cases, die ein Team abfragen sollte, oder für das Sammeln von User Stories?

Olivia Montgomery: Ja. Falls Sie einen IT-Business-Analysten haben, der alle Anforderungen einsammelt – klasse! Meist ist das aber nicht der Fall. User Stories selbst zu formulieren fällt vielen Power Usern schwer.

Ich versende oft einen Fragebogen – an Power User und Lead-Personen im betroffenen Bereich. Im Mad-Libs-Stil: Ihre User Story lautet: Als ... (Rolle) brauche ich die Möglichkeit, ... (Funktion), damit ... (Ziel). Dieses Ausfüllmuster beschleunigt die Erfassung und ermöglicht die direkte Weitergabe der User Story an den Anbieter.

Galen Low: Das ist eine tolle Methode, offen zu bleiben, und erlaubt dem Anbieter, seinen Lösungsansatz zu zeigen. Gleichzeitig bekommen die Teams Sicherheit, dass der Use Case wirklich unterstützt wird.

Olivia Montgomery: Genau. Das Erscheinungsbild und die Bedienung sind bei der Business-Demo entscheidend. Die zweite Demo ist dann technisch orientiert. Die User Stories betreffen dann etwa: Wie oft laufen diese Jobs? Müssen wir warten? Können Jobs nachts laufen? Welchen Einfluss hat das?

Hier ist die Teilnahme von Tech-Leads und dem technischen Ansprechparter des Anbieters Pflicht. Ihr Systemadmin muss wissen: Wie funktioniert das Tool? Wo werden Daten gespeichert? Hoset der Anbieter sie oder hosten Sie selbst? Welche technischen Details gibt es? Warten Sie mit diesen Gesprächen bis zur Vertragsunterzeichnung, erleben Sie böse Überraschungen.

Fragen Sie: Braucht es Custom Code? Ist die Funktion ab Werk enthalten? Diese Themen kennt Ihr Business Owner oder Power User oft nicht. Auch Sie als Projektmanager nicht immer, sofern Sie kein technischer PM sind. Fragen Sie auch nach Integrationen – gibt es Schnittstellen zu Ihren Tools? Bauen Sie auf, ob das Tool Integrationen mit Ihren spezifischen Anwendungen schon hat. Wenn nicht: Ist das ein K.O.-Kriterium? Wären Sie bereit, eigene Integrationen zu entwickeln? All diese Gespräche sind im Vorfeld wichtig.

Das klingt erstmal nach zu vielen Themen, aber mit guter Vorbereitung bleibt die Demo zielorientiert. Ihre Tech-Teams wissen, was zu fragen ist, und ersparen Ihnen viel Ärger zu einem späteren Zeitpunkt.

Galen Low: Das ist ein ganz wesentlicher Punkt – es gibt so viel zu besprechen, aber wie verhindern wir, dass das Gespräch ausufert? Wie priorisieren Sie Use Cases und Fragen für den Anbieter?

Olivia Montgomery: Da hilft nur: Verlassen Sie sich auf Ihre Teamleiter, Business Leader, Power User. Fragen Sie alle vor der Demo gezielt: Was sind Ihre wichtigsten Anliegen? Was muss unbedingt behandelt werden?

Lassen Sie sie priorisieren. Als PM müssen Sie dann während der Demo darauf achten, dass die wichtigsten Punkte auch vorgeführt werden. Wenn jemand zu sehr ins Detail will: Freundlich lenken. Anbieter sind zwar gut im Zeitmanagement, aber zögern Sie nicht einzugreifen, um an den vereinbarten drei Kernpunkten zu bleiben. Reden Sie im Vorfeld mit allen Teilnehmenden, damit sie wissen, was auf sie zukommt, sich nicht abgeschnitten fühlen und die Richtung verstehen.

Galen Low: Als Projektmanager steuern Sie vieles, aber Entscheidungen liegen auch bei den Sponsoren und Entscheidern. Wichtig ist, gemeinsam mit der Führungsmannschaft die Prioritäten zu definieren. Nutzen Sie Input aller Teams, dokumentieren Sie die User Stories und geben Sie jedem Beteiligten eine Stimme im Prozess.

Olivia Montgomery: Genau. Erklären Sie immer: Im Demo-Termin geht es um die ein bis drei wichtigsten User Stories. Zusätzliche Fragen gehören in die RFP- oder Dokumentationsphase. Nach der Demo sollten Sie eine Kostenaufstellung anfordern: Was kostet Custom Code? Wer baut die geforderte Funktion? Viele Softwarelösungen ermöglichen inzwischen Low Code Workflows, aber das muss klar sein. Wer baut Integration? Wer pflegt den Code? Damit gehen Sie in der Demo nicht zu tief ins Detail und behalten dennoch den Überblick.

Galen Low: Ich möchte auf den Punkt zurückkommen: Zwei Demos, eine geschäfts-, eine IT-orientiert. Aber irgendwann muss alles wieder zusammenkommen. Sollte das gesamte Auswahlkomitee ein Bewertungsschema („Scorecard“) erstellen, um ausgewählte Produkte vergleichbar zu machen? Oder sind Vergleichsrubriken heute angesichts vieler Unterschiede der Produkte überholt?

Olivia Montgomery: Ich bin ein großer Fan von Bewertungsschemata. Die sind absolut noch zeitgemäß. Sie helfen, emotionale Reaktionen aus demospezifischen Verkaufsshows herauszunehmen und sich auf die eigentlichen Anforderungen zu konzentrieren.

Fragen Sie z.B.: Erfüllt die Software unsere geschäftlichen und technischen Anforderungen? Ohne eine Scorecard fehlt eine nachvollziehbare Entscheidungsgrundlage, und sie bietet eine gute Diskussionsbasis. Als PM sollten Sie diese Dokumente auch archivieren – vielleicht werden Projekte auditiert oder es kommen Rückfragen, warum ein Tool gewählt (oder auch nicht gewählt) wurde. Dann hilft die Scorecard zu sehen, dass z.B. eine Integration fehlte und das den Ausschlag gab. Das erleichtert spätere Entscheidungsprozesse enorm.

Ob Sie eine zentrale Scorecard haben oder einzelne Stakeholder individuell ausfüllen, hängt von Größe und Komplexität des Projekts ab.

Es kann auch sein, dass ein neuer CTO fragt: „Warum haben wir das Tool gewählt?“ Dann haben Sie eine fundierte Entscheidungsdokumentation, die Sie vorzeigen können, und das ist bei börsennotierten Unternehmen in Audits sehr hilfreich.

Galen Low: Drei Stichworte möchte ich da herausgreifen. Erstens: Scorecards gelten oft als generisch („UI bewerten von 1 bis 10“), aber eigentlich sollten sie die spezifischen Ziele abbilden. Also: „Wie gut unterstützt das Tool die Integration in unsere Systemlandschaft und automatisiert unsere Prozesse?“ So wird gezielt bewertet.

Olivia Montgomery: Ich halte Scorecards für besser, wenn sie weniger spezifisch, aber klar sind. Beispiel: Skalen von 1 bis 5 statt 1 bis 10, und jede Zahl bekommt klar definiert, was sie bedeutet, etwa „erfüllt Erwartungen“, „erfüllt nicht“, „übertrifft Erwartungen“, oder „nicht vorhanden“ (dann null Punkte).

Galen Low: Stimmt, weniger Stufen bringen oft mehr Klarheit und zwingen zu einer klareren Meinung.

Olivia Montgomery: Absolut, definierte Skalen sind besser. Wichtig ist, dass aus jeder Bewertung klar hervorgeht, wie die Entscheidung zustande kam. Und natürlich auch, dass die Gesamtpunktzahl nachvollziehbar ist – vor allem, wenn Sie Kriterien gewichten.

Galen Low: Und: Es muss nicht immer jede Person nach denselben Kriterien bewerten. Die Tech-Teams nehmen die technischen Features, die Business-Teams andere Aspekte – Hauptsache, alles ist einheitlich über alle Tools hinweg. Stimmen Sie dem zu?

Olivia Montgomery: Genau. Ich empfehle ein Scorecard-Template, das technische und geschäftliche Anforderungen kombiniert, und dabei klar stellt, wer was bewertet. Alle sollten alle Bewertungskriterien sehen, vielleicht ausgegraut bei fachfremden Fragen, aber immer transparent.

Das hilft auch, verschiedene Blickwinkel zu berücksichtigen: Die IT bewertet Integrationen und Cybersicherheit, Geschäftsführung die Dashboards. Unstimmigkeiten regen zur Diskussion an – z. B. Integration ist laut IT ungenügend, Vertrieb wurde aber vom Anbieter versichert, sie sei möglich – allerdings als individuelle Lösung. Das muss besprochen werden, damit Risiken klar werden und die Entscheidung informiert getroffen werden kann.

Eine einheitliche Scorecard fördert den Austausch, involviert alle und verhindert böse Überraschungen im Nachhinein.

Galen Low: Sehr guter Punkt: Beim Scorecard-Einsatz geht es um Gesprächsgrundlagen, nicht nur um Zahlen. Wo gibt es Diskrepanzen, die diskutiert werden müssen?

Für mich wirkt das wie Planning Poker beim agile Estimating: Stimmen auseinander, lasst uns über die Gründe sprechen.

Olivia Montgomery: Genau das ist es. Eine Gesprächsbasis auf Zahlenebene, nicht auf persönlicher Ebene. Das verhindert emotionale Diskussionen.

Galen Low: Lass uns auf das Sammeln und Auswerten der Scorecards eingehen: Welche Tools, Meetings und Abläufe würdest du für das Auswerten und Zusammenführen der Bewertungen nach den Demos empfehlen?

Olivia Montgomery: Das hängt sehr von der Organisation ab. Es gibt kein Patentrezept – jedes Unternehmen ist anders, die Prozesse, die Zeit, das Budget. Als PM brauchen Sie vielfältige Werkzeuge und müssen vorab klären, wer wirklich entscheidet – von Lenkungsausschuss bis zu Einzelpersonen. Diese Klarheit brauchen Sie bereits, bevor Sie Kontakt mit den Anbietern aufnehmen. Das ist entscheidend für die spätere Auswertung.

Galen Low: Ich verstehe: Vorbereitung und Klarheit, wer entscheidet, sind entscheidend. Die Nachvollziehbarkeit der Bewertungsbasis ist ein großer Vorteil.

Meine Erkenntnis: Das ganze Auswahlverfahren lebt von guter Vorbereitung – besonders als PM, der das Ganze orchestriert, von Soft Skills über Datenaufbereitung bis zu Transparenz. Es gilt, die Prioritäten abzubilden, User Stories zu sammeln und im Nachgang an die Demos alle Daten aufzubereiten und zu präsentieren, damit die Entscheidungsträger die finale Wahl treffen können – und Sie eine auditierbare Nachvollziehbarkeit geschaffen haben.

Olivia Montgomery: Genau. Wenn es schwer ist, Scorecards individuell ausfüllen zu lassen, kann man sie auch im Team gemeinsam nach der Demo besprechen und gemeinsam bewerten – das steigert das kollektive Erlebnis und hilft Entscheidern, sich stärker einzubringen.

Galen Low: Gute Idee – es ist eine interaktive Diskussion, keine olympische Jury. Das bringt Leute zusammen und sichert die Akzeptanz der Entscheidung.

Wenn manche sagen: Man kann es nie allen recht machen – wie kann man Erwartungen im Software-Auswahlprozess managen, um Unzufriedenheit zu vermeiden?

Olivia Montgomery: Genau hier punkten Scorecards – speziell, wenn Sie die Kriterien gewichten. Fokussieren Sie auf das WARUM: Nicht das Projekt „Tool X“, sondern das Auswahlprojekt. Erlauben Sie sich, den Bedarf immer wieder in Erinnerung zu rufen, gerade wenn Teammitglieder einfach nur „die Software jetzt wollen“. Fragen Sie: Löst das Tool wirklich unser Problem – unabhängig von schicken Features? Scorecards dienen dabei als emotionsfreie Referenz.

Bringen Sie die Diskussion immer wieder zurück zum Business Need. Manchmal haben Tools besonders fancy Features, aber sie können ein Muss-Kriterium – wie Integration mit dem E-Mail-System – nicht leisten. Dann helfen Scorecard und Priorisierung, die richtigen Entscheidungen zu treffen.

Galen Low: Mein Fazit: Scorecards schaffen Transparenz über den Auswahlprozess – sie sind ein Verwaltungsinstrument, ein Mittel zur Kommunikation an alle Beteiligten, ein Rechenschaftsdokument bei Audits und helfen, im Prozess die Vision immer wieder zu vermitteln.

Offen zurückzumelden, warum die Entscheidung so gefällt wurde, nimmt Frust heraus – ganz vermeiden lässt er sich nicht, aber man sorgt so für breite Akzeptanz und zeigt: Die Wahl war rational nachvollziehbar.

Olivia Montgomery: Genau, es geht um Respekt für die Entscheidung. Nicht jeder muss begeistert sein, aber alle müssen die Entscheidung respektieren können – und das geht am besten mit einem offenen, durchsichtigen Prozess, damit keiner denkt, man hätte „das Tool genommen, weil der Bruder vom CEO dort arbeitet“. Das ist in vielen Unternehmen Realität und Scorecards helfen dabei, dies zu verhindern.

Galen Low: Großartig. Olivia, es ist immer toll, dich im Podcast zu haben. Viele wertvolle Einblicke! Was mich am meisten überzeugt hat: Zwei getrennte Demos für Business und IT – nicht alles in einen Topf werfen, sondern unterschiedliche Perspektiven fördern, dann aber in der Bewertungsgesprächsrunde alle zusammenbringen. Das ist wirklich ein geniales Konzept.

Olivia Montgomery: Genau, Ihr Power User muss nicht dabei sein, wenn Sie über API-Funktionen sprechen, und umgekehrt. Seien Sie respektvoll mit der Zeit der Stakeholder und sorgen Sie dafür, dass Business und IT rechtzeitig zu einer Lösung finden – nicht erst bei der Implementierung.

Galen Low: Noch eine letzte Frage, diesmal eine Fangfrage …

Olivia Montgomery: Noch eine?

Galen Low: Ja, noch eine zum Abschluss.

Angenommen, Sie sind Projektmanager und im Unternehmen wird Softwareauswahl nicht ernst genommen, sondern es soll z. B. „das Tool vom Bruder“ genommen werden. Wie bringen Sie Entscheidungsstrenge in den Prozess? Wie nehmen Sie Einfluss?

Olivia Montgomery: Zuerst: Klären Sie respektvoll, wer verantwortlich ist. Manchmal müssen Sie direkt den Entscheider ansprechen und um Unterstützung bitten. Wenn Sie mit dem Entscheider sprechen: Bauen Sie eine gute Beziehung auf, hören Sie zu und schlagen Sie z.B. vor, gemeinsam eine Scorecard auszufüllen, um systematisch alle Kriterien zu prüfen. Nutzen Sie dabei die sokratische Methode – gemeinsam herausfinden, welche Anforderungen wirklich erfüllt werden (z.B.: Integration?). Schritt für Schritt werden so die Stärken und Schwächen deutlich, und vielleicht stellt sich heraus, dass Ihr Vorschlag trotzdem der beste ist – oder eben nicht. Wichtig ist offene, transparente Kommunikation.

Galen Low: Ausgezeichnet. Danke, Olivia! Das war ein wirklich tiefer Einblick in den Prozess der Softwareauswahl und insbesondere die Demos sowie die Entscheidungsfindung …

Ich hoffe, unsere Zuhörer*innen konnten viel mitnehmen – wir freuen uns auf dein nächstes Mal im Podcast. Es gibt sicher noch viele Themen und Fangfragen von meiner Seite!

Olivia Montgomery: Dankeschön, das hat mir großen Spaß gemacht. Ich hoffe, es war für viele hilfreich und nimmt vielleicht ein wenig die Angst vor dem Demo-Prozess. Herzlichen Dank, Galen – ich spreche sehr gern mit dir.

Danke!

Galen Low: Wie sehen Sie das? Lohnt sich eine Software-Demo für Ihr Team? Oder ist sie mehr eine Illusionsshow, die eine praktische Evaluation umgeht? Schreiben Sie Ihre Gedanken und Erfahrungen unten in die Kommentare.

Wenn Sie Ihre Fähigkeiten als strategische Projektleitung weiterentwickeln wollen, kommen Sie zu unserer Community! Auf thedigitalprojectmanager.com/membership finden Sie eine unterstützende Gemeinschaft, die Wissen teilt, komplexe Herausforderungen löst und gemeinsam die Zukunft unseres Berufs mitgestaltet.

Von praxiserprobten Vorlagen und monatlichen Trainingssessions, die Zeit und Energie sparen, bis zum Erfahrungsaustausch in Foren, Community-Events und Mastermind-Gruppen – als Mitglied stehen Ihnen über tausend Menschen zur Seite für Ihre Karriere im digitalen Projektmanagement.

Wenn Ihnen die heutige Folge gefallen hat, abonnieren Sie unseren Podcast und bleiben Sie in Kontakt auf thedigitalprojectmanager.com.

Bis zum nächsten Mal – danke fürs Zuhören.