Kategorier
Projektledardrama - Film

Animerat projektledardrama i flera delar – Del 2

Vi funderar ständigt på hur vår blogg om projektledning kan göras mer levande och rolig för dig som läsare. Därför testar vi nu ett nytt grepp med animerad film! Spring ner till kiosken och köp en popcorn och en mellanläsk och följ dramat om hur andra kan ha det i sin projektvardag.

Del 2 – Dramat i korthet

Anna arbetar på ett medelstort företag. Hon är projektledare för en av företagets viktigaste utställningar, där man ska visa upp alla sina produkter. Till sin hjälp har hon bl a Göran som arbetat i projektet sedan starten. Nu har det blivit dags för ett avstämningsmöte med chefen Nisse. Och det verkar som att det är mer och mer som ska göras i projektet…

Det här avsnittet handlar bl a om att hantera ändringar i projekt. Ett ämne som vi inom kort kommer att återkomma till här på bloggen.
Kommentera gärna nedan! Eller skicka oss ett mail med vad du tycker om filmen.

Kategorier
Projektledardrama - Film

Animerat projektledardrama i flera delar – Del 1

Vi funderar ständigt på hur vår blogg om projektledning kan göras mer levande och rolig för dig som läsare. Därför testar vi nu ett nytt grepp med animerad film! Spring ner till kiosken och köp en popcorn och en mellanläsk och följ dramat om hur andra kan ha det i sin projektvardag.

Dramat i korthet

Anna arbetar på ett medelstort företag. Hon är projektledare för en av företagets viktigaste utställningar, där man ska visa upp alla sina produkter. Till sin hjälp har hon bl a Göran som arbetat i projektet sedan starten. Göran är erkänt skicklig på sitt arbete, men tycker kanske inte alltid om att någon annan styr över hans arbete….. Och så har vi chefen. Chefen som Anna ibland tycker är lite svår att få grepp på när det gäller projekt…

Kommentera gärna nedan! Eller skicka oss ett mail med vad du tycker om filmen.

Kategorier
Projektmodell och Verktyg

Tips på gratis verktyg för att göra enkäter på webben

I många olika projektsituationer uppstår behov av att snabbt få in synpunkter från t ex intressenter, expertis eller slutanvändare. Utbudet av tjänster och verktyg på webben för att göra mer eller mindre sofistikerade enkäter och undersökningar är stort. Ett av alla verktyg är gratisverktyget Google docs, som snabbt och effektivt låter dig skapa, skicka ut och följa upp enkäter. Och framförallt, det är mycket enkelt att lära sig.

Verktyget har funnits en tid och utökas hela tiden med nya funktioner och mallar.

Vad kan tjänsten användas till?

Det finns såklart hur många exempel som helst när tjänsten kan göra nytta i projektsammanhang. Exempel: Ställa frågor till en användargrupp vad de prioriterar för olika funktioner, utvärdera ett seminarium eller en workshop, följa upp identifierade fel och brister i en produkt etc.

Hur fungerar tjänsten?

Tjänsten är fantastiskt enkel att använda. Först måste du skaffa ett Google konto. När du väl har det är det bara att logga in och gå till Google docs/Dokument. Sedan väljer du att skapa en ny ”Form”. Resten är nästan självinstruerande. Du kan välja bland massor av olika typer av mallar för att få din enkät/undersökning att se lite roligare ut.  Frågorna i undersökningen kan vara av olika typ, t ex kryssrutor eller nedrullningsbara boxar med fördefinierade svar.

När du är nöjd med din undersökning så kopierar du bara länken till din undersökning som visas längst ned på skärmen. Klistra in länken i ett mail och skicka den till de som ska fylla i undersökningen. Sedan är det bara att luta sig tillbaka. Resultatet av undersökningen visas i snygga och prydliga grafer eller som en lista.

Om du behöver mer hjälp i hur du använder enkätverktyget är det bara att googla på ”enkät google docs”.

Vi använder själva tjänsten i olika sammanhang och är mycket imponerade av hur enkelt och smidigt det fungerar.

Vad har du för erfarenheter av enkäter på webben allmänt eller om just Google docs? Eller har du kanske några smarta tips på funktioner i verktyget? Kommentera nedan!

Kategorier
Strategier för projekt

Hur hänger livscykelperspektiv och kravhantering egentligen ihop?

Effektivt kravarbete inom IT-utveckling och andra typer av projekt blir allt viktigare. Kravarbetet är dessutom något som berör hela organisationen. Tiden när kravhantering endast var något för IT-avdelningen är sedan länge förbi.

Som projektledare förutsätts du ofta ha en förståelse för hur kravhantering fungerar i de inledande faserna i projekt. Men för den som inte dagligen arbetar med krav kan detta stora och komplexa ämne vara svårt att tränga igenom. En bra början och introduktion till området kan därför vara att få klart för sig vad som menas de olika kravtyperna – funktionella och icke-funktionella krav.

Ett annat begrepp som används flitigt i det här sammanghanget är begreppet livscykelperspektiv. Det här inlägget handlar om att försöka förklara vad funktionella och icke-funktionella krav är för något och hur de hänger ihop med begreppet livscykelperspektiv.

Livscykelperspektiv (life cycle management)

En normal livslängd för ett IT-system är kanske 5–10 år. Under den tidsperioden kommer organisationens processer och behov att utvecklas och förändras. Det gör att systemet successivt måste anpassas och utvecklas för att kunna hantera de förändringar som sker. Men att ändra, bygga på och vidareutveckla system kan vara både problematiskt och kostsamt. Därför bör man ta höjd även för de krav som inte finns initialt, men som kan komma att bli verklighet i takt med att förändringar sker inom och utanför organisationen.

Ett väl utfört kravarbete beaktar och omfattar systemets hela tilltänkta livscykel, dvs från den första lanseringen av systemet tills systemet ska skrotas. Ett arbete som kräver extra tankemöda, resurser och tid initialt. En konsekvens av det är kanske att tidpunkten för en första lansering av systemet måste skjutas något på till förmån för den tid som det extra kravarbetet tar.

Eftersom många projekt genomförs under tidspress med krav från ledningen på en snabb time to market så ägnas ofta för lite tid åt kravarbetet. Fokus läggs enbart på de krav som finns på den första versionen av systemet. Hela idén med att tänka på ett systems hela livscykel redan från början är att det i slutändan kommer att löna sig, något som ofta visar sig vara en sanning.

Vilka olika typer av krav ska då hanteras med tanke på ett systems livscykel?

Vad menas då med funktionella och icke-funktionella krav? Här kommer en kort beskrivning.

Funktionella krav

En vanlig definition av funktionella krav vid systemutveckling är: ”De tjänster och funktioner som systemet ska tillhandahålla användaren”. Exempel på funktionella krav på ett system är möjlighet att registrera en betalning, kunna skriva ut en faktura, beräkna ett resultat etc. Funktionella krav är oftast de mest uppenbara och därför något som automatiskt får stort fokus i de inledande projektfaserna.

Icke-funktionella krav

Icke-funktionella krav kan ses som egenskaper på ett system utöver förväntad funktionalitet. En vanlig definition är: ”Med icke-funktionella krav avses egenskaper som systemet bör uppfylla, men som inte kan karaktäriseras som tjänster, såsom tillförlitlighet, användbarhet, effektivitet, kapacitet och säljbarhet”.

Tycker du fortfarande inte att det är tydligt vad icke-funktionella krav är? Här följer 13 olika typer av vanliga icke-funktionella krav med en kort förklaring av varje krav:

1. Underhållsbarhet avser frågor som har med ett systems förvaltning att göra, såsom korrigering av fel, förbättring av prestanda, anpassning till ny IT-utrustning och konfigurationshantering. Underhållsbarhet kan åstadkommas på olika sättt ex genom att upprätta en god dokumentation av systemet och dess handhavande. Det är också viktigt att bygga systemet i så fristående komponenter som möjligt, för att få kontroll över sidoeffekter och följdverkningar av uppdateringar.

2. Flexibilitet avser möjligheter att ändra och bygga ut system. Vanligtvis uppnås detta genom att systemet struktureras i komponenter som kan bytas ut och ändras.

3. Utrustningsoberoende avser möjlighet att flytta programvara mellan olika datorer och plattformar. Detta är viktigt exempelvis då organisationer utvecklas, decentraliseras eller startar samarbete med andra organisationer, vilket ofta medför att olika typer av plattformar måste kunna samverka. Utrustningsoberoende kan åstadkommas på olika sätt, exempelvis genom att ett system struktureras så att bearbetning av affärslogik och bearbetning som är relaterad till teknik separeras.

4. Återanvändbarhet avser möjlighet att i framtida projekt kunna återanvända analysresultat, design, system, program eller delar av program, för att uppnå kostnadsbesparingar vid framtida utveckling. Dessutom kan man oftast lita på att beprövade komponenter är korrekta. Återanvändbarhet kan åstadkommas på olika sätt, exempelvis genom att bygga systemet i komponenter och begränsa samband mellan komponenterna.

5. Interoperabilitet avser möjlighet för system att kommunicera med andra system eller annan utrustning. Det kan bl a åstadkommas genom att vanligt förekommande tekniker och utrustning utnyttjas och att man ansluter sig till gällande standarder av olika slag. Vidare bör man sträva efter en öppen design.

6. Att följa vedertagna standards är viktigt inför utvidgningar och samarbete med andra system.

7. Testbarhet avser möjlighet att kunna testa ett system. Att testa ett konventionellt administrativt system är oftast relativt enkelt, men att testa realtidsförlopp och samverkan och tidsmässig synkronisering mellan olika system och annan utrustning kan ibland vara svårare. Ett sätt att åstadkomma testbarhet är att frilägga kritiska delar och att skapa tydliga kontrollstrukturer i ett system.

8. Korrekthet avser huruvida ett system uppfyller specifikationen och tillfredsställer användarens önskemål.

9. Tillförlitlighet avser huruvida ett system utför operationerna på rätt sätt och att data är korrekta. Detta kan ha olika betydelse i olika typer av system. I ett datorspel är det inte av avgörande betydelse, men i ett säkerhetskritiskt system, t ex ett system som övervakar och styr flygtrafik, är det av största betydelse. Det kan exempelvis åstadkommas genom att olika typer av avstämningar och kontroller införs.

10. Effektivitet avser prestanda och ett systems förmåga att utnyttja IT-utrustningens möjligheter. Prestanda kan avse lagringsvolymer, bearbetningshastigheter och kommunikationshastigheter.

11. Säkerhet avser skydd mot otillbörlig åtkomst av program och data. Detta uppnås genom olika typer av tekniska skydd, exempelvis brandväggar, men en medveten och utbildad personal är också viktigt i detta sammanhang.

12. Användbarhet avser exempelvis enkelhet att använda ett system och enkelhet för användaren att lära sig detsamma. Det kan bl a åstadkommas genom att prototyper skapas, som de blivande användarna kan testa och pröva i utvecklingsprocessen.

13. Tillgänglighet är viktigt i exempelvis övervakningssystem och kan bl.a. åstadkommas genom att systemet eller delar därav dubbleras.

Av de 13 kravtyperna ovan har de sex första direkt att göra med framtiden, dvs de bör ses i ett livscykelperspektiv. Återigen kan sägas att det vid nyutveckling kostar lite mer och tar lite längre tid om sådana krav skall tänkas ut och beaktas, men att det ofta lönar sig i långa loppet.

De övriga sju icke-funktionella kraven kan också vara viktiga att beakta i ett livscykelperspektiv. Det kan gälla t ex kravet på användbarhet. Vid användarens bristande medverkan i kravprocessen, kan brister i systemet uppstå, t ex att viktiga affärshändelser inte hanteras på ett riktigt sätt eller att systemet är för krångligt utformat.

En siffra som nämns inom IT är att då ett system är nyutvecklat har man sett endast 25% av livscykelkostnaden. Övriga 75% uppstår under systemets livslängd och då gäller det att man tagit höjd för detta ifrån början. Inte sällan inträffar det att ett system måste skrotas redan efter något år därför att det är så oflexibelt byggt att det är mer lönsamt att börja om från början för att kunna möta de nya kraven.

Fokus i det här inlägget har varit på IT-utveckling. Men du som inte arbetar med IT utan i andra typer av projekt kan troligen också se fördelarna med att beakta både funktionella och icke-funktionella krav och att i möjligaste mån försöka blicka över hela livscykeln så tidigt som möjligt i projektet. Se även våra tips nedan som avser kravarbetet generellt.

Här kommer några tips för ett effektivt kravarbete:
  • Medvetandegör betydelsen av professionellt kravarbete och etablera en process för att ta fram och dokumentera krav
  • Låt kravarbetet få ta tid, det lönar sig på lång sikt
  • Engagera så många som möjligt i kravarbetet, inte minst med tanke på livscykelperspektivet. Engagera även de som har inblick i kommande planer som påverkar organisationens framtid
  • Se till att systemet passar in i en föränderlig framtid, avseende t ex affärsutvecklingsplaner, val av tekniska plattformar, leverantörssamarbeten och strategier för systemutveckling
Kategorier
Strategier för projekt

Vässa projekten med lateralt tänkande

Kraven på att projekten levererar rätt lösning och utförs på rätt sätt blir allt viktigare i takt med mer slimmade organisationer, snabbare krav på time-to-market och jakten på effektivitet. Det här blogginlägget beskriver en av flera metoder för att möta dessa ökade krav.

Ett projekt ses normalt som ett engångsarbete som genomförs av en tillfällig projektorganisation. Syftet kan vara att skapa något nytt eller förbättra något befintligt. Då en uppgift ska lösas i projektform finns det åtminstone tre strategiska frågor att ta ställning till:

1. Att lösa rätt problem eller behov
2. Att finna den bästa lösningen
3. Att genomföra lösningen på bästa sätt

De två första frågorna handlar mycket om kännedom om verksamheten och förmåga till kreativitet. De bör behandlas i samband med ett projekts initiering eller i en förstudie, dvs innan projektet startar. Den tredje frågan kan behandlas både i en förstudie och i projektets inledning, planeringsfasen.

Flera studier visar att missnöje med projektets resultat huvudsakligen förklaras av brister i beställningen, vilket berör de två första frågorna. Projektet var inte helt rätt tänkt från början.

Edward de Bono

Edward de Bono, född 1933 på Malta, är en läkare och författare som förknippas med gruppers effektivitet och med begreppet kreativitet, som han menar att alla kan lära sig. Hans tankar och metoder är framför allt tillämpliga i de två första momenten, dvs för att precisera problemet och för att finna den bästa lösningen.

De Bono menar att det vid problemlösning och tänkande i grupp finns tre vanliga problem

Vi reagerar ofta känslomässigt i stället för att tänka logiskt. Känslor är inte fel, men de ska användas på rätt ställe.

Om gruppen saknar strategier för tänkandet, blir den lätt paralyserad.

Brist på strategi för tänkandet och processen skapar förvirring i gruppen. Gruppen talar ofta om olika saker samtidigt, har olika perspektiv och kan befinna sig på olika detaljnivåer samtidigt.

Två av de Bonos metoder adresserar just dessa problem: Lateralt tänkande (The Use of Lateral Thinking, 1967) och Sex tänkarhattar (Six Thinking Hats®, 1985). Metoderna har fått stor internationell spridning.

Lateralt tänkande

De Bonos laterala tänkande är en metod för att stimulera skapandet av nya och gärna okonventionella lösningar på ett problem. Metoden används för det första momentet ovan, nämligen att definiera problemet och finna en lösning. Det går att t ex tänka tvärtemot, byta perspektiv, pröva nya kombinationer och hämta lösningar och idéer från helt andra områden. Det här är något som många projekt skulle må bra av. Fruktbart kan också vara att bemanna problemlösningsgruppen på ett okonventionellt sätt, t ex genom att ta med biologer och marknadsförar vid teknisk problemlösning. Metoden kan liknas vid brainstorming där det inte i första hand bedöms vad som är bra och realistiskt. Lateralt tänkande syftar till att finna en lösning.

Varför är lateralt tänkande användbart i projekt?

Lateralt tänkande passar inom flera områden, inte minst i dagens projektklimat. Idag ökar kraven på projekten genom att chefer och beställare ofta överlåter till projekten att lösa sin uppgift på ett kreativt, nytänkande och värdeskapande sätt. Projektledaren får dessutom ofta sin beställning iform av en relativt ofullständig beskrivning av vad som ska göras. Då kan projektledaren använda lateralt tänkande som ett bra verktyg.

Ett exempel från högskolevärlden är läraren som för att spara tid, lät sina studenter ta hem och rätta sina egna tentor. Det kunde göras med hjälp av en uttömmande och pedagogisk rättningsmall som studenterna fick med sig hem. Före utlämnandet tog läraren en kopia av tentan. Vinsten blev för studenten ett extra bra förståelse- och inlärningstillfälle och för läraren avsevärd reducering av rättningstiden, då endast en snabb koll behövde göras av varje tenta.

Sex tänkarhattar

De Bonos metod sex tänkarhattar (Six Thinking Hats®) innebär att en grupp tillsammans analyserar och bedömer en lösning systematiskt ur sex olika perspektiv, ett perspektiv i taget. Varje perspektiv symboliseras av en färgad hatt och tanken är att alla i gruppen samtidigt ikläder sig en hatt av samma färg.

De Bonos sex tänkarhattar

Vit hatt representerar objektiva fakta och information, ingen spekulation tillåts

Röd hatt representerar den emotionella aspekten, känslor och intuition, kräver ingen motivering

Svart hatt representerar det negativa och söker risker, problem, svagheter och hot som motiveras logiskt

Gul hatt representerar fördelar, styrkor och möjligheter som motiveras logiskt

Grön hatt representerar det kreativa, och används för alternativ och nytänkande

Blå hatt representerar processen, vad gruppen bör fokusera på och kanske nödvändiga förändringar i gruppens sammansättning

Med hjälp av hattarna uppnås bl a följande fördelar
  • Strukturering av tänkandet
  • Allas deltagande stimuleras
  • Fokusering på samma sak samtidigt i gruppen
  • Kreativiteten i gruppen stimuleras och ökas
  • Kommunikationen i gruppen underlättas
  • Underlättande och effektivisering av beslutsfattande

Låt oss spinna vidare på exemplet ovan, där det laterala tänkandet kring effektiv tentamensrättning resulterade i det sensationella lösningsförslaget att studenten rättar sin egen tenta. Lösningen analyseras nu med hjälp av de sex hattarna i tur och ordning.

Nedan visas exempel på frågeställningar som kan komma upp

Vit hatt (information och fakta). Hur många tentor handlar det om per år? Hur många lärartimmar läggs ner på rättning per år? Vilka typer av tentor rör det sig om – korta faktasvar eller essay-svar?

Röd hatt (intuition och känslor). Verkar modernt och bra! Kanske orättvisa missar i rättningen kan komma att göras?

Svart hatt (problem m.m) Alla typer av tentor passar inte för detta. Alla lärare kanske inte gillar detta. Studenterna kan komma att kräva detta på alla kurser. Går det att skapa heltäckande rättningsmallar? Är det rättssäkert? Hur skall överklagningar hanteras?

Gul hatt (fördelar m.m). Extra inlärningstillfälle för studenten och minskad rättningstid för läraren

Grön hatt (nya lösningsidéer m.m). För tentor med relativt korta fakta svar kan man förenkla ännu mer genom att tillämpa flervalsfrågor. Essay-frågor bör lämnas helt utanför

Blå hatt (process m.m). Ta med fler lärarrepresentanter i gruppen så att alla typer av kurser och tentor är representerade

Det här blogginlägg har förhoppningsvis belyst hur de Bonos metoder kan användas för att skapa kreativitet vid problemlösning och utformning av projektbeställningar.

Om du vill lära dig praktisera metoden finner du här länkar till litteratur att köpa på amazon.com, Bokus och Adlibris

Kategorier
Tips från projektcoachen

Tips från projektcoachen – Kravhantering

Beskrivning av projektsituationen

Två grossistföretag gick samman. Deras produkter kompletterade varandra och man förväntade sig därför en stor försäljningsökning. Ett annat mål var att sänka kostnaderna med effektivare organisation, bättre processer och modernare IT-stöd. Ökad användning av webben var en nyckelfaktor. I den första etappen – delprojekt 1 – skulle en ny ordermottagningsprocess skapas, där kunden skulle kunna registrera sin order direkt via webben eller knapptelefon eller ringa till en ordermottagare. Det var bråttom.

Ett välrenommerat konsultföretag kontrakterades för systemutvecklingen. Man anordnade workshops där konsulten tillsammans med användarna specificerade hur systemet skulle se ut. Databaser byggdes upp, program skrevs, tester genomfördes, personalen utbildades, systemet startade. Allt flöt på till belåtenhet och systemet kunde startas två veckor före planerad tid. Projektplanen höll med råge! Men redan under den första veckan framkom missnöje med systemet. Det gällde ”krångliga” och onödigt många bilder och de passade inte riktigt ihop med vissa blanketter och koder. I vissa arbetsmoment måste man titta i fyra olika bilder. I vecka tre dök det upp tekniska problem i form av konstigt långa svarstider ibland. Kunder klagade på att systemet inte fungerade under vissa versioner av Netscape. Vid första månadsskiftet visade det sig att kopplingen till ekonomisystemet inte fungerade. VD och styrelse fick panik, verksamheten var i gungning.

En totalt oplanerad brandkårsutryckning krävdes och en stark oro uppkom för de efterföljande etapperna som redan var planerade.

Du kallas in som projektcoach med uppdraget att reda ut situationen. Vad gör du?

Coachens hantering

Jag kontrakterades som coach för att reda ut situationen och ta reda på varför det gått snett och att stödja projektledaren i de kommande projektetapperna. Jag satte mig in i vad som hänt på en vecka och kunde konstatera att konsultföretaget byggt systemet så som sagts i specifikationerna, men att det var i själva specifikationerna det brast eftersom man inte tacklat kraven på ett professionellt sätt.

Följande punkter betonade jag särskilt

Prototyper som kunde provköras saknades, ekonomipersonal var inte med i projektet, ny oprövad teknik användes, verksamhetsprocesserna dokumenterades inte så att alla förstod. En annan svaghet var att systemet var byggt i för stora komponenter, vilket minskade flexibiliteten inför framtida vidareutvecklig. Dessutom ifrågasatte jag om man inte kunnat köpa vissa komponenter. Några ”smarta” delar i systemet ifrågasatte jag också, eftersom de avvek från vedertagen standard och skapade ett stort leverantörsberoende. Till företagsledningens bestörtning kom jag med det drastiska förslaget att göra om etapp 1 och införa en professionell kravhanteringsprocess (mycket av det som gjorts var fortfarande användbart).

Styrelsen accepterade rådet eftersom mycket fanns att vinna i de följande tre etapperna. Konsultföretaget, som fortfarande bedömdes som kompetenta, behölls. Projektledaren, som kom från användarsidan behölls också, men fick nu till sin hjälp en specialist på systemutveckling och framför allt kravhantering.

Tips från coachen

Många studier visar att brister i kravhantering är den främsta orsaken till att man misslyckas i systemutvecklingsprojekt. Det gäller att:

  • ha en bra kravhanteringsprocess så att man på ett systematiskt sätt och med bra tekniker, hjälpmedel och vedertagna standards tar sig från behov i verksamheten till specifikationer på system
  • få med alla intressenter i systemet så att alla önskemål och krav kommer med
  • dokumentera kraven så att alla förstår. Körbara prototyper är ett bra komplement till skrivna specifikationer
  • strukturera kraven med hjälp av användningsfall
  • gör riskanalyser, förhandla och prioritera kraven
  • validera kraven, d.v.s. förvissa dig om att systemet verkligen löser verksamhetens problem
  • skapa testfall, baserade på användningsfallen, inför kommande acceptanstester
  • använda datorstöd för kravhantering om projektet är stort. Där kan man registrera, relatera och bryta ner olika typer av krav. Man kan också relatera krav till realiserade systemdelar och därigenom säkerställa att inget glöms bort

Tänk även på att beakta andra krav än de funktionella kraven som t ex hur orderregistrering skall gå till, det finns även andra typer av krav, s.k. icke-funktionella, som är minst lika viktiga. Exempel på sådana är användbarhet, tillgänglighet, prestanda, förändringsbarhet, designbegränsningar, standards (interna och externa), säkerhet och legala krav.