4 olika kommunikationsstilar – viktigt att förstå i projekt

På en projektledarkurs för några år sedan fick jag lära mig fyra olika kommunikationsstilar.
De är:Fyra kommunkationsstilar

Man kommer fram till dessa fyra kommunikationsstilar genom att definiera två dimensioner. Den första dimensionen är från social(bryr sig i första hand om relationer) till saklig(fokuserar på fakta).

Den andra dimensionen är från stödjande till drivande. En stödjande person månar om förankring och att alla skall delta. De vill att hela organisationen ska vara se nyttan och vill att alla skall ta ett aktivt ägandeskap. En drivande person önskar framförallt förändringar. De är proaktiva och vill få fram beslut och resultat. De är otåliga och väntar inte in hela gruppen utan de går före.

Lägger man ut det skapas fyra olika sektorer och därmed fyra stilar/persontyper:

Vänskapliga(gröna enligt DISC) personer är stödjande och sociala. De vill att alla skall trivas och är mån om att alla är delaktiga. De bjuder in och tar hand om nya medlemmar och vill gärna bjuda på fika och ordna fester – enda hindret för dem är att hitta en bra anledning. De lägger stor vikt vid att alla trivs och mår bra. De brister ifall omsorgen om andra blir alltför stor och om deras omsorg går förhindrar tydlighet och resultatfokus.

Uttrycksfulla(gula enligt DISC) personer syns och tar plats och kan uppfattas som om de tycker att de är världens centrum. De har ett extrovert lärande eftersom de lär sig själva och får insikter genom att beskriva problemet för någon som lyssnar. De generaliserar ofta och är ofta bra på att se samband ur ett helhetsperspektiv. De tror att de är bra på strategifrågor, fast eftersom de ofta har många ideer hittar nya strategier hela tiden så stämmer det inte.

Ofta förstärker de en berättelse för att nå önskad effekt. Omgivningen uppfattar det beteendet som lite falskt, men det tycker de inte själva för de är inte så noga med detaljer. Deras styrka är visioner, de är bra på att övertyga och sälja in ideer och skapa engagemang. De är bra på att driva på förändring och de försöker föra in nya tankar och idéer. De är inte så bra på att göra det sista som krävs för att slutföra ett projekt. I det läget har de istället ofta bytt fokus till nästa projekt. De tar ofta snabba beslut men det går också snabbt för dem att ändra redan tagna beslut.

Pådrivande(röda enligt DISC) personer driver projekt med liten hänsyn till det mellanmänskliga. De gillar att sitta i förarsätet och styra själv, i alla fall över ett område som de kan betrakta som sitt.  Om de inte får sitt eget område att styra över så är de inte alls med i projektet utan redan på väg till något annat. Man kan se ett sånt mönster hos Göran Persson, vår före detta statsminister. Redan på 70-talet kom han kom in i riksdagen men övergav riksdagsarbetet efter en mandatperiod och återvände till Katrineholm där han senare blev kommunalråd. I Katrineholm kunde han styra själv. Efter att Göran avgått som partiledare blev han inte kvar i Stockholm utan flyttade tillbaka till Sörmland igen för att som ägare till en skogsfastighet kunna styra själv.

Om man vill få en pådrivande person mer motiverad i projektet skall man säga ”det vore bra för din karriär”. De har svårt att passa in i rollen som endast teammedlem och behöver en uppgift eller ett område de kan styra över själva.

Analytiska(blå enligt DISC) personer gillar att skapa struktur och ordning. De är de som läser alla bilagor i utskickade mail, och de kan ofta inte förstå varför inte alla andra gör detsamma. De skapar ofta strukturer vid sidan av den egentliga uppgiften. De strukturerna kan vara bra på sikt, men ofta är det för kostsamt och oftast inte nödvändigt. De anser oftast att de inte är klara. De blir nämligen aldrig 100% klara.

Analytiska personer har ett i huvudsak inåtriktat lärande. De vill vara ifred när de lär sig själva. De lär sig genom att hämta fakta från böcker och andra källor. Analytiska kan uppfattas som tysta och inte delaktiga, men när de får utrymme och uttalar sig är det oftast genomtänkt. Om en analytiskt person tar ett beslut så ligger det fast och ändras inte i första taget. Problemet är att det är svårt att ta beslut för det finns ju alltid ytterligare en aspekt som man borde undersöka och ta hänsyn till.

Vilken persontyp är du?
De flesta upplever själva att de är en kombination av de fyra persontyperna. Det är normalt att man har olika stil i familjen, på arbetet och ibland sina vänner. Man kan även byta stil när man blir stressad. 

Personer i din omgivning upplever att du stämmer överens med en av persontyperna och de bestämmer sig ofta inom några sekunder. Några personer gillar överhuvudtaget inte modellen för att den är inte tillräckligt exakt.

Jag själv uppfattas av omgivningen som social, ofta uppe till höger bland de uttrycksfulla. I vissa tillfällen är jag pådrivande och i jobbet är min uppgift till stor del analytisk, men jag tar ofta hjälp av andra mer sakliga och detaljkunniga kollegor som jag samarbetar med.

Annan kommunikationsstil i stressade situationer
Många byter till en annan stil när man upplever stress. Skillnaden kan vara stor. En uttrycksfull kan bli analytisk och börja analysera det underliggande problemet till att projektet har problem och håller på att krascha. En analytisk person som upplever att det är kris kan bli pådrivande och börja dela ut order till sin omgivning. Omgivningen blir mycket förvånad och osäker och vet inte hur de skall reagera om skillnaden i stressade situationer är stor.

Paradox
Modellen hjälper mig att förstå och acceptera andras beteende och jag kan anpassa min kommunikation. Jag blir mer tolerant när jag inser att det finns andra synsätt som egentligen är lika naturliga och självklara för andra. Oftast de flesta flesta med. Paradoxalt agerar och reagerar vi oftast precis tvärtom. Omedvetet förutsätter vi att andra personer i omgivningen är precis som oss och tänker på samma sätt. Det finns en bok som heter ”Omgiven av idioter!” som beskriver hur det kan kännas.

Situationsanpassad kommunikation
Det ideala är att man kan anpassa sitt beteende och sin kommunikation beroende på den man möter och den situation man befinner sig i.


Läs mer:

PowerPoint – How to present and convince your audience!

 

En mer utvecklad modell för personprofiler som jag lärt mig senare finns beskriven på denna sida

Vad förväntas en certifierad arkitekt kunna?

En av mina utbildningar och certifieringar som arkitekt heter ”Certifierad Microsoft .NET-arkitekt av Microsoft Sverige och Sundblad & Sundblad” som jag gick 2006. Tänkte lyfta fram det jag skrev om kraven för det gäller fortfarande.

Certifieringen innebar utbildning hos Sundblad&Sundblad under under 4 ggr 3 dagar, tillsammans 12 dar.  Den kanske största behållningen av kursen var diskussionerna med kursledningen och de andra kursdeltagarna. Nästan alla var erfarna utvecklare, en del var konsulter, andra anställda på stora företags IT-avdelningar.

Tyngdpunkten låg på att förstå verksamhetens krav och hur de skall överföras till lösningar. För att riktigt kunna ta till sig utbildningen anser jag att man måste ha gått och funderat på verksamhetsprocesser och problem kring dessa och hur de borde lösas i tio år. Så var det nog inte för alla. Sedan var det väldigt mycket om SOA. Det är inte vanligt med så bra kurser.

Utbildningen utvärderades av Microsoft Learning i Redmond och de fann att materialet och effekterna på deltagarna var mycket goda. Därför har man köpt ut utbildningssmaterialet och skall genomföra utbildningen on-line webbaserat över hela världen tillsammans med Sten och Per Sundblad.

Microsoft tog för några år sedan fram ett certifieringsprogram för arkitekter som är mycket exklusivt och dyrt. Målgruppsmässigt är det avsett för kanske 5-10 personer totalt i Sverige. Kraven är tydligen extremt höga men områdesindelningen av vad man skall kunna är intressant.

Lösningsarkitekter(Solution architects) förväntas ha goda kunskaper inom följande områden:

  • Ledarskap
  • Kommunikation
  • Organisationslära
  • Strategi
  • Arbetssätt och taktik (innefattar kravhantering, modellering, informationsmodellering, stödja teknisk projektledning, metodkunskap, förståelse för driftsättningsstrategier och begrepp som SLA och ITIL)
  • Teknisk bredd
  • Tekniskt djup

Även om jag inte alls tillhör de fem svenskar som skall prova att certifiera mig enligt det programmet anser jag att områdena väl beskriver vad som krävs av en arkitekt. Det är en bred roll. Många av områdena är mjuka områden som ledarskap och förmåga att hantera konflikter. Det är också tydligt att det inte är teknisk projektledning, utan man skall ge bidrag till de som arbetar med teknisk projektledning. Teknisk projektledning är en egen specialitet även om kunskapskraven är ganska lika.

Läs mer vad varje område innehåller och om Microsofts certifieringsprogram för arkitekter här

Man verkar inte behöva kunna något om Agile eller Lean Software Development. Det är en brist i deras program.

MacBook Pro

Har köpt in en MacBook Pro. Min första Mac. För 18 år sedan på tekniska högskolan i Linköping blev jag ”frälst” på Appledatorer. Jag tänkte mig att jag bara skulle arbeta med Mac. Så blev det inte. Det blev PC istället. Det finns mycket mer IT-jobb och systemutveckling i PC-världen.

Fast en gång hade jag ett konsultuppdrag med ett specialanpassat verktyg för Mac som hette HyperCard. Hypercard hade hyperlänkar för navigering innan webbsidor ens var påtänkta.

Men nu är jag tillbaka. Fast jag har också minst 4 PC hemma…

Socialt entreprenörsskap – en trend?

Så här i valtider blir jag glad över att några av mina vänner satsar på socialt entreprenörskap. Kanske är det en trend.

Pernilla Näsfors har startat bolaget OpenHeart och kallar sig Social IT Entrepreneur. Stina Berge står på 6:e plats på Centerns riksdagslista för Stockholms län och har som titel: social entreprenör.  En investerare och företagsledare jag känner, Karin, har engagerat sig i ledningen för Elisabethgården i Vimmerby som tar emot kvinnor som utsatts för våld.  Arbetet är verkligen socialt entreprenörskap för utsatta kvinnor och deras barn.

Jag hoppas att det inte är en tillfällighet. Denna trend gillar jag verkligen och kommer att försöka stödja på lite olika sätt. Först genom att rösta på Stina Berge. Partifärgen har mindre betydelse för mig. Jag kryssar Stina för att jag vill att hon skall komma in i riksdagen. Det är mer kraft och driv i hennes åsikter än vad hon ger sken av.

Pernilla kommer jag att försöka stötta i hennes företagssatsningar och Elisabethgården kan jag göra reklam för. De har en fin text av Sören Kirkegaard på sin webb som inspirerar mig. Mer socialt entreprenörskap för ett bättre Sverige. Undrar om något parti har den slogan så här i valtider?

Projekt i den nya globala världen

Vi kommer att arbeta mer och mer i globala projekt. I Asien växer IT-satsningarna starkt. Läs Reuven Cohens blogg om framgångar för Cloud Computing i Asien.

Det kommer att bli viktigt att veta vad som fungerar och inte fungerar när teamet är spritt över hela världen och man måste leverera resultat varje dag, vecka och månad.

Jag hittade en riktigt bra inlägg, ett pattern, för detta. Läs J.D. Meiers blog ”Patterns and practices for distributed teams” om du vill.

Lycka till. Framtiden tillhör de som har erfarenhet av globala projekt.

Verksamhetsarkitektur(VA) och behovet av VA

En insikt efter paneldebatten är att vi deltagare talar förbi varandra. Anledningen är att vi har olika definitioner av vad en arkitekt är och att vi har olika problembilder som vi vill lösa.

Rollen som jag företräder här i detta inlägg heter verksamhetsarkitekt och området heter verksamhetsarkitektur(VA). Jag vill ge ett exempel på ett problem som är lagom komplext men som visar på behovet av VA. Nedan finns en skiss över Scrum-teamens ansvar:

3 team med totalt 20 personer

3 Scrum-team med totalt 20 personer

Utvecklingsarbetet är uppdelat i tre olika oberoende Scrum-team som samarbetar eftersom det anses vara det mest effektiva i den aktuella situationen. Om alla 20 skulle arbeta i samma team blir resultatet sämre. Uppdelningen i team leder i sin tur till problem som redovisas längre ner.

Kund – teamet utvecklar ett CRM-system som fokuserar på kunder, många länder, många marknader, komplicerade kundorganisationer med dotterbolag, marknadsbolag och internationella koncernbolag med personal med olika roller.

Produkt – teamet utvecklar ett produkt och konfigurationssystem med många olika produkter som består av komponenter, där produkterna kan sättas samman i sammansatta produkter och där man ute vid sälj- och leveransprojekt önskar få hjälp med vilka komponenter som fungerar i vilka produkter och i olika versioner.

Installerade produkter – teamet utvecklar ett system som har som mål att hålla reda vilka produkter i vilka konfigurationer har installerats hos vilka kunder och på vilka platser. Man vill kunna svara på frågor som:  Vilka avtal finns och vad avser de? Vilka tjänster, garantier och service ingår? Vem är kontaktpersonerna hos det egna företaget och hos kunderna?

I verksamhetsarkitekturen beskrivs i enkla modeller och innehåller övergripande processbeskrivningar, informationsmodeller, existerande system och gemensamma tjänster enligt SOA. Det finns också matriser som visar existerande beroenden mellan processer, informationsobjekt, system och SOA-tjänster.

Verksamhetsarkitekturens modeller ligger lagrat gemensamt och tillgängligt för att alla teamen skall ha tillgång till en gemensam bild på helhetsnivån. Avsikten är att modellerna skall underhållas ute i de olika teamen och att ändringar av gemensamma modeller skall ske kontrollerat och därefter spridas.

Problem: De olika teamen har olika syn

Det finns i exemplet tydliga beroenden mellan teamen men trots att man utsett en ansvarig för modellerna och möts i gemensamma möten enligt federativ modell så kan man inte enas. Produkt och Kundteamen tycker inte att det är viktigt att uppdatera de gemensamma modellerna. ”Installerade produkter”-teamet anser att det är viktigt. De är också i högsta grad beroende av de andras modeller.

Min fråga till agilisterna: Vad gör man?

Vad gör man om man är renlärig agilist (förespråkare av Agile Manifesto) om man är beroende av varandras modeller mellan teamen men ett eller flera team prioriterar kortsiktigt och man efter samtal inte kan påverka de andra teamen att ändra sig? Samlar man produktägarna? Eller beställaren? Eller bidar man sin tid till fler blir medvetna/mogna och inser problemet och vill lösa det?

Mitt förslag på lösning: Verksamhetsarkitektens arbete och ansvar

En utsedd ansvarig verksamhetsarkitekt eller en styrgrupp går in med mandat och anger ramarna för hur viktiga modellerna är och hur de skall underhållas av teamen. Teamen anpassar sig till dessa ramar. De gör fortfarande inte lika (vilket är tillåtet), men de håller sig inom de uppsatta ramarna, om inte så måste någon styra upp det hela efter sitt mandat. Det finns ett motsatt problem när teamen arbetar för mycket med sina modeller. Det är inte heller tillåtet.

Problem med Agile-synen

Agilisterna(förespråkare av Agile Manifesto) saknar lösning på problemet ovan om de inte accepterar någon som har mandat att styra när teamen har olika åsikter och inte kan påverkas. Agilisterna gillar oftast inte heller det faktum att teamen måste uppdatera de centrala modellerna. Anledningen är att modeller inte är fungerande programvara som är det enda resultat som verkar räknas inom Agile, eller som det står i manifestetWorking software over comprehensive documentation”. Egentligen är källkoden också slags en modell, ett perspektiv över systemet. Fast det har man ofta inte tänkt på.

Lösning: Vidareutveckla Scrum/Agile

Min åsikt är att agilisterna är alltför begränsade i sin problemdefinition. Deras nuvarande arbetssätt fungerar bara i mindre sammanhang i små företag eller för arkitektur inom en lösning.

Det bör vi ändra på. Det kan lösas om vi vidareutvecklar Scrum/Agile-rollerna och tillåter modeller som resultat och använder redan etablerade och fungerande sätt att snabbt ta fram dessa modeller.

Modellerna får inte ta för mycket tid

Modellerna får inte ta mer än max 2 månader att ta fram initialt och de finns sedan gemensamt tillgängliga. Specialister(verksamhetsarkitekter) och inte teamen är ansvariga för att det finns modeller att utgå ifrån. De första modellerna tas fram i seminarieform av erfarna seminariehandledare tillsammans med sakkunniga från verksamheten.

Teamens ansvarar för återkoppling

Teamen är ansvariga för att underhålla och uppdatera modellerna mer eller mindre kontinuerligt och att bevaka och anpassa sig och införa förändringar i de gemensamma modellerna som berör teamets ansvarsområde.

Lösningen ovan finns nästan i verkligheten också

Lösningen ovan är inspirerad av ett företag i telekombranschen. Mandatet att ge riktlinjer, granska och styra projekten är i den organisationen delegerat till en grupp, ett forum (Information Model Architect Forum). På det företaget har man inte anammat Agile/Scrum än annat inom små projekt inom teknisk produktutveckling.

Vinster med verksamhetsarkitektur(VA)

Företag som har ordning och reda på sin verksamhetsarkitektur kan tjäna mycket på det eftersom det ger klarhet och tydlighet. IT-systemen förbättras. Ledningen får bättre kontroll, även på kostnaderna. Kvaliteten höjs. Systemlösningarna kan bli mer flexibla och beslutsunderlagen för ledningen kan förbättras inför stora förändringar som inför uppköp och sammanslagningar.

Världens vackraste stad?

Jag läste ett blogginlägg som jag vill lyfta fram om världens vackraste stad. Tonen i texten, balansen och förmågan att uttrycka sig målande med få ord uppskattar jag.  Det känns verkligen som om jag är med,  först i besöket i skärgården och sedan på jazzkonserten. Jag längtar kanske själv tillbaka Stockholm och minns  liknande upplevelser från tidigare år.

Det visar att IT-folk är känsliga och kan uttrycka sig målande om det vackra i livet. En av anledningarna till att jag själv började blogga var att jag vill komplettera bilden av de som arbetar med IT. Tack Sebastian.

Företagsbesök i Silicon Valley 1998 – styrkan i nätverket

Jag åkte på en resa med Dataföringen till Silicon Valley1998. Vi gjorde tio företagsbesök, ett varje halvdag. Det var IBM:s laboratorier, Sun, Oracle, Sveriges tekniska attachéer mm. Jätteintressant.

Vad kommer jag ihåg? Jo, att man på de tekniska attacheerna berättade om strategin att använda sitt nätverk för att få kommentarer/råd. Man sa där att varje ide, varje initiativ låg ca 3 tre veckor före sina konkurrenter. Vinnare var de som kunde hantera sina idéer på bästa sätt. De som kunde dra nytta av sitt nätverk av personliga kontakter för att få kommentarer/råd.  Då hade man större chans att behålla sitt försprång.

Denna tanke gjorde jag till min. Jag har byggt ett nätverk av rådgivare. Jag väljer att vara öppen. Det känns bra för mig personligen. Det utmanar det andra sättet, kontroll-sättet, på ett bra sätt. Det ger verkligen nytta för mig.

Det andra som jag kommer ihåg var att jag tänkte ”Oh, vad en del är korkade!” om några av de andra deltagarna. Bakgrunden av att ett företagsbesök hade blivit inställt. Därför åkte vi till ett annat företag, CompuServe, på besök. Då 1998 var internet rättså nytt. Vi hade hört många tala om internets möjligheter på nästan alla företag i deras presentationer. Nu var vi på CompuServe som hade en egen programvara för det som kallades BBS(Bulletin Board Systems). De tillhörde den gamla skolan. De hade precis blivit uppköpta av AOL.  De var hopplöst, långt efter. De hade inte kunnat integrera internet i deras strategi utan de sa att deras klient, deras slutna system, skulle bli framtiden.

Efter besöket överhörde jag en annan av deltagarnas kommentarer om CompuServe. De sa samma kommentarer som på de lysande företagspresentationerna. ”Intressant”, ”Vilka möjligheter!” typ och jag tänkte”Oh, vad en del är korkade!” Vilka bortkastade pengar för deras organisationer att skicka dem på denna resa…

Jag själv var helt upp i entreprenörskapet. Jag arbetade på Know IT som konsult, men mitt i den superintressanta resan från 36 personer(när jag började 1994) till ett par hundra anställda vid börsintroduktionen (-97) och då -98 var ju värdet på aktierna riktigt på väg upp. Jag lärde mig mycket av att följa Know IT från insidan. Då -98 var dokusåporna ganska nya företeelser. Jag tänkte själv att den såpa som skedde framför mina ögon, med mina kollegor som aktörer, med ledningens agerande och styrelsens agerande, var mycket intressantare än det som gick på TV.

”Du kan sälja det kunden (tror han) vill ha, och jag kan leverera det kunden behöver!”

En erfaren verksamhetsarkitekt sa så till mig i ett sammanhang. Han hade sagt det till den kundansvarige och erfarne säljaren på konsultbolaget.

Verksamhetsarkitekten menar att ledningen/cheferna egentligen inte på djupet förstår och är insatt i detaljerna och därmed inte heller i vad de verkligen behöver. Detsamma gäller säljaren. Säljaren tror också, liksom cheferna, ibland att de vet vad de behöver. Låt alla tro det. Verksamhetsarkitekten, om han har riktigt stor erfarenhet, levererar det kunden behöver. Det blir win/win det. Fast på ett ovanligt sätt.

Det finns en variant av ovanstående som ofta förekommer, som får riktigt allvarliga konsekvenser. Det är när IT-folket tror att de förstår verksamheten och inte verkligen försöker förstå verksamheten. Då blir det fel. Och dyrt. 

Erfarenhet är nog enda sättet för att förstå vilket av alternativen som sker i ett specifikt fall för en viss kund. Att chefer och säljare skulle förstå alla detaljer går inte heller. Det kallas micro-management och funkar inte heller.

Företagskultur för ömsesidigt lärande

Värderingar

Denna tabell är hämtad från ett föredrag om facilitering av Frank Stenman, Lorensbergs organisationskonsulter. Det är viktiga värderingar för lärande organisationer som vill stödja samarbete mellan olika människor, roller och grupper. De stöder också mångfald. Det kan verka förvillande enkelt och självklart, men att verkligen leva efter dem i hela organisationen är svårt, ibland nästan omöjligt. Om man lyckas leva efter dem alla har man fått en företagskultur som stöder ömsesidigt lärande.

Tyvärr finns många exempel på motsatsen. De som sticker ut hakan och säger som det är blir ifrågasatta av gruppen. Man uppmanar ibland nya kollegor att ”hålla låg profil” för att de skall  fungera i denna typ av organisationer. Man säger sig leva efter dessa värderingar, men gör det inte i praktiken. Dessa organisationer går miste om intäkter och möjligheter som hade kommit fram om större öppenhet och fler personer hade fått möjlighet att lämna sina bidrag.

Frågan är också vad man skall göra om man upplever att man arbetar i en organisation som präglas av andra grundvärderingar. Skall man byta organisation? Skall man stanna och utmana och ifrågasätta det man tycker är fel? Visst skall man försöka förändra genom strida för sina åsikter, men jag vet också att det inte är en lätt fråga. Ibland vore det kanske skönare om man inte såg bristerna i organisationens företagskultur. Det är intressant att denna typ av kunskap, dvs organisationslära ingår i kraven på arkitekter enligt Microsoft. Organisationslära ingår som en viktig del i deras certifieringsprogram för arkitekter.

Läs mer om lärande i organisationer:
http://www.scu.edu.au/schools/gcm/ar/arp/argyris2.html