Runt om i Sverige fortsätter projekt att genomföras med hög intensitet i de flesta branscher, trots speciella tider. Devisen – vi ställer inte in, vi ställerom – börjar kännas old school eftersom det numera är en självklarhet. Och eftersom projekt består av människor som behöver mötas för att kunna skapa värde i projekten växer nya digitala mötesformer fram.
Leverantörer av mötesplattformar lanserar förbättrade funktioner nästan varje vecka. Dessutom skrivs det alltmer om tips och råd för god digital mötesteknik runt om på bloggar och i sociala medier. Tekniken gör det också enkelt att spela in möten och diskussioner och åsikter blir förevigade och sprids i olika digitala kanaler.
Stora delar av utbildningsbranschen betraktar numera distansutbildning som en naturlig komponent för lärande. Sedan 2012 vidareutvecklar ProjektStegen olika digitala delar för utbildning. Under den resan har vi tillsammans med våra kursdeltagare lärt oss vad som fungerar och inte. Bland alla olika digitala komponenter är mötet i mindre grupper något vi utvecklat mycket, och det är kanske just i den delen av en utbildning där det finns mest praktisk kunskap att hämta för en kursdeltagare.
Det är när deltagare i en utbildningsgrupp öppet och generöst delar med sig av sina verkliga upplevelser, utmaningar och erfarenheter som utbildning kan bli fantastisk!
Under digitala möten i mindre grupper diskuterar vi olika projektsituationer och samtal kommer lätt in på områden som kan vara känsliga. Kanske upplever någon missnöje med ett agerande från en kollega, kanske upplever någon avsaknad av rätt förutsättningar för ett projekt. För att underlätta förtroliga diskussioner som verkligen gör skillnad kan det behövas principer kring hur information från möten hanteras. Det är här Chathams husregel kan bidra till att skapa en öppenhet och trygghet i mötet.
Vad är Chatham House Rule?
Regelns enkla princip kan sammanfattas med att det som sägs och diskuteras på mötet får spridas vidare, och det uppmuntras. Men ingen får avslöja enskilda mötesdeltagares åsikter och uttalanden. Information, kunskap och lärdomar från mötet får alltså användas efter mötet, men det är gruppen som blir källa till informationen, utan spårbarhet till enskilda mötesdeltagare.
Regeln uppfanns redan 1927 och har sedan dess utvecklats och förtydligats. Regeln är väl spridd och används flitigt i t ex olika internationella nätverk och institutioner. Vi använder regeln själva i utbildningssammanhang och för vissa typer av projektmöten.
Som så ofta är det enkla det mest användbara! Dessutom är det lätt att knyta an husregeln till agila värderingar och principer – det är gruppen som helhet som levererar och ansvarar för resultatet.
Läs mer om Chatham house rule för djupare förståelse för vad den innebär.
Har du några tips på husregler som kan göra skillnad för givande möten? Tipsa gärna!
Många av oss har upplevt det på möten – projektet är i ett tidigt skede och det finns många oklarheter, vägval och frågetecken att reda ut för att säkerställa rätt lösning och strategi för att uppnå målen. Olika frågor kommer upp på inledande möten och många av frågorna är så komplexa att de behöver underlag, analys och eftertanke – kort sagt en förstudie.
Istället för att parkera svåra frågor och ta upp dem senare när de är tillräckligt förberedda så inträffar HIPPO-syndromet. HIPPO* är en akronym och står för Highest Paid Person’s Opinion, fritt översatt till högst avlönade personens åsikt. En HIPPO är oftast en senior chef, som utifrån sin position agerar med stor auktoritet och hyser respekt från medarbetare.
På möten tar ofta HIPPOn initiativet och ger sin syn på olika frågor. Istället för att dennes åsikt utgör en av flera möjligheter eller synsätt på vägen framåt så betraktas HIPPOns åsikt som den sanning och vägledning som projektet behöver för att komma vidare. Detta trots att så kanske inte alls är fallet. Det kanske saknas data för att fatta beslut, eller så har den unga och nyanställda projektmedarbetaren mer insikt och relevanta kunskaper i aktuella frågor. Men dennes åsikter tenderar att väga lätt när HIPPOn väl har sagt sitt.
Beslut i projekt ska vara grundade på data, analys och projektets samlade kompetens, inte enbart på HIPPO!
Vad kan du som professionell projektledare göra för att undvika det här syndromet? Vårt bästa tips är att alltid förbereda frågor som ska behandlas på möten med väl genomarbetade diskussionsunderlag. Om en fråga ska leda till ett beslut bör beslutsunderlaget också innehålla en rekommendation till beslut, med tillhörande motivering. Det här gör att diskussioner och beslut baseras på data och underlag.
Ytterligare ett tips är att du som projektledare aktivt styr möten så att alla mötesdeltagare får utrymme att ge sin syn på frågor innan ordet ges till HIPPOn. Genom det undviks att mötesdeltagare påverkas för mycket av HIPPOns åsikt.
* Begreppet HiPO, Highest Paid Option myntades av Dylan Lewis 2006 och vidareutvecklades sedan samma år till HIPPO av Avinash Kaushik och Ronny Kohavi.
Kan projektvärlden lära sig något av militära strategier? Det sägs att t ex det amerikanska specialförbandet Navy Seals använder följande devis – Slow is Smooth, Smooth is Fast, fritt översatt till att skynda långsamt är effektivt.
Att organisera ett team kräver först och främst ett mål, därefter en plan för att ta sig dit så snabbt som möjligt utifrån de förutsättningar som finns. Framdrift i gå-tempo är för långsamt, att springa ökar risken för misstag. Att halvspringa kan vara en bra medelväg. Vid eftertanke så går det ju att visuellt se hur militära trupper rör sig framåt genom att halvspringa i ett genomtänkt mönster – framåt mot målet i så snabbt tempo som möjligt utan att riskera för stora misstag.
Efter att ha utbildat tusentals projektledare och chefer i projektarbetsformen är det tydligt att många organisationer har för bråttom i sina projekt. Ofta går man från en otydlig idé och målbild direkt till genomförandet. Att det är en allt för utbredd verklighet idag i projektvärlden visar också undersökningar.
Många är de projekt som skulle vinna på att avsätta mer tid till att först göra en ordentlig målformulering, följt av en hållbar plan och sedan riskanalys för vad som kan hindra att nå målet. Därefter kan projekt börja röra sig framåt och leverera nytta i ett snabbt men kontrollerat tempo. Eller som dom säger därborta – Slow is Smooth, Smooth is Fast!
Att beställa rätt projekt och samtidigt ha kunskap om när i tiden olika typer av funktionalitet och nytta behövs är centralt i alla typer av verksamheter. I grunden handlar det om kunskaper i att balansera insikter om verksamhetsbehov med produktionskapacitet. Ju bättre en organisation är på att definiera sina behov, och hur, när och i vilken omfattning projekten ska leverera den nyttan, desto effektivare projekt.
Häng med på en bloggserie i flera delar där vi beskriver och reflekterar kring hur kravarbete i projekt kan förberedas, genomföras och följas upp för att säkerställa att projekten levererar precis det som verksamheten efterfrågar.
Först ut är måldriven utveckling med behoven i fokus. Det ska sägas direkt att bloggserien har sin utgångspunkt i agilt arbetssätt, men många principer och moment kan även användas i traditionella arbetssätt, som t ex sekventiellt.
Om du saknar något område eller frågeställning inom det här området som du skulle vilja att vi kompletterar med så tar vi tacksamt emot förslag!
Effektivt kravarbete börjar med att klargöra behovsbilden. Låt behoven utgöra basen och strukturen för att definiera krav, ta fram lösningar, leverera och fungera som utgångspunkt för att följa upp att det blev som vi tänkt oss.
En kravprocess består av ett flöde av behov, möjligheter, lösningar och krav. Se samspelet mellan begreppen i den här översiktsbilden.
Några förklarande punkter av översikten ovan som beskriver ett väl beprövat sätt att hantera krav vid agilt arbetssätt:
Behoven utgör grunden för kravhantering och är kopplade till de effekter som önskas uppnås. De samlade behoven kan benämnas som målbilden.
En Roadmap beskriver och visualiserar när en beställare behöver börja kunna använda resultatet, dvs börja kunna nyttja leveranserna från projektet.
Möjligheterna att tillgodose behoven tas fram på en första grov nivå. Med fördel kan dom olika möjligheterna uttryckas som olika Lösningsförslag.
Lösningsförslagen kan vara en mix av initiala respektive mer långsiktiga lösningar, vilket innebär att det kan bli aktuellt att gå vidare med både en kortsiktig och en långsiktig lösning för projektet, även kallat livscykelperspektiv.
Krav kommer nu in i bilden när Valda lösningar ska utformas.
De Valda lösningarna kan innebära en eller flera Leveranser och Delleveranser
Leveranser bryts sedan ner i olika Aktiviteter, dvs arbete, som behöver utföras för att kunna leverera.
Leveranser till verksamheten sker på två nivåer: – Delleveranser från Utvecklingsteam, dvs innan allt är på plats avseende Leveransen. – Leveranser från projektet, dvs när allt är på plats (”tillräckligt bra”) för att kunna anses levererat från projektet.
Verksamheten tar emot lösningarna successivt i form av olika delleveranser från utvecklingsteamen. Varje delleverans testas och godkänns av verksamheten.
Verksamheten påbörjar nyttjandet av lösningarna för att hantera sina behov. Nyttjandet sker över tid enligt bestämd Roadmap.
Med ovanstående vill vi visa att krav bottnar i behov, dvs något man behöver för att kunna uppnå de effekter man önskar. Det gäller både sk funktionella och icke-funktionella krav.
I våra konsultuppdrag ser vi ofta att många organisationer inte låter behoven vara ett eget steg i kravprocessen. Istället väljer man att direkt gå på kraven. Med det finns då en risk att tappa kopplingen mellan verksamhetsbehoven och det som projekten levererar.
Agilt vs Sekventiellt vid hantering av krav
En alltför vanlig kommentar vid traditionell utveckling som använder ett sekventiellt arbetssätt är ”Ni har inte fått den funktionen därför att den inte fanns med i kravlistan”. Det här beror oftast på att det är svårt att i förväg tänka på alla delar som behöver komma med.
Med det agila arbetssättet faller det sig mer naturligt att arbeta i strukturen Behov-Krav, dvs behov som resulterar i ett antal krav. I agil utveckling nöjer man sig ofta initialt med att definiera de behov som verksamheten behöver tillgodose på en övergripande nivå. I takt med att behoven sedan prioriteras sker sedan en detaljering, vilket vi kommer att beskriva mer i kommande blogginlägg i den här bloggserien.
Förståelsen av behoven ger bättre helhetsbild och stabilare bas än en kravförteckning. Lösningen för att tillgodose behoven kan komma att se annorlunda ut än om verksamheten själv tänker i lösningar med tillhörande krav.
Fördelar med att separera behov och krav
Projekt är människor är en tes vi ofta använder. Så även när det gäller krav. Att skilja på behov och krav skapar organisatoriska fördelar i projekten eftersom det blir naturligt att verksamheten fokuserar på att definiera sina egna behov. De äger därmed själva basen för projektet. Därefter engageras utvecklings- och produktionsenheter för att tillsammans med verksamheten arbeta vidare med kravprocessen och ta fram lösningar och definiera krav.
En vanlig fallgrop med att börja med att tänka lösningar och krav för tidigt är att det kan finnas olika möjligheter att tillgodose behoven. Dessutom är det ofta mycket lättare att beskriva olika alternativa och effektiva lösningar om de ställs mot specifika och definierade behov. Om kraven istället utgör basen för kravarbetet finns risk att man i onödan låser fast ett antal krav som kanske inte är relevanta eftersom de finns med i kravlistan för en lösning som kanske inte är aktuell längre, dvs risken finns att krav kvarstår till utvecklingsfasen även fast dom kraven kom till för en annan lösning som inte valts.
Visualisering av behoven i en roadmap
En gemensam målbild är en mycket bra bas för projekt. Med målbild menas en samlad och heltäckande beskrivning av behoven och de effekter som önskas uppnås. Ett tips är också att redan i ett tidigt skede börja arbeta med prioritering av behoven. En sk. roadmap kan vara ett enkelt sätt att visualisera prioritering av förväntade leveranser för att tillmötesgå behov.
En roadmap visar när verksamheten önskar få sina respektive behov tillgodosedda och i vilken omfattning. Mer om visualisering av roadmaps kommer vi att beskriva i kommande blogginlägg.
Måldriven utveckling
Baserat på olika möjligheter att tillgodose behoven, kan sedan olika lösningsförslag arbetas fram av t ex utvecklingsavdelningen, IT etc. Verksamheten är hela tiden med och kompletterar med krav under projektets gång.
Vid agil utveckling genomförs projekt indelat i flera kortare etapper, t ex i tidsperioder om 2-3 veckor. Ytterligare en fördel med måldriven utveckling utifrån behov är att det ofta är enklare att diskutera innehåll i olika etapper om utgångspunkten för planering av etapper är på behoven istället för att använda en kravlista som bas.
Fokus på behoven snarare än kraven gör att vi får en måldriven utveckling baserat på vad som behöver levereras och när verksamheten behöver sina leveranser. På så sätt uppnås också en naturlig prioritering i projekt.
Hur ska det här då gå till i praktiken? Vem ska utföra arbetet och hur sker kommunikation i den här typen av kravarbete? Vi kommer att återkomma kring organisation och roller längre fram i den här bloggserien.
Hoppas du har lust att följa hela vår bloggserie kring detta viktiga område krav. I kommande inlägg kommer vi beskriva och reflektera kring prioriteringar och avgränsningar, roller och ansvar, visualisering av roadmaps och verifiering.
Svenska ProjektAkademien verkar för att främja utveckling och tillämpning av projektarbetsformen i svenskt arbetsliv. Ett sätt som de stödjer projekt som arbetsform är att de har en årlig uppsatstävling som vänder till studerandes examensarbeten på bachelor- eller masternivå.
På våra utbildningar är en vanlig fråga om vi kan ge tips på bra och lättanvända verktyg för projektledning. I takt med att allt mer arbete flyttas ut i molnet så dyker nya verktyg och aktörer upp hela tiden. Konkurrensen bland verktyg för samarbete kring projekt och aktiviteter är idag mycket hård. Det finns dock några verktyg som vi själva jobbar med. Här kommer några tips på verktyg som kan vara till stor hjälp för projektledare. Ett kriteria när vi valt ut verktygen nedan har varit att de är molnbaserade, relativt billiga att starta med och inlärningströskeln är låg. Håll till godo! Har du tips på ett nytt spännande verktyg för projektledning? Kommenterar gärna nedan.
Prototyping och Design
Invision är ett modernt verktyg för att t ex samarbeta kring framtagning av prototyper. Det går snabbt och tydligt att diskutera, visa, ändra och lägga till information kring t ex olika skärmbilder för en webbsida eller mobilapp.
Slack är ett flexibelt verktyg för att samarbete. Slack har ett snyggt och lättjobbat gränssnitt och innehåller ett stort antal möjligheter till integration av andra appar, t ex olika planeringsverktyg, dokumentsystem mm.
Microsoft Project är det mest använda planeringsverktyget. Finns versioner både för desktop och som molntjänst. Finns i såväl enkla och grundläggande versioner till mer avancerade versioner som inkluderar portföljstyrning mm.
Jira är ett av de större verktygen för agil mjukvaruutveckling. Baseras på sk Scrum/Kanban-tavlor. Många funktioner för att mäta framdrift i projektet.
Microsoft SharePoint är den mest använda plattformen för dokumenthantering. Microsoft Sharepoint har med sin koppling till Office 365 snabbt blivit populär. Innehåller flera bra verktyg för projekt som t ex Planner, Teams mm.
Asana är ett mycket väldesignat och lättanvänt verktyg för teamarbete inom projekt och aktiviteter. Innehåller också sk kanban-tavlor där gruppen kan se pågående och avslutade aktiviteter.
Ett av de mer etablerade verktygen som fokuserar på enkel funktionalitet kring Gantt-scheman. Det går snabbt att skapa en struktur över ett projekt och det finns även stöd för lite mer avancerade funktioner som t ex kritiska linjen mm.
Trello är ett mycket lättanvänt verktyg för att arbeta med aktiviteter och uppgifter. Principen är att dela in tavlor utifrån ett tänkt arbetsflöde, t ex kommande, pågående och avslutade uppgifter. Dessutom är det enkelt att kategorisera uppgifter och t ex få notiser om ändringar sker mm.
De flesta projekt innehåller någon form av siffror och har behov att pedagogisera information för olika målgrupper. Piktochart innehåller ett stort antal färdiga mallar för olika typer av infographics. Visualiering på ett enkelt sätt.
De Lättanvänt och visuellt verktyg för att planera, genomföran och följa upp projekt. Finns olika typer av kopplingar och kan användas för olika typer av projekt och behov. Fokus på agil utveckling men fungear lika bra för plandriven utbildning
Canva innehåller ett mycket stort antal färdiga mallar för olika typer av grafiska produktioner, t ex inlägg i sociala medier, presentationer, logotyper, annonser etc. Det går mycket enkelt och snabbt att skapa professionell design för print och digitalt.
Det är svårt att hitta en generell regel för vad som är en optimal projektstorlek. Ett alltför litet projekt levererar inget av tillräckligt värde och ett för stort projekt kan kväva sig självt. Någonstans däremellan finns den optimala projektstorleken. Exakt var den finns varierar, men det går att systematiskt närma sig frågan.
WBS – en bra början
Ett vanligt sätt att angripa projekt är att arbeta med en sk WBS – Work Breakdown Structure. Först identifieras förväntade leveranser från projektet. Därefter analyseras de arbetsuppgifter/aktiviteter som krävs för varje leverans. Slutligen skapas projektplanen genom att aktiviteterna läggs ut i kalendern, med hänsyn till beroendeförhållanden mellan aktiviteterna.
Ofta nöjer sig många projekt med att göra en WBS. Men risken är att resultatet blir komplext och svåröverskådligt och därmed svårt att styra och följa upp. Det leder ofta till förseningar och fördyringar. Då uppstår inte sällan kaos och projektledaren tappar greppet om sluttid och om budget. Dessutom förskjuts medarbetarnas förväntade insats i tid, vilket förmodligen inte alls passar med deras egna och organisationens övriga planer.
Känns det igen? Någon form av ytterligare strukturering krävs för att få kontroll.
Don´t boil the ocean – dela upp projektet i mindre delar
Det finns ett välkänt managementbegrepp som heter Don´t boil the ocean, något som i det här sammanhanget fritt skulle kunna översattas till ”fokusera på en mindre del i taget istället för att allt på en gång”.
Med WBS:en som utgångspunkt struktureras arbetet i mindre delar som kan genomföras fristående från varandra. Resultatet blir ett antal olika komponenter/delar som tas fram och levereras fristående. Slutligen sätts de samman till en slutprodukt. Fördelen är att utvecklingen blir mer fokuserad, att komponenterna enklare kan bytas ut och att de i bästa fall kan återanvändas i andra sammanhang.
Frågan återstår dock om delarna ska utgöra delprojekt som underordnas ett huvudprojekt, eller om delarna ska vara fristående projekt med egen projektplan, ledning och bemanning?
Generellt sett brukar delprojekt vara att föredra om delarna ska levereras som en helhet. Likaså är delprojekt ofta bra om det är samma styrgrupp, projektledare och resurser för de olika delarna.
Fristående projekt är intressant om delarna kan levereras och användas separat och därmed har ett egenvärde för beställaren. I de fallen kan man med fördel etappindela projektet.
Begreppet projektprogram är också värt att nämna i det här sammanhanget. Vad som menas med det begreppet varierar kraftigt. Oftast innebär det att ett antal delprojekt, eller fristående projekt, har någon form av gemensam styrning i form av t ex en programledning. Programledningens uppgift kan t ex vara att samordna delarna, prioritera och säkerställa att dubbelarbete inte sker mellan de olika projekten.
Enklare att prioritera och tidigare leveranser
En fördel med att dela in projektet och leveranserna i mindre delar är att prioritering ofta blir enklare. Om tid och eller pengar tar slut kan man se vad som kan strykas eller senareläggas. En annan fördel med att bryta ner till delprojekt eller fristående projekt är att leveranser kommer tidigare och mer succesivt, istället för en stor leverans på slutet. Det här angreppssättet är något som blir allt mer vanligt och är ett exempel på agil utveckling.
Nedan beskrivs generella fördelar ur beställarens och ur projektgruppens synvinkel:
Fördelar för beställaren
Får successivt ta del av de förbättringar som projektet levererar
Får erfarenhet av nya tekniker och synsätt. En lärande process
Kanske blir medveten om nya möjligheter, vilket man kanske inte var från början
Får erfarenhet av att kommunicera effektivt med projektgruppen
Ser hur uppskattning av kostnader och tider fungerar i verkligheten
Får en uppfattning om projektgruppens styrkor och svagheter
Fördelar för projektgruppen
Ser tidigt effekterna av sitt arbete
Får erfarenhet av att kommunicera effektivt med beställaren
Får ökade kunskaper om verksamheten och beställarens problem. En lärande process
Ser hur uppskattning av kostnader och tider fungerar i verkligheten
Fokus på beställarens problem och önskemål ökar
Får en ökad uppfattning om beställarens engagemang, kunskap och tillgänglighet
Några faktorer som talar för att dela in ett stort projekt i mindre delar
Antal involverade personer är stort
Planerad genomförandetid är lång
Projektet är komplext
Ny teknik används
Ovana och dåliga kunskaper inom organisationen för aktuell typ av projekt
Beställaren har behov av tidiga resultat
Det finns ett antal kritiska delar
Projektet är geografiskt spritt
Projektet innehåller stora risker
7 steg för att dela in ett projekt i mindre delar
Gör en WBS för hela projektet
Dela upp i separata och helst fristående delar, om så är möjligt, vilket nästan alltid är fallet. Grunden för uppdelningen kan vara verksamhetsnyttan, teknik, risker etc
Upprätta en lämplig tidsordning för allt som ska utföras. Naturligtvis måste man ta hänsyn till eventuella samband och beroendeförhållanden mellan delarna
Prioritera delarna, vilket måste samplaneras med tidsordningen. Exempel på prioriteringsgrader är MÅSTE, VIKTIGT, BRA ATT HA
Bestäm om delarna ska genomföras som delprojekt under ett och samma projekt eller fristående projekt
Samla alla intressenter och gå igenom hela planeringsarbetet tillsammans för att komma fram till ett optimalt angreppssätt
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
Alla har vi med jämna mellarnrum behov av att fundera hur vi bäst prioriterar vår tid. Ju mer tempot och antal ”måsten” ökar, desto större blir behovet av att prioritera rätt. Ett behov som i allra högsta grad finns hos projektledare i projektets alla faser.
En klassisk metod att använda vid prioritering är den sk Eisenhowermetoden, även kallad Eisenhowerprincipen. Den sägs ha använts av den amerikanska presidenten Dwight D. Eisenhower, som lär ha myntat uttrycket What is important is seldom urgent and what is urgent is seldom important. Fritt översatt: det som är viktigt är det sällan bråttom med, och det som det är bråttom med är sällan viktigt.
Den här enkla modellen går helt enkelt ut på att placera in t ex aktiviteter i en matris efter principen viktigt/inte viktigt och bråttom/inte bråttom.
Placera in dina aktiviteter och uppgifter i matrisen och få svart på vitt att bara för att det är bråttom med en uppgift eller aktivitet, så är den inte nödvändigtvis prioritet 1.
Verksamheter, samarbeten och projekt styrs av kommunikation med hjälp av språket. Det är oftast av avgörande betydelse för resultatet att information förstås och tolkas på samma sätt av alla berörda. Missförstånd på grund av oklarheter kan leda till kostsamma misstag, inte minst inom projektarbete.
Exempel på oklarheter i en organisation kan vara
Vem skall anses vara kund – den som betalar produkten eller den som använder den? Eller finns det en annan definition?
Vilket samband råder mellan begreppen leverans, sändning, mottagning, artikel, ankomstkontroll, returorder, reklamationsorder och order?
Ingår installation av systemet?
Även oklarheter i själva processen, t ex projektprocessen, kan vara en källa till missförstånd
När anses projektet vara startat – när beställningen är gjord, när förstudien är påbörjad eller när genomförandet startat?
Vad avses med projektets mål – projektmålen som ska levereras eller de effekter som förväntas uppnås när projektet har levererat, dvs effektmålen?
Vad menas med en veckas leveranstid – 7 kalenderdagar eller 5 arbetsdagar?
Vad innebär begreppsanalys och terminologiarbete?
Begreppsanalys och terminologiarbete innebär att organisationen enas om innebörden i viktiga ord och begrepp. Begrepp kan exempelvis avse produkter, dokument, processer, händelser, aktörer och regler. I det enklaste fallet skapar men bara en ordlista/termkatalog/begreppslista som fastställer vilka ord som ska användas t ex kund, leveransadress, fakturaadress, artikeltyp.
Ordlistan kan förses med förklaringar/definitioner och blir då mer informativ, t ex med patient avses den som tidigare behandlats på vårdcentralen. Man kan också beskriva begreppen på ett djupare sätt, relatera dem till varandra och precisera vad som skiljer och förenar närliggande begrepp t ex order, normalorder, prioriterad order, snabborder, returorder, ersättningsorder, kompletteringsorder, reklamationsorder och gratisorder.
Vanliga problem vid kommunikation med språket och ord
Man brukar skilja mellan syntaktiska och semantiska oklarheter i språket. Syntaktiska oklarheter har med meningens konstruktion att göra, exempelvis alla våra internationella produkter och tillbehör. Avses alla tillbehör eller endast de internationella? Semantiska oklarheter har med ordens betydelse att göra. Det finns många olika typer av semantiska problem, exempelvis att ett ord kan betyda olika saker (jfr ordet fil) eller att det finns fler ord för samma sak (kundnummer och kundID).
Ytterligare ett problem är när ord är vaga och kan uppfattas på olika sätt, exempelvis ordet moral. Det är ett välkänt faktum att vårt språk i sig ofta är oprecist. Vi förstår normalt varandra ändå, eftersom vi ofta känner de vi kommunicerar med och vet hur de tänker och hur de uppfattar begrepp. Det blir svårare då man kommunicerar med människor man aldrig arbetat med tidigare, vilket ofta är vanligt i projektsammanhang.
Grundläggande standards ISO-704 och UML
Grundläggande standard inom terminologiarbete är ISO 704 Terminology work – Principles and methods. Det är ett ramverk för tänkandet och definierar viktiga begrepp, klassificeringar och strukturer. Vidare ges exempel och rekommendationer samt anvisningar för hur terminologiarbete bör gå till. En annan standard som också är relevant i detta sammanhang är UML – Unified Modelling Language.
Begreppsmodeller – Olika typer av samband mellan begrepp
Ibland kan begreppen i en verksamhet vara välkända, entydiga och väldefinierade. Detta är tyvärr dock inte alltid fallet. Ett hjälpmedel i analysarbetet i kniviga fall är att arbeta med grafiska begreppsmodeller enligt ovan nämnda standards för att fånga begreppen och deras relationer. Därefter definierar man begreppen och för in dem i ordlistan/begreppskatalogen/termdatabasen.
I följande figur visas ett enkelt exempel som beskriver fem begrepp och hur de hänger samman. Patient och läkare är båda en person (triangel/pilspetsen betyder generalisering/specialisering). Varje person har fler kroppsdelar (asterisk betyder fler). En patient kan göra fler läkarbesök. Vid ett läkarbesök behandlas endast en kroppsdel av en läkare, men en kroppsdel kan ha behandlats vid flera läkarbesök. Den grafiska modellen kan ytterligare detaljeras med andra typer av symboler och samband.
Begrepps- och termdatabaser och olika typer av datorstöd
IT-stöd för begreppsmodeller finns att köpa, exempelvis UML-stöd. IT-stöd för termkataloger är det dock inte så gott om. Det verkar som de flesta företag som har datoriserade termkataloger har utvecklat egna enkla IT-stöd, exempelvis i Microsoft® Access. En termkatalog kan i enklaste fallet bara vara en ordlista och i det mer avancerade fallet vara kompletterad med fullständiga definitioner av begreppen och relationerna dem emellan.
Följande exempel på frågor kan vara intressanta att ställa mot en begreppsdatabas
Är begreppet vägkorsning en generalisering eller precisering av något annat begrepp?
Har begreppet lamphållare samband med något annat begrepp?
Vilka begrepp ansvarar Karlsson för?
Vilka begrepp finns inom området akutsjukvård?
Vad heter offert på ryska?
Vilka synonymer finns till begreppet försening?
Lite filosofi-light om språk och semantik
Begreppsanalys och terminologiarbete handlar om språket, dess begrepp och hur dessa definieras. Semantik är läran om språkets och dess effekter och kopplingen till verkligheten. Nedan ges en kort inblick i ämnet, huvudsakligen baserat på en klassiker inom ämnet, boken Empirisk semantik av norrmannen Arne Naess », (Almqvist & Wiksell).
Enligt Naess görs påståenden med hjälp av språket, exempelvis jorden är platt, vilket uttrycks med just denna sats eller med någon av satserna the Earth is flat eller jordklotet har en plan yta. Ett annat exempel på två satser som innehåller samma påstående är Lars är längre än Lisa och Lisa är kortare än Lars. Det omvända kan också förekomma. Satsen det är grönt kan tolkas på två sätt: vi har fått klartecken eller färgen är grön. Värt att notera är att ett påstående inte behöver vara sant. Kommunikation tolkas alltid av en mottagare. Tolkningen är ofta avhängig av vem som tolkar och i vilken situation det är. Bilen är dyr betyder säkert olika då den tolkas av en oljeschejk eller av en gymnasist som sommarjobbat ihop till sin första begagnade bil. Per är snabb betyder en sak då han bedöms som systemutvecklare och något annat då han ställer upp i ett hundrameterslopp.
Ett annat intressant begrepp är Intentionsdjup. Då en läkare säger att hjärtat verkar slår normalt så har läkaren säkerligen en djupare motivering än då en lekman yttrar detsamma. En definition av ett begrepp kan beskrivas olika djupt. Ökat djup ger en bättre precision men gör det ofta mer svårförståeligt och därmed mindre användbart. Det gäller att ha ett rimligt och ändamålsenligt djup i definitionerna.
Definitioner är ett stort ämne. Det kanske viktigaste är att definitionen träffar rätt, dvs att den inte är för trång eller för vid. Om vi exempelvis som definition av begreppet bil anger motordrivet landfordon så är den för vid, eftersom t ex en motorcykel även då kan uppfattas som en bil. Om vi istället anger motordrivet landfordon med fyra hjul så är den för trång eftersom det finns bilar med exempelvis tre eller sex hjul. Definitioner kan också vara fel på andra sätt. Ett vanligt fel är cirkeldefinitioner, t ex Lön = Lön för ordinarie arbetstid plus övertid.
Slutsats
Kommunikation med språket är ett svårt ämne. Missförstånd kan förorsaka olika typer av fel inom en verksamhet eller projekt och ofta kan konsekvenserna av missförstånd bli dyra.
I projektvärlden finns normalt massor av begrepp och definitioner. I de inledande faserna av ett projekt kan missförstånd och olika tolkningar leda till att fel projekt startas, att beställaren och projektledarens uppfattning om vad som ska levereras skiljer sig markant, att egenskaper hos en produkt inte motsvarar kraven etc.
Vi hoppas att det här blogginlägget har belyst vikten av att tillämpa begreppsanalys i tillräcklig utsträckning för att skapa klarhet och tydlighet i kommunikationen och därmed minimera risker. Hur mycket tid och kraft som t ex ett projekt ska ägna åt detta varierar naturligtvis, men det är ofta väl investerad tid att fundera igenom en miniminivå för hur begrepp och definitioner ska hanteras i verksamheten och för det enskilda projektet.
Vad är dina erfarenheter av vikten att vara överens om begrepp och definitioner?
