Haal het maximale uit een softwaredemo

 

Lees het transcript:

We proberen onze podcasts te transcriberen met behulp van een softwareprogramma. Vergeef ons eventuele typfouten, want de bot heeft het niet altijd voor 100% bij het rechte eind.

Galen Low: Welnu, opnieuw loopt de softwaredemo van een leverancier volledig uit de hand. Je technologiedirecteur en je DevOps-lead lijken buzzwordbingo te spelen met elk stukje marketingjargon dat de presentator noemt. De ogen van je algemeen manager beginnen glazig te worden nu de onderwerpen iets te technisch worden. En hoewel de persoon die presenteert echt lijkt te weten waar hij of zij het over heeft, lijkt niemand de olifant in de kamer aan te spreken: het feit dat die persoon eigenlijk de neef of nicht van jullie CEO is.

Is er geen manier om ieders tijd beter te benutten?

Als middelmatige demo's een obstakel vormen voor het nemen van een goed geïnformeerde beslissing over nieuwe software voor je organisatie, blijf dan luisteren.

We bespreken enkele van de meest effectieve strategieën om de demofase van je softwareselectieproces veel relevanter te maken voor de specifieke behoeften van je organisatie.

Hallo allemaal, bedankt voor het luisteren! Mijn naam is Galen Low van The Digital Project Manager. Wij zijn een community van digitale professionals met als doel elkaar te helpen vaardigheden te ontwikkelen, zelfvertrouwen op te bouwen en verbinding te maken, zodat we de waarde van projectmanagement in een digitale wereld kunnen vergroten. Als je daar meer over wilt horen, ga dan naar thedigitalprojectmanager.com.

Goed, vandaag hebben we het over het proces van het selecteren van nieuwe software voor je projectteams, en specifiek over hoe je door de verkooppresentatie van een softwaredemo heen kunt prikken en ervoor kunt zorgen dat de tool niet alleen de beste tool is, maar ook de juiste tool voor de manier waarop je teams werken. Vandaag bij mij is Olivia Montgomery, Associate Principal Analyst bij Capterra en voormalig IT-PMO-leider, die nu kleine en middelgrote bedrijven adviseert over softwareselectie.

Hallo, Olivia!

Olivia Montgomery: Hoi, Galen! Bedankt voor de uitnodiging.

Galen Low: Het was geweldig om je weer in de show te hebben. Hoe gaat het met je in Austin?

Olivia Montgomery: Het is behoorlijk spannend. South by Southwest vindt plaats en het evenement is weer fysiek sinds, voor het eerst sinds 2020. De stad bruist en er zijn zoveel evenementen, lezingen en allerlei andere dingen gaande. Het is deze week behoorlijk spannend.

Galen Low: We zijn weer begonnen. South by Southwest, ik ben er superenthousiast over. Het staat overal in mijn socialmediafeed en zo. Ik ben nog nooit in Austin geweest, maar het lijkt zo'n levendige, muzikale gemeenschap. Er gebeurt zoveel, er zijn zoveel conferenties en manieren waarop mensen bij elkaar kunnen komen en plezier kunnen hebben.

Dus nu klinkt het alsof ik geen excuses meer heb. Misschien wordt dit het jaar. Misschien wordt dit het jaar.

Olivia Montgomery: Het is echt gaaf. Er zijn absoluut technologietrajecten. Ik heb lezingen kunnen bijwonen van leiders uit de toeleveringsketen, de CEO van Amtrak en John Deere is hier echt bezig met hun technologische focus. Er zijn VR-ervaringen die zich echt richten op verhalen vertellen op nieuwe manieren, van zeer zware, serieuze onderwerpen tot luchtig entertainment, en op de manier waarop we anders met content en elkaar kunnen omgaan.

Galen Low: Heel gaaf. Wat was tot nu toe je favoriet?

Olivia Montgomery: Afgezien van alle daadwerkelijke technologie en innovatie die we zien, heb ik de nieuwe Batmobile in het echt kunnen zien. En ik moet zeggen dat dat voor mij een hoogtepunt was. Ik ben een filmliefhebber. Ik kijk eigenlijk geen trailers, dus ik heb geen enkele trailer gezien. Ik heb Batman nog niet gezien vanwege South by, maar ik heb de Batmobile voor het eerst in het echt gezien. Dat was dus behoorlijk gaaf.

Galen Low: Ik denk dat dat waarschijnlijk beter is dan een trailer.

Olivia Montgomery: Dat denk ik ook. Ik dacht: oké, ik snap het, ik zie de sfeer. Nu heb ik echt zin om de film te zien.

Galen Low: Daar kijk ik ook meer naar uit nu alles weer opengaat, toch? Gewoon onverwachte dingen tegenkomen; de dingen die je niet van plan was te doen, liggen weer voor je.

Geweldig. Goed, laten we erin duiken.

Laten we het hebben over het meest stressvolle en twijfel oproepende onderdeel van het softwareselectieproces: de demo. Laat ik beginnen met het schetsen van de situatie.

Stel dat je de opdracht hebt gekregen om een nieuwe tool voor je organisatie te vinden en dat je óf de enige beslisser bent óf de selectiecommissie voorzit. Je hebt talloze uren besteed aan het vinden van usecases. Je hebt vereisten bij het team opgehaald. Je hebt budgetten vastgesteld met je leidinggevenden en online enorm veel onderzoek gedaan. En eindelijk ben je op een punt gekomen waarop je een shortlist hebt van tools die lijken te voldoen, en nu wil je ze in actie zien.

Waarom is dit dan zo stressvol en twijfel oproepend? Ik denk vooral omdat dit letterlijk het hoogtepunt is van al je inspanningen tot nu toe. Je brengt alle belanghebbenden bij elkaar. Je probeert alle vereisten effectief aan je softwareleveranciers over te brengen. Er wordt van je verwacht dat je enorm veel informatie opneemt en ter plekke reageert, en dat alles vindt plaats in de meest stressvolle omgeving van allemaal: een vergadering.

Dus misschien moeten we, met dat alles in gedachten, beginnen met de tegenargumenten. Moet een team of organisatie überhaupt wel een demo doen? Is het niet gewoon een verkooppraatje?

Olivia Montgomery: Doe alsjeblieft demo's. Ik begrijp het. Ik heb heel wat demo's bijgewoond die zwaar op verkoop waren gericht. Dat was een belangrijke aanleiding voor mij om na te denken over manieren om deze beter te maken. Ik geloof echt in het demoproces en er is veel voorbereiding en werk dat je, vooral als projectmanager, kunt doen om demo's tot een van de belangrijkste onderdelen van het selectieproces te maken.

Dus ja, doe demo's, maar ze zijn niet zo eenvoudig als het volgen van de leiding van de leverancier. Daar kunnen sommige mensen de fout in gaan. Je wilt echt zelf de leiding nemen en in wezen de vereisten bepalen voor wat je tijdens de demo wilt zien.

Galen Low: Ik denk dat dat allemaal eerlijk is. Deze tools hebben ook veel diepgang, toch? Vaak kiezen we een tool om veel verschillende dingen te doen en voor verschillende mensen verschillende functies te vervullen. Maar is het überhaupt mogelijk om tijdens een demo zoveel terrein te bestrijken, in plaats van alleen het oppervlak van de basisfuncties van software te bekijken? Of welke strategieën moet een organisatie overwegen om ervoor te zorgen dat ze de antwoorden krijgen die ze nodig hebben?

Olivia Montgomery: Ja. Goede vragen.

Om te beginnen: nee, je kunt niet alles behandelen in een softwaredemo. Daar komt je eerdere online onderzoek van pas. En als je bijvoorbeeld een RFP-proces uitvoert, of wanneer je bij je laatste twee of drie leveranciers bent aangekomen, laat hen dan al die informatie in een document naar je sturen. De demo is niet de beste plek om alle functionaliteit door te nemen die je nodig hebt.

Je wilt je specifiek richten op hoe de gebruikersinterface eruitziet en op de belangrijkste user stories die je team moet doorlopen. Welke bedrijfsprocessen moeten door deze tool worden ondersteund? En eerlijk gezegd: vinden de gebruikers de manier waarop de tool eruitziet en aanvoelt prettig? Dit kan hun eerste kennismaking met een tool en de interface zijn.

De uitstraling en gebruikservaring zijn hier dus belangrijker. De lijst met daadwerkelijke functionaliteit moet al vóór het ondertekenen van een contract zijn uitgeschreven.

Galen Low: Ik denk dat dat heel belangrijk is. Bedankt daarvoor, want ik stelde het eerder een beetje voor als het hoogtepunt, toch? Alle wegen leiden naar deze demo, maar eigenlijk vult de demo gewoon een aantal hiaten op.

Het is eigenlijk onderdeel van dat onderzoeksproces. Er zijn dingen die je in actie moet zien om er een gevoel bij te krijgen, zoals je zei: de gebruikersinterface, bepaalde usecases. Het wordt niet: ik heb al dit onderzoek gedaan, ik kan al deze dingen, ik heb naar de vergelijkingsgrafiek gekeken en laat me nu elke functie in twee uur zien. Dat zou waarschijnlijk niet goed gaan.

Het is eerder: geweldig, ik denk dat we dit allemaal kennen. We hebben dit allemaal op papier gezien, je hebt aanvullende details naar me gestuurd. Laten we nu een demo plannen waarin we daadwerkelijk op een paar belangrijke zaken kunnen ingaan.

Olivia Montgomery: Precies. Ik raad zelfs sterk aan om twee demo's te plannen.

Ik houd van een demo gericht op de bedrijfsvoering en daarna een technische demo. Als je ze combineert, wordt het een zeer lange, ingewikkelde vergadering. De helft van de belanghebbenden zal niet geïnteresseerd zijn in de technische kant en de andere helft niet in de bedrijfskant. Daarom raad ik aan ze op te splitsen, uit respect voor de tijd van je belanghebbenden.

Je hebt ook verschillende mensen nodig in die vergaderingen. Het zijn niet dezelfde mensen. Ik ben het er dus sterk mee eens dat dit een soort beoordelingsstap is, maar ook nog steeds een moment om aanvullende vereisten bij de leverancier op te halen. Plan er dus twee. We bespreken niet of het om een projectmanagementtool, een boekhoudtool, een nieuw ERP-systeem of welke softwaretool dan ook gaat; ik volg graag ongeveer dezelfde demostructuur.

De eerste is dus gericht op de bedrijfsvoering. Zorg dat de bedrijfseigenaar aanwezig is. Dat is waarschijnlijk wat vanzelfsprekender, maar je wilt ook je power user erbij hebben. Dat is vaak een supervisor, iemand met een leidende rol of de persoon die de tool dagelijks gebruikt. Het doel hiervan is dat je de tool zowel vanuit een strategisch langetermijnperspectief als vanuit het dagelijkse gebruik bekijkt.

De bedrijfseigenaar kan beslissen of deze tool onze groei ondersteunt en past bij de richting waarin we gaan, maar je hebt ook de power user nodig om diens specifieke user story te bekijken. Die persoon wil weten of de belangrijkste functie die hij of zij moet uitvoeren daadwerkelijk kan worden uitgevoerd en hoe dat eruitziet en aanvoelt.

Soms hoor ik van projectmanagers dat ze niet altijd draagvlak krijgen om een power user bij een van de demo's te betrekken. Soms is het te vroeg, soms zijn er allerlei excuses, maar je power users blijven ook bij de rest van het project betrokken. Waarschijnlijk worden zij je QA-persoon tijdens de daadwerkelijke implementatie.

Zij zijn je belangrijkste bron voor gebruikersvereisten. Zij vormen het team dat de tool gaat gebruiken. Ze moeten tevreden zijn met de uitstraling en gebruikservaring, en nogmaals: de demo is vooral een beoordeling van die uitstraling en gebruikservaring. Zorg er dus voor dat beide personen bij die demo aanwezig zijn.

Een andere manier om dit goed voor te bereiden, is het verzamelen van user stories bij het team, waaronder minstens één of twee van die power user, en deze ruim van tevoren naar de leverancier te sturen. Stuur ze minstens enkele dagen vóór de geplande demo's, zodat de leverancier het systeem kan voorbereiden en je precies door die user story kan leiden. Je wilt kunnen zeggen: als accountant moet ik binnen 24 uur het rapport voor de maandafsluiting kunnen uitvoeren, zodat ik de boekhoudmaand kan afsluiten. Je moet dit daadwerkelijk in de tool zien gebeuren.

Een user story betekent niet dat je exact definieert: ik wil deze specifieke functie in de tool zien. Het geeft ruimte aan de mogelijkheid dat deze tool een innovatieve manier heeft gevonden om een functie te bereiken of uit te voeren die je nog niet eerder hebt gezien. Je wilt hen dus niet in een keurslijf dwingen door te zeggen: laat me alleen dit zien. Tegelijkertijd moet je openstaan voor andere mogelijkheden.

In algemene zin moet de power user zijn of haar belangrijkste functie kunnen zien. Ook je bedrijfseigenaren hebben vereisten die ze willen bekijken, meestal het directiedashboard. Hoe ziet dat eruit?

Hoe ziet de tool eruit wanneer ik als manager, leider of CEO inlog? Hoe haal ik mijn rapporten uit mijn dashboard? Ook dat moet je kunnen zien en je moet de leverancier vragen om voorbeeldgegevens voor je in te voeren. Meestal wordt er een sandbox voor je demo ingericht. Laat hen enkele voorbeeldgegevens vooraf laden, zodat je daadwerkelijk een indruk krijgt van de rapportagestructuur.

Galen Low: Dat is echt interessant. Ik vind het idee om de groep op te splitsen geweldig. Het voelt soms contra-intuïtief bij een besluitvormingsproces, maar ik vind het goed dat er twee verschillende demo's zijn, omdat er twee verschillende gesprekken over deze tool moeten worden gevoerd.

En uiteindelijk gaat het om het beste gebruik van ieders tijd. Soms krijgen we weerstand: nee, we willen onze power user van de boekhouding in deze fase nog niet betrekken, want het is te vroeg in het proces. Maar dat is juist onderdeel van het gesprek over het beoordelen van het langetermijngebruik en de diepgang van het gebruik van de tool.

En eerlijk gezegd gaat het ook om het beoordelen van die persoon als power user en mogelijk als voorvechter van het selectieproces, omdat diegene betrokken was en aanwezig was. Als dat niet zo is, kan die persoon uiteindelijk de luidste stem in de kamer zijn die zegt dat het een slechte beslissing was.

Ik vond wat je zei over een sandbox ook goed. Bij sommige softwareselectieprocessen die ik heb meegemaakt, doe je eerst het werk en daarna de demo, waarbij je achteroverleunt en kijkt. Vervolgens zeg je: geef me nu een omgeving waarin ik de dingen die je tijdens de demo hebt laten zien zelf kan uitproberen.

Maar bestaat er ook een situatie waarin mensen tijdens de demo zelf dingen uitproberen in een sandboxomgeving, dus een praktische demo?

Olivia Montgomery: Ik weet zeker dat power users die kans geweldig zouden vinden. Een van de valkuilen is dat je software wilt kiezen die geschikt is voor je huidige processen én voor je toekomstige situatie. Soms richt een demo zich alleen op de toekomstige situatie.

Soms is het idee: zodra we deze tool hebben, zullen onze processen zich drastisch ontwikkelen en automatisch volwassen worden dankzij alle automatisering die we kunnen krijgen. Maar dat is niet de realiteit. Je power user kan weten: hoe ziet het er vanaf dag één uit wanneer we deze tool gebruiken? Voldoet hij aan onze huidige situatie en ondersteunt hij tegelijkertijd onze toekomstige situatie?

Ik denk dus dat toegang tot de sandbox vooraf je power user kan helpen bepalen of deze tool vandaag bruikbaar is en of het werk nog steeds gedaan kan worden. Je wilt de tool niet inschakelen en vervolgens alle functionaliteit verliezen.

Ik weet niet of je technische teams dit zouden waarderen, belangrijk zouden vinden of er de tijd voor zouden hebben. Ik ben er opnieuw een groot voorstander van om heel transparant en open te zijn. Praat met je belanghebbenden en met de leverancier over wat je nodig hebt en welke ideeën zij hebben. Zo prik je door de verkooppresentatie heen door de leverancier niet volledig de demo te laten bepalen, maar je wilt ook openstaan voor het feit dat zij de oplossing kennen.

Misschien hebben ze innovatieve manieren om een probleem aan te pakken waar je zelf nog niet aan had gedacht. Daar moet je ook voor openstaan.

Galen Low: Daar houd ik van. Laten we wat meer praten over de voorbereiding op deze twee demo's. Heb je goede verhalen of voorbeelden van usecases die een team moet vragen om te doorlopen om te controleren of de software daadwerkelijk werkt zoals bedoeld? Of gewoon over het proces van het verzamelen van die user stories? Zoals je zei: op een manier die het niet te veel beperkt.

Het moet niet worden: laat me alleen dit ene ding zien. Als de software het op een andere manier benadert, moet het team daar ook naar kunnen kijken.

Olivia Montgomery: Absoluut. Als je het geluk hebt dat je een IT-bedrijfsanalist hebt die al je vereisten voor je kan verzamelen, is dat geweldig. Dat komt niet vaak voor. En zelfs als je zo iemand hebt, heeft je power user misschien nog nooit eerder een user story of vereiste aangeleverd en heeft die persoon hulp nodig.

Iets wat ik in het verleden heb gedaan en wel prettig vind, is een enquête uitsturen naar het team, de power user en de afdelingsleiders die de tool gaan gebruiken. Ik geef hun een soort structuur in de stijl van Mad Libs. Je user story is: als [functie], heb ik de mogelijkheid nodig om [handeling] uit te voeren, zodat [reden].

Het is al een soort invulverhaal en het helpt hen snel te denken: oké, ik kan deze lege plekken invullen. Het is snel en eenvoudig voor hen. Vervolgens kun je die exacte user story naar de leverancier sturen en zeggen: dit is precies wat ik wil zien.

Ik houd dus wel van een Mad-Libs-aanpak.

Galen Low: Daar ben ik ook dol op. Ik ben een groot fan van Mad Libs en user stories, en hier worden ze gecombineerd. Het is een geweldige manier om ernaar te kijken. Het laat de leverancier ruimte om een demo vorm te geven die laat zien hoe hun software dit zal aanpakken, terwijl het team toch bevestiging krijgt dat de tool dit kan en hoe je dat doet. Heel interessant.

Olivia Montgomery: Het zien en prettig vinden van de uitstraling en gebruikservaring is opnieuw de belangrijkste drijfveer van de bedrijfsgerichte demo. Ik noemde ook de tweede demo, de technisch gerichte demo. Hier kunnen je user stories bijvoorbeeld gaan over hoe vaak bepaalde taken worden uitgevoerd en of je moet wachten.

Kunnen we taken om 1.00 uur 's nachts plannen? Ze worden een uur uitgevoerd. Is dat acceptabel voor de organisatie? Hebben we het vaker of minder vaak nodig? Beschikken we over de mogelijkheden? Hiervoor moeten je technische leads en de technische lead van de leverancier aanwezig zijn.

Je systeembeheerder moet weten hoe deze tool functioneert, net als degene die verantwoordelijk is voor en toezicht houdt op je IT-architectuur. Je engineer moet weten waar de gegevens worden opgeslagen. Host de leverancier ze? Vind je dat goed? Host je ze zelf? Weet je waar? Er zijn zoveel technische details dat je voor onaangename verrassingen kunt komen te staan als je deze gesprekken uitstelt tot het moment waarop je een contract ondertekent.

Dit moet dus onderdeel zijn van het beoordelingsproces. Breng de twee technische teams samen, laat hen hun vragen beantwoorden, toon precies hoe het eruitziet en bespreek de mogelijkheden. Ze kunnen vragen: vereist dit maatwerkcode? Zit deze functionaliteit standaard in het product?

Dit zijn vragen waarop je bedrijfseigenaar en power user geen antwoord zullen hebben. En soms weet je het als projectmanager, tenzij je een technisch projectmanager bent, ook niet. Je moet deze vragen dus stellen. Je wilt ook meer weten over integraties. Vraag of bestaande klanten van de leverancier een integratie hebben met X en Y, jouw specifieke tools.

Wees niet bang om de tools die je gebruikt bij naam te noemen en te vragen of ze momenteel integraties met deze tools hebben. Bij een groot, bekend bedrijf lijkt dat misschien vanzelfsprekend, maar soms moet je wat meer doorvragen. Bij kleinere bedrijven wil je dit zeker weten.

Als ze geen bestaande of standaardintegratie hebben, is dat dan een dealbreaker voor jou? Je moet weten of je deze aangepaste integratie zelf moet bouwen, of je daar de middelen voor hebt, of de leverancier het voor je wil doen en of je de tijd hebt. Al dit soort gesprekken kunnen dan worden gevoerd.

Het klinkt misschien alsof het een te uitgebreid gesprek wordt, maar dat is echt niet zo als je je goed hebt voorbereid. Je technische teams weten wat ze moeten vragen. Je bespaart jezelf een hoop problemen als je dit niet langer uitstelt.

Galen Low: Dat is een enorm belangrijk punt. Er is zoveel om te behandelen. Het kan een uitgebreid gesprek worden. We willen ons richten op bepaalde usecases, maar zelfs een stuk software zoals een CRM- of ERP-systeem of een contentmanagementsysteem moet voor die usecases veel verschillende dingen kunnen doen. Dat kost tijd om te demonstreren en te bespreken.

Hoe selecteer en prioriteer je de usecases en vragen die je door de leverancier wilt laten behandelen, zonder dat het gesprek te uitgebreid wordt?

Olivia Montgomery: Dit is een enorme vraag. Je moet vertrouwen op je teamleiders, bedrijfsleiders en power user. Praat vóór de demo met hen en vraag: wat zijn je belangrijkste zorgen? Wat moeten we absoluut behandelen?

Laat hen vertellen wat het belangrijkst is. Als je een zeer technische projectmanager bent, kun je die gesprekken zelf sturen, en dat is geweldig. Maar dat zijn velen van ons niet. Vertrouw dus op hen en vraag: wat zijn de twee of drie dingen die je moet zien?

Zorg er vervolgens voor dat je die tijdens de daadwerkelijke demo behandelt en op koers blijft. Je moet tijdens de demo namelijk ook faciliteren. Als iemand te diep op iets ingaat, kun je zeggen: ik wil zeker weten dat we deze drie punten behandelen. Leveranciers zijn doorgaans goed in tijdmanagement, omdat ze veel demo's van hun producten hebben gedaan.

Maar wees ook niet bang om in te grijpen en te zeggen: ik wil zeker weten dat we deze drie punten behandelen. Om dat te laten werken, moet je vooraf met de mensen die bij de demo aanwezig zullen zijn bespreken wat de drie punten zijn. Zo worden ze niet verrast en voelen ze zich niet afgesneden, onderbroken of afgewezen. Ze weten dan: oké, we gaan terug naar het afgesproken onderwerp.

Galen Low: Ik denk dat dit een heel belangrijk punt is. In de rol van projectmanager, wanneer je dit proces beheert, zijn er gebieden waar je controle over hebt en waarvoor je verantwoordelijk bent om ze op te zetten.

Maar sommige beslissingen liggen echt bij anderen, ook bij een softwareselectieproject. Je hebt je sponsor en de besluitvormers, zoals je zei: het leiderschapsteam. We moeten op dat besluitvormingsproces vertrouwen, zodat dat team prioriteert wat we uit een demo willen halen en er tegelijkertijd een proces blijft om input te verzamelen van alle verschillende teams die de tool mogelijk moeten gebruiken.

Zo kunnen zij hun invulverhaal aanvullen, hun usecase vastleggen en documenteren en uiteindelijk een stem in het proces hebben.

Olivia Montgomery: Precies. Je kunt mensen er ook altijd aan herinneren dat je tijdens de demo de drie of misschien vier zeer gerichte user stories probeert te behandelen die je aan de leverancier hebt voorgelegd, zodat die weet wat er moet worden voorbereid.

Alles daarbuiten kun je in je RFP of een ander document laten uitschrijven. Je kunt altijd zeggen: we hebben hiervan documentatie nodig. Wat kost dat? Je wilt na de demo ook van de leverancier een uitsplitsing krijgen van wat maatwerkcode is.

Je hebt om specifieke functionaliteit gevraagd. Dit is hoeveel het volgens ons kost. Wij bouwen het voor je, of je moet het zelf doen. Je moet weten of zij het moeten schrijven of dat jij het moet doen. Hetzelfde geldt voor integraties. Om tijdens de demo niet te veel in details te verzanden, herinner je iedereen eraan dat de details in de documentatie moeten komen en ga je verder met het daadwerkelijk bekijken van de software.

Galen Low: Dat vind ik goed. Ik wil terugkomen op het idee dat we de groep hebben opgesplitst. We hebben gezegd: organiseer twee demo's. De ene is meer op de bedrijfsvoering gericht, met je power user erbij en aandacht voor de gebruikersinterface. De andere is meer op IT gericht, met gesprekken over infrastructuur, integraties, cronjobs en planning die op de achtergrond moet worden uitgevoerd.

Maar op een bepaald moment moet dit weer bij elkaar komen. De verschillende groepen voeren gesprekken en beoordelen op basis van verschillende onderwerpen. Moet de volledige selectiecommissie een soort scorecard opstellen, zodat ze appels met appels kunnen vergelijken tussen de producten op de shortlist? Een manier om hun gedachten te documenteren, zodat ze die later als groep kunnen bespreken en hun meningen en gevoelens over de software kunnen kwantificeren en beoordelen?

Of is dat misschien een verouderde manier om ernaar te kijken? Producten en software zijn tegenwoordig zo verschillend. Sommige zijn misschien te complex om met een rubric te vergelijken. Wat vind jij daarvan?

Olivia Montgomery: Ik ben blij dat je over leveranciersscorecards begint. Ik ben er een groot voorstander van. Ze zijn absoluut nog steeds relevant. Telkens wanneer je emotionele reacties kunt verminderen, wat een valkuil is bij demo's die zwaar op verkoop zijn gericht, is dat nuttig. Je moet emoties buiten beschouwing kunnen laten en onthouden waarom je in eerste instantie software nodig hebt.

Het helpt je te zeggen: dit is het probleem dat we oplossen. Als je dat hebt uitgeschreven, kun je vergelijken hoe elke leverancier scoort. Je denkt misschien: deze leverancier was echt goed. Maar wanneer je terugkomt bij je scorecard met vragen als of de functionaliteit aan onze behoeften voldoet, kun je de bedrijfs- en technische kant vergelijken. Als de tool niet aan beide voldoet, is het geen goede keuze.

Zelfs als je bedrijfseigenaar van één bepaalde tool houdt om een emotionele reden, heb je zonder scorecard of gestandaardiseerde rubric geen spoor van hoe je de beslissing hebt genomen. Scorecards zijn nuttig tijdens besluitvormingsgesprekken. Als projectmanager raad ik ook sterk aan om ze elke keer op te slaan, omdat je nooit weet wanneer het project wordt gecontroleerd.

Je weet nooit wanneer mensen vragen gaan stellen. Misschien willen ze de software over een paar jaar vervangen. Dan wil je kunnen weten waarom je destijds niet voor deze leverancier hebt gekozen. Misschien scoorde die leverancier een één op de integratieschaal.

Wanneer je later opnieuw met hen praat, kun je vragen of ze die integraties inmiddels hebben gebouwd. Dan heb je een geïnformeerd en goed onderbouwd besluitvormingsproces. Ik steun, onderschrijf en waardeer leveranciersscorecards volledig. Ze zijn een manier om verspreide informatie bij elkaar te brengen, zodat iedereen elkaars scores kan zien.

Of je nu één grote leveranciersscorecard gebruikt of elke belangrijke belanghebbende er één laat invullen en ze daarna samenvoegt, hangt af van de omvang van je bedrijf en de complexiteit van het systeem. Voor een projectmanagementtool laat je waarschijnlijk verschillende leiders hun eigen scorecard invullen.

Daarna breng je ze als projectmanager samen en sla je ze op. Dat is belangrijk, want je weet nooit wanneer je ze nodig hebt. Ik heb dit zelf meegemaakt. Ik werkte bij een bedrijf waar onze CTO kort na de implementatie van een nieuw ERP-systeem veranderde. Ze wilde natuurlijk weten waarom we deze tool gebruikten en hoe we deze leverancier hadden gekozen.

Welke emotionele reactie ze ook had, ik kon aantonen dat we een geïnformeerde en goed onderbouwde beslissing hadden genomen. Dat helpt niet alleen bij het opbouwen van een relatie met de nieuwe belanghebbende, maar helpt die persoon ook de organisatie te begrijpen.

Als je voor een beursgenoteerd bedrijf werkt, zullen auditors bovendien willen weten dat je niet zomaar zaken hebt gedaan met het softwarebedrijf van je broer. Ze moeten kunnen zien dat je de beslissing op een afgewogen en gestandaardiseerde manier hebt genomen.

Galen Low: Er zijn drie dingen die ik uit je antwoord wil halen. Ten eerste denk ik dat sommige mensen een leveranciersscorecard zien als iets heel algemeens: een score voor de gebruikersinterface op een schaal van één tot tien.

Dat kan nuttig zijn, maar volgens mij zeg je dat je specifieker moet zijn. Wat probeer je te bereiken? Waarom koop je nieuwe software? Dat is de rubric. In welke mate helpt deze tool ons bijvoorbeeld om aan te sluiten op de rest van ons software-ecosysteem en geïntegreerde, gestroomlijnde en geautomatiseerde processen te creëren?

Olivia Montgomery: Ik houd er eigenlijk van als leveranciersscorecards iets minder specifiek zijn. Een schaal van één tot tien kan veel zijn. Ik raad meestal aan om die terug te brengen naar één tot vijf en vast te leggen wat elke score betekent.

Een score van één kan bijvoorbeeld betekenen dat de tool niet aan de verwachtingen voldoet, een drie dat hij aan de verwachtingen voldoet en een vijf dat hij de verwachtingen overtreft. Of de functionaliteit is helemaal niet aanwezig; dan geef je een nul.

Galen Low: Niet aanwezig. Ja.

Olivia Montgomery: Ik gebruik dus graag één tot vijf. Dat is iets duidelijker. Je dwingt mensen om duidelijker te zijn in hun antwoord. De berekening wordt eenvoudiger, vooral als je de criteria afzonderlijk weegt.

Galen Low: Dat vind ik goed. Ik denk aan al die enquêtes met een net promoter score die ik krijg: hoe waarschijnlijk is het dat je deze tool aan een vriend aanbeveelt, van nul tot tien? Dan vraag ik me af wat een zeven precies betekent.

Olivia Montgomery: Precies. Als je het leuk vindt, kies je zeven. Als je het niet leuk vindt, kies je drie. Dat doet iedereen. Dat is niet echt nuttig.

Met één tot vijf vereenvoudig je het en dwing je mensen een kant te kiezen en die keuze te definiëren. Of je nu een tool, papier of spreadsheet gebruikt, laat precies weten wat elke score betekent. Je kunt het eenvoudig houden: voldoet aan de verwachtingen, voldoet niet aan de verwachtingen of overtreft de verwachtingen.

Galen Low: Ik vind dat goed. Het andere dat ik hoor, is dat we verschillende gesprekken voeren omdat we de groep hebben opgesplitst.

Veel mensen zien een scorecard als iets algemeens en als een appels-met-appelsituatie, waarbij iedereen die helpt bij de beslissing dezelfde criteria gebruikt om software te beoordelen.

Maar misschien heeft niet iedereen exact dezelfde scorecard. Misschien gebruikt iedereen een consistente scorecard voor zichzelf bij verschillende softwareproducten die hij of zij beoordeelt. Bedoel je dat? En vind je dat een goed idee? Zo kunnen de technische IT-teams beoordelen op basis van technische criteria en het bedrijfsgerichte team op basis van bedrijfscriteria.

Zolang iedereen de tools op dezelfde manier beoordeelt, kunnen ze het gesprek aangaan wanneer ze weer samenkomen, zonder dat iemand iets moet beoordelen dat buiten zijn of haar expertise valt.

Olivia Montgomery: Over het algemeen raad ik één scorecardtemplate aan met zowel technische als zakelijke vereisten. Maak vervolgens duidelijk wie verantwoordelijk is voor welke kolom of rij.

Het technische team moet de integratievereisten, cybersecurity en andere technische onderdelen invullen. De rapportage en het dashboard kunnen door de leidinggevenden worden beoordeeld.

Ik wil wel dat alle informatie met iedereen wordt gedeeld. Je kunt kolommen grijs maken wanneer je de scorecard naar bepaalde mensen stuurt, maar ze moeten kunnen zien dat die informatie bestaat.

Je wilt voor iedereen dezelfde scorecard, om allerlei redenen. Het helpt iedereen begrijpen dat er meer stemmen zijn dan alleen die van henzelf. Soms komen er interessante zaken naar boven. Je hoofd IT kan bijvoorbeeld zeggen dat de leverancier tijdens de technische demo geen enkele bestaande klant heeft met deze integratie en dus niet aan de verwachtingen voldoet.

De bedrijfseigenaar kan echter hebben gehoord dat de leverancier dit wel kan. De scorecard helpt dan het gesprek op gang te brengen. De leverancier zegt dat het kan, de IT-directeur zegt dat het inderdaad kan, maar alleen via een aangepaste integratie die niet standaard of getest is en die geen enkele andere klant gebruikt. Dat brengt risico's met zich mee.

Misschien wil je die risico's niet nemen. Dat gesprek moet plaatsvinden. Een scorecard is een goede manier om dat gesprek te starten. Je zult vaak horen: ze zeiden dat ze dit konden doen. Misschien komt je schaduw-IT-afdeling binnen en zegt dat ze de oplossing al hebben beoordeeld en dat dit is wat ze willen.

Dan kun je zeggen: prima, maar we hebben een leveranciersscorecard. Dit is de gestandaardiseerde aanpak die we elke keer gebruiken. Misschien hebben ze die al ingevuld, afhankelijk van je relatie met hen, of je vult hem samen in.

Hetzelfde geldt voor een leidinggevende die tijdens een conferentie een nieuwe tool heeft gezien en daar enthousiast over is. Eén gezamenlijke scorecard helpt iedereen op één lijn te krijgen, zich betrokken en gehoord te voelen en belangrijke gesprekken te voeren voordat je idealiter een contract ondertekent.

Galen Low: Dat is een enorm belangrijk punt dat vaak over het hoofd wordt gezien. Vooral wanneer we praten over scorecards en numerieke waarden. Iemand kan denken: we voeren het in de computer in en die vertelt ons welke software we moeten kiezen.

Maar eigenlijk is het een aanjager van een gesprek. Waar zijn we het niet over eens? Waar moeten we dieper op ingaan? Wat bedoelde je precies?

De nerdy projectmanager in mij denkt aan planning poker. De ene persoon vindt iets een drie omdat het heel eenvoudig is en iemand anders geeft een 21. Dan moeten die mensen met elkaar praten, want er is duidelijk een enorm verschil.

Olivia Montgomery: Ja, precies. Het is een basis voor gesprekken en voorkomt ook dat gesprekken verhit of emotioneel worden. Je deelt je informatie en komt tot cijfers in plaats van een welles-nietesgesprek.

Galen Low: Nu we het toch over nerdigheid hebben: kunnen we wat dieper ingaan op het verzamelen en samenvoegen? Je noemde eerder gewogen scores. Iedereen vult de scorecard in en we hebben een plek nodig om alles op te slaan.

Kun je uitleggen wat je zou doen als je een organisatie was? Zou je een tool gebruiken? Welke vergaderingen zou je organiseren nadat alle demo's zijn afgerond? Hoe breng je de informatie weer onder de aandacht van mensen, voer je berekeningen uit en bepaal je waar gesprekken nodig zijn en wie daarbij betrokken moet zijn?

Olivia Montgomery: Dat is een enorme vraag.

Er is veel variatie. Ik geloof sterk in een gestandaardiseerde maar aangepaste aanpak. Elke belanghebbende is anders en elk bedrijf is anders. Ook de volwassenheid van je omgeving en bedrijfsprocessen, het beschikbare geld en de beschikbare tijd verschillen. Heb je nu een softwaresysteem nodig of wordt dit een vervangingstraject van zes maanden?

Als projectmanager moet je veel hulpmiddelen in je gereedschapskist hebben, zodat je flexibel kunt inspelen op wat er gebeurt. Om te beginnen moet je weten wat de verwachtingen zijn. Hopelijk kun je, voordat je een demo plant, begrijpen wie de uiteindelijke beslissers zijn.

In een groter bedrijf kan er een stuurgroep of IT-stuurgroep zijn waaraan je je bevindingen moet presenteren. Bij een kleiner bedrijf of een minder zichtbare tool moeten misschien alleen je hoofd IT en de directeur van de bedrijfseenheid overeenstemming bereiken.

Je moet al deze informatie kennen voordat je de demo plant en hopelijk zelfs voordat je met leveranciers praat.

Galen Low: Ik denk het wel. Elke organisatie is anders, maar mijn belangrijkste inzicht is dat je vooruit moet kijken en je moet voorbereiden. Als projectmanager die dit proces leidt, moet je je vaardigheden en zachte vaardigheden inzetten om complexe en soms politieke gesprekken te navigeren.

Je moet kunnen zeggen: dit is onze rubric, dit is onze scorecard, hier slaan we ze op, zo bereiden we onze sessies voor en dit vragen we de leveranciers te demonstreren op basis van de user stories die zijn ingediend en geprioriteerd.

Na de demo's moet je een plan hebben om alle gegevens samen te brengen en op een manier te presenteren waarmee je het gesprek kunt voeren. Je moet de juiste mensen aan tafel brengen: de besluitvormers, bedrijfseigenaren en technische leads, zodat zij een definitieve beslissing kunnen nemen.

Tegelijkertijd creëer je een controleerbaar spoor, omdat je misschien wordt gecontroleerd of omdat er een nieuwe CTO komt die wil weten waarom jullie deze keuze hebben gemaakt. In plaats van het hele proces opnieuw te doorlopen, kun je de nieuwe persoon laten zien: dit was ons proces, dit waren onze overwegingen en dit zijn de gegevens.

Olivia Montgomery: Als je moeite hebt om draagvlak te krijgen voor een leveranciersscorecard, kun je de scorecards ook samen invullen. Dat kan handig zijn als je organisatie nog niet klaar is voor een volwassen, gestructureerd projectmanagementproces.

Plan na de demo's bijvoorbeeld 45 minuten in en zeg: dit gaan we samen invullen. Zo wordt de scorecard actief ervaren als gesprek en besluitvormingsinstrument. Veel mensen, vooral bedrijfsleiders, vinden het prettig om zaken samen te bespreken.

Of je nu in dezelfde ruimte bent of op afstand werkt, vul de scorecard samen in en zeg: dit zijn de drie leveranciers die we allemaal hebben gezien. Aan het einde van deze vergadering hebben we samen een volledige leveranciersscorecard ingevuld en hopelijk bereiken we consensus.

Galen Low: Dat vind ik goed. Het is geen quiz en jullie zijn geen olympische juryleden. Je kunt dit gezamenlijk doen. Het is een gesprek.

Wanneer alles achter de rug is, zeggen sommige mensen misschien dat je bij softwareselectie niet iedereen tevreden kunt stellen. Hoe manage je onderweg de verwachtingen van mensen binnen je bedrijf die input hebben geleverd en belang hebben bij deze beslissing, zodat ze niet gefrustreerd raken door de uiteindelijke keuze?

Olivia Montgomery: Dat is nog een reden waarom ik van leveranciersscorecards houd, vooral als je de criteria weegt. Houd in gedachten waarom je een tool nodig hebt, niet alleen welke tool je aanschaft. Noem je project niet 'implementatie van X-software'. Noem geen leverancier in de projectnaam.

Het is een project voor het selectieproces. Blijf onthouden waarom je de software nodig hebt, want dat kan gemakkelijk worden vergeten. Wanneer mensen klaar zijn om een beslissing te nemen, zeggen ze soms: we willen deze software, koop hem gewoon en zet hem maandag aan.

Vraag steeds: lost wat de leverancier heeft gezegd, het voorstel, het contract, de demo en alle andere informatie het bedrijfsprobleem op dat we proberen op te lossen? Gebruik de scorecard als een gestandaardiseerde, niet-emotionele oefening om de focus daarop te houden.

Je wilt niet eindigen met: deze tool doet functie X, Y en Z heel goed, maar hij kan niet integreren met ons e-mailsysteem, terwijl dat een must-have is. Iemand vindt de rapportage misschien geweldig, maar als de integratie ontbreekt, is de tool niet geschikt.

Breng het gesprek dus steeds terug naar de leveranciersscorecard en vraag altijd: lost dit het bedrijfsprobleem op? Niet: heeft dit mooie nieuwe functies?

Galen Low: Dat vind ik geweldig. Ik noteerde in mijn hoofd: scorecard staat gelijk aan transparantie. Niet automatisch, maar dat is wel hoe je hem gebruikt.

Transparantie over de beslissing die je neemt zorgt voor een controleerbaar spoor, zowel voor auditors als voor mensen die later vragen waarom je die beslissing hebt genomen. Voor de mensen die het proces doorlopen, geeft het duidelijkheid en structuur. Iedereen begrijpt wat we proberen te bereiken, waarom de scorecard wordt gebruikt en waarom bepaalde zaken worden benadrukt.

Aan het einde deel je de beslissing met iedereen die betrokken was: dit hebben we besloten en dit is waarom. Je bedankt hen voor hun deelname en legt uit hoe de scores tot stand zijn gekomen.

Maakt dat iedereen blij met de keuze? Waarschijnlijk niet. Sommige mensen zullen nog steeds zeggen dat die andere tool een geweldige integratiefunctie had. Maar je hebt in elk geval een onderbouwing en de juiste mensen gedurende het proces betrokken.

Olivia Montgomery: Je wilt respect voor de beslissing. Mensen hoeven niet blij te zijn met de beslissing, maar ze moeten die wel respecteren. Dat kan alleen wanneer je eerlijke en transparante gesprekken voert en mensen kunnen zien dat je niet zomaar voor een tool hebt gekozen omdat bijvoorbeeld de broer van iemand daar werkt.

Dat is geen grapje; het is in veel bedrijven een reëel probleem. Het gebeurt. De beslissing hoeft niet geliefd te zijn, maar moet wel worden gerespecteerd.

Galen Low: Olivia, het is altijd geweldig om je in de show te hebben. Er zit zoveel goeds in ons gesprek van vandaag. Wat me vooral bijblijft, is het idee van twee demo's.

Intuïtief wil ik de groep bij elkaar houden, zodat we samen een beslissing nemen. Maar dat betekent niet dat de demo voor iedereen dezelfde moet zijn. Sterker nog, dat is waarschijnlijk geen goed idee, omdat er zoveel terrein te behandelen is en de gesprekken zo verschillend zijn.

Je kunt alles weer samenbrengen met iets als een scorecard en daarna een gezamenlijk gesprek voeren. Zo betrek je iedereen, zonder tijd te verspillen. Dat is geweldig advies.

Olivia Montgomery: Je power user hoeft er niet bij te zijn wanneer je bespreekt hoe vaak taken worden uitgevoerd en hoe de API eruitziet. Omgekeerd geldt hetzelfde. Respecteer ieders tijd, maar laat niets onbesproken en wacht niet te lang voordat bedrijfsvoering en IT overeenstemming bereiken.

Dat mag niet pas tijdens de implementatie gebeuren.

Galen Low: Laatste vraag. Een strikvraag.

Olivia Montgomery: Nog een?

Galen Low: Ja, nog een strikvraag om af te sluiten.

Stel dat je projectmanager bent in een organisatie waar je ziet dat een softwareselectieproces niet zorgvuldig wordt uitgevoerd. Misschien zegt iemand zelfs: dat is het softwarebedrijf van mijn broer, we krijgen een goede deal.

Wat kun je doen of zeggen om meer structuur in dat proces te brengen en de vooringenomenheid weg te nemen? Welke gesprekken moet je voeren?

Olivia Montgomery: Zorg voor een respectvolle relatie met degene die die mening heeft. Controleer of die persoon verantwoordelijk is voor de uiteindelijke beslissing. Soms is dat niet zo en moet je naar degene gaan die de beslissing neemt en zeggen: ik heb je hulp nodig, ik heb je autoriteit nodig.

Als die persoon de beslissing neemt, luister dan naar hem of haar en vraag of jullie samen een leveranciersscorecard kunnen invullen. Leg uit dat je zeker wilt weten dat alles is afgedekt en dat je enthousiast bent over de tool. Wees niet afwijzend en werk aan de relatie. Misschien werk je nog lange tijd met deze persoon samen.

Je kunt de scorecard samen invullen en een socratische methode gebruiken. Vraag bijvoorbeeld: wat heb je geleerd over de integraties? Als blijkt dat daar niet over is gesproken, zeg je: goed, laten we dat bespreken.

Door vereisten stap voor stap te ontvouwen, kan iemand zelf ontdekken dat een tool misschien niet de beste keuze is. Misschien blijkt juist dat het wel de beste tool is. In dat geval kun je zeggen: bedankt voor deze informatie, maar we moeten de oplossing nog steeds beoordelen en minstens met één andere optie vergelijken.

Ik kom steeds terug op hetzelfde: wees open en transparant. Laat weten dat de oplossing moet werken voor IT, voor de bedrijfseenheid, voor de huidige situatie en voor de toekomstige situatie. Doe het samen.

Galen Low: Geweldig. Daar ben ik dol op.

Olivia, fijn dat je er was. We hebben echt diepgaand gekeken naar het softwareselectieproces, vooral naar deze demo's en het besluitvormingsproces daarna.

Ik hoop dat onze luisteraars hier veel waarde uit hebben gehaald. Ik kijk ernaar uit je opnieuw in de show te hebben, want er is nog veel meer terrein dat we kunnen behandelen en ik heb nog meer strikvragen voor je.

Olivia Montgomery: Bedankt dat ik mocht komen. Ik hoop dat mensen iets hebben geleerd en anders zijn gaan nadenken over selectieprocessen en demo's. Misschien zien ze er niet meer zo tegenop en laten ze zich niet langer overrompelen door beslissingen die worden doorgedrukt. Ik hoop echt dat dit nuttig was. Ik praat altijd graag met je. Je bent geweldig, Galen. Heel erg bedankt.

Bedankt!

Galen Low: Wat vind jij? Is een softwaredemo de tijd van je team waard? Of is het vooral een show die een praktische, diepgaande evaluatie omzeilt? Laat je gedachten en verhalen achter in de reacties hieronder.

En als je je vaardigheden als strategische projectleider wilt aanscherpen, kom dan bij onze community. Ga naar thedigitalprojectmanager.com/membership voor toegang tot een ondersteunende community die kennis deelt, complexe uitdagingen oplost en samen de toekomst van ons vak vormgeeft.

Van uitgebreide sjablonen en maandelijkse trainingssessies die je tijd en energie besparen tot ondersteuning van vakgenoten via ons discussieforum, community-evenementen en mastermindgroepen: lid zijn van onze community betekent dat je meer dan duizend mensen aan je zijde hebt terwijl je je loopbaan in digitale projectoplevering vormgeeft.

En als je het leuk vond wat je vandaag hebt gehoord, abonneer je dan en blijf op de hoogte via thedigitalprojectmanager.com.

Tot de volgende keer. Bedankt voor het luisteren.