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.

Kategorier
Strategier för projekt

Slow is Smooth, Smooth is Fast

Kan projektvärlden lära sig något av militära strategier? Det sägs att t ex det amerikanska specialförbandet Navy Seals använder följande devis – Slow is Smooth, Smooth is Fast, fritt översatt till att skynda långsamt är effektivt.

Att organisera ett team kräver först och främst ett mål, därefter en plan för att ta sig dit så snabbt som möjligt utifrån de förutsättningar som finns. Framdrift i gå-tempo är för långsamt, att springa ökar risken för misstag. Att halvspringa kan vara en bra medelväg. Vid eftertanke så går det ju att visuellt se hur militära trupper rör sig framåt genom att halvspringa i ett genomtänkt mönster – framåt mot målet i så snabbt tempo som möjligt utan att riskera för stora misstag.

Efter att ha utbildat tusentals projektledare och chefer i projektarbetsformen är det tydligt att många organisationer har för bråttom i sina projekt. Ofta går man från en otydlig idé och målbild direkt till genomförandet. Att det är en allt för utbredd verklighet idag i projektvärlden visar också undersökningar.

Många är de projekt som skulle vinna på att avsätta mer tid till att först göra en ordentlig målformulering, följt av en hållbar plan och sedan riskanalys för vad som kan hindra att nå målet. Därefter kan projekt börja röra sig framåt och leverera nytta i ett snabbt men kontrollerat tempo. Eller som dom säger därborta – Slow is Smooth, Smooth is Fast!

Kategorier
Strategier för projekt

Måldriven utveckling med behoven i fokus

Att beställa rätt projekt och samtidigt ha kunskap om när i tiden olika typer av funktionalitet och nytta behövs är centralt i alla typer av verksamheter. I grunden handlar det om kunskaper i att balansera insikter om verksamhetsbehov med produktionskapacitet. Ju bättre en organisation är på att definiera sina behov, och hur, när och i vilken omfattning projekten ska leverera den nyttan, desto effektivare projekt.

Häng med på en bloggserie i flera delar där vi beskriver och reflekterar kring hur kravarbete i projekt kan förberedas, genomföras och följas upp för att säkerställa att projekten levererar precis det som verksamheten efterfrågar.

Först ut är måldriven utveckling med behoven i fokus. Det ska sägas direkt att bloggserien har sin utgångspunkt i agilt arbetssätt, men många principer och moment kan även användas i traditionella arbetssätt, som t ex sekventiellt.

Om du saknar något område eller frågeställning inom det här området som du skulle vilja att vi kompletterar med så tar vi tacksamt emot förslag!


Effektivt kravarbete börjar med att klargöra behovsbilden. Låt behoven utgöra basen och strukturen för att definiera krav, ta fram lösningar, leverera och fungera som utgångspunkt för att följa upp att det blev som vi tänkt oss.

En kravprocess består av ett flöde av behov, möjligheter, lösningar och krav. Se samspelet mellan begreppen i den här översiktsbilden.

kravhantering i projekt - måldriven utveckling

Några förklarande punkter av översikten ovan som beskriver ett väl beprövat sätt att hantera krav vid agilt arbetssätt:

  • Behoven utgör grunden för kravhantering och är kopplade till de effekter som önskas uppnås. De samlade behoven kan benämnas som målbilden.
  • En Roadmap beskriver och visualiserar när en beställare behöver börja kunna använda resultatet, dvs börja kunna nyttja leveranserna från projektet.
  • Möjligheterna att tillgodose behoven tas fram på en första grov nivå. Med fördel kan dom olika möjligheterna uttryckas som olika Lösningsförslag.
  • Lösningsförslagen kan vara en mix av initiala respektive mer långsiktiga lösningar, vilket innebär att det kan bli aktuellt att gå vidare med både en kortsiktig och en långsiktig lösning för projektet, även kallat livscykelperspektiv.
  • Krav kommer nu in i bilden när Valda lösningar ska utformas.
  • De Valda lösningarna kan innebära en eller flera Leveranser och Delleveranser
  • Leveranser bryts sedan ner i olika Aktiviteter, dvs arbete, som behöver utföras för att kunna leverera.
  • Leveranser till verksamheten sker på två nivåer:
    Delleveranser från Utvecklingsteam, dvs innan allt är på plats avseende Leveransen.
    Leveranser från projektet, dvs när allt är på plats (”tillräckligt bra”) för att kunna anses levererat från projektet.
  • Verksamheten tar emot lösningarna successivt i form av olika delleveranser från utvecklingsteamen. Varje delleverans testas och godkänns av verksamheten.
  • Verksamheten påbörjar nyttjandet av lösningarna för att hantera sina behov. Nyttjandet sker över tid enligt bestämd Roadmap.

Med ovanstående vill vi visa att krav bottnar i behov, dvs något man behöver för att kunna uppnå de effekter man önskar. Det gäller både sk funktionella och icke-funktionella krav.

I våra konsultuppdrag ser vi ofta att många organisationer inte låter behoven vara ett eget steg i kravprocessen. Istället väljer man att direkt gå på kraven. Med det finns då en risk att tappa kopplingen mellan verksamhetsbehoven och det som projekten levererar.

Agilt vs Sekventiellt vid hantering av krav

En alltför vanlig kommentar vid traditionell utveckling som använder ett sekventiellt arbetssätt är ”Ni har inte fått den funktionen därför att den inte fanns med i kravlistan”. Det här beror oftast på att det är svårt att i förväg tänka på alla delar som behöver komma med.

Med det agila arbetssättet faller det sig mer naturligt att arbeta i strukturen Behov-Krav, dvs behov som resulterar i ett antal krav. I agil utveckling nöjer man sig ofta initialt med att definiera de behov som verksamheten behöver tillgodose på en övergripande nivå. I takt med att behoven sedan prioriteras sker sedan en detaljering, vilket vi kommer att beskriva mer i kommande blogginlägg i den här bloggserien.

Förståelsen av behoven ger bättre helhetsbild och stabilare bas än en kravförteckning. Lösningen för att tillgodose behoven kan komma att se annorlunda ut än om verksamheten själv tänker i lösningar med tillhörande krav.

Fördelar med att separera behov och krav

Projekt är människor är en tes vi ofta använder. Så även när det gäller krav. Att skilja på behov och krav skapar organisatoriska fördelar i projekten eftersom det blir naturligt att verksamheten fokuserar på att definiera sina egna behov. De äger därmed själva basen för projektet. Därefter engageras utvecklings- och produktionsenheter för att tillsammans med verksamheten arbeta vidare med kravprocessen och ta fram lösningar och definiera krav.

En vanlig fallgrop med att börja med att tänka lösningar och krav för tidigt är att det kan finnas olika möjligheter att tillgodose behoven. Dessutom är det ofta mycket lättare att beskriva olika alternativa och effektiva lösningar om de ställs mot specifika och definierade behov. Om kraven istället utgör basen för kravarbetet finns risk att man i onödan låser fast ett antal krav som kanske inte är relevanta eftersom de finns med i kravlistan för en lösning som kanske inte är aktuell längre, dvs risken finns att krav kvarstår till utvecklingsfasen även fast dom kraven kom till för en annan lösning som inte valts.

Visualisering av behoven i en roadmap

En gemensam målbild är en mycket bra bas för projekt. Med målbild menas en samlad och heltäckande beskrivning av behoven och de effekter som önskas uppnås. Ett tips är också att redan i ett tidigt skede börja arbeta med prioritering av behoven. En sk. roadmap kan vara ett enkelt sätt att visualisera prioritering av förväntade leveranser för att tillmötesgå behov.

leveranser av resultat och nytta projekt i en roadmap

En roadmap visar när verksamheten önskar få sina respektive behov tillgodosedda och i vilken omfattning. Mer om visualisering av roadmaps kommer vi att beskriva i kommande blogginlägg.

Måldriven utveckling

Baserat på olika möjligheter att tillgodose behoven, kan sedan olika lösningsförslag arbetas fram av t ex utvecklingsavdelningen, IT etc. Verksamheten är hela tiden med och kompletterar med krav under projektets gång.

Vid agil utveckling genomförs projekt indelat i flera kortare etapper, t ex i tidsperioder om 2-3 veckor. Ytterligare en fördel med måldriven utveckling utifrån behov är att det ofta är enklare att diskutera innehåll i olika etapper om utgångspunkten för planering av etapper är på behoven istället för att använda en kravlista som bas.

Fokus på behoven snarare än kraven gör att vi får en måldriven utveckling baserat på vad som behöver levereras och när verksamheten behöver sina leveranser. På så sätt uppnås också en naturlig prioritering i projekt.

Hur ska det här då gå till i praktiken? Vem ska utföra arbetet och hur sker kommunikation i den här typen av kravarbete? Vi kommer att återkomma kring organisation och roller längre fram i den här bloggserien.

Hoppas du har lust att följa hela vår bloggserie kring detta viktiga område krav. I kommande inlägg kommer vi beskriva och reflektera kring prioriteringar och avgränsningar, roller och ansvar, visualisering av roadmaps och verifiering.

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
Motiverande citat

Projekten blir allt mer komplexa

Ett tänkvärt citat från den store ledaren Nelson Mandela. Vi tycker att citatet passar utmärkt att applicera på dagens projekt. De blir alltmer komplexa och kräver ofta nytänkande och banbrytande insatser. Längst fram står projektledaren som ska leda hela projektet och göra visionen till verklighet.

Kategorier
Länkar

Ny lista över världens mest innovativa företag presenterad

Boston Consulting Group har nu publicerat en ny lista över världens mest innovativa företag. Precis som tidigare är IT den dominerande branschen, även biltillverkare är flitigt representerade på listan.

Det kanske mest spännande är dock att nya typer av bolag tar sig in på listan. Klädmärket Under Armour finns som nykomling på plats 22. De har ett mycket spännande arbetssätt för att jobba med innovation, se exempel på det genom Under Armour Idea House ».

Länk till listan med de mest innovativa företagen finns här »

Kategorier
Länkar

Innovation i projekt – högre krav på projektledaren?

Projektledning innebär alltid att förhålla sig till projekttriangelns tre faktorer tid, kostnad och resultat. I den bästa av världar har beställaren tydligt beskrivit och godkänt projektets viktning av dessa faktorer så att summan blir 1, t ex Tid=0,5, Kostnad=0,3 och Resultat=0,2. I exemplet är projektets förmåga att hålla tidsramar viktigast, följt av vikten att hålla budget. Projektets resultat bedöms som minst viktigt. I verkligheten är det dock oftast så att resultat och kvalitet inte är någonting som kan prioriteras bort utan betraktas som en självklarhet att det uppfyller – för att inte säga överträffar – förväntningarna. Inte sällan använder chefer och beställare ord som nytänkande, innovation, banbrytande, revolutionerade etc när de beskriver vilka förväntningar de och organisationen har på projekt. Dock nämns sällan att det finns utökad budget och tid för dessa projekt…….Hur ska man då agera som projektledare i lägen när det ställs allt större krav på innovation?

För det första gäller det att hela tiden vara observant på att ansvar och krav på innovation inte av bekvämlighetsskäl läggs på projektledaren. Innovation kräver genomarbetade processer i hela utvecklingscykeln från start till mål – kundkrav, idéer, design, produktutveckling, test, lansering etc. Det gäller därför som projektledare att vara överens med sin beställare om vad som förväntas och att rätt förutsättningar finns för att åstadkomma det. Vet inte beställaren exakt vad han eller hon vill ha så är antingen ett agilt arbetssätt eller en fördjupad förstudie nästan alltid ett måste för att få fram en gemensam bild och specifikation på förväntningar på projektet. Då tydliggörs även vad som är baskrav och vad som förväntas utöver det.

Det finns ett enormt utbud av sajter och bloggar som har innovation som fokus. Här har vi valt ut ett antal mycket läsvärda sajter som förutom innovation även tar upp trender och nya tekniker och arbetssätt. Kort sagt ämnen som en projektledare ständigt behöver hålla sig uppdaterad kring!

Länklistan som ger dig som projektledare koll!

https://www.psfk.com
https://recode.net
https://blogg.vinnova.se/category/opendata/
https://digiday.com
https://laughingsquid.com
https://www.naringsbloggen.se/innovation/
https://breakit.se

Har du tips på andra sajter och bloggar som handlar om innovation, trender och nya sätt att bedriva utveckling? Kommentera nedan!

Kategorier
Checklistor projekt

Checklista Förstudiefasen

Se nedanstående punkter som exempel på vad som är viktigt att tänka på i förstudiefasen i projekt
  • Det finns ett skriftligt beställningsdokument, kallat t ex projektdirektiv, att utgå ifrån
  • Det finns en namngiven beställare till förstudien
  • Förstudien har en beslutad budget som är realistisk
  • Förstudiens resurs- och kompetensbehov är kartlagt och nödvändiga resurser finns att tillgå
  • Förstudien har en tidsplan
  • Förstudiens mål är tydliga
  • Förstudiens leveranser finns beskrivna
  • Förstudiens avgränsningar är tydliga och förankrade
  • Övriga liknande eller angränsande projekt till förstudien är identifierade
  • Förstudiens intressenter finns beskrivna
  • Det är tydligt om förstudien ska omfatta flera olika alternativa lösningar eller endast fokusera på en lösning
  • En leveransförteckning finns upprättad med tillhörande leveransbeskrivningar
  • Olika analyser har genomförts för att bedöma projektet ur olika aspekter
  • Begrepp som används i förstudien är definierade för att säkerställa att alla menar samma sak med respektive begrepp
  • Förstudiens rutiner och arbetssätt finns tydligt beskrivna och är kommunicerade
  • Rutiner för förstudiens olika typer av möten och dess frekvens finns beskrivna
  • Säkerhets- och sekretessregler för förstudiens arbete och resultat är hanterade
  • Olika hinder för förstudiearbetet har beaktats
  • Ett skriftligt dokument, kallat t ex projektförslag, är framtaget som ett resultat av förstudien
  • Ett beslutsmöte har genomförts med projektförslaget som underlag
  • Beslutet innehåller något av alternativen: Acceptera projektförslaget och gå vidare till nästa fas, Acceptera projektförslaget med vissa ändringar eller Stoppa projektet

Copyright© ProjektStegen Sverige AB

Kategorier
Projektmodell och Verktyg

Använd Infographics för dina projekt

Allt fler bloggar, sajter, dokument, marknadsföringsmaterial etc använder sig av Infographics. Vad är då Infographics? Osäkert om det finns någon bra svensk översättning men en fri översättning av begreppet skulle kunna vara visuell informativ grafik, dvs ett medel för att på ett så tydlig sätt som möjligt visualisera ett budskap. Ett bra och enkelt exempel på hur Infographics kan användas hittar du här ». Exemplet visar hur mycket enklare det är att beskriva innehållet i t ex en Caffé Mocha med hjälp av enkel grafik istället för att med endast ord försöka göra beskrivningen tydlig.

Är Infographics då något nytt? Svaret är såklart nej. I alla tider har grafik och illustrationer kompletterat det skrivna ordet. Men det som är nytt är hur det används och i vilka sammanhang. Bruset av information blir som bekant allt större. Därför fungerar det idag ofta inte att nå ut med budskap via omfattande broschyrer, texter och dokument. Det gäller oavsett om det är en produktbeskrivning, en PowerPoint presentation för ledningsgruppen eller för att sälja in en projektidé till chefen.

Den som idag når ut med sitt budskap bäst är ofta den som kan sammanfatta det viktiga i några få ord och sedan visualisera nyttan, resultatet, det önskade läget etc på ett lättkonsumerat sätt. Och då är Infographics ett alldeles utmärkt verktyg och medel. I projektsammanhang finns det massor av olika situationer där det finns ett behov av att lyfta fram budskap på ett tydligt och enkelt sätt.

Exempel på situationer då Infographics kan användas
  • vid jämförelse av två eller flera alternativ
  • vid presentation av statistik och undersökningar
  • vid beskrivning av olika behov och vilken nytta t ex ett projekt medför
  • vid en översiktlig presentation av ett komplicerat ämne
  • vid olika beslutssituationer

Hur gör man då för att skapa Infographics? Sätter på sig stora tänkarhatten » och sedan köper in de dyraste grafikprogrammen? Eller bokar snabbt ett möte med reklambyrån och ber dem komma med förslag?

En rekommendation här är att följa dessa steg
  • Fundera igenom vilket huvudbudskap du vill förmedla
  • Beskriv målgruppen för budskapet för dig själv. Vad är relevant för målgruppen? Vilka olika intressen har de? Vilken kunskapsnivå har de om området och olika termer och begrepp? Behöver allt verkligen förklaras eller kan vissa delar utlämnas och beskrivas på annat sätt?
  • Försök beskriva budskapet så enkelt och så översiktligt som möjligt
  • Förenkla och förkorta ytterligare
  • Oavsett dina grafiska kunskaper så kan en enkel skiss visa hur du tänker dig en lösning, dvs visualisera
  • Fundera ut vilka olika kanaler din Infograhics ska verka inom? Ska det finnas en digital version för webben? En printversion? Osv

Välj sedan verktyg, se tips nedan, eller kontakta en reklambyrå eller kommunikationsbyrå för att få fram olika förslag.

Verktyg

Att själv göra Infographic kräver relativt stora kunskaper om layout, färg och form. Såklart kan även enkla verktyg som t ex PowerPoint räcka i något sammanhang, men för mera professionell visualisering krävs ofta verktyg som t ex Adobe Illustrator, Adobe PhotoShop eller andra verktyg som du kan läsa om här »

Länkar till verktyg online

Det finns även ett stort antal sajter som erbjuder mycket professionella verktyg och färdiga mallar för olika grafiska illustrationer av information . På bara några minuter kan även en novis skapa Infographics som ser ut som en byråproduktion i den högre klassen.
Exempel på verktyg online, där vissa är gratis och vissa kostar pengar, finner du i listan nedan. En trend bland onlineverktyg för visualisering är att de ofta har en stark koppling till olika typer av sociala media som t ex Twitter och Facebook.
Piktochart »
Visual.ly »
Easel.ly »
Vizualize.me (för att visualisera ditt CV) »
Hoppas det här blogginlägget gav lite inspiration till dina egna visualiseringar. Botanisera runt bland länkarna ovan sätt igång och visualisera! Har du tips & råd inom området visualisering och Infographics? Kommentera nedan!

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