All posts in Project Management

Skandinaviens största event kring projektledning, ”Passion for Projects”, genomfördes nyligen på Svenska Mässan i Göteborg. Det handlar om passion, inte bara om passion för projekt utan även passion för förändring, utveckling och lösningar – det handlar om leverans av förändring och transformation…

 

Läs hela inlägget här:

https://www.netrelations.com/sv/inspiration/blogg/highlights-fran-passion-for-projects-2018/

 


SharePoint! När jag nämner detta ord är det med spänning jag inväntar reaktion… detta för att det finns starka känslor kring vilken upplevelse man har haft i samband med SharePoint. Reaktionen kan ha en närmast traumatisk återkoppling och andra reagerar euforiskt över tillfället att berätta om alla framgångssagor… varför har det blivit så och hur ser SharePoint ut idag?

SharePoint har en lång historia av att vara en ledande plattform för att bygga intranät och hantera företagsrelaterat innehåll. Enligt Nielsen Norman Group’s Top 10 intranets så är 70-80% av topp 10 intranäteten byggda på SharePoint. Det verkar dock inte lika vanligt att man skryter med det, nästan tvärt om och det händer att kunder frågar om man kan få det att se ut som något annat än ”SharePoint”.

Det klassiska (Classic) SharePoint lanserades redan 2002 och har genomgått flera upplyft genom åren. Eftersom det finns många olika lösningar av varierande kvalitet och flera olika versioner så är det nästan omöjligt att fullt förstå hur användare har mottagit lösningen. Microsoft behövde fatta ett beslut: översyn av den åldrande produkten, eller se SharePoint dö en långsam och smärtsam död. Resultatet fick vi se i fjol med införandet av den nya ”moderna” SharePoint upplevelsen (Modern).

På kort tid så har Microsoft lyckats koordinera flera parallella initiativ på flera olika nivåer och resultatet pratar för sig själv om man vill se efter. Några av de saker jag tycker sticker ut med detta nya tänkt kring SharePoint och Office 365:

  • Tilltalande sidor, listor och bibliotek – både för redaktörer och konsumenter av innehåll, påminner inte det alls om klassiska SharePoint
  • Responsivitet – Det är inte längre en fråga om sidorna fungerar på mobiltelefoner
  • Hastighet – Större del av koden körs på klienten, moderna webdelar och smartare indexeringsfunktioner
  • SharePoint Framework (SPfX) – Helt ny utvecklarupplevelse med nya moderna verktyg och process
  • Office 365 – bra integration till andra moduler (Outlook, Planner, Forms m.fl.) och nya grupper i Office 365 för att hantera användare och rättigheter
  • Hubbsidor – En platt struktur istället för mängder med undersidor, gemensamma funktioner och navigering
  • Flow – Automation och arbetsflöden som fungerar även utanför SharePoint, kan exporteras och utvecklas vidare som Azure Logic Apps
  • Teams – nytt samarbetssätt med allt som behövs i samma kontext
  • Agile/DevOps – nya kvalitetssäkrade funktioner snabbare, mer öppenhet och transparens

Enligt Gartner så är nu SharePoint rankad #1 på förmågan att exekvera innehållstjänster.

According to Gartner, “Content services platforms are the next stage of enterprise content management, representing a shift from self-contained systems and repositories to open services.” To truly deliver on the promise of content services, you must balance manageability with ease of use to unlock productivity gains around your critical business information.

Jag kan inte göra annat än att hålla med och hoppas att fler användare kan tänka sig ge SharePoint en ny chans. Kontakta gärna din favorit expert och boka in en demo på det nya moderna tänket kring SharePoint/Office365 och framtidens digitala arbetsplats.

:=)

 


I årets State of DevOps rapport så finns det med ett mycket intressant inlägg kring transformativt ledarskap (tranformational leadership). Bra ledarskap påverkar direkt teamets förmåga att leverera och detta bör ske genom agila och lean principer för maximal effekt.

Vad är då transformativt ledarskap?

Transformativt ledarskap är en modell där ledare inspirerar och motiverar anhängare för att uppnå högre prestanda genom att förankra sunda värderingar och målmedvetenhet, vilket underlättar omfattande organisationsförändringar. Dessa ledare uppmuntrar sina team att arbeta mot ett gemensamt mål genom sin vision, värderingar, kommunikation, exempel-inställning och deras uppenbara omsorg för sina efterföljares personliga behov.

Det som jag tycker är extra intressant med artikeln är just vilka karaktäristika egenskaper som effektiva ledare har för att genomföra transformeringar. Ledarna är ju mycket riktigt de som sätter tonen i organisationen och befäster önskade kulturella normer.

  • Vision. Har ett tydligt begrepp om var organisationen går och var den ska vara om fem år.
  • Inspirerande kommunikation. Kommunicerar på ett sätt som inspirerar och motiverar, även i en osäker eller föränderlig miljö.
  • Intellektuell stimulans. Utmaningar som följer efter att tänka på problem på nya sätt.
  • Stödjande ledarskap. Påvisar vård och hänsyn till efterföljarnas personliga behov och känslor.
  • Personligt erkännande. Säkerställer att mål och förbättringar av arbetskvaliteten uppnås. Ger personligen komplimanger till andra när de gör enastående arbete.

Men det är inte ledarens transformationsegenskaper som ensamt möjliggör transformeringen, utan det beror även på en lämplig arkitektur, god teknisk praxis, användning av agila/lean management principer. Bra ledare hjälper bygga högpresterande teams. Vidare så belyser artikeln en tydlig korrelation mellan transformationsledarskap och högpresterande teams. Analysen fann också att transformationsledarskapet är starkt korrelerat med Net Promoter Score (NPS).

State of DevOps har även andra bra artiklar, bland annat om Lean product management, så om du inte redan har hämtat hem rapporten så rekommenderar jag att hämta hem och läsa igenom… mycket nöje :)

 

 


I dagarna har jag tagit ytterligare en certifiering – PRINCE2® Foundation

En av de saker som jag verkligen gillar med PRINCE2 (PRojects IN Controlled Environments) är hur tillämpningsbar modellen faktiskt är. Betydligt mer så än vad jag antog tidigare. Det finns många bra saker med PRINCE2, några saker som är värt att nämna är hur väl PRINCE2 fungerar med Agila arbetsmetoder – tydlighet i hur faser, roller och delegation med toleranser hanteras och uppmuntrar till förtroende på bästa tänkbara sätt.

Certifieringen PRINCE2® Foundation är grundläggande och det finns ytterligare nivåer man kan uppnå, exempelvis PRINCE2 Practitioner (kanske blir ett framtida mål). Om man exempelvis jämför med PMP® certifiering så är det ganska stor skillnad i utmaning, där PMP är betydligt mer utmanande, men även har olika upplägg som delvis kompletterar varandra. Om man jämför tegelstenar (böcker) så är både PMBOK och PRINCE2 böckerna väldigt tunga att läsa pärm till pärm och en skillnad mellan dessa är att PMBOK är en guide till kunskapsbanken kring projektledning vilket medför högre förväntningar på förkunskaper.

En av de saker som jag fastnade på under mina förberedelser var på var ordet PID – Projektinitieringsdokumentation (Project Initiation Documentation), som för mig var förvirrande likt men ändå olikt en Projektplan enligt PMBOK. Detta eftersom det även finns en projektplan i PRINCE2, men har lite olika syften och innehåll – smått förvirrande om man redan jobbat in begreppet. Ett annat begrepp som jag inte riktigt blir vän med är ordet Produkt, mycket i PRINCE2 handlar om Produkter, med en solid nerbrytningsprocess för att hantera just Produkten av projektet. Av någon anledning så gillar jag inte ordet produkt i IT-utvecklingssammanhang utan föredrar Applikation, dvs. en applikationsnerbrytning och hantering av applikationslivscykeln för att belysa att det är digitala produkter vi arbetar med. Det är nyanser av skillnad mellan en fysisk produkt och en digital produkt (applikation), det finns även helt andra möjligheter kring en digital värld som rör sig mot DevOps (utveckling möter förvaltning) tankar. Så även med relationen till ITIL (Information Technology Infrastructure Library) där det mesta handlar om tjänster – då det är samma organisation bakom både PRINCE2 och ITIL så hade jag nog förväntat mig mer länkar mellan dessa båda – som hanterar två olika delar av samma livscykel (projekt och förvaltning).

Några andra skillnader mellan PRINCE2 och PMBOK är antalet kunskapsområden som en projektledare förväntas vara införstådda med – PRINCE2 har 7 kunskapsområden och PMPBOK har 10. PRINCE2 motiverar det med att de väljer att endast ha med kunskapsområden som är generiska för alla typer av projekt, vilket exkluderar områden som kontraktshantering och mänskliga resurser (HR). Även antalet processer är 7 stycken i PRINCE2, men i PMBOK så är det hela 47 olika processer, med mängder av verktyg och tekniker som en projektledare förväntas bemästra.

För några veckor sedan var jag och lyssnade på en föreläsning från Klas Skogmar kring skillnader mellan PMBOK® Guide och PRINCE2 på ett event ordnat av PMI Sweden. En mycket bra föreläsning med många bra punkter, där Klas även jämför mot ISO21500. Klas har även skrivit ett ”White Paper” på ämnet som finns att hämta på Axelos hemsida – https://www.axelos.com/case-studies-and-white-papers/prince2-the-pmbok-guide-and-iso-21500-2012 och det finns även ett webinar att tillgå – https://www.axelos.com/events-calendar/prince2-pmbok-guide-and-iso-21500-2-webinar

Det verkar inte som PRINCE2 är så stort i Sverige ännu men i övriga Europa så är det en väl etablerad modell och i synnerhet i ursprungslandet – England. Jag ser det som välinvesterad tid att certifiera sig i PRINCE2® Foundation och om du går i tankar att ta en första projektledarcertifiering så kan jag varmt rekommendera att just titta på PRINCE2® Foundation.

 

 


Årligen så genomför PMI en global undersökning kring projekt-, program- och portföljhantering för att fånga stora trender inom projektledning. I år 2015 ligger fokus på kunskapshantering, riskhantering, agilitet och förmågan att mäta framgång.

Det finns mycket intressant i årets undersökning och PMI framhäver att ledande organisationer fokuserar på att utveckla en kultur och ett gemensamt mindset kring projekthantering. Tydliga strategier för kunskapsöverföring och projektprocesser som ligger i linje med organisationsstrategier är gemensamt för framgångsrika organisationer.

Se vad som skiljer högpresterande organisationer från övriga i PMI infographic nedan.

Taking a Pulse

Taking a Pulse

Att många av de frågade inte fullt ut förstår nyttan av projektledningsfunktionen ger ju en del förbättringspotential att jobba vidare med.

Så här skriver PMI kring projektledning och agilitet (Capturing the Value of Project Management Through Organizational Agility):

Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. Agile allows teams to deliver projects piece by piece and make rapid adjustments as needed. Agile is not done in place of managing a project. Rather, it is frequently introduced as a way to speed up the phases of a project.

Smart organizations realize that using agile techniques, such as Scrum or DevOps, is not the only—or even the best—indicator of an organization’s speed or flexibility. In fact, the most agile organizations are more likely to use several different project management approaches, including agile/incremental/iterative project management practices (65 percent), Lean (55 percent), Waterfall (48 percent), and Extreme (37 percent).

Kanske är det just blandningen av projektprocesser och dålig kunskapshantering som leder till att många inte förstår nyttan med funktionen. Organisationer som lyckas blanda rätt mix av godbitar och med stor kunskap kring projekt är markant mer framgångsrika. Tydliga karaktärsdrag av Samarbete, Kommunikation och Flexibilitet leder till bättre projektresultat.

To become agile, organizations will need to make changes in how they work by establishing a framework around strategy, culture, leadership, people, and process.

För mer information och gratis nerladdning av rapporter och videos från Pulse of the Profession se http://www.pmi.org/pulse


Att bygga mjukvaror är svårt, att räkna på investeringar i mjukvaror är svårt, att möta investeringen med rätt byggkvalitet är jättesvårt. Vi vet oftast för lite kring vilken skuld vi har ackumulerat genom de beslut vi tar längs resan och vi fokusera inte ofta på att amortera skulder.

Total ägandekostnad (eng. Total Cost of Ownership, TCO) är något som investerare kalkylerar på för att se vad den totala kostnaden är för en mjukvara inför ett investeringsbeslut. Den totala ägandekostnaden omfattar såväl anskaffningskostnad som driftskostnad men i många fall så räknar man inte med ackumulerade skulder som en del av den totala kostnaden för ägande, kanske för att det inte finns bra modeller för detta eller för att man helt enkelt inte förstår att det kan kalkyleras.

Under en applikationslivscykel så skiftar investeringen från en kapitalinvestering (CAPEX) till en operativ kostnad (OPEX), vanligtvis från ett projekt till en förvaltning. Inkluderat i denna övergång är de skulder som ackumulerats vilket kan leda till oförutsedda kostnader och ytterligare investeringsbehov för att möta effektmål. Det är en stor risk att inte veta vilken skuld man äger och vilka mått av kvalitet man mäter på, detta kanske är än mer viktigt när det kommer till mjukvaror då det kommer strida strömmar av inkrementella förbättringar och de positiva riskerna (vinster) kan kontinuerligt värderas därefter. Det är trots allt idéer som blir till affärsapplikationer, som sparar pengar eller ökar omsättningen.

För några veckor sedan var jag med som talare på en konferens kring systemförvaltning och passade även på att lyssna på övriga talares framträdanden. Ett mycket intressant framträdande var från Johan Magnusson, forskare från Chalmers kring Teknikskuld (eng. Technology debt) och Teknisk skuld (eng. Technical debt). Det bredare begreppet kring teknikskuld som innefattar såväl personal (ideologi, kompetens, arbetsmiljö), användare (nöjdhet, rykte) och system (infrastruktur, skugg-it, teknisk, styrning) kan även ackumulera skuld på samma sätt som teknisk skuld gör vid exempelvis bristande kvalitet i konstruktion av programvara. Väldigt användbart för att hantera såväl risker som nyttorealisering och skuldsanering, ser fram emot mer insikt i denna forskning.

Att automatisera, optimera och integrera leveransprocessen är utmanande, men om inte snabbt införande prioriteras kommer det inte heller att gå snabbt, likaså är avsaknad av inbyggd kvalitetshantering det säkraste sättet att erhålla dålig kvalitet och en stor dold skuld med ockerränta. Genom att kontinuerligt värdera nya insikter och vikta dessa mot baslinjen så kan man istället undvika onödiga problem och säkerställa bra och friska nyckeltal.


En gång för länge länge sedan (som många sagor börjar) så fick två fotografer i uppdrag att ta klassfoton på alla klasser i en skola där elever skulle stå i längdordning från den kortaste till den längsta. Den första fotografen samlade in data från varje elev, sorterade efter ordning och bad sedan varje enskild elev ställa in sig efter ordningen. Den andra fotografen bad eleverna att själva ställa sig i ordning och litade fullt på att eleverna själva kunde lösa uppgiften. Gissa vilken fotograf som fick mest gjort, blev mest omtyckt och fångade de bästa bilderna?

Denna bildliga beskrivning är tyvärr inte så ovanlig som man gärna vill tro. Genom att ”våga” lita på människor så skapar man förtroende och trivsel.

Inom IT världen så förändras saker väldigt fort, vi är vana vid förändring i vår bransch. Vi behöver utvecklas konstant och vi drar snabbt nytta av nya tillskott. Som konsult så tar jag med mina erfarenheter och mitt anpassningsbara sinne in i olika organisationer där förändringsvanan kan variera en hel del. Vissa branscher är mer mogna och där är förändringar små och sällsynta, men i andra branscher kan kontinuerliga förändringar vara nyckeln till framgång. Vi ser ett allt mer växande behov av IT och fördelarna blir att större i takt med att IT blir mer moget.

Integration är något vi pratar om mycket inom IT branschen idag, det handlar om integration av applikationer, system och människorna. Hur vi söker och sprider kunskap och insikter hanteras idag till stor del av IT, vi behöver inte fysiskt röra på oss lika mycket tack vare IT tjänster. Industrialismen tillhör ett annat decennium och miljön mår bättre om vi inte behöver flyttas oss över hela staden, fram och tillbaka varje dag. Vi har fått fler valmöjligheter och kan anpassa vår vardag bättre idag, mycket tack vare IT.

Fördelarna med att väva in IT in i alla skikt av verksamheten börjar bli tydlig för våra ledare, men insikten och strategin för att nå fram till målen verkar vara grumligare. För lyckad IT-integration är det är centralt att ”våga” lita på människor och uppmana till förändringar.

Den åldrade föreställning att IT är något av en svartkonst som endast de invigda kan hantera är på väg att bli historia, som en bra historia som börjar med en gång för länge länge sedan…

 


Ordet projekt påminner en hel del om ordet projektil, båda kräver energi, har en startpunkt och ett mål, samt en inriktning och en styrning.

Att arbeta i projekt kan med fördel jämföras med en lagsport, utan tydliga positioner och samarbete så blir det inte bra och man lyckas helt enkelt inte med det man avser att åstadkomma. Rollen som projektledare är argumenterbart den mest krävande rollen i projektteamet. Många organisationer sänder sina projekt rakt in i fördärvet, genom att inte tillsätta en ledning för projektet och kanske inte ens säkerställer att tilltänkt ledare har en välutrustad ”verktygslåda” för att utföra uppdraget. Om man bara har en hammare så ser man alla problem som en spik, är ett talesätt som verkligen gör sig rätt här.

”Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.” PMBOK, 5th Edition

Det kan vara behjälpligt att ytterligare bryta ner verktygslådan i dessa 3 projektdimensioner nedan.

blog.yllemo.com-projektdimensioner

Tekniska-dimensionen
Denna dimension innehåller projektet många tekniska detaljer som projektledaren blir involverad i och därför bör ha större domäninsikt för att inte sinka teamet. Som IT-projektledare gör man lätt misstaget att tro att det går att driva ett mjukvaruutvecklingsprojekt på samma sätt som exempelvis ett infrastrukturprojekt. Båda är ju IT projekt, men det är stora skillnader som bör respekteras därefter.

Transaktions-dimensionen
Den kontrollerande dimensionen där man behöver säkerställa en baslinje och säkerställer avvikelser genom olika transaktioner och kontroller. Här är projektledarens roll mer styrande och övervakande. Inom systemutvecklingsprojekt så ser vi idag en reformation mot det agila hållet, där rollen som projektledare inte behövs i samma utsträckning och teamen själva tar ansvaret för arbetsprocessen.

Transformerande-dimensionen
Den transformerande dimensionen handlar mycket om ledarskap och försändringshantering. Eftersom projektledning handlar mycket om människor och att leda människor genom transformationer så är det ofta i denna dimension man hittar kompetenta ledare av människor.

Det kan vara utmanande att definiera var projektet befinner sig och det kan röra sig runt olika dimensioner över tid, vilket även är utmanande för projektledare som kanske inte har verktygen för utmaningen utan då ser allt som spikar att hamra på.

Rådet till den sponsor som söker tillsätta en projektledare för sitt projekt är likt rådet till en bågskytt, att säkerställa att det finns rätt energi, att det har en bra startpunkt och ett tydligt mål, samt en inriktning och en styrning mot målet.

En rutinerad projektledare som har erkänd erfarenhet (gärna certifierad) bör rimligtvis även ha den kunskap, förmåga och verktygslåda som behövs för att styra sponsor-projektilen rätt in mot målet, även om målet verkar flytta på sig mellan de olika dimensionerna.

 


Tittar man på ett historiskt perspektiv kring systemutveckling så ser man att det har hänt mycket kring antalet roller och verktyg som är involverade under hela livscykeln. Mängden kommunikationsvägar  har samtidigt ökat radikalt, det är betydligt fler specialister med i utvecklingsprojekten än tidigare och det blir därmed svårare att avläsa status då det behövs aggregeras data från fler källor än tidigare.

kommunikationsvägar systemutveckling alm

Det är kanske inte så ovanlig att specialister vill ha de bästa verktygen för just den specialiseringen man nischat in sig på, som exempel så vill ju gärna testproffs använda sig av Test Management verktyg och programmerare vill ju gärna ha effektiva källkodshanteringssystem. Börjar man lista dessa specialist system så blir det snart en gedigen lista och det är inte alltid så lätt att få dessa system att kommunicera med varandra utan manuell handpåläggning.

Det finns en formel för att räka ut hur många kommunikationsvägar som finns givet antalet kommunikatörer, formeln är n*(n-1)/2 och används ofta inom projektledning för att räkan på hur många kommunikationsvägar som måste hanteras. Som exempel så kan vi tänka att ett systemutvecklingsprojekt består av 10 personer så blir kommunikationsvägarna mellan dessa 10*9/2=45, alltså kan kommunikationen färdas på 45 olika vägar.

Denna formel går även att applicera på verktyg som systemutvecklare behöver använda för att bedriva effektiv systemutveckling. Om vi tänker oss att det finns 10 olika verktyg för systemutveckling (så som verktyg för programmering, källkodshantering, dokumentation, rapportering, krav, test, arkitektur, tidsrapportering, bygghantering och drifthantering) då blir även detta 45 olika vägar som information kan tänkas behöva flyta för att få effektivitet i flödet. Enligt min erfarenhet så är det inte så många organisationer som lägger samma vikt vid denna typ av kommunikationsvägar som i projekten, men det borde man för det minimerar waste (se Lean) och förbättrar kvalitet på resultatet. Detta argument är centralt i ALM (Application Lifcecycle Management) verktyg, där fokus är att länka samman alla verktyg och underlätta för hela systemutvecklingsflödet både mellan människor i sociala relationer och mellan verktyg och informationsflöden däremellan.

Är man ansvarig projektledare för ett större systemutvecklingsprojekt och får den vanliga frågan ”Hur går det?” så blir ju svaret ofta ett konsultsvar – Det beror på…
Det är ju så många olika saker som väger in och det är ofta svårt att få insikt om hur det faktiskt går vid en given tidpunkt och ibland kan det faktiskt vara så illa att man inte ens har möjligheten att införskaffa sig insikt då det är för många kommunikationsvägar som saknas eller inte är kompatibla.

 
Vi vill ju ofta arbeta mer agilt och i många kortare iterationer vilket är bra då man efter varje cykel kan avgöra om man behöver ändra riktning. För att denna process skall fungera optimalt så behöver även verktygen samspela effektivt över hela applikationen så det inte uppstår köbildning i någon instans där informationsflödet kan komma ur synk. Genom att samordna verktyg och processer för att aktivt hantera alla kommunikationsvägar över hela applikationslivscykeln så faciliteters även de sociala kommunikationsvägarna.


De flesta företag strävar efter mål och strategier som ger dem unika fördelar mot sina konkurrenter.

Förvånansvärt få av dessa företag har etablerade strategier för att skapa egenutvecklade fördelar med hjälpa av skräddarsydda applikationer och IT-lösningar, vilket jag nu tänkte redogöra varför jag anser att dessa företag borde tänka om.

Finns resultatet att köpa så bör man kanske inte utveckla det själv… det ger ju inga strategiska fördelar då konkurrenter kan köpa samma lösning. Köp då istället in den färdiga lösningen och investera istället där det faktiskt går att få en unik fördel. Genom att tänka på hur en IT-lösning kan erbjuda direkta fördelar för verksamheten genom att driva egenutveckling av applikationer, vi kallar detta begreppet – ”Strategisk IT”, den andra typen av IT kallar vi här för ”Nytto IT” och det är allt annat som inte är av strategisk vikt, se nedan:

blog.yllemo.com_stratit

Då Strategisk-IT erbjuder unika fördelar och Nytto-IT mestadels erbjuder verksamhetsstödjande IT så kan alla former av IT underminera verksamheten och försvåra för verksamhetens nyttjandegrad av IT-stöd. Genom att aktivt analysera hur verksamheten kan konsumera kunskap och leverera insikt och beslutsunderlag tillbaka till strategiska råd så får man se tidiga indikatorer på att något borde ändras. Precis som en kvalitetsprocess bör även en IT-strategisk process finnas på plats då nästan alla idag arbetar med hjälp av IT-stöd i någon form.

Det man skall värdera när man investerar i egenutvecklade lösningar är långsiktigheten, man borde tänka hela livscykeln och räkna in både projektresultat och de långsiktiga effektmål som man utvecklar för. Tänker man på detta redan tidigt i projektet så får man en förvaltningsbarhet kring lösningen som kortar ner vidareutvecklingstider och kunskapsöverföringstider.

Det är först till kvarn som får mala när det gäller strategisk-IT, den som först har sin lösning på plats vinner det största övertaget, nästa företag som försöker nå samma fördel får en betydande nackdel och över tid så blir nya innovationer ofta ett tvång för alla andra företag. Ett företag som inte har varit med på banan kan få en rejäl kalldusch och krampaktigt tvingas försöka komma ikapp, vilket kan vara en utmaning även för den bästa på den snabbrörliga informationsarenan.

Jag får ofta riskrelaterade frågor kring reaktivt beteende, vad gör vi om… något händer… vilket i sig själv är bra då risker skall tas seriöst. Men även positiva risker skall värderas högt… hur kan vi skapa IT relaterade fördelar från… något händer… När det kommer till risker så finns det mycket att göra även på informationsarenan.

Det gäller att veta vilka applikationer och processer man skall investera i för att nå de långsiktiga visionerna. Jag tror inte det är en bra strategi att tänka för brett och säga att allt är viktigt, då man då förlorar sitt fokus på det som faktiskt är av högsta prioritet. Vill man öka insikten i den egna organisationens it-flora så kan man söka IT-strategiskt rådgivning. Lämpligtvis från seriösa leverantörer som förstår samtid och verksamhetsbehov i relations till IT-behovet. Genom en kartläggning av existerande IT-stöd och samrådande dialog med verksamheten så kan en IT-rådgivning ändra riktning helt, det är inte helt ovanligt att man blir hemmablind.

Att tänka på IT från ett strategiskt verksamhetsperspektiv är nyckeln till framgång på informationsarenan. Inget kommer skapas automagiskt varken strategisk-it eller kunskapshantering utan det måste styras och aktivt drivas från toppen av organisationen och med fokus på rätt områden och av rätt anledning.