Finns det en pilot ombord?: informationsblad

Viktigt!: Den här artikeln är maskinöversatt, se ansvarsfriskrivningen. Den engelska versionen av den här artikeln finns här för din referens.

"Om det finns en pilot ombord, skulle han eller hon vilja vara så vänlig att trycka på sin anropsknapp?" är något ingen passagerare någonsin vill höra. Jag läste nyligen om en gammal nyhetsartikel om just en sådan händelse i december 2013. När piloten på ett flygplan från Des Moines, i Iowa i USA, drabbades av ett akut sjukdomstillstånd frågade den biträdande piloten passagerarna om det fanns någon annan pilot ombord. Kapten Mark Gongol, B1-bombplanspilot i US Air Force, tog den sjuke pilotens plats. Planet, passagerarna och besättningen landade tryggt.

Det är en bra historia, men nu när jag läste om den kom jag att tänka på något helt annat. För inte så länge sedan ringde en potentiell kund och undrade om de kunde "pilottesta" vår tidrapportsprogramvara för företagsprojekt. Den här typen av samtal får mig alltid att stanna upp lite. När någon på ett flygplan säger "pilot" vet vi alltid exakt vad som avses, men när någon som utvärderar programvarualternativ säger "pilottesta" är jag inte alls lika säker.

I programvaruvärlden förekommer termen ”pilot” ofta i samband med andra utmanande utvärderingsmetoder, till exempel "koncepttest". Låt oss ta en titt på vad de här båda termerna betyder och hur du bäst använder dem i din egen företagsprocess för utvärdering.

Koncepttest (Proof of Concept)

Det här är en term som använts länge och som är populär inom elektroteknik. Man provade kretsar på experimentplattor för att ta reda på om de fungerade, inte för att börja producera dem. Vid koncepttestning tillbringar du kanske mer tid vid labbänken än om du bara skapade produktionskretsen, men riskerna är begränsade till just det kretskort du arbetar med. Det är en billig metod som medför små risker för att testa om en elektrisk krets ger önskat resultat.

I programvarusammanhang bör ett koncepttest utformas för att testa något. När potentiella kunder ringer för att fråga om jag kan förse dem med ett koncepttest för programvara för hantering av företagsprojekt eller företagstidrapporter ger jag dem alltid samma svar: "Vilka koncept är det du vill testa?"

I regel möts detta med tystnad och viss förvirring.

Om du ska utföra ett koncepttest, men inte har någon aning om vad du vill testa och bevisa, hur kan du då veta om testet är lyckat eller misslyckat? Det kan du naturligtvis inte.

Nu undrar du kanske varför någon överhuvudtaget vill göra ett koncepttest i så fall? Det vanligaste svaret är att frågeställaren förmodligen inte har ett tydligt och klart uppdrag från sina chefer att implementera programvaran som frågeställaren förhör sig om, utan bara hoppas att om de får se programvaran och hur den fungerar kommer de att bli förtjusta i den och vilja distribuera den. Det är alltså inför ledningen saken ska ”testas” och ”konceptet” är hela programvaruidén.

Om det vore så enkelt att övertyga ledningar om att en viss programvara för företagsprojekt och tidrapporter är helt rätt utformad för just dem skulle vi distribuera betydligt mycket mer än vi gör.

Problemet med den här metoden är att det arbete du kommer att kunna utföra för att distribuera den här koncepttestsinstansen med största sannolikhet inte skulle få samma stöd som du skulle få för produktionsdistributionen av ett företagssystem. När en organisation distribuerar ett företagssystem, till exempel ett system för tidrapporter eller projekthantering, är det flera olika saker som krävs för att det ska fungera bra. Först måste ledningen och personal från alla delar av organisationen som berörs av distributionen komma med input. Sedan krävs det tid för konfiguration, teknisk hjälp för att koppla samman systemet med andra företagssystem, stöd från ledningen, tid för utbildning och ja, pengar.

Om du inte har något av allt detta, vad är det då för system du kan åstadkomma med ditt koncepttest? I bästa fall blir det en skugga av vad du tänkte dig. Som det ser ut idag med stor tillgång på molnlösningar kan du förmodligen hitta ett fullständigt värdbaserat system och på så sätt slippa köpa servrar och programvara, men att få ett system installerat är ändå endast en bråkdel av det arbete som krävs bara för att distribuera den mest grundläggande versionen av ditt koncepttestsystem.

Det är lätt att förstå varför en organisation tvekar att lägga en massa tid och resurser på implementeringen av något som kan påverka hela organisationen. Det är helt enkelt ett högriskprojekt. Vi talar oftast bara om fördelarna med programvaror för företagsprojekthantering, men det är inte svårt att föreställa sig att om allt går snett kommer nackdelarna att vara minst lika stora. Att minimera risktagandet ligger alltså i allas intresse. Men om den verkliga utmaningen är att övertyga ledningen om fördelarna med ett system finns det definitivt bättre sätt att göra det på. På HMS Software fokuserar vi på några av följande tillvägagångssätt:

  1. Tala med en verklig, redan befintlig kund.

    Vi har glädjen att ha flera kunder som i det stora hela är rätt nöjda. När en ny potentiell kund funderar över vad de är på väg att ge sig in på brukar vi låta representanter för den potentiella kundens organisation träffa någon som redan är kund hos oss. I flera fall har den befintliga kunden bjudit in till ett personligt möte på sitt eget företag. I en del andra fall har den potentiella kunden haft samtal med vår redan etablerade kund, som vi avsiktligen inte deltagit i. Vi uppmuntrar vår befintliga kund att dela med sig av både positiva och negativa erfarenheter.

  2. Låt oss testa det.

    Om du verkligen har ett koncept som du vill testa, så låt oss hjälpa dig att testa det. Det finns legitima skäl till varför vissa aspekter av vissa implementeringar först måste testas. Kanske kommer distributionen att innehålla mycket stora mängder av vissa typer av data. Vid ett tillfälle ombads vi till exempel att visa hur vår lösning skulle fungera med ett synnerligen stort projekt. Vi har också blivit ombedda att visa hur vår programvara fungerar med vissa webbläsare eller databaser, eller kopplad till olika versioner av vissa externa system. Om det är den typen av koncept som är ett hinder för utvärderingen är det ämnesexperterna som är bäst lämpade att klara utmaningen.

  3. Du kan få viss utbildning för detta.

    Om den potentiella kunden absolut vill låta sin egen personal prova att arbeta med kundens egna data i systemet kan vi hjälpa till med att läsa in alla data i ett värdbaserat system och sedan göra en mycket begränsad, grundläggande konfiguration av systemet enligt kundens önskemål, och utbilda de personer som ska delta i testningen. Vi föredrar definitivt att själva komma till företaget och hjälpa till med demonstrationen, men om det inte är möjligt vill vi först granska skriptet eller demonstrationen som de berörda personerna ska använda och även hjälpa till att anpassa det eller ge de personer som ska utföra arbetet viss utbildning.

Var finns det en pilot när du behöver en?

Så hur blir det med pilotprojektet? Det är väl bättre, eller hur? Det kan det vara. Om du har blivit ombedd att genomföra en pilotdistribution av ett hanteringssystem för företagstidrapporter eller företagsprojekt bör du börja med fastställa målen. Om målen endast handlar om koncepttest är det inte ett pilotprogram du arbetar med.

Ett pilotprojekt är en riktig, faktisk distribution i produktionen. I regel omfattar det en del av den användarbas som systemet är tänkt att ha, och därför tar det troligtvis lite tid att genomföra ett pilotprogram. Även om behoven hos hela den tänkta användarbasen måste beaktas redan från början ligger pilotprogrammets fokus på en verklig implementering för pilotanvändarna. De kommer att hantera sina projekt eller fylla i sina tidrapporter på riktigt i det nya systemet.

Pilotimplementeringen kommer att ställas inför samma utmaningar som en fullständig produktionsdistribution, om man bortser från själva mängden data och dessas komplexitet. De vanligaste problemen jag sett med pilotprojekt är bland annat brist på stöd från ledningen, otillräcklig budget, otillräckligt med tid och resurser och, förmodligen värst av allt, brist på uttalade mål som kan användas för att fastställa om pilotprojektet var lyckat eller inte.

Detta betyder inte att ett pilotprojekt är någonting dåligt i sig. Det kan vara mycket klokt att genomföra ett pilotprojekt. Det kan minska risken för att en hel organisation blir lidande av en ofullständig eller dåligt konfigurerad distribution. Men det krävs en hel del planering för att ett pilotprojekt ska bli lyckat.

Vi påbörjade nyligen arbetet med en distribution av betydande storlek för en organisation inom den offentliga sektorn. Något som är mycket positivt med detta är att organisationen i fråga redan har lagt den tid som krävs på en bra utvärdering. De har valt det företagssystem de vill ha. Lyckligtvis är det vårt. Under det gångna året har vi tillsammans med deras utvärderingsteam arbetat med att besvara alla deras tekniska frågor, och nu kan fokus vändas mot hur personalen och deras prestationer kommer att påverkas i det dagliga arbetet.

Kunden föreslog att vi under en sexmånadersperiod skulle arbeta med en ganska stor grupp, men ändå bara ungefär en tiondel av hela gruppen. Det finns en rimlig budget, pilotprojektet har stöd av ledningen ända upp på högsta nivå och vi har tillräckligt med tid för att säkert hinna hjälpa till med allt vi normalt brukar göra i samband med en distribution av det här slaget. Gruppen som ska arbeta med den här miljön för projektspårning och tidrapportering kommer att använda den i produktionen under överskådlig framtid. Det är alltså inte bara ett test. Det är mer som första fasen i en distribution, inte "vi provar och ser hur det går". Med alla dessa faktorer på plats har vi goda skäl att förvänta oss ett lyckat resultat senare i år.

Sammanfattning

Pilotprojekt och koncepttestsprojekt är en realitet i samband med företagsprogramvara, men om det är något du planerar framöver kan du bidra till att det blir framgångsrikt genom att framhålla vissa nyckelfaktorer för alla berörda:

  1. Börja med att sätta upp tydliga och klara mål.

  2. Säkerställ sedan noga att ledningen verkligen förstår vad du behöver och att du kommer att få det stöd som krävs i form av pengar, resurser och tid för att uppnå målen.

  3. Gör slutligen en projektplan och hantera den på samma sätt som du hanterar alla andra projekt i din portfölj.

Om författaren

Chris Vandersluis är VD och grundare av programvaruföretaget HMS Software i Montreal, Kanada, en Microsoft Certified Partner. Han har en examen i ekonomi från McGill University och över 30 års erfarenhet av automatisering av system för projektstyrning. Han är sedan länge medlem av Project Management Institute (PMI) och var med och grundade lokalavdelningarna till Microsoft Project Users Group (MPUG) i Montreal, Toronto och Quebec. Bland de publikationer som Chris skrivit för återfinns Fortune, Heavy Construction News, Computing Canada, PMI:s PMNetwork och Project Times. Han undervisar i avancerad projekthantering på McGill University och föreläser ofta om projekthantering i hela Nordamerika och runt om i världen. HMS Software är utgivare av det projektorienterade tidtagningssystemet TimeControl och har varit Microsoft Project Solution Partner sedan 1995.

Chris Vandersluis kan nås via e-post på: chris.vandersluis@hms.ca

Om du vill läsa fler EPM-relaterade artiklar av Chris Vandersluis kan du besöka hans blogg EPM Guidance (http://www.epmguidance.com/?page_id=39).

Obs!: Ansvarsfriskrivning för maskinöversättning: Den här artikeln har översatts av ett datorsystem utan mänsklig inblandning. Microsoft erbjuder dessa maskinöversättningar för att hjälpa icke engelskspråkiga användare att ta del av information om Microsofts produkter, tjänster och tekniker. Eftersom artikeln är maskinöversatt kan den innehålla fel i ordval, syntax och grammatik.

Utöka dina kunskaper
Utforska utbildning
Få nya funktioner först
Anslut till Office Insiders

Hade du nytta av den här informationen?

Tack för din feedback!

Tack för din feedback! Det låter som att det kan vara bra att koppla dig till en av våra Office-supportrepresentanter.

×