Det självklara receptet för framgång i projekt

10 01 2012

Under ett flertal kurser har vi bett deltagare (ofta, men inte alltid, erfarna projektledare) att beskriva ett projekt de varit med om, på jobbet eller privat, som varit särskilt framgångsrikt och vilka förutsättningar och faktorer som fanns på plats.

Det som är utmärkande från dessa samtal är att:

– alla, oavsett erfarenhet, kan beskriva minst ett projekt som varit en framgång
– alla kan med enkelhet identifiera vilka framgångsfaktorer som låg bakom
– uppräknade framgångsfaktorer är till 95% i linje med principerna i det agila manifestet.

Vid senaste tillfället, på kursen ”Att leda och driva agila projekt” på Frontit, så reflekterade deltagarna över den på något sätt självklara uppräkningen. ”Vi sitter ju själva på svaren – varför GÖR vi inte detta hela tiden?”

Här är deras framgångsfaktorer och recept för framgång i projekt:

SCOPE (Omfång)

  • Inte för stort
  • Akta svällning

VERKSAMHET OCH KRAV

  • Verksamheten med, hela tiden
  • Närhet till kunden, har mottagaren med sig
  • Har med sig kravställare och engagerad kravägare
  • Visa skarpt mot beställaren
  • Engagerad beställare
  • Förberedelser, kratta manegen

MÅLBILD

  • Tydligt mål
  • Förståelse – alla drar mot samma mål
  • Delmål – driv mot målen från start med timeboxar
  • Beskriv VAD vi ska lösa, inte hur

TEAM

  • Alla var där
  • Folk engagerade
  • Hålla lusten vid liv!
  • Fira segrar
  • Tät grupp
  • Kräver närarbete
  • Tydliga roller
  • Emotionellt/funktionellt perspektiv

STYRGRUPP

  • Engagerad och aktiv styrgrupp, som är påläst och tar sitt ansvar
  • Utbilda styrgruppen

KOMMUNIKATION

  • Kommunikation – intern och extern
  • Samma språk

UPPFÖLJNING OCH UTVÄRDERING

  • Utvärdera projektet löpande – och korrigera på vägen
  • Ha bra uppföljning – hela tiden

VÄRDERINGAR

  • Prestigelöshet

Grupperingen har jag gjort nu för att det ska bli lättare att läsa, säkert skulle någon av deltagarna valt en annan gruppering.

Efter att ha fått liknande faktorer vid olika tillfällen är det värt att särskilt uppmärksamma Team-faktorerna. Vi bör inte underskatta värdet av sammansvetsade team för att nå framgång. Tyvärr verkar detta bli mer och mer ovanligt i projektvärlden. Tillfälliga projektmedlemmar, projektmedlemmar på distans, splittrat arbete, lokaler som inte är anpassade för teamarbete, liten tid och inga pengar för  teamstärkande aktiviteter mm gör att vi slår undan benen för oss själva när vi försöker driva ”projekt”.

Själva idén med ett projekt är en fokuserad insats under en avgränsad tidsperiod som samlar olika kompetenser för att få ut nytta av teamorienterat arbete.

De organisationer som arbetar med långsiktiga team, dvs samma team – olika projekt eller utvecklingsaktiviteter, verkar nå större framgång. När glömde vi bort team-tanken i våra projektorganisationer?

Som projektledare, eller för den delen vilken roll som helst jag får i ett projekt, säkerställer jag numera att dessa faktorer (och synonymer) finns på plats innan jag gör ett åtagande som deltagare. Om de inte finns på plats när jag kommer in frågar jag vad vi kan ta för steg för att få dessa på plats. Vid t.ex distansarbete kan kreativa lösningar för närhet hittas, det finns exempel på detta. Om situationen är ”omöjlig” avstår jag hellre än att fortsätta kasta pengar i sjön genom att spendera beställares investeringar i arbete som inte har eller kan få rätta förutsättningarna att lyckas.

Hur gör du?





Kvalitet och kommunicera lättrörliga krav – Sundsvall 42

20 10 2011

Under konferensen Sundsvall42, som pågick den 18-20 oktober 2011 höll jag ett seminarium på tema ”Att kommunicera lättrörliga krav” i spåret ”Kvalitet” med undertexten ”Ok, nu jobbar vi agilt – är det bättre eller inte”. Flera frågor att svara på alltså, hur gör man det på 40 minuter?

Dessutom var det skrivet att detta är ett seminarium, inte en föreläsning, och min tolkning av seminarium är att det innehåller interaktivitet. Hur gör man en workshop i en biosalong med 60 deltagare?  Det finns säkert bra svar på det, det sätt som dök upp i huvudet på mig inför konferensen var att låta deltagarna refklektera omkring begreppet ”Kvalitet” och hur det kan tillämpas på kravarbete i en alltmer snabbrörlig värld – och dessutom dokumentera on the fly i Prezi. Att servera färdiga svar när det sitter 60 erfarna testledare, kravare, förvaltningsledare i publiken känns på något sätt.. omodernt – det måste finnas bättre sätt. Färdiga svar är bara att googla på – som min nyfunne digitala kamrat @erkstam sa under sitt föredrag om digitalisering.  ”Googla på mig så kan vi skippa hela den där presentationsbiten.”

Googla på ”Agile requirements” så hittar du en del, eller varför inte skaffa ett Twitter-konto tillslut och fråga där! Twitter är en fantastisk yrkeskunskapsbank för tips om artiklar, bloggar, rapporter mm. Om du hittar mig där (@ulrikapark] kan jag hjälpa till lotsa till intressanta grupper där du kan ställa frågan, eller så retweetar jag din fråga. Några tips från mig på tekniker och annat finns lite längre ner.

Prezi-dokumentationen från seminariet  (via traditionell dator behövs inget login). Jag försöker också få ner resultatet här i en något mer fyrkantig form som kanske är lättare att skriva ut. Tack till Ulf Eriksson, Reijo Soréus, Azim Rezaei, adjunkten från Mittuniversitetet och alla andra mycket kloka personer i lokalen som bidrog till ett facit, ett av flera multipla sanningar, för HUR vi bör jobba med krav för att uppnå kvalitet i de system, produkter eller tjänster vi levererar.

Några associationer  deltagarna gjorde till begreppet ”Kvalitet”:
(alla 60 kommer redovisas i separat inlägg)

LEVERERAT ENLIGT BESTÄLLNING

Vad kan vi göra när vi arbetar med krav för att bli säkrare på att leverera enligt beställning (”det får kosta så här mycket, jag vill ha det här”)?

Deltagarnas svar:
Var TYDLIG! Hur blir vi tydliga? Genom DIALOG och MALLAR t.ex User Stories.

Detta brukar jag kalla ”Extreme Expliciteness”. Extrem tydlighet alltså. Att använda krav&test-tekniken ”Specification by example” (Gojko Adzic har skrivit bra böcker i området) i kombination med user stories (Mike Cohn) är mycket användbart för att uppnå extrem tydlighet.

INGA FEL

Vad kan vi göra när vi arbetar med krav för att bli säkrare på att det blir rätt – inga fel?

Deltagarnas svar:
Test & granskning i iterationer!
Demos!
Flera iterationer över ett och samma krav!
Användarmedverkan!
Utvecklarmedverkan!

Inte bara kravaren är med i kravställningen alltså! och involverade på riktigt – mitt tillägg. Det räcker inte med att göra en workshop en gång där man ”samlar in krav” utan utvecklare och användare behöver vara med och påverka kraven löpande under hela genomförandet. Bästa sättet att lära sig mer om detta är att börja pröva idag!  Vad hindrar dig, ditt team, din organisation från att iterera över ett krav flera gånger, eller att involvera utvecklare i processen? Vad kan DU göra för att påverka det i små steg? Sitta 1 dag i veckan hos IT-leverantören? Sitta 1 dag i veckan hos din kravställare?

TRYGGT

Hur gör vi för att uppnå trygghet med kraven?

Deltagarnas svar:
Prototyper
Verifiera kraven, genom demos
Prioritering!
Kommunikation!
Rätt människor med

Ramverket Scrum innehåller många verktyg för just detta – tvärfunktionella team, prioriterade product backlogs och kommunikation och synlighet genom regelbundna demos och tvärfunktionella planeringsmöten (sprintplanering).
Scrum på 5 minuter.
Confessions of a serial Product Owner

ANVÄNDBARHET

Kvalitet är användbarhet. Hur uppnår vi användbarhet när vi arbetar med krav?

Deltagarnas svar:
Prototyper
Användningstester

Mitt tillägg: Engagera en duktig UX-designer (användbarhetsexpert ibland kallad) i teamet – som arbetar med teamet löpande genom hela genomförandet, inte bara i början eller i slutet. Personliga tips: Anette Lovas – Connecta, Fredrik Lindersson  – Söderhavet, Johanna Särnå – Valtech,  Sigrun Tallungs – Frontit, och säkert en hel bunt till därute t.ex på Antrop och Transformator Design.

Intressanta artiklar om User Experience Mapping

HÅLLBAR

Hur uppnår vi krav som håller över tid, är aktuella mer än 3 månader?

Deltagarnas svar:
Tydliga mål!
Gå ner på djupet! Gå ner på domänen och förstå varför.

Mål håller ofta längre än detaljerade krav. Vi ändrar inte målen varje dag, däremot gärna detaljerna beroende på förändrade omvärldskrav eller förväntningar.
Informationsobjekt/domänobjekt håller också längre än detaljer i funktionalitet är min erfarenhet. En informationsentitet – eller domänobjekt – (beroende på vilken ”skola” man pratar med) ändras inte varje dag när man väl lyckas förstå och kommunicera vad det är för objekt ”begrepp” vi pratar om. Därför är domänobjekt t.ex utmärkt lämpliga för att strukturera krav- och testdokumentation omkring, eftersom dessa strukturer håller över tid – åtminstone bra mycket längre tid än en user story.

Dessutom så vid de tillfällen jag varit med vid begreppsmodelleringsworkshops ”med rätt människor med” så har betydligt djupare insikter kommit fram om kraven. Insikter som kan vara både besvärliga och kännas omöjliga, men som verkligen bidrar till en djupare dimension av kravförståelse och detta kan förhindra allvarliga misstag och belysa nödvändiga samband och förändringar. En teknik som används alldeles för lite – eller för stelbent gömt i någons kammare, i ett hemligt filarkiv som bara vissa personer får åtkomst till. Sprid denna teknik!

Tips: Använd SMARTA mål. Googla på SMART goals. Eller fundera på vilka dina klarkriterier är. Beskriv, definiera vad ni menar när ett krav är ”klart” så har du ett mål definierat.
Tips: Arbeta med Domain Driven Design eller Begrepps-/informations-/domänmodellering. Förstå er verksamhet genom modellering. Ta hjälp av duktiga modellerare, kanske finns en ensam arkitekt någonstans hos er som inget hellre vill än att bli inbjuden till teamet och kravställningen? Eller en utvecklare som brinner särskilt för domänförståelse och modellering?

PORSCHE

Hur kan vi arbeta med krav om vi vill skapa en produkt/tjänst som är av motsvarande kvalitet som en Porsche?

Deltagarnas svar:
Smakar det så kostar det!
Sätt rätt förväntningar! Det kanske är ok att det blir en Trabant, bara förväntningarna är satta och kommunicerade så.

Min kommentar: Om vi förväntas skapa de administrativa stödsystemens motsvarighet till en Porsche, eller the BMW of kundtjänstsystem – då behövs det resurser för krav. Vi behöver antagligen flera olika kompetenser – analytiker, arkitekter, ux-designers, exploratory testers.. i teamen. Det räcker inte med en verksamhetsrepresentant på 30%…  Vi behöver också acceptans för att det kostar tid av flera personer i verksamheten såsom affärs-/verksamhetsutvecklare, strateger, domänexperter, personal att delta i användningstest, workshops mm.

OM VI HAR MÅLET ATT GÖRA ALLT DETTA, disciplinerat och ett steg i taget, visst kommer kraven hålla högre kvalitet?

Tack för orden och berätta gärna nästa år på SU42 hur det går med kraven!

Om jag hade trotsat programmet och hållt ett föredrag i stället, hade det jag tagit upp varit just dessa saker. De exempel jag hade med mig handlade om – Tydliga mål, begreppsmodellering, prioritering (backlog), user stories, specification by example och experience mapping – enklare version. Hade inte haft en chans att få med allt – t.ex användningstester och iterationer, så tack till deltagarna för att vi fick med mycket mer än jag hunnit med ensam.

De exempel från verkligheten jag tänkt visa upp finns lite av dem i Prezin. Vid något tillfälle ska jag försöka producera en artikel här om ”exempel från verkligheten på lättrörliga krav”.

Happy development!





Agila Sverige 2011 – 10 år av agile

24 05 2011

Varje gång jag ser programkod på storbildskärm kan jag inte låta bli att bli sugen igen, att göra det riktiga hantverket/konstverket. Nya språk, roliga saker som händer, monader & Scala, funktioner och kvalitetstänk gör att jag undrar ibland hur det skulle vara att prova igen.
Programming, motherfucker
liksom.

Vi andra gör ju bara (?) Managment, asshole

Min stora miss!  Att inte delta i open x-sessionen där man skulle para kund/programmerare och utveckla något snabbt som attan till en marknad.  Var istället en stor behållning att se några vänners blixttal bland annat Jocke Holm i 4D-glasögon som siar en framtid där vi organiserar vår verksamhet utifrån-och-in på riktigt och verksamheten både drar (pull) i utvecklingen och deltar i den (vilket borde vara fallet redan idag, dock en optimistisk framtidsvision fortfarande).

Roland Bäcklin visar hur man mha improvment communities på Ericsson tror jag, arbetar med förbättringar i större skala – där en medarbetare committar sig till ett tillfälligt community som har ett visst mål, när målet är uppnåt upplöses communityt och medarbetaren kan delta i ett nytt om han vill. Förutsättning – 5-10% avsatt arbetstid för att arbeta med och implementera förbättringar i verksamheten. Boktips: Succeeding with Agile – Mike Cohn.

Medarbetare, motarbetare och vårt inrotade språk om att tala om oss själva och andra som ”resurser” var på tapeten. Tack Maria Thelin, Jaybis för den insikten under FishBowl-debatten som var en mycket lyckad start där många fick chansen att med väl valda ord uttrycka sin syn på 10 år av Agile.

Individens egna ansvar, teamets ansvar att bli självorganiserade – tänkte fler än jag själv över. Bland annat Petter Wigle som tycker att alla kodapor bör se sig själva som kodlejon i stället, att i stället för att passivt vänta på att få information – se till att skaffa den själva.

Deltog i intressant Open X om Economy of Gifts, att vi kan om vi vill börja organisera oss enligt devisen ”jag hjälper dig med något så finns det säkert något som du kan hjälpa till med i framtiden”. Komma loss ur budget- redovisnings- och tidrapport-träsket – kan vi själva kanske göra något åt det t.om, genom att bjuda på oss själva och inte be om lov – utan be om ursäkt efteråt? Det fungerar på många ställen. Kopplade dessutom väl till det Björn Elmberg talade om på #Webbdagarna – att gamla sanningar är på väg ut i business, nya på väg in – Sharing economy om jag minns rätt pratade han om.

Den största aha-upplevelsen – #OutdoorFriday med Martin Persson. De arbetar utomhus en dag i veckan, för att stimulera hjärnan, hjärtat och kreativiteten – komma ur våra bunkrar, stänga av laptopen, packa en termos och ett liggunderlag och sitta ute, t.om i Februari. Med mer än märkbart resultat. Inspirerar mig att göra det jag bara tänkt länge – att ta med viktiga intressenter på kreativa möten utomhus. Uppbackat av forskning. Det var inte så svårt upptäckte vi under ett OpenX där vi helt plötsligt befann oss utomhus.

Almut Herzog berättade om att starta upp projektet med ”Inception Deck” – ett sätt att få projektteamet med på tåget, väntar in hennes presentation att länka här.

Hans Brattberg, inspirerar om att ge feedback i smått och stort med hjälp av tekniken Perfection Game där tre frågor ställs: Vad ger du mig för betyg på det här? Vad gillade du med det? Vad skulle jag göra för att uppnå det perfekta betyget?  Fråga att använda i team-retrospektiv: ”Hur skulle en perfekt sprint se ut?”

Fantastiskt många bra & underhållande tal i år, givande fikapauser, riktigt drag på middagen.

Tre saker som lyste igenom:
– Eget ansvar för att uppnå det vi vill
– Det behöver inte vara så svårt
– Testning ur alla perspektiv, exploratory, visualisering, automatisering, bdd’s vara eller inte vara, specflow..

Härligt nördig och samtidigt både mänsklig och väldigt medveten konferens som tidigare. Kvaliteten helt klart högre i år både på tal och open space, även om det var lite tunt med postningar på open x-schemat med tanke på det debattglada klientelet.

Vi saknar nästa generations deltagande – vad går 90-talisterna och funderar över därute på sina campus? Något för nästa år gissar jag. Också tvärfunktionella konferenssamarbeten är nästa naturliga steg, det är många som vill i olika forum.

Kram på er! We are the system, society & change.





Early bird – AYE conference – för ledare

7 04 2011

En konferens att gå på för den som vill utveckla sitt ledarskap, teamförståelse, organisationsmönster, systemtänkande.

Garanterat No Slides!

Early bird ett par veckor till.

Vem vet, vi kanske ses?

Esther Derby, Jerry Weinberg, Johanna Rothman mfl

http://www.ayeconference.com/schedule/

 

 





Webbdag 2 – 31 mars

31 03 2011

Några budskap från Webbdagarna dag 2
(bilden från Björn Elmbergs presentation)

– Internet börjar bli en del av jaget, en 11 månaders bebis kan inte gå men kan öppna ett fönster mot internet – Jocke Jardenberg
– Internet är One Machine – med många fönster.

http://jardenberg.se/b/internet-om-fem-ar-webbdagarna-2011/

– Sharing is caring. Pengar är inte längre allt. – Björn Elmberg

– Powerpoint is finally dead. Prezi ett mycket sympatiskt företag. Gratis programvara för den som delar med sig, betala för den som vill gömma sina grejer. Pratade några ord med Peter Arvai under pausen om hur de arbetar med produktutveckling mellan kontoren i Budapest & San Fransisco. Svaret – de outsourcar inte – de är samma företag, med samma brinannde kultur. Häftigt företag med investering från bl.a TED. Som rekryterar till Budapest, ifall du är intresserad.

Andreas Sjöström, Sogeti, filosoferar med skön stil om mobilappar. Härligt exempel på en sann berättare. Inga slides bara poesi – hur man nu lyckas dikta om appar.

– Creuna fantiserar om att beaming äntligen ska bli verklighet. Några sköna tankar om produktutveckling. Är det bilen vi säljer eller bilen + tjänsten + allt omkring. Nytt sätt att se på bilprodukten. Någon twittrade att Creuna borde pyssla med produktutveckling av bilar, fint exempel de visade upp. En gissning är att de och Björn Elmberg på Cybercom/Saab fann varandra under konferensen.

– och Google.. ja..  citerar Mikael Lindblad ”Efter två bra #webbdagarna är det bestående intrycket att google känns lika sexiga som IBM”

för att inte tala om Microsoft. Ska ni slå er ihop kanske? Varför inte med Nokia.. heh. Går alla stora produktföretag samma väg till slut..?

Magnus Höij, skötte modereringen helt ok och framförallt skönt musikval & snygg setting, nog så viktigt för helheten.

En kaskad av Internet över oss, där vi sitter och blir smågamla och bekväma, behövs helt klart en digital dusch då och då.

Tack för det.

Utdrag av presentationer





Veckans ord: Kontroll

6 06 2010

Har du läget under kontroll? Har du koll?
Koll på vadå? På ungdomarnas nya mönster, på historien? På marknaden eller människans potential?

Den bild som dyker upp i mitt huvud när jag tänker på ordet kontroll är en bild på en gymnast, på en bom, som gör en sådan där fantastisk långsam bakåtvolt, går ner i brygga bakåt och runt. Det tycker jag är att ha koll på läget.

Vad händer då om bommen börjar svänga från sida till sida samtidigt som du gör den där bakåtvolten?
Det lätta svaret är naturligtvis att gymnasten (du) får anpassa tekniken och färdigheten till den nya situationen, den svängande bommen (omvärlden).

Vissa skulle nog försöka stoppa bommen från att svänga och det går antagligen till en viss del. Agilister skulle säga att det är något dåligt. Bättre anpassa sig till den nya rörelsen än förhindra den.

I hur stora vinklar och hur fort ska bommen svänga för att det inte ska vara en fara för hela rummet (hela systemet) och vi helt enkelt MÅSTE försöka hindra den på något sätt för att den inte ska skada någon, i stället för att bara anpassa vår teknik (metoder) och  redskap till att själva kunna röra oss smidigt på bommen?

Erfarenhet av liknande svängningar, känsla och omtanke för omgivningen är det som också där ger det rätta svaret, skulle jag tro. Och då har vi den positiva innebörden av kontroll, för visst finns det en sådan.





Veckans ord: Mål

18 04 2010

Hur många av er därute har varit med om att det finns SMARTA mål i samma stund ni har blivit engagerade i ett projekt? Vore jätteintressant att få del av era erfarenheter och kommentarer.

Med SMART menas (en av flera översättningar):

S – Specifikt
M – Mätbart
A – Accepterat (Agreed)
R – Relevant
T – Tidsanpassat (Timely)

Varför frågar jag? Därför att insikten har slagit mig hur väldigt många utvecklingsprojekt som initieras och investeras i som inte alls har något som liknar SMARTA mål,  utan som enbart baseras på ett behov ”Vi behöver byta ut en gammal teknik..” ”Den här gruppen behöver ett systemverktyg..”, ”vi behöver en ny hemsida..”, ett behov som oftast är högst relevant men som – hur ofta – omvandlas till tydliga och relevanta mål för ett team att jobba mot?

Målet finns där  men gömt i annan information eller diffust uttryckt är min erfarenhet.

Om ett team av bergsklättrare gav sig ut på expedition med tanken att ”vi behöver ett berg att klättra upp på”  i stället för  ”vi ska bestiga Mount Everest den här månaden” – hur många flaggor skulle då sitta på en bergstopp däruppe? T.ex.

Hur viktigt är ett mål egentligen?








Följ

Få meddelanden om nya inlägg via e-post.