2.2 Projekt inom produktionsutveckling

Följande avsnitt bearbetar de aspekter som är väsentliga att ta hänsyn till tidigt i agila projekt inom produktionsutveckling. Genom att bearbeta dessa punkter som beskrivs i avsnittet kan projektet frontmatas och eventuella problem hanteras.

Projekt med högre grad av osäkerhet är ofta mer lämpade för en agil modell medan den s.k. vattenfallsmodellen passar bättre i projekt med mindre osäkerhet Det finns dock inget som säger att det inte går att kombinera dessa metoder för att driva projekt. Det är även viktigt att poängtera att de flesta företag har ett kvalitetssystem och följer s.k. grind-modeller (Stage/Gate) för projektgenomförande, vilket alla projekt på företaget behöver anpassas till. Är det ett projekt med ny teknik där det inte är helt klargjort hur produkten ska tillverkas är det ofta lämpligt att starta projektet med en agil projektmodell. Det går oftast i ett senare skede att vid behov växla över till vattenfallsmodellen. En första viktig princip när en agil projektmetod används är att sätta samman ett projektteam som tillsammans sätter mål och skapar samsyn. Detta är kritiskt för ett effektivt genomförande (mer om projektroller och teamsammansättning i kapitel 2.2). Det är viktigt att tidigt fundera på hur projektet skall drivas och att involvera teamet i planeringsarbetet.

De övergripande målen, budget och tidsramarna för projektet är vanligen kända och definierade innan projektstart, till exempel i en ”intern projektbeställning”. Alternativt är utvecklingen av produktionssystemet en del i ett större utvecklingsprojekt. Projektbeställare i form av projektchef, produktionsdirektör, eller liknande bör även vara kända. Finns inte detta på plats bör den frågan lösas för att skapa förutsättningar att lyckas med projektet.

I detta första skede av projektet är det särskilt viktigt att lägga extra arbete på att:

• formulera en tydlig gemensam målbild. Ofta bedrivs projektet enligt principen ”så här brukar vi göra”, utan större reflektion kring vad det är som verkligen ska leverera. Därför är det viktigt att i ett tidigt skede gemensamt formulera och definiera en målbild som samtliga inblandade förstår.
• ta god tid till att reflektera kring vilken metod som ska användas och hur det aktuella projektet borde genomföras. Strategi för genomförande bör finnas på plats tidigt. Det finns annars en risk att viktiga aspekter förbises eller missas, så som att få med alla ombord och bygga ett bra team tidigt.
• göra en tidig värdering om det är rimliga mål, omfattning, tidsramar, resurser, etc. för att leverera projektet. Det är bra att tidigt flagga för om det finns oklarheter eller orimligheter. Det är inte ovanligt att det finns så många osäkerheter att det vore bättre att genomföra en förstudie, för att sedan besluta om att genomföra projektet.

När frågorna ovan är klargjorda, projektets förutsättningar definierade, beställare utsedd och det finns ett team på plats är det dags att planera projektet.

Ett första steg är att förstå vad kärnan i leveransen från projektet består av och vilka de kritiska intressenterna är. Har detta klargjorts är förutsättningarna goda för att få en bra projektstart. För att förstå kärnan och värdet av projektleveransen finns det två vägledande principer:

• Förstå funktionaliteten: Vad är det för processer som skapar värde som någon vill betala för? Vanligen finns långa kravspecifikationer med omfattande krav och det är ofta svårt att få en tydlig bild om inte de grundläggande funktionerna lyfts fram. Se till att funktioner och alla de begränsande krav som finns hålls isär. Det hjälper till under projektets genomförande. Dessutom är många kravspecifikationer bristfälligt skrivna och flera krav växer fram under projektets gång, varför det hellre bör ses som en kravhanteringsprocess, som startar med funktionaliteten. Involvera slutanvändare i detta arbete.
• Tänk effekt snarare än leverans: Istället för att tänka ”vad som ska levereras” bör tankesättet vara ”vad som blir effekterna när projektresultatet implementeras”. Detta är ofta lite abstrakt och lite svårare, men det är mycket bättre att fokusera på effekterna än att bygga färdigt något till en viss tid. Är effekterna tydliga blir det lättare att motivera teamet och genomföra projektet. Är det svårt att visa på effekterna är det en indikation på att projektet är antingen för svagt eller dåligt definierat.

Det är viktigt att tidigt klargöra kritiska interna och externa intressenter. Med intressent avses alla de personer och organisationer som kan ha en påverkan på projektet i någon form. Vilka intressenter som finns och hur enkelt det är att definiera dem varierar mellan projekt, men denna fråga kan inte uteslutas. Antalet intressenter varierar och vissa projekt kan ha få intressenter. Några exempel följer nedan:

• Mottagare av projektresultatet: Oftast någon i linjebefattning. Det är viktigt att klargöra vem som blir ägare av projektresultatet. Finns inte det på plats är det bra att tidigt börja driva frågan.
• Interna intressenter: T ex kvalitet, inköp, produktionsteknik, och konstruktion.
• Externa intressenter: T ex myndigheter, kunder och leverantörer.

För att varje projektdeltagare ska kunna arbeta effektivt i projektet är det väsentligt att tidigt klargöra vilka frihetsgrader som finns. På så sätt blir arbetet mer inriktat på de frågor som kan göra skillnad. Vanligtvis är det mycket som redan är fastlagt och då handlar det om att leda och styra projektet i rätt riktning. Det är då viktigt att säkerställa att förmågan att kommunicera fungerar. Det är avgörande att lyckas etablera ett team som har ett bra och tätt samarbete som kan ta hand om förändringar och problem, kan planera/omplanera, säkra små steg mot slutleveransen/målen och säkra att alla jobbar med prioriterade frågor.

Nedan finns en checklista med aspekter som bör klargöras tidigt för att bespara projektet onödigt arbete i senare skeden och för att undvika omarbete. För mindre projekt är många delar inte tillämpbara, men det är en checklista så ta bara med det som skapar mervärde i det aktuella projektet. Dessa är användbara både inom ramen för ett agilt arbetssätt och inom modeller liknande vattenfall. Varje projekt är unikt och checklistan ger exempel på aspekter att beakta i ett tidigt skede.

• Avtal / “Design Brief” / Project Order
• Förstå avtalet
• Teamet, roller, flexibilitet
• Arbetets omfattning
• Mål
• Leverabler
• Budget
• Behov av förstudier
• Milstolpar, planeringsprinciper, “Base line”
• Rapportering
• Kommunikation
• Utvecklingsrapportering
• Dokument-hantering (verktyg, mallar, etc.)
• Koordination / Gränssnitt
• Kravhantering
• Förändringshantering
• Förhandling kring projektsponsorer
• QA / HSE
• Normer och förhållningssätt
• Kritiska utmaningar
• Informationshantering
• DBs / Verktyg / etc.
• Mottagare av projektresultat
• Nyckelintressenter
• Agil eller Vattenfall
• Lärdomar
• Förväntningar och prioriteringar