Jag kom hem från jobbet och började bläddra i Ny Teknik. Jag kom till spalten för veckans problem, miniproblemet, och började genast med en lösning. Veckans problem handlar om trafikstockning och lyder:

En graf över problemet

Ett mycket stort antal bilar skall efter ett evenemang i A köra till D. Vägarna AC, BC och BD har hög kapacitet. Där är körtiden alltid densamma, 2 h, 0,25 h respektive 2 h. Vägen AB har begränsad kapacitet, och körtiden är (1 + p) timmar, där 0 < p < 1 är andelen av bilarna som kör AB. Analogt gäller för vägen CD, med 0 < q < 1.

Man får först höra att vägen BC är avstängd. Då planerar ungefär hälften av förarna att köra ABD och resten ACD. I båda fallen tar det 3,5 h. Men just innan evenemanget är slut får man veta att BC har öppnats, och man får också kontinuerligt rapporter om trafikflödet på vägarna.

Denna nya möjlighet leder till att alla resorna tar en kvart längre. Hur kan det komma sig?

Eftersom alla bilar kontinuerligt har information om hur de andra bilarna agerar kommer samtliga bilar att ta lika lång tid på sig ute på vägen. Detta innebär att alla tänkbara vägsträckor kommer att gå lika fort att åka, så:

1+p + 2 = 2 + 1+q = 1+p + 0,25 + 1+q       (1)

<=> 3+p = 3+q <=> q = p

=> 3+p = 2,25 + 2p => p = q = 0,75

Stoppas detta in i (1) blir den totala åktiden 3,75 timmar, dvs 15 minuter längre än om inte en extra väg hade öppnats! En extra väg, som intiutivt borde innebär mer utrymme och kortare tid, ger istället motsatt resultat. Detta kallas för ett Nash-jämviktsläge som uppstår om alla individer försöker optimera för sig själva.

Exempel: Antag att det finns två aktörer som väljer mellan två alternativ; att ta den kortaste vägen för sig själva eller att tillsammans optimera med avseende på båda aktörerna samtidigt. I ruta (1) optimerar individerna med avseende på kollektivet, i ruta (4)  med avseende på sig själva. I ruta (2) och (3) optimerar någon individ med avseende på sig själv och den andra med avseende på kollektivet. Eftersom utfallet i dessa rutor är sämre än när båda optimerar med avseende på sig själva så kommer ett jämviktsläge uppstå i (4).

Ett annat exempel på Nash-jämviktsläge är då två aktörer plockar svamp innan den är mogen (eftersom någon annan kan komma att ta den innan dess). Detta är ett exempel på ett så kallat prisoners dilemma, som uppstår när det går att dra fördel av att agera direkt jämfört med att vänta.

Jag har precis avslutat mitt kandidatarbete vid Teknikens ekonomi och organisation, Chalmers Tekniska Högskola. Kandidatarbetet har titeln Morgondagens löpandebandmontering i ljuset av gårdagens erfarenheter. Syftet har varit att beskriva och jämföra några av dagens framträdande system för fordonstillverkning för att därefter komma till slutsatser om morgondagens produktionssystem.

Kandidatarbetet vid Industriell Ekonomi på Chalmers genomförs i grupper om sex personer och omfattar 15 högskolepoäng. Det innebär 1,5 års heltidsarbete (90 högskolepoäng) för en person, vilket enligt min perception är väldigt omfattande.

Eftersom gruppen består av sex personer som skall lösa ett problem krävs det således omfattande koordinering, styrning och samarbete.  Karl Wackerberg, som ingick i min kandidatarbetsgrupp, tar i sitt inlägg Att effektivt skriva examensarbete och rapporter upp några punkter som han anser särskilt viktiga för att en grupp skall komma överens. I detta inlägg skall jag ge min syn på grupprocessen för att skriva en uppsats.

Liknelse mellan gruppens produktivitet och resistans i parallell- respektive seriekopplade motstånd…

Illustration av parallellkoppling

Inom elläran finns en mängd olika lagar om samband mellan spänning – U, ström – I, motstånd (resistans) – R och effekt – P. Två välkända lagar behandlar motstånd i parallell- respektive seriekopplade kretsar.

Illustration av seriekoppling

Min teori om grupparbeten är att produktiviteten i gruppen varierar mellan ett tillstånd där alla får ut sin maximala förmåga och ett tillstånd då medlemmarna i gruppen hämmar varandra.

Att alla får ut sin maximala förmåga motsvaras av resistansen i den seriella kretsen där R_tot = R_1 + R_2 + … + R_n.

Att gruppens personer hämmar varandra får illustreras av motståndet i en krets vid parallellkoppling, där 1/R_tot = 1 / R_1 + 1/R_2 + … + 1/R_n, vilket innebär att R_tot < R_1, R_2, …, R_n.

Teorins övre gräns går att motivera med att gruppens prestation teoretiskt skulle kunna vara summan av alla individers prestationer om alla har exakt samma mål, uppgiften går att dela upp perfekt mellan individer samt att det inte är några problem vid sammanfogning av resultat. Dessa kriterier uppfylls dock väldigt sällan, vilket medför ”overheadförluster”. Overheadförlusterna  tar sig uttryck i kommunikationssvårigheter mellan gruppmedlemmar, försenade deadlines, svårigheter att passa tider, bristande engagemang, oförmåga att komma överens osv.

Hur skall en grupp styras för att uppnå bästa resultat?

”Adding more people to a late project only makes it later.”

- Är en följd av Lehman och Bellamys fem lagar kring programvaruutveckling och projektstyrning (Software Engineering and Projekt Management). Citatet går allmänt under akronymen Brooks lag. Anledningen till lagen är kommunikationsproblem och svårigheter för nya personer att sätta sig in i ett projekt på en kort tidsperiod.

Jag skulle vilja applicera Brooks lag på kandidatarbetet:

”Om en projektgrupp består både av personer som arbetar fram- och baktungt blir det ofta problem när de som arbetar baktungt visar att de vill börja bidra till resultatet.

Innebörden är att om gruppen har bestämt att arbeta efter vissa deadlines och dessa inte hålls av några i gruppen hamnar de efter. Jag tror därför det är mycket viktigt att verkligen etablera en gemensam ambitionsnivå. Om inte alla delar samma ambitionsnivå är det viktigt att det också framgår så alla vet vad som gäller.

Liksom Karl tror jag det är ett bra sätt att arbeta i par, på samma sätt som det är ett vanligt tillvägagångssätt i programmeringsprojekt. Att arbeta i par ger fler än en åsikt och en mer genomarbetad text med mindre fel.

Jag tror också att ett standardiserat arbetssätt är viktigt. Detta eftersom arbete efter standard gör att ”best practice” tillämpas, processen kvalitetssäkras och en tredje part kan ta vid där en annan slutat utan att behöva göra omskrivningar. Vid skrivarbete är standarder också viktiga för att ge en röd tråd genom texten. Jag tror heller inte på ägande av text. En text ägs av alla i gruppen och är fri att utveckla, ifrågasätta och korrigera från fel.

Andra element som är viktigt i grupparbeten för bearbetning av text är:

• Samarbete med uppdragsgivaren.
• Att avstämningar syfte och problemformuleringar kontinuerligt görs för samtliga inkrement i texten så att dessa inkrement inte leder till konflikt med vad som tidigare är skrivet.
• Att kontinuerligt se över strukturen i arbetet när nya inkrement görs. Kan det vara så att något är duplicerat? Sträva hela tiden efter låg sammanbindning mellan stycken och hög grad av sammanhang i stycken. Detta gör det enkelt att hålla struktur i texten och sortera om för andra upplägg. En skribent måste alltid förvänta sig förändring i texten.

Liknelse med agila metoder i programvaruutveckling

Mina rekommendationer ovan har utgått ifrån principerna vid den agila programmeringsmetoden extrem programmering. Extrem programmering utgår från följande principer:

• Kontinuerliga inkrement som gås igenom tillsammans med kunden och utvärderas för att generera krav till nästa inkrement.
• Parprogrammering ger kvalitet på koden på grund av dubbla genomläsningar.
• Alla äger koden.
• Samarbete med kunden för att specificera krav på nästa inkrement.
• Kontinuerliga tester när ett nytt inkrement införts. Samtliga tester som gjorts tidigare körs tillsammans med de tester som utvecklats för det nya inkrementet.
• Kontinuerlig refactoring av koden för att förenkla underhåll och framtida inkrement.
• Sträva efter låg ”coupling” och hög ”cohesion”.

Faktum är att det finns mycket att lära sig om skrivprocesser genom att studera punktlistor inom mjukvaruutveckling och tänka utanför det egentliga användningsområdet. Jag tror dock, trots all teori, att det vid nya projekt handlar mycket om erfarenheter från gamla. Därför gäller det att kontinuerligt utvärdera sig själv, göra ständiga förbättringar och aldrig vara nöjd.

Jag hittade en intressant lag, regel eller vad ni nu väljer att kalla den, när jag läste om programvaruutveckling (Eng. Software Engineering). Parkinsons lag lyder (Wikipedia):

”Work expands so as to fill the time available for its completion.”

Parkinsons lag innebär att om du sätter en tid på ett projekt eller arbete så tar projektet alltid så lång tid eller längre. Visst, det kan ta kortare tid, men oftast sätts komplexiteten i projektet så att det håller på tills tiden (eller budgeten) är slut.

Bedriver ett projekt

Lagen är av textboksförfattaren (Sommerville, 2007) tillämpad på IT-projekt, men enligt min mening bör den också vara tillämpbar på vilken typ av projekt som helst. Speciellt om inte projektet är planerat eller följer någon given process. Se mitt resonemang om hur management konsulter arbetar.

Referenser

Sommerville, Ian (2007). Software Engineering. Boston : Addison-Wesley

I programvaruutveckling (eng. Software Engineering) finns det i huvudsak tre olika processmodeller för utveckling:

Vattenfallsmodellen, evolutionär- och komponentbaserad utveckling.

Vattenfallsmodellen identifierar olika faser som gås igenom vid alla utvecklingsprojekt. Dessa består av kravspecifikation, design, implementation och enhetstest, integration och acceptanstest samt utveckling. Samtliga steg gås igenom sekventiellt och leverabler i form av rapporter presenteras när varje steg är avslutat. Det sker alltså ingen iteration mellan faserna och management kan enkelt styra processen. Detta har klara fördelar men också nackdelar i en föränderlig miljö.

Den andra konceptuella utvecklingsmodellen är evolutionär utveckling. Den består av samma faser som vattenfallsmodellen med skillnaden att dessa gås igenom i flera inkrement. Efter varje version är kunden med och tar fram nya krav till nästa version som sedan designas, implementeras och valideras. Modellen kan användas för att utveckla färdiga system samt för prototyper till kravspecifikation. Även varianter på evolutionär utveckling finns. Exempel är iterativ utveckling där kraven är färdiga och faserna därefter gås igenom i flera steg iterationer. Ett annat exempel är spiralmodellen där mycket frihet råder.

Den tredje huvudmodellen för programvaruutveckling är komponentbaserad utveckling (CBSE). Denna utvecklingsgren går ut på att återanvände färdiga så kallade COTS produkter, commercial of the shelf. Processen har går igenom följande steg; kravspecifikation, komponentsökning, kravanpassning till de komponenter som hittas, val av komponenter, integration av komponenter samt validering mot krav. Att använda CBSE minimerar ledtider och kostnader, minskar risker för projekthaveri och ökar pålitligheten eftersom komponenten testats tidigare. Nackdelar är att koden oftast inte kan inspekteras eftersom komponenten ofta kommer i ett kompilerat format. Detta ger sämre kontroll för underhåll och vad som ska ske i framtida versioner. Utöver att komponenter är körbara (kompilerade) är de standardiserade, oberoende av annat, har gränssnitt (requires och provides) och är väl dokumenterade.

Jag arbetar en del med java och skall sommarjobba med matlab. Att använda en vattenfallsmodell är då på grund av arbetets omfattning helt omöjligt. I sommar har jag en månad på mig för att sätta ihop ett matlab program som skall grafiskt skall kunna användas för beräkningar av olika eklektiska system. Att göra detta från ruta ett hade krävt tid för att lära sig hur allt ska fungera, bygga funktioner, krav, arkitektur osv. Jag kommer att utgå från funktioner som redan finns och min uppgift är att göra gränssnittet för att slå in dessa funktioner så att de går att använda på ett bättre sätt. Komponentbaserad utveckling..

GPS-klocka

Jag har länge funderat på olika privata projekt. Jag började lite på en flash applikation för att kunna presentera häftiga diagram från data ur en databas, men kom snabbt fram till att det inte intresserade mig. Jag har länge funderat på att skapa mitt eget program för gps hantering. Det jag använder nu är fokuserat på träning och har vissa bra funktioner, men jag tror att jag skulle kunna skapa något mycket bättre. Idéen är att skriva programmet i java för att kunna använda det både lokalt och via en applet på nätet. Programmet skall kombinera vanlig gps hantering i skogsmiljö samt träning med gps likt min gps-klocka (←).

Jag tror att jag behärskar de flesta av de tekniker som kommer att behövas för att skapa applikationen. Jag har nylighen hittat en mycket bra öppen komponent för gps kartor som jag kommer att använda. Komponenten omsluter (wrapper) javascript, som används för att programmera till de flesta kartor som till exepel google maps, med java. Claudius Hauptmann är en annan bra resurs som skrivit ett par artiklar om programmering till google maps.

Jag har varit en snabbis i Stockholm efter att ha sökt ett stipendium på Boston Consulting Group. Jag blev uppringd för en vecka sedan och fick veta att jag var i ”final”. Jag och ett par andra studenter från Chalmers skulle bli telefonintervjuade och en vinnare skulle utses för stipendiet på 25000 kr som BCG ger till en ambitiös student som ska plugga utomlands. Intervjun gick mycket dåligt och jag mins att jag inledde svaret på frågan vem jag är med ”ja, de finns väl inte så mycket att berätta…”. Jag fick dock sagt att jag är en ambitiös student, med fantastiska betyg som gör klassiker, jagar, spelar golf osv.

Min sambo Sofia blev också en av kandidaterna som gick till final för tjejernas stipendium. Vi satte oss på tåget mot Stockholm spända av förväntan dagen innan Valborg. Vi hade då fått reda på att det var tre killar och tre tjejer som tävlade om Chalmers stipendier. Chansen var alltså 1/3 för att jag skulle få och  5/9 att jag eller Sofia skulle få.

Kvällen blev jättehäftig. Den inleddes med en presentation på BCG:s kontor bredvid slottet som förklarade vilka BCG var; ett företag som hjälper beslutsfattare att ta svåra beslut, vilket självklart går att ta mycket betalt för. Ett av de senaste projekten som förklarades var stretegin för nästa års Volvo Ocean Race. Mycket av det som kommer förändras tycker jag var vettigt, dock inte att det kommer införas en åldersgräns för de tävlande eftersom äldre är dyrare för teamen. Enligt mig tar det bort lite av charmen med sporten.

Efter presentationen, där det bjöds på champagne, hoppade vi på en stor specialchartrad båt mot Lidingö. På båten bjöds det också på champagne och väl framme på restaurangen drinkar. Middagen bestod i av en förrätt med bland annat pilgrimsmusslor, en varmrätt med fasan och murklor och en efterätt med någon kakaogrej. Efteråt var det gratis i baren och kvällen avslutades för de som ville på Stureplan.

Affärsidén för en managementkonsultfrima

Den stora frågan jag ställde mig under kvällen var hur dessa konsulter jobbade för att bli så fruktansvärt välavlönade. Hur gör ni era kunder nöjda? Svaret på frågan är att de levererar oberoende tankar från extremt välutbildade och sympatiska människor som förhoppningsvis löser kundernas problem. För mig som läser Industriell Ekonomi och för tillfället Software Engineering kommer då en given följdfråga. För IT-projekt är det som levereras till kund okonkret (eng. intangible). Om en kund beställer ett program är det väldigt svårt att säga vad som ska levereras när det gäller pålitlighet, prestanda, design osv. Allt detta är subjektivt och det går egentligen inte att säga hur mycket resurser som skall spenderas för att göra kunden nöjd. Två mjukvaruingenjörer presterar ofta väldigt olika resultat och lösningar på samma problem. Hur vet man vad som är den bästa lösningen?  Inom Software Engineering jobbar man med standardiserade processer i utveckling och noggranna kravspecifikationer för att lösa detta problem.Trots detta misslyckas över 50 % av alla IT projekt och 80 % går över budget. En statistik som hållit sig på samma nivå sedan den första transistorn kom ut i produktion.

Hur gör då en konsultfirma som BCG, som enligt mig står inför samma problematik mot kunder för att styra sina projekt och för att definiera resultatet med kunden? Enligt mina efterforskningar bland konsulterna tror jag inte man tänker så mycket på detta (kommentera gärna om jag har fel här). Det finns inga direkt standardiserade processer utan projektledaren som har mycket erfarenhet är den som styr varje individuellt projekt med sin magkänsla. Detta kan givetvis fungera om projektledaren gör rätt och är kompetent, men vad händer när konsultfirman växer sig så stor att det inte går att kontrollera hur varje individ är? Folk som inte vill arbeta kommer enligt mig alltid drabba företag, oavsett om de är konsulter med extrema intagningskrav. Här finns ett problem! Ett annat problem är att kunderna (VD:arna) ofta ger konsulterna extremt fria händer och är enligt min hypotes för dåliga på att ställa krav. Ofta vräker de bara ut några miljoner och ber konsultera jobba tills dessa är slut och därefter presentera lösningen. Men när vet man att lösningen är nådd? Är det alltid ett samband mellan resultat och pengar som investeras i projektet? Hur kan man egentligen räkna hem ett managementkonsultuppdrag? Enligt min mening är det svårt att veta vad som skulle hänt om inte lösningen presenterats och därmed ha något att jämföra med för att kunna säkerställa att investeringen är klokt gjord.

Paradoxerna är många men på något sätt går det bättre än någonsin för våra konsultfirmor. BCG anställer trots finanskrisen. Kanske är denna bara ytterligare bränsle. Frågan är bara när konsulternas finanskris kommer. När kommer beslutfattarna tänka själva och ställa rimliga krav?

Ytterligare en paradox är konsulternas informella rekryteringspolicy som handlar om att hitta personer mer problemlösningsförmåga. Detta kan som uttrycks bestå av kompositörer, ingenjörer, ekonomer eller läkare. Att ha en teoretisk bakgrund verkar inte vara den avgörande faktorn bara personligheten är tillräckligt ”konsultig”. Jag kan delvis hålla med om att detta mot bakgrund av mycket av det som lärs ut ändå glöms bort. Dock är det i grund och botten en mycket konstig rekryteringsstrategi om det finns någon som helst rationalitet i utbildningssystemet.

Den ständiga tvåan

Hur gick det då för mig med stipendiet? Som rubriken antyder gick det inte som jag hoppats och velat tro. Som vanligt föll jag på målsnöret och fick se två klasskompisar ta emot alla applåder. Ingen av dem var Sofia, vilket inte gjorde saken roligare.  Den omedelbara tanken var att säga hej då till konsulterna och åka hem. Jag hindrades dock av Sofia och min frågeställning kring managementkonsultens affärsidé, som vid den tidpunkten ännu inte besvarats.

Trots mina mycket goda betyg, arbetslivserfarenheter (på ABB, Ica och hos en Chalmersproffessor), engagemang i Intize, handledarerfarenhet och klassikerresultat (under 23 timmar) var jag ännu en gång tvåa. Jag har alltid varit tvåa när det gäller stipendier och faktiskt inte fått något av de jag sökt. För att bli mer attraktiv i framtiden är det inte betyg eller arbete jag skall förbättra i mitt CV. Rese-erfarenhet är mycket viktigt, vilket gör mitt utbytesår i Australien till en strategisk pärla.

För att avsluta detta inlägg finns vill jag påpeka att tvåan alltid lär sig något och blir än mer motiverad att fortsätta. Jag går starkare ur detta och gör förhoppningsvis bättre ifrån mig vid nästa prövning. Nu vet jag hur konsulter jobbar och är inte nervös för det! Framtidens konsultföretag kommer, om jag någon gång får bestämma, ha en ännu tydligare affärsmodell. Tack för mig.