För tillfället arbetar vi med en företagssimulering i grupper om fyra till fem. Varje grupp utgör ett eventföretag som av Grums kommun fått i uppdrag att erbjuda ett evenemang genom vilket kommunen, medborgarna och staden som helhet kommer att utvecklas och gå i vinst. Tiden att planera och generera en offert som är redo för presentation är satt på tre veckor, varav endast en är rent och skärt projektarbete. En stor del av detta studieblock är att vi drar nytta av och lära oss projektverktyg. Ett av dessa verktyg är en så kallad WBS (Work Breakdown Structure). Enkelt sett så används metoden för att bryta ned ett projekt i mindre moment (arbetspaket) vilket underlättar planering, resurshantering, analyser och det ger en bra överblick.
Förra veckan presenterade Lubit ett WBS system/spel som vi använde oss av. Matrisen vi körde med bestod av ett schema som innefattade tjugo dagar. Grupperna tog sig an en minisimulering som hade följande parametrar:
Uppdragsgivare: SEB
Uppdrag: Designa ett spel om privatekonomi
Format: Brädspel
Målgrupp: Barnfamiljer
Omfattning: Spelet ska vara färdigdesignat, med spelplan och artefakter färdiga att skickas till tillverkning.
Grupperna fick brainstorma för att ta fram områden vi ansåg som viktiga att ha med i en WBS. Med hjälp av vår fiktiva budget planerade vi hur arbetet skulle gå till under dessa tjugo dagar (eller åtminstone de dagar vi tog i anspråk).
För min del så var det inte bara ett lärande ur rent projektledarsyfte, utan det gav mig även djupare förståelse för speldesign. Alla aktiviteter som framtagits kategoriserades och gavs en färgkod (vi använde olikfärgade post-its att skriva ned arbetspaketen på.) Design, produktion, etc. När vi delat ut de diverse arbetspaketen i schemat så inträdde ett slags arbetsflöde. Man kunde ta ett steg tillbaka och överskåda skapelseprocessens mekanismer. Genom detta uppstod en möjlighet att på ”makronivå” utföra olika effektiviseringar. Detta är något jag tänker implementera i mitt eget spelskapande för att i ett tidigt utvecklingsskede få bättre översikt och insikt om diverse utvecklingsbehov och praktiska moment.
Medan vi planerade och fördelade resurser i form av personal så lade vi märke till att det blev ett relativt tight schema. I med detta kändes det rätt att lägga in en kontroll och viloperiod. Vår grupp beslöt att skjuta fram projektet en dag för att få plats med en buffert. Detta var dagen innan (enligt Lubitschemat) själva presentationen av produkten i det simulerade projektet. Här kunde de anställda andas ut, och om ett problem skulle uppstå fanns det tid att åtgärda det utan den enorma stress som skulle ha uppstått om problemet uppmärksammats under en fullspäckad sista arbetsdag.
Vi hade hela tiden som mål att ha en viss mängd resurser kvar som en depå för personalbonus och tillskott till nästkommande projekt. Men i och med vår tidsbuffert kändes det ännu mer relevant att inte vara slösaktiga. Om ett problem uppstod så skulle inte en buffert vara till hjälp om vi inte hade resurserna att åtgärda det.
Som helhet var det en nyttig WBS workshop, speciellt eftersom jag kommer att ha praktisk användning för systemet i mitt eget arbete inom kort.
Subscribe to:
Post Comments (Atom)
1 comment:
Kul att du fann workshopen nyttig, Mischa. Och du kommer som sagt garanterat få nytta av den. Angående vilodagar och eventuella budgeteringsdelar för resor till Karibien så är det nog ganska ovanligt att man har tid och pengar till att stanna upp produktionen en hel dag (visserligen var parametrarna för övningen att deltagarna i det fiktiva projektet hade andra sysslor parallellt med projektet, så jag tolkar det som att vilodagen var till för att låta projektmedlemmarna jobba med andra saker).
Post a Comment