Kategorier
Förändringsarbete Strategier för projekt

Olika utvecklingsstrategier

Att välja strategi för hur en produkt eller tjänst ska utvecklas är en viktig fråga att ta ställning till vid planering av alla projekt. I det här inlägget beskriver vi tre olika strategier.


Att utveckla en tjänst eller en produkt kan såklart göras på flera olika sätt. Det finns flera faktorer som styr valet av utvecklingsstrategi, t ex verksamhetens korta och långsiktiga behov, organisationens kunskap om det aktuella området, olika typer av risker och marknadskännedom. Helt klart är det ofta väl investerad tid att börja med att noga analysera utvecklingsstrategi och att förankra den hos olika intressenter.

Ibland kan det vara mest effektivt att börja med att specificera allt som ska utföras i detalj.

I vissa fall kan det vara motiverat att leverera en initial lösning där verksamheten kortsiktigt kan dra nytta av effekterna, och sedan börja om med den långsiktiga lösningen.

Ofta är det önskvärt, om det är möjligt, att successivt bygga vidare på en lösning.

Låt oss titta lite närmare på tre olika utvecklingsstrategier och några exempel på vilka olika för- och nackdelar de kan ha.


Sekventiell utveckling

Vid sekventiell utveckling, även kallad vattenfallsprincipen, är det inte ovanligt att arbetet med behov och krav slås samman och görs vid ett och samma tillfälle i ett projekts tidiga faser. Fokus är då normalt på krav, där verksamheten beskriver och fastställer lösningens olika delar i detalj. Specifikationer lämnas sedan över till utvecklings- och produktionsenheter som tar fram lösningar baserade på kravdokumentationen. När hela lösningen är helt färdigutvecklad lämnas resultatet över till verksamheten, som då kan nyttja resultatet med full funktionalitet.

Fördelar

  • Tydlig uppdelning mellan kravarbete och utveckling
  • Kan förenkla avtal vid upphandling där externa leverantörer används
  • Kan underlätta arbete med att tänka igenom hela livscykeln för en produkt och tjänst redan från början

Nackdelar

  • Svårt att identifiera alla behov och krav i ett tidigt skede
  • Svårt att tids- och kostnadsuppskatta alla delar innan utveckling startat
  • Förändrade behov och ändringar kan bli svåra och kostsamma att genomföra

Exempel

Ett nytt intranät skulle införas i en organisation. I projektets tidiga skede arbetade verksamheten och IT tillsammans fram en detaljerad kravspecifikation för alla funktioner och sammanställde sedan ett förfrågningsunderlag. Det bestämdes från början att intranätet skulle bestå av 10 olika moduler. Underlaget skickades till några utvalda leverantörer. En leverantör valdes, som sedan utvecklade och installerade systemet. Det nya intranätet tillgängliggjordes för alla användare med full funktionalitet för alla 10 moduler vid ett och samma tillfälle. Projektet tog 12 månader att genomföra.


Agil utveckling utan återanvändbarhet

Det kan finnas situationer där en lösning snabbt behöver tas fram för att kunna tillmötesgå verksamhetens behov. Fokus kan då vara att så tidigt som möjligt leverera nytta, utan hänsyn till att lösningen ska kunna återanvändas och användas som utgångspunkt att bygga vidare på i kommande utveckling. Produktens eller tjänstens hela livscykel är därmed underordnad och ingen eller lite tid läggs på att analysera detaljerade krav för framtida utveckling.

Fördelar

  • Fokus kan läggas på att ta fram en lösning för det som verksamheten bedömer som bråttom och viktigt
  • Utveckling kan gå snabbare om ingen hänsyn behöver tas till produktens eller tjänstens hela livscykel
  • Genom mindre utvecklingssteg skapas ett bra underlag för att bedöma kommande behov, krav och lösningar

Nackdelar

  • Kan vara kostsamt att inte kunna återanvända resultatet av lösningen
  • Risk att lösningar inte blir tillräckligt bra och genomtänkta för att kunna leverera önskad nytta
  • Att inte tänka på produktens eller tjänstens hela livscykel från början kan bli kostsamt i slutändan

Exempel

Ett nytt intranät skulle införas i en organisation. Verksamheten hade bråttom med att kunna nyttja en modul där personalen skulle kunna tidrapportera sin arbetstid då det tidigare tidrapporteringsverktyget hade slutat att fungera. Leverantörer för intranät kontaktades. Det visade sig att den typen av funktionalitet bl a krävde att en databas med personalinformation först installerades. Verksamheten fattade då beslut om att införskaffa en temporär lösning för tidrapportering genom att hyra in sig i en molntjänst, i väntan på att en modul för tidrapportering var på plats i det nya intranätet. Tid för att komma igång med molntjänsten var ca 1 månad. Arbetet med att införa den långsiktiga lösningen påbörjades strax efter att molntjänsten startades upp. Projektet tog 13 månader att genomföra.


Agil utveckling med återanvändbarhet

Kännetecken för agil utveckling är att dela in utveckling i kortare etapper, där verksamheten frekvent får leveranser i mer begränsad omfattning. I varje etapp eftersträvas att kunna leverera maximal nytta utifrån den utvecklingskapacitet som finns, samtidigt som livscykelperspektivet beaktas för att kunna bygga vidare på tidigare lösningar. Fokus är att successivt förbättra och utöka lösningen så att den blir mer heltäckande. Efter varje etapp ska det normalt finnas en bättre eller utökad lösning som verksamheten kan nyttja.

Fördelar

  • Utveckling beaktar både kort- och långsiktiga behov
  • Mindre omfattande utvecklingssteg kan minska risker för felinvesteringar genom att resultatet successivt används och utvärderas
  • Skapar en flexibel utveckling som underlättar anpassning till verksamhetens föränderliga behov

Nackdelar

  • Risk att snabba leveranser inte blir tillräckligt bra och det kan upplevas svårt att få korrigeringar utförda pga att nya krav och önskemål prioriteras högre
  • Antalet ohanterade frågor kan tendera att växa eftersom inställningen kan vara att de kan hanteras i ett senare skede
  • Risk att dokumentation prioriteras ned, vilket t ex kan öka personberoenden

Exempel

Ett nytt intranät skulle införas i en organisation. Verksamheten inledde ett arbete med att beskriva sina behov av olika moduler och önskad funktionalitet. En prioritering gjordes för att tydliggöra vad som var mest bråttom och viktigt. Därefter diskuterades hur projektet skulle genomföras med IT. Man kom överens om att två moduler hade högst prioritet: en modul med en databas med personalinformation och en modul för tidrapportering. Olika leverantörer kontaktades, och den utvalda leverantören fick i uppdrag att utveckla och installera de två mest prioriterade modulerna. Efter 2 månader var modulerna på plats och kunde börja användas av verksamheten. Därefter beskrevs och detaljerades övriga moduler. Man räknade med att kunna installera och tillgängliggöra en ny modul per månad. Från början bedömde verksamheten att 10 moduler skulle behövas, men det visade sig i slutändan att 8 moduler var tillräckligt. Projektet tog 10 månader att genomföra.

Kategorier
Strategier för projekt

Definiera begreppen och undvik dyra missförstånd

Verksamheter, samarbeten och projekt styrs av kommunikation med hjälp av språket. Det är oftast av avgörande betydelse för resultatet att information förstås och tolkas på samma sätt av alla berörda. Missförstånd på grund av oklarheter kan leda till kostsamma misstag, inte minst inom projektarbete.

Exempel på oklarheter i en organisation kan vara

Vem skall anses vara kund – den som betalar produkten eller den som använder den? Eller finns det en annan definition?

Kund?

Vilket samband råder mellan begreppen leverans, sändning, mottagning, artikel, ankomstkontroll, returorder, reklamationsorder och order?

Samband?

Ingår installation av systemet och vad avses egentligen med installation?

Vad avses?
Även oklarheter i själva processen, t ex projektprocessen, kan vara en källa till missförstånd

När anses projektet vara startat – när beställningen är gjord, när förstudien är påbörjad eller när styrgruppen godkänt projektplanen?

Vad avses med projektets mål – de som projektet ska leverera eller de effekter som förväntas uppnås när projektet har levererat, dvs effektmålen?

Vad menas med två veckors utvecklingstid – 14 kalenderdagar eller 10 arbetsdagar?

Vad innebär begreppsanalys och terminologiarbete?

Begreppsanalys och terminologiarbete innebär att organisationen enas om innebörden i viktiga ord och begrepp.

Begrepp kan t ex avse produkter, dokument, processer, händelser, aktörer och regler. I det enklaste fallet skapar men bara en ordlista/termkatalog/begreppslista som fastställer vilka ord som ska användas t ex kund, leveransadress, fakturaadress, artikeltyp.

Ordlistan kan förses med förklaringar/definitioner och blir då mer informativ, t ex med patient avses den som tidigare behandlats på vårdcentralen.

Man kan också beskriva begreppen på ett djupare sätt, relatera dem till varandra och precisera vad som skiljer och förenar närliggande begrepp t ex order, normalorder, prioriterad order, snabborder, returorder, ersättningsorder, kompletteringsorder, reklamationsorder och gratisorder.

Vanliga problem vid kommunikation med språket och ord

Man brukar skilja mellan syntaktiska och semantiska oklarheter i språket. Syntaktiska oklarheter har med meningens konstruktion att göra, exempelvis alla våra internationella produkter och tillbehör. Avses alla tillbehör eller endast de internationella? Semantiska oklarheter har med ordens betydelse att göra. Det finns många olika typer av semantiska problem, exempelvis att ett ord kan betyda olika saker (jfr ordet fil) eller att det finns fler ord för samma sak (kundnummer och kundID).

Ytterligare ett problem är när ord är vaga och kan uppfattas på olika sätt, exempelvis ordet moral. Det är ett välkänt faktum att vårt språk i sig ofta är oprecist. Vi förstår normalt varandra ändå, eftersom vi ofta känner de vi kommunicerar med och vet hur de tänker och hur de uppfattar begrepp. Det blir svårare då man kommunicerar med människor man aldrig arbetat med tidigare, vilket ofta är vanligt i projektsammanhang.

Men oftast förstår vi ju varandra – så vad är problemet?

Det är ett välkänt faktum att vårt språk ofta är oprecist, men att vi förstår varandra ändå, eftersom vi normalt känner de vi kommunicerar med och vet hur de tänker och uppfattar ord och begrepp; ”alla vet” vad det talas om. Men det finns två situationer då denna tysta kunskap kan sättas på prov i ett projekt. Den ena är då projektet involverar eller kommunicerar med personer utanför organisationen vilket inte är ovanligt. Den andra är om det uppstår behov av djupare analyser och hantering av detaljerade krav, eftersom man då oftast måste hantera snarlika begrepp och relationer dem emellan.

Begreppsmodeller – olika typer av samband mellan begrepp

Ibland kan begreppen i en verksamhet vara välkända, entydiga och väldefinierade. Detta är tyvärr dock inte alltid fallet. Ett hjälpmedel i analysarbetet i kniviga fall är att arbeta med grafiska begreppsmodeller enligt ovan nämnda standards för att fånga begreppen och deras relationer. Därefter definierar man begreppen och för in dem i ordlistan/begreppskatalogen/termdatabasen.

I följande figur visas ett enkelt exempel som beskriver fem begrepp och hur de hänger samman. Patient och läkare är båda en person (pilspetsen betyder generalisering/specialisering). Varje person har fler kroppsdelar (asterisk betyder fler). En patient kan göra fler läkarbesök. Vid ett läkarbesök behandlas endast en kroppsdel av en läkare, men en kroppsdel kan ha behandlats vid flera läkarbesök. Den grafiska modellen kan ytterligare detaljeras med andra typer av symboler och samband.

Begrepps- och termdatabaser och olika typer av datorstöd

IT-stöd för begreppsmodeller finns att köpa, exempelvis UML-stöd. IT-stöd för termkataloger är det dock inte så gott om. Det verkar som de flesta företag som har datoriserade termkataloger har utvecklat egna enkla IT-stöd, exempelvis i Microsoft® Access. En termkatalog kan i enklaste fallet bara vara en ordlista och i det mer avancerade fallet vara kompletterad med fullständiga definitioner av begreppen och relationerna dem emellan.

Följande exempel på frågor kan vara intressanta att ställa mot en begreppsdatabas
  • Är begreppet vägkorsning en generalisering eller precisering av något annat begrepp?
  • Har begreppet godkänd samband med något annat begrepp?
  • Vilka begrepp ansvarar Karlsson för?
  • Vilka begrepp finns inom området akutsjukvård?
  • Vad heter offert på ryska?
  • Vilka synonymer finns till begreppet försening?
Lite filosofi-light om språk och semantik

Begreppsanalys och terminologiarbete handlar om språket, dess begrepp och hur dessa definieras. Semantik är läran om språket och dess effekter och kopplingen till verkligheten. Nedan ges en kort inblick i ämnet, huvudsakligen baserat på en klassiker inom ämnet, boken Empirisk semantik av norrmannen Arne Naess », (Almqvist & Wiksell).

Enligt Naess görs påståenden med hjälp av språket, exempelvis jorden är platt, vilket uttrycks med just denna sats eller med någon av satserna the Earth is flat eller jordklotet har en plan yta. Ett annat exempel på två satser som innehåller samma påstående är Lars är längre än Lisa och Lisa är kortare än Lars. Det omvända kan också förekomma. Satsen det är grönt kan tolkas på två sätt: vi har fått klartecken eller färgen är grön. Värt att notera är att ett påstående inte behöver vara sant. Kommunikation tolkas alltid av en mottagare. Tolkningen är ofta avhängig av vem som tolkar och i vilken situation det är. Bilen är dyr betyder säkert olika då den tolkas av en inköpsavdelningen på ett företag eller av en gymnasist som sommarjobbat ihop till sin första begagnade bil. Per är snabb betyder en sak då han bedöms som systemutvecklare och något annat då han ställer upp i ett hundrameterslopp.

Ett annat intressant begrepp är Intentionsdjup. Då en läkare säger att hjärtat verkar slår normalt så har läkaren säkerligen en djupare motivering än då en lekman yttrar detsamma. En definition av ett begrepp kan beskrivas olika djupt. Ökat djup ger en bättre precision men gör det ofta mer svårförståeligt och därmed mindre användbart. Det gäller att ha ett rimligt och ändamålsenligt djup i definitionerna.

Definitioner är ett stort ämne. Det kanske viktigaste är att definitionen träffar rätt, dvs att den inte är för trång eller för vid. Om vi exempelvis som definition av begreppet bil anger motordrivet landfordon så är den för vid, eftersom t ex en motorcykel även då  kan uppfattas som en bil. Om vi istället anger motordrivet landfordon med fyra hjul så är den för trång eftersom det finns bilar med exempelvis tre eller sex hjul. Definitioner kan också vara fel på andra sätt. Ett vanligt fel är cirkeldefinitioner, t ex Lön = Lön för ordinarie arbetstid plus övertid.

Slutsats

Kommunikation med språket är ett svårt ämne. Missförstånd kan förorsaka olika typer av fel inom en verksamhet eller projekt och ofta kan konsekvenserna av missförstånd bli dyra.

I projektvärlden finns normalt massor av begrepp och definitioner. I de inledande faserna av ett projekt kan missförstånd och olika tolkningar leda till att fel projekt startas, att beställaren och projektledarens uppfattning om vad som ska levereras skiljer sig markant, att egenskaper hos en produkt inte motsvarar kraven etc.

Vi hoppas att det här blogginlägget har belyst vikten av att tillämpa begreppsanalys i tillräcklig utsträckning för att skapa klarhet och tydlighet  i kommunikationen och därmed minimera risker. Hur mycket tid och kraft som t ex ett projekt ska ägna åt detta varierar naturligtvis, men det är ofta väl investerad tid att fundera igenom en miniminivå för hur begrepp och definitioner ska hanteras i verksamheten och för det enskilda projektet.

Vad är dina erfarenheter av vikten att vara överens om begrepp och definitioner?

Kategorier
Strategier för projekt

Vision inom agila projekt

Inom agil utveckling används ofta begreppet vision. En vision kan sägas vara startpunkten, motivet och de mål som ska vara uppnådda när ett projekt är klart och resultatet ifrån projektet levererar full nytta.

Men vänta nu, är det inte det här som brukar benämnas effektmål i projekt? Båda ja och nej. Projektets vision kan, enligt ProjektStegen ska tilläggas, sägas vara en övergripande och bred beskrivning av nuläge, behov, lösningsidéer uttryckta på verksamhetsnivå samt vilka behov som ska tillgodoses och vem som har behoven.

Effektmålen kvantifierar de effekter verksamheten ska uppnå genom att använda projektets leveranser. Effektmålen ska vara konkreta, kunna mätas och varje önskat effektmål ska ha ett målvärde som följs upp och utvärderas. Effektmålen tillsammans ska stämma överens med visionen.

Kort & kärnfull

En vision ska vara kortfattad och kärnfull, samtidigt ska den vara enkelt utformad så att alla involverade verkligen förstår motivet och det förväntade resultatet vid genomförande av projektet.

Det finns olika sätt att beskriva en vision. Ibland kopplas begreppet hissbudskap (engelskans elevator pitch) ihop med hur en vision ska uttryckas. Med det menas att visionen ska kunna förklara projektet på en kort tidsperiod, t ex en minuts hissfärd. Utgångspunkten är att den som får visionen presenterad för sig får svar på frågorna varför? till vem? hur? fördelar?

Titta på en kort film som visar fem delar och dimensioner som en vision kan innehålla:

Ert projekt , er vision

Vi har sparat det bästa till sist, nämligen att det inte finns någon standard eller enhetligt sätt att beskriva en vision. Det kan sägas vara i linje med agil utveckling i allmänhet, dvs att det kan finnas riktlinjer för hur den här delen av projektet kan göras, men det är upp till varje projekt att välja hur riktlinjerna ska användas på ett sätt som passar det enskilda projektet. Ofta nämns principen att visionen ska vara positiv, visionär och innehålla utmanande mål och förväntningar. Vi ställer oss bakom den principen på ProjektStegen, men vill samtidigt understryka att orealistiska mål kan medföra ökade risker för besvikelser och negativ stress.

Behoven i fokus

Annat värt att tänka på vid utformning av en vision är att det är behoven som ska vara i fokus, inte funktioner och krav. En vision kan innehålla idéer om lösningar, men då ska de vara på en övergripande nivå utan detaljer. Visionen är ett dokument som verksamheten utformar.

Har du tips, idéer eller tankar om hur en vision kan utformas? Håller du med om vår beskrivning av en vision eller har du andra erfarenheter av hur visionen kan utformas för att utgöra en bra start på ett projekt? Kommenterar gärna!

Kategorier
Strategier för projekt

Vad kan Formel 1 lära oss om agilt?

I helgen är det premiär för säsongen 2021 av Formel 1, eller F1 som den invigde kallar sporten. Premiären sker i mellanöstern, närmare bestämt i Bahrain. Nyligen släpptes också Netflix tredje säsong av serien Formula 1 – Drive to survive.

För den oinvigde i sporten kommer här en kort sammanfattning: Formel 1 är den högsta serien inom banracing, med futuristiska bilar, det senaste inom högteknologi, galet mycket pengar, stora risker, hängivna team och supporters. Lägg därtill att varje Formel 1 team har ungefär mellan 300 och 1 000 anställda, som under en säsong ska planera och organisera 21 tävlingar i lika många länder.

Oavsett vad man tycker om sporten i sig är Formel 1 en fascinerande industri, som i minsta detalj kräver precision i organisation och utveckling. Och eftersom vi dagligen tänker och verkar inom agila projekt är det svårt att inte dra paralleller mellan agilt och F1. Här kommer sex reflektioner kring F1 och agilt. Häng med, nu kööör vi!

Teamet & individen

Inom agilt pratas det mycket om självstyrande individer och självorganiserande team. På mer enkel svenska kan det sammanfattas med att varje person i ett team behöver hitta sin motivation, sina drivkrafter och på ett ansvarsfullt sätt bidra till teamets resultat. Teamet behöver inte det traditionella och styrande ledarskapet, istället eftersträvas team som tar gemensamt ansvar för att organisera sig på bästa sätt för att hela tiden förbättra sig.

Ett F1 team har flera hundra anställda, som är organiserade i olika mindre team. Varje team har en tydlig uppgift. Längst fram finns såklart förarna. Men man är noga med att hela tiden lyfta teamet. Medvetenheten om att det är teamet som helhet som är avgörande är påtaglig i F1. Det kan kanske bäst beskrivas genom ett depåstopp – ett snabbt däckbyte (världsrekordet är just nu 1.82 sekunder!) kan betyda seger, medan ett felbeslut av en enda individ i teamet kan betyda avbrutet lopp och miljoner i kostnader eller uteblivna intäkter.

Feed forward kultur

Att ge feedback på det arbete som utförts uppmuntras ofta i projekt. Dvs att återkoppla upplevelser och konsekvenser av individers och teams utförda prestationer.

Mer modernt är att använda sig av feed forward, dvs att ha ett framåtriktat fokus på hur nya kunskaper och lärdomar tas tillvara för vägen framåt. Det här märks tydligt inom F1. Synsättet verkar vara att det finns 19 förlorare och en endast en vinnare per lopp. Det här gör att varje lopp skapar ett bra underlag för kommande förbättringar baserat på felaktiga förarbeslut, team som inte är helt i synk och användning av fel material. Detta skulle såklart kunna vara föremål för kritik, utpekande av syndabockar och utkrävande av ansvar.

Teamen försöker undvika att låta det icke perfekta skapa negativ energi och för mycket tillbakablickar. Istället omvandlas frustrationen till beslutsamhet och optimism för kommande lopp. Det ska tilläggas att det säkert i stundens hetta nog finns inslag även i F1 av den traditionella och mer icke konstruktiva feedback kulturen, t ex när en tekniker sätter på fel däck vid ett depåstopp….

Utmanande mål

I agil utveckling är vision ledordet som ska vägleda projektet framåt. Inte sällan sägs att visionen ska vara utmanande och på gränsen till ouppnåbar. Samtidigt ska den fungera som vägledning och drivkraft för teamet. Mot visionen, ingenting kan eller får stoppa oss!

Det måste vara få andra sporter, företag och organisationer som kan mäta sig med F1 avseende det aktiva arbetet med mål. Allting mäts. Allting har ett tydligt målvärde och utvärderas i minsta del. Lägg sedan till att målen minst sagt är visionära och utmanande. Det finns nämligen bara ett mål för alla F1 team och det är enkelt att förstå – förstaplatsen! Allting förutom förstaplatsen är initialt att betrakta som antingen ett fiasko eller misslyckande. Men ganska snabbt omvandlas frustrationen till framåtriktad energi för att uppnå målet. Det är tydligt att mål och mätning finns djupt inpräntat i minsta del av ett F1 teams DNA.

Öppen kommunikation

Inom agilt talas ofta om ett nära samarbete och daglig dialog mellan olika intressenter. Allt för att underlätta utveckling, undvika missförstånd och för att rätt och kontinuerlig information ofta är avgörande för lyckade projekt.

Varje F1 team jobbar aktivt med att ständigt säkerställa öppen kommunikation genom alla led i organisationen. Det är också slående hur högsta ledningen på daglig basis medverkar på möten, coachar, uppmuntrar, informerar och själva ställer frågor. Det är fascinerande att en så högteknologisk miljö, full av mer eller mindre geniförklarade ingenjörer kan få till ett sånt ständigt utbyte av information kors och tvärs.

Allt tycks kretsa kring att få till ett transparent och ständigt flöde av kunskap och information, inom och mellan teamen.

Kort & lång sikt

I agil planering finns normalt två huvudperspektiv på planering, en långsiktig planering som kan sägas vara en grovplanering, där mål och viktiga milstolpar finns med. Till det kommer detaljplanering av det kommande arbetet, t ex planering för kommande 2-3 veckor. På det här sättet säkerställs helheten, samtidigt som fokus och resurser läggs på det mest närliggande arbetet.

Det är enkelt att se att alla F1 team har båda dessa perspektiv under en säsong. Varje säsong innebär ett stort antal lopp runtom hela jorden. Bara att frakta team och material till dessa ställen torde vara ett logistikprojekt av modell större. Det här kräver både en övergripande planering av hela säsongen och en detaljplanering av varje enskilt lopp. Bokstavligt talat ska varje skruv och mutter planeras. Det gäller att ständigt prioritera, prioritera om och säkerställa att fokus läggs på rätt aktiviteter. Och är det något man är skicklig på inom F1, så är det fokus. Fokus på här och nu. Det är nu det gäller, glöm allt annat.

Stor riskmedvetenhet

Aktiv riskhantering är centralt i alla projekt, så även inom agilt. Dels kan traditionella riskanalyser användas och dels kan riskhantering till viss del sägas vara inbyggt i det agila arbetssättet genom att successivt utveckla en produkt eller tjänst i mindre steg. Det här stegvisa arbetssättet kan minska risker för felinvesteringar och fel vägval genom att misstag upptäcks tidigare.

Att ständigt ha en medvetenhet om vad teknik, väder, organisation, finansiering, strategier och taktiker medför för risker är centralt inom F1. För visst finns risker. Massor av risker. Men det verkar, åtminstone utåt sett, som att identifiering, synliggörande och hantering av risker är ett högt prioriterat arbete för alla team inom F1.

Ingenting lämnas åt slumpen, och de risker som tas är medvetna och kalkylerade.

Slutsatser

Vi skulle kunna fortsätta med lärdomar om vad F1 kan lära oss som arbetar i projekt, som t ex att hela tiden visualisera och göra det komplicerade begripligt, fördelarna med att ha en ständigt närvarande beställare som aktivt fattar beslut, viljan att bidra, självkritiken m.m. Listan och liknelserna kan göras lång.

Det ska också tilläggas att det är högst oklart om F1 teamen använder begreppet projekt överhuvudtaget, t ex för en säsong, för utveckling av en bil, ett lopp etc. Kanske använder de istället begrepp som continuous delivery och continuous improvement, dvs ständiga leveranser och ständig förbättring. Det är ju också minst sagt aktuella områden inom utveckling idag. Men det är en annan historia. Den tar vi inte nu. Nu fokuserar vi på det första loppet för säsongen.

Kategorier
Läsarnas tips och råd Strategier för projekt

Tankar om projekt

I verksamheter eftersträvas ofta perfektion, tydlighet och branta utvecklingskurvor. Inte sällan ska mål och visioner uppnås genom projekt. Men är projekt perfekta? Vi kan behöva påminnas om att projekt utförs av människor, som gör sitt bästa för att tillgodose behov i verksamheter som är under ständig förändring.

Att acceptera att alla projekt inte blir fulländade kan vara utmanande. Ofta finns flera perspektiv och synsätt på vad som är tillräckligt bra utifrån behov och förutsättningar. I det här blogginlägget finns 6 utvalda bilder som kontrasterar mot det perfekta, och som kan få oss att stanna upp och reflektera kring vad som händer och sker vid genomförande av projekt. Vilka tankar och associationer kring projekt väcker de här bilderna hos dig?

Se nedan vad andra bloggläsare tycker, och dela gärna med dig av dina tankar och erfarenheter. Tillsammans kan vi lära oss mer om projekt.

tankaromprojekt1
Illustration från absurd.design

Tankar & erfarenheter

  • Den snabbaste vägen till målet behöver inte alltid vara den bästa.
  • Bestäm innehåll och principer för måltriangeln tid, kostnad och resultat.
  • Tänk bråttom och viktigt, inte bara bråttom, vid prioritering!
  • När det känns som att det går långsamt, tänk på att alla ska med och att det får ta sin tid.
Illustration från absurd.design

Läsares tankar & erfarenheter

  • Tänk på att dela upp stora projekt i mindre delar eller i separata projekt.
  • Fundera ut vad som är viktigast just nu.
  • Tydliggör och beskriv projektidén.
  • Definiera när projektet är slut och projektledarens ansvar upphör.
  • Dina idéer behöver bra kanaler för att komma till sin rätt.
Illustration från absurd.design

Läsares tankar & erfarenheter

  • Tydliggör målbilden.
  • Utmanande mål kan både motivera och skapa en känsla av orimlighet.
  • Vi är innovativa tillsammans.
Illustration från absurd.design

Läsares tankar & erfarenheter

  • Avsätt tid för intressentanalys!
  • Säkerställ att det är tydligt hur beslut fattas.
  • Säkerställ att projektledaren har mandat och att rollen respekteras.
  • Projektledaren har allas ögon och stora förväntningar på sig.
Illustration från absurd.design

Läsares tankar & erfarenheter

  • Tydliggör milstolpar och vad som ska vara uppnått vid varje milstolpe.
  • Säkra planeringen genom att analysera beroenden.
  • Vi uppfattar saker med våra olika ”glasögon” därför viktigt att få med flera perspektiv.
Illustration från absurd.design

Läsares tankar & erfarenheter

  • Säkerställ god kommunikation i projekt. Kan minska risken för konflikter.
  • Avsätt tid för att förankra frågor och beslutsunderlag!
  • Ta tag i konflikter direkt.
  • Projektarbete är ett samspel mellan olika individer som samtidigt är ihopflätade med ett gemensamt engagemang.

Kategorier
Strategier för projekt

Feedback eller feed forward?

Inom projektvärlden uppmuntras ofta chefer, beställare och projektledare att frekvent ge feedback till medarbetare och projektgruppsmedlemmar. Många agila ramverk har också sk feedback-kultur inbyggt i arbetssättet.

Ofta kan man också läsa tips som uppmuntrar att vi aktivt ska be om feedback för att kunna dra lärdom och vidareutveckla t ex projektledarskapet.

Men, i den här intressanta artikeln ifrågsätts om det verkligen är feedback som är det värdefulla sättet att utveckla individer på.

Läs artikeln på Harvard Business Review »

Kategorier
Strategier för projekt

När passar agila arbetssätt?

Vid val av vilket arbetssätt som ska väljas för utveckling finns det flera olika aspekter att ta hänsyn till, t ex karaktär av projekt, kännedom om behov på kort och lång sikt, projektets komplexitet och organisationens kunskaper inom det område som projektet avser.

Här beskrivs några situationer där agila arbetssätt för projekt kan vara att föredra framför traditionella arbetsätt:

Vi behöver ta fram en tillräckligt bra lösning som vi kan använda för att tillgodose våra nuvarande behov, vi får sedan vidarutveckla den så att den täcker in framtida behov.

Vi vet våra behov, men inser att det är svårt och tidskrävande att ta fram alla detaljkrav så här i början av projektet.

Vi vet inte hur omfattande lösning vi kommer att behöva eftersom det här är ett nytt område för oss.

Det är sannolikt att våra behov kommer att förändras i stor utsträckning jämfört med vad vi tror nu.

Vi behöver testa lösningen i mindre skala för att bättre förstå behoven och vilka krav som den har.

Kategorier
Strategier för projekt

Grattis på födelsedagen

Den 11-13 februari 2001 träffades 17 erfarna IT-personer på en skidresort i Utah, USA. Förutom att ha trevligt hade de ett gemensamt mål, att diskutera och konkretisera alternativa sätt att bedriva systemutveckling på.

Behovet till att hitta alternativa sätt var en reaktion mot att man upplevde att traditionella metoder och arbetssätt var komplexa och inte sällan resulterade i mindre lyckade projekt, t ex förseningar, fördyrningar och att leverans av resultat från projekten inte gick i takt med verksamhetens behov. Man upplevde att man saknade förmåga att hålla leveranstidpunkter och möta kvalitetskrav.

Resultatet blev det agila manifestet, som består av 12 agila principer som finns beskrivna tillsammans med 4 värderingar. Manifestet har kommit att spela en stor roll, och ofta en bas, för hur organisationer och olika agila ramverk och metoder tillämpar agila arbetssätt.

Vi säger hipp hipp hurra eftersom manifestet fyller 20 år! Det är fascinerade att manifestet fortfarande spelar en så stor roll i agila sammanhang. Det ska också sägas att det finns en mycket stor variation på hur både principerna och värderingarna tolkas. Men just det är ju så utmärkande för agilt: betrakta det som grundprinciper och värderingar, men tillämpa dom på det sättet som det passar er organisation.

Kategorier
Strategier för projekt

En husregel för möten som kan göra stor skillnad

Runt om i Sverige fortsätter projekt att genomföras med hög intensitet i de flesta branscher, trots speciella tider. Devisen – vi ställer inte in, vi ställer om – börjar kännas old school eftersom det numera är en självklarhet. Och eftersom projekt består av människor som behöver mötas för att kunna skapa värde i projekten växer nya digitala mötesformer fram.

Leverantörer av mötesplattformar lanserar förbättrade funktioner nästan varje vecka. Dessutom skrivs det alltmer om tips och råd för god digital mötesteknik runt om på bloggar och i sociala medier. Tekniken gör det också enkelt att spela in möten och diskussioner och åsikter blir förevigade och sprids i olika digitala kanaler.

Stora delar av utbildningsbranschen betraktar numera distansutbildning som en naturlig komponent för lärande. Sedan 2012 vidareutvecklar ProjektStegen olika digitala delar för utbildning. Under den resan har vi tillsammans med våra kursdeltagare lärt oss vad som fungerar och inte. Bland alla olika digitala komponenter är mötet i mindre grupper något vi utvecklat mycket, och det är kanske just i den delen av en utbildning där det finns mest praktisk kunskap att hämta för en kursdeltagare.

Det är när deltagare i en utbildningsgrupp öppet och generöst delar med sig av sina verkliga upplevelser, utmaningar och erfarenheter som utbildning kan bli fantastisk!

Under digitala möten i mindre grupper diskuterar vi olika projektsituationer och samtal kommer lätt in på områden som kan vara känsliga. Kanske upplever någon missnöje med ett agerande från en kollega, kanske upplever någon avsaknad av rätt förutsättningar för ett projekt. För att underlätta förtroliga diskussioner som verkligen gör skillnad kan det behövas principer kring hur information från möten hanteras. Det är här Chathams husregel kan bidra till att skapa en öppenhet och trygghet i mötet.

Vad är Chatham House Rule?

Regelns enkla princip kan sammanfattas med att det som sägs och diskuteras på mötet får spridas vidare, och det uppmuntras. Men ingen får avslöja enskilda mötesdeltagares åsikter och uttalanden. Information, kunskap och lärdomar från mötet får alltså användas efter mötet, men det är gruppen som blir källa till informationen, utan spårbarhet till enskilda mötesdeltagare.

Regeln uppfanns redan 1927 och har sedan dess utvecklats och förtydligats. Regeln är väl spridd och används flitigt i t ex olika internationella nätverk och institutioner. Vi använder regeln själva i utbildningssammanhang och för vissa typer av projektmöten.

Som så ofta är det enkla det mest användbara! Dessutom är det lätt att knyta an husregeln till agila värderingar och principer – det är gruppen som helhet som levererar och ansvarar för resultatet.

Läs mer om Chatham house rule för djupare förståelse för vad den innebär.

Har du några tips på husregler som kan göra skillnad för givande möten? Tipsa gärna!

Kategorier
Strategier för projekt

HIPPO syndromet i projekt

Många av oss har upplevt det på möten – projektet är i ett tidigt skede och det finns många oklarheter, vägval och frågetecken att reda ut för att säkerställa rätt lösning och strategi för att uppnå målen. Olika frågor kommer upp på inledande möten och många av frågorna är så komplexa att de behöver underlag, analys och eftertanke – kort sagt en förstudie.

Istället för att parkera svåra frågor och ta upp dem senare när de är tillräckligt förberedda så inträffar HIPPO-syndromet. HIPPO* är en akronym och står för Highest Paid Person’s Opinion, fritt översatt till högst avlönade personens åsikt. En HIPPO är oftast en senior chef, som utifrån sin position agerar med stor auktoritet och hyser respekt från medarbetare.

På möten tar ofta HIPPOn initiativet och ger sin syn på olika frågor. Istället för att dennes åsikt utgör en av flera möjligheter eller synsätt på vägen framåt så betraktas HIPPOns åsikt som den sanning och vägledning som projektet behöver för att komma vidare. Detta trots att så kanske inte alls är fallet. Det kanske saknas data för att fatta beslut, eller så har den unga och nyanställda projektmedarbetaren mer insikt och relevanta kunskaper i aktuella frågor. Men dennes åsikter tenderar att väga lätt när HIPPOn väl har sagt sitt.

Beslut i projekt ska vara grundade på data, analys och projektets samlade kompetens, inte enbart på HIPPO!

Vad kan du som professionell projektledare göra för att undvika det här syndromet? Vårt bästa tips är att alltid förbereda frågor som ska behandlas på möten med väl genomarbetade diskussionsunderlag. Om en fråga ska leda till ett beslut bör beslutsunderlaget också innehålla en rekommendation till beslut, med tillhörande motivering. Det här gör att diskussioner och beslut baseras på data och underlag.

Ytterligare ett tips är att du som projektledare aktivt styr möten så att alla mötesdeltagare får utrymme att ge sin syn på frågor innan ordet ges till HIPPOn. Genom det undviks att mötesdeltagare påverkas för mycket av HIPPOns åsikt.

* Begreppet HiPO, Highest Paid Option myntades av Dylan Lewis 2006 och vidareutvecklades sedan samma år till HIPPO av Avinash Kaushik och Ronny Kohavi.