Arkiv | Webbutveckling RSS feed for this section

En lyckad lansering – finns det ett säkert sätt att lyckas?

9 Maj

I förra veckan fick jag äntligen till lanseringen av ett projekt som vi slitit med rätt länge: digitala kataloger för Bonnierförlagen. Jag har skrivit om detta tidigare. Dels vad gäller förseningen av lanseringen, dels vad gäller samarbetet med designpartnern.

Egentligen började projektet som ett ganska simpelt uppdrag: vi planerade 40-60 timmars utveckling. Det handlade om två-tre sidmallar i EPiServer – inga konstigheter -  dock med ganska avancerade kopplingar till kundens affärssystem. Kunden hade skrivit ihop en ganska omfattande kravspec och vi körde igång med utvecklingen. Så långt allt väl…

Om vi pausar där och tar ett steg tillbaka. Tillbaka till huvudfrågan – finns det ett säkert sätt att få till en lyckad lansering?

Det finns ett antal punkter som är viktiga att enas kring – beställare/leverantör – när det gäller webbprojekt (eller projekt i allmänhet):

  • En tidsplan – datum x ska projektet vara klart/presenterat/lanserat
  • En uppdragsbeskrivning/kravspec – ”detta ska göras”
  • Om andra projekt berörs - prioritering jmf med dessa
  • Resursbehov – vilka krävs i projektteamet för åstadkomma det som efterfrågas och få projektet klart i tid?

Vi som konsulter måste dels säkerställa punkterna ovan med kunden, dels säkerställa dem internt. Oftast sitter det inte systemutvecklare och väntar på uppdrag utan är fullt sysselsatta (åtminstone hos oss på Limetta), vilket innebär att det krävs lite extra planering om det dyker upp ett mindre ”specialprojekt” som detta.

Tillbaka till projektet då. 40-60 timmar för en systemutvecklare lyckades vi få loss. Ett annat projekt skulle bli lite lidande, men med en omflyttning av resurser lyckades vi lösa det rätt bra. Med den första kravspecen i handen hade utvecklarna kommit 15-20 timmar in i projektet när det hände: uppdaterad kravspec med ändringar. Okej, ett par ändringar får man ju räkna med. Tyvärr räckte det inte med dessa, utan det kom fler. Och fler.

Från början var lanseringen tänkt till början av april, efter påsken. Med alla ändringar blev det nu i början av maj istället. Vad hade vi då kunnat göra annorlunda för att lyckas bättre?

Ett fel som jag tror vi gjorde var att ta för lätt på uppdraget som sådant. Såhär i efterhand blev det tre gånger så många timmar som vår maxuppskattning. Inte för att kunden klagar eftersom de fått (nästan) exakt vad de ville ha i och med alla ändringsomgångar (vissa ändringar på slutet var vi tvungna att stoppa).

Det som lidit mest är helt klart vår resursplanering och med det – vissa andra projekt. Varför? Jo, tidsplanen sprack helt och kravspecen ändrades fyra-fem gånger. Prioriteringen på detta projekt var hög så vi tog resurser från andra projekt.

Förmodligen skulle vi varit tuffare när det gällde alla ändringar. Istället för att nyutveckla, ändra, justera, nyutveckla, ändra osv borde vi pausat projektet för att tvinga kunden att bestämma sig. Egentligen skulle vi nog sagt nej från början eftersom tidsplanen var så knapp, men vad gör man när en bra kund behöver snabb hjälp?

Jag har i och med detta projekt lärt mig en läxa:

  • Låt inte kunden ”lura” dig att det är ett lätt och enkelt projekt innan du vet vad som ska åstadkommas
  • Kolla upp det som ska göras och se om det är möjligt – och hur lång tid det tar – innan du tar dig an uppdraget (kopplingen till affärssystemet…)

Man lär så länge man lever! :-)

Val av CMS/publiceringssystem – vilket ska man ta egentligen?

6 Maj

Jag pratade lite jobb med en bekant häromdagen. Han jobbar som systemarkitekt på ett konsultbolag är således en ”kollega”. Vi diskuterade en del runt pågående projekt och kom in på det där med CMS. Du som följer min blogg vet att jag skrivit om detta med val av CMS vid ett antal tillfällen.

Den här gången berättade jag om vissa pågående EPiServer-projekt vi håller på med och beklagade mig lite över försenade projekt. Min bekant berättade att de just lanserat flera Joomla-sajter och kunde inte förstå hur vi kunde hålla på med EPiServer som är så dyrt osv. Jag kan förstå den synpunkten – open source ger köparen/beställaren pengar över från licenskostnader som istället kan användas för utveckling – MEN – EPiServer har heltidsanställda utvecklare som jobbar med att förbättra systemet löpande. Ett starkt plus i valet av CMS i mina ögon.

Vi på Limetta får frågan då och då om vi kan bygga sajter i Joomla eller Drupal, men eftersom vi är .Net-experter får vi tyvärr tacka nej till den typan av uppdrag. Om en kund vill ha ett komplement till EPiServer kan vi då erbjuda Umbraco istället, som är ett open source .Net-alternativ.

Det som jag dock anser är det allra viktigaste i valet av CMS (publiceringssystem) är att hitta en leverantör/konsult som du som beställare har förtroende för. Dessutom är det en bra idé att inte välja ett system med få alternativa konsulter. Risken finns ju tyvärr alltid att samarbetet inte fungerar optimalt – och då måste det finnas inte en annan alternativ leverantör utan helst flera.

Välj med huvudet och fokusera inte på vilket CMS som är ”inne”. Utgå från dina CMS-behov och vad konsultmarknaden har att erbjuda. Lycka till!

Att leverera på tid – vilken tid?

26 Apr

När det gäller projekt i allmänhet och webbprojekt i synnerhet pratas det om behovet att leverera  i tid (helst till budget också, men det kan vi bortse från här och nu…). Det kan tyckas självklart att leveransen ska ske på det datum som sätts i tidsplanen, men det är inte alltid så…

Jag sitter med ett projekt nu som varit ”nästan klart” och ska lanseras ”snart” i ett par veckor. Till viss del hänger det ihop med det faktum att vi inte är ensam leverantör i projektet, men tyvärr har vi dessutom en beställare som kommer på ”smarta ideér” löpande under projekttiden. Favoritmeningen är:

Vi behöver bara en specialare just här, ingen annanstans.

Det där ”en specialare” har dock ofta en förmåga att följas av ett ”just ja – där också”. Min utvecklarkollega har fått kämpa hårt med att hänga med i svängarna. Det som är lite lustigt är att projektet startade som en ganska enkel kampanjwebb som skulle göras på två veckors kalendertid och max skulle ta 60 timmar. Nu ligger vi på snart två månaders kalendertid och uppåt 150 timmar. Tjohoo!

En följd av detta projekts något diffusa lanseringsplan är att vissa andra projekt (med lite mer fasta deadlines – typ 12 maj) berörs av det konstant framflyttade lanseringsdatumet. Frågan som dyker upp allt oftare är – vad gör vi för att inte tvingas skjuta fram kommande lanseringsdatum för de andra projekten?

Jag föredrar fasta lanseringsdatum där ett datum är ett datum. Trots att det kan innebära extraarbete för att hinna. Att ha en kund som hela tiden kommer med nya idéer, nya funktioner och skjuter fram deadline – det är hopplöst för planeringen.

Enda positiva i det hela är att vi jobbar på löpande räkning…

Olika leverantörer i samma projekt – måste det bli pannkaka av allt?

20 Apr

Jag har suttit med ett nytt, ganska litet (100-120 timmar) webbprojekt ett tag nu. Vi håller på och tar fram en ny webbplats som är fristående från företagets ”vanliga” webbplts och som därför har en egen look and feel. Det är bara ett problem – den designbyrå (inga namn) som tagit fram design, html och css:er har inte så bra koll på det där med deadlines (och inte superkoll på det som de levererar heller). Visst, sajten ser rätt snygg ut och så, men att det ska vara så svårt att göra rätt (och i rätt tid)?

Måste det vara så? Måste det bli problem när en designbyrå och en webbyrå ska designa, bygga och leverera en webbplats tillsammans. Jag kan förstå att beställaren ibland blir överrumplad av snygga skisser och annat lull-lull (reklambyråer… u know…), men det kan dock vara ett rätt stort steg mellan en specialanpassad html-dummy och den färdiga webbplatsen som ska byggas i EPiServer (i vårt fall). Avancerade databasanrop, importer, bilder av ”fel” storlek – det finns mycket som kan ”sabba” den snygga skissen.

Kan inte designleverantören och cms-leverantören snacka ihop sig först? Varför tänker inte kunden på att det kan vara två olika ”världar” som ska mötas? Var ligger ansvaret, för att knyta an till tidigare inlägg?

Jag har inga svar att komma med, men har svårt att tro att det inte är fler som är ”drabbade”. Hur har ni löst det?

Oavsett vilken ”sida” du sitter på – berätta!

Leverantör vs. beställare – ett insidesperspektiv

1 Apr

Jag tänkte gå vidare i diskussionen kring ansvaret som vilar på leverantör och beställare. Under mina drygt tio år inom webbområdet har jag suttit på båda sidor. Här är mina tankar med utgångspunkt från respektive sida när det gäller webbprojekt.

Beställaren

Som beställare vill jag ha en leverantör som kan stödja mig i min beslutsprocess. Jag har en budget på X kronor som jag vill använda på bästa tänkbara sätt. Ofta har jag en grundtanke. En idé om struktur och funktionalitet. Dessutom har jag läst på om olika content management system (publiceringssystem), men är osäker på vilket som passar bäst för min verksamhet. Jag vill självklart ha så många besökare som möjligt på min webbplats och jag vill att de snabbt och enkelt ska hitta vad de söker.

Det jag söker är någon som kan:

  • Hjälpa mig i valet av content management system – vilket/vilka fungerar för mina behov?
  • Vilka funktioner är lätta/svåra att implementera – hur ska jag prioritera? Vad ger mest för pengarna? Jämförelse mellan enklare/mer avancerade alternativ. Standardlösningar jämfört med specialare.
  • Hur lockar jag besökarna till min webbplats?
  • Hur får jag dem att hitta vad de söker?

När väl utvecklingsprojektet är igång är det viktigt att:

  • jag får statusrapporter om hur arbetet går
  • leverantören hör av sig om det dyker upp frågor och inte gör något förhastat
  • jag har möjlighet att komma med ändringar och korrigeringar
  • leverantören hjälper mig ta rätt beslut och göra vettiga prioriteringar för att undvika onödiga kostnader

Leverantören

En påläst beställare är optimalt. Någon som vet vad ett content managent system är och tanken bakom det. Det är dessutom en fördel om beställaren har ett begrepp om hur stor budgeten är. En webbplats för 200 000 kronor skiljer sig en del från en med en budget på 600 000 kronor.

Drömbeställaren har:

  • en fast budget (med viss töjbarhet)
  • funderat på mål och strategier
  • tankar kring funktionalitet, men är öppen för förslag
  • läst på och vet vad ett content management system är och hur det fungerar
  • insett att de själva är ansvariga för innehållet (om inte det ligger i projektet)
  • förståelse för att det inte är möjligt att komma med alltför stora ändringar när programmeringen väl är igång, utan inser att sånt får komma i kommande versioner av webbplatsen
  • en vilja att tillsammans med mig som leverantör skapa en bra webbplats – det är inte endast mitt ansvar som leverantör

Slutord

De viktigaste lärdomarna jag fått med mig under alla de utvecklingsprojekt jag varit involverad i är:

  1. Som leveranrtör (oftast säljare, i vissa fall projektledare) – lova inget som du inte är helt 100 på att du kan hålla. Bättre att be att få återkomma och kolla upp fakta ordentligt.
  2. Som leverantör (programmerare/utvecklare) – säg inte att det går att göra exakt som beställaren vill ha det (á 80 timmars utveckling) om det går att göra något liknande som bara tar halva tiden…
  3. Som beställare – våga ställa krav på att leverantören ska förklara och visa hur t ex content management systemet fungerar (men var beredd på att det kostar konsulttimmar)
  4. Som beställare – när du kommer med förändringar som inte finns med i offerten/projektplanen – var medveten om att både tidsplan och kostnad påverkas. MEN – våga ta upp det ändå om det är viktigt för att lyckas med webbplatsen.

Det här var mina tankar och åsikter. Ser fram emot feedback, input och kanske ett och annat exempel på lyckat/misslyckat webbprojekt…

Glad påsk!!

Leverantör vs beställare i webbprojekt – vem ska leda och vems är ansvaret?

25 Mar

Det kan låta som en rätt självklar fråga. Klart beställaren ska leda och styra arbetet. Eller? Kanske bör proffset – leverantören (konsulten) – leda istället?

Jag har sprungit på ovana beställare ett antal gånger under min karriär. Både när jag själv suttit på beställarsidan och haft kollegor som varit ovana beställare av webbplatser och som konsult. För att ett projekt ska lyckas tror jag att det krävs ett gemensamt ansvar.

Beställarens ansvarsområden

  • Vara tydlig med sina önskemål
  • Vara öppen med krav vs. ”nice to have”
  • Vara påläst kring det system som köps in
  • Vara tydlig med tidsram och budget
  • Inte komma med ändringar efter tagna beslut – försenar projektet och påverkar tidsplan och kostnad
  • Bistå i utvecklingsarbetet – finnas tillgänglig för frågor
  • Testa och godkänna den webbplats som levereras

Leverantörens ansvarsområden

  • Lyssna på beställaren
  • Konkretisera beställarens önskemål och ta fram tids- och kostnadsuppskattning (offert)
  • Stödja beställaren i dennes arbete med att sätta sig in i det system som beställs, förklara funktionalitet osv
  • Ta fram en tydlig dokumentation som beskriver vad som ska utvecklas – funktionsspecifikation
  • Hålla kunden informerad om projektstatus och eventuella risker och förseningar
  • Testa webbplatsen för att säkerställa att det som utvecklats är det som kunden beställt
  • Korrigera fel, brister, missar
  • Leverera en väl fungerande webbplats

Jag har säkert glömt vissa saker i listningen ovan. Mitt syfte är inte att vara komplett på något sätt, utan visa att det varken är mitt ansvar som konsult eller ditt ansvar som beställare att ett webbprojekt blir lyckat. Vi måste tillsammans ansvara för att det slutgiltiga resultatet blir korrekt och att utvecklingsprocessen går framåt. Både leverantör och beställare måste ha en viss ödmjukhet och lyssna på motparten, samtidigt som det är viktigt att vara tydlig och rak med det som gäller. God kommunikation är nyckeln till succé i mina ögon.

Och hur var det med det där att leda? Jo, jag som projektledare på konsultföretaget leder mitt utvecklingsteam och beställarens projektledare leder kundens interna arbete. Vi jobbar parallellt och stämmer av kontinuerligt för att fånga upp alla lösa frågor och hålla koll på tidsplan och budget. Låter enkelt här, men ofta är det lite mer komplicerat i verkligheten…

Håller du med mig i mitt resonemang eller har du andra funderingar? Hör gärna av dig!

Rekommendera CMS – vad avgör?

18 Feb

I samband med mitt inlägg om att välja CMS hade jag en diskussion på Twitter med @yttergren.  I korthet gick den ut på att Daniel Yttergren ansåg att vi som EPi-partner alltid skulle rekommendera EPiServer CMS eftersom våra utvecklare kan systemet. Oavsett om det finns andra system som också skulle uppfylla kundens krav…

Det här fick mig att fundera. Nu har vi i och för sig ett CMS för mindre företag (enklare webbplatser) som inte vill investera ett par hundratusen, men det finns ju kunder som vill ha ett kompetent CMS utan att betala licenspengar. Open source med andra ord. Umbraco är ett system som en utvecklarkollega tipsade om (och som även Daniel tog upp som exempel på open source-alternativ) och som jag nu försöker sälja in hos mina andra kollegor. Eftersom det är baserat på Microsoft ASP.NET på samma sätt som EPiServer så finns det inte samma hinder jämfört med att t ex ge sig i kast med Drupal.

Jag tror, precis som jag skrev i diskussionen på Twitter, att leverantören självklart kommer rekommendera ett system som man behärskar och vet att man kan leverera. Det finns inget syfte att rekommendera ett CMS som man inte själv kan bygga. Däremot tänker jag inte ge mig in i en disskussion kring vilket CMS som kunden ska erbjudas.

Själv försöker jag  matcha mitt erbjudande med vad kunden önskar, vilket är anledningen till att jag är nyfiken på Umbraco. Det krävs ett breddat erbjudande för att täcka in de behov, önskemål och krav som kunderna kommer med.

Nöjda kunder – vårt levebröd.

Hur väljer du CMS?

12 Feb

Häromdagen var jag på ett kundmöte tillsammans med en kollega och en kollega från ett bolag vi jobbar en del med i olika projekt. Vi föreslog EPiServer CMS 5 som plattform för kundens nya webbplats, bl a eftersom vi är EPiServer Solution Partner och för att vi med hjälp av EPi som plattform skulle kunna täcka kundens behov och önskemål. Jag hade gått  igenom den önskelista som kunden tagit fram och matchade den mot funktionerna hos EPiServer CMS 5 när jag skrev ihop offerten. Lyckades täcka in alla önskemålen.

Historien hade kunnat sluta där om det inte varit för den diskussion som vi ”leverantörer” höll på väg tillbaka till kontoret efter mötet. Varför rekommenderade vi (läs ”ni”) egentligen EPiServer? Frågade vår utomstånde kollega/partner. Jag blev lite ställd av frågan, men eftersom vi är Solution Partner så… Vad är alternativet? Ja, med tanke på den debatt som rasade i november kring CMS-val så är ju frågan inte helt främmande.

Det som dock till syvende och sist styr vilket CMS en webbyrå/IT-leverantör väljer att erbjuda måste ju handla om vilken kompetens företaget besitter. Blir ju svårt annars, eller hur?

Du vill ha en ny CMS-baserad webb – hur väljer du?

Om vi lämnat konsultsidans syn på CMS och tittar på hur du som kund väljer CMS.

Jag har varit med om allt från tre A4-sidor som bakgrundsmaterial till en mindre avhandling på uppåt 100 sidor (i och för sig med skärmdumpar och skisser, men ändå). Ibland heter det ”vi vill ha en ny, snygg sajt”, ibland ”vi vill kunna koppla på system X, Y och Z – det är väl inga problem?”.

Större företag och myndigheter gör ofta en ganska ordentlig utredning och ser över både ekonomiska aspekter såväl som vilka funktioner det tänkta CMS:et har/ska ha.

Användbarhet och integrationsmöjligheter kan också hamna högt upp på listan. I en stor organisation med många inblandade som ska arbeta med innehållet på webbplatsen är det viktigt att verktyget är lätt att arbeta med. Ett intranät kan ha en mängd underliggande system som det kommunicerar med – ärendehantering, dokumenthantering mm. Det är en hel del att ta ställning till med andra ord.

Tips inför CMS-valet

Om du står i begrepp att investera i en ny CMS-baserad webbplats rekommenderar jag dig att tänka till ordentligt. Ju mer tid och tankekraft du lägger ner innan du tar kontakt med en leverantör, desto mer korrekt tids- och kostnadsuppskattning kommer du få.

Att tänka på:

  1. Hur ska webbplatsen användas?
    Är det en företagswebb med enkla informationssidor och kontaktformulär, eller vill du kunna koppla på diverse sociala medier, e-handel, integrera med affärssystem osv?
  2. Vem ska arbeta med webbplatsen?
    Har du tänkt att marknadsassistenten ska sköta allt på webben, eller är det en decentraliserad organisation med 40 webbredaktörer, utspridda geografiskt? Krävs det en webbutbildning eller ska vem som helst kunna uppdatera innehållet?
  3. Budgeten?
    Det är en väsentlig skillnad mellan att spendera 100 000, eller 500 000, eller för den delen – 1 000 000 kronor. Inte så att det blir bättre ju mer du spenderar, men med liten budget kan du tvingas avstå från alltför komplicerade integrationer.
  4. Teknikpartner eller helhetslösning?
    Det är lätt att fastna i att bara tänka webbutveckling och teknik, men du kanske behöver hjälp med annat också i samband med bygget av din nya webbplats? Hur är det med webbstrategi, kommunikation, marknadsföring, analyser osv osv?

Jag skulle tro att det på sätt och vis är lättare att bygga en bra webbplats idag eftersom system och verktyg är mycket mer kompetenta, men det är samtidigt mycket svårare att välja eftersom urvalet är så stort…

Hör gärna av dig om du har frågor eller funderingar. Lycka till med din nya webbplats!

http://www.episerver.com/sv/partners/

Välja webblösning – skräddarsytt eller paketerat?

21 Jan

Du har säkert sprungit på företag som säger sig erbjuda ”skräddarsydda” webblösningar. Har du funderat på vad det innebär? Vad är motsatsen? Oskräddarsydd, eller kanske paketerad?

Första gången jag på allvar kom in i en diskussion om just skräddarsydda webblösningar vs paketerade lösningar var hos en fd arbetsgivare.  Vi ville skapa en intranätslösning som skulle vara ett slags ”baspaket” för medelstora företag. Lösningen skulle byggas i EPiServer CMS 5 och alternativen för kunden skulle vara rätt begränsade – för att inte fördyra utvecklingsprojektet.

Rent ekonomiskt var det en bra affär för kunden, liksom för oss. Kunden skulle spara tid för implementationen eftersom det nya intranätet som de beställde var en ren kopia av vårt ”intranätspaket”, vilket gjorde att ett intranätsprojekt kunde drivas igenom förhållandevis snabbt. Sparad tid innebär en ekonomisk besparing. Även för oss låg vinsten i en snabb implementation och dessutom gjorde vi en rätt bra vinst eftersom vi visste hur lång implementationstiden var och sen erbjöd kunden ett fast pris som låg något över. Win-win. Eller, ja, nästan i alla fall.

What’s the catch? Att säga att man säljer en paketerad lösning anses inte lika ”fint” som att erbjuda skräddarsydda lösningar. Vårt intranätsprojekt lades på is med andra ord.

CMS – skräddarsydda eller paketerade?

Det är framför allt EPiServer som jag jobbat med och där jag vet vilka möjligheter som finns, men i teorin är det inga större skillnader mellan olika system.

Grundtanken med ett CMS är att en webbplats byggs med olika typer av sidmallar och att kodning och innehåll därigenom hålls särskilda – hence ”content management system”. EPiServer CMS 5 har en mängd olika mallar som kan anpassas och dessutom har olika EPi-partners utvecklat egna add-ons.

Men, är EPiServer skräddarsytt eller paketerat? Jag skulle vilja säga att det beror på vilken EPi-partner du har och hur denna valt att sälja in lösningen. Som jag beskrev ovan med ”intranätspaketet” går det att paketera EPi, men det är inte alltid vad kunden är ute efter. Med t ex Collaborate och Engage kan du komma rätt långt med hjälp av t ex bloggar och olika integrationer mot affärssystem. Du kommer aldrig kunna få en 100% skräddarsydd lösning med hjälp av EPi, men det är fullt möjligt att få en lösning som är unik och som uppfyller dina behov. Och det räcker väl rätt långt, eller hur?

Nu vill inte jag argumentera om vilket CMS som är ”bäst”. Den diskussionen kommer aldrig komma till stopp, utan det påminner mig mest om Mac vs PC…

Slutsats

Det går både att sälja en paketerad CMS-lösning om man så vill, eller att prata om skräddarsydda lösningar – så länge både beställaren och leverantören är ense om vad som menas med respektive begrepp.

Finns det en optimal projektprocess?

16 Dec

Sen jag började jobba med projektledning för snart tio år sedan har jag av och till funderat kring det där med projektprocesser och projektmodeller. Som jag skrivit tidigare om projektmodeller så finns det rätt många som alla har sina för och nackdelar, PROPS, RUP, scrum osv. Det jag ibland känner att jag saknat är en projektprocess.

Om jag ska vara ärlig så tycker jag ibland att det är svårt att helt skilja projektmodeller från projektprocesser. En process för mig uttrycker någon form av riktning, medan en modell är mer statisk och visar ett antal faser och steg som ska gås igenom under projektets gång (som i och för sig också rör sig i en rikting, men inte lika uttalat som processen…). Efter att ha letat runt efter nåt som stödjer min tes måste jag tyvärr erkänna mig något besegrad. Det finns inte så stora skillnader och framför allt används samma begrepp. T ex använder den projektprocess som beskrivs hos Smartbiz ”faser”:

Projektprocessen delas ofta in i olika faser. En vanlig indelning är:

  • Projektidé
  • Pilotprojekt/förstudie
  • Uppstart
  • Genomförande
  • Avslut/rapportering/avlämning

Fortfarande måste jag dock hålla fast vid att jag tycker att en process uttrycker en riktning på ett sätt som jag inte helt finner i en ”typisk” projektmodell.

Hur ser du på det här med projektprocesser?

Finns det en optimal projektprocess? Hur ser den ut?

Hur får du dina projekt att lyckas, dvs leverans på tid (till budget), med nöjda projektmedarbetare och nöjd kund?

Jag lutar åt en förhållandevis enkel process i enlighet med den ovan, men som måste anpassas efter hur ett ”normalprojekt” ser ut i just min verksamhet. Vad tror du?

← Äldre inlägg
Nyare Inlägg →

Följ

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