Få mest mulig ut av en programvaredemonstrasjon

 

Les transkripsjonen:

Vi prøver ut et dataprogram for å transkribere podkastene våre. Tilgi eventuelle skrivefeil, siden roboten ikke er korrekt 100 % av tiden.

Galen Low: Nok en programvaredemonstrasjon fra en leverandør er i ferd med å gå helt galt. Teknologidirektøren og DevOps-lederen din ser ut til å spille buzzword-bingo med hvert eneste markedsføringsuttrykk presentatøren nevner. Daglig leder begynner å miste interessen idet temaene blir litt for tekniske. Og selv om personen som presenterer virkelig ser ut til å kunne sakene sine, er det ingen som ser ut til å ta opp elefanten i rommet: at personen faktisk er fetteren til toppsjefen din.

Finnes det ikke en måte å gjøre dette til en bedre bruk av alles tid på?

Hvis middelmådige demonstrasjoner har vært et hinder for å ta en informert beslutning om ny programvare for organisasjonen din, bør du lytte videre.

Vi skal gå gjennom noen av de mest effektive strategiene for å gjøre demonstrasjonsfasen i programvarevalgsprosessen langt mer relevant for organisasjonens spesifikke behov.

Hei alle sammen, og takk for at dere lytter! Jeg heter Galen Low og kommer fra The Digital Project Manager. Vi er et fellesskap av digitale fagfolk med et mål om å hjelpe hverandre med å utvikle ferdigheter, bli tryggere og knytte kontakter, slik at vi kan øke verdien av prosjektledelse i en digital verden. Hvis du vil høre mer om dette, kan du gå til thedigitalprojectmanager.com.

Greit. I dag snakker vi om prosessen med å velge ny programvare for prosjektteamene dine, og spesielt om hvordan du kan komme gjennom salgspresentasjonen i en programvaredemonstrasjon og forsikre deg om at verktøyet ikke bare er det beste verktøyet, men også det riktige verktøyet for måten teamene dine arbeider på. Med meg i dag har jeg Olivia Montgomery, Associate Principal Analyst hos Capterra og tidligere leder for IT-PMO, som nå rådgir små og mellomstore bedrifter om programvarevalg.

Hei, Olivia!

Olivia Montgomery: Hei, Galen! Takk for at jeg fikk komme.

Galen Low: Det var flott å ha deg med i programmet igjen. Hvordan har du det i Austin?

Olivia Montgomery: Det skjer mye spennende. South by Southwest pågår, og arrangementet er tilbake fysisk for første gang siden 2020. Byen er full av liv, og det er så mange arrangementer, foredrag og alle mulige ting som skjer. Det er en ganske spennende uke.

Galen Low: Tilbake for fullt. South by Southwest – jeg er kjempeentusiastisk. Det dukker opp i hele strømmen min på sosiale medier og alt mulig. Jeg har aldri kommet meg til Austin, men det virker som et så levende musikkmiljø. Det skjer så mye, og det er så mange konferanser og muligheter for folk til å møtes og ha det hyggelig.

Så nå høres det ut som om jeg ikke har noen unnskyldninger lenger. Dette kan bli året. Dette kan bli året.

Olivia Montgomery: Det er ganske kult. Det er definitivt teknologispor der. Jeg har kunnet delta på foredrag fra ledere innen forsyningskjeder, administrerende direktør i Amtrak, og John Deere er her og satser virkelig på teknologifokuset sitt. Det finnes VR-opplevelser som virkelig utforsker historiefortelling på nye måter, fra svært tunge og alvorlige temaer til lett underholdning, og hvordan vi kan samhandle med innhold og hverandre på andre måter.

Galen Low: Veldig kult. Hva har vært favoritten din så langt?

Olivia Montgomery: Bortsett fra all den faktiske teknologien og innovasjonen vi ser, fikk jeg se den nye Batmobile i virkeligheten. Det må jeg si var et høydepunkt for meg. Jeg er filmelsker. Jeg ser faktisk ikke trailere, så jeg har ikke sett noen trailer. Jeg har ikke sett Batman ennå på grunn av South by Southwest, men jeg så Batmobile for første gang i virkeligheten. Det var ganske kult.

Galen Low: Jeg tror det sannsynligvis er bedre enn en trailer.

Olivia Montgomery: Det tror jeg også. Jeg tenkte: «Greit, jeg skjønner det, jeg ser stemningen.» Nå gleder jeg meg virkelig til å se filmen.

Galen Low: Det er nettopp det jeg gleder meg mest til når ting åpner igjen, ikke sant? Å støte på det uventede – tingene du ikke planla å gjøre – er tilbake foran deg.

Fantastisk. Greit. La oss gå i gang.

La oss snakke om den mest pressede og tvilsskapende delen av programvarevalgsprosessen, nemlig demonstrasjonen. La meg begynne med å beskrive situasjonen.

La oss si at du har fått i oppgave å finne et nytt verktøy for organisasjonen din, og at du enten er den eneste beslutningstakeren eller leder utvalgskomiteen. Du har brukt utallige timer på å finne bruksområder. Du har samlet inn krav fra teamet. Du har fastsatt budsjetter sammen med ledelsen, og du har gjort masse research på nettet. Til slutt har du en kortliste over verktøy som ser ut til å passe, og nå vil du se dem i praksis.

Hvorfor er dette så presset og tvilsskapende? Jeg tror først og fremst det er fordi dette bokstavelig talt er kulminasjonen av alt arbeidet du har lagt ned så langt. Du samler alle interessentene. Du prøver å kommunisere alle kravene effektivt til programvareleverandørene. Du må ta til deg enorme mengder informasjon og reagere der og da, og alt skjer i det mest pressede miljøet av alle – et møte.

Så jeg tenkte at vi kanskje kunne begynne med motargumentene. Bør et team eller en organisasjon i det hele tatt bry seg med en demonstrasjon? Er det ikke bare en salgspresentasjon?

Olivia Montgomery: Gjennomfør demonstrasjoner, vær så snill. Jeg forstår. Jeg har deltatt på min del av demonstrasjoner som har vært svært salgsorienterte. Det var mye av dette som fikk meg til å begynne å utvikle ideer om hvordan de kunne bli bedre. Jeg tror på demonstrasjonsprosessen, og det finnes mye forberedelse og arbeid, særlig som prosjektleder, som du kan gjøre for å gjøre demonstrasjonene til en av de viktigste delene av utvelgelsesprosessen.

Så ja, gjennomfør demonstrasjoner, men de er ikke så enkle som å følge leverandørens ledelse. Det er der noen kan gå seg vill. Du bør i praksis styre og fastsette kravene til hva du ønsker å se i demonstrasjonen.

Galen Low: Jeg synes det er helt rimelig. Disse verktøyene har også mye dybde, ikke sant? I mange tilfeller velger vi et verktøy som skal gjøre mange forskjellige ting og være mange forskjellige ting for ulike mennesker. Men er det i det hele tatt mulig å dekke så mye i en demonstrasjon, utover å bare skrape i overflaten når det gjelder grunnleggende programvarefunksjoner? Hvilke strategier bør en organisasjon vurdere for å sikre at den får svarene den trenger?

Olivia Montgomery: Ja. Gode spørsmål.

For det første: Nei, du kan ikke dekke alt i en programvaredemonstrasjon. Det er her den tidligere nettbaserte researchen din kommer inn. Hvis du gjennomfører en RFP-prosess, eller når du har kommet ned til de to eller tre siste leverandørene du vurderer, bør du be dem sende deg all denne informasjonen i et dokument. Demonstrasjonen er ikke nødvendigvis det beste stedet å gå gjennom all funksjonaliteten du trenger.

Du bør konsentrere deg spesifikt om hvordan brukergrensesnittet ser ut, og de viktigste brukerhistoriene teamet ditt må følge. Hvilke forretningsprosesser må støttes av verktøyet? Og helt ærlig: Liker brukerne hvordan det ser ut og føles? Dette kan være første gang de bruker verktøyet og ser grensesnittet.

Derfor blir utseendet og brukeropplevelsen viktigere her. Den faktiske funksjonalitetslisten bør være skrevet ned før du signerer en kontrakt.

Galen Low: Det synes jeg er veldig viktig. Takk for det, for jeg rammet det inn tidligere som en kulminasjon, ikke sant? Alle veier leder frem til denne demonstrasjonen, men egentlig fyller demonstrasjonen bare noen av hullene.

Den er faktisk en del av researchprosessen. Det finnes ting du må se i praksis for å få en følelse av dem, slik du sa – brukergrensesnittet og bestemte bruksområder. Det handler ikke om at du har gjort all denne researchen og kan gjøre alle disse tingene, sett sammenligningstabellen og nå vil se hver eneste funksjon på to timer. Det ville sannsynligvis ikke gått særlig bra.

Det handler egentlig om at du allerede har sett alt dette på papiret, og at leverandøren har sendt deg flere detaljer. Nå kan dere planlegge en demonstrasjon der dere faktisk går i dybden på noen få ting som betyr noe.

Olivia Montgomery: Nettopp. Jeg anbefaler faktisk sterkt å planlegge to demonstrasjoner.

Jeg liker én forretningsorientert demonstrasjon og deretter én teknisk demonstrasjon. Hvis du kombinerer dem, blir det et svært langt og komplisert møte. Halvparten av interessentene vil ikke være interessert i den tekniske siden, og den andre halvparten vil ikke være interessert i forretningssiden. Derfor anbefaler jeg å dele dem opp av hensyn til interessentenes tid.

Du trenger også forskjellige personer i disse møtene. Det er ikke de samme personene. Jeg er derfor helt enig i at dette på en måte er et kontrolltrinn, men også fortsatt en videre innsamling av krav fra leverandøren. Så ja, planlegg to. Uansett om du ser på et prosjektstyringsverktøy, et regnskapsverktøy, et nytt ERP-system eller et annet programvareverktøy, liker jeg å følge omtrent samme struktur.

Den første er altså forretningsorientert. Ha forretningseieren med. Det er kanskje litt åpenbart, men du bør også inkludere superbrukeren. Det er ofte en leder eller fagansvarlig, altså personen som bruker verktøyet hver dag. Hensikten er å sikre at du vurderer verktøyet både fra et strategisk, langsiktig perspektiv og fra det praktiske brukerperspektivet.

Forretningseieren kan avgjøre om verktøyet vil støtte veksten og retningen deres, men superbrukeren må også være til stede for å se sin bestemte brukerhistorie. De vil vite at den sentrale funksjonen de må utføre, faktisk kan utføres, og hvordan det ser ut og føles.

Noen ganger har jeg hørt prosjektledere si at de ikke alltid får støtte til å ha med en superbruker i en av demonstrasjonene. Noen ganger er det for tidlig, og det finnes mange unnskyldninger. Men superbrukeren kommer til å følge prosjektet videre. Vedkommende ender sannsynligvis som kvalitetssikringsansvarlig under selve implementeringen.

Superbrukeren er hovedkilden til brukerkrav. Det er teamet som skal bruke verktøyet. De må være fornøyde med utseendet og brukeropplevelsen, som igjen er noe demonstrasjonen skal kontrollere. Derfor må du sørge for at begge disse personene deltar i demonstrasjonen.

En annen måte å legge til rette for dette på er å samle inn brukerhistorier fra teamet, og minst én eller to fra superbrukeren, og sende dem til leverandøren i god tid. Send dem flere dager før de planlagte demonstrasjonene, slik at leverandøren kan sette opp systemet og vise deg nøyaktig denne brukerhistorien. Du bør kunne si: «Som regnskapsfører trenger jeg å kunne kjøre rapporten for månedsavslutningen innen 24 timer, slik at jeg kan avslutte regnskapsmåneden.» Du må faktisk se dette skje i verktøyet.

En brukerhistorie skal ikke definere nøyaktig at du vil se en bestemt funksjon i verktøyet. Den åpner for at verktøyet kanskje har funnet en innovativ måte å oppnå eller utføre en funksjon på som du ikke har sett før. Du bør derfor ikke begrense leverandøren ved å si «vis meg bare dette», men samtidig må du være åpen.

Det viktigste er at superbrukeren får se sin sentrale funksjon. Forretningseierne har også krav de ønsker å se, vanligvis det ledelsesrettede kontrollpanelet. Hvordan ser det ut?

Hvordan ser verktøyet ut når jeg logger inn som leder eller toppsjef? Hvordan henter jeg rapportene mine fra kontrollpanelet? Dette er også noe du må se og oppleve, og du bør be leverandøren legge inn testdata for deg. Vanligvis setter de opp et sandkassemiljø for demonstrasjonen. Be dem forhåndslaste noen testdata, slik at du faktisk får se hvordan rapporteringsstrukturen ser ut og fungerer.

Galen Low: Dette er veldig interessant. Jeg liker tanken på å dele gruppen. Det kan virke litt kontraintuitivt når det gjelder en beslutningsprosess, men jeg liker ideen om to forskjellige demonstrasjoner fordi det er to forskjellige samtaler som må finne sted om verktøyet.

Det handler egentlig om best mulig bruk av folks tid. Noen ganger får vi motstand: «Nei, vi vil ikke involvere superbrukeren fra regnskap på dette stadiet, for det er for tidlig i prosessen.» Men det er faktisk en del av vurderingen av verktøyets langsiktige bruk og hvor dypt det skal brukes.

Det handler også om å kontrollere løsningen og gjøre superbrukeren til en slags forkjemper for utvelgelsesprosessen, fordi vedkommende var involvert. Hvis ikke, kan superbrukeren bli den høyeste stemmen i rommet som sier at det var en dårlig beslutning.

Jeg likte det du sa om en sandkasse. For noen mennesker er programvarevalg omtrent slik: Gjør arbeidet, gjennomfør demonstrasjonen, len deg tilbake og se på. Deretter sier du: «Greit, gi meg et praktisk miljø der jeg kan ta det dere nettopp viste meg, og prøve det selv.»

Men finnes det situasjoner der folk faktisk prøver det selv i et sandkassemiljø under demonstrasjonen – en praktisk demonstrasjon?

Olivia Montgomery: Jeg er sikker på at superbrukere gjerne ville hatt muligheten til det. En av fallgruvene er at du ønsker å velge programvaren som passer både til dagens prosesser og fremtidig situasjon. Noen ganger fokuserer demonstrasjonen bare på fremtidig situasjon.

Noen ganger tenker man at prosessene vil utvikle seg dramatisk og modnes automatisk når man får verktøyet og all automatiseringen. Men det er ikke nødvendigvis virkeligheten. Superbrukeren vil kunne vite hva som skjer fra første dag: Støtter dette dagens situasjon samtidig som det støtter fremtidig situasjon?

Jeg tror det kan være nyttig for superbrukeren å komme inn i sandkassen på forhånd. Da kan vedkommende se om verktøyet kan brukes i dag, samtidig som jobben fortsatt blir gjort, i stedet for at man slår det på og mister funksjonalitet.

Jeg vet ikke om de tekniske teamene dine vil sette pris på det, bry seg om det eller ha tid til det. Jeg er likevel en stor tilhenger av å være svært åpen og tydelig. Snakk med interessentene dine, og snakk med leverandøren om hva du trenger og hvilke ideer de har. På den måten kommer du gjennom salgspresentasjonen ved å ikke la leverandøren styre demonstrasjonen fullt ut, men du bør samtidig være åpen for at leverandøren kjenner løsningen.

Kanskje har de innovative måter å løse et problem på som du ikke har tenkt på. Derfor bør du være åpen for det også.

Galen Low: Det liker jeg. La oss snakke litt mer om forberedelsene til disse to demonstrasjonene. Har du noen gode historier eller eksempler på bruksområder et team bør be om å få gjennomgått for å sikre at programvaren faktisk fungerer slik den skal? Eller bare prosessen med å samle inn brukerhistoriene, slik du nevnte, på en måte som ikke begrenser den for mye?

Det skal ikke være slik at man sier «vis meg bare denne ene tingen», for hvis programvaren løser det på en annen måte, er det noe teamet bør få se.

Olivia Montgomery: Ja, absolutt. Hvis du er så heldig å ha en forretningsanalytiker innen IT som kan samle inn alle kravene for deg, er det fantastisk. Det er ikke vanlig. Selv om du har en slik person, har kanskje ikke superbrukeren gitt deg en brukerhistorie eller krav før og trenger hjelp.

Noe jeg har gjort tidligere, og som jeg liker, er å sende ut en undersøkelse til teamet, superbrukeren og lederne for avdelingene som skal bruke verktøyet. Jeg gir dem en struktur i stil med Mad Libs. «Som [rolle] trenger jeg å kunne [funksjon], slik at [formål].»

Det blir allerede en slags utfyllingsoppgave, og det hjelper dem raskt med å fylle inn feltene. Det er enkelt og lett for dem. Deretter kan du ta den nøyaktige brukerhistorien og sende den til leverandøren: «Dette er akkurat det jeg vil se.»

Så ja, jeg liker en Mad Libs-tilnærming.

Galen Low: Det liker jeg. Jeg er stor fan av Mad Libs og brukerhistorier, og her kombineres de. Det er en flott måte å se det på. Det lar leverandøren forme en demonstrasjon som viser hvordan programvaren løser behovet, samtidig som teamet kan få bekreftet at den faktisk gjør det. Veldig kult.

Olivia Montgomery: Å se det og vite at du liker utseendet og brukeropplevelsen, er den viktigste drivkraften i den forretningsorienterte demonstrasjonen. Jeg snakket også om den andre demonstrasjonen, den tekniske. Her kan brukerhistoriene omfatte hvor ofte jobbene kjøres. Må vi vente?

Kan vi planlegge jobbene til klokken ett om natten? De skal kjøre i én time – er det akseptabelt for virksomheten? Trenger vi dem oftere eller sjeldnere? Har vi kapasiteten? Det er her du må sørge for at de tekniske lederne dine og leverandørens tekniske leder deltar.

Systemadministratoren din må vite hvordan verktøyet fungerer, og den som eier og drifter IT-arkitekturen, må vite hvor dataene lagres. Drifter leverandøren dem? Er det greit? Drifter dere dem selv? Vet dere hvor? Det er mange tekniske detaljer som kan gi svært ubehagelige overraskelser hvis du venter til kontrakten skal signeres før dere snakker om dem.

Derfor må dette være en del av vurderingsprosessen. Når de to tekniske teamene møtes, kan de svare på spørsmål, vise hvordan løsningen ser ut og diskutere kapasitet. De kan spørre: «Krever dette spesialutviklet kode?» eller «Finnes denne funksjonen ferdig i løsningen?»

Dette er spørsmål forretningseieren og superbrukeren ikke nødvendigvis kan svare på. Som prosjektleder, med mindre du er teknisk prosjektleder, kjenner du kanskje heller ikke svarene. Derfor må du stille disse spørsmålene. Du bør også spørre om integrasjoner: Har noen av de eksisterende kundene deres en integrasjon med X og Y, altså de spesifikke verktøyene deres?

Ikke vær redd for å nevne verktøyene dere bruker, og spør om leverandøren allerede har integrasjoner med dem. Hvis de ikke har en eksisterende eller ferdig integrasjon, må du vurdere om det er en stopper. Må dere bygge en tilpasset integrasjon? Har dere ressurser til det? Vil leverandøren gjøre det for dere? Har dere tid? Dette er samtaler dere må ta.

Det kan høres ut som en overfylt samtale, men hvis du har gjort forarbeidet, er det egentlig ikke slik. De tekniske teamene vet hva de må spørre om, og du sparer deg selv for mye hodebry ved å ta samtalen nå i stedet for senere.

Galen Low: Det er et viktig poeng. Det er så mye som skal dekkes. Samtalen kan bli overfylt. Vi vil gjerne konsentrere oss om bestemte bruksområder, men et programvareprodukt, enten det er et CRM- eller ERP-system eller et innholdsstyringssystem, må gjøre mange forskjellige ting. Det tar tid å demonstrere og diskutere alt dette.

Hvordan velger og prioriterer du bruksområdene og spørsmålene du ønsker at leverandøren skal ta opp, uten at samtalen blir for omfattende?

Olivia Montgomery: Dette er et stort spørsmål. Du må støtte deg på teamlederne, forretningslederne og superbrukeren. Snakk med dem før demonstrasjonen: «Hva er de viktigste bekymringene deres? Hva må vi sørge for å dekke?»

La dem fortelle deg hva som er viktigst. Hvis du er en svært teknisk prosjektleder, kan du styre disse samtalene, og det er flott. Men mange av oss er ikke det. Stol på dem og spør: «Hva er de to eller tre tingene dere må se?»

Deretter sørger du for at de faktisk blir dekket i demonstrasjonen og holder dere på sporet. Du må også lede selve demonstrasjonen. Hvis noen går for dypt inn i et tema, kan du si: «Hei, jeg vil være sikker på at vi dekker de tre punktene.» Leverandører er vanligvis gode på tidsstyring fordi de har gjennomført mange demonstrasjoner, og de kan hjelpe deg med dette.

Men ikke vær redd for å gripe inn. For at det skal fungere, må du ha en forberedende samtale med dem som skal delta og si: «Dette er de tre tingene vi skal dekke.» Da blir de ikke overrasket og føler ikke at du avbryter eller avviser dem. De vet at dere har blitt enige om sporet, og det gjør det lettere å komme tilbake på rett kurs.

Galen Low: Jeg synes det er et viktig poeng. Som prosjektleder har du kontroll over noen områder og ansvar for å legge til rette for prosessen. Men noen beslutninger ligger hos andre, selv i et programvarevalgsprosjekt. Du har en sponsor og beslutningstakere, som ledelsen, og vi må stole på at ledergruppen prioriterer hva vi ønsker å få ut av en demonstrasjon.

Samtidig må vi samle innspill fra alle teamene som skal bruke verktøyet, slik at de kan fylle ut brukerhistoriene, få bruksområdene sine logget og dokumentert, og til syvende og sist få en stemme i prosessen.

Olivia Montgomery: Ja. Du kan alltid minne folk på at demonstrasjonen skal dekke tre eller kanskje fire svært fokuserte brukerhistorier som du har presentert for leverandøren, slik at de er forberedt.

Alt utover dette kan du be om å få skriftlig i RFP-en eller i den andre dokumentasjonen dere bruker. Du kan alltid si at dere trenger dokumentasjon på dette, og spørre hva det vil koste.

Etter demonstrasjonen bør du få en oversikt fra leverandøren: Dette er spesialutviklet kode, dette er funksjonaliteten dere ba om, dette er hva vi tror det vil koste, og dette er hvem som må bygge det. Programvare går generelt mot lavkode, slik at en utvikler, systemadministrator eller til og med virksomheten og superbrukeren kan sette opp mange arbeidsflyter selv.

Men dere må vite hvem som skal gjøre jobben. Må leverandøren skrive koden, eller må dere gjøre det selv? Det samme gjelder integrasjoner. For å unngå å gå for langt ned i detaljene under demonstrasjonen bør du minne alle på at detaljene kan dokumenteres, slik at dere kan gå videre med å se programvaren i bruk.

Galen Low: Det liker jeg. Jeg vil komme tilbake til noe. Vi har delt gruppen og satt opp to demonstrasjoner. Den ene har forretningsfokus, med superbruker og brukergrensesnitt. Den andre har IT-fokus, med infrastruktur, integrasjoner, kjøringer og planlegging.

Men på et tidspunkt må dette samles igjen. Bør hele utvelgelseskomiteen lage et vurderingsskjema, slik at de får sammenlignbare vurderinger av produktene på kortlisten? En måte å dokumentere tankene på, slik at de kan kvantifisere og vurdere oppfatningene og meningene sine når de møtes igjen?

Eller er dette en gammeldags måte å se det på, siden produktene og programvaren er så forskjellige? Kanskje noen er for komplekse til å sammenlignes med et vurderingsskjema. Hva tenker du?

Olivia Montgomery: Jeg er veldig glad for at du nevnte leverandørens vurderingsskjema. Jeg er en stor tilhenger av det. Det har absolutt fortsatt en plass. Når du kan redusere følelsesmessige reaksjoner, som ofte oppstår i salgsorienterte demonstrasjoner, bør du gjøre det. Du må kunne legge følelsene til side og huske hvorfor dere trenger programvaren.

Et vurderingsskjema hjelper dere med å beskrive problemet dere skal løse og sammenligne leverandørene. Du kan tenke: «Denne leverandøren var veldig imponerende.» Men når du kommer tilbake til skjemaet og ser spørsmål som «Dekker løsningen funksjonskravene våre?» og vurderer både forretningssiden og den tekniske siden, blir det tydelig at løsningen ikke passer hvis den ikke dekker begge.

Selv om forretningseieren elsker ett bestemt verktøy av emosjonelle grunner, har dere uten et vurderingsskjema eller en standardisert modell ingen dokumentasjon på hvordan beslutningen ble tatt. Skjemaene er nyttige i beslutningsdiskusjoner. Som prosjektleder anbefaler jeg også sterkt at du lagrer dem hver gang, fordi du aldri vet når prosjektet blir revidert.

Du vet aldri når noen vil stille spørsmål, eller om dere ønsker å bytte ut programvaren om noen år. Da kan dere se hvorfor dere ikke valgte en bestemt leverandør første gang. Kanskje leverandøren fikk én av fem på integrasjoner. Når dere tar opp kontakten igjen, kan dere undersøke om integrasjonene nå er på plass. Da får dere en informert og kunnskapsbasert beslutningsprosess.

Jeg støtter, anbefaler og liker leverandørens vurderingsskjema. Det gjør det mulig å samle informasjonen fra de ulike samtalene. Alle kan se hverandres vurderinger, enten dere bruker ett felles skjema eller samler inn skjemaer fra de viktigste interessentene.

Det avhenger av virksomhetens størrelse og systemets størrelse og kompleksitet. For et prosjektstyringsverktøy vil du sannsynligvis ha flere ledere som fyller ut sine egne skjemaer, før du som prosjektleder samler dem.

Og lagre dem. Jeg har selv opplevd en situasjon der CTO-en i en virksomhet sluttet kort tid etter at vi hadde innført et nytt ERP-system. Den nye CTO-en ville vite hvorfor vi brukte dette verktøyet og hvordan vi hadde valgt leverandøren. Jeg kunne vise til at beslutningen var informert og gjennomtenkt, og forklare hvorfor den ble tatt.

Det hjelper ikke bare relasjonsbyggingen med den nye interessenten, men også vedkommendes forståelse av virksomheten. De har nettopp begynt i et nytt selskap og trenger å forstå situasjonen.

Hvis du arbeider i et børsnotert selskap, vil revisorene særlig vite at dere ikke bare ga oppdraget til programvareselskapet til broren deres. De må se at dere tok beslutningen på en målt og standardisert måte.

Galen Low: Det er tre ting jeg vil trekke frem. Det første er at mange tenker på et leverandørskjema som veldig generelt, for eksempel en vurdering av brukergrensesnittet fra én til ti. Det kan være nyttig, men du sier egentlig at man bør være konkret: Hva prøver dere å oppnå? Hvorfor skaffer dere ny programvare?

Det er vurderingskriteriet. På en skala fra én til ti, hvor godt lar dette oss koble oss til resten av programvareøkosystemet og integrere for å skape flytende, strømlinjeformede og automatiserte prosesser?

Olivia Montgomery: Jeg liker faktisk at leverandørens vurderingsskjema er litt mindre spesifikt. En skala fra én til ti kan bli mye. Jeg anbefaler vanligvis å redusere den til én til fem og definere hva hvert tall betyr. Én kan bety at løsningen ikke oppfyller forventningene, fem at den overgår dem, eller dere kan bruke «oppfyller», «oppfyller ikke» og «overgår forventningene». Hvis funksjonen ikke finnes, er vurderingen null.

Galen Low: Ikke-eksisterende. Ja.

Olivia Montgomery: Jeg liker skalaen fra én til fem. Den er tydeligere og tvinger folk til å være mer bestemte. Matematikken blir også enklere, særlig hvis kriteriene vektes individuelt.

Galen Low: Jeg liker det. Jeg tenker på alle undersøkelsene med anbefalingsscore jeg får: «Hvor sannsynlig er det at du anbefaler dette verktøyet til en venn?» fra null til ti. Jeg lurer alltid på hva en sjuer egentlig betyr.

Olivia Montgomery: Du velger sju hvis du liker det de spør om, og tre hvis du ikke liker det. Det gjør alle. Det er ikke særlig nyttig.

En skala fra én til fem forenkler det og tvinger folk til å ta stilling og definere vurderingen. Uansett om du bruker et verktøy, et papir eller et regneark, må du forklare nøyaktig hva skalaen betyr. «Oppfyller forventningene», «oppfyller ikke forventningene» og «overgår forventningene» kan være nok.

Galen Low: Det liker jeg. Det andre jeg oppfatter, er at vurderingsskjemaet ikke nødvendigvis må være identisk for alle på alle områder. IT-teamet vurderer integrasjoner, sikkerhet og tekniske krav, mens forretningsteamet vurderer andre ting.

Så lenge alle bruker en konsekvent vurdering på tvers av verktøyene de vurderer, kan de ta med seg resultatene tilbake til gruppen uten å måtte vurdere noe som ligger utenfor ansvarsområdet deres.

Olivia Montgomery: Jeg anbefaler vanligvis én mal som inneholder både tekniske krav og forretningskrav. Deretter bør det være tydelig hvem som eier hvert område. Det tekniske teamet fyller ut integrasjonskrav, cybersikkerhet og andre tekniske punkter, mens ledelsen kan vurdere rapporteringspanelet.

Men all informasjon bør deles med alle. Dere kan skjule kolonner i versjonen som sendes til enkelte personer, men de bør se at kolonnene finnes.

Det er flere grunner til å bruke samme skjema. Det hjelper alle med å forstå at det finnes flere perspektiver enn deres eget. Det kan også avdekke interessante forskjeller. IT-lederen kan si at leverandøren ikke har noen eksisterende kunder med den aktuelle integrasjonen, mens forretningseieren har fått høre fra selgeren at den kan bygges.

Da kan skjemaet starte en viktig samtale: Er det en spesialutviklet integrasjon? Er den testet? Har andre kunder den? Finnes det risiko? Er dere villige til å ta den risikoen?

Et felles skjema hjelper alle med å komme på samme side, føle seg involvert og bli hørt. Det legger til rette for viktige samtaler før kontrakten signeres.

Galen Low: Det er et viktig poeng. Når vi snakker om tall, kan noen tro at vi bare legger alt inn i en datamaskin og får vite hvilken programvare vi skal velge. Men egentlig er skjemaet en drivkraft for samtalen. Hvor er det uenighet? Hvor må vi gå i dybden og spørre hva noen mente?

Den prosjektledernerdete siden av meg tenker på planleggingspoker. Hvis én person sier tre og en annen sier 21, må de snakke sammen, for det er et stort sprik.

Olivia Montgomery: Nettopp. Det er et grunnlag for samtalen og hindrer at diskusjonen blir opphetet eller emosjonell. Dere kan dele informasjonen og holde dere til tallene i stedet for en «han sa, hun sa»-diskusjon.

Galen Low: Når vi først snakker om nerding, kan vi kanskje gå dypere inn i innsamlings- og sammenstillingsprosessen? Du nevnte vektede vurderinger. Alle fyller ut skjemaet, og vi trenger et sted å lagre resultatene.

Hvordan ville du gått frem hvis du var en organisasjon? Hvilket verktøy ville du brukt? Hvilke møter ville du satt opp etter at alle demonstrasjonene var gjennomført? Hvordan legger du informasjonen frem for folk igjen, gjør beregningene og finner ut hvor det er behov for flere samtaler og hvem som bør delta?

Olivia Montgomery: Det er et stort spørsmål. Det finnes stor variasjon. Jeg tror på en standardisert, men tilpasset tilnærming. Alle interessenter er forskjellige, og alle virksomheter er forskjellige. Det samme gjelder modenheten i miljøet, forretningsprosessene, pengene og tiden dere har. Trenger dere systemet nå, eller skal det være en utskifting over seks måneder?

Som prosjektleder må du ha mange verktøy i verktøykassen, slik at du kan tilpasse deg situasjonen. For å begynne må du vite hva forventningene er. Forhåpentligvis kan du før demonstrasjonen finne ut hvem som faktisk tar den endelige beslutningen.

I en større virksomhet kan det være en styringskomité eller et IT-styringsutvalg du må presentere resultatene for. I en mindre virksomhet kan det være nok at IT-lederen og lederen for forretningsenheten blir enige. Du må vite dette før du planlegger demonstrasjonen, helst før du snakker med leverandørene.

Galen Low: Jeg tror det svarer på spørsmålet. Alle organisasjoner vil være forskjellige, men poenget er å ha fremsyn nok til å forberede seg og lage en plan, særlig hvis du er prosjektleder og leder prosessen.

Du må bruke både verktøyene og de mellommenneskelige ferdighetene dine til å navigere i komplekse og politiske samtaler. Du må kunne si: «Her er vurderingsmodellen vår. Her er leverandørskjemaet. Her skal vi lagre det. Slik forbereder vi møtene. Dette forteller vi leverandørene, og dette ber vi dem vise basert på brukerhistoriene og prioriteringene.»

Etter demonstrasjonene må du ha en plan for å samle all informasjonen og presentere den på en måte som legger til rette for en samtale, med de riktige personene rundt bordet. Når den endelige beslutningen skal tas, må beslutningstakerne, forretningseierne og de tekniske lederne samles.

Samtidig bør du skape et revisjonsspor, enten fordi dere kan bli revidert, eller fordi en ny CTO senere vil spørre hvorfor dere valgte denne løsningen. I stedet for å starte prosessen på nytt kan du vise hva dere gjorde, hvilke vurderinger dere tok og hvilke data dere baserte dere på.

Olivia Montgomery: Hvis det er vanskelig å få støtte til et leverandørskjema, kan dere fylle det ut sammen etter demonstrasjonene. Sett av 45 minutter og fyll det ut i fellesskap. Da blir verdien som samtale- og beslutningsverktøy mer aktiv og tydelig.

Mange ledere liker å diskutere ting sammen. Enten dere er i samme rom eller på forskjellige steder, kan dere vurdere leverandørene dere har sett og forhåpentligvis komme frem til en felles konklusjon.

Galen Low: Det liker jeg. Det er ikke en prøve, og de er ikke olympiske dommere. Dere kan gjøre det sammen. Det er en diskusjon.

Når alt er sagt og gjort, vil noen kanskje si at du ikke kan gjøre alle fornøyde når du velger programvare. Hvordan håndterer du forventningene underveis, slik at de som bidro med innspill og har en interesse i beslutningen, ikke blir misfornøyde med det endelige valget?

Olivia Montgomery: Dette er enda en grunn til at jeg liker leverandørens vurderingsskjema, særlig når kriteriene vektes. Husk hvorfor dere trenger et verktøy, ikke bare hvilket verktøy dere får. Ikke kall prosjektet «implementering av X-programvare» og oppkall det etter en bestemt leverandør.

Husk hvorfor dere trenger programvaren, for det kan lett bli glemt. Når folk er klare til å ta en beslutning og sier «Vi vil ha dette, bare kjøp det og slå det på», må du spørre om forslaget, kontrakten, demonstrasjonen og all annen informasjon faktisk løser forretningsproblemet.

Bruk vurderingsskjemaet som en standardisert og ikke-emosjonell måte å holde fokus på. En leverandør kan ha flotte funksjoner, men hvis den ikke kan integreres med e-postsystemet deres, og det er et absolutt krav, er den kanskje ikke riktig.

Galen Low: Jeg liker det. Jeg skrev ned: «Vurderingsskjema er lik åpenhet.» Ikke nødvendigvis automatisk, men det er slik det brukes.

Å være åpen om beslutningen gir et revisjonsspor, både for revisorer og for personer som senere spør hvorfor dere tok beslutningen. For dem som deltar i prosessen, gir det tydelighet og struktur. Alle forstår hva dere prøver å oppnå, hvorfor de blir involvert og hvorfor vurderingsskjemaet ser ut som det gjør.

Til slutt handler det om å kommunisere beslutningen tilbake til alle: «Dette valgte vi, og dette er grunnen. Takk for deltakelsen.» Det gjør ikke nødvendigvis alle fornøyde, men dere har en begrunnelse og riktig involvering underveis.

Olivia Montgomery: Du ønsker respekt for beslutningen. Folk trenger ikke å være fornøyde, men de må respektere beslutningen. Det kan de bare gjøre når diskusjonene har vært ærlige og åpne, og når de ser at dere ikke valgte løsningen fordi for eksempel broren til noen arbeider der.

Det er faktisk et reelt problem i mange virksomheter. Beslutningen trenger ikke å bli elsket, men den må respekteres.

Galen Low: Olivia, det er alltid flott å ha deg med. Det har vært mye nyttig i samtalen. Det jeg særlig tar med meg, er ideen om to demonstrasjoner. Intuitivt ønsker jeg å holde gruppen samlet fordi vi skal ta en beslutning sammen, men det betyr ikke at alle må se den samme demonstrasjonen.

Tvert imot er det sannsynligvis en dårlig idé, fordi det er så mye å dekke og samtalene er så forskjellige. Dere kan knytte det sammen med et vurderingsskjema og en felles diskusjon etterpå, slik at alle fortsatt involveres uten at folks tid sløses bort.

Olivia Montgomery: Superbrukeren trenger ikke å være til stede når dere snakker om hvor ofte jobbene skal kjøre eller nøyaktig hvordan API-et ser ut. Samtidig må du respektere alles tid, ikke hoppe over noe og ikke vente for lenge med å få forretning og IT til å bli enige.

Det bør ikke skje under implementeringen.

Galen Low: Siste spørsmål. Lurespørsmål.

Olivia Montgomery: Ett til?

Galen Low: Ja, bare for å avslutte.

La oss si at du er prosjektleder i en organisasjon der programvarevalgsprosessen ikke behandles grundig. Kanskje noen sier: «Det er brorens programvareselskap, så vi får en god pris.» Hva kan du gjøre? Hva kan du si for å skape mer struktur og redusere skjevheten i prosessen?

Olivia Montgomery: Sørg for å ha et respektfullt forhold til personen som har denne oppfatningen. Finn ut om vedkommende faktisk er ansvarlig for den endelige beslutningen. Hvis ikke, må du gå til beslutningstakeren og si at du trenger hjelp og myndighet.

Hvis personen tar beslutningen, kan du lytte til vedkommende og spørre om dere kan fylle ut et leverandørskjema sammen. Forklar at du vil forsikre deg om at alt er dekket, og at du faktisk er positiv til verktøyet. Ikke avvis personen. Arbeid med relasjonen, for du kan komme til å arbeide med vedkommende lenge.

Dere kan bruke en sokratisk metode: «Hva lærte du om integrasjonene?» Hvis svaret er at dere ikke snakket om dem, kan dere gjøre det nå. På den måten kan kravene avdekkes trinn for trinn, og personen kan selv oppdage at dette kanskje ikke er det beste verktøyet.

Kanskje er det faktisk det beste verktøyet. Da kan du si at informasjonen var nyttig, men at dere likevel må kontrollere løsningen mot minst ett annet alternativ.

Jeg kommer stadig tilbake til at man bør være åpen og tydelig. Forklar at løsningen må fungere for IT, forretningsenheten, dagens situasjon og fremtidig situasjon. Gjør det sammen.

Galen Low: Fantastisk. Jeg liker det.

Olivia, det var veldig hyggelig å ha deg med. Vi har gått grundig gjennom programvarevalgsprosessen, særlig demonstrasjonene og beslutningsprosessen etterpå.

Jeg håper lytterne fikk mye ut av dette, og jeg gleder meg til å ha deg tilbake i programmet. Det er mye mer vi kan snakke om, og flere lurespørsmål jeg kan stille.

Olivia Montgomery: Tusen takk for at jeg fikk komme. Jeg håper folk lærte noe og kanskje ser annerledes på programvarevalg og demonstrasjoner. Kanskje de ikke gruer seg like mye, og kanskje de ikke lar andre presse gjennom beslutninger. Jeg håper dette var nyttig. Jeg liker alltid å snakke med deg, Galen. Tusen takk.

Takk!

Galen Low: Hva synes du? Er en programvaredemonstrasjon verdt teamets tid, eller er den mest et skuespill som hopper over en mer praktisk og grundig evalueringsperiode? Legg igjen tanker og historier i kommentarfeltet nedenfor.

Hvis du vil utvikle ferdighetene dine som strategisk prosjektleder, kan du bli med i fellesskapet vårt. Gå til thedigitalprojectmanager.com/membership for tilgang til et støttende fellesskap som deler kunnskap, løser komplekse utfordringer og former fremtiden for faget vårt – sammen.

Fra robuste maler og månedlige opplæringsøkter som sparer deg for tid og energi, til støtten fra andre medlemmer i diskusjonsforumet, arrangementene og mastermind-gruppene våre: Å være medlem av fellesskapet betyr at du har over tusen mennesker i ryggen mens du navigerer karrieren din innen digital prosjektleveranse.

Hvis du likte det du hørte i dag, kan du abonnere og holde kontakten på thedigitalprojectmanager.com.

Til neste gang. Takk for at du lyttet.