På tal om projekt ...

Hej!

Erik
Jag heter Erik Sjöberg och är vd på Moment Projektkonsult. I min blogg kommer jag
att ge min syn på projektledning och allt vad det kan innebära.
Läs mer

Hej!

henrik_stadler_thumb

Mitt namn är Henrik Stadler och jag är Senior projektledare på Moment Projektkonsult.I min blogg skriver jag främst om projekt-ledning eftersom det är något jag brinner för.

Läs mer

Sök

Igår genomfördes tredje träffen i Projektnäring, och temat för dagen var "Årets projektledare", där både vinnaren Marie Reinicke och två av finalisterna, Jonas Ekberg och Yashar Moradbakhti, delade med sig av sina erfarenheter och alla vi som var där hade möjlighet att nätverka och utbyta idéer mellan såväl företag och branscher.

Frida Nilsson, redaktionchef på Motivation.se har skrivit ett intressant referat från träffen med rubriken "Känn varje individs styrkor - så skapar du supereffektiva team".

  /Erik

Publicerad i Ledarskap
2012-01-13 08:45

Agil projektledare

Äntligen! Efter en dryg månads väntan kom äntligen resultatet. Jag och många med mig fick ett mail som sa att vi hade klarat certifieringen och kan nu titulera oss PMI-ACP(Agile Certified Practitioner).

Under väntan har känslorna pendlat mellan “Såklart jag har klarat mig” till den lite mer deppiga “Det kanske inte gick så bra i alla fall”, så det var riktigt skönt att äntligen få ett besked och fantastiskt roligt att det gick som jag nog hela tiden trodde.

Nu ser jag med tillförsikt fram mot nya spännande Agila projekt som kan innebära roller som Agil projektledare, produktägare eller varför inte att hjälpa ett företag att införa Agil utveckling?   

/Henrik

Publicerad i Projektledning

Individer fattar bättre beslut än grupper!

Efter de senaste årens starka agila trender var det nog många som hajade till när Ari Riabacke förra veckan på Projektnärings första träff rakt upp och ner deklarerade att individer oftast fattar bättre beslut än grupper. Ari som disputerat i beslutsfattande torde ju ha bra vetenskapliga belägg för sina kommentarer.

Men vad innebär det för de agila metodernas syn på vikten av självorganiserande team, decentraliserat beslutsfattande osv? Redan före de agila metodernas intåg hde ju erfarna projektledare under lång tid involverat projektmedlemmarna i beslutsfattandet och ofta tagit ett steg tillbaka och låtit gruppen fatta flertalet beslut - i Sverige oftast efter koncensus - och bara i undantagsfall gått in och tydligt sagt att "det här är mitt beslut".

Så vad menar då Ari? Som jag tolkade Ari menade han att individer i en grupp har lättare att gömma sig bakom andra invider i gruppen när man fattar beslut. Man kanske inte fullt ut förstår beslutsunderlaget eller konsekvenserna av sitt beslut men "han" eller "hon" i gruppen "brukar ju förstå". Dessutom är det inte så allvarligt om det blir fel eftersom "vi ju var överens". Skillnaden blir stor när en individ är ytterst ansvarig och kommer ställas till svars för konsekvenserna av beslutet, och därför blir beslutet ofta bättre.

Men har det då plötsligt blivit mindre viktigt med gemensamma beslut, att få in hela gruppens samlade kompetens, att skapa delaktighet i beslutsprocessen osv?

Mitt eget svar på det blir förstås ett nej! Däremot tyckte jag det var riktigt uppfriskande att höra Aris kommentar eftersom jag tycker att såväl ledarskapsteorier som projektmetoder ofta förespråkas lite för enkelt och onyanserat. Som ledare måste man förstås ha förståelse för alla ovanstående perspektiv på beslutsfattande och situationsanpassat välja det som passar bäst, vilket i de allra flesta fall inte blir vare sig svart eller vitt utan en blandning. Som vanligt gäller det att förstå så många av verktygen i verktygslådan som möjligt och dessutom ha kunskapen om hur och när de bör användas. Om det enda verktyg man behärskar är en hammare kommer som bekant det mesta att se ut som en spik.

Publicerad i Organisation
2011-04-12 11:47

PMI vs agilt

Den internationella projektledningsorganisationen Project Management International (PMI) har på många sätt starkt bidragit till att projektledningsprofessionen fått ökad synlighet och status i arbetslivet. Det är mycket positivt. Man har bl a tagit fram PMBOK (Project Management Body Of Knowledge) som på flera sätt blivit den internationella standarden inom projektledning. PMBOK och tillägg i form av standarder för portföljhantering, programledning m m har kommit att bli rejält omfattande på gott och ont.

På gott - därför att de är genomtänkta och relativt heltäckande.

På ont - därför att det enligt min personliga uppfattning kommit att bli ett alltför stort fokus på omfattande processer, terminologier och annan "avbockningsbar faktakunskap" och för lite fokus på enkelhet, kommunikation, ledarskap och fingertoppskänsla.

Samtidigt som PMIs standarder vuxit fram har också de nya agila metoderna varit på stark frammarsch där huvudfokus snarare ligger på teamets effektivitets, självstyrande, kommunikation och samarbete och under en tid är det nog många som frågat sig hur dessa världar ska kunna mötas.

Det är därför glädjande att se PMI ta sig an de agila tankarna och nu ta fram en certifiering för agil projektledning och det ska bli intressant att se hur denna satsning utvecklas. En styrka med PMIs agila certifiering är också att den liksom den etablerade PMP-certifieringen (Project Management Professional) ställer krav på såväl utbildning som praktisk erfarenhet och avklarad tentamen. Inom flera andra metoder, t ex inom Scrum (och för den delen Prince2 - även om den metoden inte är agil) finns det ju certifieringar som erhålls redan efter en kort introduktionsutbildning, vilket självklart drar ner värdet av certifieringen.

Här följer så några länkar med information om PMIs agila certifiering:

Publicerad i Certifiering
2009-11-02 11:34

När börjar ni testa?

I många projekt är testning en av de viktigare aktiviteterna. Det gäller i allra högsta grad produktutvecklings- och IT-projekt.

En viktig framgångsfaktor är när i projektet man påbörjar sitt testarbete. Arbetar man efter en strikt vattenfallsmodell riskerar man att alltför sent fånga upp eventuella problem med testaktiviteterna. Om man till exempel arbetat 1,5 år i ett IT-projekt, och har ett halvår kvar till leverans, och först då inser något av följande har man stora problem:

  • De olika testmomenten tar längre tid än planerat
  • Utbildningen i testverktygen var otillräcklig
  • Bemanningen i testgruppen är otillräcklig avseende kvalitet och/eller mängden resurser
  • Prestanda-/skalbarhets-/datasäkerhetstester visar att en annan teknisk arkitektur borde ha valts

Listan kan göras mycket längre. Den viktiga slutsatsen är att testgrupperingen av projektet måste sättas i arbete och produktion så tidigt som möjligt i projektet: för att påverka utvecklingsprocessen, för att tidigast möjligt få till ett bra samarbete och flöde med krav- och utvecklingsteamen, för att det ska finnas tid kvar för att åtgärda eventuella utbildningsbehov, för att undvika att testandet blir en flaskhals på slutet osv. Sist men inte minst är det ett fantastiskt bra sätt att minimera risken för sena besked om stora förseningar i projektet.

Vissa projekt- och utvecklingsmetodiker ”tvingar” igång testandet tidigt och man får automatiskt ett bra stöd. Det gäller t ex projekt som använder systemutvecklingsmetodiken RUP, eller projekt som drivs med agila metoder som Scrum.

Viktigast ur det här perspektivet är såklart inte vilken etikett man har på sin process, utan att man börjar testa tidigt. Hur gör ni i era projekt?

Publicerad i Metodik
2009-10-06 11:22

Ny artikel om Scrum

Computer Sweden uppmärksammar på nytt Scrum i sin artikel Nu växer kritiken mot Scrum. Den här gången handlar det om att konsultföretag tjänar pengar på certifieringarna och att Ken Schwaber lämnar ordförandeposten i Scrum Alliance.

Personligen tycker jag det är mer intressant att läsa om tillämpningar av Scrum i stora komplexa projekt där det lättrörliga arbetssättet får slåss med andra prioriteringar som t ex krav på tidigt fastslagen teknisk arkitektur eller mer detaljerad planering inledningsvis som krav inför investeringsbeslut. Hur gjorde man och vad ledde det till?

Publicerad i Certifiering

På konferensen igår diskuterade vi bl a Scrum utifrån några faktiska projekt som drivits av Momentare. En fråga som kom upp var vem som beordrar övertid i ett Scrumprojekt – för absoluta deadlines kan ju finnas även där. Konkreta fall blir alltid mest intressanta att diskutera!

Publicerad i Metodik

Att få ett enstaka projektteam att arbeta agilt och därigenom effektiviseras är en mindre utmaning. Betydligt mer komplext, intressant och potentiellt lönsamt, blir det om man får med hela organisationen på ett nytt arbetssätt och skapar en förändrad kultur. En intressant artikel i ämnet är Where to Begin Your Transition to Lean-Agile.

Publicerad i Metodik

För att ett projekt ska bli effektivt fordras det en lagom mängd administration, oavsett om det är i form av traditionell projektplanering, möten, budgetering etc eller sprintplaneringar och dagliga scrummöten. För lite eller för mycket administration ger sänkt effektivitet – fast av olika skäl. För lite ger otillräcklig kontroll och bristfällig informationsspridning och för mycket administration skapar byråkrati och stjäl tid från produktivt arbete i projektet.

Det finns ett nyckeltal som säger att ca 20% av projekttiden bör vara just administration, i ett traditionellt projekt projektledning, delprojektledning, möten, tidrapportering etc. Jag tycker att detta nyckeltal stämmer förvånansvärt bra på olika sorters projekt av alla storlekar.


Publicerad i Metodik
2010-01-12 10:35

Metodfascism

Varför finns det en sådan övertro på metoder och processer? Personligen känner jag snarare en oro över att det inte kommer fungera när någon tveklöst påstår att med metodik x eller y så löser vi alla problem. Inte ens när de råkar vara den senaste som alla pratar om.

Det vore så mycket bättre om man kunde betrakta olika metodiker som verktygslådor. Som professionell PL ska man givetvis behärska de flesta verktygen i de flesta verktygslådorna. Vattenfallsmetoden lär oss att tänka först och planera i förväg. RUP sätter t ex fokus på ett iterativt arbetssätt och tidigt säkrad arkitektur. De agila metoderna ger oss bra verktyg för att successivt utveckla produkter som vi inte har möjlighet att specificera på förhand och understryker vikten av samarbete, kontinuerligt lärande och vikten av att själv få planera sitt arbete.

Den PL som bäst förmår att analysera sitt projekts och sin organisations förutsättningar, och sedan använder rätt verktyg (även om de kommer från olika verktygslådor) för att nå målen har stora möjligheter att lyckas. Särskilt om man inser att sammansättningen av verktygen bara är startpunkten till det verkligt viktiga: att få användningen av dem att fungera i projektet. Det sistnämnda uppmärksammades också i Det finns inga snabba genvägar i dagens Computer Sweden.

Avslutningsvis ett citat jag fick med mig hem från en ledarskapskurs en gång: “Om det enda verktyg jag har är en hammare, kommer det mesta att se ut som en spik.”

Publicerad i Metodik
<< Första < Föregående 1 2 Nästa > Sista >>
Sida 1 av 2