Er det en pilot ombord?: hvitbok

Viktig: Denne artikkelen er maskinoversatt, se ansvarsfraskrivelsen. Du finner den engelske versjonen av artikkelen her som referanse.

Noe passasjerer på et fly aldri har lyst til å høre, er: «Finnes det en pilot om bord? Han eller hun må vennligst komme frem». Jeg leste en utrolig nyhetsartikkel på nytt, om en sann hendelse akkurat som dette som skjedde i desember 2013. Etter at piloten på et fly fra Des Moines i Iowa hadde en medisinsk nødssituasjon, spurte annenpiloten om det var noen piloter om bord. Kaptein Mark Gongol, en bombeflypilot i det amerikanske luftforsvaret, tok oppfordringen. Flyet, passasjerene og staben fikk en sikker landing.

Det er en flott historie, men da jeg gikk tilbake for å lese den på nytt, ble jeg minnet på noe helt annet. En potensiell kunde ringte meg nylig og spurte om de kunne være «pilot» for virksomhetsprosjektet vårt for timelisteprogrammer. Slike samtaler får meg alltid til å tenke meg om. Når noen på et fly sier «pilot», er det veldig tydelig hva som menes, men når noen som evaluerer programvarealternativer, sier «pilot», er jeg ikke så sikker.

Begrepet «pilot» i programvaresammenheng er ofte blandet sammen med andre utfordrende evalueringsmetoder, for eksempel «konseptbevis». La oss ta en titt på hva disse termene betyr, og hvordan du kan bruke dem på best måte i din egen evalueringsprosess i virksomheten.

Konseptbevis

Dette er en term fra flere år tilbake, som er populær innenfor elektroteknikk. «Bread boarding» av en krets ble utført for å se om kretsen var mulig, ikke for å begynne å lage den for produksjon. I konseptbevis bruker du kanskje mer tid i en lab enn tiden du ville brukt på å lage produksjonskretsen, men den eneste skaden du kunne forårsake, var på kretskortet som ligger foran deg. Dette var en metode som både var rimelig og hadde lav risiko for å bevise at en elektrisk krets kunne levere det ønskede resultatet.

I programvaresammenheng skal et konseptbevis utformes for å bevise noe. Når potensielle kunder ringer for å spørre om jeg kan hjelpe dem med å levere et konseptbevis for prosjektadministrasjon eller timelister for virksomheter, har jeg alltid det samme svaret: «Hvilke konsepter vil du bevise?»

Dette resulterer vanligvis i stillhet og et forvirret uttrykk.

Hvis du skal utføre et konseptbevis og ikke har klart for deg hva du prøver å bevise, hvordan kan du vite om det blir vellykket eller mislykket? Det finnes selvfølgelig ingen måte å få til dette på.

Men hvorfor vil noen i det hele tatt utføre et konseptbevis da? Det vanligste svaret er at den som spør, sannsynligvis ikke har den nødvendige støtten fra ledelsen til å implementere programvaren de undersøker, og håper at hvis de ser hvordan den fungerer, blir de hektet og enige om at den skal distribueres. I dette tilfellet er «beviset» for ledelsen, og «konseptet» er hele inntrykket av virksomhetsprogramvaren.

Hvis det var så enkelt å overbevise ledelser om at virksomhetsprosjekter og timelisteprogramvare passer for dem, ville vi distribuert veldig mye mer av det.

Problemet med denne metoden er at det er lite sannsynlig at du vil få like mye støtte for arbeidet du må gjøre for å distribuere dette konseptbeviset, som du vil få for produksjonsdistribusjon av et virksomhetssystem. Når en organisasjon distribuerer et virksomhetssystem, for eksempel et timeliste- eller prosjektstyringssystem, finnes det mange ting som er nødvendige for å få det til å bli en suksess. For det første må du få tilbakemelding fra ledelsen og linjeansatte for alle aspekter av organisasjonen som inngår i distribusjonen. Deretter må det settes av tid for konfigurasjon, hjelp fra tekniske tjenester til å koble det til andre bedriftssystemer, støtte fra ledelsen, tid til opplæring og penger.

Hvis du ikke har noen av disse tingene, hva vil systemet som du kan fullføre i konseptbeviset, være? Det vil i beste fall bli en skygge av det du vil ha. Med dagens tilgang til skyen kan du sannsynligvis få tilgang til et system som er helt vertsbasert, slik at du slipper å bekymre deg om å kjøpe servere og programvare. Det å ha et system installert er imidlertid bare en brøkdel av arbeidet som kreves for å selv foreta en grunnleggende distribusjon av konseptbevissystemet.

Det er enkelt å forstå hvorfor en organisasjon nøler med å bruke mange penger og ressurser på å implementere noe som har muligheten til å påvirke hele organisasjonen. Det er en øvelse med høy risiko. Vi pleier å snakke om fordelene ved programvare for foretaksprosjektstyring, men det er enkelt å forestille seg at samme prosjekt, hvis det går galt, kan ha en like negativ innvirkning. Så det å redusere risikoen er en opplagt bekymring. Men hvis den reelle utfordringen er å overbevise ledelsen om fordelene med systemet, må det finnes bedre måter å gjøre dette på. Hos HMS Software fokuserer vi på noen av disse metodene:

  1. Snakke med en reell kunde som allerede er etablert.

    Vi er heldige som har noen flotte kunder som stort sett er fornøyde. Når en ny potensiell kunde har bekymringer om hva de begir seg ut på, setter vi den organisasjonen sammen med en eksisterende kunde. I mange tilfeller er den eksisterende kunden generøs nok til å tilby seg til å være vert for et personlig møte. I andre tilfeller ringer de hverandre, der vi bevisst ikke deltar. Vi oppfordrer eksisterende kunder til å dele både gode nyheter og utfordringer.

  2. La oss bevise det.

    Hvis du virkelig har et konsept som må bevises, kan vi hjelpe deg. Det er legitime årsaker til hvorfor enkelte aspekter av noen implementeringer må bevises først. Distribusjonen har kanskje svært store mengder med visse typer data. En gang ble vi for eksempel bedt om å vise at løsningen vår kunne fungere med et spesielt stort prosjekt. Vi har blitt bedt om å vise hvordan programvaren fungerer med bestemte nettlesere eller med enkelte databaser, eller koblet til bestemte versjoner av visse eksterne systemer. Hvis det er slike typer konsepter som hindrer evalueringen, er det ekspertene på området som er de beste personene for å løse utfordringen.

  3. Du kan få opplæring i dette.

    I tilfeller der den potensielle kunden absolutt må vise at systemet fungerer med dataene som brukes av personalet, hjelper vi til med å laste inn data på et vertsbasert system, og utfører deretter et minimum for å konfigurere systemet som klienten vil ha, og lære opp personene som vil være involvert. Vi foretrekker å hentes inn i firmaet for å hjelpe til med selve demonstrasjonen, men hvis dette ikke er mulig, ber vi om å gå gjennom manuset eller demonstrasjonen som de involverte personene skal bruke, og ber om å bidra med å justere den eller lære opp de som skal levere den.

Hvor er en pilot når du trenger en?

Så hva med pilotprosjektet? Det er bedre, ikke sant? Det kan det være. Hvis du har blitt bedt om å etablere en pilotdistribusjon av et timeliste- eller prosjektstyringssystem for virksomheter, bør du starte med å fastslå målene. Hvis målene bare handler om å bevise konsepter, er det ikke et pilotprosjekt i det hele tatt.

Pilotprosjekter er en ekte distribusjon, i produksjon i sanntid. De omfatter vanligvis et delsett av den totale brukerbasen som vurderes for systemet som evalueres, og derfor vil et pilotprogram sannsynligvis ta litt tid. Selv om behovene til hele målgruppen av brukere tas hensyn til fra begynnelsen, fokuserer pilotprogrammet på å gjøre en reell implementering for pilotbrukere. De kommer faktisk til å styre prosjektene sine eller fylle ut timelistene sine med det nye systemet.

Pilotimplementeringen møter de samme utfordringene som en fullstendig produksjonsdistribusjon ville gjort, med unntak av volumet eller kompleksiteten til dataene. De vanligste utfordringene i pilotprosjekter jeg har sett, inkluderer manglende støtte, utilstrekkelig budsjett, tid og ressurser og, kanskje aller verst, mangel av klart definerte mål, slik at vi kan vite om pilotprosjektet var vellykket eller ikke.

Men dette vil ikke si at et pilotprosjekt er dårlig. Det kan være svært fornuftig å foreta et pilotprosjekt, og det kan bidra til å redusere risikoen for å påvirke hele organisasjonen med en ufullstendig eller dårlig konfigurert distribusjon. Å få et pilotprosjekt til å fungere krever planlegging.

Nylig satte vi i gang med en stor distribusjon for en organisasjon i offentlig sektor. Det som er tilfredsstillende, er at organisasjonen allerede har brukt tiden de skulle, til å fullføre evalueringen. De har tatt valget om hvilket virksomhetssystem de vil bruke. Det er heldigvis vårt. Vi har arbeidet med evalueringsgruppen det siste året for å sikre at de tekniske spørsmålene ble besvart, men nå settes fokuset på innvirkningen på de dagligdagse prosessene til personene i denne organisasjonen.

De foreslo at vi jobber i en periode på 6 måneder med en stor gruppe, men som likevel bare består av 10 prosent av hele gruppen. Det finnes et tilstrekkelig budsjett, pilotprosjektet har støtte fra ledelsen på øverste nivå, og vi har nok tid til å sikre at vi kan hjelpe til med alt vi vanligvis ville gjort på en distribusjon som denne. Gruppen som blir satt på dette miljøet med prosjektsporing og timelister, skal arbeide med det, under produksjon, i nærmeste fremtid slik, at det ikke bare er en test. Dette er mer som første fase i en distribusjon, ikke en øvelse i «vi prøver det og ser hvordan det går». Med alle disse faktorene til stede forventer vi et vellykket resultat på slutten av året.

Til slutt

Pilotprosjekter og konseptbevisprosjekter er nødvendige i virksomhetsprogramvare, men hvis du skal bruke et i fremtiden, kan du bidra til at det blir vellykket, ved å peke ut noen hovedfaktorer for suksess til alle som er involvert.

  1. Først må du sørge for at målene dine er klart formulert.

  2. Deretter må du sørge for at ledelsen forstår det du trenger, og vil støtte deg med penger, ressurser og tid for å kunne nå disse målene.

  3. Til slutt må du lage en prosjektplan og styre den på samme måte som du ville gjort med et hvilket som helst annet prosjekt.

Om forfatteren

Chris Vandersluis er administrerende direktør og grunnlegger av HMS Software, en Microsoft-sertifisert partner basert i Montreal, Canada. Han har en økonomigrad fra McGill University og over 30 års erfaring i automatisering av prosjektstyringssystemer. Han er langvarig medlem av Project Management Institute (PMI) og var med på å grunnlegge lokalavdelingene av Microsoft Project Users Group (MPUG) i Montreal, Toronto og Quebec. Publikasjoner som Chris har skrevet for, inkluderer Fortune, Heavy Construction News, Computing Canada Magazine, PMIs PMNetwork og Project Times. Han underviser i avansert prosjektstyring på McGill University og holder ofte foredrag ved tilstelninger i forbindelse med prosjektstyring i hele Nord-Amerika og rundt om i verden. HMS Software er utgiver av det prosjektorienterte timeskrivingssystemet TimeControl og har vært Microsoft Project Solution Partner siden 1995.

Chris Vandersluis kan kontaktes på e-post på chris.vandersluis@hms.ca

Hvis du vil lese flere artikler av Chris Vandersluis om foretaksprosjektstyring, kan du se veiledningsbloggen hans for foretaksprosjektstyring (http://www.epmguidance.com/?page_id=39).

Merknad: Ansvarsfraskrivelse for maskinoversettelse: Denne artikkelen er oversatt av et datasystem i stedet for en oversetter. Microsoft tilbyr disse maskinoversettelsene slik at brukere som ikke snakker engelsk, får tilgang til innhold om Microsoft-produkter, -tjenester og –teknologier. Ettersom artikkelen er maskinoversatt, kan den inneholde feil i vokabular, syntaks eller grammatikk.

Utvid ferdighetene dine
Utforsk opplæring
Vær først ute med de nye funksjonene
Bli med i Office Insiders

Var denne informasjonen nyttig?

Takk for tilbakemeldingen!

Takk for tilbakemeldingen! Det høres ut som det kan være lurt å sette deg i kontakt med én av våre Office-kundestøtteagenter.

×