Kuinka saat ohjelmistoesittelystä kaiken irti

 

Lue tekstitys:

Kokeilemme podcastiemme tekstittämistä ohjelmistolla. Pyydämme anteeksi mahdollisia kirjoitusvirheitä, sillä botti ei ole sataprosenttisen tarkka.

Galen Low: Jälleen yksi toimittajan ohjelmistoesittely on menossa pahasti pieleen. Teknologiajohtajasi ja DevOps-vetäjäsi vaikuttavat pelaavan muotisanabingoa jokaisen esittelijän mainitseman markkinointitermin kohdalla. Pääjohtajasi silmät alkavat lasittua aiheiden muuttuessa liian teknisiksi. Ja vaikka esittelijä vaikuttaa todella tuntevan asiansa, kukaan ei tunnu puhuvan huoneessa olevasta norsusta: siitä, että hän on itse asiassa toimitusjohtajasi serkku.

Eikö olisi olemassa tapaa käyttää kaikkien aikaa paremmin?

Jos vaisut esittelyt ovat vaikeuttaneet organisaatiosi uuden ohjelmiston tietoihin perustuvaa valintaa, jatka kuuntelemista.

Käymme läpi tehokkaimpia strategioita, joiden avulla ohjelmiston valintaprosessin esittelyvaiheesta tehdään paljon olennaisempi organisaatiosi erityistarpeiden kannalta.

Hei kaikille, kiitos kuuntelusta! Olen Galen Low The Digital Project Managerista. Olemme digitaalisten ammattilaisten yhteisö, jonka tavoitteena on auttaa toisiamme kehittämään taitoja, kasvattamaan itsevarmuutta ja verkostoitumaan, jotta voimme nostaa projektinhallinnan arvoa digitaalisessa maailmassa. Jos haluat kuulla lisää, siirry osoitteeseen thedigitalprojectmanager.com.

Tänään puhumme projektitiimien uuden ohjelmiston valintaprosessista ja erityisesti siitä, miten ohjelmistoesittelyn myyntipuheesta päästään olennaiseen ja varmistetaan, että työkalu ei ole ainoastaan paras työkalu vaan myös oikea työkalu tiimien työskentelytapaan. Kanssani on Olivia Montgomery, Capterran apulaispääanalyytikko osoitteesta Capterra sekä entinen IT:n PMO-johtaja, joka neuvoo nykyään pieniä ja keskisuuria yrityksiä ohjelmistojen valinnassa.

Hei, Olivia!

Olivia Montgomery: Hei, Galen! Kiitos kutsusta.

Galen Low: On hienoa saada sinut jälleen ohjelmaan. Miten Austinissa on mennyt?

Olivia Montgomery: Täällä on melko jännittävää. South by Southwest on käynnissä, ja se järjestetään taas paikan päällä ensimmäistä kertaa vuoden 2020 jälkeen. Kaupunki on eläväinen, ja täällä on valtavasti tapahtumia, keskusteluja ja kaikenlaista muuta. Tämä viikko on todella jännittävä.

Galen Low: Taas mennään. South by Southwest innostaa minua todella paljon. Se näkyy kaikkialla sosiaalisen median syötteessäni. En ole koskaan päässyt Austiniin, mutta siellä on niin eloisa musiikkiyhteisö. Tapahtumia, konferensseja ja tapoja kokoontua yhteen ja pitää hauskaa on valtavasti.

Kuulostaa siltä, ettei minulla ole enää tekosyitä. Ehkä tämä on se vuosi.

Olivia Montgomery: Se on todella hienoa. Täällä on ehdottomasti myös teknologia-aiheisia kokonaisuuksia. Olen päässyt kuuntelemaan toimitusketjujen johtajia, Amtrakin toimitusjohtajaa ja John Deereä, joka painottaa vahvasti teknologiaansa. Lisäksi tarjolla on virtuaalitodellisuuskokemuksia, jotka keskittyvät tarinankerrontaan uusilla tavoilla aina vakavista aiheista kevyempään viihteeseen sekä siihen, miten voimme olla vuorovaikutuksessa sisällön ja toistemme kanssa eri tavoin.

Galen Low: Hienoa. Mikä on ollut tähän mennessä suosikkisi?

Olivia Montgomery: Kaiken varsinaisen teknologian ja innovaation lisäksi näin uuden Batmobilen paikan päällä. Se oli minulle kohokohta. Olen elokuvaharrastaja. En oikeastaan katso trailereita, joten en ole nähnyt yhtäkään. En ole vielä nähnyt Batmania South by Southwestin takia, mutta näin Batmobilen ensimmäistä kertaa paikan päällä. Se oli todella hienoa.

Galen Low: Se on varmasti parempi kuin traileri.

Olivia Montgomery: Luulen niin. Ajattelin vain, että nyt ymmärrän tunnelman ja olen todella innoissani elokuvan näkemisestä.

Galen Low: Sitä minäkin odotan, kun asiat jälleen avautuvat: odottamattomiin asioihin törmäämistä ja sitä, että suunnittelemattomat kokemukset palaavat eteemme.

Hienoa. Mennään asiaan.

Puhutaan ohjelmiston valintaprosessin paineisimmasta ja eniten epäilyksiä herättävästä osasta eli esittelystä. Aloitetaan tilanteen kuvaamisesta.

Oletetaan, että tehtäväksesi on annettu uuden työkalun etsiminen organisaatiollesi ja olet joko ainoa päätöksentekijä tai johdat valintakomiteaa. Olet käyttänyt lukemattomia tunteja käyttötapausten löytämiseen. Olet kerännyt vaatimuksia tiimiltä, laatinut budjetin johdon kanssa ja tehnyt paljon verkkotutkimusta. Lopulta sinulla on lyhyt lista työkaluista, jotka vaikuttavat sopivan tarpeisiin, ja haluat nähdä ne toiminnassa.

Miksi tilanne on niin paineinen ja epäilyksiä herättävä? Mielestäni ennen kaikkea siksi, että kyseessä on kaikkien tähänastisten ponnistelujesi konkreettinen huipentuma. Koordinoit kaikkia sidosryhmiä. Yrität viestiä kaikki vaatimukset tehokkaasti ohjelmistotoimittajille. Sinun odotetaan omaksuvan valtavan määrän tietoa ja reagoivan heti, ja kaikki tapahtuu kaikkein paineisimmassa ympäristössä eli kokouksessa.

Ajattelin, että voisimme aloittaa vastustajien argumenteista. Kannattaako tiimin tai organisaation edes vaivautua esittelyyn? Eikö se ole vain myyntipuhe?

Olivia Montgomery: Käykää esittelyissä, ehdottomasti. Ymmärrän kyllä. Olen osallistunut moniin hyvin myyntipainotteisiin esittelyihin. Se oli yksi syy siihen, että aloin pohtia, miten niistä voisi tehdä parempia. Uskon esittelyprosessiin, ja erityisesti projektipäällikkö voi valmistautumalla ja tekemällä paljon työtä tehdä esittelystä yhden valintaprosessin tärkeimmistä osista.

Kyllä, käykää esittelyissä, mutta ne eivät ole niin helppoja kuin toimittajan johdon seuraaminen. Siinä jotkut voivat mennä pieleen. Teidän pitää itse ohjata ja määrittää olennaisesti vaatimukset sille, mitä haluatte esittelyssä nähdä.

Galen Low: Se on mielestäni reilua. Näissä työkaluissa on myös paljon syvyyttä. Usein valitsemme työkalun tekemään monia eri asioita ja palvelemaan monia eri käyttäjiä. Onko esittelyssä edes mahdollista käsitellä näin laajaa kokonaisuutta muuten kuin raapaisemalla ohjelmiston perusominaisuuksien pintaa? Millaisia strategioita organisaation kannattaisi käyttää varmistaakseen tarvitsemiensa vastausten saamisen?

Olivia Montgomery: Erinomainen kysymys.

Ensinnäkin kaikkea ei voi käsitellä ohjelmistoesittelyssä. Siksi aiemmin tekemäsi verkkotutkimus on tärkeää. Jos käytätte tarjouspyyntöprosessia tai olette päässeet kahden tai kolmen loppuvaiheen toimittajan joukkoon, pyytäkää heitä lähettämään kaikki tiedot asiakirjana. Esittely ei ole paras paikka käydä läpi jokaista tarvitsemaanne toimintoa.

Keskittykää nimenomaan käyttöliittymän ulkoasuun ja muutamaan keskeiseen käyttäjätarinaan, joita tiiminne tarvitsee seurata. Mitä liiketoimintaprosesseja työkalun on tuettava? Ja rehellisesti: pitävätkö käyttäjät sen ulkoasusta ja tuntumasta? Tämä voi olla heidän ensimmäinen kertansa työkalun ja käyttöliittymän parissa.

Siksi ulkoasu ja käyttötuntuma ovat tässä keskeisempiä. Varsinaisen toiminnallisuusluettelon pitäisi olla kirjattuna ennen sopimuksen allekirjoittamista.

Galen Low: Tämä on todella tärkeää. Kiitos siitä, sillä kuvasin aiemmin tilannetta eräänlaisena huipentumana, johon kaikki tiet johtavat. Todellisuudessa esittely vain täyttää joitakin aukkoja.

Se on osa tutkimusprosessia. On asioita, jotka täytyy nähdä toiminnassa, jotta niistä saa tuntuman, kuten mainitsemasi käyttöliittymä ja tietyt käyttötapaukset. Tarkoitus ei ole, että olen tehnyt kaiken tutkimuksen, katsonut vertailutaulukkoa ja pyydän nyt näyttämään kaikki ominaisuudet kahden tunnin aikana. Se ei todennäköisesti toimisi hyvin.

Parempi lähtökohta on, että tunnemme kaiken paperilla, olet lähettänyt meille lisätietoja ja nyt sovimme esittelystä, jossa voimme perehtyä muutamaan tärkeään asiaan.

Olivia Montgomery: Juuri niin. Suosittelen vahvasti kahden esittelyn järjestämistä.

Järjestäisin liiketoimintaan keskittyvän esittelyn ja teknisen esittelyn. Niiden yhdistäminen tekisi kokouksesta hyvin pitkän ja monimutkaisen. Puolet sidosryhmistä ei olisi kiinnostunut teknisestä puolesta ja toinen puoli liiketoimintapuolesta. Siksi suosittelen jakamaan ne, jotta sidosryhmien aikaa kunnioitetaan.

Myös kokouksiin tarvitaan eri ihmiset. Kaikki eivät ole samoja henkilöitä. Olen siis vahvasti samaa mieltä siitä, että kyseessä on eräänlainen tarkistusvaihe, mutta samalla myös lisävaatimusten keräämistä toimittajalta. Järjestäkää siis kaksi esittelyä. Emme puhu nyt siitä, onko kyseessä projektinhallintatyökalu, taloushallinnon työkalu, uusi toiminnanohjausjärjestelmä tai mikä tahansa muu ohjelmisto. Noudattaisin kaikissa suurin piirtein samaa esittelyrakennetta.

Ensimmäinen esittely keskittyy liiketoimintaan. Mukaan tarvitaan liiketoiminnan omistaja. Se on ehkä ilmeistä, mutta mukaan kannattaa ottaa myös tehokäyttäjä. Hän on usein valvoja, tiiminvetäjä tai henkilö, joka käyttää työkalua päivittäin. Tavoitteena on varmistaa, että tarkastelette työkalua sekä strategisesta pitkän aikavälin näkökulmasta että käytännön käyttäjän näkökulmasta.

Liiketoiminnan omistaja voi päättää, että työkalu tukee kasvua ja tulevaisuuden suuntaa. Tehokäyttäjän on kuitenkin nähtävä oma käyttäjätarinansa. Hänen pitää tietää, että keskeinen tehtävä voidaan suorittaa ja miltä se näyttää ja tuntuu.

Olen kuullut projektipäälliköiltä, etteivät he aina saa hyväksyntää tehokäyttäjän osallistumiselle kumpaankaan esittelyyn. Joskus on liian aikaista tai esitetään monenlaisia tekosyitä. Tehokäyttäjä kuitenkin osallistuu todennäköisesti myös projektin loppuosaan ja toimii usein laadunvarmistajana varsinaisen käyttöönoton aikana.

Hän on tärkein käyttäjävaatimusten lähde. Hän kuuluu tiimiin, joka tulee käyttämään työkalua. Hänen täytyy olla tyytyväinen sen ulkoasuun ja käyttötuntumaan, joiden arviointi on jälleen yksi esittelyn tärkeimmistä tehtävistä. Siksi molempien henkilöiden pitää olla mukana.

Yksi tapa valmistella tilannetta on kerätä tiimiltä käyttäjätarinoita, joista vähintään yksi tai kaksi tehokäyttäjältä, ja lähettää ne toimittajalle hyvissä ajoin ennen esittelyä. Näin toimittaja voi määrittää järjestelmän niin, että se näyttää juuri kyseisen käyttäjätarinan toteutuksen. Haluat ehkä nähdä, kuinka kirjanpitäjä voi suorittaa kuukauden päätösraportin 24 tunnin kuluessa, jotta kuukausi voidaan sulkea. Tämä pitää nähdä tapahtuvan työkalussa.

Käyttäjätarina ei tarkoita, että määrittelet tarkalleen yhden tietyn toiminnon, jonka haluat nähdä. Se antaa toimittajalle mahdollisuuden näyttää innovatiivisen tavan toteuttaa tehtävä, jota et ehkä ole aiemmin nähnyt. Toimittajaa ei siis pidä rajata liikaa, mutta tehokäyttäjän on silti voitava nähdä keskeinen tehtävänsä.

Myös liiketoiminnan omistajalla on vaatimuksia. Hän haluaa yleensä nähdä esimerkiksi johdon koontinäytön. Miltä työkalu näyttää, kun kirjaudun sisään päällikkönä, johtajana tai toimitusjohtajana? Miten saan raportit koontinäytölleni? Nämä näkymät täytyy nähdä ja toimittajaa kannattaa pyytää syöttämään järjestelmään testitietoja. Toimittaja yleensä määrittää esittelyä varten testiympäristön. Pyytäkää häntä lataamaan sinne testitietoja, jotta raportointirakenteesta saa todellisen käsityksen.

Galen Low: Tämä ajatus ryhmän jakamisesta on todella kiinnostava. Päätöksenteossa se voi tuntua vastakkaiselta intuitiolle, mutta pidän ajatuksesta, että esittelyjä on kaksi, koska työkalusta täytyy käydä kaksi erilaista keskustelua.

Kyse on lopulta ihmisten ajan parhaasta käytöstä. Joskus vastustetaan esimerkiksi kirjanpidon tehokäyttäjän osallistumista, koska prosessi on liian alkuvaiheessa. Todellisuudessa hänen osallistumisensa auttaa arvioimaan sekä työkalun pitkän aikavälin käyttöä että käytön syvyyttä.

Samalla tehokäyttäjästä voi tulla valinnan puolestapuhuja, koska hän on osallistunut prosessiin. Jos hän ei osallistu, hän saattaa myöhemmin olla äänekkäin henkilö sanomassa, että päätös oli huono.

Pidin myös maininnastasi testiympäristöstä. Usein ensin tehdään työ ja sitten seurataan esittelyä sivusta. Olisi kuitenkin hyödyllistä saada käytännön ympäristö, jossa voisi itse kokeilla esittelyssä nähtyjä asioita. Voivatko ihmiset kokeilla työkalua testiympäristössä jo esittelyn aikana?

Olivia Montgomery: Tehokäyttäjät varmasti haluaisivat mahdollisuuden siihen. Yksi ongelma on, että ohjelmiston pitäisi sopia nykyisiin prosesseihin ja tulevaan toimintamalliin. Joskus esittely keskittyy vain tulevaisuuden toimintamalliin.

Ajatellaan, että työkalun hankkimisen jälkeen prosessit muuttuvat dramaattisesti ja kypsyvät automaattisesti kaiken saavutettavan automaation avulla. Se ei kuitenkaan ole todellisuutta. Tehokäyttäjä tietää, mitä työkalulla voidaan tehdä ensimmäisestä päivästä lähtien. Hän näkee, tukeeko työkalu nykytilaa ja tulevaa toimintamallia.

Testiympäristöön pääseminen etukäteen voisi auttaa tehokäyttäjää arvioimaan, voiko hän käyttää työkalua jo tänään niin, että työ tulee tehdyksi ilman toiminnallisuuden menettämistä.

Tekninen tiimi ei välttämättä ehdi tai halua tehdä tätä. Olen silti avoimuuden ja suoruuden kannattaja. Keskustele sidosryhmien ja toimittajan kanssa siitä, mitä tarvitsette ja millaisia ideoita heillä on. Näin ette anna toimittajan ohjata esittelyä täysin, mutta hyödynnätte samalla heidän ratkaisunsa tuntemusta. Heillä voi olla innovatiivisia tapoja lähestyä ongelmaa, joita ette itse ole ajatelleet. Myös sille pitää jättää tilaa.

Galen Low: Pidän tuosta. Puhutaan lisää näihin kahteen esittelyyn valmistautumisesta. Millaisia käyttötapauksia tiimin pitäisi pyytää käytäväksi läpi varmistaakseen, että ohjelmisto toimii? Entä miten käyttäjätarinoita kerätään niin, etteivät ne rajoita liikaa vaihtoehtoja?

Olivia Montgomery: Jos käytettävissä on IT-liiketoiminta-analyytikko, hän voi kerätä kaikki vaatimukset. Se olisi hienoa, mutta ei tavallista. Vaikka tällainen henkilö olisi käytettävissä, tehokäyttäjä ei välttämättä ole aiemmin kirjoittanut käyttäjätarinaa tai määrittänyt vaatimuksia ja tarvitsee apua.

Olen esimerkiksi lähettänyt kyselyn tiimille, tehokäyttäjälle ja niiden osastojen vetäjille, jotka tulevat käyttämään työkalua. Olen antanut heille täytettävän rakenteen: käyttäjätarina alkaa sanoilla "roolissani ___ tarvitsen mahdollisuuden ___, jotta voin ___". Tällainen rakenne auttaa täyttämään kohdat nopeasti ja helposti. Sen jälkeen tarkan käyttäjätarinan voi lähettää toimittajalle.

Galen Low: Pidän siitä todella paljon. Olen suuri käyttäjätarinoiden ja täydennystehtävien fani, ja tässä ne yhdistyvät. Se jättää toimittajalle tilaa näyttää, miten heidän ohjelmistonsa ratkaisee tarpeen, mutta varmistaa samalla, että tiimi saa vahvistuksen siitä, että vaadittu tehtävä onnistuu.

Olivia Montgomery: Ulkoasun ja käyttötuntuman näkeminen on liiketoimintaan keskittyvän esittelyn tärkein tavoite. Toinen esittely keskittyy tekniseen puoleen. Käyttäjätarinoissa voidaan käsitellä esimerkiksi sitä, kuinka usein työtehtävät suoritetaan, pitääkö niiden valmistumista odottaa ja voidaanko ne ajoittaa aamuyölle. Teknisen vetäjän ja toimittajan teknisen vetäjän pitää olla mukana.

Järjestelmänvalvojan täytyy tietää, miten työkalu toimii ja kuka omistaa ja käyttää IT-arkkitehtuuria. Insinöörin täytyy tietää, missä tiedot säilytetään, isännöikö toimittaja niitä ja sopiiko se teille. Jos nämä keskustelut käydään vasta sopimusta allekirjoitettaessa, seurauksena voi olla epämiellyttäviä yllätyksiä.

Teknisen tiimin pitää kysyä esimerkiksi, vaatiiko toiminto mukautettua koodia vai löytyykö se suoraan tuotteesta. Yrityksen omistaja ja tehokäyttäjä eivät yleensä tiedä vastauksia näihin kysymyksiin, eikä projektipäällikkökään välttämättä tiedä, ellei hän ole tekninen projektipäällikkö. Myös integraatioista pitää kysyä: onko toimittajan nykyisillä asiakkailla integraatioita käyttämienne työkalujen kanssa?

Älkää pelätkö nimetä käyttämiänne työkaluja ja kysyä, onko niihin olemassa integraatioita. Jos valmiiksi integroitua ratkaisua ei ole, pitää arvioida, onko mukautetun integraation rakentamiseen resursseja, aikaa ja toimittajan tukea.

Tämä ei ole paisunut keskustelu, jos olette valmistautuneet. Tekninen tiimi tietää, mitä kysyä, ja säästätte paljon vaivaa, kun käsittelette asiat riittävän aikaisin.

Galen Low: Tämä on suuri asia. Käsiteltävää on paljon, vaikka haluamme keskittyä tiettyihin käyttötapauksiin. Miten käyttötapaukset ja toimittajalle esitettävät kysymykset valitaan ja asetetaan tärkeysjärjestykseen?

Olivia Montgomery: Kysy tiiminvetäjiltä, liiketoiminnan johtajilta ja tehokäyttäjältä, mitkä ovat heidän tärkeimmät huolenaiheensa ja mitä heidän täytyy nähdä. Jos et ole tekninen projektipäällikkö, nojaa heihin. Kysy, mitkä kaksi tai kolme asiaa heidän on ehdottomasti nähtävä.

Projektipäällikön tehtävä on myös ohjata esittelyä. Jos joku syventyy liikaa yhteen asiaan, voit muistuttaa, että kolme tärkeintä kohtaa täytyy vielä käsitellä. Toimittajat osaavat yleensä hallita aikaa, mutta myös sinun pitää tarvittaessa puuttua tilanteeseen.

Jotta tämä toimisi, käy ennen esittelyä keskustelu kaikkien osallistujien kanssa ja sovi yhdessä, mitkä kolme asiaa käsitellään. Näin kukaan ei ylläty eikä koe, että hänet keskeytetään tai sivuutetaan.

Galen Low: Projektipäällikkönä hallitset monia prosessin osia ja vastaat niiden järjestämisestä. Jotkin päätökset kuuluvat kuitenkin sponsorille, päätöksentekijöille ja johtoryhmälle. Heidän on priorisoitava, mitä esittelystä halutaan saada irti, samalla kun eri tiimien näkemykset kerätään ja dokumentoidaan.

Olivia Montgomery: Esittelyssä kannattaa muistuttaa, että tavoitteena on käsitellä kolme tai neljä tarkasti rajattua käyttäjätarinaa, jotka on annettu toimittajalle etukäteen. Kaikesta muusta voi pyytää kirjallisen vastauksen tarjouspyyntöön tai muuhun dokumentaatioon. Pyytäkää esittelyn jälkeen erittely esimerkiksi mukautetusta koodista, kustannuksista, vastuista ja integraatioista.

Näin keskustelu ei uppoa yksityiskohtiin, vaan kaikki olennaiset asiat dokumentoidaan ja voidaan jatkaa ohjelmiston toiminnan tarkastelua.

Galen Low: Pidän tästä. Olemme jakaneet ryhmän kahtia: toinen esittely keskittyy liiketoimintaan ja toinen IT:hen. Jossain vaiheessa asiat pitää kuitenkin yhdistää. Kannattaako koko valintakomitean laatia jonkinlainen pisteytyskortti, jotta loppuvaiheen tuotteita voidaan verrata toisiinsa ja ryhmän ajattelu dokumentoida?

Olivia Montgomery: Olen suuri toimittajien pisteytyskorttien kannattaja. Ne ovat edelleen erittäin hyödyllisiä. Kun myyntipainotteinen esittely herättää tunteita, pisteytyskortti auttaa vähentämään tunneperäisiä reaktioita ja palauttaa mieleen, miksi ohjelmistoa alun perin hankitaan.

Pisteytyskortissa voidaan vertailla toimittajia esimerkiksi toiminnallisuuden, liiketoiminnan vaatimusten ja teknisten vaatimusten perusteella. Jos työkalu ei täytä molempia kokonaisuuksia, se ei ole hyvä vaihtoehto.

Ilman pisteytyskorttia tai muuta yhdenmukaista arviointitapaa päätöksestä ei jää jälkeä. Pisteytyskortti auttaa päätöksentekokeskusteluissa, ja projektipäällikkönä suosittelen säilyttämään ne aina. Projekti voidaan myöhemmin auditoida tai joku voi kysyä, miksi tietty toimittaja valittiin.

Kun palaatte asiaan myöhemmin, voitte nähdä, että toimittaja sai esimerkiksi integraatioista arvosanan yksi. Jos integraatio on sittemmin rakennettu, päätös voidaan arvioida uudelleen tietoon perustuen.

Pisteytyskortti kokoaa eri lähteistä saadun tiedon yhteen. Kaikki voivat nähdä toistensa arviot, olipa käytössä yksi yhteinen kortti tai jokaisella keskeisellä sidosryhmällä oma korttinsa.

Galen Low: Kuulostaa siltä, että pisteytyskortin pitää olla paljon konkreettisempi kuin yleinen käyttöliittymäarvio.

Olivia Montgomery: Kyllä. Pidä asteikko mieluummin välillä 1–5 kuin 1–10 ja määrittele, mitä kukin arvo tarkoittaa. Esimerkiksi täyttää odotukset, ei täytä odotuksia, ylittää odotukset tai toiminto puuttuu kokonaan.

Galen Low: Se tekee arvioinnista selkeämpää. Sama kriteeri pitää soveltaa johdonmukaisesti eri ohjelmistoihin.

Olivia Montgomery: Aivan. Yksi yhteinen pisteytysmalli, jossa liiketoiminnan ja tekniset vaatimukset ovat mukana, on yleensä paras. On kuitenkin selvitettävä, kuka vastaa mistäkin kohdasta. Tekninen tiimi arvioi integraatioita ja kyberturvallisuutta, kun taas johtajat voivat arvioida raportointikoontinäyttöä.

Kaikki tieto kannattaa silti jakaa kaikille. Sama pisteytyskortti auttaa ymmärtämään, että päätökseen vaikuttaa useita näkökulmia. Se paljastaa myös ristiriidat, kuten tilanteen, jossa myyjä lupaa toiminnon mutta IT-tiimi tietää, että se vaatisi testaamattoman mukautetun integraation.

Yksi yhteinen pisteytyskortti auttaa kaikkia pysymään samalla sivulla, tuntemaan itsensä kuulluiksi ja käymään tärkeät keskustelut ennen sopimuksen allekirjoittamista.

Galen Low: Se on tärkeä huomio. Pisteytyskortti ei kerro tietokonemaisesti, minkä ohjelmiston valitsemme, vaan toimii keskustelun käynnistäjänä. Jos yksi antaa arvosanan kolme ja toinen 21, heidän pitää keskustella siitä, miksi arviot eroavat niin paljon.

Olivia Montgomery: Juuri niin. Se tarjoaa keskustelulle perustan ja pitää sen poissa tunnepitoisesta väittelystä. Huomio siirtyy numeroihin ja perusteluihin.

Galen Low: Miten pisteytyskorttien kerääminen, yhdistäminen ja käsittely käytännössä toteutetaan? Mitä työkaluja ja kokouksia käyttäisit ja miten päätät, ketkä osallistuvat jatkokeskusteluihin?

Olivia Montgomery: Jokainen organisaatio on erilainen. Tarvitaan standardoitu mutta mukautettava lähestymistapa. Sidosryhmät, liiketoiminnan kypsyys, prosessien kypsyys, käytettävissä oleva raha ja aika sekä ohjelmiston kiireellisyys vaikuttavat kaikki.

Projektipäälliköllä pitää olla useita työkaluja käytössään ja kyky mukautua tilanteeseen. Ennen esittelyjen aikatauluttamista pitää selvittää, ketkä tekevät lopullisen päätöksen. Suuressa yrityksessä päätös voidaan esitellä ohjausryhmälle tai IT:n ohjauskomitealle. Pienemmässä yrityksessä päätöksen voivat tehdä IT-johtaja ja liiketoimintayksikön johtaja yhdessä.

Nämä tiedot pitää selvittää ennen toimittajien kanssa keskustelemista, jotta tiedät, kenelle tulokset lopulta esitetään.

Galen Low: Jokainen organisaatio on erilainen, mutta valmistautumisen ja suunnitelman merkitys on sama. Projektipäällikön pitää tietää, missä pisteytyskortit säilytetään, miten kokoukset valmistellaan, mitä toimittajilta pyydetään näyttämään ja miten tulokset tuodaan takaisin oikeiden ihmisten käsiteltäviksi.

Lopulliseen päätökseen tarvitaan päätöksentekijät, liiketoiminnan omistajat ja tekniset vetäjät. Prosessista pitää myös jäädä tarkastettava jälki, jotta päätös voidaan perustella myöhemmin.

Olivia Montgomery: Jos pisteytyskortin käyttöönotto tuntuu vaikealta, voitte täyttää yhden kortin yhdessä esittelyjen jälkeen. Varaa esimerkiksi 45 minuutin kokous ja täyttäkää kortti yhteisesti. Näin kortista tulee aktiivinen keskustelu- ja päätöksentekoväline.

Olipa kaikki samassa huoneessa tai eri paikoissa, arvioikaa yhdessä kaikki esitellyt toimittajat ja pyrkikää yhteisymmärrykseen kokouksen lopussa.

Galen Low: Pidän tästä. Kyse ei ole kokeesta, eikä kukaan ole olympiatuomari. Arviointi voidaan tehdä yhteistyössä.

Kun kaikki on päätetty, kaikki eivät ehkä ole tyytyväisiä. Miten matkan varrella hallitaan niiden ihmisten odotuksia, jotka antoivat päätökseen panoksensa?

Olivia Montgomery: Pisteytyskortti auttaa erityisesti silloin, kun kriteerit painotetaan. Muistakaa, miksi työkalua tarvitaan, älkääkä vain sitä, mikä työkalu hankitaan. Älkää nimetkö projektia jonkin toimittajan ohjelmiston käyttöönottoprojektiksi. Pitäkää mielessä ratkaistava liiketoimintaongelma.

Kysykää jatkuvasti, ratkaisevatko toimittajan lupaukset, tarjous, sopimus ja esittely sen ongelman, jota olette ratkaisemassa. Pisteytyskortti pitää arvioinnin standardoituna ja vähemmän tunnepitoisena.

Joku voi pitää yhdestä työkalusta, koska sen raportointikoontinäyttö on hieno, mutta jos se ei integroidu välttämättömään sähköpostijärjestelmään, se ei ehkä ole oikea ratkaisu. Palatkaa aina kysymykseen: ratkaiseeko tämä liiketoimintaongelman? Älkää keskittykö vain uusiin ja näyttäviin ominaisuuksiin.

Galen Low: Pisteytyskortti tarkoittaa minulle läpinäkyvyyttä. Se luo perustelut ja tarkastusjäljen, mutta myös auttaa kaikkia ymmärtämään, mitä yritetään saavuttaa ja miksi heidän osallistumisensa on tärkeää.

Lopuksi päätöksestä ja sen perusteista pitää kertoa kaikille osallistuneille. Kaikki eivät ehkä pidä valinnasta, mutta he voivat kunnioittaa sitä, koska prosessi ja perustelut ovat avoimia.

Olivia Montgomery: Tavoitteena ei ole, että kaikki ovat päätökseen tyytyväisiä. Tavoitteena on, että kaikki kunnioittavat päätöstä. Se onnistuu vain rehellisellä ja avoimella keskustelulla. Kaikkien pitää voida nähdä, ettei työkalua valittu esimerkiksi siksi, että jonkun sukulainen työskentelee kyseisessä yrityksessä.

Galen Low: Olivia, on aina hienoa saada sinut ohjelmaan. Keskustelumme tärkein oppi on minulle se, että esittelyjä kannattaa järjestää kaksi. Ryhmää ei tarvitse pitää yhdessä koko ajan, kunhan asiat yhdistetään myöhemmin esimerkiksi pisteytyskortin avulla.

Olivia Montgomery: Tehokäyttäjän ei tarvitse olla mukana keskustelussa siitä, kuinka usein työt suoritetaan tai miltä ohjelmointirajapinta näyttää. Kaikkien aikaa pitää kunnioittaa, mutta liiketoiminnan ja IT:n ei myöskään pidä odottaa liian pitkään ennen yhteisen näkemyksen muodostamista. Sen ei pitäisi tapahtua käyttöönoton aikana.

Galen Low: Viimeinen kysymys. Olet projektipäällikkö organisaatiossa, jossa ohjelmiston valintaan ei suhtauduta riittävän järjestelmällisesti. Joku saattaa sanoa, että kyseessä on veljen ohjelmistoyritys ja saatte hyvän hinnan. Mitä voit tehdä prosessin ryhdistämiseksi ja ennakkoluulojen vähentämiseksi?

Olivia Montgomery: Rakenna kunnioittava suhde henkilöön, jolla on tällainen näkemys. Selvitä, onko hän lopullinen päätöksentekijä. Jos ei ole, puhu päätöksentekijälle ja pyydä tämän tukea. Jos hän tekee päätöksen, kuuntele häntä ja ehdota, että täytätte toimittajan pisteytyskortin yhdessä.

Kerro, että haluat varmistaa kaikkien näkökulmien huomioimisen. Älä vähättele ketään, vaan työskentele suhteen eteen. Voit käyttää kysyvää lähestymistapaa: mitä integraatioista tiedetään, mitä tietoturvasta on selvitetty ja miten nykyisiä ja tulevia prosesseja tuetaan. Näin vaatimukset tulevat esiin ilman vastakkainasettelua.

Ole aina avoin ja suora. Ratkaisun pitää toimia IT:lle, liiketoimintayksikölle, nykytilalle ja tulevalle toimintamallille. Tehkää arviointi yhdessä.

Galen Low: Hienoa. Olemme tehneet syvällisen katsauksen ohjelmiston valintaan, erityisesti esittelyihin ja niiden jälkeiseen päätöksentekoon.

Toivon, että kuuntelijat saivat paljon hyödyllistä tietoa. Odotan jo seuraavaa keskusteluamme ja uusia kysymyksiä.

Olivia Montgomery: Kiitos kutsusta. Toivon, että kuulijat oppivat jotain ja suhtautuvat esittelyihin eri tavalla. Niitä ei tarvitse pelätä eikä antaa toimittajan jyrätä päätöksiä. Oli hienoa keskustella kanssasi.

Galen Low: Mitä mieltä olet: onko ohjelmistoesittely tiimisi ajan arvoinen vai onko se vain näytelmä, joka kiertää käytännöllisemmän ja syvällisemmän arvioinnin? Jätä ajatuksesi ja kokemuksesi alla oleviin kommentteihin.

Jos haluat kehittää taitojasi strategisena projektijohtajana, liity yhteisöömme. Siirry osoitteeseen thedigitalprojectmanager.com/membership ja pääset mukaan kannustavaan yhteisöön, joka jakaa tietoa, ratkaisee monimutkaisia haasteita ja muovaa yhdessä ammattimme tulevaisuutta.

Saat käyttöösi vankkoja malleja ja kuukausittaisia koulutuksia, jotka säästävät aikaasi ja energiaasi, sekä vertaistukea keskustelufoorumilla, yhteisön tapahtumissa ja pienryhmissä. Yhteisömme jäsenenä sinulla on yli tuhat ihmistä tukenasi, kun etenet digitaalisissa projekteissa ja rakennat uraasi.

Jos pidit kuulemastasi, tilaa podcast ja pysy yhteydessä osoitteessa thedigitalprojectmanager.com.

Ensi kertaan. Kiitos kuuntelusta.