Vad är krav?

26 01 2015

Häromdagen hörde jag en presentation av en person som jobbar på ett spelföretag. Han sa att de inte arbetar med krav alls. Vad jag hörde var att de inte har den gamla formen av kravanalytiker som sitter och samlar och specificerar allt de kommit fram till, för att sen föda utvecklare med dessa specifikationer. I stället låter de spelutvecklarna testa och experimentera fram olika varianter tills något känns bra. De har också en relativt stor grupp hängivna spelare (användare) som får pröva spelen tills de identifierar vilka som faktiskt är bra och roliga och då eventuellt släpper de spelen. Han sa att endast en bråkdel av spelen faktiskt når ut i produktion.

De arbetar också mycket med test, förutom användningstesten så automatiserar de test av sådant som bara måste fungera gång på gång, typ login och annat. Dessutom har de fasta regler att förhålla sig till, t.ex från API:er (gränssnitt) med tjänster som de använder, t.ex Facebook, Google mfl. Och det är ju bara att följa de gränssnittsspecarna.

I mitt huvud tänkte jag, men! Ni jobbar ju visst med krav! I alla fall enligt min personliga tolkning av vad krav faktiskt är. Det är bara så att ni jobbar mycket mer modernt och snabbt med kravarbete än vad många andra gör.

Det ni gör när ni experimenterar och släpper lös den kreativa sidan hos utvecklarna, testar med spelare och automatiserar gränssnitt och studerar och programmerar utifrån API-specar är ju också krav!

Fast ”Krav” är ett olyckligt ord. Just här använder jag ”krav” som ett samlingsord för alla tekniker, metoder och arbetsuppgifter som leder till förståelse av vad användarna faktiskt behöver och beslut om vad som ska ut i drift eller inte.

”Krav” för mig kan uttryckas muntligt, skriftligt, som en teckning, en modell, en skiss, en dialog, som ett test, som programkod, en första version av mjukvara. Någon sa att den enda sanna kravspecen är programkoden, och det håller jag med om, även om den kanske inte är så läsbar för alla. Programkoden talar faktiskt om för maskinen vad den ska utföra. Det mesta som inte är programkod är tankar och idéer som uttrycks på mer eller mindre luddiga sätt.

”Krav” är analysarbete. Att göra en prototyp av ett spel, eller en tjänst och att låta testa den samt studera och dra slutsatser av resultatet och förbättra eller förkasta är också analysarbete.

Problemet är att ”Krav” är ett så dåligt ord eftersom det associerar direkt till långa kravspecar.

”Krav” kan i min värld vara t.ex:

– En backlog
– Ett experiment eller en prototyp
– En skiss på en näsduk eller whiteboard
– En begrepps/informationsmodell eller domänmodell (vilket ord man nu föredrar..)
– En användarberättelse (user story eller en hel text om kundens resa genom systemen)
– Ett testscenario
– Feedback från någon
– En vision förmedlad av någon (användare, utvecklare, vd, medarbetare, marknadschef, säljare, kundtjänst…)
– Ett kommunicerat mål
– Regler definierade av någon

Jag vill dumpa ordet ”krav” och det är antagligen det vi måste göra för att komma loss från de långa kravspecarnas och användningsfallens bojor. Fenomenet i sig: att analysera, förstå, testa, undersöka, följa upp, visionera & designa försvinner dock inte för att vi dumpar ordet ”Krav”. Det är fortfarande en nödvändighet för att få något värdefullt ut av den mjukvara vi producerar.

Att hej vilt koda utan mål, mening, vision eller feedback vore hrm.. intressant.. att se resultatet av. Jag tror att den här killen från spelföretaget ville säga att de kodade hej vilt och ”kravlöst”, men faktum var att de verkar väldigt strukturerade i sin metod att experimentera och samla in feedback, förstå spelarna och jobba med visioner.

Kravspecifikationen då? Har den spelat ut sin roll?
Ordet i sig, ”kravspecifikation”, måste vi nog också göra oss av med för att bli av med dokument som ingen varken läser eller förstår, förutom den som skrev den.

Specifikationer och dokumentation av olika slag däremot kommer vi fortsätta behöva. I olika grad beroende på hur många beroenden vi har och hur stor vår affär eller verksamhet är. Att publicera ett API/webservice för någon internt eller externt att använda utan någon form av dokumentation blir… svårt för de som ska använda den. Att förvänta sig att mjukvara hos myndigheter, banker eller andra regulerade verksamheter ska anpassa sig till lagstiftning utan någon dokumentation av lagarna blir också.. svårt. Det är också specar.

Att gång på gång undersöka och muntligt sprida affärs- och verksamhetsregler i en stor organisation blir också… svårt. Lyckas man dokumentera dessa regler på ett läsbart och hållbart sätt så kanske man inte behöver så många fler specifikationer.

Problemet med specifikationer är inte att de finns, utan att de är för omfattande, att de snabbt blir inaktuella och beskriver design och andra delar som konstant förändras och att de är svårtillgängliga.

Utmaningen är att specificera tillräckligt lite.

I spelföretagets fall så höll de sina specifikationer i form av automatiserade testfall. Genom att titta i de specarna så förstår man hur spelen fungerar.

Jag har sett verksamheter där man faktiskt har en lätt tillgänglig källa över domänmodellen (informationsmodellen) som uppdateras med exakt vilka koder som betyder vad och vilka regler som gäller.

Det går.

Men kanske går det inte att prata om ”krav” och ”specifikationer” längre. Det för med sig en ryggsäck som vi inte vill ha.

Min ambition är att jobba med både krav och specifikationer utan att prata om dem.

Annonser




Agilt, Iterativ & Inkrementell!

22 03 2013

Jag fick den här frågan från en kompis & student:

”Agile, Iterativ & Inkremell! Vi har pratat lite om det jag & några från klassen, och alla typ blandar ihop allt!
Vissa säger att tex Scrum är agilt, andra säger att det är ngt annat bla bla, jätte förvirrande :b det ända jag har
koll på är att RUP iaf är iterativt haha.”

Ska jag göra ett försök att förklara begreppen lite kort?  Jag gör ett försök..

Agile
Agile är ett sätt att tänka. Det är inte ett verktyg. Det är inte en metod. Det finns metoder som Scrum, Kanban, Lean Software Development som kan hjälpa dig att komma framåt. Du kan vara agil utan att använda någon metod alls. Du kan också vara agil med en gammaldags metod som RUP, eller vilken som helst annars. Det handlar om ditt sätt att se på projekt som en icke-förutsägbar händelse, och ditt sätt att se på verkligt samarbete (arbeta tillsammans), ständigt omfamna förändringar i omgivningen och hos dina kunder, kontinuerligt förbättra hur du och ditt team arbetar och samarbetar.

Det går att jobba enligt Scrum och inte alls vara agil, även om Scrum med sina regler om att inom en kort tid leverera fungerande programvara ofta hjälper till på vägen att bli agil.

Den här blog posten beskriver vad agile inte är  – med referenser till principerna i det Agila manifestet, som handlar om principer – inte verktyg & metoder.   http://www.tommycode.se/2012/12/what-is-agile.html?m=1

En gång delade jag några tankar om vad agilt är, på stapplande engelska..

http://blog.smartbear.com/software-quality/bid/224669/Ulrika-Park-Becoming-Agile

Iterativ

Iteration är ett annat ord för upprepning. Inom matematiken och i programmering handlar detta om att en funktion eller process åstadkommer något genom att upprepa tills ett önskat resultat uppnåtts.  (wikipedia nerkortat)

Ett annat ord är loop. Tänk dig ett flygplan som gör en loop. Sedan gör flygplanet samma loop igen. Det är den 2:a iterationen. Bilden nedan är ett gäng iterationer av samma flygplan.

Smoke-Loops-Flight-demonstration-Circle-Sky-300x187

Inom systemutveckling är det att utveckla samma funktion flera gånger tills den är tillräckligt bra.
Det kan också vara att genomföra samma projekt flera gånger tills det är tillräckligt bra att släppa till kund.

Säg att du skriver en uppsats om ett ämne. Du skriver en version rakt på tills den är klar. Sedan börjar du om och skriver samma uppsats en gång till. Du tar med dig saker från första versionen, kanske många meningar, men lägger till saker, tar bort saker, ändrar ord. Den andra versionen är andra iterationen. Skriver du den en tredje gång, har du gjort 3 iterationer.

Detta är något som glömts bort i många genomföranden av s.k agile.

Jag har varit med i ett par projekt där vi verkligen jobbade iterativt. Det vill säga – vi valde en funktion att bygga. Definierade vilka krav & testfall som skulle passera för att funktionen skulle kunna fungera någotsånär. Vi visade upp funktionen för beställaren/kravställaren. Sedan byggde vi samma funktion en gång till – byggde ut, snyggade till, förbättrade både bakom ytan (programkoden) och framför ytan (användargränsnittet). Ibland en tredje och fjärde gång.

Att jobba iterativt är att ALLTID bygga samma funktion minst 2 iterationer – 2 gånger.

Faktiskt så påstod även någon att även den förhatliga Vattenfallsmetoden var iterativ från början. Meningen var att man skulle driva sitt projekt enligt Krav – design – implementation – test – integration – leverans och sedan köra samma projekt en gång till och då göra det rätt och snyggt. Kanske borde kolla upp källorna på detta, men har för mig att jag sett bilder på en loop – där man går tillbaka till början direkt efter slutet.

Idén med RUP var också att vara iterativ. Dvs definiera krav (use cases), design, progammera, testa under en fas, sedan gör samma sak en gång till. Tyvärr dränktes den idén i för mycket annan information, regler & dokumentation så att jag har sett få RUP-projekt som faktiskt jobbat iterativt, även om jag har hört talas om dem som faktiskt gjort det.

Scrum är enklare och studerar man metoden noga kan man se att tanken är att iterera, loopa, över funktioner. Det har tyvärr också ofta dränkts i idén att man bara ska leverera snabbt snabbt. Att leverera snabbt är inte huvudfokus i principerna i det agila manifestet. Ingenstans sägs att man ska leverera snabbt. Men man ska prioritera fungerande programvara framför pappersprodukter (oändliga dokument som inte går att använda).

En ”sprint” i Scrum är INTE en iteration. En sprint är rätt och slätt en time-box på t.ex 2 veckor (aldrig mer än 4). Efter 2 veckor ska teamet visa upp resultatet för sina intressenter. Och bara fungerande programvara. Dokumentation, tankar, idéer och planer är oväsentligt. Huruvida man faktiskt tar samma funktion och itererar över den i nästa sprint, sägs inget om i Scrum, även om metoden kan tvinga fram det beteendet. Man hinner inte på 2 veckor göra så mycket ”lull lull”. Man måste ofta gå tillbaka till samma funktion nästa eller senare sprintar för att göra den värdig att sälja/använda.

Man kan säga att en sprint i Scrum kan vara en projekt-iteration. Dvs man genomför samma projekt i många iterationer, tills det är tillräckligt bra. Första iterationen så har man gjort projektet (krav, test, utveckling, integration, leveransfärdigt) fast det kanske inte är tillräckligt bra – än, så man gör en iteration till över samma projekt så blir resultatet bättre.

Jag har inte sett många Scrum-projekt som sett på sprintar på det sättet. Även om tanken var att en sprint – skulle vara en iteration av ett projekt.

Sprint och iteration är alltså (oftast) två helt olika saker.

Du kan bygga en funktion under en sprint, och sen strunta i att bygga/förbättra den igen. Då har du inte itererat över den funktionen. Du har bara jobbat i en time-box, en sprint.

Inkrementell

”An increment is an increase of some amount, either fixed or variable. For example one’s salary may have a fixed annual increment of x%” (redigerat från wikipedia).   Om din lön ökar med en fast % varje år, så ökar den i inkrement.

Inkrement är alltså en utökning.

Jag tänker på en bakelse. Säg att du har en liten rund bit sockerkaka och fyller den med bär. Sedan tittar du på den och tycker den förtjänar lite grädde runtom. Du lägger till grädde. Det är ett inkrement. Bakelsen var redan klar att äta och njuta av med sockerkakan och bär, men med inkrementet grädde så har du utökat bakelsen till en lite större upplevelse. Sedan tittar du på bakelsen igen och bestämmer dig för att lägga på riven choklad runtom. Ytterligare en utökning, ett inkrement. Den var redan färdig som den var, men chokladen gav det lilla extra.  Som ett sista inkrement lägger du på hyvlad mandel.

Du hade en färdig bakelse från början med sockerkaka & bär. Bara sockerkakan hade  inte varit tillräckligt, det hade bara varit en sockerkaka. Efter den första inkrementet, utökade du den stegvis, inkrementellt, till en större finare bakelse.

Samma gäller funktioner i systemutveckling. Du bygger en funktion som är färdig som den är. Den går att använda. Sedan utökar du den med (små) inkrement, ett extra värde, ett extra inmatningsfält, extra information.

Exempel
Ett exempel på inkrementell funktionsutveckling var när vi skulle presentera kursinformation i ett utbildningssystem för studenter.

Det första inkrementet bestod bara i att visa upp kurskoden och namnet på kursen. Fullt fungerande.
Det andra inkrementet bestod i att visa upp ytterligare information, såsom kort beskrivning, hur många poäng kursen var, vilken institution som gav kursen.
Tredje inkrementet var att visa upp kurstiteln på engelska och vilka prov som ingick.
Etc.

Vid första inkrementet kunde vi inte släppa funktionen till studenter, den var för fattig på information. Däremot kunde vi visa upp den för vår beställare/kravställare/produktägare, så att han kunde se att det fungerar.
Efter 3:e inkrementet var funktionen redo att släppas till studenter – slutanvändaren.

Skillnaden mellan iteration och inkrement??

Inte helt lätt att avgöra. När man stegvis utökar (increment) – en färdig funktion, så gör man det genom att iterera – alltså återkomma till samma funktion (bakelse) flera gånger.

Inkrement = utökning
Iteration = upprepning

Solklart?

Skulle vara jätteintressant  om den som rättar era tentor vill kommentera den här artikeln, kanske har hen ett ännu bättre svar på skillnaden mellan iteration & inkrement?

Kram

Ulrika





”För att det är tradition…”

25 12 2012

Jag har alltid blivit så oerhört provocerad av detta påstående. Varför har vi julskinka på bordet? ”För det är tradition”, har jag mer än en gång hört genom åren.

Varför inte bara svara ”För att det är gott”, ”För att det ser fint ut”, ”För att det är roligt att griljera” eller någon annan, vilken som helst orsak.

Jag blir så oerhört provocerad av  kommentaren”För att det är tradition…” – oavsett om det gäller julskinka, åka till släkten, köpa julklappar eller något helt annat som inte alls har att göra med julen.

Det som gör mig så provocerad är att svaret är så.. hjärndött. Så total brist på reflektion, vilja, engagemang, tanke. Brist på respekt för sin egen och andras fattningsförmåga. Den mer eller mindre bildade person som gör något, och hävdar traditionen som orsak är inte ett uns bättre än alla dessa som genom historien, och fortfarande, hänvisar till ”att Bibeln säger så” för att förklara sina handlingar, åsikter eller yttranden.

Med argumentet ”att det står i Biblen” eller ”det är tradition” eller ”vi har alltid gjort så” kan man bortförklara de mest vidriga, eller bara korkade beteenden.

Jag tror att det som gör mig så provocerad är att jag vet att ingen häromkring är så oförstående att hen inte kan hitta en annan anledning till julskinkan än just traditionen. Och att jag ser personer göra saker som de verkligen inte gillar ”för att det är tradition”, särskilt runt jul. Orsaken ”för jag försöker lära mig en ny kultur” eller ”jag vill verkligen göra faster Stina glad och åka 100 mil i snöstorm med 4 snoriga ungar” är ju helt förståeliga och antagligen genomtänkta. ”För att det är tradition..” är det inte.

Att ha julskinka på bordet för att det är tradition, utan att ens kanske gilla det, är en dumhet som ingen behöver göra.  Om orsaken är ”för att faster Stina gillar det” är det ju en helt annan grej, självklart ska faster Stina få julskinka. Bra orsak!  Men ”för att det är tradition… ” tar på något sätt bort all intelligens hos personen som säger det.

Ungefär som att vi i säkert 10 års tid efter att någon person sa att det var konstigt att kalla ”chokladbollar” för ”negerbollar” hörde alldeles för många personer, även i film, som hävdade att ”vadå, vi har ju alltid kallat det så”. Samma totala brist på tanke, av människor som faktiskt gått i skolan.  ”Ja, men då så, då fortsätter vi kalla det för det då… ”

”I Bibeln står att homosexualitet är fel”. ”Möjligtvis, men tycker verkligen alla som tror på Gud det på riktigt..?”

Provocerande när hyfsat bildat folk inte använder sin tankeförmåga.

I kontorssammanhang kan man höra samma tema. ”Varför måste du fråga chefen om du får göra den här förstudien som DU anser rätt?” ”För att vi har alltid gjort på det här sättet”.

Kan du förklara varför?

Nu tror jag naturligtvis inte att de som läser denna text skulle få för sig att referera till Bibeln som orsak till dumma uppfattningar eller beteenden, eller ens ”det brukar vara så”. Säkerligen har du dock mer än en gång hört orsaksbeskrivning på jobbet vara ”för att det brukar va så”. Och i privata sammanhang hört annars kloka starka individer som gör märkliga saker runt julen ”för att det är tradition”.

Jag tror att när vi hör ”traditionen” eller ”det har alltid varit så” som argument till att göra saker man inte vill på jobbet eller på julen, så kan vi ändra detta genom att bara uppmnuntra den personen till att förklara sig. ”Ja, men hur skulle DU nu vilja göra?” ”Vad hindrar dig..” och inte nöja dig med ”traditionen” som svar.

En annan tradition som provocerar mig att hänvisa till är ”traditionell projektledning” eller ”traditionella projektverktyg”. Vadå traditionella? Provokationen består i att genom att hänvisa till traditionen så utesluts jag och alla andra som verkar idag från att bidra med kunskap. Även tankeförmågan hos den som yttrar ”att traditionellt har vi gjort så” utesluts. Om samma person i stället berättar vad som är bra med en viss metod eller modell, kommer vi andra säkert förstå och komma med på tåget.

Genom att hänvisa till traditionen anses man inte behöva förklara sig.

Traditionen har inget egenvärde. Punkt. Däremot kan vanor, sysselsättningar, metoder eller modeller ha ett stort värde oavsett hur gamla eller nya de är. Traditionen har inget med ålder att göra.

Brist på reflektion är brist på respekt för sig själv och sin omgivning. Och få saker är så skadligt för mänskligheten som brist på respekt, visst?

Vad vill DU göra under julhelgen? Och vad vill DU göra när du kommer tillbaka till jobbet?

God Föränderlig Jul och Nytt kunskapsutvecklande År!





Att vara projektledare

27 08 2012

Jag fick idag en fråga ”kan du berätta lite vad du gjort som projektledare?” av en person som fått ett erbjudande att prova-på att byta roll.

Jag fick tänka till lite, vad är det egentligen jag gjort i projektledar- och projektledarliknande roller (som t.ex produktägare, scrummaster) under de ca 10 år som jag verkat i rollen.

Jag måste vara ärlig och svarade så här:

I korthet har det mesta jobbet som projektledare handlat om det sociala – att bli kompis med alla – och då menar jag alla, inklusive den där jobbiga otrevliga typen som jag kanske inte alls alltid haft lust att bli kompis med.

Och dessutom få dessa alla att bli kompis med varandra. Som en jäkla kamratstödjare för vuxna helt enkelt. 😉

Andra halvan har handlat om att om att övertyga ledningsgrupper och chefer om att tro på vårt projekt och ge oss de medel (miljoner ibland, lokaler, utrustning etc) till just vårt projekt som vi behöver. Som en jäkla politiker och försäljare helt enkelt. 😉

Och det värsta är att det är sant.

Planering och organisation är typ 1% av jobbet som projektledare.

Vilket när man läser kursprogram och annat kan låta som att det är de 1%-en som det handlar om att vara projektledare.

Vi pratade om detta och jag kom på att ingen talade om detta för mig när jag gav mig in på banan.

Jag kunde också lägga till att, jo som projektledare är man den som får ta smällarna och all skit när saker går dåligt, och när det går bra är det teamet som får beröm. Det är du som står där när det stormar, det är du som får vara försvararsadvokaten när det är svårt och det är dig de hotar att halshugga när det krisar.

”Låter inte så lockande” säger hon.

Om någon sagt detta för 10 år sedan, hade jag ändå tackat ja till det erbjudande jag då fick?

Jag vet inte.

Det tog mig 5 år att börja tycka det var roligt på riktigt att vara projektledare – eller då blev jag ScrumMaster – kanske hade något samband? Eller var det bara så att det var då jag började få tillräcklig erfarenhet för att börja bli bekväm med rollen?

Det tog mig ytterligare 5 år att ha tagit mig igenom strider, stått i blåsten, blivit hotad, kramad, peppad och stressad innan jag började förstå vad teamledarrollen egentligen handlar om. Jag påstår inte att jag bemästrar den, mycket är kvar att lära. Numera är det väldigt roligt och spännande att gå till jobbet och faca de där herrarna i höga hattar som har miljonerna, eller se sitt team växa och nå framgångar.

Det har tagit tid, och jag vet inte om någon annan projektledare skulle säga annorlunda?

Jag har sett så många pressade, stressade, överarbetade, ledsna och oförstådda projektledare runt om.

Samtidigt verkar vi vara ett ordentligt gäng som bara inte kan hålla oss ifrån den här organisation/metod/team/coachande rollen, som bara måste se om det går att komma i mål den här gången och hur roligt man faktiskt kan ha på vägen. Att få möta team efter team av fantastiska människor som älskar att utveckla system, produkter och tjänster i någon form.

Jag skulle inte vilja vara utan det.

Skulle du?





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?