Nödvändiga projekt som få bryr sig om och som inte ger någon belöning – det är det som it-proffsen fruktar mest, skriver vår amerikanska systertidning CIO.com. Här är deras lista över vilka projekt det handlar om.
1. Stora patchningsarbeten i sista minuten
Att patcha systemen för att se till att allt är uppdaterat och säkert är en viktig uppgift Men det är också en uppgift som de flesta it-proffs hatar.
– Vi får hela tiden stora projekt i vårt knä där man inte har patchat på flera månader, rentav år, säger Oli Thordarson, vd på it-tjänsteleverantören Alvaka Networks.
– Ibland kan det handla om hundratals produktionsservrar – och även utvecklings- och testservrar. Att veta att vi kan sabba ett stort märkes närvaro på internet om något går snett är väldigt stressigt. Det är därför som de interna medarbetarna ibland skjuter upp att patcha tills chefen plötsligt förstår situationen och inser att det blivit övermäktigt.
Oli Thordarson berättar om när Alvaka patchade Windows åt polisen i en stad. För alla på golvet gick det som smort, men polischefens och de högre polisbefälens datorer gick alla ner.
– De som leder polisen är inga blyga personer. De ringde oss och var helt skogstokiga för att de inte kunde logga in och sköta sina uppgifter.
Läs också: 10 analysmisstag att sky som pesten
Orsaken var att de använde sig av datorer som var lite annorlunda och hade tredjepartsappar som skapade en konflikt. Oli Thordarson och hans team lyckades rulla tillbaka uppdateringarna, isolera problemet och fixa allt på en halvtimme. Men det var en stressig halvtimme.
Så vad lär man sig? Det gäller att se till att man har en noggrant testad backupplan säger Unnar Gardarsson, teknikchef på Alvaka.
– Varje gång jag gör ett patchningsjobb så gör jag en projektplan som räknar in allt ifrån normala backuper till att förvarna personer och att stoppa tjänster. En del system är väldigt svåra att behaga och det krävs en väldigt specifik process för att ta dem offline. Att vara förberedd och tänka igenom varje tänkbart scenario är avgörande.
2. Den stora mejlmigrationen till molnet
Att gå från en traditionell e-postlösning till molnet låter rätt okomplicerat. Men det är det inte konstaterar Mike Meikle, vd på Securehim, som sysslar med it-säkerhet för vårdsektorn.
För det första, påpekar han, är användare bra på att hamstra och samla på sig gigabyte efter gigabyte av meddelanden som borde ha raderats för flera år sedan så bara datavolymen är skrämmande.
Går du från gamla system som Lotus Notes så måste du konvertera en hel del data. En del av informationen i mejlen är dessutom känslig och det gäller att se till att allt följer regelverk som GDPR.
Du hanterar också system som människor förlitar sig till dygnet runt för att kommunicera, boka möten och så vidare.
Mike Meikle berättar att han arbetat med företag där molnmigreringen tagit över ett år och krävt mycket handhållande.
– Eftersom e-post är närvarande överallt så får it direkt ta stöten om det går fel på något sätt. Trots att det finns Slack och andra gruppchattar så är mejlmigrering ett av de projekt som it-avdelningen verkligen fruktar.
Så vad lär man sig? Att precis som med alla andra projekt från helvetet gäller det att göra sin läxa i förväg. Se till att ha järnkoll på alla systemkrav och utse en kärngrupp av användare som du kan köra konceptvalidering, proof of concept, och piloter med. På så sätt kan du jämna ut alla ojämnheter i förväg.
– Det duger inte att it-avdelningen går runt och säger ”åh, det här ser bra ut, säger Mike Meikle.
– Du måste verkligen känna till kraven från dina användare och vad de kommer att tolerera.
3. Projekt som krävs för att leva upp till regelverket – men som ledningen struntar i
Det finns två slags it-projekt: de som får starkt stöd från den högsta ledningen för att de är strategiska för att lyckas och så alla de andra. Men de allra värsta är de där medarbetare måste tvingas – sparkande och skrikande – att delta.
– Projekt som drivs för att uppfylla regelverk och som ledningen gett sitt mandat till men som inte backas helhjärtat är de allra värsta, säger en chef på en it-konsult som vill vara anonym.
Tills för ett år sedan var han teknikchef på en stor finansiell institution på USA:s västkust. När han kom in på företaget var tillsynsmyndigheterna redan på gång att stoppa dem delvis på grund av en otillräcklig katastrofplan. Aktieägare drev på för att de skulle städa upp i röran och även om ledningen stöttade projektet så hade avdelningscheferna andra prioriteringar och där låg inte katastrofplanen högst på listan.
Så de deltog helt enkelt inte och lämnade inte in det material som krävdes för att identifiera kritiska data och appar. De lät bli att delta i testningen och ignorerade mejl som teknikchefen skickade.
Han vände sig till cio:n och klagade men möttes av tystnad. Så projektet gick vidare trots att ingen ville kännas vid riskerna.
Så vad lär man sig? Att dokumentera hela processen – även de misslyckade försöken att få olika parter att delta – är grundläggande. Men du måste också se till att informationen går till rätt personer så att de som stöttar projektet inta kan skylla på att de inget visste.
Annars kan man göra som teknikchefen – byta jobb så snart som möjligt.
4. Affärssystem är ett fult ord
Troligen skapar implementeringen av ett nytt affärssystem mer ångest än några andra projekt.
Att få ihop affärssystemet med alla de gamla systemen är fyllt av faror – och när du dessutom kastar in språkliga och kulturella barriärer så har du ett recept för en katastrof av enorma proportioner, enligt Dan Coleby, konsultchef på ITLab.
För drygt tio år sedan arbetade han på en av de största konsultfirmorna i London Han kallades då in för att hjälpa den japanska delen av ett stort multinationellt bolag att rulla ut företagets globala affärssystem. Det hade då redan hållit på i två år och gått över budget, delvis beroende på att en del hårdvara var riktigt gammal.
– Ett av systemen var så gammalt att vi måste låna strömförsörjning från en utställning på National Computer Museum i Tokyo om det enda som de hade på företaget inte skulle fungera.
– Vi hade bara åtta timmar varje natt på oss att lägga in nya data i affärssystemet i åtta timmar men gränssnittet tog 20 timmar att köra så det var i princip meningslöst.
Läs också: Från blockkedjan till robotkirurger – här är de 8 farligaste tekniktrenderna
Men det största problemet var inte tekniskt utan personligt och politiskt. Dan Coleby var helt enkelt tvunget att lista ut hur han skulle få systemet implementerat utan att någon förlorade ansiktet. Dan Coleby fick inte röra arkitekturen, strategin eller företagets globala förhållningssätt till teknik.
– Det slutade med att jag övertalade japanerna att ändra sina affärsprocesser så att de använde mindre information. Jag tog bort 90 procent av alla data och då kunde systemet köras på mindre än åtta timmar.
Så vad lär man sig? Jo att tekniken inte ensam är svaret – människorna och processerna är minst lika viktiga.
5. För lite tid och för mycket lovat
Kanhända beror det på extrem optimism eller en önskan att imponera på chefen. Men att underskatta tiden och ansträngningen som det tar att leverera en applikation kan göra ett utmanande projekt till ett helvetiskt.
– Folk är ofta väldigt optimistiska om av vad de kan leverera på kort tid, särskilt i snabbrörliga företag, säger Alan Zucker, grundare av Project Management Essentials.
Han minns själv ett projekt från slutet av 1990-talet då han arbetade på ett stort telekomföretag. Varje månad fakturerade företaget över en miljard dollar med hjälp av hundratals ihoplänkade kalkylark och databaser för att hålla ordning på allt. Lösningen var en elegant idé där allt lades in i en databas och sedan låta dem på ekonomiavdelningen bygga sina egna affärsregler. Det fanns bara ett aber – it-avdelningen lovade att leverera lösningen på nio månader. När Alan Zucker ärvde projektet efter fyra månader var inte en enda rad kod skriven ännu och it-avdelningen samlade fortfarande in kraven från användarna. Och de insåg att jobbet var mycket mer komplicerat än någon insett.
I samma veva började alla peka finger åt varann konstaterar Alan Zucker.
– Min motsvarighet på it-avdelningen började gå i försvarsställning. Han skrev oändliga mejl som kändes som polisutredningar. Vid den här tiden, detta datum så sa den och den detta... och så vidare. Situationen eskalerade och det gick inte längre att ha konstruktiva diskussioner.
Först när it-chefen omplacerades och en ny person kom in kunde man skapa en mer tillåtande tidplan och projektet gick framåt igen. Det tog ytterligare två år innan det var klart, och till sist blev resultatet lyckat.
Så vad lär man sig? Alan Zucker säger att han i framtiden behöver backa ur konfrontation och hitta en väg för båda parter att vinna i slutänden. Han lärde sig också att det är okej att fråga efter mer resurser och återställa de ursprungliga villkoren för projektet. Och till sist visade det att det räcker med att ändra en enda del – eller en person – för att förbättra gruppdynamiken.
6. Speciella önskemål från högsta ledningen
Du har standardiserat hela den globala verksamheten på Android men för att få vd:n att lämna sin Iphone får du bända den ur hans händer. Eller så ber en chef som har styrelsens öra om att få en skräddarsydd lösning just för sin avdelning.
I en perfekt värld så skulle sådana projektförfrågningar kollas av mot de strategiska planerna för att se om de är nödvändiga för att må specifika mål innan de blev godkända.
Läs också: 5 viktiga färdigheter som sätter fart på din karriär
Men, konstaterar Mike Meikle, så fungerar det inte i de flesta organisationer.
– Ofta är det vem som helst som har mest politisk styrka som bestämmer vad som blir gjort.
Och det handlar ofta om att cio:erna inte har kraft att hålla emot.
– Många gånger viks de ihop som en billig kostym, säger Mike Meikle.
Så vad lär man sig? Om du inte har en ordentlig process för it-projekt så räkna med att dina prioriteringar blir överkörda av de som har mest muskler. Du måste hitta dina bundsförvanter när det gäller styrning, risk och regelefterlevnad och se till att it-avdelningen sitter med varje styrgrupp.
För att hantera it-projekten effektivt behöver du stöd från högsta ledningen konstaterar Mike Meikle.
– Om inte så kommer du att behöva betala chefernas nycker ur din it-budget så att det bara blir smulor kvar till mindre glamorösa men viktiga projekt som infrastruktur och nätverk.
