All posts in Project Management

En vanlig definition är att kunskap är att veta eller känna till något, en annan definition lyder att kunskap är sann, välgrundad övertygelse och ytterligare en annan definition är att kunskap är inlärd teoretisk förmåga att förstå, återge och tillämpa information och idéer. Det finns med stor säkerhet fler definitioner och tolkningar kring kunskap och blickar vi framåt in i nästa decennium så tror jag vi kommer uppdatera våra uppslagsverk med en bredare definition kring kunskap för att även inkludera kunskap baserad på kollektiv intelligens och artificiell intelligens.

I vår föränderliga värld så är ”kunskap” något vi tidigt lär oss att man ”måste” ha för att överleva och få ett bra liv. Mängden information runt oss ökar lavinartat och vi ignorerar ofta att kunskap är färskvara för människor. Halveringstiden för kunskap är väldigt kort, men med hjälp av digitala uppfinningar och högteknologiska maskiner så kan vi se på ”kunskap” med helt nya ögon.

The real voyage of discovery consists, not in seeking new landscapes, but in having new eyes

– Marcel Proust

Under hösten så presenterade Microsoft mängder av nya teknologier som avsevärt förbättrar organisationers förmåga att samarbeta och utvinna värdefulla insikter och kunskap från nya och redan existerande källor. Med nya spännande ord som Fluid Framework och Project Cortex så utlovar Microsoft en mycket spännande vision av framtiden. En vision där värdefull kunskap kan utvinnas ur data och information med kontinuerligt förbättrad artificiell intelligens. Genom att samarbeta i realtid med samma information oavsett kontext och dokumentformat kan vi enklare kan få en enda gemensam sanning – Single source of truth (SSOT).

Vad är Project Cortex?

Project Cortex använder avancerad artificiell intelligens (AI) för att leverera insikter och utnyttjar kollektiv ”kunskap” för att automatiskt organisera innehåll och innovativa upplevelser genom ämneskort, intranätssidor och kunskapsbanker i vanliga Office verktyg som Outlook och Teams. Project Cortex använder AI för att analysera innehåll från team och system, identifierar innehållstyper, extraherar viktig information och organiserar automatiskt innehåll i ämnen som projekt, produkter, processer och kunder. Som sedan skapar ett kunskapsnätverk baserat på förhållanden mellan ämnen, innehåll och människor.

Se mer kring Project Cortex på ALMBoK.com

Vad är Fluid Framework?

Fluid Framework är ny teknik och uppsättningar av upplevelser som gör samarbete sömlöst genom att bryta ner hinder mellan olika applikationer.  Stödjer samarbete för flera personer att samtidigt samarbeta direkt på webben och/eller innehåll inne i ett redan existerande dokument. Ramverket bygger på en komponentbaserad modell som gör det möjligt för skaparen att konstruera generiskt innehåll och använda komponenten i olika applikationer. Ändringar sker samtidigt på alla instanser där komponenten används. Detta möjliggör för nya sätt att samarbeta och säkerställer att information alltid är uppdaterad med senaste innehållet och ger även utrymme för digitala intelligenta agenter att arbeta tillsammans med människor.

Se mer kring Fluid Framework på ALMBoK.com

Vad är ALMBoK.com?

Application Lifecycle Management Body of Knowledge (ALMBoK) är en kunskapsbank kring livscykelhantering av applikationer och digitala produkter. Ambitionen är att strukturera insikter kring affärs- och mjukvaruutvecklingsmetoder, verktyg och processer längs hela livscykeln från vaggan till graven. ALMBok.com är helt gratis och utan reklamintäkter, men med möjlighet att stödjas som Patreon.

ALMBoK.com länkar samman information från flera platser på internet, exempelvis Wikipedia och Youtube för att skapa en snabb och ren översikt på kunskapsområden och för att referera till mer djupgående information kring produkter, metoder och externa länkar. Några heta kunskapsområden inkluderar:

Om du skulle vilja hjälpa till att utveckla ALMBoK.com med nya kunskapsområden så kontakta gärna mig direkt på Linkedin eller gå med i LinkedIn gruppen – https://www.linkedin.com/groups/6668160/


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.