Batphone: hvitbok

Tittelen på denne rapporten refererer til politimester Gordons liberale bruk av Batphone når byen Gotham var i vanskeligheter (fra 1970-tallets TV-serie Batman).

Denne hvitboken er en del av samlingen som kalles "From the Trenches". Den setter den fiktive Batman-historien i sammenheng med at vi under en EPM-implementering noen ganger kunne ønske vi hadde tilgang til en Batphone når vi har problemer. Den inneholder også mange måter å unngå å få problemer på under implementeringen.

Hvis du vil laste ned Word-versjonen av denne rapporten, kan du se Batphone.

Hvis du vil se flere hvitbøker, kan du se "From the Trenches" white papers (på engelsk).

Batphone

Den originale TV-serien om Batman ble først sendt i 1966. Den varte bare i 120 episoder, men den endret en hel kultur på måter som vises den dag i dag. I Batman og Robins verden (spilt av Adam West og Burt Ward) fantes det en "Bat"-løsning på alt. Uansett hva problemet var, så hadde Batman løsningen. Batmobile, Batboat, Batplane og Batcave hadde alle sin plass. Og hvis du trengte hjelp, uansett hvor vanskelig situasjonen var, hvordan kunne du få tak i Batman? Med en Batphone selvfølgelig! Ta av røret på Batphone, så er hjelpen på vei.

Bilde av rød Batphone (fra TV-serien Batman)

Politimester Gordon pleide å bruke Batphone når det så håpløst ut, noe det selvfølgelig gjorde i hver episode. Det spilte ingen rolle hvor vanskelig utfordringen var. Det var bare å ta av røret på Batphone, og i løpet av 22 minutter (pluss tid for reklame) var skurken beseiret og Gotham City var atter en gang fredelig.

Hver eneste løsning i Batmans verden var laget slik at den lignet en flaggermus. Håndjern? Formet som en flaggermus. Verktøybelte? Flaggermuslogoer. Entrehake? Ser selvfølgelig ut som flaggermusvinger. Når jeg ser tilbake på bilder av Batphone, ser den til min overraskelse skuffende normal ut. En rød telefon med en nummerskive (husker du disse?). Jeg er ikke sikker på hvorfor den hadde nummerskive. Den ringte bare til ett sted, nemlig til Batcave, der redningen var å finne.

Det kan virke nostalgisk å tenke på telefoner med nummerskive og gamle episoder av Batman, men det er egentlig ikke det som er poenget med dagens artikkel. Det er 40 år siden Batphone ble avleggs, men folk ringer til EPM-konsulenter hver dag i håp om at Batphone vil fungere en siste gang.

Skurkene varierer. Noen er tekniske. De må oppgraderes fra versjon x til versjon y. Noen er arkitektoniske. De må få det interne EPM-systemet til å kommunisere med brukere i verden utenfor. Noen er kulturelle. Brukerne nekter å bruke systemet. Og noen er prosedyremessige. Prosessen de følger, ser ikke ut til å levere resultatet de forventet.

Uansett hvilken utfordring det dreier seg om, er spørsmålet til konsulentselskapet det samme: Kan du fikse det på 22 minutter?

Det er en situasjon som overraskende mange EPM-brukere havner i – der de trenger øyeblikkelig hjelp til å komme ut av en vanskelig situasjon. Det er ofte en nødssituasjon, og ledelsen trengte en løsning i går. Personene som ringer (jeg får et par oppringinger hver uke), er ikke evneveike. De er svært intelligente, flinke og dyktige ledere.

Det finnes selvfølgelig ingen Batphone. Jeg skulle ønske det gjorde det. Jeg ville brukt den til alle typer personlige utfordringer. Så de som ringer, er sjelden fornøyd med svarene de får. Så la oss se litt på hva det er som gjør at folk havner i en slik knipe at de føler behov for å bruke den røde telefonen, og hvordan du kan unngå å bli en av dem.

Hvordan problemene oppstår

La oss først se på hva det er som gjør at folk får problemer når de foretar en EPM-implementering. Det er et par vanlige grunner til dette:

  • De undervurderer utfordringen    Dette er absolutt den mest vanlige feilen i en EPM-distribusjon. Det er ikke slik at alle distribusjoner må være omfattende og vanskelige. Det er absolutt ikke alltid tilfellet. Men, kanskje på grunn av ønsketenkning, er det utrolig vanlig å undervurdere hva som må til for å få fullt utbytte av en EPM-distribusjon. Den første feilen skjer når de velger hva som er målet for distribusjonen. Noen ser det slik at når verktøyet er installert, er det et vellykket prosjekt. Det er det selvfølgelig ikke. Noen ser det slik at den første gangen verktøyet brukes eller den første rapporten som kommer ut av verktøyet, er målet. Det er det heller ikke. En løsning på problemene som EPM-verktøyene ble valgt for, er målet du må konsentrere deg om. Det betyr at kulturen er endret, opplæringen er fullført, bruken er i full gang, verktøyene fungerer og dataene er der. Ja, det kan virke litt mye, men hvis du er så mye som en millimeter fra det målet, så har du fremdeles ingenting. (Nå ja, nesten ingenting, i alle fall.)

  • De gjør det til et teknisk prosjekt    De av oss som er i teknologibransjen, er mest skyldige i dette, og de fleste av oss vet egentlig bedre. Allikevel er det av en eller annen grunn vanskelig å motstå fristelsen til å tro at tilgjengeligheten til teknologi betyr at problemet er løst. Mange av organisasjonene vi besøker, sier noe sånt som "Vi har jo installert Project Server, så hvorfor er staben vår overbelastet?" Som vi har sagt en stund nå, så kreves det en kombinasjon av mennesker, teknologi og prosesser og en god del endringsstyring attpåtil for at prosjektstyring for virksomheter skal fungere. Dette er ikke noe som kommer automatisk når DVD-en med programvaren er innenfor døren.

  • De involverer ikke ledelsen    Dette skjer også svært ofte. De som tross alt forstår fordelene med et prosjektstyringssystem for virksomheter best, er mest sannsynlig de som sliter med å analysere store mengder data som kommer fra et miljø med mange prosjekter og mange ressurser. Prosjektstyring for virksomheter er mest populært når en organisasjon prøver å forene et komplekst sett av motstridende prioriteringer og en enorm kombinasjon av ferdigheter og erfaring. Man skulle tro det var en selvfølge at ledelsen var involvert i et slikt prosjekt, men det er ofte ikke tilfellet. Utfordringen med å endre bedriftskulturen fra en tenkemåte i form av enkeltprosjekter til virksomhetsprosjekter, er nesten umulig å overvinne uten lederne, og likevel blir ledelsen altfor ofte forbigått fordi man bekymrer seg for at de ikke vil forstå hva som kreves for å fullføre en EPM-distribusjon.

  • De lager urealistiske tidsplaner    Det er ingen som ønsker at en EPM-distribusjon skal ta lang tid. Og det er vanlig å håpe at prosjektet kan gjennomføres i løpet av noen dager eller et par uker i stedet for de månedene det vanligvis tar. Det er også en vanlig utfordring at det ikke er like enkelt å få ressursene til et "internt" prosjekt som for eksempel EPM som det er til et klientbasert eller kommersielt prosjekt. På grunn av dette og andre ting er det vanlig å lage en tidsplan for prosjektet med ressursbehov som er sørgelig utilstrekkelige.

  • De bruker ikke prosjektstyring på prosjektstyringssystemet    Hvis du har lest noe av det jeg har skrevet, er det store sjanser for at du har sett dette før. Det er med prosjektledere som med skomakere, hvis barn ikke har sko. Resultatet er en vanlig mangel på et prosjektdokument, et godkjent budsjett, en sporbar tidsplan, tildelte ressurser og alt annet utstyr som er vanlig for alle andre prosjekter de administrerer.

Hva hadde de forventet?

Ok, dette er grunnen til at folk så ofte får vanskeligheter. Fordelene som ledelsen forventer at distribusjonen av et EPM-system skal gi, er vanligvis direkte knyttet til utfordringene i virksomheten. Det er løftet om en løsning på disse utfordringene som får ledelsen til å godkjenne utgiftene til programvare, maskinvare, infrastruktur og muligens også tjenester. De vanligste av disse utfordringene kan høres kjent ut:

  • Ressurser er overbelastet    Det er ikke sikkert det er klart hva ressursene blir brukt på, men det er svært vanlig at man finner at ressurser er overbelastet. Et mer komplisert problem er når man finner at noen ressurser er overbelastet mens andre er underbelastet, noe som ofte indikerer en uoverensstemmelse mellom den kunnskapen og erfaringen som er tilgjengelig kontra den som er nødvendig.

  • Kritiske prosjekter blir ikke fullført i tide    Det burde være åpenbart at kritiske prosjekter bør være ferdige til planlagt tid, men det virker som det alltid er noe som forstyrrer slike planer. Det kan skyldes motstridende ressursbehov, at man velger for mange prosjekter som krever for mye av de samme ferdighetene, eller bare dårlig prioritering. Noen ganger vil organisasjonene tro at det er mangel på dyktighet fra prosjektlederens side, men i et miljø med flere prosjekter og flere avdelinger, er det mer sannsynlig at problemet er organisatorisk.

  • Prosjekter blir ikke gjennomført innenfor budsjettrammen    Det gjelder det samme for kostnadene som for tidsplanen. I høyteknologibransjen, som i så mange andre bransjer, er arbeidsmengden den mest variable komponenten i prosjektkostnadene. Hvis man bruker mye lenger tid med samme antall personer, blir prosjektet dyrere. Et forbausende antall kontorprosjekter er fremdeles ikke sporbare. De er planlagt, men den faktiske kostnaden per prosjekt er ikke registrert.

  • Konkurrentene gjennomfører prosjektene sine raskere enn du gjør    I en konkurranseutsatt økonomi kan det å være først på markedet, bli forskjellen mellom vinn og forsvinn. Så for mange organisasjoner er det viktig å sørge for at prosjektledelsen er minst like effektiv som konkurrentene.

  • Det finnes ikke innsyn i hva ressursene i et prosjekt bruker tiden på, eller ingen måte å finne ut hvor mye tid som brukes på hvert prosjekt    Noen ganger er intet svar verre enn et dårlig svar. Dette gjelder spesielt hvis du er i toppledelsen. Hvis du vet at resultatene er dårlige, kan du bruke dine ferdigheter og ressursene du har til rådighet til å løse problemet som foreligger. Hvis du vet at noe er feil, men du ikke kan si hva det er, er du bundet på hender og føtter. Du har ingen anelse om hvor du skal prøve å løse problemet.

Hvordan kan jeg unngå problemer?

Du bør absolutt unngå å komme til det punktet da du føler at du trenger en Batphone. Så hva kan du gjøre med EPM-miljøet for å sikre at du ikke havner i en slik situasjon?

Ok, alt vi sa i det første avsnittet er opplagt:

  • Foreta en grundig kostnadsberegning

  • Ikke tro at EPM bare er et teknisk prosjekt

  • Involver toppledelsen fra begynnelsen

  • Lag en realistisk tidsplan, og foreta en virkelighetskontroll ved å sammenligne den med andre i bransjen

  • Utarbeid en prosjektplan og et prosjektdokument, og gjøre alle de tingene du vanligvis gjør med andre prosjekter

Hva annet kan du gjøre?

Først og fremst bør du starte prosjektet vel vitende om at du på ett eller annet tidspunkt vil ha bruk for en Batphone. For det vil du. Når du vet dette, kan du budsjettere for hjelp som du ikke har noen gjeldende plan for. Vi anbefaler at våre klienter budsjetterer 10–20 % av prosjektet til "uforutsette behov". "Hva er det til?" blir vi alltid spurt. "Det vil du fortelle oss senere," svarer vi alltid. Det er vanlig å ikke bruke alle pengene. Men det er også veldig vanlig å bruke noen av dem. Det å ha en dyktig ekspert allerede avsatt til prosjektet, i tillegg til et budsjett, vil gjøre en enorm forskjell senere.

Start med en forventning om at planen og personene vil endres. Mitt favorittsitat når det gjelder prosjektstyring stammer fra Napoleon Bonaparte, som sa: "Ingen slagplan overlever det første møtet med fienden." Det samme gjelder også for EPM-planer. Forutsatt at en implementering trolig vil vare i flere måneder, er det store sjanser for at noen personer vil endres i løpet av planen. Så planlegg med tanke på stabsendring.

EPM-systemer utvikler seg. Det er vanlig i disse dager å tenke på den "totale eierkostnaden" når det gjelder bedriftsapplikasjoner. Jeg mener vi bør inkludere hele livssyklusen til applikasjonen i planene for EPM-prosjektet. Har du tenkt over hvilken versjon av et verktøy du skal implementere? Har du tenkt over hvilke andre verktøy det er avhengig av? Hva med den regelmessige oppdateringen/oppgraderingen av disse verktøyene? Har du gjort noen tilpasninger? Hva med tilpasset opplæring? Har du tenkt over om disse tingene kan overføres til en ny versjon i tilfelle du skal distribuere en?

Planlegg med tanke på endringer i fagpersonellet, også. Hva vil skje om noen måneder når du går videre til en ny fase av implementeringen eller introduserer et nytt viktig medlem av teamet, og du har én enkelt konsulent som jobber for deg? Vil den konsulenten være tilgjengelig? (Konsulenter går fra ett prosjekt til et annet, så svaret er ofte "nei".) Hvis du arbeider med et konsulentfirma, har du snakket om hvordan de kan ta vare på arbeidet som konsulentene gjør, slik at andre kan ta over hvis det er nødvendig?

Få det skriftlig

En av de vanligste utfordringene, og den som er enklest å løse, kommer av dårlig dokumentasjon. Det er det enkleste måten å bli lurt på, men det at slik dokumentasjon finnes, kan utgjøre forskjellen mellom å gå tilbake til et skrevet referansemateriale og å lete etter en Batphone. Det er heller ikke nok å skrive et dokument og stappe det ned i en skuff et sted. Dokumentene bør bli en del av en kontinuerlig registrering, og EPM-prosessen kan referere til dem som en del av en regelmessig evalueringsprosess. Her er noen av dokumentene som jeg mener er viktigst for et EPM-miljø:

  • Lønnsomhetsundersøkelse    Jeg vet ikke hva det er med den innledende lønnsomhetsundersøkelsen som gjør den så kjedelig, men det er den tingen det er mest vanlig å miste oversikten over, og på mange måter er den grunnen til at du i det hele tatt har et EPM-miljø. Lønnsomhetsundersøkelsen viser hva de forventede organisatoriske fordelene er, altså hva organisasjonen forventer av EPM-systemet. Noe av det første vi spør om når vi får en "nødtelefon", er "Hva er det forventet at systemet skal levere?" Vi spør ikke bare administratoren. Vi spør også ledelsen, brukerne og de som har fordel av virksomheten. Svarene er forskjellige, alt etter hvem vi spør. Det er fordi det opprinnelige forretningspremisset er blitt borte.

  • Roller og ansvarsområder    I den siste versjonen av dokumentet for roller og ansvarsområder nøyer vi oss ofte med bare å angi navnet på en person, og det tar ikke lang tid før rollen som den personen har i EPM-systemet, er glemt. Hvis du har et dokument for roller og ansvarsområder, kan du justere parameterne for hvem som gjør hva i EPM-prosessen etter hvert som organisasjonen går gjennom personellendringer eller til og med organisatoriske strukturendringer.

  • Veiledning og flytdiagram for prosesser    Dette blir ofte glemt når vi kommer til prosedyremessige veiledninger. Man må nøye seg med "slik gjør du det"-trinn i en prosesshåndbok, uten at det opplyses om hvorfor disse trinnene er viktige og hva som skal gjøres med resultatet av hvert trinn. En prosessveiledning og – best av alt – et visuelt flytdiagram vil gi fremtidige ledere en forståelse av hva systemet leverer, og det vil bli mye enklere å tilpasse systemet i fremtiden.

  • Kriterier for systemutvelgelse    Når du har valgt EPM-systemet og eventuelle tredjepartsverktøy, bør du la fremtidige generasjoner vite hva avgjørelsen ble basert på. Vi har kommet inn i organisasjoner 5, 7 eller 10 år etter at systemet ble distribuert, og sett et system med flere tilknyttede verktøy, og spurt "Hvorfor gjør du dette? Det ville vært mye enklere å gjøre dette!" Grunnen til disse avgjørelsene er ikke å finne noe sted. I noen tilfeller har kunden i flere år gjort noe på en ekstremt komplisert måte, og dette kunne ha vært gjort mye enklere hvis de hadde hatt nyere versjoner av de eksisterende verktøyene. De kan ikke ta en så enkel beslutning som å endre et verktøy eller bruke en nyere versjon fordi de ikke lenger har tilgang til hvorfor de valgte å gjøre noe på en bestemt måte for mange år siden.

Det finnes virkelig ingen Batphone.

Når jeg sier det, er det nesten som å si at påskeharen eller julenissen ikke finnes. Det er bare dårlige nyheter. Men det finnes virkelig ingen Batphone. Men jeg er sikker på at selv om det ikke finnes noen magisk telefon, vil folk fortsatt ringe meg i morgen og be meg om å overvinne Gotham Citys nyeste skurk. Her er noen anbefalinger hvis du får problemer og føler behov for å ringe til en ekspert:

  1. Lytt til rådene du får. Det er tåpelig å betale en ekspert for å gi deg råd, og deretter bestemme deg for at du vet bedre enn de gjør. Hvis du skal spørre om råd og du har å gjøre med en ekspert, bør du prøve å lytte og i det minst vurdere rådene. Batman ville ikke ha fortsatt å komme når politimester Gordon ringte hvis Gordon hver gang hadde sagt: "Nå som du er her, Batman, kan du gjøre det samme som alle mine andre politimenn gjør."

  2. Batman kunne klare det på 22 minutter, men det vil sannsynligvis ikke du kunne klare. Hvis du ringer en ekspert, kan han fortelle deg hvor lang tid det bør ta å løse problemet. Etter at du har snakket med eksperten, kan du velge ikke å løse problemet, men de fleste EPM-utfordringer, selv de tekniske, kan sjelden løses på bare noen minutter. Batman måtte tross alt klare det på 22 minutter fordi 8 minutter var avsett til reklame, og de er viktige.

  3. Politimester Gordon fortalte bare Batman hva problemet var, ikke hvordan han burde løse det. Alt for ofte får vi en telefon fra en panikkslagen EPM-administrator som vet at jeg må bruke en oppdatering, skrive en rapport og lære opp to personer. Jeg lytter alltid tålmodig til dette, og deretter ber jeg kunden beskrive problemet på samme måte som han nettopp har beskrevet løsningen for meg. Før du ringer til en ekspert, bør du først tenke over hvilket problem du vil legge frem.

Konklusjon

Du må virkelig bruke Batphone. Spør deg for. Ikke spør bare én konsultasjonsekspert, og ikke få bare én mulig løsning. Spør kolleger eller andre i bransjen om de vet hvem du kan ringe til, og snakk med minst to av dem. Det er en bra virkelighetskontroll å se hvordan én ekspert håndterer problemer i forhold til en annen. Husk at Batman kan ha vært fantastisk, men det er mange superhelter å velge mellom!

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 og PMIs PMNetwork, og han er en fast spaltist for 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 en Microsoft Project Solution Partner siden 1995.

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

Hvis du vil lese flere EPM-relaterte artikler av Chris Vandersluis, kan du se HMS sitt veiledningsnettsted for EPM (http://www.epmguidance.com/?page_id=39).

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.

×