Innovationer och förbättringar i produkter

På senare tid har jag arbetat en hel del med utveckling av produkter. Jag menar då inte att jag själv har arbetat hantverksmässigt med att ta fram dem utan snarare att jag ägnat mig åt kraven och processerna från det att idén kommit fram till dess att produkten är tillgänglig på marknaden.

Innan projekt kommer igång så brukar det vara en hel del funderande kring kraven, vad för sorts produkt som ska tas fram, hur mycket pengar som är rimligt att lägga på en viss funktion, mm. Det är också då som man kan komma att prata om innovationer. Innovationer är hett, och i allmänhet tror många att innovationer är något finare än förbättringar. De är liksom mer långtgående, revolutionerande, vackrare.

Själv menar jag att så inte behöver vara fallet. Innovationer som språkligt begrepp syftar naturligtvis oftast på helt nya idéer, men det är sällan intressant för företag att arbeta med helt nya idéer. Man vill vanligen hålla sig till ett område man förstår sig på. Av den anledningen kan det vara intressant att lägga samman förbättringsförslag och mer långtgående idéer i samma idékorg när man tar beslut om vilka idéer som ska förverkligas.

Man märker då oftast att idéer om produkten kan vara små förbättringar såväl som stora ändringar som leder till helt nya tillämpningar, dvs en ny produkt. Man märker också att minimala förändringar i produkten emellanåt ändå kan ge stora förändringar i tillämpning när man vänder sig till nya marknader. De här två perspektiven är viktiga när man bedömer en ny idé till produkt: var placerar den sig i förhållande till vår nuvarande produkt i vår interna värld - är den lätt eller svår att producera och förstå jämfört med dagens produkt? Och var placerar den nya produkten sig på den externa kundskalan, är det samma kunder som ska bearbetas med en ny produkt eller är det en ny marknad man ska ge sig på? Ju längre man rör sig ut på den interna och externa skalan desto mer handlar det om en äkta innovation i ordets sanna betydelse, men företagsekonomiskt ökar också risken högst betydligt när allt är okänd mark.

Att ta fram en innovativ produkt som helt avviker från den innevarande och dessutom vänder sig till en hel ny skara av kunder är i sanning innovativ för företaget men så riskabel att man knappt kan förstå hur den kommer att klara sig på marknaden. Det blir även internt ett mer komplicerat projekt och svårbedömt hur den helt nya produkten ska produceras. Det är lägre risk att välja ut idéer som  skapar nya produkter som åtminstone vänder sig till en delmarknad man redan förstår sig på. För att analysera hur man byggt upp sin produktutvecklingsportfölj kan det vara intressant att analysera risknivån och lägga 10-30% inom det som är högriskzonen (se bild lånad ur Harvard Business Review).

Man kan även vilja komplettera produkter med tjänster, mer om det här: Produkt- och tjänsteutvecklingsprojekt.

Projektledare och molntjänster

Det här med IT-trender är ett ämne jag återkommit till flera gånger. En stark trend som kommit förbi hype-stadiet och blivit en accepterad lösning är användande av molntjänster.

Det har sjunkit in hos de flesta att molntjänster är tjänster som erbjuds på distans och med god möjlighet att dynamiskt växla mellan lågt och högre nyttjande. Det här är den stora skillnaden jämfört med de äldre outsourcingfirmorna som hade tröskelvärden då deras kapacitet tog slut och man blev tvungen att betala för ny nyttjandenivå (varpå de gick ut i sin serverhall och anslöt en dator till, kan man anta). Äkta cloudleverantörer kan sprida användandet över flera maskiner och ser inte några tröskeleffekter, de fungerar alltså som ett stort hotell istället för ett fritidshusområde och delar dynamiskt ut nya rum istället för att uppföra nya stugor för varje nytillkommande kund (om liknelsen tillåts).

Det intressanta med molnlösningar tycker jag är att de kan göra så stor skillnad i IT-projekt. Jag vet inte hur många gånger jag som projektledare börjat mitt projekt med att räkna på kostnaderna för att upprätta utvecklings- och testmiljöerna. Investerar man i maskiner och mjukvara så blir det en stor kostnad för projektet även om man skriver av maskinparken under många år och nyttjar den för förvaltning. Speciellt dyrt blir det förstås om man av någon anledning kommer på att projektet bör ändra inriktning eller läggas ner, då står man i värsta fall där med en stor och tämligen värdelös investering på halsen.

Om man tänker molnlösning så sänker man risken i projektet radikalt, det blir billigare att växla upp till den kapacitet man behöver och likaså ner när man inte behöver kapaciteten mer.

Enligt min erfarenhet nyttjas molnlösningar med fördel för demo (innan man bestämt sig eller vid avstämningar), utveckling (medan lösningen tas fram), test (för att verifiera att den håller) och utbildning (för att lära upp nya användare). Med produktionsmiljön är det en annan sak. Inom exempelvis processindustrin där systemen ska fungera dygnet runt så är det inte accepterat att nyttja molntjänster för produktionens driftbehov, ändå kan man dra stor fördel av molnlevererade tjänster under utvecklingsprojektet för de ändamål jag nämner. Att man kan ha stor användning för molntjänster i miljöer där produktionen har extrema krav är något som inte alla tänkt på, det är t.o.m. så att man kan bli hånad om man vågar säga det, men nu har jag visst sagt det igen...

Produkt- & tjänsteutvecklingsprojekt

Vad är en tjänst? Vad är en produkt? Vad skiljer dem åt? Och varför behöver jag bry mig om det?

De bäst utvecklade resonemangen om skillnaden mellan produkter och tjänster har jag hittat hos Christian Grönroos. Han säger att produkter är slutresultat av en produktionsprocess, resultatet tas sedan över av kunden i sin helhet. Produkten blir kundens egendom. Tjänster däremot har inte ett slutresultat som konsumeras eller ett resultat som kunden kan ta med sig. Tjänster är istället en konsumtion av produktionsprocessen i sig. Det finns naturligtvis ett önskat slutresultat här också, men när vi talar rena tjänster så finns det ingenting som kunden fysiskt kan ta med sig. Förutom processen och slutresultatet så är även kundens upplevelse central när det gäller tjänster, dvs hur vi kommunicerar med kunden påverkar i hög grad hur kunden ser på vår tjänst.

Sammanfattningsvis; Tre saker utmärker alltså tjänster:

• Produktionsprocessen är tjänsten
• Specifika slutresultat önskas
• Kommunikationen kring upplevelsen är central

När man tittar på sammanfattningen så slås man av att det här faktiskt inte är helt likt produkter, men ändå ser vi idag hur produktföretag efter produktföretag vill in på tjänstemarknader de tycker sig förstå. Ericsson har redan gjort det, Volvo är på god väg, ABB har det som ett mål, mm. Tjänster är hett och det är ett uppenbart sätt att profilera sig eller hitta lönsamma nischer, mm.

Många vill alltså komplettera produkter med tjänster. Det är numera en glidande skala mellan tjänster och produkter, se figur A. Som exempel på en ren produkt återfinner vi SALT längst till höger, som exempel på ren tjänst finner vi undervisning längst till vänster. Som exempel på en produkt som kräver en större tjänsteinsats vid försäljningen har vi KÖPA NY BIL - kunder vill kunna grotta ner sig i tillval och färger, mm, varför en genomarbetad tjänst kring försäljningen är nödvändig. Som exempel på en tjänst med stort produktinnehåll har vi HYRA BIL. Men hur nära är det då egentligen mellan dessa två bil-alternativ? För den som i dagsläget producerar eller säljer nya bilar så kan det lätt se väldigt närliggande ut att istället hyra ut dem.

 Figur A: Tjänst eller produkt? En glidande skala.

I det här fallet, där det är lätt för oss som har erfarenhet av både att köpa ny bil och av att hyra bil, så är det ganska tydligt att det är stor skillnad mellan dessa två alternativ. Det blir mycket svårare att förstå sig på skillnaderna om produkten är mer obekant och det tjänsteerbjudande man tänkt sig är svåröverblickat till en början. Det är därför jag menar att det kan vara vettigt att fundera över de generella skillnaderna mellan produkter och tjänster - det blir helt enkelt lättare att lägga upp sitt tjänsteutvecklingsprojekt om man har ett gott grepp om hur det brukar se ut.

Att hyra ut bilar handlar inte alls om att låta kunderna ta ställning till samma frågor som vid ett bilköp. Oftast är exempelvis bilens färg eller t.o.m. märke ganska oviktiga medan storleksklass och tillgänglig period är viktiga. Medan den köpande kunden får med sig bilen hem så får den hyrande kunden visserligen med sig bilen under en period men när hyrestiden är över så är också bilen borta.

Som generell bild över hur tjänster levereras skulle man kunna rita upp en modell, se figur B. Centralt är förstås processen, i fallet med hyrbilar börjar vi med att informera potentiella hyrbilskunder om de tjänstealternativ som finns. Dessa paketeringar har inte så mycket med produkten att göra utan handlar mycket om att lösa schemaläggningen av resursen. Det här är utmärkande för tjänster - de utförs alltid någonstans och denna plats kan ha begränsningar, personalen kan vara en trång resurs, likaså verktygen för tjänstens utförande. I fallet med hyrbilar så är alltså inte bilen en produkt längre utan snarare ett verktyg för att leverera tjänsten framgångsrikt.

Ut mot kunden återfinns alltid ett antal kontaktpunkter, det är här i kommunikationszonen vi har vår möjlighet att presentera våra tjänster på ett professionellt sätt. Observera att det lika gärna kan vara mot flera kunder som en enda kund, vilket också är något som är utmärkande för tjänster. Vissa tjänster levereras helt enkelt till flera kunder på en gång (exempelvis undervisning) och det är inte ens otänkbart att låta kunden delta i produktionsprocessen. För att återgå till exemplet med hyrbilar så skulle t.ex. kunden kunna sköta bokningen av sin bil själv via en webbsida trots att det är just tjänsten "boka tillgängliga bilar" som är kärnverksamheten hos biluthyraren.

Figur B: Generell tjänsteleveransmodell

Eftersom de här frågorna är generella när man går från att vara en produktleverantör till att vara en tjänsteleverantör inom ett (synbarligen) närliggande område så kan man tjäna stort på att fundera igenom dem innan man startar upp ett tjänsteutvecklingsprojekt. Framtidens produkter lär kompletteras med mer tjänster, och vice versa, så att som projektledare studera det här området är viktigt om man vill ta tag i den här typen av utvecklingsprojekt.

Projektledare, hitta platsannonser

Jag blev tillfrågad om jag ville skriva ett gästblogginlägg på Careerbuilder.se, ett inlägg om hur man blir projektledare.

Moderbolaget Careerbuilder.com är den ledande aktören inom onlinerekrytering i USA och den svenska sidan Careerbuilder.se är också stor. Enligt KIA-index, som mäter trafik till svenska siter, så har Careerbuilder.se fler unika besökare än någon annan svensk site inom kategori "Arbete och rekrytering" med 126.555 unika webbläsare under förra veckan. De kategoriserar sina platsannonser så besök Careerbuilder och sök lediga jobb som projektledare!

Mitt inlägg på Careerbuilders karriärblogg har rubriken "Hur blir man projektledare?" och handlar om just precis hur man blir projektledare. Inlägget finns här.

Upphandling av projekt

Jag har reflekterat lite kring hur man upphandlar IT-projekt och mina erfarenheter kring hur bedömning av leverantörer görs. Det är en rätt vanlig del i uppstarten av vissa projekt.

Om det inkomna anbudet är bland dem man väljer att bedöma så handlar det enligt min erfarenhet ofta om att värdera pris, hur lösningen som helhet ser ut, tidigare erfarenhet av leverantören samt villkoren. De fyra parametrarna är alltid viktiga! Vill ni läsa vidare om detta så kan ni titta på mitt inlägg på Projectplace's blogg eller nedan:

Upphandling av IT-projekt

Under uppstart av projekt har jag som projektledare flera gånger varit med om att upphandla utrustning, tjänster eller hela delprojekt. I de här upphandlingslägena har jag letat på internet efter stöd i upphandlingssituationer, men vanligen landar man då i artiklar som är väldigt inriktade på offentlig sektor och offentliga upphandlingar. Se exempelvis IDG som har en hel site kallad upphandling24.idg.se Man kan lätt drabbas av starka känslor av tristess när man klickar på en sån länk.

Inom näringslivet så är inte upphandlingar lika strikta. Man kan exempelvis välja en leverantör enbart på grund av tidigare goda erfarenheter av deras prestation. Då bekymrar man sig inte så mycket om exempelvis pris eller övriga villkor som kunde skilja sig mellan leverantörer. När man kommer till större inköp eller hela delprojekt så kan det ändå vara en god idé att genomföra en mer formell upphandling.

I större internationella koncerner slänger man sig då med ett antal begrepp som kan vara bra att känna till: RFI, RFP, RFQ är några vanliga förkortningar.

RFI, Request for information: Det här är när man går ut med en rätt allmän förfrågan för att ta reda på vilka leverantörer som kan tänkas vara intressanta att få anbud ifrån. I samband med förfrågan så kan man passa på att avkräva leverantören ett påskrivet sekretessavtal för att få ta del av underlaget för den upphandling som komma skall. Man behöver inte fundera så länge innan man förstår varför det kan vara vettigt med sekretess – underlaget för större upphandlingar är inte något man är särskilt bekväm med att konkurrenter tar del av.

RFP, Request for proposal: Det här är en anbudsförfrågan med en detaljerad beskrivning av det behov som föreligger, men inte helt uppstyrd vad gäller de lösningar man förväntar sig. Fördelen med att inte beskriva i detalj hur lösningen ska se ut är att olika leverantörer kan dra nytta av olika erfarenheter och standardlösningar de har i sin portfölj när de svarar. Nackdelen är förstås den samma: olika leverantörer svarar på olika sätt och bedömningen av vilken lösning som är bättre eller ens likvärdig blir svår.

RFQ, Request for quote: Det här är en förfrågan där man beskriver sin situation och vilken lösning man vill ha. Det enda man ber leverantören om är pris och övriga villkor (men även villkoren brukar man försöka styra).

Jag har inom IT-området faktiskt inte stött på formella upphandlingsprocesser där man gått ut med en ren prisförfrågan, dvs en RFQ. Det har oftast handlat om RFI eller RFP. Men hur gör man för att bedöma skilda anbud? Det är inte helt lätt.

Jag tycker att man bör ha en grupp som gör bedömningen, en grupp sammansatt av olika parter. Det kan vara framtida slutanvändare, sponsor, teknisk expert, projektledare, mm. Viktigt är att den inte är alltför ensidigt sammansatt.

Jag skulle nog säga att alla gånger jag deltagit i sådana bedömningar så har vi först gjort en grov bedömning av svaret som inkommit jämfört med den förfrågan som skickades ut. Vissa svar är standardsvar som avviker så mycket från förfrågan att man kan sortera bort dem som irrelevanta.

Sedan görs bedömningen, en punkt som alltid bedöms är pris. Pris per timma, produkt eller pris per projektsteg. Ibland blir det riktigt svårt, t.ex. när en leverantör kräver licenser på en tidigare utvecklad lösning, har väldigt stor skillnad på timtaxa för olika roller (svensk projektledare, indisk utvecklare), bara kan garantera fast pris för en viss delleverans, osv.

En annan sak som alltid bedöms är lösningen. Om man inte alls tror på en föreslagen lösning så måste den väljas bort, den kan t.ex. gå på tvärs med en teknisk arkitektur man försökt etablera.

Tidigare erfarenhet av en leverantör bör absolut vägas in, den som gång på gång levererat på ett framgångsrikt sätt bör ha pluspoäng. I offentliga upphandlingar kan man kanske inte göra så, det är åtminstone inte något som brukar stå i underlaget över hur bedömningar görs. Däremot kan man förstås fundera på om det finns med i bedömningen ändå, för framgångsrika leverantörer brukar få förnyat förtroende.

Slutligen bör avtalsvillkor bedömas. Ofta är det en förhandlingsfråga, men med vissa stora leverantörer så har man inte så stor möjlighet att påverka deras avtalsvillkor. Troligen bör man då koncentrera sig på att ändra de villkor man inte kan gå med på, exempelvis att skriva om klausulen om att eventuella framtida tvister ska lösas i Kalifornisk domstol. Det här får man överlåta till en professionell inköpare eller avtalsexpert.

När alla i urvalsgruppen sagt sitt så brukar en slutförhandlare ta över och få avtalet klart.

Personligen tror jag man tjänar mest på att få till en win-win förhandling med sin leverantör. Att ta in en avtalsförhandlare som med diverse oväntade textfinter och avtalsabrovinker lyckas uppnå ett tydligt övertag eller en prisnivå som är svår för leverantören att leva med kan leda till friktion under hela projektet.

”Det räcker inte med att lyckas. Andra måste misslyckas.”
- Gore Vidal

Det finns för övrigt ett tänkvärt citat från Gore Vidal som sammanfattar hur avtalsupplägget inte bör konstrueras, jag infogade det här ovanför.

Projektledning med indiska resurser

Mitt inlägg på Projectplace's projektblogg publicerades tidigare idag. Inlägget handlar om mina erfarenheter av att arbeta på distans med projektdeltagare i Indien. Eftersom jag nu haft indiska projektmedlemmar eller hela delprojekt i Indien vid flera tillfällen de senaste åren så uppfattar jag detta som något av en trend som kan vara intressant att skriva om.

Projektledning med utlandsresurser

INDIEN

Jag befinner mig just nu i ett projekt som huvudprojektledare inom mjukvaruutveckling och precis som i mitt förra  projekt ligger de flesta delprojekten i Indien medan jag själv nästan alltid är i Sverige. Det här ger en del intressanta utmaningar som jag personligen tror väldigt många kommer att stöta på i framtiden. Precis som vi sett att tillverkning av prylar flyttat till länder med lägre löneläge så kan många tjänster komma att flytta, men kanske inte nödvändigtvis till samma ställe som tillverkningen. Någon har sagt att Kina är världens fabrik och Indien världens kontor. Något ligger det absolut i det.

Vissa tror att man flyttar enkla tjänster till Indien eftersom det är enkla tjänster som utförs med lätthet av dessa billiga resurser. Jag skulle vilja påstå att det är en fördom. Det finns oerhört duktiga personer som arbetar i Indien! Att det i första vågen huvudsakligen lades ut enklare tjänster till Indien handlar mest om att dessa tjänster är lättast att utföra på distans och att kunderna har accepterat att enklare tjänster utförs på det här sättet.

Nu har marknaden mognat ytterligare och alla typer av tjänster utförs på avstånd. Så fort man accepterat att alla resurser inte nödvändigtvis måste komma inpendlande för att slå sig ner i ett stort rum i Borlänge eller Kista så har man öppnat dörren hela vägen ut mot ett gigantiskt rum i Bangalore.

UTMANINGEN MED AVSTÅND

Att arbeta på distans är ingenting nytt, att ha utvecklarteamet på annan plats än beställaren är förhållandevis vanligt. Jag har tidigare varit med om allt från att utvecklarna suttit längre ner i samma korridor, på annan våning, i närliggande stad eller på andra sidan Östersjön. Gemensamt för de här varianterna har varit att det varit möjligt att låta utvecklarna besöka beställarsidan vid behov. Egentligen har det varit så enkelt att det gått att boka in från ena dagen till den andra när behov uppstått. Så är det inte med indiska resurser, det här är en av de större skillnaderna. Indier behöver arbetstillstånd och visum för att få komma till Sverige i tjänsten, resan tar dessutom motsvarande två arbetsdagar.

Även tidszonsförskjutningen är en utmaning, men vi i Europa har hela förmiddagen gemensam med Indiens eftermiddag så det är inget stort problem som det nog är för exempelvis amerikanska bolag som arbetar med Indien. Tar man för vana att lägga sina avstämningsmöten under förmiddagen så fungerar det som regel bra. Ska man verkligen jobba tillsammans så är det dessutom en god idé att ha väldigt tät kontakt med så god bandbredd som möjligt, dvs att bara släppa ifrån sig några välskrivna instruktioner per e-post med jämna mellanrum duger inte. Räkna istället med att ha så tät kommunikation per chat, telefon eller videomöte så att det till slut upplevs som om du arbetar på plats i Indien. När du själv börjar tänka ”one lakh” när du ser siffran ”100000” så är du på god väg!

Jag tror det var min bloggarkollega här på Projectplace (M. Bouzeid) som skrev något om hur man upplever svenskar efter att ha jobbat utomlands ett tag, och jag upplever det nu plötsligt på samma sätt: svenskar säger väldigt sällan ja till att jobba. Det är en lite märklig arbetskultur på vissa håll i Sverige som blir uppenbar när man jobbat med andra och sedan plötsligt ska prata med svenska resurser igen. Få tar glatt emot ett uppdrag, de flesta skruvar på sig och försöker bli av med uppgiften, alla rabblar upp svårigheter. Varför är det så här? Inte vet jag, det spelar inte så stor roll när man väl insett att skillnaden finns där, och att få höra om komplexiteten i en uppgift ”up front” från första början är naturligtvis bättre än att förtiga problem. Med de indiska resurserna kan man få gräva lite innan de berättar om vilka svårigheter som kan finnas, men nog är det trevligt med folk som säger ”ja” när man ber dem göra något?

SLUTORD

Jag får troligtvis anledning att återkomma till utmaningarna med att projektleda på distans eftersom det verkar ha blivit ett vanligt förekommande fenomen i mitt eget projektledarliv.

Projektstyrning, erfarenhet av olika modeller

När jag först började med projektledning och sökte runt på nätet så fick jag intrycket att PMI (Project Management Institute) och deras projektledningsmodell var den vanligaste och därmed intressantaste modellen att sätta sig in i.

Modellen är en typisk projektstyrningsmodell, dvs den går inte ner på själva praktiska projektarbetsnivån i någon större utsträckning och kan därför användas i de allra flesta projekt oberoende av bransch.

PMIs modell är även upptagen som ANSI standard, dvs amerikansk standard. Över huvud taget tycks modellen vara klart vanligare i USA än på andra håll i världen. Att hitta mer information om modellen på nätet är lätt och deras Project Management Body of Excellence (PMBOK) bok är rätt vanligt förekommande på projektledningskontor även här i landet.

I Europa är dock IPMA en vanligare projektledningsmodell, i Sverige är det Svenskt Projektforum som tillhandahåller modellen. De certifierar också med ensamrätt i Sverige projektledare enligt IPMA. Det är svårt att hitta allmänt tillgänglig information om exakt vad modellen innebär, det här med ensamrätt och exklusivitet tycks utmärkande för modellen. Det finns exempelvis ingen sida på svenska wikipedia som förklarar IPMAs modell.

En tredje internationellt förekommande projektmodell är PRINCE som verkar komma starkt tack vare att systermodellen ITIL (för förvaltning) blivit så populär. Jag har hört många tala om den men inte stött på den praktiskt i Sverige.

Så långt de modeller som är internationellt gångbara modeller för styrning av projekt där man som projektledare även kan låta certifiera sig. När jag nu arbetat många år som projektledare så kan jag konstatera att de här modellerna inte är speciellt vanligt förekommande i Sverige. Visst finns de med i konsulters meritförteckningar, men de två i särklass vanligaste modellerna för projektledarskap i Sverige är PPS (Praktisk Projektstyrning från Tieto) och PROPS (Ursprungligen Projektet för Projektstyrning på Ericsson). Jag skulle säga att de här modellerna t.o.m. är ännu vanligare än man kan tro vid en första anblick för många svenska företagsspecifika modeller visar sig vid en mer ingående granskning grunda sig på PPS eller PROPS men med smärre anpassningar.

Vad sägs exempelvis om den här översikten över PPS, kanske påminner den om den modell som tillämpas på din arbetsplats?



Avslutningsvis tänkte jag nämna RUP (Rational Unified Process) och Scrum som inte är projektstyrningsmodeller på samma sätt som de modeller jag beskrivit här. RUP och Scrum kallas emellanåt för ”produktionsmodeller”, anledningen är att de inte kan användas generellt för alla typer av projekt utan tagits fram för arbete i IT-projekt specifikt. De är alltså inte inriktade på styrprocessen i projekt och hur kommunikation ska ske med t.ex. styrgruppen utan snarare på systemutvecklingsmetoder. RUP pratar om användarfall t.ex. och Scrum talar om hur kodutvecklarna ska kommunicera. De här modellerna används oftast parallellt med en projektstyrningsmodell (exempelvis en av dem jag räknat upp ovan). De kan inte användas för projekt utanför IT; jag kan inte tänka mig ett vägbygge projektledas enligt RUP. Vanligt förekommande är de däremot, Scrum (och andra agile/lean modeller) som en mer stigande stjärna och RUP som den brett etablerade herren på täppan.