Er der en pilot ombord?: hvidbog

Vigtigt: Denne artikel er maskinoversat. Se ansvarsfraskrivelsen. Du kan finde den engelske version af denne artikel her til din orientering.

"Hvis der er en pilot ombord, bedes han eller hun trykke på tilkaldeknappen?" er noget, man som passager helst aldrig vil høre. Jeg genlæser en enestående historie fra en virkelig hændelse, som den fandt sted tilbage i december 2013. Da en pilot på en flyvning fra Des Moines, Iowa fik et ildebefindende, spurgte andenpiloten, om der var andre piloter ombord. Kaptajn Marker Gongol, en pilot på et B1-bombefly i US Air Force, trådte til. Flyet, passagererne og personalet landede sikkert og i god behold.

Det er en god historie, men jeg læste historien igen af en helt anden årsag. En af vores potentielle kunder ringede for nylig og spurgte, om de kunne få en "pilotversion" af vores timeseddelsoftware til virksomhedsprojekter. Disse typer opkald får mig altid til at tøve et øjeblik. Når en person på et fly siger "pilot", er vi alle meget sikre på, hvad det betyder, men når en person, der evaluerer softwaretyper siger "pilotversion", er jeg aldrig sikker.

Ordet "pilot" i softwarens verden er ofte blandet sammen med andre udfordrende evalueringsmetoder, f.eks. "koncepttest". Lad os se nærmere på, hvad disse ord betyder, og hvordan du bedst bruger dem i din egen proces for virksomhedsevaluering.

Koncepttest

Dette er et udtryk, som går mange år tilbage og er populært i elektroindustrien. Der blev udført "bread boarding" af et kredsløb for at se, om kredsløbet var muligt, ikke for at starte produktionen af det. I en koncepttest bruger du sandsynligvis mere tid i laboratoriet, end du ville gøre i fremstilling af kredsløbet i produktion, men den eneste skade, du kunne gøre, var på det kredsløbskort, du arbejdede på. Det var en omkostningsbesparende metode med lav risiko til at bevise, at et elektrisk kredsløb kunne levere det ønskede resultat.

I softwaretermer bør en koncepttest udføres for at bevise noget. Når potentielle kunder ringer for at spørge, om jeg kan hjælpe dem med at levere en koncepttest til projektstyring for store virksomheder eller timeseddelsoftware til virksomheder, har jeg altid det samme svar: "Hvilket koncept ønsker du at bevise?"

Dette besvares typisk med stilhed og et forvirret udtryk.

Hvis du skal udføre en koncepttest, og du ikke har begreb om, hvad du forsøger at bevise, hvordan kan du så vide, om testen er en succes eller en fiasko? Det er naturligvis ikke muligt.

Hvorfor, spørger du, ville nogen så i det hele taget foretage en koncepttest? Det mest almindelige svar er, at personen, der anmoder om det, sandsynligvis ikke har den nødvendige opbakning fra ledelsen til at implementere den software, de kigger nærmere på, og håber, at hvis det kører lige foran øjnene af ledelsen, ville den forelske sig i idéen og acceptere, at softwaren installeres. I dette tilfælde er “test” en test af ledelsen, og “koncept” er hele begrebet virksomhedssoftware.

Hvis det var nemt at overbevise ledelsen om, at virksomhedsprojekter og timeseddelsoftware passer perfekt til virksomheden, ville vi installere meget mere af det.

Problemet med denne metode er, at arbejdet, du skal kunne gøre for at installere denne koncepttest, sandsynligvis på ingen måde vil få samme støtte, som du ville få ved installation af et virksomhedssystem i produktion. Når en organisation installerer et virksomhedssystem, f.eks. et timeseddel- eller projektstyringssystem, kræves der mange ting for at gøre det til en succes. Først skal der være input fra ledelsen og linjemedarbejdere fra alle sider af organisationen, der er involveret i installationen. Dernæst skal der være tid til konfigurationen, hjælp fra tekniske tjenester til at linke til andre virksomhedssystemer, støtte fra ledelsen, tid til uddannelse, og, ja, penge.

Hvis du ikke har nogen af disse ting, hvilket system kan du da fuldføre i din koncepttest? Det vil i bedste fald være en skygge af det, du i virkeligheden har behov for. I dagens sky-tidsalder kan du sandsynligvis få adgang til et system, der er fuldt hostet, så du skal i det mindste ikke bekymre dig om at købe servere og software, men blot at have et system installeret er kun en brøkdel af det arbejde, der kræves for at foretage selv en grundlæggende installation af systemet fra koncepttesten.

Det er nemt at forstå, hvorfor en organisation vil tøve med at bruge en masse penge og ressourcer på implementeringen af noget, der har mulighed for at påvirke hele organisationen. Det er en opgave med høj risiko. Vi har tendens til kun at tale om fordelene ved projektstyringssoftware til store virksomheder, men det er nemt at forestille sig, at det samme projekt, hvis det går galt, kan påvirke lige så negativt. Så at mindske risikoen er et indlysende problem. Men hvis den reelle udfordring er, at overbevise ledelsen om fordelene ved systemet, må der helt sikkert være bedre måder at gøre dette på. Hos HMS Software er vi fokuseret på nogle få af de følgende metoder:

  1. Tal med en ægte, allerede eksisterende kunde.

    Vi er så heldige at have nogle gode kunder, som i det store og hele er meget tilfredse. Når en ny potentiel kunde er i tvivl om, hvad de er på vej ind i, bringer vi den pågældende organisation sammen med en eksisterende kunde. I mange tilfælde har den eksisterende kunde været generøs nok til at tilbyde at være vært for et personligt møde. I andre tilfælde taler de sammen i telefonen, som vi bevidst ikke er en del af. Vi opfordrer den eksisterende kunde til at dele både fordele og udfordringer.

  2. Lad os bevise det.

    Hvis du virkelig har et koncept, der skal testes, kan du lade os hjælpe dig med at teste det. Der er legitime grunde til, at visse aspekter af en række implementeringer skal være testet først. Installationen kan måske indeholde meget store mængder af visse typer data. F.eks. blev vi én gang bedt om at vise, at vores løsning kunne fungere med en særlig stor projektbelastning. Vi er blevet bedt om at vise, at vores software kan arbejde sammen med visse browsere eller databaser, eller at den kan arbejde sammen med bestemte versioner af en række eksterne systemer. Hvis det er den slags koncepter, der blokerer evalueringen, er de bedste personer til at overvinde denne udfordring eksperter inden for emnet.

  3. Du kan få uddannelse med i købet.

    I de tilfælde, hvor den mulige kunde ønsker at se systemet arbejde med kundens egne data, der bruges af medarbejderne, hjælper vi med at indlæser data til et hostet system og foretager derefter en minimal konfiguration af systemet, som ønsket af klienten, og en minimal oplæring af de personer, der er involveret. Vi foretrækker at være en del af virksomheden for at hjælpe med selve demonstrationen, men hvis det ikke er muligt, beder vi om at gennemgå scriptet eller demonstrationen, som de involverede personer vil bruge, og beder om at hjælpe med at justere den eller oplære de personer, der skal levere den.

Hvor er piloten, når du har brug for en?

Så hvad med pilotprojektet? Det er bedre, ikke sandt? Det kan det være. Hvis du er blevet bedt om at etablere en pilotimplementering af et virksomhedsbaseret timeseddelsystem eller projektstyring for store virksomheder, bør du begynde med fastlæggelse af mål. Hvis målene kun drejer sig om en koncepttest, så deltager du slet ikke i et pilotprogram.

Et pilotprojekt er en ægte, produktionsbaseret live-installation. Det omfatter typisk et undersæt af den samlede brugerbase, der er i betragtning for det evaluerede system, og derfor vil et pilotprogram ofte tage et stykke tid. Mens den komplette brugerbases behov tages i betragtning fra begyndelsen, fokuserer pilotprogrammet på at foretage en reel implementering for pilotbrugerne. De vil administrere deres faktiske projekter eller udfylde deres faktiske timesedler via det nye system.

De samme udfordringer, som en komplet produktionsinstallation står overfor, står pilotimplementeringen også overfor, med undtagelse af mængden eller kompleksiteten af data. De mest almindelige udfordringer i pilotprojekter, jeg har set, omfatter manglende støtte, utilstrækkeligt budget, utilstrækkelig tid og utilstrækkelige ressourcer og, nok værst af alt, manglende konkrete mål for at afgøre, om pilotprojektet lykkedes eller ej.

Dermed ikke sagt, at et pilotprojekt er en dårlig ting. At gennemføre et pilotprojekt kan være meget fornuftigt og kan bruges til at reducere risikoen for, at hele organisationen påvirkes af en ufuldstændig eller dårligt konfigureret installation. Men at foretage et vellykket pilotprojekt kræver en del overvejelser.

For nylig begyndte vi at arbejde på en installation af betydelig størrelse til en offentlig organisation. Det gode ved denne øvelse er, at organisationen allerede har brugt al den tid, de burde for at gennemføre deres evaluering. De foretog deres valg af virksomhedssystem. Heldigvis blev det vores. Vi har arbejdet med deres evalueringsteam i løbet af det sidste år for at sikre besvarelse af deres tekniske spørgsmål, men nu ændres fokus til påvirkningen af daglige processer for personer i organisationen.

De foreslog, at vi over en periode på 6 måneder samarbejder med en gruppe, der, selv om den er stor, fortsat kun udgør ca. 10 procent af hele gruppen. Der er et tilstrækkeligt budget, pilotprojektet har støtte fra topledelsen, og vi har tilstrækkelig tid til at sikre, at vi kan hjælpe med alt, hvad vi normalt ville gøre på en installation som denne. Den gruppe, der skal involveres i dette projekts sporings- og timeseddelmiljø, skal arbejde med det i produktion i et godt stykke tid, så det er ikke blot en test. Det kan mere sammenlignes med første fase af en installation og ikke en “prøv det, og se, hvordan det går”-øvelse. Med alle disse faktorer på plads forventer vi et vellykket resultat senere i år.

Afslutning

Pilot- og koncepttestprojekter er et faktum ved virksomhedssoftware, men hvis du foretager et i fremtiden, kan du hjælpe med at gøre det til en succes ved at udpege en række succesfaktorer til alle, der deltager:

  1. Først skal du sørge for, at dine mål er gjort tydelige.

  2. Dernæst skal du sørge for, at ledelsen forstår det, du skal bruge, og kan hjælpe dig med hensyn til penge, ressourcer og tid for at kunne nå disse mål.

  3. Til sidst skal du sørge for at udarbejde en projektplan og administrere den som ethvert andet projekt i projektoversigten.

Om forfatteren

Chris Vandersluis er formand og grundlægger af den certificerede Microsoft-partner, HMS Software i Montreal, Canada. Han har universitetsgrad i økonomi fra McGill University og mere end 30 års erfaring med automatisering af projektstyringssystemer. Han er mangeårigt medlem af Project Management Institute (PMI) og hjalp med at grundlægge Montreal-, Toronto- og Quebec-afdelingerne af Microsoft Project Users Group (MPUG). Publikationer, som Chris har skrevet for, omfatter Fortune, Heavy Construction News, Computing Canada Magazine, PMI's PMNetwork og Project Times. Han underviser i avanceret projektstyring på McGill University og taler ofte ved arrangementer i forbindelse med projektstyring over hele Nordamerika og over hele verden. HMS Software er udgiver af det projektorienterede tidsstyringsystem TimeControl og har været Microsoft Project Solution Partner siden 1995.

Chris Vandersluis kan kontaktes via mail på: chris.vandersluis@hms.ca

Hvis du vil læse flere EPM-relaterede artikler af Chris Vandersluis, kan du se hans EPM-vejledningsblog (http://www.epmguidance.com/?page_id=39).

Bemærk: Ansvarsfraskrivelse for maskinoversættelse: Denne artikel er blevet oversat af et computersystem uden menneskelig indgriben. Microsoft tilbyder disse maskinoversættelse for at hjælpe ikke-engelsktalende brugere til at kunne nyde indhold om Microsofts produkter, tjenester og teknologier. Da artiklen er maskinoversat, kan den indeholde forkerte ord eller syntaks- eller grammatikfejl.

Del Facebook Facebook Twitter Twitter Mail Mail

Var disse oplysninger nyttige?

Fantastisk! Har du mere feedback?

Hvordan kan vi forbedre det?

Tak for din feedback!

×