Vi har en tendens til å behandle ny teknologi som den hellige gral, et lysfyr og svaret på alt som er tregt, ineffektivt og gammelt. Og det kan være det - hvis det implementeres med en lastebil med planlegging og framsyn.
Men vel, vi vet alle hvordan det går.
I løpet av mine år i regjeringen, der det noen ganger føltes som om vi spilte et spill med teknologisk fangst som umulig var å vinne, lærte jeg hva som kan skje når denne framsynen blir tatt for gitt. Det ligner litt på Den hellige gral og mye mer som kostnadsoverskridelser, forsinkelser og omviklede løsninger på ellers enkle problemer.
Som jeg lærte, er en av de viktigste nøklene til et vellykket teknologiprosjekt det harmoniske forholdet mellom forretningsteamet og teknologiteamet. Etter min erfaring kjørte forretningsgruppen ofte endringen (vi trenger for eksempel et mer komplekst system for å spore føderale tilskuddsutgifter), men vi kunne ikke oppnå et smid av fremgang uten at utviklerne og IT-prosjektledere kunne gjøre det skje. Prosjekter endte ofte langt fra harmoniske, et resultat av å snakke forskjellige språk og opprettholde enormt forskjellige forventninger (en endring som for eksempel virket mindre for meg, som ofte viste seg å være viktig for utviklerne).
Men virksomhet og teknologi kan - og må - være venner. De gode nyhetene? Å oppnå harmoni er egentlig ikke så komplisert. Som ethvert samarbeid har det å gjøre med frekvensen og kvaliteten på kommunikasjonen, et gjensidig avtalt målsett og en plan for å håndtere den nærmest uunngåelige endringen av disse målene. Her er noen grunnleggende retningslinjer for å administrere divisjonen forretningsteknologi.
1. Mål å spikre kravene første gang
Tenk på forretningskrav som en blåkopi. Du ville ikke tegne et skissert sett med tegninger for et hus, levere dem til entreprenøren og ønske ham lykke til. Du ville ikke komme tre uker tilbake i byggingen og be ham legge til en tredje etasje og et fjerde bad, og kanskje et karnappvindu i stuen. Og du ville absolutt ikke tegnet tegningene dine uten innspill fra en arkitekt og en ingeniør.
Et teknologiprosjekt er ikke så annerledes. Det må utformes med presisjon, og når utviklingen begynner, er det ikke alltid like lett å imøtekomme endringer uten å påvirke hele fundamentet. Dette er grunnen til at det er avgjørende å være så omfattende som mulig fra begynnelsen og få innspill og kompetanse du trenger når du tenker gjennom hva løsningen vil kreve. Intervju sluttbrukere for å forstå utfordringene de står overfor og nøyaktig hvordan de vil trenge å bruke den nye teknologien. Ikke gjør forutsetninger, og ikke legg igjen deler av planleggingen til senere.
2. Men erkjenner at du vil savne noen få
Når det er sagt, fant jeg det nesten umulig å se for meg hver eneste funksjon vi trengte under de abstrakte planleggingsstadiene. Når systemet først var i utvikling, ville vi innse at vi glemte å be om en avansert søkefunksjon eller en “lagre og fortsett” -knapp. Da vi henvendte oss til utviklerne for å be dem om å imøtekomme disse nye forespørslene, ble vi ofte møtt med frustrasjon. Kanskje den nye endringen ville kreve at de angre arbeidet de allerede hadde gjort, og omarkitektur deler av løsningen. Kanskje vi så for oss at det skulle ta to timer når det faktisk skulle ta en dag.
Du kan ikke være i stand til å forhindre disse avsløringene senere i spillet, så det beste du kan gjøre er å bygge i en buffer for å imøtekomme dem. Legg til en ekstra uke til den opprinnelige tidslinjen og ytterligere 5-10% til budsjettet. Mange organisasjoner, som erkjenner hvor ofte forventningene endrer seg, har tatt i bruk en smidig tilnærming til utvikling og rullet ut teknologi i faser for å gi mulighet for periodisk revurdering. Uansett hvilken tilnærming du gjør, ikke gjør feilen ved å tro at du har tenkt på alt fra komme til farten. Det skjer nesten aldri.
3. Know Scope Creep når du ser det
Når prosjektet går videre og nye behov kommer fram, er det viktig å skille mellom de du virkelig trenger og de du bare ønsker. Å be utviklerne dine om å ta imot hver bjelle og plystre sinnet kan drømme opp fører ofte til uendelige prosjekter og altfor komplekse sluttresultater. Hver nye forespørsel, før den sendes, bør prioriteres.
Når du vurderer en funksjon, kan du stille deg noen grunnleggende spørsmål: Vil systemet fungere uten den? Hvor mye tid vil det ta å implementere, og hvor mye fordel vil til slutt leveres til sluttbrukeren? Hvis vi venter til en fremtidig løslatelse for å løse det, vil noe gå tapt? Det er en øvelse av prioritering, og alt kan tildeles en status som høy, middels eller lav. Hvis det er lavt, legg det på en figurativ parkeringsplass - jeg har hørt om selskaper som har dokumenter om "drømmeutvikling" som alle kan legge ideer til, og ingeniørene kan bla på fritiden. Det kan alltid ses på nytt som en del av en rekke forbedringer som skal gjøres når prosjektet er ute og løper vellykket.
4. Utvikle et felles språk
Ethvert nytt system har et sett av forretningsmessige mål. Det vil tillate deg å fange opp mer data, effektivisere en eksisterende prosess eller tilby nye tjenester til kundene dine. Det er avgjørende at forretningsteamet og teknologiteamet setter seg før noe arbeid har begynt og kommuniserer disse målene. Forretningsmålene må ikke gå tapt i et hav av teknisk snakk, og de må være godt i tankene i hver fase av arbeidet.
Å utvikle et felles språk betyr ikke bare kollektiv målsetting, men å spore fremgang på en måte som fungerer for alle. Virksomhet og teknologi kan bruke forskjellige verktøy for å måle arbeidet sitt, men det må være minst ett syn på fremdrift som deles. Dette kan være så enkelt som en prosjektplan eller et regneark med avtalte felt, som datoer og mål og prosent fullført, slik at alle har tilgang til statusen til hver oppgave som skal fullføres. Målet er å unngå en situasjon der forretningsteamet tror de er halvveis der, og teknologiteamet sier at de bare er et kvarter - alle skal ha den samme forståelsen av hva som er gjort og hva som er igjen å gjøre.
Det kan hende du snakker i forretningsplaner og PowerPoints, og de snakker kanskje i kode, men med mindre du kommuniserer tydelig fra farten, vil du aldri komme deg ut av Babel. Et vellykket teknologiprosjekt handler om et sinnemøte - ikke bare i begynnelsen, men på hvert trinn underveis. Erkjenn forutsetningene dine, og prøv å ikke lage for mange. Jo mindre skillet mellom virksomhet og teknologi, jo lettere vil det være å krysse broene dine sammen.
