Kategorier
Strategier för projekt

10 moderna verktyg för projektarbete

På våra utbildningar är en vanlig fråga om vi kan ge tips på bra och lättanvända verktyg för projektledning. I takt med att allt mer arbete flyttas ut i molnet så dyker nya verktyg och aktörer upp hela tiden. Konkurrensen bland verktyg för samarbete kring projekt och aktiviteter är idag mycket hård. Det finns dock några verktyg som vi själva jobbar med. Här kommer några tips på verktyg som kan vara till stor hjälp för projektledare. Ett kriteria när vi valt ut verktygen nedan har varit att de är molnbaserade, relativt billiga att starta med och inlärningströskeln är låg. Håll till godo! Har du tips på ett nytt spännande verktyg för projektledning? Kommenterar gärna nedan.

Prototyping och Design

Invision är ett modernt verktyg för att t ex samarbeta kring framtagning av prototyper. Det går snabbt och tydligt att diskutera, visa, ändra och lägga till information kring t ex olika skärmbilder för en webbsida eller mobilapp.

Samarbete och kommunikation

Slack är ett flexibelt verktyg för att samarbete. Slack har ett snyggt och lättjobbat gränssnitt och innehåller ett stort antal möjligheter till integration av andra appar,  t ex olika planeringsverktyg, dokumentsystem mm.

Planeringsverktyg

Microsoft Project är det mest använda planeringsverktyget. Finns versioner både för desktop och som molntjänst. Finns i såväl enkla och grundläggande versioner till mer avancerade versioner som inkluderar portföljstyrning mm.

Agil systemutveckling

Jira är ett av de större verktygen för agil mjukvaruutveckling. Baseras på sk Scrum/Kanban-tavlor. Många funktioner för att mäta framdrift i projektet.

Samarbete och dokument

Microsoft SharePoint är den mest använda plattformen för dokumenthantering. Microsoft Sharepoint har med sin koppling till Office 365 snabbt blivit populär. Innehåller flera bra verktyg för projekt som t ex Planner, Teams mm.

Projekt och uppgifter

Asana är ett mycket väldesignat och lättanvänt verktyg för teamarbete inom projekt och aktiviteter. Innehåller också sk kanban-tavlor där gruppen kan se pågående och avslutade aktiviteter.

Gantt scheman

Ett av de mer etablerade verktygen som fokuserar på enkel funktionalitet kring Gantt-scheman. Det går snabbt att skapa en struktur över ett projekt och det finns även stöd för lite mer avancerade funktioner som t ex kritiska linjen mm.

Strukturerade listor

Trello är ett mycket lättanvänt verktyg för att arbeta med aktiviteter och uppgifter. Principen är att dela in tavlor utifrån ett tänkt arbetsflöde, t ex kommande, pågående och avslutade uppgifter. Dessutom är det enkelt att kategorisera uppgifter och t ex få notiser om ändringar sker mm.

Infographics för alla

De flesta projekt innehåller någon form av siffror och har behov att pedagogisera information för olika målgrupper. Piktochart innehåller ett stort antal färdiga mallar för olika typer av infographics. Visualiering på ett enkelt sätt.

Verktygslåda för design

Canva innehåller ett mycket stort antal färdiga mallar för olika typer av grafiska produktioner, t ex inlägg i sociala medier, presentationer, logotyper, annonser etc. Det går mycket enkelt och snabbt att skapa professionell design för print och digitalt.

Kategorier
Strategier för projekt

Finns det en optimal projektstorlek?

Det är svårt att hitta en generell regel för vad som är en optimal projektstorlek. Ett alltför litet projekt levererar inget av tillräckligt värde och ett för stort projekt kan kväva sig självt. Någonstans däremellan finns den optimala projektstorleken. Exakt var den finns varierar, men det går att systematiskt närma sig frågan.

WBS – en bra början

Ett vanligt sätt att angripa projekt är att arbeta med en sk WBS – Work Breakdown Structure. Först identifieras förväntade leveranser från projektet. Därefter analyseras de arbetsuppgifter/aktiviteter som krävs för varje leverans. Slutligen skapas projektplanen genom att aktiviteterna läggs ut i kalendern, med hänsyn till beroendeförhållanden mellan aktiviteterna.

Ofta nöjer sig många projekt med att göra en WBS. Men risken är att resultatet blir komplext och svåröverskådligt och därmed svårt att styra och följa upp. Det leder ofta till förseningar och fördyringar. Då uppstår inte sällan kaos och projektledaren tappar greppet om sluttid och om budget. Dessutom förskjuts medarbetarnas förväntade insats i tid, vilket förmodligen inte alls passar med deras egna och organisationens övriga planer.

Känns det igen? Någon form av ytterligare strukturering krävs för att få kontroll.

Don´t boil the ocean – dela upp projektet i mindre delar

Det finns ett välkänt managementbegrepp som heter Don´t boil the ocean, något som i det här sammanhanget fritt skulle kunna översattas till ”fokusera på en mindre del i taget istället för att allt på en gång”.

Med WBS:en som utgångspunkt struktureras arbetet i mindre delar som kan genomföras fristående från varandra. Resultatet blir ett antal olika komponenter/delar som tas fram och levereras fristående. Slutligen sätts de samman till en slutprodukt. Fördelen är att utvecklingen blir mer fokuserad, att komponenterna enklare kan bytas ut och att de i bästa fall kan återanvändas i andra sammanhang.

Frågan återstår dock om delarna ska utgöra delprojekt som underordnas ett huvudprojekt, eller om delarna ska vara fristående projekt med egen projektplan, ledning och bemanning?

Generellt sett brukar delprojekt vara att föredra om delarna ska levereras som en helhet. Likaså är delprojekt ofta bra om det är samma styrgrupp, projektledare och resurser för de olika delarna.

Fristående projekt är intressant om delarna kan levereras och användas separat och därmed har ett egenvärde för beställaren. I de fallen kan man med fördel etappindela projektet.

Begreppet projektprogram är också värt att nämna i det här sammanhanget. Vad som menas med det begreppet varierar kraftigt. Oftast innebär det att ett antal delprojekt, eller fristående projekt, har någon form av gemensam styrning i form av t ex en programledning. Programledningens uppgift kan t ex vara att samordna delarna, prioritera och säkerställa att dubbelarbete inte sker mellan de olika projekten.

Enklare att prioritera och tidigare leveranser

En fördel med att dela in projektet och leveranserna i mindre delar är att prioritering ofta blir enklare. Om tid och eller pengar tar slut kan man se vad som kan strykas eller senareläggas. En annan fördel med att bryta ner till delprojekt eller fristående projekt är att leveranser kommer tidigare och mer succesivt, istället för en stor leverans på slutet. Det här angreppssättet är något som blir allt mer vanligt och är ett exempel på agil utveckling.

Nedan beskrivs generella fördelar ur beställarens och ur projektgruppens synvinkel:

Fördelar för beställaren
  • Får successivt ta del av de förbättringar som projektet levererar
  • Får erfarenhet av nya tekniker och synsätt. En lärande process
  • Kanske blir medveten om nya möjligheter, vilket man kanske inte var från början
  • Får erfarenhet av att kommunicera effektivt med projektgruppen
  • Ser hur uppskattning av kostnader och tider fungerar i verkligheten
  • Får en uppfattning om projektgruppens styrkor och svagheter
Fördelar för projektgruppen
  • Ser tidigt effekterna av sitt arbete
  • Får erfarenhet av att kommunicera effektivt med beställaren
  • Får ökade kunskaper om verksamheten och beställarens problem. En lärande process
  • Ser hur uppskattning av kostnader och tider fungerar i verkligheten
  • Fokus på beställarens problem och önskemål ökar
  • Får en ökad uppfattning om beställarens engagemang, kunskap och tillgänglighet
Några faktorer som talar för att dela in ett stort projekt i mindre delar
  • Antal involverade personer är stort
  • Planerad genomförandetid är lång
  • Projektet är komplext
  • Ny teknik används
  • Ovana och dåliga kunskaper inom organisationen för aktuell typ av projekt
  • Beställaren har behov av tidiga resultat
  • Det finns ett antal kritiska delar
  • Projektet är geografiskt spritt
  • Projektet innehåller stora risker
7 steg för att dela in ett projekt i mindre delar
  1. Gör en WBS för hela projektet
  2. Dela upp i separata och helst fristående delar, om så är möjligt, vilket nästan alltid är fallet. Grunden för uppdelningen kan vara verksamhetsnyttan, teknik, risker etc
  3. Upprätta en lämplig tidsordning för allt som ska utföras. Naturligtvis måste man ta hänsyn till eventuella samband och beroendeförhållanden mellan delarna
  4. Prioritera delarna, vilket måste samplaneras med tidsordningen. Exempel på prioriteringsgrader är MÅSTE, VIKTIGT, BRA ATT HA
  5. Bestäm om delarna ska genomföras som delprojekt under ett och samma projekt eller fristående projekt
  6. Samla alla intressenter och gå igenom hela planeringsarbetet tillsammans för att komma fram till ett optimalt angreppssätt
  7. Fatta beslut och starta
Kategorier
Strategier för projekt

Hur hänger livscykelperspektiv och kravhantering egentligen ihop?

Effektivt kravarbete inom IT-utveckling och andra typer av projekt blir allt viktigare. Kravarbetet är dessutom något som berör hela organisationen. Tiden när kravhantering endast var något för IT-avdelningen är sedan länge förbi.

Som projektledare förutsätts du ofta ha en förståelse för hur kravhantering fungerar i de inledande faserna i projekt. Men för den som inte dagligen arbetar med krav kan detta stora och komplexa ämne vara svårt att tränga igenom. En bra början och introduktion till området kan därför vara att få klart för sig vad som menas de olika kravtyperna – funktionella och icke-funktionella krav.

Ett annat begrepp som används flitigt i det här sammanghanget är begreppet livscykelperspektiv. Det här inlägget handlar om att försöka förklara vad funktionella och icke-funktionella krav är för något och hur de hänger ihop med begreppet livscykelperspektiv.

Livscykelperspektiv (life cycle management)

En normal livslängd för ett IT-system är kanske 5–10 år. Under den tidsperioden kommer organisationens processer och behov att utvecklas och förändras. Det gör att systemet successivt måste anpassas och utvecklas för att kunna hantera de förändringar som sker. Men att ändra, bygga på och vidareutveckla system kan vara både problematiskt och kostsamt. Därför bör man ta höjd även för de krav som inte finns initialt, men som kan komma att bli verklighet i takt med att förändringar sker inom och utanför organisationen.

Ett väl utfört kravarbete beaktar och omfattar systemets hela tilltänkta livscykel, dvs från den första lanseringen av systemet tills systemet ska skrotas. Ett arbete som kräver extra tankemöda, resurser och tid initialt. En konsekvens av det är kanske att tidpunkten för en första lansering av systemet måste skjutas något på till förmån för den tid som det extra kravarbetet tar.

Eftersom många projekt genomförs under tidspress med krav från ledningen på en snabb time to market så ägnas ofta för lite tid åt kravarbetet. Fokus läggs enbart på de krav som finns på den första versionen av systemet. Hela idén med att tänka på ett systems hela livscykel redan från början är att det i slutändan kommer att löna sig, något som ofta visar sig vara en sanning.

Vilka olika typer av krav ska då hanteras med tanke på ett systems livscykel?

Vad menas då med funktionella och icke-funktionella krav? Här kommer en kort beskrivning.

Funktionella krav

En vanlig definition av funktionella krav vid systemutveckling är: ”De tjänster och funktioner som systemet ska tillhandahålla användaren”. Exempel på funktionella krav på ett system är möjlighet att registrera en betalning, kunna skriva ut en faktura, beräkna ett resultat etc. Funktionella krav är oftast de mest uppenbara och därför något som automatiskt får stort fokus i de inledande projektfaserna.

Icke-funktionella krav

Icke-funktionella krav kan ses som egenskaper på ett system utöver förväntad funktionalitet. En vanlig definition är: ”Med icke-funktionella krav avses egenskaper som systemet bör uppfylla, men som inte kan karaktäriseras som tjänster, såsom tillförlitlighet, användbarhet, effektivitet, kapacitet och säljbarhet”.

Tycker du fortfarande inte att det är tydligt vad icke-funktionella krav är? Här följer 13 olika typer av vanliga icke-funktionella krav med en kort förklaring av varje krav:

1. Underhållsbarhet avser frågor som har med ett systems förvaltning att göra, såsom korrigering av fel, förbättring av prestanda, anpassning till ny IT-utrustning och konfigurationshantering. Underhållsbarhet kan åstadkommas på olika sättt ex genom att upprätta en god dokumentation av systemet och dess handhavande. Det är också viktigt att bygga systemet i så fristående komponenter som möjligt, för att få kontroll över sidoeffekter och följdverkningar av uppdateringar.

2. Flexibilitet avser möjligheter att ändra och bygga ut system. Vanligtvis uppnås detta genom att systemet struktureras i komponenter som kan bytas ut och ändras.

3. Utrustningsoberoende avser möjlighet att flytta programvara mellan olika datorer och plattformar. Detta är viktigt exempelvis då organisationer utvecklas, decentraliseras eller startar samarbete med andra organisationer, vilket ofta medför att olika typer av plattformar måste kunna samverka. Utrustningsoberoende kan åstadkommas på olika sätt, exempelvis genom att ett system struktureras så att bearbetning av affärslogik och bearbetning som är relaterad till teknik separeras.

4. Återanvändbarhet avser möjlighet att i framtida projekt kunna återanvända analysresultat, design, system, program eller delar av program, för att uppnå kostnadsbesparingar vid framtida utveckling. Dessutom kan man oftast lita på att beprövade komponenter är korrekta. Återanvändbarhet kan åstadkommas på olika sätt, exempelvis genom att bygga systemet i komponenter och begränsa samband mellan komponenterna.

5. Interoperabilitet avser möjlighet för system att kommunicera med andra system eller annan utrustning. Det kan bl a åstadkommas genom att vanligt förekommande tekniker och utrustning utnyttjas och att man ansluter sig till gällande standarder av olika slag. Vidare bör man sträva efter en öppen design.

6. Att följa vedertagna standards är viktigt inför utvidgningar och samarbete med andra system.

7. Testbarhet avser möjlighet att kunna testa ett system. Att testa ett konventionellt administrativt system är oftast relativt enkelt, men att testa realtidsförlopp och samverkan och tidsmässig synkronisering mellan olika system och annan utrustning kan ibland vara svårare. Ett sätt att åstadkomma testbarhet är att frilägga kritiska delar och att skapa tydliga kontrollstrukturer i ett system.

8. Korrekthet avser huruvida ett system uppfyller specifikationen och tillfredsställer användarens önskemål.

9. Tillförlitlighet avser huruvida ett system utför operationerna på rätt sätt och att data är korrekta. Detta kan ha olika betydelse i olika typer av system. I ett datorspel är det inte av avgörande betydelse, men i ett säkerhetskritiskt system, t ex ett system som övervakar och styr flygtrafik, är det av största betydelse. Det kan exempelvis åstadkommas genom att olika typer av avstämningar och kontroller införs.

10. Effektivitet avser prestanda och ett systems förmåga att utnyttja IT-utrustningens möjligheter. Prestanda kan avse lagringsvolymer, bearbetningshastigheter och kommunikationshastigheter.

11. Säkerhet avser skydd mot otillbörlig åtkomst av program och data. Detta uppnås genom olika typer av tekniska skydd, exempelvis brandväggar, men en medveten och utbildad personal är också viktigt i detta sammanhang.

12. Användbarhet avser exempelvis enkelhet att använda ett system och enkelhet för användaren att lära sig detsamma. Det kan bl a åstadkommas genom att prototyper skapas, som de blivande användarna kan testa och pröva i utvecklingsprocessen.

13. Tillgänglighet är viktigt i exempelvis övervakningssystem och kan bl.a. åstadkommas genom att systemet eller delar därav dubbleras.

Av de 13 kravtyperna ovan har de sex första direkt att göra med framtiden, dvs de bör ses i ett livscykelperspektiv. Återigen kan sägas att det vid nyutveckling kostar lite mer och tar lite längre tid om sådana krav skall tänkas ut och beaktas, men att det ofta lönar sig i långa loppet.

De övriga sju icke-funktionella kraven kan också vara viktiga att beakta i ett livscykelperspektiv. Det kan gälla t ex kravet på användbarhet. Vid användarens bristande medverkan i kravprocessen, kan brister i systemet uppstå, t ex att viktiga affärshändelser inte hanteras på ett riktigt sätt eller att systemet är för krångligt utformat.

En siffra som nämns inom IT är att då ett system är nyutvecklat har man sett endast 25% av livscykelkostnaden. Övriga 75% uppstår under systemets livslängd och då gäller det att man tagit höjd för detta ifrån början. Inte sällan inträffar det att ett system måste skrotas redan efter något år därför att det är så oflexibelt byggt att det är mer lönsamt att börja om från början för att kunna möta de nya kraven.

Fokus i det här inlägget har varit på IT-utveckling. Men du som inte arbetar med IT utan i andra typer av projekt kan troligen också se fördelarna med att beakta både funktionella och icke-funktionella krav och att i möjligaste mån försöka blicka över hela livscykeln så tidigt som möjligt i projektet. Se även våra tips nedan som avser kravarbetet generellt.

Här kommer några tips för ett effektivt kravarbete:
  • Medvetandegör betydelsen av professionellt kravarbete och etablera en process för att ta fram och dokumentera krav
  • Låt kravarbetet få ta tid, det lönar sig på lång sikt
  • Engagera så många som möjligt i kravarbetet, inte minst med tanke på livscykelperspektivet. Engagera även de som har inblick i kommande planer som påverkar organisationens framtid
  • Se till att systemet passar in i en föränderlig framtid, avseende t ex affärsutvecklingsplaner, val av tekniska plattformar, leverantörssamarbeten och strategier för systemutveckling
Kategorier
Strategier för projekt

Prioritera rätt med enkel och beprövad metod

Alla har vi med jämna mellarnrum behov av att fundera hur vi bäst prioriterar vår tid. Ju mer tempot och antal ”måsten” ökar, desto större blir behovet av att prioritera rätt. Ett behov som i allra högsta grad finns hos projektledare i projektets alla faser.

En klassisk metod att använda vid prioritering är den sk Eisenhowermetoden, även kallad Eisenhowerprincipen. Den sägs ha använts av den amerikanska presidenten Dwight D. Eisenhower, som lär ha myntat uttrycket What is important is seldom urgent and what is urgent is seldom important. Fritt översatt: det som är viktigt är det sällan bråttom med, och det som det är bråttom med är sällan viktigt.

Den här enkla modellen går helt enkelt ut på att placera in t ex aktiviteter i en matris efter principen viktigt/inte viktigt och bråttom/inte bråttom.

Placera in dina aktiviteter och uppgifter i matrisen och få svart på vitt att bara för att det är bråttom med en uppgift eller aktivitet, så är den inte nödvändigtvis prioritet 1.

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?

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

Ingår installation av systemet?

Ä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 genomförandet startat?

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

Vad menas med en veckas leveranstid – 7 kalenderdagar eller 5 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 exempelvis 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.

Grundläggande standards ISO-704 och UML

Grundläggande standard inom terminologiarbete är ISO 704 Terminology work – Principles and methods. Det är ett ramverk för tänkandet och definierar viktiga begrepp, klassificeringar och strukturer. Vidare ges exempel och rekommendationer samt anvisningar för hur terminologiarbete bör gå till. En annan standard som också är relevant i detta sammanhang är UML – Unified Modelling Language.

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 (triangel/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 lamphållare 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åkets 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 oljeschejk 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

Vässa projekten med lateralt tänkande

Kraven på att projekten levererar rätt lösning och utförs på rätt sätt blir allt viktigare i takt med mer slimmade organisationer, snabbare krav på time-to-market och jakten på effektivitet. Det här blogginlägget beskriver en av flera metoder för att möta dessa ökade krav.

Ett projekt ses normalt som ett engångsarbete som genomförs av en tillfällig projektorganisation. Syftet kan vara att skapa något nytt eller förbättra något befintligt. Då en uppgift ska lösas i projektform finns det åtminstone tre strategiska frågor att ta ställning till:

1. Att lösa rätt problem eller behov
2. Att finna den bästa lösningen
3. Att genomföra lösningen på bästa sätt

De två första frågorna handlar mycket om kännedom om verksamheten och förmåga till kreativitet. De bör behandlas i samband med ett projekts initiering eller i en förstudie, dvs innan projektet startar. Den tredje frågan kan behandlas både i en förstudie och i projektets inledning, planeringsfasen.

Flera studier visar att missnöje med projektets resultat huvudsakligen förklaras av brister i beställningen, vilket berör de två första frågorna. Projektet var inte helt rätt tänkt från början.

Edward de Bono

Edward de Bono, född 1933 på Malta, är en läkare och författare som förknippas med gruppers effektivitet och med begreppet kreativitet, som han menar att alla kan lära sig. Hans tankar och metoder är framför allt tillämpliga i de två första momenten, dvs för att precisera problemet och för att finna den bästa lösningen.

De Bono menar att det vid problemlösning och tänkande i grupp finns tre vanliga problem

Vi reagerar ofta känslomässigt i stället för att tänka logiskt. Känslor är inte fel, men de ska användas på rätt ställe.

Om gruppen saknar strategier för tänkandet, blir den lätt paralyserad.

Brist på strategi för tänkandet och processen skapar förvirring i gruppen. Gruppen talar ofta om olika saker samtidigt, har olika perspektiv och kan befinna sig på olika detaljnivåer samtidigt.

Två av de Bonos metoder adresserar just dessa problem: Lateralt tänkande (The Use of Lateral Thinking, 1967) och Sex tänkarhattar (Six Thinking Hats®, 1985). Metoderna har fått stor internationell spridning.

Lateralt tänkande

De Bonos laterala tänkande är en metod för att stimulera skapandet av nya och gärna okonventionella lösningar på ett problem. Metoden används för det första momentet ovan, nämligen att definiera problemet och finna en lösning. Det går att t ex tänka tvärtemot, byta perspektiv, pröva nya kombinationer och hämta lösningar och idéer från helt andra områden. Det här är något som många projekt skulle må bra av. Fruktbart kan också vara att bemanna problemlösningsgruppen på ett okonventionellt sätt, t ex genom att ta med biologer och marknadsförar vid teknisk problemlösning. Metoden kan liknas vid brainstorming där det inte i första hand bedöms vad som är bra och realistiskt. Lateralt tänkande syftar till att finna en lösning.

Varför är lateralt tänkande användbart i projekt?

Lateralt tänkande passar inom flera områden, inte minst i dagens projektklimat. Idag ökar kraven på projekten genom att chefer och beställare ofta överlåter till projekten att lösa sin uppgift på ett kreativt, nytänkande och värdeskapande sätt. Projektledaren får dessutom ofta sin beställning iform av en relativt ofullständig beskrivning av vad som ska göras. Då kan projektledaren använda lateralt tänkande som ett bra verktyg.

Ett exempel från högskolevärlden är läraren som för att spara tid, lät sina studenter ta hem och rätta sina egna tentor. Det kunde göras med hjälp av en uttömmande och pedagogisk rättningsmall som studenterna fick med sig hem. Före utlämnandet tog läraren en kopia av tentan. Vinsten blev för studenten ett extra bra förståelse- och inlärningstillfälle och för läraren avsevärd reducering av rättningstiden, då endast en snabb koll behövde göras av varje tenta.

Sex tänkarhattar

De Bonos metod sex tänkarhattar (Six Thinking Hats®) innebär att en grupp tillsammans analyserar och bedömer en lösning systematiskt ur sex olika perspektiv, ett perspektiv i taget. Varje perspektiv symboliseras av en färgad hatt och tanken är att alla i gruppen samtidigt ikläder sig en hatt av samma färg.

De Bonos sex tänkarhattar

Vit hatt representerar objektiva fakta och information, ingen spekulation tillåts

Röd hatt representerar den emotionella aspekten, känslor och intuition, kräver ingen motivering

Svart hatt representerar det negativa och söker risker, problem, svagheter och hot som motiveras logiskt

Gul hatt representerar fördelar, styrkor och möjligheter som motiveras logiskt

Grön hatt representerar det kreativa, och används för alternativ och nytänkande

Blå hatt representerar processen, vad gruppen bör fokusera på och kanske nödvändiga förändringar i gruppens sammansättning

Med hjälp av hattarna uppnås bl a följande fördelar
  • Strukturering av tänkandet
  • Allas deltagande stimuleras
  • Fokusering på samma sak samtidigt i gruppen
  • Kreativiteten i gruppen stimuleras och ökas
  • Kommunikationen i gruppen underlättas
  • Underlättande och effektivisering av beslutsfattande

Låt oss spinna vidare på exemplet ovan, där det laterala tänkandet kring effektiv tentamensrättning resulterade i det sensationella lösningsförslaget att studenten rättar sin egen tenta. Lösningen analyseras nu med hjälp av de sex hattarna i tur och ordning.

Nedan visas exempel på frågeställningar som kan komma upp

Vit hatt (information och fakta). Hur många tentor handlar det om per år? Hur många lärartimmar läggs ner på rättning per år? Vilka typer av tentor rör det sig om – korta faktasvar eller essay-svar?

Röd hatt (intuition och känslor). Verkar modernt och bra! Kanske orättvisa missar i rättningen kan komma att göras?

Svart hatt (problem m.m) Alla typer av tentor passar inte för detta. Alla lärare kanske inte gillar detta. Studenterna kan komma att kräva detta på alla kurser. Går det att skapa heltäckande rättningsmallar? Är det rättssäkert? Hur skall överklagningar hanteras?

Gul hatt (fördelar m.m). Extra inlärningstillfälle för studenten och minskad rättningstid för läraren

Grön hatt (nya lösningsidéer m.m). För tentor med relativt korta fakta svar kan man förenkla ännu mer genom att tillämpa flervalsfrågor. Essay-frågor bör lämnas helt utanför

Blå hatt (process m.m). Ta med fler lärarrepresentanter i gruppen så att alla typer av kurser och tentor är representerade

Det här blogginlägg har förhoppningsvis belyst hur de Bonos metoder kan användas för att skapa kreativitet vid problemlösning och utformning av projektbeställningar.

Om du vill lära dig praktisera metoden finner du här länkar till litteratur att köpa på amazon.com, Bokus och Adlibris

Kategorier
Strategier för projekt

Kan Paretos lag tillämpas i projekt?

Paretos lag, mer känd under beteckningen 80-20 regeln, handlar om att det viktiga fåtalet har ett avgörande inflytande på helheten. Eller annorlunda uttryckt, 20 % av orsakerna svarar för omkring 80 % av effekterna. 1941 snubblade management- och kvalitetsgurun J. M. Juran över det resultat som den italienske ekonomen Vilfredo Pareto beskrivit redan 1906, nämligen att 80 % av marken ägdes av endast 20 % av befolkningen.

Samma förhållande gällde förmögenheten i landet. Juran upptäckte att Paretos lag också gällde inom kvalitetsarbete, nämligen att 20 % av komponenterna förorsakade ca 80 % av problemen. Efter detta har det konstaterats att 80-20 regeln gäller inom många områden, alltifrån ingenjörskonst till sociala vetenskaper. Just 80-20 relationen är naturligtvis inte exakt utan differensen kan vara både större och mindre, beroende på område och aktuell situation. Men klart synes vara att differensen ofta är oväntat stor, vilket innebär att det kan finnas skäl till att begrunda detta i det enskilda fallet inom t ex organisationer, processer, förändringar och projekt.

Följande är beskrivna och tänkbara exempel där Paretos lag kan ha relevans

20 % av marknadsföringen står för 80 % av försäljningen

80 % av klagomålen kommer från 20 % av kunderna

20 % av säljarna står för 80 % av försäljningen

20 % av resultatet står för 80 % av användarupplevelsen

80 % av utfört arbete görs på 20 % av den slutliga tiden

20 % av personalen står för 80 % av problemen

20 % av komponenterna i en produkt står för 80 % av kostnaderna

20 % av ärendena i en tjänsteorganisation står för 80 % av den totala handläggningstiden

80-20 regeln verkar uppenbarligen vara värd att beakta i förändringsprojekt i de flesta sammanhang, t ex IT-utveckling, organisationsutveckling, processutveckling och produktutveckling. Alla utvecklings- och projektinsatser verkar inte vara lika viktiga, vilket gör att Paretos lag är intressant då man t ex analyserar relationen mellan utvecklingskostnader och möjliga och önskvärda effekter. Det gäller att försöka identifiera de viktiga 20 procenten. För att göra detta kan man analysera lönsamheten i olika delar av önskat resultat, vilket kan ge en prioriterad lista för projektinsatserna. Naturligtvis är det inte alltid så enkelt att på så sätt identifiera det som bör göras. Vissa delar kan behöva göras, trots att de inte finns med bland de 20 procenten.

Det kan t ex bero på följande

Lagar och förordningar ställer krav på projektets resultat

Inom t ex IT kan säkerhetsfrågor vara utanför förhandlingsbarhet

Samordning med andra verksamheter/produkter och inordning i infrastrukturer

Samband mellan de olika projektresultaten kan medföra att en lågprioriterad del krävs för att en högprioriterad skall fungera

En annan aspekt på Paretos lag är undantagsfall vs. normalfall inom olika typer av ärendehantering inom t ex en tjänsteorganisation.

Om 80-20 regeln skulle visa att 80 % av ärendena (normalfallen) är relativt enkla och kan klaras på 20 % av tiden, så kan dessa klaras av personal med kortare utbildning, medan de 20 % ärenden som är komplicerade skulle kunna hanteras av särskilt utbildade experter.

Inom IT, då man bygger system, kräver kanske 80 % av funktionerna 20 % av projektets tid och kostnader, medan de 20 % mer komplicerade funktionerna kanske kräver 80 % av utvecklingstiden.

Komplicerad logik är dessutom sårbar för programmeringsfel och felaktig hantering av användaren. Så, den fråga man kan ställa sig i projektet är om inte de komplicerade 20 procenten (siffran kan naturligtvis vara lägre eller högre) skall hanteras manuellt och inte ingå i systemet. Exempel på ett krångligt ärende kan vara då man måste korrigera för en felaktig transaktion som inträffat för ett år sedan. Man kanske blir tvungen att gå tillbaka till databas-backuper och den felaktiga transaktionen kan också ha gett följdfel i andra system och databaser, som måste hittas och korrigeras.

Förändring och utveckling kostar ofta mycket pengar, medför risker och kan ta lång tid. Detta blogginlägg försöker belysa att man initialt bör analysera och pröva vad som är mest lönsamt och viktigt. Om man lyckas identifiera den lönsamma kärnan, så kan projektet begränsas till denna. Eller, om den kan realiseras fristående, kan den utgöra den första etappen i projektet. Därefter kan man i lugn och ro, och med erfarenhet från den realiserade kärnan, fundera på en eventuell utvidgning och fortsättning.

Slutsats

Kan då Paretos lag tillämpas i projekt? Detta är naturligtvis ett extremt sätt att förhålla sig till projekt och hur pass väl det fungerar i praktiken varierar nog från projekt till projekt. Men, det är i alla fall en intressant modell för att sträva efter de 20 procenten i projektet som ger mest effekt och välja bort de 20 procenten som tar mest tid och resurser.