Få ut mesta möjliga av en programvarudemo

 

Läs transkriberingen:

Vi testar att transkribera våra poddavsnitt med hjälp av ett program. Ursäkta eventuella stavfel eftersom boten inte har rätt 100 % av gångerna.

Galen Low: Ännu en programvarudemonstration från en leverantör håller på att krascha och brinna upp. Din teknikchef och din DevOps-ansvariga verkar spela buzzwordbingo med varje marknadsföringsjargong som presentatören nämner. Din verksamhetschef börjar få glasartad blick när ämnena blir lite för tekniska. Och även om personen som presenterar verkligen verkar kunna sin sak är det ingen som tycks ta upp elefanten i rummet: det faktum att personen faktiskt är din vd:s kusin.

Finns det inget sätt att använda allas tid bättre?

Om intetsägande demonstrationer har varit ett hinder för att fatta ett välgrundat beslut om ny programvara för din organisation, fortsätt lyssna.

Vi ska gå igenom några av de mest effektiva strategierna för att göra demonstrationsfasen i urvalsprocessen för programvara betydligt mer relevant för organisationens specifika behov.

Hej allihop, tack för att ni lyssnar! Jag heter Galen Low och arbetar med The Digital Project Manager. Vi är en gemenskap av digitala yrkesverksamma med uppdraget att hjälpa varandra att bli skickligare, tryggare och mer sammankopplade, så att vi kan höja värdet av projektledning i en digital värld. Om du vill höra mer om det kan du gå till thedigitalprojectmanager.com.

Okej. I dag pratar vi om processen för att välja ny programvara för era projektteam, och mer specifikt om hur man skär igenom säljpresentationen i en programvarudemonstration och ser till att verktyget inte bara är det bästa verktyget, utan också rätt verktyg för hur era team arbetar. Med mig i dag har jag Olivia Montgomery, Associate Principal Analyst på Capterra och tidigare PMO-chef inom IT, som nu ger små och medelstora företag råd om val av programvara.

Hej, Olivia!

Olivia Montgomery: Hej, Galen! Tack för att jag fick komma.

Galen Low: Det var fantastiskt att ha dig med i programmet igen. Hur har du haft det i Austin?

Olivia Montgomery: Det är ganska spännande. South by Southwest pågår, och det är tillbaka fysiskt för första gången sedan 2020. Så staden är livfull och det finns så många evenemang, föredrag och alla möjliga saker på gång. Det är verkligen spännande den här veckan.

Galen Low: Tillbaka igen, tillbaka igen. South by Southwest, jag är superentusiastisk över det. Det dyker upp i hela mitt sociala medieflöde och allt sådant. Jag har aldrig tagit mig ner till Austin, men det verkar vara en så livfull musikalisk gemenskap. Det händer så mycket, det finns så många konferenser och sätt för människor att träffas och ha roligt.

Så nu låter det som att jag inte längre har några ursäkter. Det här kanske blir året. Det här kanske blir året.

Olivia Montgomery: Och det är riktigt häftigt. Det finns definitivt teknikspår. Jag har kunnat gå på föredrag med ledare inom leveranskedjor, Amtraks vd, och John Deere är här och driver verkligen sitt teknikfokus. Det finns VR-upplevelser som verkligen fokuserar på berättande på nya sätt, från mycket tunga och allvarliga ämnen till lättsam underhållning och hur vi kan interagera med innehåll och varandra på andra sätt.

Galen Low: Väldigt häftigt. Vad har varit din favorit hittills?

Olivia Montgomery: Bortsett från all faktisk teknik och innovation som vi ser fick jag se den nya Batmobilen i verkligheten. Och jag måste säga att det är en höjdpunkt för mig. Jag är filmfantast. Jag tittar faktiskt inte på trailrar, så jag har inte sett någon trailer. Jag har inte sett Batman ännu på grund av South by, men jag såg Batmobilen för första gången i verkligheten. Så det var riktigt häftigt.

Galen Low: Jag tror att det förmodligen är bättre än en trailer.

Olivia Montgomery: Det tror jag också. Jag tänkte: Okej, jag förstår, jag ser känslan. Nu är jag verkligen sugen på att se filmen.

Galen Low: Det är det jag ser fram emot mer när saker öppnar upp igen, eller hur? Att bara stöta på det oväntade, sådant man inte planerade att göra, finns framför en igen.

Fantastiskt. Okej. Då sätter vi igång.

Låt oss prata om den mest pressade och tvivelskapande delen av urvalsprocessen för programvara, nämligen demonstrationen. Låt mig börja med att beskriva situationen.

Anta att du har fått i uppgift att hitta ett nytt verktyg för din organisation och att du antingen är ensam beslutsfattare eller leder urvalskommittén. Du har lagt otaliga timmar på att hitta användningsfall. Du har samlat in krav från teamet. Du har fastställt budgetar tillsammans med ledningen och gjort massor av efterforskningar på nätet. Till slut har du en kortlista med verktyg som verkar passa, och nu vill du se dem i praktiken.

Så varför är detta pressat och tvivelskapande? Jag tror främst att det beror på att detta bokstavligen är kulmen på allt ditt arbete hittills. Du försöker hantera alla intressenter. Du försöker kommunicera alla krav effektivt till dina programvaruleverantörer. Du förväntas ta till dig en enorm mängd information och reagera direkt, och allt sker i den mest pressade miljön av alla – ett möte.

Så jag tänkte att vi kanske kan börja med motargumenten. Bör ett team eller en organisation ens bry sig om att ha en demonstration? Är det inte bara en säljpresentation?

Olivia Montgomery: Ha demonstrationer, snälla, snälla. Jag förstår. Jag har suttit igenom min beskärda del av demonstrationer som varit mycket säljfokuserade. Det var mycket av det som fick mig att börja fundera på hur man kan göra dem bättre. Jag tror på demonstrationsprocessen, och det finns mycket förberedelser och arbete, särskilt för projektledaren, som du kan göra för att göra dem till en av de viktigaste delarna av urvalsprocessen.

Så ja, ha demonstrationer, men de är inte riktigt så enkla som att följa leverantörens ledning. Jag tror att det är där vissa kan gå fel. Du vill verkligen styra och i praktiken fastställa kraven för vad du vill se i demonstrationen.

Galen Low: Jag tycker att det är helt rimligt. De här verktygen har också mycket djup, eller hur? Och ofta väljer vi ett verktyg som ska göra många olika saker och vara många olika saker för olika personer. Men är det ens möjligt att täcka så mycket i en demonstration, utöver att bara skrapa på ytan när det gäller grundläggande funktioner i en programvara? Eller vilka strategier bör en organisation överväga för att säkerställa att den får de svar den behöver?

Olivia Montgomery: Ja. Bra frågor.

För det första: nej, du kan inte täcka allt i en programvarudemonstration. Det är där dina tidigare efterforskningar på nätet kommer in. Och om du genomför en RFP-process, eller när du har kommit ner till de två eller tre slutliga leverantörer som du tittar på, be dem skicka all den informationen till dig i ett dokument. Demonstrationen är inte den bästa platsen för att gå igenom all funktionalitet du behöver.

Du vill fokusera specifikt på hur användargränssnittet ser ut och på några viktiga användarberättelser som teamet behöver följa. Vilka affärsprocesser behöver stödjas av det här verktyget? Och ärligt talat, tycker användarna om hur det ser ut och känns? Det här kan vara första gången de använder ett verktyg och ser gränssnittet.

Därför blir utseendet och känslan viktigare här. Den faktiska funktionslistan bör vara nedskriven innan du skriver under ett avtal.

Galen Low: Jag tycker att det där är väldigt viktigt. Och tack för det, för jag beskrev det tidigare som en kulmen, eller hur? Alla vägar leder fram till demonstrationen, men egentligen fyller demonstrationen bara i vissa luckor.

Den är faktiskt en del av efterforskningsprocessen. Det finns saker som du helt enkelt behöver se i praktiken för att få en känsla för dem, som du sa: användargränssnittet och vissa användningsfall. Det kommer inte att vara: Hej, jag har gjort all den här efterforskningen och kan göra alla de här sakerna. Jag har tittat på jämförelsetabellen, och nu vill jag att du visar mig varje funktion under två timmar. Det skulle förmodligen inte gå särskilt bra.

Det är snarare: Bra, jag tror att vi känner till allt detta. Vi har sett allt detta på papper, och du har skickat ytterligare detaljer till mig. Nu bokar vi en demonstration där vi faktiskt kan gå på djupet i några saker som är viktiga.

Olivia Montgomery: Precis. Jag rekommenderar faktiskt starkt att man bokar två demonstrationer.

Jag föredrar en verksamhetsinriktad demonstration och sedan en teknisk demonstration. Om man kombinerar dem blir det ett mycket långt och komplicerat möte. Hälften av intressenterna skulle inte vara intresserade av den tekniska sidan och den andra hälften skulle inte vara intresserad av verksamhetssidan. Därför rekommenderar jag att man delar upp dem, av respekt för intressenternas tid.

Dessutom behöver du olika personer i de mötena. Det är inte samma personer. Så jag håller starkt med om att det på sätt och vis är ytterligare ett granskningssteg, men också ytterligare kravinsamling från leverantören. Och ja, boka två – oavsett om vi pratar om ett projektledningsverktyg, ett redovisningsverktyg, ett nytt affärssystem eller vilket programvaruverktyg du än tittar på. Jag gillar att följa ungefär samma demonstrationsstruktur.

Den första är alltså verksamhetsinriktad. Ha verksamhetsägaren där. Det är kanske lite mer uppenbart, men du vill också inkludera din avancerade användare. Ofta är det en arbetsledare eller någon i en ledande roll, personen som använder verktyget dagligen. Syftet är att säkerställa att du tittar på verktyget både ur ett strategiskt långsiktigt perspektiv och ur ett praktiskt användarperspektiv.

Verksamhetsägaren kan avgöra om verktyget kommer att stödja organisationens tillväxt och riktning, men du behöver också ha den avancerade användaren där för att se den specifika användarberättelsen. De vill veta att deras centrala uppgift kan utföras och hur det ser ut och känns.

Ibland har jag hört projektledare säga att de inte alltid får med sig en avancerad användare till någon av demonstrationerna. Ibland är det för tidigt, ibland finns det en mängd ursäkter, men den avancerade användaren kommer också att följa med genom resten av projektet. Det är troligt att personen blir din kvalitetssäkringsperson under själva införandet.

De är din främsta källa till användarkrav. Det är teamet som kommer att använda verktyget. De måste vara nöjda med utseendet och känslan, vilket återigen är något demonstrationen verkligen granskar. Därför vill du se till att båda dessa personer är med i demonstrationen.

Ett annat sätt att förbereda detta är att samla in användarberättelser från teamet, och åtminstone en eller två från den avancerade användaren, och skicka dem till leverantören långt i förväg. Helst flera dagar före de planerade demonstrationerna, så att leverantören kan konfigurera systemet och gå igenom exakt den användarberättelsen med dig. Du ska kunna säga: Som redovisningsekonom behöver jag kunna köra rapporten för månadsbokslutet inom 24 timmar, så att jag kan avsluta redovisningsmånaden. Du behöver faktiskt se hur det händer i verktyget.

En användarberättelse ska inte definiera exakt: Jag vill se just den här funktionen i verktyget. Den öppnar i stället för möjligheten att verktyget har hittat ett innovativt sätt att uppnå eller genomföra en funktion som du kanske inte har sett tidigare. Du vill alltså inte låsa fast leverantören genom att säga: Visa bara detta. Men du måste också vara öppen.

I grund och botten behöver den avancerade användaren kunna se sin centrala funktion. Verksamhetsägaren kommer också att ha krav som hen vill se, vanligtvis den verkställande instrumentpanelen. Hur ser den ut?

Hur ser verktyget ut när jag loggar in som chef, ledare eller vd? Hur tar jag fram mina rapporter på instrumentpanelen? Även det handlar om hur saker ser ut och känns. Du måste se dem och be leverantören lägga in testdata åt dig. Vanligtvis konfigurerar leverantören en sandlådemiljö för demonstrationen. Be dem förinstallera lite testdata så att du faktiskt kan få en känsla för rapportstrukturen.

Galen Low: Det där är verkligen bra. Jag gillar tanken på att dela upp gruppen. Det verkar ibland lite kontraintuitivt när det handlar om en beslutsprocess, men jag gillar idén med två olika demonstrationer eftersom det är två olika samtal som behöver föras om verktyget.

Det handlar faktiskt om att använda människors tid på bästa sätt. Och det du sa om att vi ibland får motstånd – att vi inte vill involvera vår avancerade användare inom ekonomi i det här skedet eftersom det är för tidigt i processen och så vidare – är viktigt. Det är faktiskt en del av bedömningen av verktyget och den långsiktiga och djupa användningen av det.

Och ärligt talat handlar det också om att granska och göra den personen till en slags ambassadör för urvalsprocessen, eftersom hen var involverad och närvarande. Om personen inte var det kan hen i stället bli den starkaste rösten i rummet och säga att det var ett dåligt beslut.

Jag gillade det du sa om en sandlådemiljö. För vissa tror jag att processen vid val av programvara är att man gör arbetet, genomför demonstrationen och sedan lutar sig tillbaka och tittar. Därefter vill man ha en praktisk miljö där man kan ta det som visades i demonstrationen och prova det själv.

Men finns det situationer där människor faktiskt provar själva i en sandlådemiljö under demonstrationen, alltså en praktisk demonstration?

Olivia Montgomery: Jag är säker på att avancerade användare där ute skulle uppskatta chansen att göra det, eftersom en av fallgroparna är att man vill välja det programvaruverktyg som passar både de nuvarande processerna och det framtida läget. Ibland fokuserar en demonstration bara på framtiden.

Ibland är tanken: När vi får det här verktyget kommer våra processer att utvecklas dramatiskt och mogna automatiskt med all den automatisering vi kommer att kunna få. Men det är inte verkligheten. Den avancerade användaren kommer att kunna avgöra om verktyget fungerar från dag ett, om det uppfyller dagens behov och samtidigt stöder framtida behov.

Därför tror jag att det kan hjälpa den avancerade användaren att komma in i sandlådemiljön i förväg. Då kan personen se: Ja, jag skulle kunna använda det här i dag och ändå få jobbet gjort. Vi kommer inte att slå på det och förlora all funktionalitet.

Jag vet inte om era tekniska team skulle uppskatta det, bry sig om det eller ha tid att göra det. Jag förespråkar starkt transparens och öppenhet. Prata med era intressenter och leverantören om vad ni behöver och vilka idéer de har. På så sätt skär ni igenom säljpresentationen genom att inte låta leverantören styra hela demonstrationen, men ni vill samtidigt dra nytta av deras lösningskunskap.

De kanske har innovativa sätt att angripa ett problem som ni inte hade tänkt på. Därför vill ni även vara öppna för det.

Galen Low: Jag gillar det. Låt oss prata lite mer om hur man förbereder sig inför de här två demonstrationerna. Har du några bra berättelser eller exempel på användningsfall som ett team bör be leverantören att gå igenom för att säkerställa att programvaran fungerar som den ska? Eller om själva processen med att samla in användarberättelser, på ett sätt som inte begränsar den för mycket?

Olivia Montgomery: Absolut. Om du har turen att ha en verksamhetsanalytiker inom IT som kan samla in alla krav åt dig är det fantastiskt. Det är inte vanligt. Och även om du har en sådan person kanske din avancerade användare aldrig tidigare har lämnat en användarberättelse eller formulerat krav. Då behöver personen hjälp.

Något jag har gjort tidigare och tycker om är att skicka ut en enkät till teamet, den avancerade användaren och avdelningens arbetsledare – alltså de personer som kommer att använda verktyget. Jag ger dem en struktur i stil med en lucktext. Användarberättelsen börjar: Som [yrkesroll] behöver jag kunna [uppgift], så att jag kan [anledning].

Det blir som en färdig lucktext som gör det enkelt för dem att fylla i. De förstår vad som ska göras, det går snabbt och du kan sedan ta exakt den användarberättelsen och skicka den till leverantören och säga: Det här är precis vad jag vill se.

Så jag tycker om en lucktextmetod.

Galen Low: Jag älskar det. Jag är ett stort fan av lucktexter och användarberättelser, och här kombineras de. Det är ett bra sätt att se på det. Det lämnar dörren öppen för leverantören att utforma en demonstration som visar hur programvaran hanterar behovet, samtidigt som teamet kan få bekräftelse på att den faktiskt gör det och hur man gör det. Väldigt häftigt.

Olivia Montgomery: Att se det och veta att man tycker om utseendet och känslan är återigen den stora drivkraften bakom den verksamhetsinriktade demonstrationen. Jag nämnde också den andra demonstrationen, den tekniskt inriktade. Där kan användarberättelserna inkludera frågor som: Hur ofta körs de här jobben? Måste vi vänta?

Kan vi schemalägga jobben till klockan 01.00? Det kommer att köras i en timme. Är det acceptabelt för verksamheten? Behöver det köras oftare eller mer sällan? Har vi kapaciteten? Där vill du säkerställa att era tekniska ledare och leverantörens tekniska ledare är med i demonstrationen.

Systemadministratören behöver veta hur verktyget fungerar och den som ansvarar för IT-arkitekturen behöver förstå det. Ingenjören behöver veta var data lagras. Är det leverantören som driftar den? Är det okej för er? Driftar ni den själva? Vet ni var? Det finns så många tekniska detaljer som kan leda till mycket obehagliga överraskningar om ni väntar till dess att avtalet ska undertecknas.

Därför måste den delen ingå i granskningsprocessen. De två tekniska teamen behöver vara tillsammans, besvara frågor, visa exakt hur det ser ut och diskutera kapaciteten. De kan fråga: Kommer det här att kräva specialkod? Finns funktionen direkt i grundutförandet?

Det här är frågor som verksamhetsägaren och den avancerade användaren inte kommer att kunna besvara. Och ibland kanske inte heller projektledaren, om hen inte är teknisk projektledare. Därför måste ni ställa frågorna. Ni vill också veta mer om integrationer. Fråga om någon av leverantörens befintliga kunder har en integration med era specifika verktyg.

Var inte rädda för att nämna vilka verktyg ni använder och fråga om leverantören redan har integrationer med dem. Om de inte har en befintlig eller färdig integration måste ni avgöra om det är ett avgörande hinder. Måste ni bygga en anpassad integration? Har ni resurserna? Är leverantören villig att göra det åt er? Har ni tid? Alla sådana samtal behöver äga rum.

Det kan låta som ett överlastat samtal, men jag lovar att det inte är det om ni har gjort era förberedelser. Era tekniska team vet vad de behöver fråga om, och ni sparar er själva mycket besvär genom att inte vänta längre i processen.

Galen Low: Jag tycker att det är en enormt viktig poäng. Det finns så mycket att täcka att samtalet kan bli överlastat. Vi vill fokusera på vissa användningsfall, men även ett programvaruverktyg som ett CRM- eller affärssystem eller ett innehållshanteringssystem behöver göra många olika saker i de här användningsfallen. Det tar tid att demonstrera och diskutera dem.

Så hur väljer och prioriterar man användningsfallen och frågorna som man vill att leverantören ska besvara, utan att samtalet blir överlastat?

Olivia Montgomery: Det här är en mycket viktig fråga. Du måste förlita dig på teamledarna, verksamhetsledarna och den avancerade användaren. Prata med dem före demonstrationen och fråga: Vilka är era största bekymmer? Vad vill ni se till att vi täcker?

Låt dem berätta vad som är viktigast. Om du är en mycket teknisk projektledare kan du styra de samtalen, vilket är utmärkt, men många av oss är inte det. Förlita dig på dem och fråga: Vilka två eller tre saker måste ni se?

Se sedan till att de täcks under den faktiska demonstrationen och håll er till planen. Du måste också underlätta demonstrationen. Om någon vill gå för djupt in på något kan du säga: Jag vill säkerställa att vi täcker de tre punkterna. Leverantörer är vanligtvis mycket bra på tidshantering eftersom de har genomfört många demonstrationer, men var inte rädd för att bryta in.

För att det ska fungera måste du dock ha ett förberedande samtal med personerna som ska delta i demonstrationen. Säg: Det här är de tre sakerna. Då blir ingen överraskad och ingen känner sig avbruten eller avfärdad. De vet att ni redan har kommit överens om spåret och kan återgå till det utan att känna sig åsidosatta.

Galen Low: Jag tycker att det är en mycket viktig poäng. I rollen som projektledare, när du leder den här processen, finns det områden där du har kontroll och ansvarar för att sätta upp saker.

Men vissa beslut ligger faktiskt hos andra, även i ett projekt för val av programvara. Du har en sponsor och beslutsfattare, som ledningsgruppen, och vi behöver förlita oss på den beslutsprocessen och på ledningsgruppen för att prioritera vad vi vill få ut av något som en demonstration.

Samtidigt måste vi samla in synpunkter från alla team som kan behöva använda verktyget. De fyller i lucktexten, loggar och dokumenterar sina användningsfall och får en röst i processen.

Olivia Montgomery: Precis. Du kan alltid påminna människor om att ni i demonstrationen försöker täcka tre, kanske fyra, mycket fokuserade användarberättelser som ni har presenterat för leverantören, så att de är förberedda.

Allt utöver det kan ni be om att få skriftligt i er RFP eller i någon annan form av dokumentation. Ni kan alltid säga: Vi behöver dokumentation om detta. Vad kostar det?

Efter demonstrationen vill ni också ha en uppdelning från leverantören. Om ni har frågat efter en specifik funktion, är det specialkod? Hur mycket tror de att det kostar? Kommer de att bygga den åt er eller måste ni göra det själva?

Ni behöver veta om de måste skriva koden eller om ni måste göra det, samma sak gäller integrationer. För att inte fastna för mycket i detaljer under demonstrationen kan ni påminna alla: Låt oss få detta dokumenterat och gå vidare med att faktiskt se programvaran fungera.

Galen Low: Jag gillar verkligen det. Jag vill återkomma till något. Vi har delat upp gruppen och sagt att man ska ordna två demonstrationer. Den ena har mer verksamhetsfokus och den andra mer IT-fokus, med samtal om infrastruktur, integrationer, schemaläggning och jobb som körs i bakgrunden.

Men någon gång måste allt komma samman igen. Gruppen har haft olika samtal och utvärderar utifrån olika perspektiv. Bör hela urvalskommittén skapa någon form av bedömningsmatris, så att de kan jämföra de kortlistade produkterna på lika villkor och dokumentera sina tankar? När de samlas igen kan de då kvantifiera och utvärdera sina åsikter och känslor kring programvaran.

Eller är det ett föråldrat sätt att se på saken? Produkter och programvara är så olika i dag att vissa kanske är för komplexa för att jämföras med en bedömningsmatris. Vad tycker du?

Olivia Montgomery: Jag älskar att du tog upp leverantörsbedömningsmatriser. Jag är ett stort fan. Jag tycker absolut att de fortfarande har en plats och inte alls är föråldrade. När du kan minska känslomässiga reaktioner, som är en fallgrop i säljtunga demonstrationer, är det värdefullt.

Du måste kunna ta bort känslorna och minnas varför ni skaffar programvara från början. Det hjälper er att formulera problemet ni försöker lösa och jämföra hur varje leverantör klarar det.

En leverantör kan ha varit väldigt imponerande, men när ni återgår till bedömningsmatrisen och frågar om den uppfyller era funktionella, verksamhetsmässiga och tekniska krav blir det tydligt att den kanske inte passar.

Även om verksamhetsägaren älskar ett visst verktyg av ett känslomässigt skäl har ni utan en bedömningsmatris eller standardiserad modell inget spår av hur beslutet fattades. De är användbara i beslutsdiskussioner. Som projektledare rekommenderar jag också starkt att ni sparar dem varje gång, eftersom ni aldrig vet när projektet kommer att granskas.

Ni vet aldrig när någon kommer att ställa frågor eller när programvaran behöver bytas ut om några år. Då vill ni kunna säga: Varför valde vi inte den här leverantören första gången? Jo, därför att den fick en etta på integrationsskalan.

När ni senare återkommer till leverantören kan ni fråga om integrationerna nu är byggda. Då har ni en informerad och välgrundad beslutsprocess.

Jag stöder, rekommenderar och tycker verkligen om leverantörsbedömningsmatriser. De gör det möjligt att samla information från olika perspektiv. Alla kan se varandras bedömningar, oavsett om ni använder en gemensam matris eller om varje nyckelintressent fyller i en och ni sedan sammanställer dem.

Det beror på organisationens storlek och systemets storlek och komplexitet. För ett projektledningsverktyg kommer ni förmodligen att ha många olika ledare som fyller i egna bedömningar. Sedan sammanför du dem som projektledare och sparar dem.

Jag har själv varit med om att en teknikchef byttes ut kort efter att vi hade infört ett nytt affärssystem. Den nya teknikchefen ville veta varför vi använde verktyget och hur vi hade valt leverantören. Jag kunde visa att det var ett välgrundat och informerat beslut och förklara varför.

Det hjälper också den nya intressenten att förstå verksamheten. Om du arbetar i ett börsnoterat företag kommer revisorerna särskilt att vilja veta att ni inte bara gav affären till en släktings programvaruföretag, utan att ni fattade beslutet på ett uppmätt och standardiserat sätt.

Galen Low: Det finns tre saker jag vill lyfta fram i det du sa. För det första tror jag att vissa ser en leverantörsbedömningsmatris som något mycket generiskt, till exempel att betygsätta användargränssnittet på en skala från ett till tio.

Men det du säger är att man ska vara specifik. Vad försöker ni uppnå? Varför skaffar ni ny programvara? Det är själva bedömningsmodellen. Hur väl kommer verktyget exempelvis att kunna ansluta till resten av ekosystemet av programvara och skapa smidiga, automatiserade processer?

Olivia Montgomery: Jag tycker faktiskt att vissa leverantörsbedömningsmatriser kan vara mindre specifika. En skala från ett till tio kan vara för mycket. Jag rekommenderar vanligtvis att man begränsar den till ett till fem och definierar vad varje värde betyder.

Ett kan betyda att den inte uppfyller förväntningarna, tre att den uppfyller dem och fem att den överträffar dem. Om funktionen inte finns alls kan den få noll.

Galen Low: Inte befintlig. Precis.

Olivia Montgomery: Jag gillar alltså skalan ett till fem. Den är tydligare och tvingar människor att vara mer bestämda i sina svar. Den gör också matematiken enklare, särskilt om ni viktar kriterierna individuellt.

Galen Low: Jag gillar verkligen det. Jag tänker på alla undersökningar där man frågar hur sannolikt det är att man skulle rekommendera ett verktyg till en vän på en skala från noll till tio. Då undrar man verkligen vad en sjua betyder.

Olivia Montgomery: Om du gillar det du får frågan om väljer du en sjua. Om du inte gillar det väljer du en trea. Det är vad de flesta gör, och det är inte särskilt användbart.

Skalan ett till fem förenklar och tvingar människor att välja sida och definiera sitt svar. Oavsett om ni använder ett verktyg, ett papper eller ett kalkylblad måste ni förklara exakt vad värdena betyder. Det kan vara så enkelt som uppfyller förväntningarna, uppfyller inte förväntningarna och överträffar förväntningarna.

Galen Low: Jag gillar det. Den andra saken jag tar med mig är att även om man delar upp gruppen och har olika samtal, kan samma bedömningsmatris användas för att skapa en gemensam grund.

Olivia Montgomery: Vanligtvis rekommenderar jag en gemensam mall som innehåller både tekniska och verksamhetsrelaterade krav. Var tydlig med vem som ansvarar för vilken kolumn eller rad.

Det tekniska teamet ska fylla i integrationskrav, cybersäkerhet och andra tekniska aspekter. Ledningen kan bedöma rapporteringsinstrumentpanelen. Men all information ska delas med alla.

Ni vill använda samma matris för alla eftersom det hjälper alla att förstå att det finns fler perspektiv än deras eget. Om IT-chefen säger att leverantören saknar befintliga kunder med en viss integration medan verksamhetsägaren har fått höra från säljaren att leverantören kan göra det, hjälper matrisen er att föra samtalet vidare.

Då kan ni klargöra att det skulle kräva en specialbyggd, oprövad integration och att andra kunder inte använder den. Det innebär risker som organisationen kanske inte vill ta.

En gemensam bedömningsmatris hjälper alla att komma på samma sida, känna sig delaktiga och hörda samt föra de viktiga diskussioner som bör äga rum innan avtalet undertecknas.

Galen Low: Det är en viktig poäng som kanske förbises. Någon kan tro att man bara matar in siffrorna i en dator och får veta vilken programvara man ska välja, men egentligen är matrisen ett verktyg för att driva samtal.

Var finns oenigheten? Var behöver vi gå på djupet och fråga vad någon menade? Som den nördiga projektledaren i mig tänker jag på planeringspoker. Om en person tycker att något är en trea och en annan tycker att det är en tjugoetta måste de prata med varandra, eftersom det uppenbarligen finns ett stort spann.

Olivia Montgomery: Exakt. Det är en grund för samtal och hindrar också samtalen från att bli heta eller känslomässiga. Ni kan dela information och hålla er till siffror i stället för att fastna i ett ”han sa” och ”hon sa”.

Galen Low: När vi ändå talar om nörderi undrar jag om vi kan gå djupare in på sammanställningen. Du nämnde viktade poäng och att alla fyller i sina delar. Var lagrar man allt? Vilka möten sätter man upp efter demonstrationerna? Hur sammanför man informationen, gör beräkningarna och avgör vilka samtal som behöver föras och vilka som ska delta?

Olivia Montgomery: Det är en enorm fråga, Galen.

Det finns stor variation. Jag tror starkt på en standardiserad men anpassad metod. Varje intressent och varje verksamhet är olika. Mognaden i miljön och processerna, pengarna och tiden ser olika ut. Behöver ni ett system nu eller handlar det om ett byte som tar sex månader?

Som projektledare behöver du många verktyg i din verktygslåda för att kunna anpassa dig. Börja med att förstå förväntningarna. Förhoppningsvis kan du, innan du bokar en demonstration, ta reda på vilka som faktiskt fattar det slutliga beslutet.

I ett större företag kan det finnas en styrgrupp eller en IT-styrgrupp som du ska presentera resultaten för. I ett mindre företag eller vid ett mindre synligt verktyg kanske det bara är IT-chefen och chefen för verksamhetsenheten som behöver enas. Du behöver känna till allt detta innan du bokar, helst innan du ens kontaktar leverantörer.

Galen Low: Jag tycker att din poäng om framförhållning är viktig. Förbered dig, ha en plan och använd dina projektledningsfärdigheter och mjuka färdigheter för att hantera komplexa politiska samtal.

Ha en modell, en bedömningsmatris, en plats där den lagras och en plan för era sessioner. Berätta för leverantörerna vad ni vill se utifrån de användarberättelser som teamen har lämnat in och hur ni har prioriterat dem.

Efter demonstrationerna ska du ha en plan för att samla all data, lägga fram den igen på ett sätt som möjliggör samtal och samla rätt personer kring bordet. När det slutliga beslutet ska fattas behöver beslutsfattare, verksamhetsägare och tekniska ledare mötas.

Samtidigt skapar du ett granskningsbart spår, antingen för att ni kan bli granskade eller för att en ny teknikchef senare vill veta varför ni valde den här vägen. I stället för att upprepa hela processen kan du visa vad ni gjorde, vilka tankar ni hade och vilka data som låg till grund för beslutet.

Olivia Montgomery: Om det är svårt att få stöd för en leverantörsbedömningsmatris kan ni fylla i den tillsammans efter demonstrationerna. Boka exempelvis 45 minuter och säg: Nu fyller vi i detta tillsammans.

Då blir matrisens verkliga värde som samtals- och beslutsverktyg mer aktivt. Många verksamhetsledare tycker om att reda ut saker tillsammans.

Fyll i den gemensamt och säg: Vi bedömer de leverantörer vi alla har sett. När mötet är slut har vi fyllt i en komplett leverantörsbedömningsmatris och förhoppningsvis nått samsyn.

Galen Low: Jag gillar det. Det är inget prov och deltagarna är inga olympiska domare. Man kan göra det tillsammans. Det är ett samtal.

När allt är sagt och gjort kanske vissa säger att man inte kan göra alla nöjda när man väljer programvara. Hur hanterar man förväntningarna under vägen så att de som bidrog med synpunkter och har intressen i beslutet inte blir missnöjda med det slutliga beslutet?

Olivia Montgomery: Det är ytterligare ett skäl till att jag gillar leverantörsbedömningsmatriser, särskilt om ni viktar kriterierna. Kom ihåg varför ni behöver ett verktyg, inte bara vilket verktyg ni ska skaffa.

Döp inte projektet efter en specifik leverantör. Kalla det inte ”implementering av X-programvara”. Det är ett urvalsprojekt. Kom ihåg varför ni behöver programvaran, eftersom det lätt glöms bort när människor vill fatta ett snabbt beslut.

Fråga alltid om leverantörens förslag, avtal, demonstration och all annan information faktiskt löser det affärsproblem ni försöker lösa. Bedömningsmatrisen fungerar som en standardiserad och icke-emotionell modell som hjälper er att behålla fokus.

Ni kan säga: Jag förstår att du gillade rapporteringsinstrumentpanelen, men verktyget kan inte integreras med vårt e-postsystem och det är ett måste. På så sätt återför ni diskussionen till matrisen och frågan om verktyget löser affärsproblemet, inte om det har nya och imponerande funktioner.

Galen Low: Jag älskar det. I mitt huvud skrev jag: bedömningsmatris är lika med transparens. Den skapar inte automatiskt transparens, men det är så den används.

Den gör beslutet tydligare för dem som deltar i processen. Här är vad vi försöker uppnå och varför deras medverkan är viktig. I slutet kan ni berätta för alla vad ni har beslutat och varför, tacka dem för deras deltagande och visa hur beslutet bedömdes.

Kommer alla att vara nöjda? Förmodligen inte. Men ni har en tydlig motivering och rätt personer har varit involverade under hela processen.

Olivia Montgomery: Ni vill ha respekt för beslutet. Alla behöver inte vara nöjda, men de ska respektera beslutet. Det kan de bara göra när diskussionerna är ärliga och transparenta och när de kan se att ni inte valde verktyget bara för att någons släkting arbetar där.

Det händer faktiskt i många verksamheter. Beslutet behöver inte vara älskat, men det måste respekteras.

Galen Low: Olivia, det är alltid trevligt att ha dig med i programmet. Jag tror att vi har gått igenom urvalsprocessen för programvara på djupet, särskilt demonstrationerna och beslutsprocessen efteråt.

Det jag framför allt tar med mig är tanken på två demonstrationer. Jag vill intuitivt hålla ihop gruppen när vi fattar ett gemensamt beslut, men själva demonstrationen behöver inte vara densamma för alla. Det är förmodligen en dålig idé eftersom det finns så mycket att täcka och samtalen skiljer sig åt.

Man kan knyta ihop det med en bedömningsmatris och ett gemensamt samtal efteråt, så att alla fortfarande involveras utan att deras tid slösas bort. Det är ett fantastiskt råd.

Olivia Montgomery: Den avancerade användaren behöver inte vara med när ni pratar om hur ofta jobb ska köras eller exakt hur ett API ser ut. Respektera allas tid, men vänta inte för länge med att låta verksamheten och IT komma överens.

Det ska inte ske under införandet.

Galen Low: Sista frågan. En lurig fråga.

Olivia Montgomery: En till?

Galen Low: Ja, en sista lurig fråga.

Anta att du är projektledare i en organisation där du ser att urvalsprocessen för programvara inte hanteras med tillräcklig noggrannhet. Kanske säger någon: Det där är min brors programvaruföretag, vi får ett bra pris.

Vad kan du göra och säga för att skapa mer struktur och minska partiskheten i urvalsprocessen?

Olivia Montgomery: Se till att du har en respektfull relation med personen som har den uppfattningen.

Kontrollera om personen faktiskt ansvarar för det slutliga beslutet. Ibland gör hen inte det, och då måste du vända dig till beslutsfattaren och säga: Jag behöver din hjälp och din auktoritet.

Om personen fattar beslutet ska du lyssna på hen och fråga om ni kan fylla i en leverantörsbedömningsmatris tillsammans. Förklara att du vill säkerställa att alla grunder är täckta och att du verkligen är engagerad i verktyget. Var inte avfärdande. Arbeta med relationen.

Ni kan använda en sokratisk metod. Fråga: Vad lärde du dig om integrationerna? Om svaret blir att de inte pratade om det kan ni säga: Bra, låt oss göra det. Låt oss fråga leverantören.

Genom att stegvis gå igenom kraven kan personen själv upptäcka att verktyget kanske inte är bäst – eller att det faktiskt är bäst. Tacka för informationen och föreslå ändå att ni jämför med åtminstone ett annat alternativ.

Var öppen och transparent. Verktyget måste fungera för IT, för verksamheten, för dagens behov och för framtida behov. Gör det tillsammans.

Galen Low: Fantastiskt. Jag älskar det.

Olivia, det var så trevligt att ha dig här. Jag tror att vi har gjort en riktigt djupdykning i urvalsprocessen för programvara, särskilt i demonstrationerna och beslutsprocessen efteråt.

Jag hoppas att våra lyssnare fick mycket värde av detta. Jag ser fram emot att ha dig tillbaka i programmet, eftersom det finns mycket mer att prata om och fler luriga frågor för mig att ställa.

Olivia Montgomery: Tack så mycket för att jag fick vara med. Jag hoppas att människor lärde sig något och kanske tänker annorlunda på urvalsprocesser och demonstrationer. Jag hoppas att de inte längre behöver frukta dem eller låta besluten köras över. Jag älskar alltid att prata med dig, Galen. Du är fantastisk. Tack så mycket.

Tack!

Galen Low: Vad tycker du? Är en programvarudemonstration värd teamets tid, eller är det mest en uppvisning som undviker en mer praktisk och djupgående utvärderingsperiod? Lämna dina tankar och berättelser i kommentarerna nedan.

Om du vill utveckla dina färdigheter som strategisk projektledare kan du gå med i vår gemenskap. Besök thedigitalprojectmanager.com/membership för att få tillgång till en stödjande gemenskap som delar kunskap, löser komplexa utmaningar och formar framtiden för vårt yrke – tillsammans.

Från gedigna mallar och månatliga utbildningstillfällen som sparar tid och energi till kamratstödet i vårt diskussionsforum, våra gemenskapsevenemang och mastermind-grupper innebär ett medlemskap att du har över tusen personer på din sida när du navigerar din karriär inom digital projektleverans.

Om du tyckte om det du hörde i dag kan du prenumerera och hålla kontakten på thedigitalprojectmanager.com.

Tills nästa gång. Tack för att du lyssnade.