1. No category

Maj 2015 Agility in IT-­‐projects Forfattere: Simon Berg Andersen 201207638 Stefan Bay-­‐Hahn 201207631 Vejleder: Søren Erik Nielsen Antal tegn u. Mellemrum: 151.342 A a r h u s S c h o o l o f B u s i n e s s a n d S o c i a l S c i e n c e s D e p a r t m e n t o f B u s i n e s s A d m i n i s t r a t i o n Simon Berg Andersen Stefan Bay-­‐Hahn Executive summary Today's businesses invest a lot of resources in implementing IT-­‐systems. IT is the backbone of every big business and it is a competitive tool in all industries. Beginning an IT-­‐project is easy, finishing it successfully, has a way different level of difficulty. To undertake this challenge, a large variety of development models have been developed over time. This thesis is focusing on agile development models. They are used in a wide range of small and big projects all over the world. Even though the models should give a how-­‐to guideline, many of the projects still end up failing. This brings up the research question of this assignment: “Based on a self developed analysis model the assignment will analyze, how a small and a big IT-­‐project has attained success with agile development models.” By this question and through the assignment we want to examine how the project's size affects the agility of the project, even though the fundamental basis of the projects is agile development. To answer the question above, a qualitative study of a small and a big agile project in the private sector in Denmark has been undertaken. The empirical data has been collected by semi-­‐structured interviews with a representative from each of the two examined projects. This also means that the result of this analysis is only evidence for the two specific projects and therefore not a general conclusion. The collected data has been analyzed by our own developed analysis model. This model is created upon the theory of critical success factors from Nah & Delgado (2006) and Chow & Cao (2008). The model contains ten different critical success factors that we find significant to the success of an agile IT-­‐project. These factors have been analyzed to examine how the two projects attained success with agile development models. The primary theory on agile project development models/methods used in the thesis has been derived from the work of The Agile Alliance (2001) with the Agile Manifesto and the principles behind it. The two cases that have been examined are the big Apollo Project accomplished by Dansk Supermarked, and the small project for the outdoor furniture company Gloster accomplished by the consultancy Klean. The projects differ from each other in both size and complexity. The result of the analysis shows that there is a significant difference in how a big and a small project succeed with agile development. The big project has to make several dodges to succeed with agile development models, whilst the smaller project is able to follow one specific project development model. The biggest difference lies within the critical success factors, Business process reengineering, User involvement, Implementation and Requirements. Dansk Supermarked has to use a lot more resources in preparing their organization for the implementation in comparison to the small project by Klean. In addition to that, the analysis shows that the big project can’t stick to one specific agile development Side 2 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn model, but has to work with situational models that include traditional development models. The critical success factor User involvement was fulfilled in the big project by incorporating the users in the project group, where the small project just needed close contact to the users. The implementation in the small project was radically different from that in the big project. Klean implemented the system in small steps in the whole organization in Gloster. In addition to that Dansk Supermarked implemented the system by product category across the organization. A very important dodge in the fulfillment of the critical success factor Requirement in the project was detected in the analysis. Dansk Supermarked acknowledged that they could not determine all requirements of the system during the Apollo project. Therefore they aligned the expectation of the system with the business organization to an 80% solution. This was a fundamental reason for their success. Several other dodges was detected as well. Side 3 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Indholdsfortegnelse Executive summary .................................................................................................................................. 2 1 Indledning ................................................................................................................................................ 6 1.1 Problemstilling ............................................................................................................................................... 6 1.2 Formål ............................................................................................................................................................... 7 1.3 Afgrænsning .................................................................................................................................................... 7 2 Definitioner ............................................................................................................................................. 8 2.1 Projektudviklingsmodel .............................................................................................................................................. 8 2.2 Agil ........................................................................................................................................................................................ 8 2.3 Analysemodel .................................................................................................................................................................. 8 2.4 Leverance .......................................................................................................................................................................... 8 2.5 Implementering .............................................................................................................................................................. 8 2.6 Udrulning ........................................................................................................................................................................... 8 2.7 Milepæle ............................................................................................................................................................................. 8 3 Metode ....................................................................................................................................................... 9 3.1 Interview ....................................................................................................................................................... 10 3.2 Opgavens fremgangsmåde ....................................................................................................................... 10 4 Præsentation af cases ......................................................................................................................... 10 4.1 Dansk Supermarked -­‐ Apollo .................................................................................................................. 10 4.2 Klean – Gloster ............................................................................................................................................. 11 4.3 Valg af cases .................................................................................................................................................. 11 5 Teori ......................................................................................................................................................... 13 5.1 Projektudviklingsmodeller ..................................................................................................................... 13 5.1.1 Scrum ............................................................................................................................................................................ 13 5.1.2 Rapid Transformation (KPS Consulting) ...................................................................................................... 15 5.2 Egenudviklet analysemodel .................................................................................................................... 15 5.2.1 Projektfaser ............................................................................................................................................................... 16 Figur 1 – Projektfaser (Egen tilvirkning) ............................................................................................................................... 16 5.2.2 Kritiske succes faktorer ........................................................................................................................................ 17 Figur 2 -­‐ Egenudviklet analysemodel (Egen tilvirkning) ................................................................................................. 18 5.2.2.1 Forretningsplan og Vision ............................................................................................................................................. 18 5.2.2.2 Kravspecifikation ............................................................................................................................................................... 18 5.2.2.3 Definer milepæle ............................................................................................................................................................... 19 5.2.2.4 Opfølgning af milepæle ................................................................................................................................................... 19 5.2.2.5 Omfattende test .................................................................................................................................................................. 19 5.2.2.6 Udrulning .............................................................................................................................................................................. 19 5.2.2.7 Uddannelse og træning ................................................................................................................................................... 20 5.2.2.8 Omstrukturering af forretningsprocesser .............................................................................................................. 20 5.2.2.9 Brugerinddragelse ............................................................................................................................................................ 20 5.2.2.10 Projekt management og organisering .................................................................................................................... 20 5.2.3 Fravalg af faktorer .................................................................................................................................................. 21 6 Empiri ...................................................................................................................................................... 21 Side 4 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 7 Analyse .................................................................................................................................................... 22 7.1 Forretningsplan og vision ........................................................................................................................ 22 7.2 Kravspecifikation ....................................................................................................................................... 24 Figur 3 -­‐ Projekttrekant (Egen tilvirkning) ........................................................................................................................... 27 7.3 Definer milepæle ........................................................................................................................................ 28 7.4 Opfølgning af milepæle ............................................................................................................................. 31 Figur 4 -­‐ Tragt model (Frederiksen, 2015) (Egen tilvirkning) ....................................................................................... 33 7.5 Omfattende test ........................................................................................................................................... 34 7.6 Udrulning ...................................................................................................................................................... 38 Figur 5 -­‐ Taktisk gennemførelse af implementeringen (Attrup & Olsson, 2012, side 267, figur 8.4) ........... 39 7.7 Uddannelse og træning ............................................................................................................................. 43 7.8 Omstrukturering af forretningsprocesser ......................................................................................... 45 7.9 Brugerinddragelse ..................................................................................................................................... 48 7.10 Projekt management og organisering .............................................................................................. 49 Figur 6 -­‐ Organisationsdiagram over projektgruppen (Egen tilvirkning) .............................................................. 54 8 Diskussion .............................................................................................................................................. 58 9 Konklusion ............................................................................................................................................. 59 10 Perspektivering ................................................................................................................................. 62 11 Referenceliste .................................................................................................................................... 63 12 Bilag ....................................................................................................................................................... 65 12.1 Bilag 1 – Interviewguide ........................................................................................................................ 65 12.2 Bilag 2 – Interview med Lars Mosbek ............................................................................................... 68 12.3 Bilag 3 – Interview med Martin Frederiksen .................................................................................. 86 Side 5 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 1 Indledning En undersøgelse af større IT-­‐projekter har vist at hver sjette projekt fejler med store tab som følger heraf (Loiborg, 2011). Eksempelvis tab af økonomiske ressourcer eller effektiviseringstab som følge af, at den effektivisering IT-­‐projektet skulle bringe med sig udebliver. De fejlslagne IT-­‐projekter er et problem for brugerne, virksomhederne, investorerne, leverandørerne og samfundet som helhed. Et IT-­‐projekts succes afhænger af mange forskellige faktorer, en af dem er måden hvorpå projektets udvikling struktureres, med andre ord hvilken projektudviklingsmodel der anvendes. Alt efter valg af udviklingsmodel giver dette nogle muligheder og begrænsninger for de involverede parter. Hvorvidt et IT-­‐projekt er styret udelukkende af virksomheden selv, eller om det er et IT-­‐konsulenthus, der udfører projektet for virksomheden, er en projektgruppe afhængig af en form for struktur for at kunne styre projektet. Mange vælger her en af de veldokumenterede og afprøvede projektudviklingsmodeller til at strukturerer projektet. Grundet den store udvikling inden for IT-­‐løsninger, udvikler måden hvorpå IT-­‐projekter bliver udført sig også. Derfor findes der i dag flere forskellige projektudviklingsmodeller beregnet til strukturering og styring af et IT-­‐projekt. Et korrekt valg at projektudviklingsmodel synes at være kritisk for at et IT-­‐projekt ender med at blive en succes. Al erfaring viser at IT-­‐projekters kompleksitet stiger år for år. Derfor vil denne udfordring fortsat være til stede fremadrettet. 1.1 Problemstilling Som nævnt indledningsvist er det uden tvivl et stort problem for virksomhederne, store som små, når deres IT-­‐projekter fejler. Hvad enden det er en fejlleverance, budgetoverskridelse eller forsinket levering der lægges til grund for fejlen. Flere IT-­‐projekter ville formentlig kunne reddes med korrekt brug af en projektudviklingsmodel, men er korrekt brug af en projektudviklingsmodel afhængigt af projektets størrelse? Uafhængigt af projektudviklingsmodel er det en stor nødvendighed at opfylde forskellige succeskriterier i forbindelse med IT-­‐projekter. Dette for at mindske sandsynligheden for at projektet fejler, men understøtter projektudviklingsmodellerne opfyldelse af succeskriterierne og hvordan? Svaret på disse spørgsmål vil have en væsentlig betydning for, hvilken model virksomheden vælger i forhold til det projekt, der skal udføres og hvilke succeskriterier, der lægges vægt på i den pågældende organisation. Der er således ikke uddybende klarhed over, betydningen af brugen af projektudviklingsmodel i forhold til succeskriterierne inden for IT-­‐projekter. Der findes en Side 6 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn lang række litteratur på området, men ikke noget sammenfattende. Det er denne mangelende sammenfatning af litteratur der danner grundlaget for opgavens emne. Ud fra ovenstående problemstilling er der opsat følgende problemformulering: Med udgangspunkt i en egen udviklet analysemodel vil opgaven analysere, hvordan et lille og et stort IT-­‐projekt har opnået succes med agile udviklingsmodeller. 1.2 Formål Formålet med denne opgave er at belyse, hvordan der uafhængigt af et projekts størrelse kan opnås succes ved brug af de agile projektudviklingsmodeller. Vi er igennem studiet ved Aarhus School of Business and Social Sciences blevet introduceret for forskellige modeller til at strukturer et IT-­‐projekt. Herunder de agile projektudviklingsmodeller, som over de seneste årtier langsomt har vundet mere og mere indpas i IT-­‐projekterne. Faktum er dog at der til stadighed ofte opstår eksempler på IT-­‐projekter, store som små, der fejler med store tab til følge. Igennem denne opgave ønskes det at belyse, hvordan de agile modeller hjælper til at store som små projekter bliver succeser. Denne indsigt håber vi at kunne gøre brug af i vores resterende studietid og hvis vi engang i fremtiden, står overfor at skulle arbejde med en projektudviklingsmodel. 1.3 Afgrænsning I forhold til et IT-­‐projekts faser er der valgt en positiv afgrænsning til de fire faser; Ide og beslutning, Planlægning, Gennemførelse og Aflevering. En projektgruppes arbejde inden for de nævnte fire faser er i høj grad påvirket af den valgte projektudviklingsmodel og er således interessante at analyserer i denne opgave. Det har desværre ikke været muligt, at få en uddybende forklaring om modellen Rapid Transformation, da KPS Consulting ikke ønskede at offentliggøre informationer herom. Dette har givet en begrænsning i forhold til indsigten i de anvendte værktøjer og fulgte principper. Side 7 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 2 Definitioner I det nedenstående defineres en række begreber, som er med til at sætte en sproglig ramme for opgaven med den hensigt, at undgå misforståelse og forvirring. 2.1 Projektudviklingsmodel Der arbejdes i opgaven med projektudviklingsmodeller. Det defineres som et paraplybegreb for de mange forskellige udviklingsmodeller som Vandfaldsmodellen, Spiralmodellen og SCRUM. Projektudviklingsmodellerne bruges til at strukturere udviklingsfaserne i et projekt. 2.2 Agil I opgaven anvendes begrebet agil, i forbindelse med beskrivelse af en bestemt gruppe af projektudviklingsmodeller, nemlig de agile projektudviklingsmodeller. Fælles for projektudviklingsmodellerne i denne gruppe er, at de introducerer en arbejdsform, hvor tværfunktionelle og selvorganiserende teams samarbejder om udviklingen af krav og løsninger. Der arbejdes i korte inkrementelle intervaller, hvori der itereres over løsningen. 2.3 Analysemodel Når der i opgaven snakkes om og anvendes en analysemodel, menes der et metodisk redskab til at strukturere en analyse. Ved anvendelse af en analysemodel på flere cases fås en fælles reference, som der på overskuelig vis kan sammenlignes over. 2.4 Leverance En leverance ses som en eller flere færdige og gennemtestede dele af et IT-­‐system. Næste logiske skridt er, at leverancen skal implementeres. Således kan en leverance forstås som en færdig ”pakke” indeholdende en eller flere dele af et IT-­‐system, som er klar til at blive sendt ud til kunden. Når pakken ankommer til kunden, skal den pakkes op og tages i brug, denne del klares under implementeringen. 2.5 Implementering Implementering defineres som det arbejde, der knytter sig til at bringe en eller flere dele af et IT-­‐system i brug. 2.6 Udrulning Udrulning defineres som værende en underkategori til implementering, som indbefatter installeringen af systemets software og hardware. 2.7 Milepæle En milepæl markerer opfyldelsen af en signifikant aktivitet i projektet og dermed dennes gennemførsel. Milepælene fastlægges som en del af projektets planlægning. De bruges til at overvåge projektet, og de viser tydeligt, om projektet følger tidsplanen eller er bagud. Milepæle kan knytte sig til større eller mindre aktiviteter. Derudover kan milepælene knytte sig til aktiviteter der sker indenfor projektgruppens rammer eller aktiviteter, der også påvirker brugerne som eksempelvis en implementering. Side 8 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Det skal nævnes at der i opgaven flere steder anvendes engelske ord og begreber. Det er undladt at oversætte disse, da det vil kunne skabe unødvendig misforståelse og forvirring. 3 Metode Følgende afsnit vil beskrive opgavens anvendte metode til besvarelse af problemformuleringen. Der vil i opgaven blive anvendt en problemorienteret tilgang. I opgaven ønskes det således at nå frem til et resultat, der kan afhjælpe det opstillede problem omkring, hvordan der opnås succes ved brug af de agile projektudviklingsmodeller. For at nå frem til dette resultat udvikles vores egen analysemodel, som kan passe på de udvalgte cases. Denne analysemodel vil blive udviklet på baggrund af eksisterende modeller og teorier. Først vil der blive redegjort for den anvendte teori. Herunder teori om projektudviklingsmodeller, som hjælper med at strukturerer IT-­‐projekter. Teorierne er valgt ud fra de cases som er behandlet i opgaven. Der vil således blive redegjort for teorierne bag de projektudviklingsmodeller, som primært har fundet anvendelse i de to analyserede cases. I opgaven er der behov for en fælles reference, der er gældende for både store IT-­‐projekter, som implementering af ERP systemer, men også for små projekter. For at kunne opstille denne fælles referenceramme tages der udgangspunkt i litteratur, der omhandler de store IT-­‐
projekter. Dette fordi denne litteratur er lettere at tilpasse til de mindre projekter, end det vil være at anvende litteratur om mindre IT-­‐projekter og tilpasse denne til store projekter. Der vil således blive redegjort for den litteratur, der danner grundlag for den egenudviklede analysemodel. Her er der taget udgangspunkt i artiklen ”Critical Succes Factors for ERP implementation and upgrade” (Nah & Delgado, 2006). Denne artikel sammenfatter en lang række litteratur på området og opstiller en række kritiske succes faktorer (KSF) for implementering og opgradering af ERP systemer. Den fungerer således som udgangspunktet for vores valg af kritiske succes faktorer. Med dette udgangspunkt udvides vores analysemodel med teori fra artiklen ”A survey study of critical succes factors in agile software projects” (Chow & Cao, 2007) for at gøre modellen mere alsidig. Udgangspunktet af analysemodellen udvides med denne artikel, da den har et agilt perspektiv på hvad der giver et udviklingsprojekt succes. Da begge cases i opgaven som udgangspunkt er agile er det vigtigt at have denne synsvinkel med i vores analysemodel. Artiklen fra Chow & Cao er ligeledes en sammenfatning af forskellige litterære værker, hvorfra der er fundet inspiration til fejlfaktorer og succes faktorer. Herpå er der foretaget en statistisk analyse. Side 9 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Fra de to ovenstående artikler uddrages en række faktorer, som finder særlig relevans ved analyse af IT-­‐udviklingsprojekter, store som små. 3.1 Interview Til indsamling af empiri vil der blive anvendt kvalitative interviews. De vil blive udformet på baggrund af den egenudviklede analysemodel. De enkelte interviews vil blive gennemført med en middel grad af struktur, således at strukturen i interviewet bevares, og der sikres svar på de spørgsmål der ønskes besvaret. Derudover gives der plads til at respondenten kan fremhæve elementer, som denne finder relevant og give uddybende svar, der bevæger sig en smule væk fra det egentlige spørgsmål, såfremt det har relevans. 3.2 Opgavens fremgangsmåde Først præsenteres de to udvalgte cases. Dette vil blive gjort for at give et indblik i og en begrundelse for valget af de to cases og dermed en forståelse for den baggrund teorierne er valgt ud fra. Herefter vil der blive redegjort for den anvendte teori omkring projektudviklingsmodeller, for at belyse den teoretiske baggrund for den senere analyse. Som en del af teoriafsnittet er også forklaring og begrundelse for den egenudviklede analysemodel. Analysemodellen danner baggrund for den indsamlede empiri og den efterfølgende analyse af de to cases. Før analyseafsnittet vil der være en kort præsentation af empirien, indsamlet fra interviews. Analyseafsnittet er delt op efter de ti kritiske succes faktorer, præsenteret i analysemodellen. Ved hver KSF vil der blive introduceret uddybende teori omkring emnet. Derefter vil der blive analyseret på den indsamlede empiri på baggrund af denne teori. Til sidst vil der være en delkonklusion på den enkelte kritiske succesfaktor. Dette bliver gjort for at strukturer analysen og gøre den mere overskuelig. Den samlede analyse af alle ti KSF’er rundes til sidst af med en endelig konklusion for at besvare problemformuleringen. Resultatet vil til sidst blive perspektiveret således, at opgavens resultat bliver sat i et større sammenhæng. 4 Præsentation af cases I den nedenstående afsnit vil de to udvalgte cases kort blive præsenteret. Derudover vil der blive argumenteret for deres relevans i forhold til denne opgave. 4.1 Dansk Supermarked -­‐ Apollo Dansk Supermarked (DS) er Danmarks største detailvirksomhed, og driver 1400 butikker i fem lande. Hver eneste dag forsyner koncernen 1,4 millioner kunder, hvilket giver en årlig omsætning på cirka 57 mia. Kr. (Dansk Supermarked, 2015 B) Side 10 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn DS har igennem en længere årrække arbejdet på et af de største IT-­‐projekter i retail branchen i Danmark nogensinde. Det omhandler implementeringen af SAP på tværs af alle deres butikker og alle lande de opererer i. Apollo projektet startede i 2010, som en udmøntning af strategien om, at hele organisationen skulle operere på det samme standardsystem, nemlig SAP. Projektet sluttede officielt i september 2014. En 150 mand stor projektgruppe arbejdede gennem perioden på projektet. Eksterne konsulenter blev hentet ind fra hele verden, for at hjælpe DS med dette projekt, som er et af de større målt på projektgruppens størrelse og antallet af brugere. Hovedpartneren der støttede DS i projektet var det tyske konsulenthus KPS Consulting (KPS), der med deres agile Rapid Transformation (RT) model hjalp DS succesfuldt igennem projektet. Projektet ses som et agilt projekt fra Dansk Supermarkeds side, men det har i nogle tilfælde været nødvendigt at anvende mere vandfaldsorienterede tilgange i projektet. 4.2 Klean – Gloster Klean er et mindre Dansk konsulenthus placeret i Aarhus, der har specialiseret sig i digitale projekter og softwareløsninger. I denne opgave tages der udgangspunkt i en konsulentopgave de har lavet for det engelsk baserede havemøbelfirma Gloster. Glosters ønske var at få en hjemmeside, der fortalte historien bag deres eksklusive møbler til deres kunder. Desuden skulle hjemmesiden gøres klar til fremtidig E-­‐commerce og kunne bruges som et grundlag for fremtidig online markedsføring. Dermed var der lagt op til et projekt, der ikke bare omhandlede en hjemmeside, men også et bagvedliggende analyse system som blandt andet skulle kunne måle kundeadfærd, således at online markedsføring kunne målrettes. Til dette projekt anvendte Klean en agil udviklingsmodel, for at udvikle den rigtige hjemmeside og et system med de funktioner, Gloster efterspurgte. 4.3 Valg af cases De to projekter der er valgt at analysere, er markant forskellige set i forhold til flere parameter. Først og fremmest er projekternes størrelse markant forskellige. Dansk Supermarkeds udrulning af en ERP løsning på hele deres retail område, var et meget stort projekt, hvor der var over 25.000 brugere. Set i forhold til dette var Kleans projekt for Gloster meget lille, med kun fem brugere. Derudover var løsningen til Gloster ikke et stort ERP system, men derimod ”blot” en ny hjemmeside, en produktdatabase og et værktøj til at kunne foretage analyser til brug i deres online markedsføring. Derudover leverede Klean også meget rådgivning i at lægge strategier og i at udføre online markedsføring. En anden parameter, hvor de to cases adskiller sig fra hinanden er kunde-­‐leverandør forholdet. Dansk Supermarked har selv oprettet en projektgruppe, hvoraf halvdelen af pladserne er bemandet af medarbejdere fra Dansk Supermarked og den anden halvdel er eksterne konsulenter. Gloster har derimod hyret konsulenthuset Klean til at levere en løsning Side 11 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn og har ikke selv medarbejdere i projektgruppen. Klean skulle dog fungerer i et tæt samarbejde med Gloster og agere deres IT-­‐afdeling. I begge cases er der som udgangspunkt anvendt agile projektudviklingsmodeller. Klean er ekspert i brugen heraf, imens det for Dansk Supermarked er en ny arbejdsform og har præsenteret en række omstillingsudfordringer. Til at hjælpe dem med disse udfordringer og med at arbejde agilt, har de hyret det eksterne konsulenthus KPS, som stod for en stor del af projektgruppens eksterne konsulenter. På den måde fik DS den support der var nødvendig, for at skiftet til en agil arbejdsform blev en fordel og ikke en ulempe. Grunden til, valget af de to cases med deres indbyrdes forskelle er, at de giver to spændende indgangsvinkler til arbejdet med agile projektudviklingsmodeller, og hvordan det kan lykkes at få succes hermed. At de to løsninger, der skulle leveres var forskellige har ikke været af særlig betydning, da det ikke er løsningen, men derimod processen nærværende opgave har fokus på. At de to løsninger er forskellige har dog i dette tilfælde betydet, at der har været forskellige grader af kompleksitet i de to cases. Denne forskellighed har været interessant i forhold til opgaven, fordi den kan have betydning for, hvordan der arbejdes med udviklingsmodellerne. Begge projekter er omfattet af et tæt partnerskab mellem leverandør og kunde. Kleans rolle er at agere som Glosters IT-­‐afdeling. Det er Klean, der har oprettet projektgruppen og det er Klean, der anvender den agile projektudviklingsmodel. Således har de reelt bedre forudsætninger for at give os den empiri, der ønskes at analysere på, end Gloster har. Dansk Supermarked har selv oprettet projektgruppen og kan således ses som værende både kunde og leverandør. Dansk Supermarked har dog aktivt taget nogle valg, som har betydet at projektgruppen har fungeret som en selvstændig enhed. Således ses projektgruppen som værende ”leverandør” til Dansk Supermarked. Projektgruppen er sammensat af medarbejdere fra Dansk Supermarked og eksterne medarbejdere herunder KPS, som bragte deres egen projektudviklingsmodel til projektet. I begge tilfælde er det således mest relevant at snakke med en person fra projektgruppen, som har besiddet en management -­‐ eller lederstilling og dermed har indgående kendskab til projektet og de anvendte værktøjer og modeller til strukturering heraf. Side 12 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 5 Teori I de nedenstående afsnit vil der blive beskrevet teori til nogle af de overordnede emner og begreber, som der er anvendt i opgaven. Den specifikke teori, anvendt til analyse af hver enkelt KSF, er at finde i opgavens analysedel. Derudover vil den egenudviklede analysemodel blive introduceret og der vil blive redegjort for teorierne der ligger bag. 5.1 Projektudviklingsmodeller En projektudviklingsmodel bruges, som defineret, til at strukturere udviklingsfaserne af et projekt. De forskellige modeller giver hver deres bud på, hvordan der skal arbejdes med eksempelvis planlægning og management. Således forsøger modellerne at give redskaber til at sikre projektets succes. Traditionelt set er projektudviklingen delt ind i en række faser. Den traditionelle udviklingsmodel kaldes populært for vandfaldsmodellen. Den følger en streng sekventiel inddeling af faser. Her er der ingen iterationer tilbage til tidligere faser og modellen er kendt for at være meget tung på dokumentationssiden. Agile alternativer til vandfaldsmodellen begyndte at træde frem i 90’erne. I 2001 samledes ledende fortalere for de agile projektudviklingsmodeller for at diskutere netop de agile modeller og deres anvendelse. Resultatet af dette møde blev blandt andet, at fortalerne nåede til enighed om et fælles manifest for de Agile modeller. Af agile modeller kan nævnes Extreme Programming (XP), Scrum, Dynamic Systems Development Model (DSDM), Adaptive Software Development, Crystal Methods, Feature-­‐Driven Development, Pragmatic Programming m.fl. (The Agile Alliance, 2001 A). Fælles for dem er, at her arbejdes der i en iterativ udviklingsproces, hvor omdrejningspunktet er hyppig levering af fungerende software. Fokus er på at levere værdi til kunden og ændrede krav til systemet er velkomne og kan håndteres effektivt. Møder, helst face-­‐to-­‐face, er foretrukket frem for skriftlig kommunikation, hvilket resulterer i en nærmest fraværende kravspecifikation i sin traditionelle forstand. De to cases i denne opgaver har begge anvendt agile projektudviklingsmodeller eller elementer herfra. De to agile udviklingsmodeller der hovedsageligt anvendes vil blive beskrevet i de næste to afsnit. 5.1.1 Scrum Scrum er en agil projektudviklingsmodel, der introducerer en række værktøjer og ”best practices”, som tilsammen skal hjælpe med at styre et projekt. I Scrum inddeles projektet i en række intervaller kaldet sprints. Længden af et sprint kan varierer afhængigt af projektets størrelse, kompleksitet og projektgruppens præferencer, men der er generelt en præference for kortere perioder. Der arbejdes både iterativt og inkrementelt. Således vil der i et sprint Side 13 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn arbejdes med at udvide og forbedre løsningen fra forrige sprint, samt tilføje nye funktionaliteter. Målet for hvert sprint er at have en ny levering klar til udrulning. Det betyder at leveringen for sig selv skal være testet, men også i forhold til integrationen med resten af løsningen skal der være testet. Når der arbejdes efter Scrum modellen er der gode muligheder for at håndterer nye og skiftende krav, ønsker og behov fra kunden. Dette blandt andet fordi arbejdsopgaverne i et sprint først planlægges umiddelbart før sprintets start, og der derved er en god fleksibilitet i løsningerne heraf. I Scrum modellen introduceres en række roller. Tre af kernerollerne er ”product owner” (PO), ”scrum master” (SM) og ”development team” (udviklingsteam). En PO er projektets ejer og skal således sikre at kunden får en løsning med de ønskede funktioner og den ønskede effekt. Dermed sagt er det også her ansvaret ligger for, at der leveres den ønskede værdi. En SM er en facilitator, der skal sikre at udviklings teamet har hvad de skal bruge. Derudover har SM’en ansvaret for at de agile processer bliver fulgt og at værktøjerne i Scrum bliver brugt. Derudover står SM for afviklingen og styringen af de forskellige typer af Scrum møder. Udviklingsteamet er tværfunktionelt og selvorganiserende og har ansvaret for at udviklingen og implementeringen af de ønskede funktionaliteter. Et projekt, hvor Scrum er den valgte projektudviklingsmodel, er struktureret over en række møder og artefakter. En ”produkt backlog” er et dokument over de ønskede funktioner til løsningen. Funktionerne skal prioriteres i forhold til den værdi de giver for kunden. Det er PO’ens ansvar at denne artefakt vedligeholdes i løbet af projektet. Dette er aktuelt fordi det er meget realistisk, at kundens ønsker ændrer sig i takt med den indsigt de får gennem projektet. Ud fra denne ”product backlog” laves en ”realease backlog”. Det sker i planlægningen af den næste udrulning. Heri prioriteres de funktioner, fra ”product backlog”, som er ønsket som en del af den næste udrulning. Udover en prioritering laves en tidsestimering. Ud fra denne ”realease backlog” er der nu mulighed for, at tilrettelægge et antal sprints og hvilke funktioner, der skal arbejdes med heri. Dette dokumenteres i en ”sprint backlog”. Antallet af arbejdsopgaver der planlægges gennemført i et sprint afhænger af et begreb kaldet ”velocity”. ”Velocity” er et estimat for den mængde arbejdsopgaver et team kan gennemføre i et sprint, baseret på tidligere sprints gennemførte arbejde. Det er herefter udviklings teamets opgave at fordele opgaverne imellem sig, med coaching fra Scrum masteren. I løbet af et sprint holdes der daglige møder, for at overvåge udviklingen. Til at overvåge udviklingen bruges yderligere et såkaldt ”burndown chart”. Dette er en graf der viser tid overfor resterende arbejde i sprintet. Ved at bruge denne kan det i løbet af sprintet ses, hvordan teamet får arbejdet sig igennem den samlede arbejdsmængde i sprintet. Derved kan der også fås et estimat for, hvornår udviklingsteamet er færdige med opgaverne og således se om projektet overholder deadline. Med den viden kan der foretages eventuelle korrigerende handlinger. Efter et sprint afholdes et ”sprint review” møde, hvor der kigges på resultatet af sprintet. Dette møde afholdes så brugerne har mulighed på at give feedback på leverancen og forslag til yderligere ønsker til løsningen. Slutteligt afholder Scrum teamet et retrospektivt møde, hvor der reflekteres over, hvordan arbejdet er gået. Her kigges der både på om Scrum processer og Side 14 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn værktøjer er blevet anvendt succesfuldt, og der kan gives forslag til eventuelle ændringer. På den måde får teamet en mulighed for at udvikle sig og blive endnu bedre til deres arbejde. (von Wangenheim et al., 2013) 5.1.2 Rapid Transformation (KPS Consulting) Rapid Transformation er en model, som er udviklet af det tyske konsulenthus KPS, med hovedsæde i München. KPS er en virksomhed med 600 ansatte, som siden deres start i år 2000 har rådgivet store og mellemstore virksomheder i forretningsudvikling og procesforbedringer på handels-­‐ og forbrugsmarkedet. Ved RT modellen foregår strategiudvikling, procesdesign og implementering så vidt muligt parallelt. Samtidig integreres alle projektets niveauer og faser med hinanden således, at overgangen fra strategidefinition og procesmodellering til den afsluttende implementering bliver så let som mulig. Der fokuseres i høj grad på end-­‐to-­‐end processer, for at binde systemet rigtigt sammen i forhold til organisationen. ”Blueprints” bliver på ingen måde brugt. I stedet fokuseres der i høj grad på brugen af prototyper. De forskellige organisationsafdelinger og slutbrugerne bliver tidligt i processen en integreret del af projektet. Udviklingen af systemet foregår iterativt med gennemgang af prototyper for brugerne, som derved giver feedback som der kan arbejdes videre med. 5.2 Egenudviklet analysemodel En central del af denne opgave er den egenudviklede analysemodel, som anvendes til at analysere de to case studier (se figur 2). Analysemodellen skal opstilles således, at den kan bruges til analyse af både store og små IT-­‐projekter. Analysemodellen er bygget op efter teorien omkring et traditionelt projektforløb. Derefter er den tilpasset i forhold til, at den skal kunne fremstå som en general analysemodel til IT-­‐projektudviklingsmodeller. Denne fremgangsmetode er valgt for at holde fokus på at et IT-­‐projekt, stort eller småt, gennemgår det samme projektforløb og dermed de samme faser. For at kunne sammenligne de to projektudviklingsmodeller introduceres således en række projektfaser, som er gældende for både store og små projekter. Analysemodellen opstilles med projektfaser som en række vertikale siloer. Projekterne løber horisontalt igennem projektfaserne og gennemgår således de samme faser. Den horisontale linje repræsenterer dermed også den kronologiske rækkefølge for projektet. Det er gældende at et agilt projekt ofte vil gennemløbe faserne flere gange, med levering af flere små delelementer. Dette modsat den traditionelle vandfaldsmodel, som gennemløber faserne uden iterationer og leverer det færdige system i en eller enkelte del leveringer. Under projektfaserne introduceres en række kritiske succes faktorer. Når en KSF placeres under en fase, skal det forstås således, at der i denne fase arbejdes med denne KSF. Da nogle KSF omhandler emner der arbejdes på under flere af faserne, vil de blive trukket på tværs af flere faser. Således endes der ud med en egenudviklet analysemodel, som repræsenterer en fælles referenceramme til analyse af projekter af forskellig størrelse. Ved brug af analysemodellen er Side 15 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn det muligt at sammenligne projektudviklingsmodeller, indenfor relevante projektfaser, på baggrund af en række kritiske succes faktorer. Nedenfor vil der argumenteres for valget af projektfaser og kritiske succes faktorer inddraget i den egenudviklede analysemodel. 5.2.1 Projektfaser En projektfase ses som et forløb i projektet, hvor der arbejdes med at gennemfører en række opgaver. Resultatet af arbejdet udført i en fase er ens, uafhængigt af hvilken projektudviklingsmodel der anvendes og uafhængigt af projekts størrelse. Således er det muligt at sammenligne et projekt, der varer flere år med et projekt, der varer nogle måneder. Dog er det gældende, at de agile udviklingsmodeller ofte anvender en iterativ proces. Her gennemløbes projektets faser flere gange, da den samlede løsning deles op i mindre delløsninger. Dette er en fundamental del af de agile projektudviklingsmodeller. Figur 1 – Projektfaser (Egen tilvirkning) Overordnet set defineres faserne i et IT-­‐projekt ved følgende fem titler: Ide og beslutning, Planlægning, Gennemførelse, Aflevering samt Drift og evaluering, som det ses foroven i Figur 1. Der er valgt en positiv afgrænsning til de første fire faser og således ses der ikke på Drift og evaluerings fasen. Selvom det er en vigtig fase, som ikke må udelades i et projekt, findes det ikke relevant at se på denne, når vores primære fokus ligger på projektudviklingsmodeller. Da faserne skal bruges til at analysere projektudviklingsmodeller, uddybes nogle af dem yderligere, som det ses af pilene og den nederste række af faser i figur 1. Det gøres for at have et mere præcist fokus at analyserer på tværs af. Således er der fra fasen Gennemførelse fundet inspiration til at danne de mere præcise faser Krav, Udvikling samt Test. Fasen Aflevering har givet inspiration til den præcise fase Implementering. Derudover giver fasen Aflevering også inspiration til Test fasen. Således endes der ud med seks mere præcise projektfaser, inspireret fra de fire anvendte overordnede projektfaser. De seks præcise projektfaser ender dermed med følgende titler: Ide og beslutning, Planlægning, Krav, Udvikling, Test samt Implementering. Side 16 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 5.2.2 Kritiske succes faktorer KSF repræsentere de områder der skal gå godt og derfor tildeles opmærksomhed, for at sikre et projekts succes. ”Critical succes factors are those few things that must go well to ensure succes for a manager or a organization, and, therefore, they represent those managerial or enterprise areas that must be given special and continual attention to bring about high performance” (Boyton, Andrew C.; Zmud, Robert W; 1984) Der skal bruges KSF til at analysere projektfaserne for hver af de to projekter. Derfor er der brug for faktorer, der dækker over store projekter, men også faktorer der kan dække de mindre projekter. Da det er et forskningsområde i sig selv, at finde signifikante KSF for forskellige typer af IT-­‐projekter, er blikket blevet rettet mod den tilgængelige litteratur. Her er der fundet meget tilgængelig litteratur vedrørende KSF for IT-­‐projekter. Nah & Delgado’s (2006) ”Critical succes factors for ERP implementation and upgrade” giver en sammenfatning af KSF for ERP implementering, på baggrund af en større samling litterære værker indenfor området. Chow & Cao (2007) ”A survey study of critical success factors in agile software projects” foretager en statistisk analyse på baggrund af en række fejl-­‐ og succes faktorer benævnt i den dengang tilgængelige litteratur omkring agile projekter. Resultat af denne analyse er at tre overordnede kritiske succes faktorer findes signifikante for agile projekter. Derudover finder Chow & Cao yderligere tre faktorer som kunne være kritiske. Der er altså fundet to litterære værker der omhandler KSF for hhv. komplekse traditionelle ERP projekter og agile projekter. Opgaven vil sammenligne Dansk Supermarkeds store og forholdsvise agile ERP projekt, hvor de implementerer SAP med et mindre IT-­‐projekt hos Klean. Derfor er det fundet nødvendigt at være kritisk i udvælgelsen af KSF fra de to anvendte litterære værker. Dette fordi flere af de KSF ikke er relevante at undersøge, da de ikke er relevante målepunkter på tværs af de to projekter. Nah & Delgado finder frem til syv overordnede kategorier af KSF for ERP projekter, som tæller: 1. Business plan and vision, 2. Change management, 3. Communication, 4. ERP team composition, skills and compensation, 5. Project management, 6. Top management support and championship og 7. System analysis, selection and technical implementation (Nah &
Delgado, 2006, p.102). Under disse syv overordnede kategorier er der sammenlagt nævnt 50 KSF, som er inspireret og samlet fra 38 litterære værker. Artiklen kommer ikke nærmere ind på vigtigheden af disse KSF. Chow & Cao finder som nævnt frem til tre overordnede faktorer, som de finder belæg for at kalde KSF, med udgangspunkt i både fejl-­‐ og succes faktorer fra litteraturen. De tre KSF tæller, (a) Delivery strategy, (b) Agile software engineering techniques, and (c) Team capability. Udover disse tre faktorer, som de kalder KSF, finder de tre yderligere faktorer, som kunne Side 17 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn være kritiske for nogle områder. Disse tæller (d) Project management process, (e) Team enviroment og (f) Customer involvement. I denne opgave går de sidstnævnte tre også under begrebet KSF. Under disse seks nævner Chow & Cao sammenlagt 25 ”attributter”/faktorer, som danner grundlag for de overordnede kategorier. Det er på baggrund af de 50 underordnede faktorer fra Nah & Delgado og de 25 underordnede faktorer fra Chow & Cao, at der udredes kritiske succes faktorer til brug i analysemodellen. Her tages der udgangspunkt i, at de underordnede faktorer skal være relevante at undersøge både for et stort og lille agilt IT-­‐projekt. Figur 2 -­‐ Egenudviklet analysemodel (Egen tilvirkning) Nedenfor gives argumentation for relevansen af hver af de anvendte KSF i den egenudviklede analysemodel, som ses ovenfor i figur 2. Slutteligt gives en overordnet begrundelse for de fravalg der er foretaget. Her gives yderligere nogle eksempler på disse fravalg. 5.2.2.1 Forretningsplan og Vision Denne KSF anses for at være væsentlig til analyse af IT-­‐projekter, da det er vigtigt at have en klar vision og mål for et IT-­‐projekt uanset størrelse. Dette medvirker at hele organisationen bag og i projektet følger den samme sti og sigter mod det samme mål. Samtidig skal forretningsplanen være en ”retfærdiggørelse” af den investering af ressourcer og kapital som topledelsen skal lave og yderligere danne grund for, ledelsens accept og støtte af projektet fremadrettet. Denne KSF strækker sig over de to faser Ide og beslutning og Planlægning grundet dens vigtighed i begge faser. 5.2.2.2 Kravspecifikation Arbejdet med at specificere krav er en af de store opgaver i ethvert IT-­‐projekt. Traditionelt set er der arbejdet med store teksttunge blueprints, som er en liste af alle de specifikke krav et system skal overholde. De agile tilgange har bevæget sig væk fra denne tunge og Side 18 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn langsommelige proces. Kravene til systemet er helt fundamentale at kigge på, da de i direkte sammenligning med resultatet, kan vise om et projekt har været en succes. Det er derfor relevant at se på, hvordan der arbejdes med krav i hhv. store og små projekter. 5.2.2.3 Definer milepæle Ethvert IT-­‐projekt skal have nogle støttepunkter i planlægningen i form af milepæle. Derfor findes denne KSF relevant at analysere da planlægning er essentielt i alle størrelser af IT-­‐
projekter. Under denne KSF kigges der således på, hvordan der i planlægningen af projektet arbejdes med milepæle og mål i forhold til de agile modeller. 5.2.2.4 Opfølgning af milepæle Opsætningen af milepæle i fasen planlægning laves for at styre projektet i den retning der ønskes, med den ønskede hastighed. Denne KSF omhandler at forfølge og monitorere om de opsatte milepæle bliver opnået som ønsket. Mange IT-­‐projekter går til grunde fordi milepælene ikke bliver nået som ønsket og typisk resulterer dette i tidsoverskridelser på flere fronter. Derfor skal denne KSF analyseres for at finde ud af, hvad de projektansvarlige aktivt gør for at nå og måle de opsatte milepæle i henholdsvis store og små projekter. Denne KSF har en tæt relation til projekt management, men holdes adskilt herfra, da det ønskes at give den sit eget fokus. Der vil også kigges på projektgruppens interne kommunikation. Er der tale om daglige, ugentlige eller månedlige gruppemøder, eller foregår kommunikationen primært gennem skrevne rapporter. Det kan også være noget helt tredje eller en blanding. 5.2.2.5 Omfattende test Hvis en bruger støder på for mange fejl ved et system, som er implementeret, kan det meget vel føre til modvilje mod at anvende systemet. Derfor er Test en vigtig KSF at medtage i forhold til om virksomheden aktivt forsøger at teste systemet så det fungere teknisk optimalt for slutbrugeren. Der er typisk mange funktioner, der skal testes for mange mulige fejl. Det er derfor en omfattende arbejdsopgave at teste. Grundet placeringen lige før projektfasen Implementering er det dog ofte en opgave, der ikke gennemføres til et tilfredsstillende niveau. Der er ofte tale om en afvejning af, om der skal leveres til tiden, eller om der skal leveres et gennemtestet system, altså kvalitet. 5.2.2.6 Udrulning Denne KSF dækker over hvordan udrulninger sker i forhold til implementeringen i virksomheden. Implementering er derfor fasen som denne KSF høre under. Der findes flere måder at udrulle et system i forhold til implementering. Ifølge bogen Power i projekter og portefølje (Attrup & Olsson, 2012) er der fire forskellige taktiske måder at gennemføre en implementering, hvortil udrulningen må tilpasses. De fire måde er; Domino implementering, Kaskade implementering, Små trin og Big bang implementering. Det ønskes at analysere Side 19 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn denne KSF, da der må antages at være forskelle i de muligheder og valg, der er i forhold til store og små agile projekter. 5.2.2.7 Uddannelse og træning I forhold til uddannelse og træning ligger der som regel et større arbejde heri, når der er tale om et stort projekt. Det er relevant at se på denne KSF, da det er essentielt at træne sine brugere af systemet for, at de kan tage det i brug og ikke afvise det. Derfor ønskes der at kigge på måden, hvorpå uddannelse og træning udføres i et stort og lille IT-­‐projekt. 5.2.2.8 Omstrukturering af forretningsprocesser ”Business process reengineering” er processen med at omstrukturere forretningsprocesser. Det kan med fordel gøres for at tilpasse en organisations forretningsprocesser til et system der har vist sig effektivt. Jf. Nah & Delgado (Nah & Delgado, 2006) kan det dog også øge kompleksiteten, risici og omkostninger ved projektet . I andre tilfælde kan det være nødvendigt at skulle lave en omstrukturering for at tilpasse sig et system, der ikke helt blev som forventet. Det er således interessant at se på, om der bliver arbejdet på samme niveau med denne KSF alt efter størrelsen af projektet. 5.2.2.9 Brugerinddragelse Det må være et faktum, at et IT-­‐system ikke er en succes, medmindre det bliver brugt, hvorved den værdi virksomheden vil have ud af systemet bliver realiseret. Derfor er denne KSF relevant at analysere. Dette fordi brugerinddragelse og -­‐feedback er et stærkt redskab til at sikre at brugerne får et system med de funktioner, de ønsker. Derudover har inddragelsen af brugerne vist sig at skabe ejerfornemmelser og dermed en større vilje til at acceptere det nye system (Bano & Zowghi, 2015). Det er relevant at kigge på, hvilke brugere der er interageret med og ligeledes i hvilket omfang brugerne anvendes i store og små IT-­‐projekter 5.2.2.10 Projekt management og organisering Denne KSF dækker overordnet over to områder. Nemlig projekt management og projektets organisering. Det er relevant at kigge på fordi det understøtter hele projektet. Dette ses også af modellen, hvor denne KSF dækker alle projektfaserne. En af de store opgaver indenfor projekt management er risikostyring. Her arbejdes der med forebyggende og afbødende handlinger for at øge sandsynligheden for projektets succes. Opfølgning af milepæle og mål er en proces, som naturligt hører under projekt management. Det er dog, som tidligere nævnt, taget ud for at give denne KSF sit eget fokus. Det andet overordnede emne, projektets organisering, omhandler organiseringen af projektgruppen. Organiseringen af gruppen skal ses i forhold til gruppemedlemmernes Side 20 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn kompetencer, ekspertise og motivation. Som en del af projektgruppens organisering vil projektgruppens fysiske placering også blive analyseret. 5.2.3 Fravalg af faktorer I forhold til den egenudviklede analysemodel, er der fravalgt en lang række faktorer fra den litteratur der er taget udgangspunkt i. De fravalgte faktorer ses ikke som værende generelle uanset størrelsen på projektet. Derfor findes de ikke relevante i vores generelle analysemodel. Desuden ønskes en model, der er let forståelig og simpel for læseren at overskue, dette ville ikke være tilfældet med inddragelse af alle fundne faktorer i litteraturen. Et eksempel på en faktor der ikke kan generaliseres er ”ERP package selection” (Nah & Delgado, 2006). Den indbefatter at der skal fokuseres på at vælge en ERP-­‐pakkeløsning, som passer til organisationen og virksomhedsstrategien på en måde, hvor et minimum af tilpasning af systemet er nødvendigt. Dette valg ville ikke blive nødvendigt i den form, for små projekter som Klean arbejder med. 6 Empiri Empirien vedrører de to cases om hhv. Kleans projekt hos Gloster og Dansk Supermarkeds Apollo projekt. For at indsamle relevant information er der foretaget et semistruktureret interview af en ledende medarbejder fra hver projektgruppe. Dette blev gennemført ud fra en interviewguide, som ses i Bilag 1. Hos Klean er der således foretaget et interview af Martin Frederiksen, Chief Technical Officer. Martin har indgående kendskab til Gloster casen og de projektudviklingsmodeller, de har anvendt. Af interviewet fremgår det, at projektgruppen primært har anvendt den agile projektudviklingsmodel Scrum. Fra projektgruppen i DS er Lars Mosbek interviewet. Lars har igennem Apollo projektets forløb på fire et halvt år været projektleder for området ”custom development” og senere overordnet projektleder for projektleder teamet. Fra disse stillinger har Lars også fået indgående kendskab til anvendte værktøjer og modeller. Af interviewet med Lars fremgår det, at den eksterne partner KPS i høj grad har bidraget med deres egne version af en agil projektudviklingsmodel kaldet Rapid Transformation. Det fremgår dog også at projektgruppen i høj grad har været nødsaget til at sammensætte deres egne modeller, for at få det store og komplekse projekt til at blive en succes. Begge interviews er af cirka halvanden times varighed og ligger i transskriberet format i bilagene til denne opgave (Bilag 2 og 3). Udover interviewet med Martin Frederiksen fra Klean er der fundet empiri til Gloster casen, fra Glosters nye hjemmeside (Gloster, 2015 A). Yderligere empiri til casen om Dansk Supermarked er fundet på Dansk Supermarkeds hjemmeside (Dansk Supermarked, 2015 A) og på den eksterne partner KPS Consultings hjemmeside (KPS Consulting, 2015 A). Der er også fundet empiri i tidsskriftet NEWS , som er et offentliggjort medarbejderblad udgivet af Dansk Side 21 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Supermarked og der kigget på ledelsesberetninger fra DS årsrapport for 2010. Derudover er der kigget på DS virksomhedsprofil på fra Aarhus Universitets karrierecenters portal og endelig på artikler fra Berlingske Business’ hjemmeside. 7 Analyse I dette afsnit vil de kritiske succes faktorer blive analyseret i samme rækkefølge, som deres argumenterede relevans i teoriafsnittet. For hver KSF vil der indledningsvist være en præsentation af den teori, der har fundet anvendelse i den efterfølgende analyse af faktoren i de to cases. Endeligt vil der være en delkonklusion der runder analysen af den individuelle KSF af. 7.1 Forretningsplan og vision Teori IT er rygraden i næsten enhver virksomhed i Danmark i dag, og derfor en vigtig faktor til at nå sine strategiske mål og visioner. Som udgangspunkt skal de forandringer der laves i en virksomhed passe til den strategi, som virksomheden fører. Uden en afstemning af interne projekter i en virksomhed og strategien vil der opstå modstridigheder i forhold til hvor organisationen arbejder hen imod og hvor ledelsen gerne vil hen. Det er essentielt, at ledelsen formår at danne bro til IT-­‐afdelingen således, at de er i tæt kontakt i forhold til at bevæge sig i samme retning. Analyse Dansk Supermarked har en målsætning om, at være landets mest konkurrencedygtige virksomhed i detailvarebranchen (Berlingske Business, 2015). Med den målsætning er det nødvendigt at kigge på, hvor fremtidens dagligvarehandel bevæger sig hen. Derudover er det nødvendigt at kigge på konkurrencen og hvilke egenskaber en virksomhed skal besidde, for at kunne være konkurrencedygtig på det gældende marked. Målsætningen er et skridt på vejen imod den overordnede vision: ”Dansk Supermarked Gruppens forretningsenheder/kæder skal være kendt for og bedømt som det bedste indkøbssted” (AU Career, 2014). En af strategierne til at nå denne vision er at DS skal være en ”omni-­‐channel retailer” (KPS
Consulting, 2015 B). Kort fortalt skal DS altså være tilstede alle steder. De skal nå ud til kunderne og kunderne skal kunne handle hos DS gennem alle tænkelige kanaler. Derfor har de brug for IT-­‐systemer, som kan håndterer og udnytte de nye kanaler. Det gamle system DSA online kunne ikke håndterer de nye kanaler/platforme som eksempelvis mobile platforme, e-­‐
handel, automatisk varebestilling og loyalitetsprogrammer. Derudover var mulighederne for forretningens udvikling begrænset af det gamle system (Jensen, 2014) . Side 22 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Apollo projektet var et skridt på vejen imod, at blive den mest konkurrencedygtige virksomhed nu, men også i fremtiden. Visionen for projektet var at standardisere og harmonisere forretningen (Bilag 2, linje 84). Denne transformering skete med henblik på at stå stærkere overfor fremtidens udfordringer og muligheder. Udfordringen lå i at 43.000 ansatte, fire forretningskæder i fire forskellige lande samt specialiserede komponenter fra den eksisterende IT-­‐løsning skulle integreres i en centraliseret løsning. Disse udfordringerne var dog ikke de eneste. Implementeringen skulle ske samtidigt med at forretningen var i drift. Derfor sammenligner programdirektør Alan Jensen også Apollo projektet med, at skulle udskifte en motor på en racerbil imens den kører (Jensen, 2014). Gloster fører en fokuseret differentieringsstrategi. De sælger håndlavede møbler af højeste kvalitet til et lille kundesegment, som er villige til at betale prisen for at få den højeste kvalitet og det bedste design. Deres kommunikerede mål er at skabe møbler, som bliver nydt i utallige øjeblikke. ”Our aim is your pleasure -­‐ to be enjoyed in countless special moments outdoors” (Gloster, 2015 B) Gloster kom til Klean med et projekt, der indebar en ny hjemmeside. Behovet for en ny hjemmeside udsprang af, at Glosters daværende hjemmeside ikke i tilstrækkelig grad kommunikerede deres historie, værdigrundlag og fokus på kvalitet og bæredygtighed. Derudover var Gloster flere år bagud i forhold til de digitale muligheder (Bilag 3, linje 139). Der var derfor mulighed for at opnå fordele ved at digitalisere flere processer, samt blive i stand til at udnytte de muligheder som IT og internettet har bragt med sig. Eksempelvis havde Gloster ingen social medie strategi. Det resulterede i at deres tilstedeværelse på de sociale medier foregik under forskellige alias, hvilket kun har den effekt, at det blive unødvendig besværligt for kunderne. Kleans rolle var at fungere som Glosters IT-­‐afdeling og være sparringspartner for ledelsen. Klean skulle være med til at forme visionen og Glosters nye cross-­‐channel strategi. Det gjorde de ved at udfordre Gloster på den retning de ønskede at gå. Derudover viste de Gloster hvilke teknologiske muligheder, der kunne være med til at bringe dem videre af den ønskede retning (Bilag 3, linje 97-­‐120). Gloster erkendte således, at de ikke havde de nødvendige kompetencer til selv, at navigere på den digitale/online bane og de åbnede op for et tæt samarbejde. Hos Gloster var det således ledelsen, der introducerede behovet for hjælp udefra og derefter kommunikerede det ned i deres organisation (Bilag 3, linje 73-­‐76). Klean påtog sig den rolle som Gloster efterspurgte og de gjorde meget for ikke blot at være en leverandør, men at skabe et fællesskab om opgaven (Bilag 3, linje 109). Et af de vigtige elementer for et IT-­‐projekt er opbakningen til projektet. I Apollo projektet hos Dansk Supermarked og i projektet for Gloster, har der været tale om at ledelsen har introduceret behovet og det er dem der har presset på for ændringerne. Ændrede processer Side 23 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn og nye systemer kan ofte blive mødt af modvilje mod forandring fra brugernes side. Det er således ikke hos brugerne, at projektgruppen skal finde sin primære opbakning. Opbakningen skal komme fra en såkaldt ”business sponsor” i ledelsen. Da det i begge tilfælde er ledelsen der har igangsat projekterne er det også naturligt at opbakningen er tilstede. Det er dog langt fra gældende, at alle ledere har samme holdning. Hos Dansk Supermarked oplevede projektgruppen, at de mistede denne opbakning fra deres ”business sponsor” i ledelsen for en begrænset periode. Det gjorde de fordi daværende CEO for Dansk Supermarked fratrådte. I perioden indtil der sad en ny CEO var der ingen ledere, der kunne give den nødvendige opbakning og tage strategiske beslutninger. Det resulterede i at projektgruppen gik ind i et sort hul, som Lars Mosbek kalder ”re-­‐planlægningshelvede”. Her mistede gruppen momentum og motivation, da der ikke kunne blive taget nogle ledelsesmæssige beslutninger. De enkelte forretningsområder begyndte at suboptimere, hvilket var stik imod projektets vision. Det var begyndelsen på en spiral, hvor der i høj grad manglede fællesskab og en synlig topledelse, der bakkede op om projektet og tog de nødvendige beslutninger (Bilag 2, linje 714-­‐724). Klean har oplevet at opbakningen fra ledelsen hos Gloster var til stede igennem hele projektet. Dog har der været et ønske om, fra Kleans side, at Gloster var mere modige. Gloster er vant til at udgive et produktkatalog om året og dette katalog skal være helt perfekt, for det kan ikke laves om, når det er sendt på gaden. Klean’s agile tilgang til projektet har dog betydet, at der kan blive rettet i ”udgivelsen”, da det ikke længere er et statisk katalog, men dynamisk i form af den nye hjemmeside. Gloster holdte dog igen med go-­‐live af den nye hjemmeside, da de ville være helt sikre på, at den var helt klar med de ønskede funktioner. Det er Klean’s opfattelse, at der hurtigt skal ske udrulning, så der fås glæde af ændringerne så tidligt som muligt. Således mener Klean, at Gloster muligvis mistede salg pga. senere go-­‐live end der var mulighed for (Bilag 3, linje 588-­‐597). Delkonklusion Både Dansk Supermarked og Gloster har lykkedes med at igangsætte projekter med en vision og strategi, som understøttede den ønskede retning for organisationen. Dansk Supermarked har selv skrevet visionen og strategien. Hos Gloster lykkedes det derimod at indgå i et tæt samarbejde med Klean, som hjalp med at udvikle visionen og strategien, så løsningen hjalp med at drive organisationen i den ønskede retning. 7.2 Kravspecifikation Teori Kravspecifikation er til for at afstemme kravene mellem dem, der skal bruge systemet, og dem der skal udvikle det. Dette bindeled, imellem de to sider af projektet, er kendt for at bære en af de store risici for at IT-­‐projekter fejler. Dette skyldes, at succesen af projektet afhænger af Side 24 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn hvor godt udviklerne forstår forretningens behov og krav. Selv små misforståelser mellem udviklerne og forretningen kan have en stor effekt i slutningen af projektet; den såkaldte ”bullwhip”-­‐effekt. Fordelene ved et klassisk kravdokument er at information er aktuel, til rådighed, den er godkendt af de rette og den kan ændres kontrolleret (Fine & Read, 2000). I forhold til den agile fremgangsmåde til at håndtere denne udredelse af krav, lægges der ikke så meget vægt på den tunge dokumentation af kravene. I stedet lægges stor vægt på interaktion med slutbrugeren for, at få deres direkte feedback og buy in rent visuelt og verbalt. Agil kravudredelse tager med andre ord udgangspunkt i det velkendte ordsprog ”et billede siger mere en tusinde ord”. Den agile fremgangsmåde foreskriver hovedsageligt, at systemet bygges i små inkrementelle dele i en iterativ proces. Derfor foregår udredelsen af krav kontinuerligt igennem udviklingsdelen af projektet. For at det kan lade sig gøre, er det nødvendigt at tage positivt imod nye eller ændrede krav til systemet. Dette kom ”The Agile Alliance” også frem til enighed om i ”Manifesto for Agile Software Development”, hvor det andet af tolv principper lyder: ”Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.” (The Agile Alliance, 2001 B) Analyse De to casestudier har begge arbejdet med udredelse af krav på en succesfuld agil måde. Dog med forskelle grundet projekternes forskellige kompleksitetsgrader. Dansk Supermarkeds meget komplekse system har ført til store udfordringer i forbindelse med kravudredelsen. Det store fokus lå her, på at skræddersy standardsystemet så lidt som muligt, med andre ord ”less is more” (bilag 2, linje 216-­‐217). Dette blev gjort med henblik på fremtidig vedligeholdelse af systemet. Jo færre krav til et standardsystem, udover dets standardfunktioner, jo nemmere er det at opgradere og vedligeholde i fremtiden (Nah & Delgado, 2006). Klean’s produkt var derimod et fuldt ud skræddersyet system, som var udviklet til præcis det miljø det skulle indsættes i. Udredelse af kravene til Glosters projekt foregik i starten af processen med at skrive et rammedokument, der beskrev hvad visionen med hele projektet var. Derefter fulgte et ni dages workshopforløb hos Klean i Aarhus. Her diskuteredes alle de nødvendige ting, som målgruppe til Glosters produkter, strategier osv. På baggrund af denne workshop udarbejdedes, hvad Klean kalder for et stil og tone dokument. Det havde til formål at beskrive farver og former mm. i forbindelse med det grafiske udtryk af Glosters hjemmeside. Ud fra Stil og tone dokumentet udarbejdedes der, sammen med Gloster, i en iterativ proces over præcis ni dage, en interaktiv frontend prototype. Efter de ni dage var der en fremvisning af, hvordan hele frontend delen kom til at fungere element for element. Hvordan de forskellige produkter skulle fremvises, hvordan navigationen af siden skulle foregå og hvordan eksempelvis udfyldelse af en formular skulle ske. Efter Glosters godkendelse blev frontend delen nedbrudt til mindre delopgaver, hvor hver delopgave var samlet i ”epics”, ”user stories” og ”tasks”. Her begyndte således arbejdet med at udforme den første version af en ”product backlog”. De tre nævnte begreber stammer fra Side 25 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn projektudviklingsmodellen Scrum, som Klean hovedsageligt har anvendt. Et ”epic” er en historie eller et krav på et niveau, som ikke er detaljeret nok til, at det fremgår hvad de egentlige opgaver systemets funktioner skal understøtte er. Denne detaljegrad kommer til dels ved introduktionen af ”user stories” og i høj grad ved nedbrydningen til ”tasks”. Under hvert ”epic” laves typisk en række ”user stories”. En ”user storie” er ligesom epics en historie eller et krav. Det er dog mere detaljeret end et ”epic” og det fremgår derfor mere tydeligt, hvilke opgaver systemet skal understøtte. Slutteligt kommer ”tasks”, som igen udledes fra hver ”user story”. Det er de præcise opgaver, der skal udføres for at en ”user story” kan gennemføres. For at have mulighed for at bekræfte systemets understøttelse af en ”user story” tilføjes en række acceptkriterier hertil. Kort fortalt er acceptkriterier en række præcise beskrivelser af, hvordan systemet skal understøtte brugerens interaktion hermed. Det var i realiteten disse ”user stories” med tilhørende acceptkriterier, der fungerede som Glosters kravspecifikation til Klean. Det er en meget kortfattet og funktionel måde at lave en kravspecifikation på. Det Klean her foretog sig, var at gøre kravspecifikationen til en række opgaver som en forbruger af Glosters hjemmeside ville udføre. Det kombineres yderligere med en funktionel beskrivelse af hvordan det gøres (Bilag 3, 158-­‐213). Klean bruger yderligere en del af deres ressourcer på at udfordre Gloster i deres tankemåde omkring, hvilke krav de sætter til systemet. Dette gør de ved at udfordre Gloster på, om de retninger de vil med systemet også er det rigtige i forhold til deres strategi (bilag 3, linje 118-­‐119). Dansk Supermarked har på samme måde udredt deres krav med en høj grad af brugerinddragelse, ved at inkorporere forretningsfolk med proceskendskab i selve projektgruppen. Selve udredelsen af kravene byggede på et konceptgrundlag som samarbejdspartneren KPS kom med. Denne kom i form af modellen som KPS kalder Rapid Transformation. RT har stor fokus på ”end-­‐to-­‐end” processer på tværs af organisationen. Udredelsen af kravene byggede på en sammenligningen af funktionerne i standardsystemet SAP med de end-­‐to-­‐end processer og behov der var. På baggrund af denne sammenligning kunne det ses, hvor standardsystemet ikke på tilstrækkeligvis kunne understøtte processerne. De steder hvor procesbehov og standardsystem ikke matchede begyndte projektgruppen at lave udvidelser for at løse problemet. Da det var den generelle holdning at SAP systemet var ”best practice”, forsøgtes det så vidt muligt at holde sig hertil. Derfor blev der ikke skræddersyet nogle løsninger, medmindre det var absolut nødvendigt. Efter seks uger var de første prototyper klar. De blev vist til DS koncernens ledelse igennem ”structured walkthroughs”. Under et ”structured walkthrough” var der en skærm, der viste systemet og en anden skærm der viste en procesguide. Her var der fra ledelsens side, mulighed for at komme med input til prototypen. Prototyperne var ikke fuldendte prototyper, men gav tilstrækkelig med input til ledelsen, til at de kunne give noget feedback tilbage. Derefter blev der gået mere i detaljer med prototypen og lavet et ”showly view” for at få endnu mere feedback og buy in til den endelige løsning. ”Structured walkthroughs” blev gennemført tre gange med halvanden måneds mellemrum under udviklingen af projektet. Selve kravene var derfor ikke dokumenteret, men blev udredt gennem kontinuerlig kommunikation mellem forretningen og Side 26 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn projektgruppen. (bilag 2, linje 176-­‐222). Projektgruppen erkendte fra starten af projektet, at de ikke kunne udrede alle krav til løsningen og afstemte derfor med forventningerne med forretningen. Prioritering lå i stedet på at levere løsningen til tiden. Økonomien var den næst vigtigste prioritet, men budgettet måtte gerne overskrides til en vis grad hvis det gjorde at de overholdte tiden. Kravene til systemet var derfor det eneste projektgruppen kunne regulere på. Målet var i bedste fald en 80% løsning til forretningen. Denne prioritering er illustreret af den såkaldte projekttrekant i figur 3, udredt af interviewet med Lars Mosbek (Bilag 2, linje 283-­‐ 295). Den mørkeblå trekant er DS prioritering. Den 100% prioritering af tiden i projektet, er illustreret ved at den mørkeblå trekant når helt ud i hjørnet af den retvinklede lyseblå trekant. Ligeledes er de to andre ikke 100% prioriteringer illustreret ved, ikke at nå helt ud i hjørnerne af den retvinklede trekant. Ifølge Lars Mosbek er det ikke muligt at opnå opfyldelse alle tre ting (bilag 2, linje 283-­‐284). Figur 3 -­‐ Projekttrekant (Egen tilvirkning) Delkonklusion Klean fulgte i høj grad hvad Scrum-­‐modellen foreskriver, når de udredte krav til løsningen for Gloster. Det resulterede i at deres udredelse af krav blev meget kortfattet og funktionel. Ved at inddrage brugerne i processen med udredelse af krav, sikrede Klean sig at kravene afspejlede brugernes ønsker og behov. Dette har været med til at sikre, at det forholdsvis lille projekt har haft den ønskede succes i forhold til udredelsen af krav. Dansk Supermarked opnåede succes med deres store projekt, da de valgte at være realistiske og sigtede efter at levere en 80% løsning i stedet for en 100% komplet løsning. Ved at DS sænkede overlæggeren for hvornår projektet var en succes i forhold til opfyldelse af krav, Side 27 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn formindskede de den kompleksitet de stod overfor betragteligt. Dette har været et væsentlig indgreb for at det store projekt lykkedes med at opfylde kravene. En anden vigtig del af DS’s succes med udredelse af krav, var at de havde inddraget medarbejdere fra forskellige steder i organisationen i projektgruppen. Det har haft den konsekvens at DS hele tiden har haft information og viden tilgængeligt i og tæt på projektgruppen. Med den traditionelle model for øje, kan der argumenteres for at disse personer i projektgruppen har gjort det ud for den traditionelle kravspecifikation. Samtidig har de så givet DS de fordele, som et kravdokument også giver, aktuel information, information til rådighed, og godkendt information af de rette. En ulempe, som DS har påført sig via denne fremgangsmåde, er at detaljegraden af kravene til systemet har manglet og dermed også krav til detaljerede funktioner i systemet (bilag 2, linje 224). Denne detaljegrad består af de sidste 20% op til 100% løsningen, hvilket DS arbejder på at lave, efter den officielle afslutning af Apollo projektet. Den økonomiske risiko DS har påtaget sig ved at arbejde agilt og ikke lavet en fastprisaftale på baggrund af en traditionel dokumenteret kravspecifikation, har de kompenseret for ved ikke at prioritere økonomien i projektet 100%. Med denne risiko kommer dog også muligheden for, at den endelige løsning faktisk bliver bedre, end hvad der kunne beskrives i en traditionel kravspecifikation. Dette fordi der ved den agile tilgang er mulighed for, at agere overfor nye krav, der udspringer af dybere indsigt i behov. 7.3 Definer milepæle Teori De agile projektudviklingsmodeller foreskriver, at leverancer skal ske med korte intervaller af to til otte ugers varighed. Det blev der i ”The Agile Alliance” opnået enighed om i 2001 og det kommer til udtryk ved det tredje af tolv principper bag ”Manifesto for Agile Software Development” som lyder: ”Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” (The Agile Alliance, 2001 B) Når leverancerne skal falde i korte intervaller, er det naturligt at milepæle også falder i disse korte intervaller. Således vil hver leverance ofte have en milepæl, som markerer dennes opfyldelse. Da der ikke foreligger en dokumenteret kravspecifikation og der undervejs i projektet tages positivt imod nye og ændrede krav, kan planlægningen og fastsættelse af milepæle være besværlig. Når milepælene skal fastlægges i de agile projektudviklingsmodeller gøres det i intervaller ud fra et tidsperspektiv. Afhængigt af projektets størrelse og kompleksitet, samt projektgruppens præferencer kan intervallets længde varierer. De agile Side 28 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn projektudviklingsmodeller arbejder dog, jf. det tredje princip ovenfor, med intervaller af to til otte ugers varighed. Hvis det besluttes, at der arbejdes med fire ugers intervaller og det er et team på otte fuldtidsansatte, så er der omtrent 1200 (=37,5*8*4) mandetimer pr. Interval. Herefter kan der så, ud fra arbejdsopgavers tidsestimat, fyldes op indtil intervallet er fyldt ud med opgaver. Jf. det første princip fra ”The Agile Alliance”, er ”det af højeste prioritet at tilfredsstille kunden gennem tidlig og kontinuerlig levering af værdifuld software” (Egen oversættelse) (The Agile
Alliance, 2001 B). Her lægges der især vægt på, at det har høj prioritet at levere værdifuld software til kunden. Således ligger der en opgave i at vurdere, hvorvidt en aktivitet skaber værdi i sig selv, er med til at skabe værdi eller egentligt ikke skaber værdi og derfor bør udelades. Dette har relevans ift. valget af aktiviteter, der skal være indeholdt i et interval. Analyse Når Klean fastsatte milepæle, gjorde de det ud fra nogle overordnede budgetter. De delte projektet op i en række budgetrammer. Med en inddeling i budgetrammer forstås en inddeling af projektet i en række mindre og mere specificerede dele med tilhørende tidsestimater. Dette gøres for nemmere at kunne overskue arbejdsopgaverne og derved være bedre i stand til at give mere nøjagtige tidsestimater. Klean er eksperter indenfor deres felt, og når de estimerer trækker de på denne ekspertise og deres store erfaring. Derudover anvender Klean nøgletal fra ”past performance”, til at udregne en estimeringsfaktor, der kan gøre et estimat endnu mere præcist. Estimeringsfaktoren uddybes yderligere under analyse af Projekt Management og Organisering. I korte træk udregnes den dog ved at kigge på den enkelte medarbejders historiske evner til at estimere og bruges således til at korrigere for eventuelle tendenser til over-­‐ eller underestimering. Det gør samlet set Klean i stand til indledende, at kunne overskue projekterne på et overordnet plan og tildele holdbare tidsestimater til de indeholdte budgetrammer. Efter inddelingen i budgetrammer og tildeling af tidsestimater hertil var opgaven at kigge på, hvilke aktiviteter der kunne gennemføres indenfor budgetområdet, som overholdte det budget der var sat af dertil (Bilag 3, linje 248). I forhold til overholdelse af budgettet skal det nævnes, at Klean var af den holdning, at deres opgave lå i at skabe mest mulig værdi for Gloster, ud fra de rammer de fik tildelt. ”Vores opgaver er at forvalte de her penge, så de (læs Gloster, red.) får mest mulig værdi for de udviklingsomkostninger som de påtager sig.” (Bilag 3, linje 252) Derfor er det naturligt at valget af aktiviteter, der blev udført indenfor hvert område, skete på baggrund af den værdi den aktuelle aktivitet skabte for Gloster. Der er naturligvis aktiviteter, som ikke skaber værdi i sig selv, men som er nødvendige for at andre vigtige aktiviteter kan skabe værdi. Side 29 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn I forhold til at tildele aktiviteter til de enkelte intervaller, anvendtes de såkaldte ”user stories”. Disse ”user stories” var udledt af ”epics”, som beskrevet under analysen af kravspecifikationen, og udviklet i samarbejde med Gloster. Ved brug af disse ”historier” blev der ramt et niveau, der var forholdsvis præcist. Derfor var Klean i stand til med stor nøjagtighed at estimere tidsforbruget for hver ”user story”. Klean tog en beslutning om, at de ville arbejde med intervaller af to ugers varighed. Da Klean som udgangspunkt bruger den agile projektudviklingsmodel kaldet Scrum, er dette to ugers interval det såkaldte sprint. Hver sprint blev nu tildelt en række ”user stories” indtil kapaciteten for de to uger var udnyttet. Således havde de nu udarbejdet den såkaldte ”sprint backlog”. Tildelingen hertil skete ud fra en vurdering af, hvad der gav mest værdi for Gloster. Derudover skete tildelingen ud fra, hvilke ”user stories” der havde relation til hinanden. Således arbejdedes der i et sprint med at kode funktioner, der understøttede ”user stories”, som relaterede sig til et fælles emne eller en fælles del af systemet. På den måde arbejdedes der i en isoleret del af koden, som udvikles, forbedres, testes og ”deployes” (Bilag 3, linje 323-­‐328). Her skal det nævnes at Klean, for altid at have en buffer, kun allokerer ”user stories” til omtrent 80% af kapaciteten. Dette er af hensyn til diverse risici, som der vil kommes ind på senere under analyse af den KSF Projekt Management og Organisering. Dansk Supermarked har i høj grad forsøgt at koordinere deres implementeringer, som også markerede deres milepæle med forretningen. Det har de været nødsaget til fordi hele projektet skulle køre sideløbende med, at alle butikker var i drift og kunderne blev betjent og serviceret. Derfor forsøgtes der at fastsætte implementeringerne efter, hvor butikkerne ikke har travlt. Det var en svær opgave, fordi butikkerne ofte kørte diverse kampagner og derfor ofte har travlt. Derudover har forretningsenhederne bagved butikkerne i perioder travlt med eksempelvis udarbejdelse af budgetter og årsrapporter. Reelt set har DS kun set én mulighed for succesfuld implementering af systemet. Den mulighed var at implementere systemerne, så de kunne håndterer en eller få varekategorier ad gangen. Derudover har implementeringerne været fordelt så de fire lande blev holdt adskilt. I Danmark blev der fastsat seks implementeringer fordelt på 13 mdr. Udover de overordnede milepæle, som består af implementeringer, har der været milepæle af mere teknisk karakter. Herunder hører eksempelvis udvikling og test af de enkelte leverancer, samt udarbejdelse af diverse prototyper til fremvisning. Disse milepæle har projektgruppen været alene om at fastsætte og forretningen har derfor stolet på projektgruppen. Med hjælp fra partneren KPS var projektgruppen i stand til at sætte og overholde de forskellige milepæle, så leveringerne skete som planlagt. Da aftalen med KPS som samarbejdspartner i projektet var fastlagt skete der en drastisk ændring i fastlægningen af milepæle. Selvom KPS ved deres indtræden i projektet ikke kendte til Dansk Supermarkeds forretning, blev der sat et ambitiøst mål sammen. Således skulle der seks uger efter KPS var hyret ind være et såkaldt ”Structured Walkthrough”, hvor den første prototype af systemet blev gennemgået for ledelsen. Senere blev der afholdt et ”Showly view”, som også er en fremvisning af systemet, blot på et mere detaljeret niveau. Side 30 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Disse to er eksempler på de større tekniske milepæle. Det har været de enkelte teams opgave at være klar til disse datoer. Med hensyn til milepæle for implementeringerne, har der været den overordnede holdning, at tiden skal overholdes. Derfor har det været nødvendigt at slække på nogle andre faktorer for, at blive klar inden deadline. Derfor er det naturligt at Dansk Supermarked slækkede på scopet, som var det mindst vigtige for dem jf. prioriteringen i projekttrekanten figur 3. Delkonklusion Gloster har haft et begrænset budget og der har derfor været et fokus på, at Klean skulle overholde de fastsatte budgetter, men stadig levere mest mulig værdi for pengene. Således har Klean fastsat deres milepæle ud fra, at de skulle overholde de budgetrammer som de fik godkendt af Gloster. Klean har et princip om, at de skal levere så meget mulig værdi for deres kunder. Derfor har de også fastsat deres milepæle ud fra hvilke aktiviteter, der gav Gloster mest mulig værdi for de omkostninger de påtog sig. Dansk Supermarked måtte skrue lidt ned for det agile, ved fastsættelsen af milepæle. Apollo projektet var så stort og kompliceret, at der ikke kunne leveres hele tiden. Det var en direkte konsekvens af deres princip om at arbejde med hele end-­‐to-­‐end processer. De måtte fastsætte mere komplekse milepæle i forhold til hvad der var ønsket, fordi der skulle implementeres hele varekategorier i hele lande ad gangen. Det at projektgruppen selv stod for at definere deres milepæle, i forhold til at kunne udrulle en del af systemet, betød at projektgruppen definerede deres milepæle i forhold til den udrulningsdato de havde koordineret med forretningen. Derfor har det været essentielt for dette store projekt at forretningen stolede på projektgruppens opfyldelse af udrulningsmilepælen. Det må konkluderes at have været nødvendigt for projektets succes, at DS har fraveget fra hvad de agile projektudviklingsmodeller foreskriver, for at de kunne overholde deres princip. 7.4 Opfølgning af milepæle Teori For at monitorere om et projekt er på vej i den ønskede retning, er det essentielt, at der følges op på om milepælene bliver nået, som ønsket. På den måde har projektlederne mulighed for at foretage korrigerende handlinger, hvis en milepæl ikke ser ud til at blive opfyldt. I den agile udviklingsmodel SCRUM, bruges blandt andet de såkaldte sprintmøder som en opfølgning på hvor langt projektet er nået. Her kigges bagud og diskuteres, hvordan processerne kører og hvordan planlægningen frem til det næste sprintmøde skal være. Yderligere bliver der anvendt ”burndown charts”, som er en grafisk præsentation af et sprints fremgang. Denne bliver lavet ud fra estimater på hvor lang tid de enkelte opgaver i et projekt tager. Hvert sprint i SCRUM bør ses som en milepæl for projektgruppen. Side 31 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Analyse Klean har i forbindelse med deres projekt lavet opfølgning af milepæle med udgangspunkt i Scrum. Her har de tildelt hver ”user story” nogle point, som udtrykker de timer, de tror, det vil tage at færdiggøre denne ”user story”. Hvis projektgruppen eksempelvis estimerer, at de skal bruge 100 timer til en given ”user story”, så får den 100 point. Bruger teamet så 80 timer på at færdiggøre den ”user story”, medfører det en ”velocity” på 120%. Derved er denne ”velocity” et udtryk for, at teamet har været 20% mere effektive, end de selv troede. Ved at følge denne ”velocity” over tid gør det, at Klean kan blive mere og mere præcise i deres estimering af hvor lang tid en ”user story” tager at færdiggøre. Denne estimeringserfaring stammer ikke kun fra dette projekt, men fra flere projekter som Klean har lavet (Bilag 3, linje 207-­‐217). Når de forskellige ”user stories” var estimeret kunne der nu opstilles et ”burndown chart”, der viste hvor meget forventet arbejde, der var tilbage vs. tiden til sprintets afslutning og næste møde med Gloster. På den måde kunne Klean og Gloster få et kvalificeret bud på, hvornår det enkelte sprint var færdigt og milepælen dermed opnået. Desuden blev der holdt opfølgningsmøder hver tirsdag og fredag mellem Klean og Gloster, for at sikre, at der var enighed omkring de fremskridt der blev gjort. Dette blev gjort via telefon eller en videosamtale ved hjælp af Skype. Yderligere blev opfølgningsmøderne brugt til, at planlægge det næste sprint i projektet, hvis det foregående var færdigt og godkendt af Gloster. En metode som Klean bruger for at styre projekter op imod færdiggørelse af en milepæl og højne sandsynligheden for succes, er den såkaldte ”feature freeze” og ”code freeze” metode (bilag 3, linje 295-­‐300). Dette omhandler at der med et vidst tidsrum til færdiggørelse erklæres ”feature freeze”, hvor der ikke måtte tilføjes flere funktioner til løsningen. Med et mindre tidsrum til færdiggørelsen erklæredes ”code freeze”, hvilket bevirkede at der ikke måtte startes på nye koder, men kun færdiggøres de igangværende. På den måde sikrede Klean at de fik lukket ned for nye arbejdsopgaver og på den måde fik afsluttet de igangværende. Når et sprint var færdigt og en levering var klar, kunne Klean og Gloster sammen se på løsningen og vurderer, om de var på rette vej eller ej. Dette er illustreret i figur 4, som grafisk viser et eksempel på, hvordan der ved de forskellige leveringer forsøgtes at finde vejen mod målet. Projektets start er markeret i venstre side og den direkte og mest effektive vej til målet er repræsenteret af den rette linje, som ender ud i målet. Det præcise mål var ukendt for både Klean og Gloster, indtil de nåede dertil. Stien fra start punktet og mod målet er fyldt med en række leveringer, som også ses som milepæle, repræsenteret ved de sorte punkter. Efter første levering, første punkt, afholdtes er møde mellem projektgruppen og kunden, hvor det diskuteres, hvordan de troede løsningen lå i forhold til den mest effektive og direkte vej mod målet. Hvis de var på afveje og ved mødet ikke var i stand til at se dette og korrigerer herefter, kunne næste levering meget vel blive endnu mere afsporet, som vist ved det andet punkt. Situationen vist ved det røde punkt og stien med nr. 1, er hvor der efter afslutning af et sprint med levering, vurderedes at projektet var på afveje. Derefter kunne der trædes et skridt tilbage og tages udgangspunkt i løsningen, som den var efter den forrige levering. Herfra kunne der igen forsøges at spore sig ind på målet, som vist ved sti nr. 2 og leveringen den Side 32 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn førte til. Ved at korrigere efter hver levering skulle projektet og løsningen helst spore sig mere og mere ind på den direkte vej mod målet. På et tidspunkt skulle der gerne kunne nås til enighed om, at målet var nået. Figur 4 -­‐ Tragt model (Frederiksen, 2015) (Egen tilvirkning) Dansk Supermarked traf et realistisk valg om, at den løsning de ville levere, kun blev en 80% løsning. De erkendte yderligere, at de ikke på forhånd kendte hverken 100% eller 80% løsningen. Med Rapid Transformation ligges der som tidligere beskrevet, stor vægt på at bruge prototyper. Det har haft den konsekvens, at der på forhånd ikke var en klar beskrivelse af, hvad der skulle endes ud med, når projektgruppen forsøgte at skræddersy en løsning til standardsystemet, for at det kunne understøtte en proces korrekt. Derfor var det også svært at sætte en klart defineret milepæl for den næste levering. Når en fastsat milepæl ikke var klart defineret, var det ligeledes besværligt at lave opfølgning herpå. Således stod projektgruppen overfor ukendte mål og en fremgangsmåde med at bruge prototyper ved udvikling af skræddersyede løsninger. Det havde den betydning at de ligesom Klean måtte forsøge, ved hver opfølgning af leveringer, at fastsætte deres placering i forhold til den direkte vej mod målet, som illustreret ved figur 4. Den opfølgning der fandt sted under projektet har været i forhold til at nå så meget som muligt, inden go-­‐live stadiet som var den overordnede milepæl, hvor de gik i luftet med hvad de havde. Derfor kan det siges, at der ikke har været et fokus på at blive færdig, men fokus på at blive så klar som mulig til den fastsatte go-­‐live dato. Der er holdt daglige ledermøder i projektgruppen for at følge op på milepæle, som de agile udviklingsmodeller foreskriver (Bilag 2, linje 349). Grundet en god åbenhed i projektgruppen, blev der åbent talt om de problemer, der var, som f.eks. delprojekter, som var ved glide ud af den ønskede bane i forhold til den opsatte milepæl. Ledergruppen diskuterede derefter, hvad der skulle til af Side 33 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn løsninger og ressourcer for at få projektet tilbage på sporet og langsomt arbejde sig hen mod målet. Delkonklusion Endnu en gang har DS’s beslutning om at reducere deres scope, til at være en 80% løsning ved levering, givet dem en fordel. Det har givet dem den fordel i opfølgningen af milepæle, at de ikke har skulle opstille milepæle efter at levere et 100% komplet system og dermed heller ikke skulle opfølge de dertilhørende flere milepæle. Derimod har de kun skulle opfølge milepæle for et 80% system, og dermed har de kun skulle koncentrere sig om de vigtigste dele af systemet. Den egentlige opfølgning blev gjort i forbindelse med deres ”structured walkthrough”, hvor de inputs de fik fra ledelsen fortalte dem om de var på rette vej i forhold til deres mål med de givne end-­‐to-­‐end processer. Yderligere har opbygningen af projektgruppen med flere projektledere, gjort projektet mere overskueligt at følge op på. Hver projektleder har på den måde kun skulle fokusere på sine egne milepæle, og yderligere derefter referere situationen til Lars Mosbek, vores informant, som på den måde har styret hele projektet hen imod go-­‐live. I modsætning til DS har Klean kunne holde sig til en decideret metodik i forhold til deres opfølgning af milepæle. Dette har medvirket til en mere simpel tilgang til opfølgning af milepæle. En konsekvens af at Klean valgte at arbejde sammen med en kunde så langt væk rent geografisk, var at de ikke konsekvent har kunnet afholde fælles sprintmøder. Dette har ikke været muligt hver anden uge, som ellers normalt er en del af Kleans metodik. Via de ugentlige samtaler ved hjælp af telefon eller Skype, har Klean alligevel formået at styre hvert sprint succesfuldt. Dette ville formentlig ikke have været muligt i et stort projekt. Her ville der være mange flere deltagere, og derfor ville et ”normalt” sprintmøde, derfor være essentielt for opfølgningen af projektets milepæle. 7.5 Omfattende test Teori Indenfor de agile projektudviklingsmodeller er det et princip, at der skal leveres fungerende software løbende, og det er udgangspunktet, at der arbejdes i korte intervaller. Det betyder, at alle arbejdsopgaver, fra udredelse af krav til test, vedrørende et stykke software, skal gennemføres indenfor intervallet. Teamet skal fungere effektivt for at nå at gennemføre leveringen til tiden. Ligesom udredelse af krav og selve udviklingen er sammensmeltet, da brugerne sidder sammen med udviklerne og udreder kravene undervejs, er test også blevet integreret med andre arbejdsopgaver. Således er arbejdet med at teste i mindre grad en selvstændig opgave, som det er en del af alle opgaver i intervallet. Test er stadig en meget vigtig opgave, og derfor er testeren ligeledes en vigtig rolle i teamet. En tester har traditionelt set haft fokus på, at software skal levere i forhold til en lang række Side 34 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn dokumenterede krav. En agil tester skal ændre dette fokus, så der i stedet fokuseres på at software skal levere i forhold til det, brugerne verbalt og visuelt har udtrykt af ønsker og behov, når de har siddet sammen med udviklere og udredt krav. Der er således et behov for, at testerne bringes tættere på brugerne og udviklerne for at blive familiære med brugernes ønsker og behov. Brugernes ønsker og behov udtrykkes ofte ved såkaldte ”User stories”. Opgaven med at teste bliver i høj grad at sikre, at den udviklede kode gør brugerne i stand til at gennemføre disse ”User stories”. Et andet argument for at testerne skal bringes tæt på udviklerne er, at de derved får mulighed for at stille de rette spørgsmål på det rette tidspunkt. På den måde kan en fejl blive fanget så tidligt i processen som muligt og derved minimeres de omkostninger, der er for at rette op på fejlen. Dette er yderligere med til drastisk at mindske den tid, udviklerne skal bruge på at rette fejlen. Hvis koden, hvori fejlen ligger, er grundlæggende vil en sen opdagelse heraf ofte betyde at kode til andre funktioner, som relaterer til den grundlæggende kode, også skal skrives om. Jo senere i processen fejlen bliver opdaget, jo mere kode risikerer man, at der skal skrives om. Derfor er det essentielt at fejlene opdages så tidligt som muligt. Et relevant emne i forhold til agile tests er nødvendigheden af at teste effektivt. Som et led hertil gælder det generelt, at alle medlemmer i et team er med til at udføre tests. Eksempelvis skal udviklerne sørge for løbende at teste den kode, de arbejder på, og således bærer de opgaven med at teste kode. Ved at hele teamet er med til at udføre testarbejdet, bliver teamet mere effektivt, blandt andet fordi fejl opdages hurtigt og testarbejdet fordeles på flere teammedlemmer. Derudover bør teamet anvende automatiserede tests, som en del af arbejdet med at teste. På den måde kan de blive endnu mere effektive. Der findes flere typer af tests, som alle har relevans. Test af kode er den type test, der foregår på det dybeste og mest detaljerede niveau. Herefter kommer forskellige testtyper, som går fra at teste helt specifikke dele af systemet til at teste hele systemet og slutteligt en test, der foretages af brugerne selv for at verificere at systemet opfylder kravene. Helt generelt gælder det, at den agile tester ikke skal ses som ”kvalitetskontrollant”, men i stedet som en holdspiller, der hjælper med at nå til målet (Carter, 2015). Analyse Hos Klean har de erfaring i at arbejde agilt, og de har med denne erfaring forbedret deres håndtering af tests. De har eksempelvis tilpasset deres sammensætning af teams, således at antallet af testere passer til antallet af udviklere. Således er der hos Klean en tester for hver tre til fire udviklere. Dette er ifølge Klean selv radikalt anderledes end den generelle praksis i branchen, hvor det ofte ses at en tester skal teste for langt flere udviklere. Begrundelsen for, at de arbejder med så få udviklere per tester, er at det er med til at øge produktiviteten af teamet. Generelt er der en tendens til at ansætte flere udviklere, hvis produktiviteten er lav. Ifølge Klean er der dog i gennemsnit 11 fejl pr. 1000 linjer kode. Så hvis der sammensættes teams ud fra, at der skrives fejlfri kode, vil der hurtigt opstå en flaskehals hos testeren. Løsningen til at skabe mere produktivitet, er således ikke udelukkende at ansætte flere udviklere, men i stedet flere testere (Bilag 3, linje 386-­‐392). Side 35 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Klean arbejder i intervaller/sprints af to ugers varighed, og de tester i hvert eneste sprint. De ser ligeledes en fordel i at kunne teste hele tiden. Derved vil omkostningerne til at rette eventuelle fejl kunne nedbringes. Jo tidligere en fejl bliver opdaget, jo nemmere har udvikleren ved at sætte sig ind i koden igen, samt finde og rette fejlen. Hvis der går for lang tid fra oprettelse af koden til meddelelsen om, at der er fejl, så vil udvikleren skulle bruge ekstra tid på at sætte sig ind i den ”gamle” kode. Klean anvender projektudviklingsmodellen SCRUM. Her er ”User stories” et centralt element. Dette er også gældende i forhold til tests. Medfølgende til en User story er et dokument med accept kriterier. Dette dokument danner rammen for arbejdet med test, fordi det her er beskrevet, hvordan systemet skal virke (Bilag 3, linje 185-­‐187). Udover test af hver enkelte ”User story”, laver Klean også tests på tværs af ”User stories”. Dette sker for at sikre, at der ikke er to enkeltstående løsninger, som ikke fungerer sammen. Ligeledes kan det være tilfælde, hvor der helt overses funktioner, som er nødvendige for, at en levering kan fungerer. Klean bruger en såkaldt ”issue tracker” til at følge de opdagede fejl og hvor langt de er i processen fra at blive løst. Som en del heraf arbejder de også med to begreber de kalder ”Parentbugs” og ”Sisterbugs”. En bug er en fejl. En ”Parentbug” er en fejl der gør at mange andre fejl også opstår og ligger altså på et højt niveau. En ”Sisterbug” er en fejl på det lavere niveau. Altså en fejl der udspringer af en ”Parentbug”. Disse to begreber bruges til at beskrive på hvilket niveau en fejl ligger og de kan bruges til at relaterer fejl til hinanden. Om der er tale om en ”Parent-­‐” eller en ”Sisterbug2 noteres ligeledes i den såkaldte ”issue tracker”, sammen med information om de forskellige relationer. På den måde er der styr på, hvilke fejl der er relaterede og hvilken ”Parentbug” der findes. Disse informationer bliver brugt når der bliver arbejdet med at løse fejl. Dette sker nemlig i ”klumper”, hvor det forsøges at løse fejl der relaterede sig til hinanden. På den måde arbejdes der i en isoleret del af koden og det er nemmere at overskue, hvordan de forskellige fejl påvirker hinanden. Den ovenstående fremgangsmåde i forhold til test, var den der blev anvendt i Gloster projektet. Dansk Supermarked har grebet test anderledes an, da størrelsen på deres projekt har betydet at de ikke nøjagtigt har kunnet følge, hvad de agile modeller foreskriver. DS har brugt fire forskellige typer af tests. Den første er en uformel og udokumenteret test, foretaget af udviklerne selv. Her testede de selv de løsninger, de var kommet frem til. Den anden type var en såkaldt Unit test, som var styret af testcases og efterfølgende opfølgning og prioritering af fejl. Det var en test af de enkeltstående funktioner, som gik i dybden og skulle sikre, at hver funktion fungerede for sig. En funktion kunne være udarbejdet af flere personer, og der var derfor behov for at teste, om funktionen virkede som forventet. Denne test blev foretaget så snart en funktion var klar til levering og har således fulgt den agile forskrift. Den tredje type var en scenarie test. Her testedes der hele end-­‐to-­‐end processer og således funktionernes integration med hinanden. DS tog et valg om at implementere hele varekategorier for et helt land ad gangen, og det havde en effekt på denne test type. Scenarie testen foregik på tværs af systemer og forretningsområder og var vigtig i forhold til at se, om Side 36 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn den samlede løsning var i stand til at understøtte en hel proces, for en hel varekategori og et helt land. Til at udføre denne test var der således en gruppe, der oprettede master data i form af fiktive ordrer, fakturaer og følgesedler. En anden gruppe, der styrede lagerløsningen og slutteligt en gruppe, der tjekkede at de finansielle poster bag de forskellige transaktioner blev oprettet korrekt og på det rigtige tidspunkt. Denne test var således ret omfattende og blev derfor ikke udført for hver levering, som de agile modeller foreskriver. Typisk havde projektgruppen afsat fire uger op mod udrulningen, hvor de blandt andet lavede disse scenarie tests. Altså er scenarietesten sket i en selvstændig fase og således efter den traditionelle model (Bilag 2, linje 426-­‐440). Den sidste og fjerde testtype var en regressionstest, som skulle teste at den nye levering ikke ødelagde noget i den eksisterende funktionalitet. Denne test var således meget vigtig, da den eksisterende funktionalitet allerede var taget i brug af organisationen, og fejl heri ville få store konsekvenser for driften (Bilag 2, linje 462-­‐465). Ligesom scenarietesten blev denne test også foretaget i en selvstændig fase. Til at udføre de forskellige tests har DS i høj grad brugt de medlemmer af projektgruppen, som var blevet trukket ud af organisationen. Derudover har resten af projektgruppen inklusiv de eksterne konsulenter også antaget rollen som testere, hvis de var specialister indenfor et område, der skulle testes (Bilag 2, linje 406-­‐409). Testerne har således været tæt på udviklerne og i flere sammenhænge har der været sammenfald af disse roller. Det var ofte de samme som stillede kravene, diskuterede forretningen og testede løsningen, hvilket DS antog for værende en fordel på grund af specialistkompetencerne (Bilag 2, linje 397). Men samtidig er det ikke uden risiko, at en eller flere personer påtager sig flere roller, da der er risiko for at løsningen således kun afspejler få betragtninger. Dansk Supermarked arbejdede uden en egentlig kravspecifikation, da de ville arbejde agilt, og med udvikling af en 80% løsning. Derfor var der ingen, der vidste hvad en 100% løsning var og dermed heller ingen der vidste, hvad en 100% test var. De lavede en såkaldt risikobaseret test, hvor de testede det de vurderede, var mest vigtigt. De har testet de mest vigtige processer igennem først og nået så langt de kunne. De så på hvilke processer der var mest kritiske for forretningen og ville skabe mest skade ved eventuelle fejl, og testede dem først. Ved de processer, som DS vurderede som mindre vigtige, og som de derfor ikke nåede at teste, var de således risikovillige overfor fejl og eventuelle afledte konsekvenser. Et eksempel på en afledt konsekvens var, da projektgruppen tilføjede et felt i en indkøbsformular. Denne tilføjelse resulterede i, at systemets funktioner til varemodtagelse ikke fungerede, og at lageret således ikke kunne varemodtage (Bilag 2, linje 483-­‐488). Delkonklusion Klean er eksperter i at arbejde agilt, og de har erfaret, at flere testere i et team, giver mere produktivitet. Derfor kører de med en tester for hver tre til fire udviklere. Det har betydet, at der altid var ressourcer til at gennemføre test, og der ikke opstod flaskehalsproblemer. De kørte alle deres test typer for hver enkelt leverance og sikrede dermed høj kvalitet og muligheden for, at kunne lave udrulning med kort varsel. Dette uden at skulle bekymre sig Side 37 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn om, hvorvidt de forskellige leverancer nu også fungerer, som de skal, også i integration med hinanden. Dansk Supermarked har testet markant anderledes end Klean. Udviklerne har adopteret et agilt princip og har løbende testet deres eget arbejde. Hver gang en funktion var lavet færdig, blev den ligeledes testet i en unit test, hvilket også følger den agile forskrift. DS fraveg herefter de agile forskrifter, til fordel for en mere traditionel tilgang. De havde succes med at køre en mere traditionel tilgang på deres omfattende tests af scenarier og regressionstest. Det har de gjort op mod hver udrulning i selvstændige faser. De har således ikke gennemført alle test typer indenfor hver leverance og bryder dermed med de agile principper. Det har dog været en nødvendighed for at opnå succes, grundet størrelsen på projektet, og det faktum at de ville implementere en hel varekategori i et helt land ad gangen. Ved at bryde med de agile principper påtog DS sig den risiko, der ligger i at fejlene blev opdaget sent i forløbet. Dermed kunne rettelse af disse fejl være betydeligt mere omfattende, end hvis de var opdaget tidligt i forløbet. Dansk Supermarked accepterede at nogle scenarier ikke ville blive testet. De tog en såkaldt risikobaseret tilgang til deres tests. Så projektgruppen testede de scenarier og processer, som var mest kritiske set fra forretningens synsvinkel. Dermed sikrede de sig at fundamentet, det grundlæggende system, i løsningen fungerede. Fundamentet vil altid være en vigtig faktor for, at løsningen bliver succesfuld. Hvis ikke der er styr på det grundlæggende system og dermed de primære funktioner, da vil implementering af sekundære funktioner med stor sandsynlighed fejle. Hvis de ikke havde lavet risikobaseret tests, og dermed havde gennemtestet hele løsningen, var hastigheden på implementeringen blevet drastisk nedsat. 7.6 Udrulning Teori De agile udviklingsmodeller foreskriver, at der leveres små dele af systemet hyppigt. Således sørges der hele tiden for, at en lille del af systemet er testet og godkendt af brugeren, før der igangsættes noget nyt. Ved udrulningen af et IT-­‐system er det vigtigt at tage stilling til flere forskellige ting. Bogen ”Power i projekter & portefølje” arbejder med fem implementeringsprincipper (Attrup & Olsson, 2012, pp.264-66). 1. De rigtige mennesker: Det er vigtigt at fokusere på de mennesker, der bliver berørt mest af den implementering, der finder sted. Det er afgørende, at de hjælpes og der er en god dialog mellem dem og projektledelsen på et tidligt stadie i implementeringen. 2. Vigtighed og handling: hvis mennesker skal ændre sig, er det altafgørende at de forstår hvorfor de skal ændre sig. 3. Stemning og timing: Det er essentielt, at stemningen omkring projektet er rigtig. Der kan være tider, hvor det er umuligt at implementere et system og andre gange, kan det Side 38 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn lade sig gøre. Det er derfor også vigtigt at planlægge implementeringen i forhold til stemningen. 4. Effekt: Et IT-­‐system implementeres for at forandre og forandringer handler om effekt. Uden en effekt er der ingen forandring. For at sikre en effekt, er det vigtigt at projektgruppen har god forretningsindsigt, så de ved hvad systemet påvirker og dermed har en effekt på. 5. Autenticitet: Projektledere og andre ledere i et IT-­‐projekt vil blive udfordret fra mange sider, fra forskellige interessenter der vil have sine behov dækket. Det er derfor vigtigt at ledere i projektet har en høj integritet, er nærværende og i øjenhøjde i hele organisationen. Foruden de fem implementeringsprincipper er der fire forskellige taktiske måder at levere systemet på: Domino implementering, Kaskade implementering, Små trin implementering og Big bang implementering (Attrup
&
Olsson,
2012,
pp.266-70). De fire implementeringsstrategier er vist i figur 5, hvor de er placeret i forhold til to akser, som repræsenterer henholdsvis Opdeling af organisationen og Opdeling af opgaven. Figur 5 -­‐ Taktisk gennemførelse af implementeringen (Attrup & Olsson, 2012, side 267, figur 8.4) Side 39 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Analyse DS har valgt at dele deres udrulninger op efter lande som hovedopdeling. Derefter var leveringerne delt ud på varekategorier. Blandt andet ved den danske udrulning, som var delt op efter følgende varekategorier (Dansk Supermarked, 2014 A): • frost • tobak, frugt og grønt, brød og kager • kolonial, øl/vand • Diverse, nearfood • Textil, slagter, bager og deli • Elektronik, møbler, hus og have Ved hvert land blev systemet sekventielt udrullet efter en opdeling i varekategorier. En udrulning af en varekategori skete på tværs af hele organisationen; Indkøb, Lager, Butik og Finance. I forhold til implementeringsstrategien hos DS, har der til dels været tale om små trin implementerings strategien. Der er tale om denne strategi grundet opdelingen af systemet efter varekategorier og opdeling af organisationen på landebasis. Dog kan det diskuteres, at der kun til dels var tale om denne strategi. Dette fordi DS’s opdeling af organisationen efter lande gav meget store organisatoriske dele, hvori systemet skulle udrulles. Således var der kun er en lille opdeling, men dog stadig en opdeling. Opdelingen af systemet efter varekategorier må også siges at være en lille opdeling. Denne opdeling betød at udrulningen skulle håndterer hele end-­‐to-­‐end processen. I interviewet med Lars fra DS nævnes det, at et område som Tekstil havde været formålstjenstligt at dele op, men dette ville stride imod deres regelsæt om at tage hele varekategorier ad gangen (Bilag 2, linje 320-­‐322). Derfor kan der være tale om, at deres strategi trækker lidt ned imod Big bang strategien. Dette begrundet med at de på trods af en opdeling af både organisationen og systemet, stadig arbejdede med forholdsvis store dele. I projektgruppen hos DS blev der indført 4 fokusområder, som bliver præsenteret under analysen af Projekt management og organisering. Et af områderne var ”Organizational change management (OCM) fokusområdet, som blandt andet stod for, at kontakte de rette mennesker forud for udrulningen. Ligeledes stod OCM for kontakten mellem projektgruppen og forretningen. Således var det også OCM området, der stod for den kommunikation, der indebar at forklare, hvorfor en proces var som den var, til de enkelte berørte personer. På den måde sikredes det, at de kunne bære den forandring, der ville finde sted. Yderligere har en nedsat gruppe af ledere fra hele organisationen, kalder ”Business Proces Ownergroup” (BPO) været med til at koordinere hele implementering på ledelsesniveau. Deres job har været at kigge på DS’s ”greater good”, når der eksempelvis opstod tvivlspørgsmål omkring implementeringen. Den direkte effekt af implementeringen af SAP er ikke udsprunget 100% endnu. Dette skyldes at der på nuværende tidspunkt arbejdes på at udvikle de sidste 20%, for at gøre systemet komplet. I sidste ende forventes resultatet at være, at organisationen bliver langt mere effektiv, da ledelsen kan løfte hele organisationen fra det samme udgangspunkt. Med implementeringen af SAP i hele organisationen har DS forsimplet og strømlinet sine processer Side 40 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn og på den måde bliver de mere konkurrencedygtige. I et så stort projekt, som det DS har udført, kan det være meget svært for de forskellige ledere, at have en høj integritet blandt den forskelligartede medarbejderskare i organisationen. DS har dog langt hen af vejen forsøgt at skabe en organisation i projektgruppen, der skulle møde brugerne i øjenhøjde, via OCM fokusområdet. Det har været dem, der tog imod brugernes problemer med forståelse og tog problemerne med videre til projektgruppen, som tog dem til efterretning. Klean har som udgangspunkt fungeret som Glosters IT-­‐afdeling. Derfor har der ikke været så stor fokus på at have kontakt med de ”rigtige” mennesker i Glosters organisation, da Klean egentlig fungerede som de ”rigtige” mennesker. Gloster har selv bestemt hvilke personer der har været involveret i projektet fra deres side (bilag 3, linje 477-­‐478). I forbindelse med udrulningen har der været et stort fokus på at ændre måden som Gloster tænker forretning på. Dette har været essentielt for, at Gloster var klar til at bære systemet, da det blev udrullet. Derfor har hele organisationen, støttet af ledelsen, haft fokus på at lære den nye forretningsstrategi. Dette fordi handel generelt er i et skifte over imod ”E-­‐commerce” frem for handel i butikker. Dermed var der også blevet skabt en naturlig forståelse for, hvorfor ændringen af forretningsprocesserne var nødvendig. Stemningen omkring udrulningen af systemet har været et større arbejde for Klean. Klean ønskede at udrulle systemet lang tid før Gloster turde (bilag 3, linje 588-­‐597). Gloster udsatte udrulningen flere gange, fordi de ville have et perfekt system inden det blev udrullet. Med andre ord var stemningen omkring udrulningen ikke afstemt mellem de to i lang periode. Gloster var vant til at lave trykte blade. Når de gjorde det, skulle det være 100% perfekt inden de trykte, da det efterfølgende ikke kunne laves om. Det var denne tankegang de havde omkring implementeringen af systemet, og derfor ikke ville udrulle uden, det var helt perfekt. Dette er i total modsætning til den agile fremgangsmetode Klean anvender. Her udrulles der, og i en iterativ proces tilrettes systemet til det er, som det skal være. For at skabe den rette effekt bag udrulningen af systemet, sørgede Klean for at skabe et tæt samarbejde med Gloster. På den måde fik de stor forretningsindsigt og kunne derved skabe et system, som ville have den effekt kunden ønskede. De specifikke effektmål for projektet kendes ikke. Men det vigtigste resultat var at gå fra trykt marketing til online marketing, og dette er lykkes med projektet. Klean har haft en høj integritet hos de personer, de har samarbejdet med hos Gloster. Dette var helt nødvendigt, da der naturligt var en undertone af kunde-­‐leverandør forhold i samarbejdet. Hvis Klean ikke kunne møde Gloster på deres niveau og forstå deres ideer, så ville samarbejdet hurtigt blive afbrudt. Derfor har det igennem projektet været helt essentielt, at der har været en god autenticitet mellem parterne. Leveringerne er sket over sprints på to uger. Ved hver levering blev en prototype på det næste sprint præsenteret, således havde Gloster indsigt i både, hvad der var lavet og skulle laves fremadrettet. Side 41 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Klean har implementeret systemet i flere dele, men den trinvise implementering er sket i hele organisationen. Dermed er implementerings strategien der er anvendt til dette projekt Kaskade strategien, som netop er kendetegnet af denne fremgangsmåde. Delkonklusion Det har været en stor ulempe for DS med deres implementeringsstrategi, fordi den skabte hvad de selv kalder for en ”co-­‐eksistens periode”. Det var en periode, hvor de kørte med to parallelle systemer. En vare kunne på intet tidspunkt figurere i begge systemer på en gang. Det havde den betydning at det var op til de ansatte i organisationen, at jonglere mellem to systemer alt efter, hvilken varekategori de arbejdede med. Dette konkluderes at have været en nødvendig, for at opnå succes, men samtidigt at have skabt mange frustrationer blandt de ansatte. Implementeringen lykkedes til dels, fordi det som udgangspunkt var den eneste måde implementeringen kunne gennemføres på (Bilag 2, linje 301). Dermed har der været en indgående forståelse i hele organisationen for, at denne måde var ”best practice”. Derudover fik DS stor gavn af at afprøve denne implementeringsform i lille skala i Sverige først. På den måde var de bedre rustet til at styre implementeringen, da de kom til den meget mere komplekse og større organisation i Danmark. Et vigtig bidrag til implementeringssuccessen var oprettelse af BPO. I dette forretningsforum kunne folk på ledelsesniveau blive enige om, hvordan systemet bedst understøttede organisationen på tværs. Endnu en gang var det med til at skabe en fælles forståelse på tværs af forretningsområderne omkring implementeringen. DS har forsøgt at kompensere for, at de ikke kunne levere så ofte, ved at forberede organisationen grundigt inden implementeringen. Denne opgave blev varetaget af OCM fokusområdet. Inden implementeringen sørgede projektgruppen yderligere for, at systemet var testet på alle måder, således at de var så sikre som muligt på at systemet virkede. På den måde kunne de have mere fokus på at supportere systemet i forbindelse med implementeringen. Dette fokus var vigtigt at få, efter implementeringen i Sverige gik skævt. Dette kunne have været undgået, hvis projektgruppen, i tide, havde opdaget at organisationen i Sverige ikke var klar og forud for udrulningen havde fokuseret mere på OCM fokusområdets opgaver. Klean har igennem deres projekt haft stor fokus på at ændre Glosters tankegang på flere områder. Dette var essentielt for at få Gloster til at forstå, hvorfor de mange ændringer var nødvendige. Klean har i modsætning til DS haft mulighed for at levere ofte, som de agile udviklingsmodeller foreskriver. Dermed har de kunne rette systemet til hen af vejen på baggrund af den feedback de fik fra Gloster. Leveringerne af systemet er derfor sket iterativt og inkrementelt på en gang. Udrulningerne er ikke sket så ofte, men har ligeledes været en iterativ og inkrementel proces. Således er der udrullet en ny del, samt itereret over det allerede implementerede. Dette mindre projekt har i forhold til implementering kunne holde sig i langt højere grad til det de agile udviklingsmodeller foreskriver. Specielt Scrum har været udgangspunktet for Kleans implementerings strategi. Det, at de har kunnet holde sig tæt til en metodik gør også, at de har haft nemmere ved at styre implementeringen, da de har haft en Side 42 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn guideline i form af Scrum. Hvorimod DS har måtte prøve sig frem og lære af deres fejl. Denne guideline har uden tvivl bidraget til Kleans succes indenfor denne KSF, udrulning. 7.7 Uddannelse og træning Teori Mange virksomheder har stor fokus på at implementere IT-­‐løsningen hurtigt for at sikre ”return on investment”. Derfor bliver vigtigheden af uddannelse og træning ofte overset. Uddannelse og træning af brugerne i det nye system er et vigtig led i at forankre systemet i organisationen. Samtidig sikres det at systemet bliver brugt på den tiltænkte måde, hvilket i sidste ende sikrer den værdi systemet var tiltænkt at give; den ovenfor omtalte ”return on investment”. En korrekt træning af brugerne kan yderligere markant nedsætte den modstand der kan komme imod et nyt system. Ved implementeringen af et nyt IT-­‐system i en hel organisation vil der altid ske et større eller mindre effektivitetsfald. Denne reducering af effektiviteten kan mindskes ved hjælp af uddannelse og træning. En tommelfingerregel i IT-­‐
branchen siger, at der skal bruges 10-­‐20% af udgifterne til en IT-­‐implementering på uddannelse og træning (Deloitte, 2013). Selve træningsprogrammet kan tilrettelægges på mange forskellige måder. Et kendt begreb inden for uddannelse og træning er superbrugere. En superbruger fungere som et bindeled mellem IT-­‐afdelingen og brugerne, men befinder sig lokalt blandt brugerne i en bestemt afdeling i organisationen. Det er superbrugerens opgave at støtte medarbejderne i anvendelse af ny teknologi. Det er vigtigt at superbrugeren har en høj integritet i forhold til medarbejderne, for at kunne skabe bro mellem brugerne og det konkrete IT-­‐system. Analyse Dansk Supermarked har igennem projektet ført et koncept de kaldte Trainer-­‐Trainer. Ideen bag dette var at projektgruppen udannede nogle udvalgte personer de kaldte Trainer-­‐
superbrugere i brugen af systemet. Disse personer var med i hele projektforløbet, under ”showly views” og diskuterede løsningen med projektgruppen. Efter deres arbejde i projektgruppen var afsluttet tog trainer-­‐superbrugerne tilbage til de afdelinger i organisationen de kom fra. Her skulle de organisere og forestå træningen af medarbejderne, som efterfølgende lærte viden om brug af systemet videre længere ude i organisationen. På den måde fik DS skabt en forgrening ud igennem organisationen af personer, der kunne træne en anden medarbejder. DS arbejdede altså bevidst med Trainer-­‐superbrugere. Organiseringen af dem var op til OCM fokusområdet i projektgruppen. Med 25.853 brugere af systemet var der naturligt en stor forskel mellem de ansattes IT-­‐evner (Dansk Supermarked, 2014 B) . Derfor har det været vigtigt for DS, at kunne kommunikere med alle medarbejdere ud fra deres niveau. Antallet af Trainer-­‐superbrugere var skaleret efter, hvor stor en organisation de skulle træne, og hvor hurtigt de skulle nå ud til dem. Dette skyldtes, at der nogle steder var tusinder af brugere og andre steder kun ti (Bilag 2, linje 554-­‐557). Side 43 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Et andet og vigtigt koncept DS arbejdede med var ”just-­‐in-­‐time-­‐training”. Dette koncept omfattede, at der skulle trænes brugere så tæt på go-­‐live fasen som muligt. På den måde havde brugerne læringen frisk i erindringen og driftstabet blev derfor mindre. Den deciderede træningsplan som DS kørte med var en plan konsolideret mellem BPO og OCM fra projektgruppen. Her var der tale om en plan over, hvem der skulle trænes hvornår, hvor mange skulle trænes, og hvem havde ansvaret for hvad. Derudover var meget af ansvaret lagt over på forretningsenhederne selv. Når der har været tale om decideret specialisttræning trænede projektgruppen selv disse specialister op fra bunden. Antallet af specialister var dog meget begrænset og derfor er denne træningsform ikke et generelt billede af den træningsmode, der generelt blev anvendt under implementeringen. I første omgang var Kleans træningsopgave indbefattet i at træne Gloster i at føre online markedsføring. Dette område havde Gloster intet knowhow omkring og skulle derfor lære det fra bunden, inden det ville give mening for Klean, at uddanne dem i selve systemanvendelsen. Herefter har Klean sendt personale til Glosters hovedkontor i Bristol for at træne brugerne af det udviklede system (Bilag 3, linje 108-­‐106). På den måde sikrede de sig, at brugerne var i trykke og vante omgivelser, havde de daglige redskaber til rådighed og derved fik en bedre indlæring. Organisationen, der skulle trænes i dette lille projekt, var langt mindre end hos DS. Derfor har de kunnet have en meget mere fokuseret personlig træning af hver enkelt bruger. Noget som DS kun gjorde ved de specialister, der skulle supportere systemet. Delkonklusion Både DS og Klean har sørget for, at denne vigtige succes faktor er blevet opfyldt. Dog er dette gjort med to meget forskellige udgangspunkter grundet omfanget af brugere, der skulle trænes. Klean har kunne føre et uddannelsesforløb meget tæt på de reelle brugere. Her er der tale om en gruppe på fem personer, der arbejder i Glosters marketing afdeling plus nogle ledere, som skulle trænes. Derfor har det været muligt at gennemføre et træningsforløb, hvor Klean har haft medarbejdere på Glosters hovedkontor og gennemgået systemet for brugerne, vist dem, hvordan systemet skulle anvendes og svaret på diverse spørgsmål. Modsat er Dansk Supermarked en enorm organisation med 25.853 brugere af systemet, heraf er 150 superbrugere (Dansk Supermarked, 2014 B). Det havde den konsekvens at de ikke kunne føre en træningsmetode som Klean, da dette ville have krævet alt for mange ressourcer og være for langsommelig. Uddannelsen og træningen lykkedes alligevel for DS igennem deres trainer-­‐trainer koncept og et fokus på at træne ”just-­‐in-­‐time”. På den måde kom de forholdsvist hurtigt ud i alle hjørner af organisationen på de rigtige tidspunkter. Det kunne ikke undgås, at der skete et informationstab jo længere ud i ”trainer-­‐kæden” de kom. Dette har dog ikke haft den helt store påvirkning for DS, da det sidste led er deltidsmedarbejdere og ungarbejdere, som altid har adgang til en ansvarshavende medarbejder, som er uddannet højere oppe i ”trainer-­‐kæden”. På den måde havde det ikke store driftstab, da disse brugere havde en ansvarlig at referere til, når de var på arbejde. Desuden havde disse brugere heller Side 44 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn ikke et stort ansvar for selve driften, og derfor led DS heller ikke et stort driftstab på disse ansatte. Med så mange brugere af systemet har der naturligt været stor forskel mellem de ansattes IT-­‐evner. Derfor har det været vigtigt for DS, at kunne snakke med alle medarbejdere i ”øjenhøjde”. Denne udfordring løste de med trainer-­‐trainer konceptet, da ”træneren” på den måde, i det fleste tilfælde, er ”elevens” nære kollega. Det var naturligt at en direkte kollega til medarbejderen var den, der kendte medarbejderens IT-­‐evner, omstillingsparathed osv. bedst. Således ses der her to succesfulde men forskellige måder at håndterer uddannelse og træning på. 7.8 Omstrukturering af forretningsprocesser Teori Informationsteknologi har historisk set haft en stor rolle i forhold til omstrukturering af forretningsprocesser, også kaldet Business Process Reengineering (BPR). BPR er arbejdet med at restrukturere virksomhedens processer helt fra laveste til højeste niveau i organisationen. Dette kan gøre virksomheden mere konkurrencedygtig igennem lavere omkostninger, øget produktivitet og bedre kundeservice. En proces skal i denne sammenhæng ses som en række sammenhængende opgaver, der udføres for at opnå et veldefineret resultat. Procesforbedringerne kan både ske inden for virksomheden eller imellem virksomheder. Desuden skal omstruktureringen af virksomhedsprocesserne passe til strategien og visionen for virksomheden. Yderligere er det vigtigt, at der i forbindelse med en omstrukturering er en klar og tydelig kommunikation fra ledelsen til de berørte medarbejdere på lavere niveauer. Dette skyldes at mange mennesker ser forandringer som noget ubehageligt og til tider meningsløst. Derfor er det vigtigt at kommunikere ud, hvorfor disse ændringer er nødvendige, og hvorfor lige netop den berørte person er vigtig i den overordnede forandring. Ifølge bogen ”Power i projekter og portefølje” er der lavet en undersøgelse af ændringsprojekter i statslige myndigheder, styrelser og servicevirksomheder i fem europæiske lande. Her blev de ansatte spurgt om, hvad de troede ledelsen kunne gøre for at motivere medarbejderne til at se ændringer som en mulighed i stedet for en trussel. Her svarede hele 65% bedre kommunikation. Dermed er der ingen tvivl om, at kommunikation mellem ledelsen og de berørte medarbejdere er essentiel, hvis der skal skabes succes med at omstrukturere forretningsprocesserne i en virksomhed (Attrup & Olsson, 2012, pp.269-70). Analyse Hele visionen bag DS’s projekt har været, at harmonisere forretningsprocesserne på tværs af organisationen. Med andre ord: hvis der skulle bestilles kyllinger i Netto, Føtex, Bilka eller Salling, så skulle det gøres på den samme måde. Hos DS dedikeredes største delen af projektgruppen til at definere forretningsprocesserne. Området der fokuserede på denne opgave kaldtes Proces og beskrives yderligere under analyse af Projekt management og Side 45 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn organisation. Cirka 100 fuldtidsansatte har været beskæftiget med dette. Proces gruppen definerede forretningsprocesserne og ud fra denne definition blev det afgjort, om standardsystemet kunne supportere den eksisterende proces eller den kunne løses mere hensigtsmæssigt. Hvis dette ikke var muligt fordi behovet var specielt, måtte projektgruppen skræddersy systemet til processen. Ligeledes stod Proces gruppen for at træne de første brugere i de nye processer, hvorefter OCM fokusområdet organiserede den videre træning i deres trainer-­‐trainer koncept. Hele OCM området af projektgruppen har været drivkraften for, at få de nye forretningsprocesser til at fungere i forretningsorganisationen. OCM har med andre ord været snitfladen mellem projektgruppen og forretningen og har derfor stået for den primære kommunikation herimellem. Dermed stod OCM for, at forretningen var klar til implementeringen af systemet. Med andre ord gjorde de så vidt muligt forretningen klar til selv at bruge og supportere systemet, allerede fra starten af implementeringen. Det har været en nødvendighed at forretningen og brugerne var klar til systemet, da der blev implementeret en hel varekategori ad gangen. Dermed har brugerne skulle omstille sig til nye arbejdsprocesser fra den ene dag til den anden. Det store fokus på fart og momentum, i forhold til at få skabt et fundament, hvor alle arbejdede ensartet, har betydet at de mange små procesforbedringer ikke blev analyseret. De forretningsprocesser, som DS fokuserede på var som udgangspunkt, grundet Rapid Transformation modellen, kun de store og vigtige end-­‐to-­‐end processer. Dette blev gjort for at det primære standardsystem kunne kommer til at fungere. De mindre procesforbedringer er DS i gang med at lave nu. Således er målet på sigt, at der nås en 100%-­‐løsning og at systemet derved understøtter hele forretningen og DS får den optimale værdi af det nye system. Hele Kleans samarbejde med Gloster har været et projekt, hvor den grundlæggende måde Gloster drev virksomhed på skulle ændres. Projektet har hele vejen igennem været en forandringsproces for Gloster. De er gået fra at have processer bygget op omkring en traditionel/gammeldags virksomhed, hvor onlinedelen af virksomheden var eksisterende, men ikke blev brugt aktivt og dermed heller ikke udnyttet til sit fulde potentiale. Efter projektet er Gloster blevet til en virksomhed, hvor onlinedelen er den primære driver for virksomhedens fremtidige salg og markedsføring. Denne forandringsproces vil tage flere år for Gloster siger Martin Frederiksen (Bilag 3, linje 419). Klean har haft fokus på at levere et system, der vil gøre Glosters ledelse i stand til at tage beslutninger på baggrund af data. Hidtil har Gloster truffet beslutninger primært ud fra deres mavefornemmelse. Den omstilling til at træffe beslutninger på baggrund af dokumenterede informationer har betydet, at Gloster skulle adoptere en ny analyseproces. Den tidligere markedsføring og kommunikation med kunder, bestod i trykte sager som kataloger og brochure. Denne proces er blevet afskaffet i forbindelse med projektet. Fremadrettet er det intentionen, at Gloster skal markedsføre sig online via de sociale medier. Dette har medført en stor forandringsproces i måden at tænke markedsføring på. Gloster har yderligere fået implementeret en produktdatabase. Her gemmes data om alle møbler og kombinationer af Side 46 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn farver og stile. På den måde har Gloster en fælles digital database, hvor al produktinformation findes. Førhen var der ingen der kendte alle kombinationer af deres møbler. Således er dette et eksempel på, at processen med at finde frem til hvilke møbler der kan fås i hvilke farver er lettet betragteligt. Delkonklusion Der har hos DS været et konstant fokus på, at tilpasse systemet så lidt som muligt. Dette har haft den konsekvens, at de som første prioritet ville ændre forretningsprocesserne, så de passede til systemet. Kun hvis standardsystemet ikke supporterede forretningsprocessen, og det var umuligt at re-­‐designe denne, skræddersyede de systemet. En naturlig forlængelse af denne konsekvens er ligeledes, at omstrukturering af forretningsprocesserne har været en enorm opgave i dette projekt, hvilket også afspejles i at Proces gruppen har været ultimativt den største i projektgruppen. Valget om at levere en 80% løsning, har betydet, at DS måtte foretage en prioritering af de forretningsprocesser, der skulle understøttes. Det er sandsynligt, at der i blandt de resterende 20% ligger opgaver i at understøtte helt specielle og manuelle processer. Med dette menes der specielle arbejdsopgaver og processer, som kun få brugere arbejder med. Efter projektet er der således en opgave i fortsat at forbedre forretningsprocesser, men også at skræddersy systemet til at understøtte de sidste specielle arbejdsopgaver og processer, for at udnytte systemet optimalt og organisere hele organisationen omkring det nye system. Grunden til at omstruktureringen af forretningsprocesserne lykkedes for DS, skyldes i høj grad det arbejde, der blev udført af projektgruppens OCM fokusområde. Hvis OCM ikke havde forberedt forretningen på det kommende system, ville alle processer, nye som ”gamle” gå i stå fra den dag implementeringen skete. Da butikskæderne stadig havde åbent for kunderne ville det have givet massive problemer fra dag et for DS, hvis en sådan standsning af processerne fandt sted. Det skal nævnes, at DS ved den første implementering i Sverige, netop oplevede sådan problemer, fordi der på dette tidspunkt endnu ikke var stort fokus på OCM området og arbejdsopgaverne herunder. Øjeblikkelige problemer ville ikke forekomme i samme skala, hvis der kigges på Gloster. De sælger ikke deres produkter direkte til deres kunder via hjemmesiden (endnu), og ville derfor ikke påvirke deres kunder direkte. I det længere løb ville det have givet konsekvenser for Gloster, hvis de ikke lærte de nye processer, inden implementeringen. Dette skyldes, at de i en periode fra implementering skulle lære at bruge deres nye markedsføringskanaler korrekt, og derfor ikke ville kunne markedsføre sig korrekt og deraf miste omsætning. Klean har igennem hele projektet arbejdet tæt sammen med Gloster og kørt projektet i en hastighed, som Gloster har bestemt. På den måde har Klean bearbejdet Glosters processer og tankegang omkring deres processer. Derfor må det også konstateres, at Gloster har haft stor gavn af at arbejde så tæt sammen med Klean, at de reelt set har fungeret som deres IT-­‐afdeling. Der ses således at begge cases har implementeret et system som i høj grad har været en generator for BPR. Dette har som en naturlig forlængelse heraf fyldt meget i begge projekter, og vil gøre det i lang tid fremover. Side 47 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 7.9 Brugerinddragelse Teori Brugerinddragelse har fået en mere og mere fremtræden rolle i system udvikling. Specielt i de agile udviklingsmodeller er det en essentiel del. Her er hovedreglen, at brugerne er eksperterne i deres arbejde. Uden brugerinddragelse risikeres der utilstrækkelig udredelse af krav til systemet, som vil munde ud i et system uden de nødvendige funktioner. Samtidig fører brugerinddragelse i designfasen til en ejerskabsfølelse af systemet blandt de involverede. Dette har de fordele, at det fører til større villighed til at bruge det endelige system, bedre system design og generel bedre attitude overfor computerteknologi (Sun, 2013). Yderligere sørges der ved brugerinddragelsen for, at udviklerne lære brugernes fagudtryk, som så kan integreres i det endelige system. Brugerinddragelse bør ifølge de agile projektudviklingsmodeller foregå i alle stadier af et IT-­‐projekt, for at sikre succes i sidste ende. En metaundersøgelse lavet af Muneera Bano & Didar Zowghi siger, at der er fem perspektiver der skabes fordele ud fra når der involveres brugere (Bano & Zowghi, 2015): Psykologisk perspektiv, Ledelses perspektiv, Metodisk perspektiv, Kulturelt perspektiv og Politisk perspektiv. Under de forskellige perspektiver ligger i alt 19 forskellige fordele. Disse fordele vil ikke blive beskrevet nærmere, men indbefatter blandt andet bedre tilfredshed med systemet, bedre kommunikation, forbedre ledelsessituationen og forøgelse af brugen af det endelige system. Analyse DS har i stor grad satset på brugerinddragelse igennem hele projektet. Brugerne er blevet inddraget i projektgruppen, når det var deres sektion eller arbejdsområde, der blev berørt af projektet. De blev valgt ud fra, at de havde et indgående kendskab til forretningsprocesserne, havde et godt netværk i organisationen og var omstillingsparate af natur. Ud af hele projektgruppen var cirka halvdelen fra Dansk Supermarked, imens den anden halvdel var konsulenter fra blandt andet samarbejdspartneren KPS. Omtrent halvdelen af medarbejderne i projektgruppen fra Dansk Supermarked var fra DS brugergruppe. Det vil sige at omtrent ¼ af projektgruppen var tidligere medarbejdere fra forskellige dele af forretningen med kendskab til processerne, hvor de kom fra. Yderligere anvendte DS i udviklingsfasen ”structured walkthroughs” og ”showly views” med ledelsen og brugere for at få direkte buy in og feedback (bilag 2, linje 193-­‐197). Set med alle fem perspektiver fra Muneera og Didar’s undersøgelse har ”structured walkthroughs” og ”showly views” medført mange fordele i forhold til det endelige system. Blandt andet har det øget kvaliteten af slutproduktet og forbedret kontakten mellem forretningen og projektgruppen. Oprettelsen af en Business Process Ownergroup hos DS har ligeledes været et essentielt værktøj til beslutningstagen i forhold til forretningen. Det var BPO gruppen, der skulle diskutere forretningsmæssige problemstillinger. Således har BPO gruppen fungeret som et Side 48 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn fælles beslutningsrum for alle afdelinger af organisationen. Det var her de for alvor arbejdede på, at optimere på tværs af organisationen og ikke lave suboptimering (Bilag 2, linje 579). Klean har igennem deres projekt haft en tæt dialog med Gloster, om hvad de gerne vil have. På trods af den geografiske afstand mellem de to parter, har Gloster været seriøse omkring at være med i processen. Gloster har derfor fløjet medarbejdere til Aarhus for at deltage i projektet ved flere lejligheder. I starten af projektet gennemførtes et ni dages workshop forløb, hvor Gloster var tilstede på Klean’s kontor i Århus (Bilag 3, linje 160-­‐164). På denne workshop blev hele referencerammen for projektet diskuteret. Efterfølgende var der en tæt dialog mellem de to parter via Skypemøder hver tirsdag og fredag, foruden en løbende kommunikation hver dag. Klean leverede et stykke færdigt system, hver anden uge. Herpå fik de feedback fra Gloster og kunne derpå iterere over det arbejde der var blevet gjort, og eventuelt tilrette systemet på baggrund af feedbacken. Delkonklusion Der er ingen tvivl om at en stor del af projekternes succes ligger i brugerinddragelsen. Den dybe dialog med forretningen har ved begge projekter været en vigtighed. Klean går i dette projekt ind og indtræder som Glosters IT-­‐afdeling, og fik som en følge heraf en meget dybdegående dialog med Gloster. Klean har haft mulighed for at snakke med alle påvirkede medarbejdere i Gloster, hvorimod DS har måtte vælge nogle nøglepersoner i organisationen, der måtte repræsentere baglandet. For DS har det haft den betydning, at detaljegraden har manglet i forhold til krav, men med deres scope nedsættelse til 80% har den detaljemangel været kompenseret derigennem. Klean har i forbindelse med projektet fulgt den agile grundskole for brugerinddragelse. Dog har de ikke kunne holde deres normale sprintmøde hver anden uge, som de ville have gjort under normale omstændigheder. Dette har de kompenseret med ved at anvende Skype møder 2 gange om ugen, for at Gloster hele tiden kunne følge med i processen og give feedback. Begge projekter har via deres brugerinddragelse fået mange fordele, når der kigges fra alle fem perspektiver beskrevet i teorien. En af de største fordele for dem, når det Psykologiske perspektiv antages, er at de har fået en høj grad af accept fra brugerne af systemet. Dette skyldes at brugerne via brugerinddragelsen er beviste om, at systemet er lavet til deres arbejdsplads, behov og krav (Bano & Zowghi, 2015). Denne accept må konkluderes at være højest i det lille projekt frem for det store, da der her var mulighed for at inddrage en større del af brugerne. 7.10 Projekt management og organisering Denne KSF vil blive analyseret ud fra to punkter, som går igen under delafsnittene Teori og Analyse. Herefter vil der samlet set rundes af i delkonklusionen. De to punkter er Organisering og Risikostyring. Side 49 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Teori -­‐ Organisering Chow & Cao (2007) har i deres artikel to attributter omhandlende organiseringen af projektgruppen, som understøtter denne KSF. Projektgruppens medlemmer skal have høje kompetencer og ekspertise og så skal de have stor motivation. Der ligger således en opgave i at få udvalgt de rette medlemmer til teams i projektgruppen. De agile projektudviklingsmodeller foreskriver, at der skal arbejdes i miljø, hvor projektgruppen og brugerne er tæt på hinanden. Det understøttes også af artiklen fra Chow & Cao, som har en attribut der hedder ”Collocation of the whole team” (Chow & Cao, 2007,
p.970). Miljøet skal fremme samarbejde og give plads til de kreative aktiviteter der undervejs skal udføres. Hvis projektgruppen sammensættes af medarbejdere fra en etableret organisation, som hver især har andre funktioner, kan det være en god ide at trække dem ud af deres vante arbejdsmiljø. Det skal de for at de kan fokuserer på projektet og ikke bliver forstyrret af ting fra deres normale virke i organisationen. Dette kan yderligere have den afledte effekt, at de nemmere tilpasser sig den agile tankegang, fordi omgivelserne også har skiftet. Ligesom brugerne skal være tæt på projektgruppen, skal projektets ejere, altså kunden, også være tæt på. Dette for at beslutninger hurtigt kan blive taget og der ikke bruges tid på at vente på beslutninger, der skal gennemgå en traditionel hierarkisk organisationsstruktur. -­‐ Risikostyring Som tidligere nævnt er risikostyring en vigtig del af projekt management. Fra litteraturen er der fortalere for, at de agile udviklingsmodeller i sig selv er med til at styre risici i en sådan grad, at der ikke yderligere behøver at være fokus på risikostyring. Der er dog også fortalere for det modsatte, der mener at den i de agile projektudviklingsmodeller inkluderede risikostyring ikke er tilstrækkelig, og at der derfor bør arbejdes yderligere med risikostyring. Det er dog generelt gældende, at en stor risikofaktor for IT-­‐projekter er skiftende krav og omgivelser (Hijazi et al., 2012). Der kan argumenteres for, at de agile projektudviklingsmodeller i sig selv er med til at håndtere skiftende krav og omgivelser på et passende niveau. Det er tidligere beskrevet, at de agile projektudviklingsmodeller tager positivt imod nye og skiftende krav. Et af grundprincipperne er tæt kommunikation mellem projektgruppen og interessenter, herunder brugere, ejere og sponsorer, hvilket er med til at nye krav kommer så tidligt i projektet som muligt. At kravene kommer fra brugere tæt på projektgruppen resulterer yderligere i, at eventuelle misforståelser kan ryddes af vejen med det samme. Derudover medvirker den iterative arbejdsform til, at der arbejdes ud fra ”unge” krav. Med unge krav skal forstås, at kravene til de funktioner, der arbejdes på i et interval også er blevet udredet i samme interval og dermed er forholdsvis nye. At kravene er unge er med til at sikre, at de funktioner der kodes til en levering bygger på det aktuelle miljø og den virkelighed, der er gældende for leverancen. Således bevirker grundprincipperne for de agile projektudviklingsmodeller, at skiftende krav og miljø vendes til en fordel. Side 50 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Hvis et projekt ikke leverer det forventede, ikke leverer til tiden eller ikke leverer indenfor budgettet kan det ende med at fejle. Disse tre ”fejltyper” kan omsættes til tre faktorer; Scope, Tid og Økonomi, som tidligere er beskrevet som de tre begrænsende faktorer af projekttrekanten. De tre faktorer repræsenterer således også en risici for at projektet fejler. Det kan der kompenseres for ved, at tillade ændringer i den ene eller to af de tre faktorer. Om et projekt er stort eller lille, er det en god ide at fokuserer på, at den tekniske kvalitet er i top. Dette kom ”The Agile Alliance” til enighed om, og de beskriver det i det niende af de tolv principper som lyder: ”Continuous attention to technical excellence and good design enhances agility.” (The Agile Alliance, 2001 B) Bag udsagnet teknisk kvalitet gemmer sig blandt andet det at holde sig til standarder. Det gælder både, når der tales om kodning, opbygning af teknisk arkitektur med videre. Ved at holde sig til standarder bliver systemet mere overskueligt og derved mindskes risikoen for fejl i den tekniske del af systemet. Specifikt i forhold til store ERP systemer gælder det yderligere, at det for så vidt muligt skal undgås at skræddersy løsningen. Det fremgår af Nah & Delgado’s artikel (Nah & Delgado, 2006), at der i litteraturen er bred enighed om, at dette er vigtigt. I forbindelse med implementeringen af et nyt system, er der altid risiko for at der vil opstå en modvilje mod forandring fra brugernes side. Da projektet ikke bliver en succes, medmindre brugerne anvender det nye system, er denne risiko også relevant at tage højde for. Analyse -­‐ Organisering Klean er en konsulentvirksomhed, som har inkorporeret den agile tankegang i hele deres virksomhed. De er lokaliseret i et ældre, men moderniseret byggeri i flere etager. Her er indretningen tydeligvis med til at fremme kommunikationen og samarbejdet blandt projektgruppen. Udviklerne sidder i et stort rum med et åbent miljø og plads til, at der rundt omkring kan siddes overfor hinanden. Derudover er der et større mødelokale, som er indrettet med et stort mødebord. Væggene kan der skrives direkte på, hvilket giver en kæmpestor hvid tavle og dermed plads til at slå kreativiteten løs. Oppe under kvisten, er der et lounge miljø, hvor projektgruppe og kunder kan drøfte projektet i uformelle omgivelser. Alt i alt kan understøtter miljøet projektgruppen i deres agile arbejdsform. Projektgruppen har igennem projektet bestået af 15 forskellige medarbejdere fra Klean. Derudover har Gloster været involveret undervejs ved at have medarbejdere til stede hos Klean til udvalgte møder. Projektet for Gloster var en smule anderledes end hvad Klean er vant til, fordi Gloster har deres kontor i England, men også har medarbejdere siddende i USA og på deres fabrikker i Indonesien. Således har Klean oplevet at arbejde med en kunde, som fysisk var langt væk. Det har haft den konsekvens, at hvor en dansk kunde i højere grad ville deltage fysisk til mange møder hos Klean, så har Gloster ikke haft samme muligheder for fysisk at være til stede. Side 51 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Gloster har dog flere gange haft medarbejdere sendt til Aarhus, både fra England og USA. Projektgruppen hos Klean er professionel og medlemmerne heri har erfaring med den agile arbejdsform. Hvert medlem er ekspert indenfor sit område og kender de andre medlemmers svagheder og styrker. Således er organiseringen samlet set med til, at det agile projekt kan blive en succes. Dansk Supermarked har i højere grad kunnet bringe brugerne tæt på projektgruppen. Cirka halvdelen af projektgruppen var besat af medarbejdere fra DS. Den resterende halvdel bestod af eksterne konsulenter fra blandt andet samarbejdspartneren KPS. Af de medarbejdere som kom fra DS, var halvdelen hentet fra DS brugergruppe. Dvs. at en fjerdedel af projektgruppen repræsenterede brugerne (Bilag 2, linje 572-­‐577). Disse medarbejdere blev udvalgt på baggrund af tre primære kriterier. De skulle have dyb indsigt i eksisterende forretningsprocesser; de skulle have et godt netværk fra den organisation, de kom fra; de skulle have en personlig profil der viste, at de var forandringsparate (Bilag 2, linje 605-­‐607). Mange af brugerne, hentet fra brugergruppen, endte med at sidde i projektgruppen længe. Det gav dyb indsigt i systemet der blev arbejdet på. Omvendt betød det også at de langsomt kom længere og længere væk fra deres viden om forretningsprocesserne, der hvor de var hentet fra. For at sikre at projektgruppen havde viden om de helt aktuelle forretningsprocesser, hentede de typisk yderligere et par personer ind til projektgruppen. De skulle sikre at al eksisterende viden, om det område der arbejdedes med, var tilgængeligt for projektgruppen. Således trak projektgruppen eksempelvis to fuldtidsmedarbejdere ud fra tekstilområdet i fem måneder for at integrere dem i projektgruppen. For at medarbejderne i DS projektgruppe kunne fokusere fuldt ud på projektet, samt af andre mere praktiske årsager, var projektgruppen fysisk placeret i deres egne kontorbygninger (projektbygninger). De to bygninger, som lå lige ved siden af hinanden, var beliggende i Aarhus tilstødende til andre kontorbygninger i brug af DS. Den største af de to bygninger havde 150 faste pladser. Her var blandt andet et stort, åbent kontormiljø hvor 100 mand var placeret. Det var det såkaldte kerneteam der sad der. Tilstødende til dette rum var andre små rum samt mødelokaler og køkkenfaciliteter. Således havde kerneteamet hele deres daglige gang her (Bilag 2, linje 622-­‐630). De eksterne konsulenter, som også var en integreret del af projektgruppen, var fra hele verden. De blev hentet ind fordi, de havde relevant erfaring fra lignende projekter. Flere af dem flyttede til Aarhus og boede her med deres familie, imens projektet stod på. Det sikrede, at konsulenterne var tilgængelige og fokuserede fuldt ud på projektet. At konsulenterne kom fra flere verdensdele resulterede i, at det var et meget livligt projekt med god inspiration fra folk med forskellige nationaliteter, kulturer og erfaringsgrundlag. Når hele projektgruppen var samlet på et sted, og der her var samlet en masse relevant erfaring og kompetencer, var de i stand til, ad hoc, at samle relevante medarbejdere til et møde (Bilag 2, linje 630-­‐644). Det var hurtigt og effektivt og var med til at sikre at projektet holdte momentum. Der har været fokus på at skabe en projektgruppe, hvor alle var ligeværdige, men kom med forskellige kompetencer og bød ind med den viden, de besad (Bilag 2, linje 407). Det har Side 52 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn været en af grundene til, at de eksterne konsulenter som udgangspunkt var hyret ind på timebasis. På den måde kunne disse konsulenter bedre indgå som en del af projektgruppen og arbejde på tværs af hele løsningen. Der var dog også små sideløbende projekter, hvor eksterne konsulenter blev hyret ind for at lave specialløsninger. Nogle af disse små projekter blev lavet ud fra en fastprisaftale, og her var DS således ikke i samme grad i stand til at inkludere konsulenterne i resten af projektet. I forhold til at have eksterne konsulenter til at arbejde på sideløbende projekter, har projektgruppen haft en udfordring i at kunne få de forskellige arbejdsformer til at fungerer. Projektgruppen har arbejdet agilt, hvilket blev anset som værende nødvendigt for at kunne arbejde effektivt (Bilag 2, linje 183). Det var dog ikke alle de sideløbende projekter, som også arbejdede agilt, eller som DS kunne påvirke. Der har således været et fokus på at få forskellighederne til at spille sammen (Bilag 2, linje 650-­‐663). Projektgruppen hos Dansk Supermarked har været inddelt i fire fokusområder, navngivet som Proces, Udvikling, Teknisk Infrastruktur og OCM (Organizational Change Management). Proces området var det største af de fire, og her arbejdedes der med at udrede krav og definere forretningsprocesser, tilpasse standardløsningen, teste systemer, træne brugere og rulle systemer ud i forretningen. Udviklings området stod for at udvikle og kode de nødvendige specialløsninger. Fokusområdet Tekniske infrastruktur stod for, at den nødvendige infrastruktur til at understøtte systemerne var tilgængelig. Slutteligt stod OCM området for at forretningen var klar til at bruge de nye systemer, herunder uddannelse og træning (Bilag 2, linje 38-­‐51). Der har ikke været et fast antal medarbejdere fra projektgruppen sat af til hvert område og der har ikke været en fysisk opdeling efter disse områder. Medarbejderne har været flyttet rundt efter behov. Antallet af projektledere, teamledere og teams i figur 6, er derfor ikke et udtryk for det reelle antal, men skal give et indblik i ideen bag organiseringen. Over de fire fokusområder, som ses i figur 6, sad der to projektledere, som havde det overordnede ansvar for projektet. Deres ansvar var fordelt så en havde ansvaret for den leverancemæssige del og den anden havde ansvaret for den forretningsløsning, der blev leveret (Bilag 2, linje 60-­‐63). De to overordnede projektledere refererede til en programdirektør. Han havde det helt overordnede ansvar for, at der blev leveret en løsning, der understøtter forretningens behov og den overordnede forretningsstrategi. Programdirektøren refererede til koncernchefen, som under sig havde en stabsfunktion siddende. Denne stabsfunktion er den såkaldte Business Process Ownergroup (BPO). Denne gruppe blev oprettet for at støtte projektgruppen og foretage beslutninger på et strategisk plan. Den bestod af ledere fra alle dele af organisationen. Side 53 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Figur 6 -­‐ Organisationsdiagram over projektgruppen (Egen tilvirkning) -­‐ Risikostyring Klean følger som tidligere nævnt en af de agile projektudviklingsmodeller, nemlig SCRUM. Her arbejder de med korte sprints, som i projektet for Gloster var af to ugers varighed. Efter de to ugers varighed var der en leverance af et stykke fungerende software, som Gloster kunne give deres respons på. Ved hele tiden at arbejde inkrementelt og iterativt i de korte sprints, havde Gloster ofte mulighed for at se, hvordan løsningen udviklede sig. Derudover kunne Klean nemt forklare, hvad de ville arbejde med i det efterfølgende sprint, fordi de to ugers arbejde nemt kunne overskues. På den måde kunne Klean ofte korrigere deres arbejde, hvis nødvendigt, på baggrund af den respons de fik fra Gloster. Klean er således et godt eksempel på, hvordan den agile arbejdsform i sig selv er med til at styre risici. Hvis Klean står overfor et projekt med høj risiko, indleder de med et såkaldt ”for-­‐projekt”. Dette for-­‐projekt har en mindre fastsat størrelse således, at budgettet er acceptabelt sat op imod den aktuelle risici. Det er naturligvis ønsket at for-­‐projektet er en succes, men fejler det kan tabet accepteres. Dette hænger naturligt sammen med for-­‐projektets formål, som er at teste, hvorvidt det er muligt at lave det egentlige projekt eller ej. Hvis for-­‐projektets resultat er, at det egentlige projekt ikke kan lade sig gøre, da er omkostningerne for for-­‐projektet sandsynligvis minimale i forhold til et eventuelt tab på det egentlige projekt. Det tab der ville lides, hvis projektet var igangsat, og det først langt inde i projektarbejdet blev opdaget, at projektet ikke kunne gennemføres, kan have store konsekvenser. På den måde kan det siges, at for-­‐projektet fungerer som en slags realitetstjek, og dermed er en forebyggende handling, når der tales om risikostyring (bilag 3, linje 560-­‐564). Hvis resultatet af for-­‐projektet er positivt og det findes, at det egentlige projekt godt kan igangsættes er dette nu af betydelig mindre risici. Denne mindre risiko vil i langt højere grad kunne accepteres. For-­‐projekt som risikominimering bruges også af Klean til estimering. Klean bryster sig ved, at kunne levere estimater, der er ”best-­‐in-­‐business”. En af grundene til at de er så dygtige til at estimere, er at de ikke forsøger at estimere noget, de ikke ved noget om. Hvis de således føler Side 54 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn sig usikre om et projekt, bruger de et for-­‐projekt til at få den nødvendige indsigt. Derved får de også den nødvendige viden i forhold til at kunne leverer et holdbart estimat. For yderligere at skærpe deres evne til at levere holdbare estimater arbejder Klean med noget, de kalder en estimeringsfaktor. I et agilt projekt kommer projektlederen til at kende sine medarbejdere rigtig godt. Med en forholdsvis kort historik på sine medarbejderes estimater og faktiske tidsforbrug, begyndte Klean at kunne foretage individuelle tilpasninger af de udregnede tidsestimater. Hvis projektlederen beder to medarbejdere om at få et estimeret tidsforbrug for den samme opgave, er det langt fra sikkert, at svaret er det samme. Dette er ikke nødvendigvis et udtryk for, at de to medarbejdere ikke er lige dygtige og dermed ikke kan løse opgaven lige hurtigt. Derimod er det sandsynligt, at medarbejderne ikke er lige dygtige til at foretage estimering. En medarbejder kan have tendens til altid at overestimere eller underestimere. Ved at føre historik over de enkelte medarbejderes afleverede estimater og faktisk tidsforbrug, kan der udregnes en såkaldt estimeringsfaktor. Denne kan fremadrettet bruges af projektlederen til at tilpasse modtagne estimater, for dermed at få et mere præcis estimat. Ud fra dette defineres estimeringsfaktoren, som en faktor der bygger på historik og som multipliceres med et estimat for at foretage en justering, der giver et mere holdbart estimat. Dansk Supermarked valgte en tilgang til deres udrulning og implementering, som i høj grad var medvirkende til, at de bedre kunne håndtere de risici der var, ved de mest komplekse udrulninger. Det gjorde de ved at starte med udrulning og implementering, der hvor risici var lavest (Bilag 2, linje 266). Udrulningerne var overordnet delt op i lande og herefter varekategorier og det startede med en udrulning i Sverige. DS er kun til stede i Sverige med Netto kæden. Det samme gør sig gældende for Polen og Tyskland. Jævnfør Årsrapporten fra Dansk Supermarked for 2010 (Dansk Supermarked, 2011) var der i Sverige 128 Netto butikker. I Polen var der 212 og i Tyskland 324. Ud fra antallet af butikker vil implementerings-­‐
rækkefølgen for landene med Sverige først, efterfulgt af Polen, herefter Tyskland og slutteligt Danmark, således være det mest sikre. Dette fordi flere butikker alt andet lige øger kompleksitet og risici. Implementeringen i Sverige var en øjenåbner for projektgruppen. Organisationen i Sverige var ikke klar til at tage imod systemet, hvilket resulterede i at det påvirkede driften negativt og førte til et mindre samlet salg (Berlingske Business, 2012). Projektgruppen måtte for en periode drive forretningen i Sverige, fordi organisationen ikke var i stand til det. Projektgruppen reagerede på dette ved, at skrue op for indsatsen indenfor OCM området. Projektgruppen lærte således af deres ”pilot” projekt i Sverige. Det betød at de ved implementeringen i Polen var bedre rustet. OCM området havde fokus på, at der var en risiko for at organisationen ikke kunne klare opgaven i at håndtere systemet selv. Derfor fortog de risikostyring i form af, at træne og forberede den polske organisation i langt højere grad end det var tilfældet i Sverige. Således havde de allerede her mindsket risikoen for at organisationen i Polen ikke var klar. Det viste sig dog også at Polen i høj grad var klar til det nye system, de tog ansvar for alt og ville selv drive forretningen. Således kunne Side 55 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn projektgruppen koncentrere sig om deres arbejde og blot være til stede som en støtte for den polske organisation (Bilag 2, linje 355-­‐366). Dansk Supermarked er en forholdsvis gammel organisation og mange af deres medarbejdere, har arbejdet der i mange år. Derfor var mange medarbejdere også blevet eksperter indenfor deres felt og i brugen af det gamle DSA-­‐system. For at styre risikoen for, at medarbejderne ikke vil tage det nye system i brug, fokuserede OCM området meget herpå, og der blev arbejdet på at uddanne alle brugere til det nødvendige niveau. Derudover blev der fokuseret på at kommunikere ud til medarbejderne at selvom de, med det nye system, pålægges yderlige opgaver, så har det nye system stor værdi. Flere medarbejdere oplevede, at de fik pålagt yderligere opgaver med indførslen af det nye system end de havde haft hidtil. Derudover har indførslen af det nye system betydet ændrede processer for mange medarbejdere. Der er således mange grunde til, at det nemt kommer til at virke, som om det nye system er mere besværligt end det ”gamle”. OCM området havde således en stor opgave i, at kommunikere ud til medarbejderne, at selvom de måske bliver pålagt ekstra arbejdsopgaver, så giver det stor værdi et andet sted i organisationen (Bilag 2, linje 532-­‐541). Dansk Supermarked lagde stor vægt på, at tiden blev overholdt. Det var den vigtigste faktor set i forhold til projekttrekanten. Herefter kom økonomien, som også ansås at være forholdsvis vigtig. Det efterlader Scope-­‐faktoren, som den mindst vigtige af de tre. I DS accepterede de, at de ikke kunne overholde alle tre og således valgte de at gå på kompromis med scopet, i fald det skulle blive nødvendigt. Det er blandt andet derfor, de valgte at arbejde med en 80 procents løsning. Allerede da de havde sagt dette anerkendte de, ikke at kunne levere en 100 % løsning, og dermed accepterede de, at der kunne være fejl og mangler. (Bilag 2, linje 284-­‐289). I forhold til test af systemet har de også erkendt, at de ikke kunne nå at teste alting inden udrulningen og således gik de yderligere på kompromis med scopet (Bilag 2, linje 419). Således valgte DS at anvende scopet til at styre risikoen for at tiden ikke blev nået. Derudover skal det nævnes at Dansk Supermarked valgte, at de så vidt muligt ville tilpasse sig til SAP’s standardløsning. Det betød dermed også, at de ville skræddersy systemet mindst muligt og forsøge at holde sig til SAP’s standarder. Dette valg har været med til at mindske risici for, at der bliver kodet specialløsninger, som ikke fungerer ordentligt og ikke kan integreres som det var ønsket. Delkonklusion Klean er en professionel konsulentvirksomhed, som er vant til det agile projektarbejde. De har erfaring i gennemførelse af IT-­‐projekter, og de arbejder med det til dagligt. De har derfor haft visse fordele i forhold til Dansk Supermarked, som har sammensat projektgruppen til dette specifikke formål; at gennemføre Apollo-­‐projektet. Klean var nødt til at ændre på deres normale håndtering af brugerinddragelse, fordi Gloster geografisk har været i stor afstand til kontoret. Gloster var dog villige til at bruge de nødvendige ressourcer for, at Klean alligevel havde brugere til stede på kontoret i Aarhus til diverse møder. Derudover har de været gode til at anvende eksempelvis Skype og videokonferencer som kommunikationsform. Klean arbejder med korte sprints og hyppige Side 56 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn leveringer, hvilket gør at Gloster ofte har kunnet se, hvad der blev arbejdet med og dermed hele tiden kunne se løsningens udvikling. Derved har Gloster også ofte kunne give relevant feedback til Klean, som herefter kunne rette deres arbejde til. Denne måde er med til at sikre at projektet ikke løber af sporet og er således med til at styre risici herfor. Den fysiske placering af projektgruppen hos Dansk Supermarked, i et samlet kontormiljø, var helt bevidst, ligesom sammensætningen af projektgruppen også var velovervejet. Det resulterede i, at de fik masser af varierende erfaring, kreativitet og initiativ inkorporeret i projektbygningen. Der har været fokus på både sammensætningen af gruppen og at placeringen skulle understøtte det agile projekt. Dette var med til at skabe en fælles ånd om projektet; at de var ”in this together” og løftede i fælles flok. At Dansk Supermarked valgte at skabe denne kreative ”bobbel”, hvori projektgruppen opererede har i høj grad understøttet projektet og været en vigtig faktor for, at projektet blev en succes. Miljøet hvori projektgruppen opererede var også i høj grad med til at understøtte den agile kommunikationsform. Selvom det har givet Dansk Supermarked mange muligheder, at have eksterne konsulenter som en integreret del af projektgruppen, har det dog også medført en økonomisk risiko. Dette fordi der ikke har været et præcist overblik over omkostningerne til konsulenterne. Risikoen for at projektet fejler grundet nye eller ændrede krav i løbet af projektet, eller et ændret miljø, håndteres blandt andet ved, at de havde brugerne tæt på projektgruppen. DS gik så vidt, som til at omtrent en fjerdedel af projektgruppen bestod af ”gamle” brugere af systemet. Derudover hyrede de eksterne konsulenter med relevant erfaring og på den måde fik samlet en masse forskellig erfaring, som var med til at løfte projektet. At der var dette fokus på at samle erfaring og kompetencer i projektgruppen har ligeledes været med til at projektet blev en succes. Side 57 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 8 Diskussion Flere kritikere af de agile projektudviklingsmodeller mener ikke, at modellerne er så gode som de beskrives af andre. Mange kritikere anser de agile modeller for at afhænge for meget af den menneskelige faktor, at være ineffektive for store komplekse systemer og for at være meget afhængig af den eller de kontaktpersoner, der er hos kunden (Hijazi et al., 2012). Der kan argumenteres for, at den model en projektgruppe vælger at bruge, formentlig er en de har erfaring i. Hvis de ikke har erfaring heri, vil de formentlig få ekstern rådgivning i modellen. Dette gør at sandsynligheden for succes blive større, end hvis en projektgruppe uden erfaring eller rådgivning i agile modeller alligevel forsøger at arbejde agilt. Det kan yderligere argumenteres for at disse kritikpunkter er nogle, der kan risikostyres ud af. Vi mener, at de agile modeller bedst understøtter en af de vigtigste faktorer, der er gældende for nutidens IT-­‐
projekter, nemlig at brugerens krav og behov ofte skifter. Inden for risikostyring af IT-­‐projekter i forbindelse med de agile projektudviklingsmodeller er der to lejre. Den ene gruppe mener, at der i de agile projektudviklingsmodeller naturligt er indlagt risikostyring, fordi de er risikodrevne modeller. Derfor er der ikke behov for yderligere fokus på risiko end modellen lægger op til. Den anden gruppe mener, at risikostyringen ikke adskiller sig væsentlig fra de traditionelle modeller, og derfor bør der fokuseres på risikostyring som en del af projektet, og ikke overlade det til selve arbejdsformen i de agile projektudviklingsmodellen. Desuden mener denne gruppe også at den indbyggede risikostyring i de agile modeller, til tider er utilstrækkelig (Hijazi et al., 2012) Dette skaber således to forskellige opfattelse af, hvor godt de agile modeller understøtter risikostyring. Enten så er risikostyring i den agile projektudviklingsmodel tilstrækkelig, eller også er den ikke. Vi er enige i, at de agile modeller understøtter, at miljøet hvori der opereres kan skifte, eksempelvis som følge af omskiftelige krav fra kunden. Dog mener vi også, at risikostyringen afhænger meget af projektets størrelse og kompleksitet. Jo større et tab der lides, hvis projektet fejler, jo mere bør der fokuseres på risikostyring. Dermed mener vi, at der bør fokuseres mere på risikostyring, end der er integreret i modellerne, hvis projektet er stort og komplekst. Da vi har talt med en intern medarbejder i hvert projekt, vil der formentlig være en tendens til at respondenterne i høj grad snakker mere positivt om projektet. Derfor har vi ikke en komplet objektivitet i vores empiri. Dette kan medføre, at de to cases, er analyseret som mere succesfulde i brugen af agile modeller, end de reelt har været. Desuden er de to respondenter selv beslutningstagerne bag brugen af de anvendte udviklingsmodeller. Dette bevirker at begge respondenter har en positiv tilgang til disse modeller. Valget af de to teorier, fra Nah & Delgado (2006) og Chow & Cao (2007), som analysemodellen er baseret på ligger op til en diskussion omkring deres anvendelighed i denne analyse Side 58 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn sammenhæng. Der er i modellen kun medtaget de KSF som vi finder generelle, uanset om det er tale om et stort eller lille IT-­‐projekt. Derved er der også implicit meget fra den anvendte litteratur, som ikke er taget med. På den måde er det komplette billede af de to emner som artiklerne omhandler, heller ikke afbilledet i modellen. Derved kan der stilles spørgsmål ved om disse artikler med deres perspektiver har bidraget til opgaven. Nah & Delgado (2006) har et ERP implementerings perspektiv som analysemodellen ikke afspejler, da den er generel og ”neutral”. Chow & Cao (2007) har udelukkende et perspektiv på KSF i forbindelse med agile software projekter og er derfor heller ikke særlig generel. Der kan dog argumenteres for, at de har bidraget positivt til modellen på andre områder. Dette skyldes at de har tilbragt konkrete videnskabelige argumenter for, at opfyldelsen af de udvalgte KSF er essentielle i forhold til at opnå succes med et IT-­‐projekt. Uden denne baggrund til analysemodellen, ville der kunne stilles spørgsmål til modellens validitet i forhold til de udvalgte KSF. Nah & Delgado’s perspektiv er som nævnt på implementering af ERP systemer, og anvendes således for, at analysemodellen kan favne de store IT-­‐projekter. Chow & Cao’s perspektiv er netop den agile arbejdsform og passer således godt på vores behov. Til sammen mener vi at de to teorier giver den nødvendige understøttelse for de valgte KSF i denne opgave. 9 Konklusion Det kan som udgangspunkt konkluderes, at der i de to analyserede cases, er forskel på hvordan det lille og store projekt har fået succes med agilitet. For begge projekter har det været gældende at brugerinddragelse i udviklingsfasen har været essentielt for deres succes. Det kan dog konkluderes, at måderne hvorpå brugerinddragelse er sket, er forskellige grundet projekternes størrelse og projektgruppernes adgang til brugere. Dansk Supermarked har inkorporeret brugerne i selve projektgruppen, hvorved de har haft direkte adgang til brugerne og deres viden omkring forretningsprocesserne. På den måde har de draget fordel af brugernes konstante tilstedeværelse. Det har betydet at projektgruppen kunne holde momentum i projektet og ikke skulle bruge ekstra ressourcer på at kommunikere med forretningsorganisationen for at få kendskab til forretningsprocesserne. Gloster har ikke haft samme mulighed for, at have brugere siddende med projektgruppen under hele udviklingen. Klean har dog haft brugere fysisk til stede hos projektgruppen i forbindelse med workshops og udvalgte møder. Derudover har Klean gjort Gloster til en stor del af projektet gennem flere ugentlige telefon-­‐ og videomøder, hvorigennem de har fået feedback. Kleans lille projekt har skabt succes igennem deres tætte samarbejde og konstante kommunikation med Gloster. Derudover har Klean haft konsulenter siddende hos Gloster, for at træne og rådgive i brugen af systemet. På den måde har Gloster hele tiden været bevidst omkring Kleans arbejde og de har været forberedt til brugen af systemet, når der var udrulninger. For at klargøre organisationen i det store projekt måtte DS oprette et OCM fokusområde, som specifikt skulle sørge for at klargøre organisationen til brugen af systemet. Dette skyldes deres store organisation med 25.853 brugere, som de skulle kommunikere Side 59 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn tilfredsstillende med i løbet af projektet. Klean havde betydeligt nemmere ved at kommunikere tilfredsstillende med brugerne i Gloster, grundet Glosters lille brugergruppe. Derudover blev der implementeret hele varekategorier i et helt land ad gangen, hvilket også skabte ekstra kompleksitet. De kompenserede for kompleksiteten ved oprettelse og brug af OCM fokusområdet, hvilket var en stor faktor i forhold til deres succes med at udvikle systemet agilt. Begge projektgrupper har ved den agile udviklingsmodel kunne omstille sig på ændrede krav i løbet af projektet, hvilket har været det rigtige i begge projekter. Det må dog konkluderes at Klean har haft nemmere ved at omstille sig i forhold til DS, grundet deres mindre komplekse system. For at DS skulle kunne trække sig succesfuldt ud af deres projekt, var det nødvendigt for projektgruppen at sætte en forventning mellem dem og forretningen, om at det var en 80% løsning de leverede. Med dette træk, erkendte projektgruppen at de ikke kunne levere et perfekt system og på den anden side heller ikke kendte 100% løsningen. Dermed lavede projektgruppen risikostyring i form af en forbyggende handling, der sikrede at forventningerne til dem selv og fra forretningen var realistiske. Uden en reel mulighed for at lave et korrekt estimat af projektets omfang, kastede DS sig uden videre ud i et projekt, som de satte et løst femårigt tidsestimat på. Det viste sig at de kunne holde dette estimat, ved blandt andet at file på scopet. Klean har derimod i deres lille projekt haft stor succes med estimering grundet deres store erfaring på området. Desuden estimere de ikke noget de ikke kender til, således de ikke risikere at estimere forkert. I det tilfælde, at de ikke har fyldestgørende viden til at kunne estimere, laver de et for-­‐projekt, som giver dem dybere indsigt. Derved sikre de sig i høj grad, at de kan leverer det de lover. Endnu en stor succes faktor for det store projekt DS har gennemført er, at de har holdt sig så tæt til standardløsningen som muligt. De har ikke skræddersyet systemet uden, at det var strengt nødvendigt. Der hvor de har været nødt til at skræddersy, har de holdt sig inden for forskrifterne udstukket af SAP i, hvordan kodningen skulle være. På den måde har de ikke kun fået succes med implementeringen af det nuværende system, men kan i fremtiden også drage stor fordel af opgraderinger og nye versioner. De har gjort kommende opgraderinger så nemme som muligt at implementere, fordi de netop har holdt sig tæt på standarden. Dette var et af de principper, som DS holdte sig til for at kunne gennemføre projektet succesfuldt. Disse principper blev ikke på noget tidspunkt brudt, selvom det betød DS måtte gå væk fra at være agile i nogle tilfælde. Blandt andet vedrørende deres leveringer og tests. Det har været vigtigt i det store projekt at have disse principper, som alle i projektgruppen fulgte. Et andet vigtigt princip de holdte sig til var, at de fokuserede på end-­‐to-­‐end processer. På den måde sørgede de for, at systemet succesfuldt hængte sammen på tværs af de forskellige forretningsenheder der er i organisationen. Dette var med til at sikre at projektgruppen fokuserede på at optimeringen skulle ske på tværs af hele organisationen og ikke som suboptimeringer. Grundet projektets størrelse har DS ikke kunne lave leveringer så ofte som Klean kunne i deres projekt. Dette var en direkte konsekvens af deres princip, om at kigge på end-­‐to-­‐end processer og valget om at implementere hele varekategorier ad gangen. Dermed måtte DS Side 60 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn omgå den agile tilgang ved at levere knap så ofte, men til gengæld bruge flere ressourcer på at være sikre at leveringerne var af høj kvalitet. Klean har med stor succes kunne drage fordel af deres meget flade struktur i projektgruppen hvilket betød at alle var lige og information frit flød mellem medarbejderne. Dette har højnet produktiviteten og kreativiteten i forbindelsen med udviklingen af systemet. DS har med lige så stor succes organiseret sig på en måde hvorpå information og kommunikation frit kunne flyde i projektgruppen. Dog må det konkluderes at organisationen ikke har været helt så flad som i det lille projekt. Denne lidt mere hierarkiske organisering ses dog som nødvendig for at kunne styre projektgruppen, taget dens størrelse og projektets omfang i betragtning. Det kan ligeledes konkluderes, at en stærk sponsor er en vigtig faktor for at projektet ender i succes. Et tydeligt eksempel herpå var da opbakningen forsvandt fra topledelsen i DS, da koncernchefen fratrådte. Her mistede projektgruppen for en stund deres primære sponsor og det resulterede i at projektgruppen helt tabte momentum, da de ingen styring og opbakning havde fra toppen. Det resulterede i at flere forretningsenheder begyndte at suboptimere, hvilket var stik imod visionen for projektet. Da den nye koncernchef kom på plads, fik projektgruppen igen en primær sponsor som var i en position, hvor de nødvendige beslutninger kunne blive truffet for at få projektet tilbage på sporet og ende ud i succes. Hastigheden i begge projekter må også konkluderes at have bidraget til deres succes. De agile udviklingsmodeller foreskriver, at man hurtigst muligt får implementeret systemet og derefter inkrementelt og iterativt arbejder videre med det. På den måde har begge projekter fået en effektiv feedback af det udrullede system. DS har haft gavn af at implementere systemet i lille skala i Sverige inden, de derefter implementerede det i de mere komplekse lande, Polen, Tyskland og til sidst Danmark. På den måde har projektgruppen kunne tage ved lære undervejs og være mest muligt rustet til de mest komplekse implementeringer. Således kan det opsummeres at selvom projekterne i de to cases begge har opnået succes ved brug af agile projektudviklingsmodeller, så har den agile model ikke været tilstrækkeligt i det store projekt. Her måtte man justere modellen og på få områder benytte en mere traditionel tilgang. Side 61 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 10 Perspektivering Vores opgave tager udgangspunkt i agile projektudviklingsmodeller. Det at Dansk supermarked har anvendt en agil projektudviklingsmodel udviklet af KPS, må antages at gøre sammenligningsgrundlaget af de to projekter sværere, end hvis det havde været en kendt og velbeskrevet model. Konklusionen af vores analyse er kun gældende for de to analyserede cases. Resultatet kan derfor ikke generaliseres på andre henholdsvis store og små agile udviklingsprojekter. Da der kun er to cases i denne analyse, åbner det op for muligheden, for at lave en undersøgelse med flere cases og ud fra dette komme med nogle generelle resultater. Afhandlingens resultat giver grobund for at konkludere, at det ikke kan lade sig gøre for store komplekse projekter at følge den agile udviklingstankegang 100%. Det vil derfor være nærliggende at undersøge nærmere, hvorfor dette ikke er muligt, og om der kan udvikles en generel agil model, der kan understøtte sådanne store komplekse projekter. Ligeledes giver afhandlingen anledning til at tro, at store komplekse projekter er nødt til at lægge stor vægt på nogle bestemte områder, for at kunne anvende de agile udviklingsmodeller. Det kan ikke udelukkes at være generelt gældende og vil derfor være relevant, at få uddybet igennem en større og mere specifik undersøgelse herom. Det kan, som anbefaling til virksomheder, der står overfor et stort og kompleks IT-­‐projekt, siges at de agile udviklingsmodeller skal overvejes grundigt. Det menes ikke, at de ikke kan bruges. Men det kræver dog et langt større kendskab til modellerne, for at kunne anvende dem i sådanne projekter. Derfor bør man se modellens svagheder i øjnene, i forhold til det projekt og den organisation man står overfor, og kompensere herfor ved at bruge ekstra ressourcer på nogle områder eller kompenserer med andre modeller, som vist i de to cases i denne opgave Side 62 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 11 Referenceliste Attrup, M.L. & Olsson, J.R., 2012. Power i projekter & portefølje. 2nd ed. Danmark: Jurist-­‐ og Økonomiforbundets Forlag. AU Career, 2014. Virksomhedsprofil: Dansk Supermarked. [Online] Available at: http://studerende.au.dk/studier/fagportaler/import/tilstuderende/karrierecenter/moedvor
espartnervirksomheder/virksomhedsprofiler/dansksupermarked/ [Accessed 2 April 2015]. Bano, M. & Zowghi, D., 2015. A systematic review on the relationship between user involvement and system success. Information & Software Technology, Februar. pp.148-­‐69. Berlingske Business, 2012. IT-­‐problemer sænker Netto i SverigeBerlingske Business. [Online] Available at: http://www.business.dk/detailhandel/it-­‐problemer-­‐saenker-­‐netto-­‐i-­‐sverige [Accessed 14 April 2015]. Berlingske Business, 2015. Dansk Supermarked fyrer 150 i Århus og Køge. [Online] Available at: http://www.business.dk/detailhandel/dansk-­‐supermarked-­‐fyrer-­‐150-­‐i-­‐aarhus-­‐og-­‐koege [Accessed 2 April 2015]. Carter, J., 2015. VersionOne -­‐ Agile made easier. [Online] Available at: http://www.versionone.com/White_Papers/Agile_Tester/ [Accessed 21 April 2015]. Chow, T. & Cao, D.-­‐B., 2007. A survey study of critical succes factors in agile software projects. The Journal of Systems and Software, pp.961-­‐71. Dansk Supermarked, 2011. Årsrapport for 2010. [Online] Available at: http://dansksupermarked.dk/wp-­‐content/uploads/2013/01/Årsrapport-­‐2010.pdf [Accessed 14 April 2015]. Dansk Supermarked, 2014 A. Fire formater -­‐ Én proces. NEWS, p.4. Dansk Supermarked, 2014 B. SAP er nødvendig for at vinde fremtiden. NEWS, p.2. Dansk Supermarked, 2015 A. Forside. [Online] Available at: http://dansksupermarked.dk [Accessed April 2015]. Dansk Supermarked, 2015 B. Vi er Danmarks største detailvirksomhed. [Online] Available at: http://dansksupermarked.dk/om-­‐os/ [Accessed 30 Marts 2015]. Deloitte, 2013. Deloitte. [Online] Available at: http://www2.deloitte.com/content/dam/Deloitte/dk/Documents/audit/Viden-­‐til-­‐Tiden-­‐
Nyt-­‐it-­‐system.pdf [Accessed 20 April 2015]. Fine, D.L. & Read, W.L., 2000. Blueprint for document control. ProQuest, Marts. pp.65-­‐69. Frederiksen, M., 2015. Tragt model. Tragt model af egen tilvirkning efter teori af Martin Frederiksen, Klean. Gloster, 2015 A. Forside. [Online] Available at: http://www.gloster.com/gle/ [Accessed April 2015]. Gloster, 2015 B. About us. [Online] Available at: http://www.gloster.com/gle/about-­‐us [Accessed 2 April 2015]. Side 63 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Hijazi, H., Khdour, T. & Alarabeyyat, A., 2012. A review of risk management in different software development methodologies. International Journal of Computer Applications, Maj. pp.8-­‐12. Jensen, A., 2014. Sap er nødvendigt for at vinde fremtiden. Koncernblad for medarbejdere, Marts. p.2. KPS Consulting, 2015 A. Forside. [Online] Available at: http://www.kps-­‐consulting.com [Accessed April 2015]. KPS Consulting, 2015 B. Succes Story Dansk Supermarked. [Online] Available at: http://www.kps-­‐consulting.com/downloads/success_story_dansk_supermarked_en.pdf [Accessed 2 April 2015]. Loiborg, C., 2011. Hvert sjette IT projekt ender katastrofalt. [Online] (1) Available at: http://www.version2.dk/artikel/hvert-­‐sjette-­‐it-­‐projekt-­‐ender-­‐katastrofalt-­‐30356 [Accessed 24 February 2015]. Nah, F.F.-­‐H. & Delgado, S., 2006. Critical succes factors for interprise resource planning implementation and ugrade. pp.99-­‐113. Sun, Z., 2013. User Involvement in System Development Process. Proceedings of the 2nd International Conference on Computer Science and Electronics Engineering. The Agile Alliance, 2001 A. About the Manifesto. [Online] Available at: http://agilemanifesto.org [Accessed 1 April 2015]. The Agile Alliance, 2001 B. Principles behind the Agile Manifesto. [Online] Available at: http://agilemanifesto.org/principles.html [Accessed 3 April 2015]. von Wangenheim, C.G., Savi, R. & Borgatto, A.F., 2013. SCRUMIA-­‐An educational game for teaching SCRUM in computing courses. The Journal of Systems and Software, pp.2675-­‐87. Side 64 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 12 Bilag 12.1 Bilag 1 – Interviewguide Indledende •
•
Vi præsentere os selv, bacheloropgavens hovedemne samt vores forventede udbytte af opgaven. Vi beder interviewpersonen om at præsentere sig selv og sin nuværende arbejdsmæssige position. 1. Hvilken officiel rolle har du haft i forbindelse med projektet? a. Har din officielle rolle skiftet igennem forløbet? 2. Fortæl lidt om de arbejdsopgaver du har varetaget i forbindelse med projektet? a. Har du påtaget dig opgaver ud over dit ansvarsområde? b. Hvis ja -­‐ Var det pålagt dig eller var det frivilligt? Egentligt interview Hvordan er der anvendt Forretningsplan/vision igennem projektet 1. Hvordan kom i frem til at der var brug for et nyt system? 2. Hvad var jeres Vision med projektet (samme fra start til slut)? 3. Hvordan var opbakningen i organisationen da visionen blev bragt på banen og hvad var konsekvenserne heraf? 4. Fortæl os om hvordan du oplever det at arbejde ud fra en fastlagt forretningsplan? Hvordan er der arbejdet med kravspecifikationen 1. Hvordan var processen med udarbejdelse af krav? a. Hvem har stået for udvikling af kravene? 2. Hvordan er kravene blevet kommunikeret til leverandøren? 3. Har der været problemer, som udspringer af kravene? a. Har kravene bundet jer fast til en bestemt løsning? 4. Har kravene været fyldestgørende? 5. Har kravene skiftet undervejs? Hvordan er milepæle og mål defineret 1. Hvordan er milepælene opstillet til dette projekt? (eventuelle dokumenter modtages gerne) 2. Hvilke konsekvenser har det haft at milepælene har været placeret som de har? 3. Hvem har sat milepælene? Opfølgning af milepæle og mål 1. Har der været enighed om hvorvidt milepæle er opnået eller ej? a. Hvis nej, hvad bunder uenigheden i? (manglende forventningsafstemning/uenighed om krav) 2. Har der været nogle konkrete faldgruber eller områder hvor der har været signifikante forsinkelser, hvilke? Side 65 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn Test af systemet 1. Hvordan har i håndteret test af systemet? a. Hvem har udviklet tests? b. Hvem har gennemført tests? c. Hvilke konsekvenser har det haft? 2. I hvilke stadier af projektet er systemet blevet testet? a. Har det givet anledning til problemer? Levering af systemet 1. Hvordan er systemet blevet implementeret ? a. I hele eller dele af organisation? b. Implementering af hele eller dele af systemet? 2. Fordele og ulemper oplevet ved denne form for implementering? Omstrukturering af forretningsprocesser 1. Er der i forbindelse med IT projektet blevet arbejdet med omstrukturering af forretningsprocessor? 2. Hvad er baggrunden for at i har valgt at ændre i forretningsprocesserne i stedet for i systemet? Uddannelse og træning 1. Hvordan er der i projektet blevet arbejdet med uddannelse og træning af brugerne? 2. Hvordan er denne træning fundet sted og struktureret? (super bruger f.eks.)? Brugerinddragelse og feedback 1. Hvordan er der i projektet blevet inddraget brugere? 2. Hvordan er feedback fra brugerne blevet håndteret? 3. Hvor mange brugere har i inddraget i projektet? 4. Hvilke funktioner har de brugere i organisationen? 5. På hvilket grundlag er disse brugere blevet valgt? 6. I hvilke faser i projektet er brugerne blevet inddraget? Projektets management og organisering 1. Er der bevidst blevet anvendt en bestemt projektmodel (PRINCE2 mv.)? 2. Er i bevidste om brugen af projektudviklingsmodeller (Vandfald, Spiral, SCRUM mv. ?)? Hvordan arbejdes der med risikostyring? 1. Hvilken måde er der arbejdet med risici på? 2. Har du oplevet problemer med den form for risikostyring? 3. Synes du at måden hvorpå projektet er udført har gjort det nemt at risikostyre og hvorfor? Intern kommunikation Side 66 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 1. Bliver der gjort noget for at fremme kommunikationen internt i projektgruppen? 2. Hvordan er anvendelsen af f.eks. informationsmøder og briefingsmøder. Organiseringen 1. Hvor mange personer har arbejdet på projektet? 2. Hvordan er projektgruppen udvalgt? (motivation, ekspertise og kompetencer) 3. Hvordan er arbejdsmiljøet i projektgruppe? (hierarkisk eller flad og samarbejdende) 4. Hvordan er den fysiske placering af projektgruppen og vigtige interessenter? Mulighed for interviewperson til at fremhæve andet 1. Er du kommet i tanke om yderligere til nogle af spørgsmålene? 2. Er der andet, som du tror ville være relevant for os at få med? Ekstra 1. Fortæl 3 gode historier fra der her projekt 2. Fortæl 3 dårlige historier fra det her projekt -­‐ Tak for interviewet! Side 67 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 12.2 Bilag 2 – Interview med Lars Mosbek Bilag 2 – Interview med Lars Mosbek fra Dansk Supermarked om Apollo projektet 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 Q: Hvad er din baggrund for at være med i projektet og hvad har din rolle været i projektet? A: Jeg er udannet datamatiker startede i Dansk Supermarkeds IT afdeling i 1998 som systemudvikler. Jeg bevægede med ret hurtigt over i at arbejde med metodearbejde og projektledelse. Siden 2000 har jeg været med til at sætte mit præg på hvordan vi arbejder med projekter her i Dansk supermarked, først på metodesiden og derefter som projektleder på rigtig mange forskellige typer projekter. I min periode har vi været flere forskellige tidsaldre igennem. Slut 90’erne og frem til 2006 var vi store og tunge på store mainframe projekter, meget avanceret mainframe projekter, vi kunne virkelig noget forretningslogik som ingen andre i markedet kunne og var langt foran på de teknologier som eksisterede der. Vi blev ekstremt modne i forhold til en helt klassisk vandfaldsmodel, analyse, design osv. og rigtig gode til at estimere og var meget præcise i de her leverancer. Vi fik bygget kodestandarder, designstandarder, kort sagt, standarder i alle retninger omkring de ting. Vi tager så en beslutning omkring 2005, om at vi ikke vi lave egen udvikling vi vil over på standardsystemer. I den forbindelse også en total ny tidsalder, vi outsourcer vores udviklingsafdeling, hovedsageligt til IBM som også tager sig af driften af vores gamle platforme. Derefter begynder vi at bygge et program op omkring organisationen for at kunne implementere SAP, igennem alle processer og alle områder i firmaet. Derved har jeg været med fra den første dag til den sidste dag, jeg tror faktisk jeg er en af de eneste har været med fra start til slut i hele den livscyklus. Selvfølgelig har jeg ikke været med i alle projekter, men mange! Jeg var med i det første projekt som var et finans implementerings projekt hvor jeg først havde en teamleader rolle og senere påtog jeg mig en projektleder rolle i det projekt. Jeg startede vores HR projekt op og så blev det overdraget til en anden projektleder. Der hvor det bliver interessant og som vi skal snakke om i dag er der hvor vi for alvor gik ind i retail siden og det gjorde vi primo 2010, og kørte et projekt derfra til september 2014. Under en program paraply med rigtig meget projekt samarbejde i organisationen sammen med den her tidsplan der bare fortsatte igennem en lang række faser igennem de her 4,5 år. Det var et lang projekt vi kørte der. Det projekt var så stort at der var et projektlederteam i den del, en 8-­‐10 projektledere, lidt forskelligt over tid på grund af størrelsen af projektet. Jeg startede med at være projektleder for et delprojekt/område der indeholdt alt vores custom development, altså alt rigtig udvikling der blev lavet omkring retail. 1,5-­‐2 år inde i projektet overtager jeg så den overordnede projektledelse af projektet og drev så projektleder teamet der så hver især havde forskellige hovedområder under projektet. Q: Så i har sat det op lidt hierarkisk op med dig øverst og så ligger der nogen under som styre hver deres område? A: altså man kan sige at vi snakker om et projekt med i snit 150 fuldtidsbeskæftigede personer der arbejde i den periode. Vi har været organiseret i fire hovedben, som egentlig alle sammen var lige vægtige. De var ikke alle sammen lige store, men alle sammen ligevægtige. Den største af dem var det vi kaldte vores proces område. Det var der man definerede Side 68 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 forretningsprocesserne, ved at snakke med brugerne rundt omkring i organisationen, man customerserede det. Vi snakker et standardsystem, så man sidder ikke og koder en masse, men man customersere indenfor standardsystemet, man testede det og rullede det ud i forretningen, inklusiv træning osv. der. Så det var der man reelt set skabte scopet og afleverede det forretningsmæssige scope. Så var der det andet ben som gik meget ud på det mere kerne udvikling og kode specialløsninger, dette kan man ikke undgå selvom man kører standardsystemer. Det tredje ben var omkring den tekniske infrastruktur, server, netværk osv. det er jo kæmpe systemer der ligger under de ting her, så de sørgede for at alle disse ting var etableret og kommer i rette tid i forhold til udviklingssystemer, testsystemer og produktionssystemer. Det fjerde ben var alt omkring organisational change management. Det omhandlede alt omkring opbygning af forretningen, få forretningen til at være klar til alt det her, som er et langt træk om at finde ud af hvordan forretningen ser ud efter vi kommer med alle de her nye processer. Vi påvirkede forretningen i høj grad omkring samarbejdsformen og hvem samarbejder lige omkring hvad. Så det er ikke kun et nyt IT system, men også nye forretningsprocesser. Så det er OCM ben, var egentlig snitfladen mellem kerneprojektet og så en projektgruppen ude i forretning med definerede roller fra direktør niveau ned til superbrugere, så man vidste hvem der var ansvarlig for hvad, hvem er ansvarlig for information og træning f.eks. Vi har kørt et trainer-­‐trainer koncept hvor man træner nogen og så træner de videre ud i organisationen. Også sign-­‐off stod de for, som er at sørge for afdelinger var klar til at bære og bruge systemet. Det var ligesom de fire hovedben der var i projektet, og hvert ben havde 1-­‐2 projektledere alt efter størrelse og også lidt efter hvor henne i projektet vi var. Så havde jeg sammen men KPS som er et tysk konsulenthus som er vores partner i der her projekt, den overordnede ledelse af det leverancemæssigt. Så havde vi Thomas Greve som havde have det overordnede ansvar for at den forretningsløsning vi kom ud med var den rette for Dansk supermarked både på kort og på langt sigt. Ikke den perfekte, det var ikke det vi gik efter, men den rette i forhold de omstændigheder vi havde der. Så han stod groft sagt på mål for scoped af projektet og jeg sørgede groft sagt for leverancerne af systemet. Q: hvor mange projektledere var det du sagde i havde fordelt på de fire siloer? A: Det svingede lidt, men mellem 8 og 10, f.eks. sad der omkring 100 mennesker i den silo vi kaldte proces. Der var så to projektledere, en fra KPS og en fra os selv som drev dette spor. Under det har det været organiseret i teams med hver deres teamleader. Der har måske været 10 teams under proces sporet. Ikke fordi vi har arbejdet med prince2, men det var meget i tråd med den tankegang at hver projektleder havde nogen teams han kunne styre igennem nogen teamladers, hvor teamleaderne havde detail indsigt i hver deres scope område. Min rolle i firmaet nu, har været siden august 1998 har jeg været afdelingslader i ITS, og i min afdeling af jeg ansvaret for projektledelse, release management og test management. Så vores kernestab af projektledere dem har jeg ansvaret for og også rent procesmæssigt hvordan vi arbejder med projektledelse og omkring de ting der. Q: Lige for at slå fast så står ITS for? A: Det står for Information Technologi and Services og er vores kerne IT afdeling. Side 69 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 Q: Kan du sige et par korte sætninger omkring forretningsplanen og visionen bag det her projekt? A: Jeg kan gøre det meget kort, for da den her princip beslutning blev taget i 2005 om at vi ville over på standardsystemer, der blev der lavet et program. Det program havde også en vision, tidsplan og økonomi bag der. Meget meget kort så er visionen at vi skal over på standardsystemer, vi skal harmonere processerne i dansk supermarked, dvs. Hvor vi tidligere havde forskellige forretningsenheder som lavede forskellige ting for det samme. Bilka på en måde, Netto på en anden måde og Føtex på en tredje. Så vi ville over på standardsystemer, forstået på den måde at vi ville udelukkende have standard. Mange køber standardsystemer og smadre dem bagefter ved at tvinge egne processer ned i standardsystemet, så du reelt set har købt en masse kode du kan rette i. Så vi har virkelig bekendt os til standardsystemet og vil harmonisere forretningsprocesserne i Dansk Supermarked. Så når vi nu bestiller fjerkræ uanset om det er i Netto, Salling eller en Føtex så bestiller man fjerkræ på den samme måde. Selvfølgelig er der specialbehov. I Bilka hvor vi har et udleveringslager, det har vi ikke i Netto og det får vi aldrig i Netto. Men hvis Netto nu skulle have en udleveringslager en gang så ville vi bruger Bilkas proces for udleveringslager. Der er også nogen lokale ting i forhold lager, vi har f.eks. nogen lagre med kraner og robotter der kører rundt omkring, det kræver nogen specielt i forhold til et lager der har kraner og robotter i forhold til et lager der ikke har. Så der er selvfølgelig nogen lokale forhold man skal tilgodese, også når vi kigger på lande. Forskelligt fra land til land kan være juridiske forhold, HR forhold osv. så vi har virkelig haft fokus på standard og stick to standard for at harmonisere processerne og arbejde ensartet. Dengang vi startede sagde vi at vi skulle være færdige i slut 2013, det var så baseret på den gang i 2005 på program niveau. For også at sige at vi vidste godt det var en lang rejse. Så har vi fokuseret rigtig meget på scopesiden også, for det har kan tage en evighed at gøre hvis man begynder at gå i detaljer om det. Så vi satte en forventning mellem os og forretning om at vi leverede en 80% løsning og hvad er en 80% løsning når man ikke kender en 100% løsning? Det kan man ikke bevise her men det var den har anerkendelse af, at det har kan vi ikke gøre perfekt. Det betyder at vi ikke lavede en rapport med massevis af businesscases, dem lod vi ligge for ellers ville vi miste momentum. Vi havde fokus på fart i forhold til at komme igennem og får skabt et fondament for at alle arbejde ensartet, som vi så kunne bygge videre på bagefter. Det var vigtigere end at lave diverse procesforbedringer i mindre grad, hvilket betyder at det har gjort ondt ude i forretningen fordi de sidste 20% måske har været en masse manual workarounds hvor man ikke kunne se at de kunne systemet egentlig gøre for mig. Ja det kunne det måske, men det ville tage tid at lave og i stedet har tiden været bedre investeret i at få systemet rullet ud igennem hele firmaet så vi har en platform og arbejde med. Især da vi fik vores nye direktør Per Bang for nogen år siden, blev der lagt rigtig meget tryk på hastighed i stedet for man når de 100% i system korrekthed. Simpelthen fordi han ikke kunne løfte organisationen fordi han ikke have nogen platform af processerne han kunne arbejde på. Vi har så mange centrale funktioner, og når de arbejde helt i en verden og halt i en anden så er det umuligt at automatisere og effektivisere de her processer eller arbejde med tingene. Så det var rigtig rigtig vigtigt vi kom over på den anden side hurtigt. På den anden side af det her projekt er de Side 70 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 projekter vi har gang i nu så ved at høste de gevinster, vi er nu i gang med at levere fra de 80% op til de 100%. Så de er begyndt at tage de benefits man har kunne se længe, at man ville kunne komme til. Det kræver igen fokus, ekskursion, test og go-­‐live for hver eneste af dem, så selvom benefits’ene er der, så er de jo ikke gratis. Så det har været selve visionen, og det projekt som vi skal snakke om i dag, er det vi har kaldt Apollo, som er sidste halvdel af hele SAP projektet som er der hvor vi har rykket os absolut mest og den del der har været aller vigtigst, da projektet derved har spredt sig til den brede retail verden hvor vi absolut ikke måtte komme ud i blindgyder. Q: så i kom frem til at i skulle have et nyt system på baggrund af at i gerne ville harmonisere og standardisere organisationen og arbejdsprocesserne? A: ja, for at harmonisere og få skabt en ERP platform hvor alle processer hænger sammen på godt og ondt. Altså hvor det har konsekvenser hvis f.eks. masterdata laver en fejl jamen så forplanter det sig ned på lageret. Men har kan vi virkelig høste benefits i sidste ende og løfte organisationen for at gøre den mere effektiv. Q: 15:20 Har folkene ude på gulvet været presset af denne vision? A: Ja! Men det har vi skam også været fra et IT leverance synspunkt. Men det har de helt sikkert været, for mange steder når vi gik live, så er vi kommet med noget der egentlig var dårligere end det de kom fra. Folk tænkte, nu kommer de med det her kæmpe IT system som de har brugt så mange år og penge på, hvad sker der lige? Men her har hele det her OCM ben også været rigtig vigtigt! De har sørget for at forståelsen bliver fortalt, hvor er det lige værdien er henne, for det kan godt være den ikke lige er dig, men så er den alle de andre steder rundt omkring. Du ser det ikke, men du gør en indsats her, og så kan de andre høste din indsats enden på kort eller på lang sigt. Så hele den her organisational change management del har været meget meget vigtig. Q: lige for at ridse det op, hvilken navne går de 4 ben under som du omtalte tidligere? A: Det første var vores process område, det vil sige der hvor vi definerede forretningsprocesserne, customizerede dem, testede dem inden vi rullede dem ud. Så havde vi den vi kaldte development. Det var den lidt mere hardcore development hvor vi byggede decideret kode, interfaces til tredjepartssystemer og sådan nogen ting. Q: Så det var der i bevægede jer lidt væk fra standardsystemet af nød? A: Man kan sige at i sådan en verden her er det også lavet sådan at man skal kode ting selv, men man kan gøre det så det overholder standard guidelines, eller man kan gøre det sådan at det bryder alle guidelines. Så det er meget et spørgsmål om hvordan man gør de ting, man kan ikke helt undgå at gøre tingene selv, men det er meget vigtigt at man virkelig tænker sig om hvad man gør og hvordan man implementere disse ting rent kodemæssigt. Så er der f.eks. interfaces, vi lever i en ekstremt integreret verden, hvor vi bliver nødt til at have interfaces til eksterne leverandører, med alle mulige former for informationer. Der er forskellige systemer som HR systemer som kører på andre teknologier og hvor vi bliver nødt til at integrere tingene sammen. Man bliver nødt til at lave meget af sådan nogen ting, men man kan godt gøre det så det holder sig inden for standarder. Det tredje ben var vores tekniske infrastruktur. Det omhandlede servere, netværk, devices, PDA’er og alt muligt andet. Det Side 71 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 sidste var så det vi kaldte OCM som omhandlede organisational change management. Hvis man kigger på de mennesker der har siddet i projektet så har der siddet 100 i proces, 25 i development, og 10 i hver af de to andre. Grunden til at de to sidste ikke er så store, er at der ligger en stor organisation bag ved dem. Ved teknisk infrastruktur f.eks. er det IBM der levere de fleste ting for os, så de folk der har siddet her har reelt set været dem der har styret leverance apparatet. OCM siden har været snitfladen mellem os og så forretningsorganisationen, derude har der så været udnævnt 150 personer som har haft specifikke roller forskellige steder i organisationen, som har drevet hele den del. De har ikke været en del af selve projektteamet, men de har haft en meget meget vigtig og veldefineret roller og ansvar. Det har været meget dynamiske over tid, vi har haft over 600 mennesker igennem kerneteamet på fire år, som har siddet i en bygning her som vi har haft for os selv og hvor vi havde projekt hovedkontor. Q: Hvis vi bevæger sig over i kravsspecifikationen, Så tænker vi der formentlig har været en hel mappe med krav til systemet? A: Nej, ingenting. Vi har arbejde med krav selvfølgelig. Men en af vores læringer i starten af programmet var da vi startede ud med de aller første SAP programmer startede vi ud rigtig vandfaldsmæssigt. SAP har en metode der hedder ASAP og det er en klassisk vandfaldsmetode, hvor man laver et stort blueprint først. Så det startede vi med at gøre på de første SAP projekter, vi lavede et kæmpe blueprint, det var rigtig fint hvor alt var skrevet i Word. Efterfølgende hvor man så kunne relatere det fandt man alle problemerne med tingene der, for det er jo altså lidt nemmere at lave tingene i Word og PowerPoint end det er at lave i virkeligheden. Efter et par projekter hvor vi havde kørt den stil og mærkede at det var spild af kalendertid at lave blueprint og faktisk rigtig svært at bruge det effektivt bagefter, så lavede vi et fuldstændig skifte da vi kom til apolloprojektet. Det partner firma vi har i Tyskland KPS, har ikke kørt noget i samme liga som det her, men har kørt en række SAP retail projekter ud, mest i tekstil branchen f.eks. Hugo Boss. Men der var et fuldstændig skifte i hvordan man griber det her an, man skriver simpelthen ingenting, man går bare i gang. Så det var prototyping fra day one. De har deres egen proces som hedder Rapid transformation. Som de kom med og sagde, det er den har måde vi griber det an på. Jeg vil dog ikke kalde den en decideret metode, men mere at konceptgrundlag som er baseret på stor fokus på end-­‐to-­‐end processer hele tiden. End-­‐to-­‐end processer på tværs af organisationen og processer så man aldrig får skabt et silo view men et bredt view. Customisere prototyper omgående med det samme, fra dag et sidder man og customizere prototyper i løsningen og viste dem til forretningen, i noget man kalder structured walkthrough, hvor man simpelthen gennemgår prototypen for forretningen får at få feedback. Bagefter går man så mere i detaljer med prototyperne hvor man kører noget der hedder show list views hvor man går mere i detaljer for at få noget buyin fra forretningen der. Derefter tester man og så ruller man løsningen ud. Så det omhandler meget iterationer, men ingen skriveri forstået som dokumentationer. Så det der skete da vi startede primo 2012 med dem, de kom ind med en række konsulenter under kick-­‐off og så satte vi os et mål, jeg tror det var inden for 6 uger at vi skulle være klar med en live demo. Den skulle præsenteres i storcenter nord’s teatersal for hele Dansk Supermarkeds ledelse. Der skulle man gennemgå de Side 72 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 første 6-­‐8 end to end processer som en live demo på storskærm. Den ene storskærm viste systemet og den anden en procesguide omkring roller og hvem der gjorde hvad. Så man gik benhårdt ind i at customisere, det var ikke nogen perfekt prototype, der var f.eks. mange steder man ikke måtte trykke, så ville det gå galt. Men det var for at skabe en forståelse og en look-­‐and-­‐feel fornnemlse for hvordan den enkelte proces ville komme til at fungere. Vi kørte tre af sådan nogen structured walkthroughs med cirka halvanden måned imellem, hvor vi så fik signoff på dem fra ledelsen. De kunne derved se at det var lige præcis sådan her systemet bliver vi laver, og det var det de ville få om et år når det var færdigt. Ledelsen kunne derved også tale højt hvis der var nogen indsigelser imod prototypen. Vi gjorde det dermed for at få buy in, buy in, buy in hele tiden fra forretningen og fokusere på de her end-­‐to-­‐end processer. Hvordan masterdata blev oprettet, hvordan indkøb oprettede en ordre, hvordan tingene bliver sendt fra leverandøren og hvordan varen lander på lageret, hvordan lageret sender til butik, hvordan butikken modtager og sætter varen på hylden og til sidst sælger den. Så vi tænkte hele tiden bredt, og dermed også den måde vi arbejdede med kravsspecifikation. Så vi kiggede på de processer vi havde, og hvad standardløsningen så kunne i forhold til dem. Så altså ikke hvad vi udelukkende ønskede. Selvfølgelig har vi lavet dokumentation af tingene, men det har mest været for vores egen skyld for at kunne vedligeholde løsningen efterfølgende, så det har ikke været decideret kravsdokumentation som så skulle sendes rundt i organisationen og få dem til at læse og skrive. Så det har været mere løsningsdokumentation vi har arbejdet omkring. Q: har der så været nogen problemer med den måde i har valgt at gøre det på? A: Selvfølgelig har der været nogen problemer når man kom virkelig ned til detaljegraden, så har der været en høj grad af forventningsafstemning, hvad var lig med og hvad var ikke lig med. Men vi har egentlig fået uddelegeret et rigtig pænt ansvar over i vores organisation på at vores folk bestemte hvordan vi gjorde det, så vi skulle ikke hele tiden spørge forretningen om lov. Vi har taget rigtig mange forretningsprocesbeslutninger i projektet selv. Vi har også haft mange forretningsfolk i projektet som er blevet absorberet ind fordi de havde forretningsviden og en forretningsbaggrund. Så ja, der har været nogen problemer her, men jeg vil ikke sige de sådan har været gigantiske. Vi har f.eks. haft problemer med vore instor foodproduction, altså vores produktionsside i forhold til ude i butikkerne. Her har der været diskussioner omkring mange praktiske ting. Nogen steder bliver der meget praktik på gulvet i hverdagen. Så der har været noget ja, men ikke på det store plan. Men på det store sigte var det helt sikkert det rigtige at vi droppede kravsspecifikationerne og gik over i prototyping, ellers var vi aldrig kommet ud af Word, så havde vi stadig siddet og skrevet i Word i dag. Q: For at slå det fast så var Apollo de sidste 20% i ligger ovenpå af de 80% løsninger i leverede? A: nej, det er hele retail udrulningen. Vi satte os det mål i primo 2010, om at lave et system der kunne køre et helt land fra end-­‐to-­‐end, alle processer i et helt land uanset om vi snakker alle masterdata processer, indkøbsprocesser, butiksprocesser, finansprocesser og lagerprocesser. Det gav vi os 2010 til at bygge op. Dette skulle vi bruge som en skabelon til de andre lande, vi aftale så er Sverige var det første land vi skulle rulle ud i. Der skulle vi starte udrulning primo Side 73 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 2011, så vi havde 2010 til at bygge løsningen, teste løsningen, hvordan vi ville lave en Go-­‐live, hvordan vi ville migrere data fra gamle systemer. Der startede Apollo, og så for hvert år der gik der udvidede vi løsningen med nye funktionaliteten og udrullede til at nyt land. Først Sverige, så polen, Tyskland og til sidst Danmark. På grund af Danmarks kompleksitet, var der rigtig mange steps vi skulle igennem der, var vi først færdige i september 2014. Det tog et år fra start til slut i Danmark. Parallelt med det har vi hele tiden bygget nye løsninger, men bygget på den initiale template som vi lavede fra starten af. Den template var stadig kernen, men blev bare udvidet stille og roligt til at kunne dække mere og mere funktionalitet. Enden fordi der har været behov for mere komplicerede processer eller fordi der har været lokale krav. F.eks. er de i Polen helt sindssyge omkring opfølgningen af moms. Sådan rent udrulningsmæssigt har det været en rigtig stor opgave at styre udrulninger, det er ikke noget man bare gør. Så vi brugte også rigtig meget tid på at diskutere hvordan man reelt set kan gå i gang. Bigbang hvor alt starter fra første sekund kunne ikke lade sig gøre. Butik by butik kunne selvfølgelig have været rart at gøre, men i forhold til alle de bagvedliggende systemer som f.eks. ville det nærmest også være umuligt. Så vi havde rigtig mange diskussioner omkring konceptet til udrulning. Vi landede på en, den var vi tro med hele vejen igennem, at vi skulle rulle ud på varekategorier. Dvs. Vi laver reelt set big bang men kun inden for en varekategori. F.eks. alt frost, uanset hvilke processer og hvor henne man er i landet kørte man SAP fra et bestemt sekund hvor man aktivere det. Det koncept har vi brugt i alle lande for at kunne starte op i etaper. Så vi startede det vi kalder en coeksistens periode hvor alle arbejde med dobbelteprocesser, og det er pisse irriterende for alle! For det er ekstremt svært at huske nu skal jeg bruge SAP og nu skal jeg bruge noget andet. Men det har været nødvendig for at få sikkerhed ind, dvs. Man har kunne afprøve en lille og ikke så risikofyldt varekategori først og sikre sig at både forretningsprocesser og it processer de spiller og så kunne man efterfølgende skalere op. Så udrulningssiden omkring Sverige blev gjort over 4 go lives, hvor blikket så har været rettet meget imod dem og vi har siddet derover onside og hjulpet dem. Q: har der været nogen konsekvenser ved den måde i har valgt at gøre det på i forhold til kravspecifikationen? A: konsekvenserne på den negative side har været at der ikke har været afstemningen om detailkrav mellem forretningen og os. I forhold til vores konsulenthus har der ikke rigtig været nogen konskvenser der, fordi vi har været meget bevidste om at den samarbejdsform vi går efter har været partnerskab. Så alt har været baseret på kontrakter hvor vi har betalt dem på dagsbasis. Så de har ikke haft brug for detailkrav for at arbejde med os, hvis de skulle have lavet en fastpriskontrakt med os, hvordan skulle de så vide hvad de skulle prissætte hvis vi ikke gav dem nogen detailkrav. Her har vi været meget bevidste om hele vejen rundt, både ved KPS som har været vores hovedleverandør, men også alle de andre eksterne vi har haft rundt om os, at vi betaler på timebasis. Det har vi jo været nødt til fordi vi ikke har kunne stille kravene og derfor kan de heller ikke lave nogen fastprisaftaler. Der har vi jo så påtaget os en økonomisk risiko, fordi vi ved ikke hvad det ender med, så det har krævet en god styring fra vores side. Som med alle projektmodeller med en projekt trekant med tid, økonomi og scope, der kan du ikke få alle tre. Der valgte vi at tiden var den vigtigste for os, økonomien var også Side 74 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 forholdsvis vigtig vi snakker om en projekt på den anden side af en milliard kroner. Så vi havde scoped vi valgte at file på. Så som udgangspunkt hvis vi mødte problemer så var vores prioritet at gå i luften på den bestemte dato uanset hvad. Så måtte vi gå i luften med hvad vi havde, vi flyttede ikke datoen og det overvejede vi heller ikke. Det mindsæt i forhold til kravspecifikation har betydet at vi kun har haft en ting at file på, scope. Selvfølgelig har vi kunne hyre eksterne konsulenter ind, men det er ikke altid mennesker der har indflydelsen på scope. Så det mindsættet med at vi går i luften no matter what, har gjort at vi var nødt til at file på scopet og dermed også på kravs siden. Det har selvfølgelig været en balancegang i hvor meget vi kunne tåle at file på det, altså i forhold til det med 80% kunne vi så tåle at gå ned på 60% på nogen områder og så stadig overleve en Go-­‐live eller vælter vi bare første dag. Og det har klart været en af konsekvenserne at vores måde at arbejde med krav på. Q: så på den måde har i også været meget agile med jeres krav? A: ja meget! Q: Nu har vi snakket lidt om milepæle som for jer i forhold til udrulning var land til land og mere nedbrudt varekategori til varekategori. Men kan du fortælle lidt om konsekvenserne af at i har gjort det på den måde? A: men kan sige at den måde vi har valgt at gøre det på her, er gjort fordi vi i vores organisation ikke er andre muligheder. Så da vi først efter analyse, design og organisation og gennemtænkte alle de kompleksiteter der er med de gamle mainframe systemer der er som også skal hænge sammen med det nye system, så indså vi på et tidspunkt at der ikke var andre muligheder at gøre det her på. Jeg synes også at vores forløb viste at vi kunne styre det og vi fik den forventede glæde af at afprøve det på lille skala for så kunne gøre det større og større. Så det var helt sikkert det rigtige valg for os. Hvordan milepælene blev defineret, kan man sige at de blev drevet ud af forretningen her. De bagved liggende milepæle med udvikling og test har forretningen ikke været så interesseret i, de stolede egentlig bare på vi blev færdige til tiden. Men hvordan vi udrullede og dermed gik live, har der været ekstremt meget forretnings koordinering over. Når vi snakker et land som Danmark, hvor vi havde 6 eller 7 Go-­‐lives. Hver af de her Go-­‐lives påvirker selvfølgelig organisationen, og tingene var helt bundet ind i processer, nogen ting kunne skilles ad, andre kunne ikke. Vi har haft nogen kerneregler vi har sat op fra starten af, som vi også var tro mod hele tiden. F.eks. en vare, en ketchup som bliver solgt i mange butikker, lande og er i mange lagre kan kun være et sted, enden så er den i SAP eller også er den i de gamle system, så når den er gået i luften så er den gået i luften. Så den kan altså ikke splittes. Ligesom en ordre der er sendt til en leverandør, enden så er den det ene eller det andet sted, der kan ikke ligge en halv ordre begge steder. Så vi har haft et overordnet regelsæt, men samtidig har vi også sørget for at vores løsning kan holde til det. Det har så også haft den konsekvens at der var nogen ting vi bare ikke kunne skille ad, f.eks. textil området som er et enormt område, ville have været rart at dele i to, men det kunne vi bare ikke fordi det brød hele vores regelsæt. Det krydret med at forretningen har travlt på alle mulige tidspunkter, Jul, påske, sommer, forår osv.. Der er hele tiden gang i et eller andet i biksen. Det her samspil har krævet en masse ting koordinering med forretningen. Men der har været rigtig god dialog omkring det og rigtig god gensidig forståelse omkring at Side 75 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 vi skulle finde en fælles måde at gøre det på. Så når vi har landet de her planer, så har vi været meget tro mod dem. Q: Så der har været en respekt for at de har planer blev overholdt? A: Ja. En af de ting der virkelig hjalp os var at vi fik etableret en Businees process ownergruop. Som var det forretningsforum hvor folk de sidder på ledelsesniveau og egentlig skal være enige omkring hvordan tingene skal fungere for dansk supermarked. Projektet arbejder jo fra end-­‐to-­‐end på tværs af alle forretningsenheder, så vi fik skabt det forum hvor der sad en ansvarlig fra de forskellige afdelinger. Den gruppe var så vores sparingspartner uanset om vi snakkede krav eller scope på projektet. Det var også deres ansvar at kigge på det greater good for Dansk Supermarked, og ikke kun suboptimering af deres område. Nogen gange måtte den ansvarlige for en enhed tage nogen tæsk i sit eget område fordi vedkommende så kunne se det vil give noget værdi i et andet område. Så det var faktisk rigtig godt at få det etableret. Det har hele tiden været dem vi har refereret til, når der skulle tages en forretningsmæssig beslutning. Den her instans lever også videre herefter projektets afslutning. Q: har det været enighed på tværs af organisationen i forhold til opfyldelse af milepæle? Altså når i sagde i havde leveret det i skulle, så var dem i levered til også enige i at det i havde leveret var det de ville have? A: Ja sådan rimeligt vil jeg sige. Jeg vil ikke bruge ordet uenighed, da der har været en rigtig god ånd om at vi var fælles om det her. Det var VORES projekt. Så når der virkelig har været problemer, hvilket der f.eks. var i maj 2013 da vi gik i luften med vores freshfood område, der var der seriøse problemer. Det var en blanding af Go-­‐Live og forretningsmæssige beslutninger der blev taget på det tidspunkt. Der var alle enige om at vi skulle ud af det her sammen. Der blev f.eks. bygget et nyt lager op indenfor 24 timer og flyttet varer fra Århus til Vejle, det var en forretningsbeslutning der blev taget for at hjælpe os i IT afdelingen. Der var daglige møder på ledelsesniveau hvor man afstemte de problemer man havde og hvad man skulle gøre fra i dag til i morgen. Uanset om det var forretnings eller IT ting der skulle ske så var der åbenhed omkring problemer og de ting der skulle gøres. Så der kunne man sige at vi trak os sammen som fælles flok for at komme ud af problemerne, og folk var villige til at tage nogen tæsk. Så jeg synes ikke der har været end ånd af uenighed og der blev peget fingre. Men der har selvfølgelig været perioder hvor der har været udfordringer. Af de virkelig store problemer vi havde, så store de kom på forsiden af aviserne, var f.eks. vores Go-­‐Live i Sverige. Her var organisation simpelthen ikke klar til at tage imod systemet. Det var egentlig på den anden side også med til at tricke hele vores OCM område. Det var læringen herfra der fik os til at sige at vi skulle gøre meget mere ud af vores OCM område. Næste område vi gik ind i efter Sverige, det var Polen og det var det total modsatte, de tog total ansvar for alt.! Fra dag et af sagde de at de kørte processerne selv. Vi skulle bare støtte op omkring dem, men de drev forretningen. I Sverige sad vi og drev forretningen på mange områder og et langt stykke tid, fordi de simpelthen ikke var i stand til at gøre det selv. Så hele det her mentalitetsskifte fra det ene land til det andet var ekstrem vigtig for os, og det var selvfølgelig vores OCM ben der gjorde et stort stykke arbejde der. Så man kan sige vi hele tiden har suget til os med erfaringer og Side 76 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 løsninger til næste step. Så det var nok vores to største problemer, vores Go-­‐Live i Sverige og så vores Freshfood i Danmark. Q: Hvad var det for nogen problemer i løb ind i med freshfood Go-­‐Live? A: Det var en kombination af flere ting, der skete to ting på en gang, 1) vi flyttede et lager fra århus til Vejle lige før Go-­‐Live. Samtidig valgte vi at insource alt danishcrown produkter som før blevet leveret direkte til butikken, nu skulle det leveres direkte til lageret. Lagdriften var heller ikke stabil da vi kom med det nye system ned over lageret. Kapaciteten var for stor i forhold til hvad der rent fysisk kunne komme igennem lageret. Så når alle lastbilerne kom med alle deres paller, så blokerede man nærmest motorvejen fordi de ikke kunne nå at komme hurtigt nok af med deres paller. Så lagerdriften var presset til det yderste, uden at vi kom med et nyt system og så kom vi med et nyt system som kom med flere problemer. Der var sporingskrav, filer fra leverandørerne der kommer for sent og alle mulige andre ting der så giver flere forsinkelser til lagerdriften. Men der var ingen mulighed for at indhente det fordi døgnets 24 timer allerede var booket 110% op, og så blev det en ond spiral. Det bliver en ond spiral af backlog, du kan ikke bestille varer hurtigt nok, og dem du bestiller kan du ikke få produceret hurtigt nok, systemet regner forkert i forhold til ordremængder, pludselig er der tomme hylder i butikkerne. Så det gjorde rigtig ondt og var skyld i tomme hylder i butikkerne i en periode. Nogen ting var selvfølgelig systemfejl som man i en optimal verden kunne have fundet via tests og andre ting var nogen forretningsmæssige konsekvenser man ikke kunne overskue konsekvenserne på længere sigt. Men det vigtigste her var den fællesskabsfølelse vi have i projektorganisationen, det var det der fik os igennem og der blev virkelig knoklet igennem alle steder på tværs af organisationen. Q: Hvem har stået for test? A: Hvis man kigger på den 150 mand store projektorganisation har vi cirka været opdelt 50/50 med eksterne og interne IT folk. Den interne har været en relativ fast skare af personer der har arbejdet med det her projekt igennem flere år. Flere af de interne kommer rent faktisk fra forretningsenhederne, men er så egentlig blevet IT folk fordi de nu har arbejdet med det her i så lang tid. Så de har en baggrund hvor de kender mange af de her ting. Så som udgangspunkt så har projektet drevet testen selv, også fordi dem ude i forretningen simpelthen ikke har haft forudsætningerne til det da vi kom med nye systemer med nye processer. Det ville have krævet et kæmpe opløft af dem i forhold til uddannelse og sige at dem ude i forretningen skulle være tester. Så som en del af leverancen så er det de samme folk der har stillet krav, de samme der har diskuteret forretningen er også dem der har testet løsningen. Men nogen gange har vi trukket nogen forretningsfolk ind for at kunne køre nogen test på dem. Det har egentlig ikke været for testen skyld, for vi har ikke kunne stole på deres test, så det har mere været af OCM-­‐mæssig karakter og give brugerne hans on fornemmelse af det system der blev leveret i fremtiden. På den måde stod de bedre efterfølgende i forhold til træning og uddannelse af deres kolleger. Så det har været for at bygge dem op og ikke for at bevise at systemet der virker. Så er der i specialistområder, der har vi trukket decideret testere ind, eksempelvis i forhold til speciale lagerløsninger hvor vi har trukket folk ind direkte fra det lager for at teste. Men som grundkoncept er systemet blevet testet af Side 77 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 projektgruppen selv. Vi har prøvet at have en projektgruppe hvor alle var ligeværdige men med et foreskellig sæt skills. Så alle har budt ind med hvad de kan, så eksterne har også siddet og testet hvis det var et område de havde erfaring indenfor. Q: Hvad har det givet jer at gøre det på den måde? A: Jeg vil sige at det var sådan lidt de muliges gunst, der var ikke andre muligheder. Efterfølgende når vi er forbi alle de har udrulninger står vi i en helt andet situation, hvor vi har fået oprettet et bruger community som næste gang vi skal bruge testere har mulighed for at bruge dem i stedet. Men i det første projekt her kunne jeg ikke se vi havde andre muligheder. Vi kunne ikke have trukket professionelle testhuse ind, vi kunne ikke bruge vores user community fordi de ikke havde nogen anelse om hvordan de skulle gribe det an. Vi havde skulle bruge flere ressourcer på at lære dem op til at blive testere, end vi skulle på at teste selv. Ja nogen gange har det givet nogen problemer, man har overset nogen ting og måske haft nogen uforudsete forventninger til hvordan det ville virke i praksis. Men igen, det er scoped vi har filet på, så vi har også filet på testscoped, vi kunne alligevel ikke teste alt fra ende til anden. Vi blev nødt til at prioritere hvilke testcases der var de vigtigste og hvilke er mindre vigtige. De vigtigste tester vi så godt vi kan og så går vi i luften med hvad vi har når deadline kommer. Så måtte vi tage risikoen på de mindre vigtige processer og tage noget mere support på dem efterfølgende. Q: hvornår har i testet i forhold til Go-­‐Live? A: Vi snakker 4 forskellige testformer. Vi lavede en meget initial developer test, for udviklerne sad og testede de ting de var kommet frem til. Den test var total uformel og udokumenteret, vi havde ikke noget specielt testscope på den. Derefter har vi så haft det vi kalde unit test hvor man testede hver eneste enkelstående funktion i vores processer bliver testet en efter en i dybden og det kan være ting der er lavet af flere forskellige personer der så mødes i en proces. De har ligget hele tiden i kalenderen for gang der blev leveret en unit så blev den testet. Det var en ok styret test med testcases og opfølgning af fejl og prioritering af fejl. Inden vi har udgivet en release har vi så kørt en scenarietest som var en end-­‐to-­‐end test, hvor vi tager alle de har enkelte funktioner som vi har kørt unittest på, og sætter op som perler på en snor og tester end-­‐to-­‐end processer på tværs af systemer og forretningsområder. Her tester vi hvordan hverdagen vil så ud i forskellige scenarie. Så et team ville måske starte med at lave noget masterdata, så vil et andet team lave en ordre et tredje team ville lave en EDI, det fjerde team ville kører en lagerløsning og til sidst ville finance se om det så stemte i bøgerne som det skulle. Det har typisk været en 4 ugers periode inden vi satte systemet i produktion (go-­‐live) et par gange om året hvor vi lige bankede det hele igennem på tværs af alt. Det er sådan at når man snakker SAP, så snakker man ikke bare et system. Der er måske 6-­‐7 forskellige SAP systemer som hænger sammen til det der udgøre vores. Derudover et hav af andre eksterne og interne systemer. Så det er stadig et forholdsvis kompleks system selvom det er et standardsystem. Det gør det også komplekst når vi tester det. Men det har vi været ligeglade med da vores filosofi var at teste end-­‐to-­‐end processer. Men der er tusinde hvis af kombinationer vi kunne teste, så vi har højest sandsynlig testet for meget nogen steder og for lidt andre steder på grund af vores prioriteringer. Side 78 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 Q: så det har været en af konsekvenserne ved at i har gjort det på den måde i har, at i måske har testet lidt skævt nogen steder hvis man kan sige det sådan? A: Ja det kan man godt sige. Vi har dog kunne trykteste med forretningen om de var enige i det vi testede. På den måde var folk også klar over at i og med vi testede det her, så testede vi jo så ikke det her. Vi har jo aldrig haft en kravspecifikation, så ingen har vidst hvad en 100% test var, så vi har lavet en risikobaseret test, hvor vi har udeladt hvad vi ikke synes var vigtig. Det har selvfølgelig gjort ondt en gang imellem når vi gik live. Men vi har så brugt vores erfaring frem i forløbet til at undgå mange problemer. Så vi har sagt til at selv når vi gik live at den der fejl burde vi altså kunne finde til næste gang vi går live. Til gengæld har vi accepteret mange af de fejl der er fundet efter Go-­‐Live fordi det har været specialiteter. Det kan godt være det har gjort ondt på den specifikke berørte proces, men det har ikke haft nogen større betydning for det store perspektiv. Q: Så når i har testet har i egentlig gået efter de processer der har den største indflydelse på forretningen og så været lige glade med om det har været nemt eller svært at teste? A: ja helt bestemt. Det samme har så galt den fjerde testtype som er revisionstest. Når vi har kørt en scenarietest og kørt en release, så har vi her haft fokus på at teste det nye funktionalitet vi er kommet med. Revisionstestesn går ud på at teste at vi ikke har ødelagt noget af det eksisterende funktionalitet. Det jo fint nok hvis vi kommer med 10 nye processer, men det hjælper ikke hvis vi så smadre 15 andre som allerede bliver brugt ude i produktionen. Det gør jo faktisk endnu mere ondt hvis det er tilfældet. Så revissionstesten er rigtig vigtig i forhold til den her risikobaseret test. Jeg plejer egentlig at tegne testscope som et isbjerg. Hvis vi tager alle processer i en produktion og tegner op, Så vil nogen ligge i toppen af isbjerget og nogen vil ligge i bunden af isbjerget. Når vi laver revisionstest så kan vi ikke teste alt test nogensinde foretaget. Uanset om vi laver automatiseret tests eller manuel test. Så derfor er det ekstremt vigtigt at have fokus på hvilke processer der ville gøre mest ondt hvis de gik i stykker efter release. Derfor bør man teste oppefra og nedefter i forhold til isbjerget, indtil man ikke har ressourcer og tid til at teste mere. Fordi de her processer kører i produktion så kender du dem jo 100%, så er det et spørgsmål og de er forretningsmæssigt prioriteret korrekt. Man kommer aldrig længere ned af ”isbjerget” end til midten hvis man kommer så langt. Så er det et spørgsmål om der er nogen afledte effekt af det man har testet her som man ikke kunne gennemskue, hvis man kan gennemskue dem så tester man dem selvfølgelig. Andre gange kan det ligge så dybt nede i standardsystemet at man ikke har nogen anelse om at det kan have indflydelse andre steder i systemet. Sådan nogen ting ville du kun kunne fange hvis en sådan proces ligger i toppen af isbjerget. Vi har nogen automatiserede tests, for at kunne teste så meget som muligt, men det er stadig nødvendigt at teste efter en risikovurdering af processerne. Et konkret eksempel som vi nok aldrig nogensinde ville kunne finde i en test, det var da vi en gang tilføjede et felt i en formular der skulle printes, det var total logisk. Men det gjorde at vi ikke kunne varemodtage på lageret. Formularen havde ingenting at gøre med lageret! Det var en indkøbsformular som skulle kunne printes og vedhæftes som bilag. Det var så fordi at dybt dybt nede i kodebasen i standardsystemet, der var der et modul som blev genbrugt af noget helt andet ude til venstre. Sådan en ting ville vi Side 79 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 kun fange i en regressionstest hvis vi havde sagt at varemodtagelse er en proces som ligger i toppen af isbjerget. Så det var den fjerde testtype vi havde fokus på. Q: Hvordan var jeres realeses? A: cirka 2 value releases om året hvor vi udvidede den her template, med nye funktionaliteter og så de her efterfølgende user Go-­‐Lives hvor det så er taget i brug rundt omkring i organisationen. Q: Hvad har der været mest fokus på i forhold til forretningsprocesser, at få systemet til at passe til jeres processer eller få processerne til at passe til systemet? A: helt klart det sidste. Det ligger helt tilbage i visionen hvor vi besluttede os for at gå over på standardsystemer. Derfor var vi nødt til at være tro mod den investering i stedet for at gøre som f.eks. Arla har været ude i og få standardsystemet til at passe til forretningsprocesserne, så får dun kun omkostninger ved det standardsystem du investere i. Så hvis SAP F.eks. tænker langsigtet og laver en opdatering til systemet man har købt, så er du helt låst fordi standardsystemet er lavet så meget om at opdateringen ikke passer der på. Du får stadig lov til at betale alle licens pengene hver eneste år, men du får bare ikke glæde af dem på længere sigt. Så vi har kørt benhårdt på at det ikke er vores processer vi skal køre men standardprocesserne og hvordan kan vi bedst muligt arbejde med dem, og så har vi selvfølgelig kørt nogen justeringer da det ikke er en sort hvis verden vi lever i. Det er også derfor det her er noget helt andet end et klassisk kodeprojekt med en stor kravspecifikation, hvor man så aflevere det til en leverandør og så er det lige præcis det man får. Her er spørgsmålet om at sige hvordan får vi mest mulig glæde ud af det standardsystem vi investere i, i forhold til de processer vi har. Der er selvfølgelig muligheder for at costumisere og nogen gange finder man huller i standardsystemet. F.eks. har vi slåsset meget med consignment, som er leverandørernes eget lager hvor leverandøren stadig ejer deres varer ind til vi har solgt dem. Det synes vi ikke var gennemtænkt i den her standardløsning, men det er en vigtig proces for os, så derfor var vi nødt til at finde ud af et eller andet. Men hvis SAP havde en løsning til det så havde vi brugt den som udgangspunkt. Q: så i har forsøgt at holde det kompatibelt med fremtidige SAP systemer der kommer ud? A: Ja.! Det har vi også haft ekstremt meget glæde af nu et halvt år efter hvor vi er færdige med udrulningen. Vi har lige kørt en opdatering hvor vi har opgraderet SAP til den nyeste version, det gik rimelig smertefrit. Vi fandt ikke særlig mange problemer, hvis vi havde lavet en masse juleleje selv så havde sådan en opdatering bare vist en lang liste at ting der ikke virkede. Så derfor er vi helt i front i verden med de systemer som SAP udgiver til retail verdenen, vi er nogen af de 4-­‐5 første der har fået de her nye systemer. Vores arkitekter sidder nede i SAP’s hovedkontor er og med til at påvirke hvordan deres løsning skal bevæge sig fremadrettet. Så vi har rigtig meget glæde af at vi kan påvirke dem og vi faktisk også kan få ting tilbage igen og det kan vi kun fordi vi har været tro imod standardløsningen. Så vi kan fremadrettet agere rigtig rigtig hurtigt fordi vi kan få leveret store klumper af gangen fra SAP, uden de store problemer. Q: hvis vi skal kigge på konsekvenser igen, hvad er så konsekvensen af at i har valgt at gøre det på den måde? Side 80 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 A: vi har aldrig lavet en sammenligning i forhold til hvis vi havde gjort noget andet, det ville have været spild af tid at lave og kun være med til at skabe frustrationer ude i forretningen. En af konsekvenserne er her at forandringen ude ved vores subbrugere har været støre. Hvis vi havde forsøgt at få deres gamle processer med over i det nye system, så have omvæltningen selvfølgelig også været mindre. Så det har også haft den konsekvens at OCM opgaven er blevet større, da de har skulle informere meget om hvorfor lige præcis de her ting skaber værdi på det store billede. For mange af brugerne giver det måske ikke mening at lige netop det de gør som ikke giver så meget mening for dem gør stor gavn for andre i organisationen. Så for mange er de blevet begravet i et dybt hul på grund af den her store forandring som vi så har skulle få dem op af igen via OCM benet. Den her afmagt omkring forandringerne for de fol som i 20 år har været eksperter i systemet, og ny hvor det nye kommer så kan de bare ingenting! Og om en uge er han blevet overhalet af en trainee som har en smule mere IT flair. Så hele OCM opgaven har været en konsekvens af den måde vi har gjort det på, vi har haft meget mere fokus derpå! Q: Hvordan har i strikket jeres uddannelse og træning sammen i forhold til det her projekt? A: Vi har valgt at kalde vores koncept trainer-­‐trainers. Vi havde nogen der hed trainer superusers, som var superusers men som også havde træningskompetencer til at lære andre det. Dem har vi haft med i projektforløbet og haft showlit views med, og diskuteret løsningen med dem, så de havde noget baggrund. Så er de blevet trænet først. Q: hvis vi tager udgangspunkt i Bilka, har det så været en eller to fra hvert varehus i har trænet som superusers? A: Nej det har været længere oppe, jeg er ikke lige klar over hvor mange der har været fra Bilke delen. Det har været meget forskelligt, for nogen steder har vi snakket tusinde hvis af brugere, andre steder ti brugere som bare er deep core specialister. Det har været skaleret efter hvor mange brugere vi skal ud til og hvor hurtigt vi skal ud til dem. Så baseret på et trainers-­‐trainer koncept hvor vi har trænet passende antal trænere i organisationen og så har de organiseret praktikken med at få hold osv. og andre brugere ned gennemorganisationen trænet. Det andet koncept vi har kørt er just-­‐in-­‐time-­‐training, Vi kan jo ikke træne fire måneder før vi går live. Vi skal træne så tæt som muligt på en Go-­‐Live dato så det er så frisk i erindringen for brugeren som muligt. Det er også derfor det her med et passende antal har været vigtigt, for hvis vi skulle rundt til alle i organisationen er der tale om rigtig rigtig mange brugere. Så skal vi have rigtig mange trænere og ikke et rejsehold som har kørt rundt i 3 måneder og supporteret. Så det har været af varierende størrelse alt efter hvor i organisationen vi skulle arbejde. Når vi har haft decideret specialist træning, altså hvor vores organisation er meget lille som slutbrugere og virkelige nogen dybe specialister som skal gøre det her fra morgen til aften hver dag jamen så har vi trænet dem alle sammen selv fra bunden af. Der har selvfølgelig ligget nogen træningsplaner som har været konsolideret mellem os og den her BPO gruppe, Hvem bliver trænet hvornår og hvem har ansvaret for hvad og hvornår skal det ske i forhold til Go-­‐Live. Så det har været drevet af hele OCM benet, hele den her trænings struktur. Men mange af tingene har været uddelegeret til forretningsenhederne selv. Side 81 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 Q: Så har vi brugerinddragelse, der nævnte du at en stor del af projektgruppen var fra jeres egne forretningsområder? A: hvis man tager projektet og kigger total generisk hen over det og siger at halvdelen af projektgruppen er fra Dansk Supermarked selv og den anden halvdel er eksterne konsulenter. Dem fra Dansk Supermarked vil jeg tro halvdelen har været fra vores brugercommuniti, dvs. Folk der måske en gang har været indkøbere men for 4 år siden er kommet ind og arbejde med de her ting. De er ikke indkøbere mere, men de har stadig styr på basisprocesserne og hvad der sker. Så vi har OK forretningsindsigt. Ellers kan man sige at keywords her i forhold til hele vores koncept med forretningsinddragelse at vi har brugt det her structured walktroughs, showlit views som seancer hvor vi fik buyin fra forretningen. Vi etablerede vores business process ownergruop som har været ansvarlige for forretningsdelen, også for at lave et fælles beslutningsrum på tværs af hele organisationen. Og så den her større OCM organisation som har været defineret ude i forretningen, med trænings superusers og fremtidige superusers osv. Så det har i høg grad været et joint venture de ting der. Q: nu nævner du at i har brugt tidligere indkøbere, har det så gjort at i ikke har fået alt med som i gerne ville, eller er det hovedsageligt kerneprocesserne i har kigget på? A: vi har hele tiden været i dyb dialog med forretningen på den anden side, så det har egentlig bare gjort af de her tidlige brugere har kunne kommunikere med forretningen på ligefod og forstå hvad der bliver sagt og forstå de problemer der bliver illustreret fra forretningens side. De har også gjort det muligt at vinkle hvad vi har kunne gøre for at løse de problemer forretningen har præsenteret over for os. Så det har gavnet vores kommunikation at vi har haft folk der har en ben i begge lejre. De har været rigtig gode til at connecte muligheder og optioner sammen. Q: Så de mennsker har stået for at modtage feedback fra jeres walktroughs osv. hvor mange walktroughs og andet har i haft? A: Det har jeg ingen tal på, men traditionelt set har vi haft rigtig mange. Det er ikke noget der bliver hold log over. Men meget! Det er ikke sådan at folk har siddet væk i uger uden at snakke sammen. Vi snakker dage imellem. Det har også været sådan at når vi startede et nyt område op, f.eks. tekstilområdet. Der trak vi to ud fra forretningen som var fuldtids, og trak dem over i vores projektbygning og var sammen med vores projektgruppe i 5 måneder kun for at vi havde viden tilgængeligt. Vi havde dem også med for at de så kunne opbygges til at kunne træne deres del af organisationen når de så blev sendt tilbage efterfølgende. Dette har vi også gjort på en del andre områder. Hvis personerne ikke vidste noget om en bestemt proces, jamen så kendte de som regel den helt rigtige at snakke med i forhold til det område. Q: på hvilke parameter er de folk så valgt ind på? A: det er de ud fra to ting. 1, de skal have en rigtig god indsigt i de eksisterende processer der sker, selvfølgelig kan de ikke vide alt så 2, de skal også have et godt netværk i deres egen organisation. Så de skal kende bredden, hvem skal man gå til og hvad sker der ude i hjørnerne eller måske de bare ved der sker noget ud i hjørnerne. 3, så skal de have en personlig profil der viser at de er forandringsparate. Da skal kunne se mulighederne, og forstå ideen og kunne arbejde hen imod forandringerne. På den måde har vi ikke skulle bruge ressourcer på at hele Side 82 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 tiden skulle overbevise dem om det er det rigtige. De skal være gode til at fange at der er en fremtid og det er den vi arbejder os hen imod. Så det har været hovedparameterne i det her. Så ikke eksperten som sådan. Q: hvornår i projektet er de her personer blevet indlogeret i det? A: Det blev de typisk når man kom til det forretningsområde. Ved eksemplet med tekstil havde vi et specielt tekstil team, og der blevet de inddraget fra første dag af. Den organisation vi har haft har vi også løbende justeret i forhold til hvad det er vi har haft fokus på. Ikke den overordnede organisation med de fire siloer, men inden for de fire siloer har vi justeret løbende justeret i forhold til hvad der var fokus. Q: i forhold til organisering nævnte du at i havde jeres egen bygning, sad i alle der både eksterne og interne? A: ja. Vi havde faktisk to bygninger. VI havde en bygning hvor vi havde cirka 150 faste pladser i semi åbent kontorlandskab. Der var et rum med cirka 100 mennesker i og så var der nogen andre rum rundt omkring, men mødefaciliteter og køkkenfaciliteter osv. Det var en 100% projektbygning hvor vi ligesom havde coreteamet til at sidde. Vi har fokuseret rigtig meget på at man sidder sammen onside, det er et bevidst valg for at tricke den her samarbejdsånd som var meget agil og hurtig i forhold til beslutninger, diskutioner og løsninger. Så har vi haft en anden bygning lige ved siden af hvor der har siddet nogen teams som vi ikke lige har haft plads til over i den anden bygning, her var der også mødefaciliteter osv. Så vi har sidder rigtig tæt på hinanden og det har været virkelig vigtigt her. Det har også betyder at alle de eksterne konsulenter har været fløjet ind og boet her og arbejdet herfra næsten alt deres arbejdstid. Nogen af dem har boet her i fire år og taget deres familie med til Aarhus og fået børn der går i børnehave nu. De er stadigvæk konsulenter, men nu er de så bare andre steder i verden. Så der har været en rigtig god projektånd i forhold til at vi arbejde fælles om det her, vi arbejder tæt om det her og hvis vi har brug for et møde så samlede man dem adhoc efter behovm dette kunne vi også gøre i bredden fordi der sad mennesker med alle muligt skills og fra alle afdelinger. Så projektånden har været rigtig rigtig vigtig og også det fysiske samvær og så har det også været krydret med sundt med at vi har folk fra alle mulige lande, engelsk har selvfølgelig været sproget. Vi har haft folk fra alle verdensdele undtagen antarktika. Så det har været et meget livligt projekt med en masse god inspiration, fra forskellige nationaliteter og forskellige erfaringsbaggrunde. Man kan sige at alle de eksterne er kommet ind på grund af at de har haft erfaring og fordi de har prøvet det her før. Så hele den her boost med erfaring i den her smedkile hvor folk de sidder tæt og er kreative er rigtig vigtig for at kunne drive det her projekt. Så det har givet os et helt specielt fællesskab og vi er ”in-­‐this-­‐together”, uanset om du kommer fra IBM, Indien, Pakistan eller KPS i Tyskland så er vi fælles om det her. Der er ingen der har haft specielle batches eller specielle aftaler, vi gør det her sammen. Det her fælleskab har været ekstremt vigtig for at kunne flytte sådan en flok af den her størrelse fremad. Q: Har alle været hyret ind på timebasis? A: Det er forskelligt, men det generelle trend er at de eksterne har været på timebasis. Hvis man begynder at kigge ud i krogene så har kerneteamet været folk der har været hyret på Side 83 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 timebasis og så har vi ledet dem. Der har selvfølgelig også været alle mulige leverandører sideløbende som vi har fået leveret specialist løsninger fra. Nogen gange via små fastprisaftale, så vi har haft alle niveauer af leverandørstyringer, store langsigtede kontrakter med leverandører, på timebasis, amts aftaler med IBM, forskellige fastprisaftaler med leverandører der siger at de skal levere den her lille bid på det her bestemte tidspunkt. I forhold til udviklingsmodeller kører alle de her leverandører jo med hver deres, og der har vi skule finde ud af hvordan vi får alle de her ting til at hænge sammen, vi har kunne diktere hvordan vi selv ville arbejde med det her, men når vi sendte det ud i byen kunne vi ikke diktere noget. Men nogen gange sendte vi det ud til et lille softwarehus hvor vi kunne påvirke dem meget, andre gange sendte vi det ud til gigantiske softwarehuse hvor vi kunne påvirke dem meget lidt. Så det har hele tiden været den her balancegang mellem at få forskellighederne til at fungere, det har der været meget fokus omkring. Q: har i været bevidste omkring den overordnede projektmodel? A: det har været skræddersyet til det her specifikke formål her, som udviklingsmodel har vi kørt den her Rapit Transformation som kommer fra KPS. Vi har nødt til at ligge en projektmodel oven på som passer til udviklingsmodellen. Den har været skræddersyet til det her, det er ikke en du kan finde i en lærebog. Den har været skræddersyet i forhold til faser, i forhold til styregruppen, i forhold til forretningen, i forhold til organiseringen og i forhold til værktøjer. Projektet har haft en størrelse hvor vi også har haft en underliggende metodebane hele vejen igennem, hvor vi har bygget metodeapparatet op tilpas i forhold til projektet. Så ja du kan kigge på elementer der lugter af Prince2, med hvem der er seniorleverandør osv. så det lugter af det ja også med konstant fokus på businesscasen. Så elementer af mange forskellige metoder som har været brændt sammen til det her unikke projekt og den kan ikke genbruges, den giver ingen mening at genbruge efterfølgende. Q: Nu nævnte du selv udviklingsmodeller, når i selv har siddet har i så fulgt en bestemt? A: vi har brugt et kludetæppe af metoder for at kunne styre forskelligheden, i det her apparat. Agilt i forhold til udviklingen, og dialogen med forretningen. Men i den afsluttende test og deployment via vandfaldsmodel, da vi var nødt til at samle en stor release da vi ikke kunne deploy hver uge, for ved rigtig agilt deployer du hele tiden og tager det i brug hele tiden. Det har vi ikke kunne for vi har skulle starte et helt land op. Så agilt i starten og så afsluttet med en vandfalds test og deployment i produktion og så Go-­‐Live. Så det har været to metoder vi har smeltet sammen, hybrid-­‐agilt bliver det nogen gange kaldt som metode. I forhold til projektledelse vil jeg sige at vi har taget bider af forskellige metodikker og så har vi sammensat en der var unik for det her projekt. Projektet har også haft en form som har berettiget at vi har skræddersyet noget unikt til det her. Vi ville ikke have kunne have drevet det her projekt med en klassik metodik. Det er selvfølgelig også det der har været med til at gøre det spændend for sådan en som mig, at lave noget der er fuldstændig unikt og hvor man skulle trække på alle former for projektledelse og udviklingsmodeller og smelte det sammen. Q: til at slutte af med, så vil vi gerne høre tre gode og tre dårlige ting ved det her projekt? A: Man kan starter med at tage det fra projektvinklen først. Det her er et unikt projekt! Det er sådan noget en virksomhed laver en gang i deres levetid, og aldrig nogensinde igen. Det Side 84 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 betyder også at være med til det her som projektleder, har været et gigantisk løft at udfordringer og kompetancer. Det vi har gjort her, og noget som vi er virkelig stolte af, er måden vi har drevet det her på, og nået det vi skulle ovenpå de teknologier og med de omvæltninger vi har lavet er nærmest ikke set på verdensplan. Når man snakker med SAP og KPS har de heller ikke set noget i den her liga før. Så vi er faktisk frontrunner på rigtig mange område lige nu. Det har i hvert fald for mig rent personligt været rigtig rigtig fedt at være med til. Det aller bedste ved det her projekt vil jeg faktisk sige har været den her skræddersygning, uanset om det har været i forhold til organisering, modeller eller udvikling, og bære åben overfor ikke at være slave i den forstand, men at man er nødt til at tilpasse sig den situation man er i. Modeller er rigtig gode og jeg er også glad for rigtig mange modeller, men man bliver også nødt til at plukke af dem og tage det bedste fra nogen og så finde ud af hvordan man kreativt kan sætte dem sammen. Der er ikke en onesize-­‐fits-­‐all, og når man kommer op i specielle projekter bliver man nødt til at tænke kreativt omkring tingene og man bliver nødt til bare at springe ud i det. Man bliver nødt til at lave en kernebase og så forfine den undervejs og learn-­‐by-­‐doing. Så ud fra et projektmæssigt synspunkt så handler det om at komme i gang, ha et idegrundlag, lave en grovstruktur, få det til at trille og så hele tiden have fokus på hvordan du kan ændre strukturen, processer, metoden osv. for at forfine ting. Så learn and adapt, hele tiden. Q: hvad hvis vi skal over i den anden boldgade af de mere negative ting ved projektet? A: Det har været rigtig svært at gennemføre og der har været rigtig mange udfordringer. Men grunden til jeg har svært ved at pege på noget er fordi der har været den her fællesånd med at det her skal vi bare igennem! Der var en periode i midten hvor vi ikke havde opbakning fra vores top management, vi havde en direktør der var stoppet og man søgte en ny. I det vakuum der var der var det umuligt at få taget nogen ledelsesmæssige beslutninger fra toppen. Hvilken faktisk gjorde at vi mistede momentum total. For da begyndte forretningsområderne pludselig at suboptimere egne forretningsområder og vi havde jo brug for fælleskab. Så den periode fik vi virkelig bekræftet hvor vigtigt det er med top management opbakning. Man skaber ikke et forandringsprojekt hvis ikke ledelsen står i front og synligt bakker op omkring de ting. Da vi inde i den periode var vi nede i et sort hul omkring motivation fordi vi egentlig bare stod og skubbede ind i en pude og kunne ikke komme fremad mad ting, og pludselig kommer man ind i rep-­‐handlingshelvede, hvor man ikke laver andet end at repetere sig selv hver dag. Så det var en ond spiral. Side 85 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 12.3 Bilag 3 – Interview med Martin Frederiksen 1 Bilag 3 -­‐ Interview med Martin Frederiksen fra Klean om Projekt for Gloster Q: Du har nævnt Gloster som et interessant projekt, hvorfor er det interessant? 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 A: Jeg syntes det er et interessant projekt at tale om fordi det er noget vi også kan kigge på samme og jeg kan kort vise, hvad websitet går ud på og vise hvilke udfordringer man har, når man laver et sådant projekt. (Website vises på computer, red.). Her kan i se det færdige resultat, der er et responsivt website, som har nogle varer, som er nogle high-­‐end havemøbler. Jeg har besøgt deres showroom i west hollywood, hvor kunderne er kendt der spontanshopper for 150.000 kr. havemøbler på en lørdag formiddag. Det er sådan noget med at stole godt kan koste 20.000 kr. for en havestol. Det er super lækre produkter og de skal jo have et website som skal matche til deres kvalitet, hvor man fremhæver designerne. De folk der køber det her vil gerne have at det er tik-­‐træ eller andre dyre materialer. De vil gerne have at der er CSR involveret, så der skal købes tik-­‐træ fra nogle plantager som man selv ejer, hvor træerne er mellem 50-­‐100 år gamle og der fornyes hele tiden plantager. Så det er bæredygtigt lavet og en blanding af skandinavisk og europæisk design og har en meget høj kvalitet i hele produktionen. Medarbejderne for ordentlig løn og der er ordentlig arbejdsvilkår. Man havde et website, som var meget dødt ift. den storytælling som man ønskede. 17 Q: Okay, så man ønskede et website der i højere grad viste historien? 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 A: Ja og det gør det så også. Det der er udfordringen når man laver sådan et website. (henviser til website, red.). Her har vi en af medarbejderne i Indonesien, som fortæller noget om tik-­‐træ og om hvordan de udvælger og forarbejder træet. Det der er udfordringen når man kommer ind i sådan virksomhed, som er en klassisk møbelvirksomhed, der producerer noget som bliver solgt igennem en masse butikker, er at datakvalitet det ikke eksisterer. Det eneste man har er datakvalitet på marketing niveau. Det er altså to drinks med paraplyer i. Der er absolut ingen struktur på noget. Så udfordringen i projektet handler egentligt ikke om at skrive noget kode. Udfordringen i projektet handler om, at ledelsen skal finde ud af at online er kommet for at blive. Ledelsen skal finde ud af at det ikke er nok at lave et website, men at de også skal sørge for deres social media strategi skal være i orden. De skal have styr på deres analytics data. Når der er noget de lærer af de her analytics data, så skal de rent faktisk reagerer på det. Wauw ikke!. Tallene siger at hvis vi gør sådan her, så virker det bedre end det her. Nu skal vi holde op med at gøre det, som vi selv synes og i stedet gøre det som vi kan bevise virker. Det der med at flytte sig fra at være drevet af mavefornemmelse og så til at være drevet af data det er en enorm omvæltning for ledelsen i alle virksomheder. Det er det også for medarbejderne, fordi de folk som er ansat i marketing eller kommunikation hvor websitet hører under, de er absolut ikke nørder. De er drevet af følelser og ting de kan lide. De drives af noget der er inspirerende og spændende. De er ikke struktureret, de har ikke styr på deres produktinformationer. Det har taget os et halvt år, at få renset produktdata således at vi Side 86 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 37 38 39 40 41 42 43 44 45 46 47 faktisk har et overblik over, hvilke stole der findes i hvilke farver, i hvilket stel og med hvilke armlæn. Lige nu bygger vi en konfigurator, der kommer om 14 dage. Det bliver et upgrade af sitet. Der er lavet nye renderings af alle møbler i meget højt kvalitet som er lavet i CAD-­‐design. Vi får alle disse renderings, altså tusinde af billeder, da der er tale om alle kombinationer af forskellige møbler. Herpå bygger vi en konfigurator, hvor man får en given stol vil kunne se den med et rødt betræk og hvilket stel findes der så hertil. Der er masser af kombinationer der findes, men også masser af kombinationer der ikke findes. Lige pludselig skal marketing afdelingen være drevet af at de hver eneste dag, året rundt, skal have styr på deres produktdata. Indtil nu har det været således at du kun den ene gang om året, hvor de udgav et katalog, skulle have styr på produktdata. I stedet for at have styr på det en gang for hver 700 dage, skal man have styr på det hver time – altid. 48 49 Q: Den her forandringsledelse og omstilling til at tænke anderledes, er det noget i har været inde og hjælpe med? 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 A: Ja, det er os der har drevet den her proces og vi driver den stadigvæk. Jeg har lige siddet til møde inden i kom, hvor vi snakkede om deres social media. Hvor vi nu er i gang med at bygge et dashboard for dem og i gang med at sætte et program op, hvor vi laver konkurrentanalyser og konkurrent overvågning. Derudover laver vi en analyse af deres læsere, altså hvem er Glosters kunde. Hvilke sites bevæger de sig på og hvad er det de gør der. Således for vi en intelligens om hvem Glosters kunder egentligt er. Derpå kan man udvælge hvilke kanaler vi skal igennem og hvilke budskaber vi skal leverer i de forskellige kanaler, så man kan trække trafik ind på websitet. Det sidder vi og laver i løbet af formiddagen og så stiller jeg spørgsmålet for 10 min siden, inden i kom: ”Hvem har adgang til alle de her konti, som Gloster har på Twitter, Facebook, LinkedIN, Pinterest, Instagram osv.?” Svaret er, der er ingen der ved hvem der har adgang til disse konti. Det er sikkert noget hvor man skal ud i organisationen, hvor en person har en konto og en anden person har en anden. Nu kommer vi til at bruge en uge, bare på at få adgang til deres konti, fordi de ved ikke selv, hvem der har oprettet dem. Det betyder også at på youtube hedder deres konto GlosterClips, på twitter hedder det GlosterFurniture, på Facebook hedder det noget andet. Hvis man som kunde overvejer at købe noget fra Gloster og lige vil se hvad de egentligt har udgivet, så skal man lige nu først finde ud af de ti forskellige navne der er ude på de forskellige social media kanaler. Man har altså sat forbrugerne i en rigtig rigtig dårlig situation på den måde. Nu skal vi have adgang til alle disse konti og dernæst have lavet navnene om. Derefter skal vi have marketing afdelingen til at forstå, hvordan man arbejder med online kommunikation. Så for at starte det projekt op, har vi foreløbigt fået et budget på 300 timer. Det siger noget om at man erkender, at man ikke har fået løst den opgave. Vi bruge de 300 timer på lige at få bragt tingene i en OK tilstand. Efter oprydningen af det rod der har stået på i årevis, kan man så begynde at skabe nogle resultater. Det illustrerer meget godt at det i dette tilfælde er direktøren der har gået til sin organisation og sagt: ”Jeg har hyret de her gutter fra Klean, de skal komme og hjælpe os med alt det her”. Herefter skal organisationen lige vænne sig til at nu er det os (læs Klean, red.), der er med til at sætte retningen. I andre organisationer er det sådan at medarbejderne siger: ”At Side 87 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 77 78 79 80 81 82 83 84 85 86 87 88 89 hvis bare jeg kunne få lov til at…”. Så har man en organisation, hvor ledelsen ikke har noget initiativ og hvor de gerne vil undgå ”digitalt”, fordi de ikke forstår hvad det er. Det ødelægger så deres muligheder for at lave forretningsudvikling. Hvis vi skal runde den af; I et andet projekt er de ekstremt langsomme til at gå online, og de har været ekstremt langsomme til at gøre hvad det er de gerne vil. Til allersidst kommer presset nedefra og op med ledelsen til at være så stort, at ledelsen erkender at nu må de nok hellere gøre det her. Så går ledelsen til bestyrelsen. Bestyrelsen er dyb modstander af at gøre noget online, fordi de forstår det heller ikke. Så bliver der brugt 1,5 år på at skubbe denne proces fremad. Det har vi været med i og vi har skabt gode resultater. Det er endt med at på et bestyrelsesmøde siger bestyrelsen så til direktøren: ”Det var vel nok godt at vi fik sat gang i det her online!”. De har fuldstændig glemt at de havde gjort for at hindre det. Nu hvor de kan se at online omsætningen vokser med raketfart, samtidigt med at butikkerne stagnere, så syntes de faktisk at det er det bedste de har gjort. Det er de udfordringer som vi er i, i de her projekter. 90 Q: Hos Gloster, hvad laver i for dem? 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 A: Her laver vi det hele. De har rent faktisk aflyst deres deltagelse på en række messer i år for at kaste de penge de sparer på ”online”. Så vi laver websitet, en produktdatabase, en konfigurator og fremover kommer alle deres produktdata til at blive vedligeholdt i den her produktdatabase vi har bygget. Således går de væk fra excel regneark og bruger databasen i stedet for. Den er lavet meget sofistikeret. Så laver vi al deres social media, bygger deres dashboards, laver deres analytics, deres ad works annoncering og alle de andre ting der skal til. Derudover er vi også sparringspartner for ledelsen ift. hele deres retail-­‐ Cross channel strategi og hvordan de egentligt skal gribe det an. Det er simpelthen i erkendelse af, at hvis den her forandringsproces skulle ske internt i organisationen, så er der for mange der skal lære for meget og det vil komme til at gå for langsomt. Det er egentligt på samme måde som ude hos Bilka, hvor vi kom ind ad døren og skulle være med til at lave den revolution, hvor alle de mennesker der sidder på den her stol de har siddet på i 10 år og har arbejdet sammen med de samme kolleger i 10 år og hentet kaffe fra den samme kaffemaskine i 10 år. Det er en næsten umulig opgave at sige til dem, at nu skal i til at tænke noget helt anderledes. Man er nød til at bringe nogle ind der kan være en katalysator, for den innovationsproces der skal ske. Så skal de lærer en helt masse, så de kan overtage det bagefter. Sådan kommer det her projekt også til at gå. Vi kommer til at lave en masse ting for Gloster og løfter deres medarbejdere og får dem efteruddannede. Vi sender en mand til Bristol her om to uger, hvor han skal være i en uge på deres hovedkontor. Vi gør meget for at få det til at live et fællesskab om den her opgave, i stedet for at vi er leverandører til dem. Sådan agerer vi som om vi egentligt er deres it-­‐afdeling. 112 Q: I forhold til visionen, er i med til at sætte den sammen med ledelsen? 113 A: Ja. Eller det er sådan set mere os der sætter visionen end dem. 114 Q: Så deres opgave er egentligt bare at sige ja eller nej? Side 88 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 A: Ja, de siger ja eller nej. Men jeg syntes rent faktisk at vi har nogle rigtigt gode diskussioner med direktøren og med de forskellige topchefer der er. Her sætter vi os ned og diskuterer, hvad det egentligt er deres strategi som virksomhed. De er gode til at kommunikere, hvad det egentligt er for nogle retninger de søger i. Så er det vores opgave, at udfordre dem på om det er nogle retninger vi tror på. Men også at sige, hvis i gerne vil i den retning, så kan i gøre det og det og det. Hvis vi snakker om et af de projekter vi skal i gang med inden sommerferien, som er at lave ecommerce i USA. De har aldrig lavet ecommerce før. Alt det vi har byget indtil nu, er bygget på en måde hvor det er rimelig ligetil at sige at ecommerce er næste skridt. Der ligger en masse arbejder der skal gøres, men vi ved hvad der skal gøre og hvordan det kommer til at fungerer. Når det her ecommerce projekt skal gennemføres, så ved vi at de medarbejdere der sidder i USA kommer til at have det rigtig svært Både mht. at løfte opgaven, men også alt muligt omkring kommunikation til deres butikker. Butikkerne vil synes at nu begynder Gloster at konkurrer med os gennem deres brug af online. Er vi nu bare et showroom for Gloster. Der er noget omkring hele forretningsmodellen og om hvordan man egentligt får lavet en aftale med butikker, så de synes at det er en god forretning for dem. De kan fx få en procentdel af online salget, baseret på deres omsætning af Gloster møbler. Det er et eksempel på at vi skal hjælpes ad med at sætte strategien. De kan fortælle hvad det er de vil. Vi kan fortælle, baseret på erfaring fra andre projekter, hvad det er for nogle metoder der kan løse det her problem. Den her metode er noget som Ford har brugt, det er ikke noget som vi har opfundet. Ford brugte det fordi mange biler bliver solgt online. Man tager ned til forhandleren og kigger på biler og bagefter tager man hjem og køber sin bil fra sin Ipad i sofaen, imens man drikker en Budweiser. 137 138 Q: Så for at runde op. Visionen med projektet, for Gloster, er i hovedtræk at få digitaliseret historien bag produkterne og få den med ud på hjemmesiden? 139 A: Ja og de har i virkeligheden været 7 år bag ud digitalt og det har vi fået 2015 til at indhente. 140 Q: I forhold til kravspecifikationen, hvordan har i arbejdet med krav? 141 142 143 144 145 146 147 148 149 150 151 152 153 154 A: Det er meget interessant og det er veldokumenteret hvordan den her opgave skal løses. I gamle dage har jeg brugt mange timer på at skrive kravspecifikationer. Når man har gjort det som sit professionelle håndværk, så finder man ud af at det faktisk ikke kan lade sig gøre. Jeg kan aldrig skrive et dokument til dig, som du vil forstå godt nok til, at du vil lave det jeg forventede. Det man typisk ser i de har vandfaldsprojekter er at man for etape har en ide, man vælger en leverandør, man beskriver nogle krav, skriver noget kode og der er nogle test. Helt nede hvor vandet plasker ud står en mand og kigger op og siger: ”Det var slet ikke det jeg troede jeg bestilte, men nu er pengene brugt og alt vandet løbet ned og det kommer aldrig op igen.” Det er umuligt at beskrive detaljeret nok. Er godt eksempel er at i den her menu struktur (viser menu på Gloster.com), som skal virke på en mobiltelefon, der har vi den udfordring at vi i virkeligheden både skal vise alle hovedområderne, men også alle kollektionerne og der er rigtig mange møbler. I det her tilfælde er det løst ved at bruge en såkaldt overloadet button. I virkeligheden er den her knap ”collections” en funktion når man klikker til venstre og en anden funktion når man klikker til højre. Når man klikker til venstre Side 89 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 kommer man hen til en forside, hvor man ser alle kollektionerne. Når man klikker til højre er der en animering, således at man nu kan se alle de forskellige kollektioner og gå direkte til den man ønsker. Forestil dig at nogle fra Gloster skulle have beskrevet det her i en kravspecifikation til os. Det er marketing folk. De vil slet ikke kunne opfinde de her ting. Det vi har gjort er at vi i stedet for at skrive en masse dokumentation, har skrevet et rammedokument der beskriver hvad visionen er med hele det her projekt. Bagefter har vi haft et workshopforløb på 9 dage, som starter med at folk fra Gloster flyver ind til Aarhus og mødes med os. Her diskuterer vi hele deres projekt og deres målgrupper. Henrik der har designet æstetikken til det her design har på baggrund af den workshop lavet et dokument vi kalder for ”Stil og Tone dokument”. Det beskriver farver, former mm. Henrik er grafisk designer, ikke digital designer. Ovenpå sidder Karina, som er digital designer. Hun tager stil og tone dokumentet og i løbet af de 9 dage, hvor Gloster primært er med til start og slut og imellem skyper, bygger vi rent faktisk en prototype. I gamle dage vil man have bygget den i Photoshop. Det er dog fuldstændig håbløst når det skal være responsivt og skalerer efter størrelse. Det der i stedet sker er at Karina arbejder sammen med Charles, som er frontend designer. Derudover har vi nogle fok der står for informationsarkitektur, usability osv. I løbet af de 9 dage bygger vi faktisk hele sitet i responsivt frontend. Det har vi fundet ud af er meget hurtigtigere end at bygge det i Photoshop først og så kode det bagefter. Samtidigt har vi efter de 9 dage fremvisning, hvor man kan vise hvordan hele websitet kommer til at fungerer, element for element. Gloster godkender denne responsive prototype og bagefter har vi i virkeligheden ikke alle siderne og indholdet, men vi har en visning af, såden her skal en stol vises, sådan har skal en artikel vises, sådan her skal navigationen fungerer, sådan her skal man kunne skifte sprog, sådan her skal man kunne navigerer mellem det engelske og det amerikanske website, sådan her skal man udfylde en formular. Bagefter bruger vi det her ned i nogle delopgaver, hvor hver delopgave er samlet i Epic User stories og tasks. Et Epic er den store fortælling. En Epic kan fx handle om produktvisning. Under det her Epic laver vi en række User storie fx Som forbrugeren Henrik vil jeg gerne finde en stol for at se hvilke materialer den er lavet af. Man kan lave et antal user stories, som er ting man forestiller sig at folk gerne vil gøre på websitet. Det næste man gør er at forsyne denne User storie med acceptkriterier. Det er i virkeligheden det der er kravspecifikationen, men den er meget kortfattet og ekstremt funktionel. I virkeligheden er acceptkriteriet en trinfor-­‐trin beskrivelse. Hvis man er udvikler vil man sige, ”hey – det er jo min algoritme jeg har her”. Hvis man er tester vil man sige ”Hey – hvis det virker på den her måde, så er det i orden.” 188 189 190 191 192 Acceptkriteriet for at finde en stol i Bristol kollektionen kan være: ”Givet at jeg klikker i menuen og givet at jeg klikker på højre side at ”collections”-­‐knappen og givet at jeg vælger Bristol i menuen, kommer jeg til en side, hvor jeg ser alle møbler i Bristol kollektionen. Givet at jeg scroller ned af siden og finder det bord jeg gerne vil se på, sendes jeg videre til en side med detaljevisning af bordet. Her finder jeg de informationer som jeg efterspørger. 193 194 Så har man egentligt beskrevet den her user story, med nogle acceptkriterier. I Stedet for at lave en mega lang kravspecifikation, hvor man opstiller alle mulige fiktive ideer til, hvordan Side 90 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 195 196 197 det her skal fungerer. Så er kravspecifikationen i virkeligheden en hel stak af opgaver, som et almindeligt menneske vil gøre på websitet. Kombineret med en funktionel beskrivelse, af hvordan det her det foregår. 198 Q: Her har man egentligt bygget sin test case op? 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 A: Ja, det er nemlig indbygget i det her. Når man har sin user story og når Gloster prioritere at den her user story skal laves i sprint 4. Så laver vi en nedbrydning af den her user story, hvor vi mødes i teamet og diskuterer hvad det krævet i HTML og CSS. Hvad er der af magento implementering, hvad er der af testarbejde og hvordan skal det dokumenteres. Så laver vi et estimat og siger at den her user story tager 12 timer. Så har vi måske 240 timer til rådighed i sprintet og derpå ved vi at sprintet kan fyldes op med 240 timers opgaver. Da vi altid har noget luft i vores produktionsplan, så tager det i tilstrækkelig grad hensyn til sygdom mm. I nogle sprint vil man finde ud af at man ikke når de 100 % af det man forventer. I andre sprint når man faktisk mere. I Agil system udvikling findes der det begreb der hedder ”Velocity”. Det er noget som man tit arbejder med i story points, hvor man tildeler hver user story et antal point. Vi har valgt at arbejde med velocity i timer. Det er ikke et udtryk for, hvis vi nu har arbejdet i 100 timer og havde en prognose på 100 timer, at vi så har en velocity på 100. Det er et udtryk for at hvis vi arbejder 100 timer og har nået de ting vi har planlagt, så har vi en velocity på 100. Den måde man skal forstå velocity på er at når teamet starter et sprint og har 100 timer de kan disponere over og estimere opgaverne til 100 timer. Så må man også forvente at de har leveret alle opgaverne når de har brugt de 100 timer. Hvis de leverede alle opgaverne og brugte 80 timer, er de i virkeligheden 20% mere effektive end de selv tror. Så er deres velocity egentligt 120. Hvis de i stedet har brugt 200 timer på at løse opgaverne, så er deres velocity 50. Det man lærer af det som team, er at hver gang vi tror noget tager en bestemt tid. Så baseret på past performance (et nøgleord) så ved vi, hvor meget vi skal lægge til at trække fra, fordi vi ved hvor dårligt folk estimerer. Når man sidder i et udviklingsteam med ti mand, så lærer man lynhurtigt hvem der kan og ikke kan estimerer. Man lærer at tage højde for at hvis man giver noget til den og den, bliver det afleveret til tiden og hvis jeg leverer det til en tredje, så kan jeg gange med tre. Det er ikke et udtryk for at tredjemand er dårlig til at skrive kode, det er et udtryk for at tredjemand er dårlig til at estimerer hvor lang tid han skal bruge på det. Så det kan man ligeså godt planlægge med – at folk er dårlige til at vurderer deres egen tid. 226 227 Q: Hvis du skal sætte nogle ord på, hvad det har af konsekvenser at i gør det på den her måde, frem for alle mulige andre måder, hvad ville det så være? 228 229 230 231 232 233 A: Det vi får ud af det, er egentligt det som kunderne får ud af det. At man har et fokus på at lave ting der virker for kunderne, i stedet for at lave noget der opfylder det der står i et dokument. Så får man også skåret meget igennem den tykke tåge af bullshit der handler om at kunderne kommer med et dokument og siger: ”Hvor lang tid tager det at lave det?” Jeg kan godt kigge på det dokument og sige at jeg lige skal have svar på 400 ting, gå lige hjem og fortæl mig hvad svarene er på de her 400 ting. Hvis kunden så bagefter kan svarer på alle Side 91 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 234 235 disse ting, så kan jeg også regne estimatet ud. Men det ved jeg med sikkerhed, at det kan de ikke. 236 Q: Det er fælles med Gloster, at i har udviklet de her user stories? 237 238 239 A: Ja, men i nogle projekter har vi fået så godt et brief på forhånd, at vi bare gør det selv. Bagefter siger vi så til dem at det er det her vi laver. Så kan de så sige at det har de det svært med eller ej. 240 28.50: gennemgang af user story og kleans back logging system. 241 30:16: Øvelse i estimering af user story 242 Q: Hvordan opstiller i milepæle? 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 A: Der er forskellige regler at gå efter her. Det første er, at inden vi laver det detaljeret estimat af ”tilmeld til nyhedsbrev”, så tager vi hele projektet og baseret på erfaring, giver et samlet estimat. Ligesom når man spørger en tømre hvor lang tid det tager at skifte et tag, så har vi en rigtig god håndværksmæssig erfaring med, hvad bør ting egentligt tage af tid. Vi tager egentligt hele projektet og deler det op i nogle budget rammer. Så indenfor fx email marketing har vi måske sat 50-­‐100 af og anderledes indenfor andre områder. Så er opgaven jo at sige, hvad kan vi egentligt gennemøre af aktiviteter indenfor det her område, der overholder det budget der er sat af hertil. Det er i modsætning til at kunden kommer med 200 sider og låser en fast pris og bagefter finder ud af at det slet ikke holder. Og så skal man til at skændes om det. Om det er Gloster eller andre kunder, så har de, de penge de har sat af på budgettet. Vores opgaver er at forvalte de her penge, så de får mest mulig værdi for de udviklingsomkostninger som de påtager sig. Det er ikke nødvendigvis sådan at resultatet bliver bedre af at der er flere features, men det er rent faktisk der hvor vandfaldsmodellen inviterer til feature creep. Derudover inviterer den til at man bliver ved med at forfølge leverandøren, som ingen måske har brug for. Men så kan økonomidirektøren hos kunden føle at han fik mere værdi for pengene. Han får bare ikke mere salg online eller noget. Tværtimod er det sådan at kunderne er glad for at noget der er simpelt og enkelt at gå til. Det kan man også se på Glosters website. Det er meget enkelt at lave, men fordi det er enkelt at lave er det også svært at lave. Hemmingway skrev engang til en af sine venner, at han vil have skrevet et kortere brev, men det havde han ikke tid til. Det er egentligt også det der gør sig gældende her. Hvis vi skal lave noget der er simpelt, skal vi have været med velovervejet omkring hvordan det her egentligt kan blive simpelt. Det er nemt nok at lave et website med en hulans masse sider og knapper. Det gør så i virkeligheden at dine user stories er enormt besværlige. Man kan godt finde informationen, man skal bare gøre det og det og det og det. Når vi har de overordnede budgetrammer, så planlægger vi efter, at i løbet af et projekt har vi 1000 timer. Vi har 100 timer her, 200 her osv. Vi har også styr på hvordan team sammensætningen gennemsnitligt skal være, således at det passer med at der er testere klar når der er nogle der har kodet noget. Ved at man har denne sammenhæng mellem udviklerressourcer, designressourcer, test ressourcer osv., så handler det om at give teamet arbejdsro, så de kan fokuserer på at de skal gennemføre de her user stories og de skal leverer om 14 dage. Side 92 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 273 Q: Så i tracker jeres milepæle ved brug af ”velocity”? 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 A: Der forskellige ting man gerne vil måle. Man vil gerne måle at ens progression er lige så hurtig, som man gætter den vil være. Det vil man gerne have styr på for at vide, på et tidligt tidspunkt, om der er en udfordring med at nå tingene indenfor budgettet. Derudover vil man gerne vide det bare for at man gerne vil være klog på hvad det er man gør. Hvis man kunne lære at man altid er langsommere end man selv tror, da kunne det være man skulle begynde at skrive noget mere på estimaterne. I forhold til milepæle, er der et løftebrug her eller er der tale om en pålidelig person. Hvis jeg lover dig at leverer 12 ting til d. 23/4, så har jeg ikke lyst til at sidde d. 24/4 og sige at jeg ikke er blevet færdig. Du vil gerne vide at alt hvad jeg leverer også kommer som forventet og jeg vil gerne være den der leverer det der er forventet. Omkring tidsforbruget, der har vi selv bygget et dashboard (viser Klean’s dashboard – burndown chart). Den røde linje viser det faktiske burndown og den blå graf viser lineært burndown. Ideen med det her er at vi fra vores logging system her en masse opgaver, hvortil der registreres tid. Dashboardet bliver synkroniseret automatisk hver time. Alle tallene bliver lagt sammen for at genererer grafen. Der er ikke noget galt i at grafen ser sådan her ud (ser konkav ud, red.), i stedet for lineær. I det her dashboard er der ikke bygget nogle features, hvor vi kan bygge et forventet burndown. Typisk vil det være således at et burndown i starten er rimelig fladt. På et tidspunkt faldet det nedad, og herefter vil det igen flade ud. Grunden til at det typisk er sådan i projekterne er at, til at starte med er man langsom til at forbruge tid, fordi man planlægger hvordan det skal være. Man bygger måske papirs prototyper og tester med en række mennesker. På et tidspunkt når man til en validering af en prototype, der vil fungerer. Herefter begynder man at kode og så går det hurtigt. På et tidspunkt når man til et punkt der hedder feature freeze. Det er der hvor kunden ikke må komme med gode ideer længere. Typisk vil der i et større projekt være en 6 ugers periode op til lanceringen. Så med 6 uger til lanceringen siger man til kunden: ”Nu kommer der ikke flere gode ideer, vel?” To uger senere er der code freeze. Hvilket betyder at nu er der ikke nogle der må begynde med at kode en ny feature. Hvis man ikke er begyndt at implementere en feature, så er det for sent at starte. Man må afslutte kode man er begyndt at skrive og rette fejl i kode der er skrevet. To uger før lanceringen, der går man i driftsprøve, hvor man laver en performancetest, sikkerhedstest mm. Hvor man tester produktet for at finde ud af om det lever op til de krav man har til driften. Først derefter går man i drift med det. Hvis det er et projekt på 3-­‐4 mdr. vil de sidste 6 uger være feature freeze, code freeze, driftsprøve og åbning. Derefter går man over i en fase, hvor man er særligt opmærksom på om der optræder noget efter man går i drift. 306 307 Q: Test har vi været omkring, hvor du snakkede om at i brugte user stories. Har du andet at tilføje til test? 308 309 310 311 312 A: Ja, der er flere ting i det. Hver eneste user story kan testes for sig. Udover det er der en opgave i at teste på tværs af user stories. Hvis man ikke gør det kan man komme til at deploye to user stories der ikke giver mening sammen med hinanden. Man kan teste to user stories, men man mangler en tredje for at det giver mening. Lad os sige at man laver et: ”Checkout flow”. Det eneste vi mangler at implementerer er den user story der handler om Side 93 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 kreditkortbetaling. Alle de andre med at putte i kurv, se oversigt, bestil levering mv, er ordnet. Hvis man deployer de user stories uden at deploye kreditkortbetaling giver det ikke mening. Man har mistet overblikket over at de første ikke giver mening uden den sidste. Når man snakker om issue tracking, Bugs, så snakker man om parent bugs og sister bugs. En parent bug er en fejl der gør at mange andre fejl opstår. Så i komplekse systemer har man brug for at finde ud af hvad der er root cause til at en fejl opstår. Normalt så er QR afdelingen dygtige til at finde ud af, at når vi har flg. Problemer, så skyldes det måske noget af validering af formularer. I stedet for at løse dem enkeltstående, så analyserer man for at se hvad man kan gøre for at harmoniserer vores valideringsmetoder noget mere. De fejl der er nede på det lavere niveau, ser man som værende søskende til hinanden, sister bugs. I issue tracker vil man anføre at man har en mistanke om at den her fejl er på samme niveau med en anden. Når man åbner backloggen til et opgave og vil prioritere, hvad man skal lave til næste sprint, så i stedet for at løse noget her og der, vil man se på det som nogle klumper. Fx kunne det være at man vil gøre noget ved de her formularer. Alle de cases der er relateret til formularer, prøver man at løse det indenfor det her sprint. Man har således en isoleret del af koden som man åbner, forbedrer, tester og deployer og lukker ned igen. Derefter lader man der gå nogle måneder før man egentligt gør noget ved det igen. 330 Q: Kører i sprints hvor i primært forsøger at eliminerer bugs? 331 332 333 334 335 336 337 338 A: Det er sjældent at vi gør det. Som regel vil det være sådan at der i et sprint er afsat 80% af tiden til at lave enten noget funktionelt eller æstetisk refakturering af noget man har lavet tidligere. Eller det er nogle nye features man laver. Man har en procentsats sat af til at rette nogle fejl. Udover at rette fejl i det kode man afleverer i det sprint, så kan det være noget af tiden der sættes af til det her, det vil gå til at refakturere et eller andet, hvor der ikke er nogle der specifikt har bedt om det, men hvor det hele bliver ødelagt hvis det er sådan at man ikke løbende gør det. Det er meget velkendt i projekter, at de bliver slået ihjel af at man bygger nye features og man undlader at rette fejl. 339 (Viser et slideshow om features) 340 341 342 343 344 345 346 347 348 349 350 351 352 Hvis det er sådan at man kun introducerer nye features og det sker meget ofte, så sker der det at man som projektleder kan vise, hold kæft hvor går det godt. På et tidspunkt når man et punkt der hedder ”bugs kill features”. Det er det punkt hvor der er bygget så meget defekt kode ovenpå hinanden. Vi har kunnet vise en enormt god progression i projektet, men vi har bygget et kæmpe krater, i virkeligheden har vi bygget ovenpå et jordfaldshul. Det der i virkeligheden sker er, at lige pludselig stopper progressionen i projektet. Man kan ikke længere lave en ny feature, fordi de resterende er så defekte. Man har bygget defekt kode på defekt kode. Så snart nogle retter en fejl et sted, stopper alting. Det bedste man kan gøre som projektleder her, er at skifte job. Hvis man gør det kan man vise at man var med på et succes projekt og lige da jeg stoppede faldt alt fra hinanden – ”men det var jo også min efterfølger der ikke var ret dygtig.” Det der sker er at progressionen går fra at være enormt god til fuldstændig at dykke og man kommer aldrig nogensinde op igen. Når det sker, så vil alle de gode folk der har arbejdet på projektet rejse. De gider ikke længere være en del af det. Dvs. Side 94 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 Det slår projektet ihjel. Hvis man skal have et visuelt billede herpå kan man se på et højhus. Hvis man bygger en etage af gangen og 5. sal bygges skævt. 6 etage bygges ovenpå et skævt fundament og hælder den modsatte vej. I stedet for at rette 5 sal op, tilpasser man altså etage 6 til at kompenserer for fejlen. Hvis der lige pludselig er en der siger: ”Hey – jeg har bygget en ny 5. Sal den sætter jeg lige ind. Den er helt lige!” Så vælter det hele. Det er faktisk det der sker i de her projekter. Først koder man og så tester man. Når man gør det på den måde er man sikker på at man på et tidspunkt bliver ramt i nakken af det. For at undgå det skal man rent faktisk lave refakturering meget tidligere i projektet end man egentligt tror. I nogle af de projekter, hvor jeg hyres ind som midlertidig udviklingsdirektør, der er det tit min første opgave at få sat noget refakturering i gang. Ledelsen siger tit at det vil de ikke betale for, men det er fordi de ikke forstå at de er ved at grave deres egen grav. Når vi starter på de refaktureringsprojekter viser det sig at der går 0,5 år hvor ledelsen er utålmodige, men hvor vi i virkeligheden redesigner hele systemarkitekturen. Lige pludselig er udviklingsafd. Klar til at blæse derudaf. Ofte forstår ledelsen bare ikke at det er noget de skal acceptere. Alle vil gerne have nye features, men ingen vil have at det man har det virker. Det spøjse er at dem der sidder i ledelsen køber gode nye biler. Hvis mekanikeren siger at de skal have fikset bremserne, fordi de ikke virker. Så vil det første de ville gøre at få fikset bremserne. Når det gælder software har de ingen tålmodighed. De vil bare gerne have at bilen bliver om lakeret og så skide være med bremserne. Vi andre vil sige, hvis du ikke kan bremse, skal du nok have bilen lakeret snart igen. 373 Q: Så i tester løbende i hvert sprint? 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 A: Ja, vi tester i hver eneste sprint. I virkeligheden er der en pointe i at teste hele tiden. Altså både bruge testautomatisering, men også, hvis man sidder som udvikler og skriver noget kode, så få en testrapport en time senere. Forskellen i at få den efter en time og en måned er at man allerede er inde i koden. Man skal ikke bruge ressourcer på at finde den frem og forstå den på ny. Man slipper også for at andre i mellemtiden har lavet ny kode man skal tage højde for også. Jeg var til møde i en udviklingsafdelingen forleden. Her finder jeg ud af at de har 11 udviklere til en tester. De vil gerne have mere produktivitet. Min holdning er, en person kan ikke teste 11 menneskers arbejde, heller ikke hvis de laver en form for selvtest først. Hvis man gerne vil øge produktiviteten i den udviklingsafd. Skal man ansætte to testere mere ikke flere der kan kode. Ledelsen, men også udviklerne selv har slet ikke været opmærksomme på det fordi de bare har tænkt, at løsningen på produktivitetsproblemet er at ansætte flere udviklere. Den tester der er, er en kæmpe risiko. Hvis vedkommende bliver syg er der intet der kan deployes. Jeg plejer at sige 1 tester, for hver 3-­‐4 udviklere. Det er radikalt anderledes end hvad it-­‐branchen generelt gør. Men it-­‐branchen gør det bare forkert! Man ved at der i snit er 11 fejl pr. 1000 linjer kode. Det er fair nok! Hvis man selv har skrevet kode, ved man hvor svært det er at gøre det perfekt. Der er hele tiden ting der flytter sig. Vi arbejder 3 mand sammen i et team, som alle skriver noget på koden. Hvem skal gøre hvad og hvordan får vi det fanget. Det nytter ikke noget at hele ens deployment proces er baseret på at der skrives fejlfri kode. Vi ved det ikke er sådan det hænger sammen. Side 95 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 393 394 Q: Mht. levering. Er jeres måde at leverer på at leverer det fra en dag til en anden. Så i bygger hele systemet og kører det indud natten over? 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 A: Hvis du forestiller dig at du skal tegne Mona Lisa. Det kan du gøre på to måder. Du kan lavet nogle fuldstændigt perfekte fliser og bygge maleriet en flise ad gangen. Når den sidste flise lægges på, så har man et komplet maleri. Den anden måde at gøre det på er at man har sådan en papir tegning, en stregtegning. Herefter tegnes hovedlinjerne op lidt bedre. Der lægges bundfarver på og på et tidspunkt er det sidste lag lagt på og man har det komplette maleri. Det er to vidt forskellige måder at bygge på. Det ene kaldes inkrementielt udviklende, hvor der hele tiden lægges noget til og det andet kaldes iterativ udvikling, hvor man hele tiden itererer over det man har lavet. Den rigtige måde at bygge software på er at være inkrementiel og iterativ samtidigt. Når man laver et sprint på 2 uger, som vi har brugt i Gloster projektet, så er det vores opgave hele tiden at lægge noget til, men samtidigt itererer over det vi har lavet. I virkeligheden sker der det at Gloster får en leverance fra os hver anden uge. Noget af det de får er en færdig feature. En anden ting de får er en demo af en feature vi arbejde på, så de kan forholde sig til den og vi kan stille spørgsmål til den og de kan give respons. Vi kan fx bygge en feature, som også er testet. Det kan fx være tilmelding til et nyhedsbrev. Det eneste vi har er feltet og knappen og Submit til campaing monitor. Vi har ikke email validering på. Vi kan godt leverer det i sprintet, fordi de features vi har bygget er 100% færdige. Hele den her user story er bare ikke feature complete endnu. Det er den først når vi har fået bygget de andre ting på. Jo flere afleveringen der er i et projekt inden man åbner det for offentligheden, jo bedre er åbningen overfor offentligheden. Det er en vigtig pointe i at lave agil udvikling. Man får øvet sig mange gange på at afleverer det, inden man rent faktisk afleverer det. 415 Q: Har Gloster skulle omstrukturer forretningsprocessor hos dem? 416 417 418 419 420 A: Ja, de har nærmest ikke skulle gøre andet. De er gået fra at være nogle der kommunikerer gennem tryksager og film, til rent faktisk at interesserer sig for online og begynde at forstå online. Derudover er de begyndt at tænke på, hvordan de fx skal gemme deres billeder så de kan genbruges på tværs. De er i gang med en enorm forandringsproces som varer flere år inden de er færdige med. 421 Q: Konsekvensen bliver så at den måde de gør tingene på nu bliver lavet om? 422 423 424 425 426 427 428 429 A: Den del af arbejdet som de har gjort i årevis, bliver fremadrettet en mindre og mindre del af deres arbejdstid. Det hænger jo så også sammen med at man køber færre og færre tryksager. Man laver ikke længere hustandsomdelte kataloger. For 10 år siden ville Idemøbler udsende et mega katalog, hver eneste år. Det var vi faktisk med til at afskaffe. Vi byggede et helt nyt website til dem, samt en ecommerce løsning blot for det de sparede på porto for at sende kataloger ud. Det der sker er at marketing afdelingen hos Gloster bliver mindre fokuseret på tryksager og kommer til at bruge mere af deres tid på online og det de skal gøre her. Alt det de skal gøre her, skal de skoles i. 430 Q: Så de har set potentialet i det? Side 96 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 431 432 433 434 435 436 A: Ja. Og jeg syntes også at nu er de begyndt at lære hurtigt. Der gik dog lang tid i 2014, hvor vi startede samarbejdet, hvor de prøvede at blive ved med at gøre som de plejede, samtidigt med at de sagde at de gerne ville gøre noget online. De holdt dog fast i at de gjorde tingene på den måde som de plejede. På et tidspunkt omkring nytår gik det op for dem at de også blev nød til at forandre sig. Det har været rigtig godt for projektet, at de startede på den forandring. Men det har været svært for dem. 437 438 Q: Når de forandre sig, gør de det så selv eller giver i dem nogle guidelines til, hvordan de bør gøre? 439 440 441 442 443 444 445 446 447 A: Vi har lært at vi ikke skal fortælle dem hvad de skal. Vi skal være gode til at give dem en ide, og så skal de selv finde retningen. Vores relation overfor Gloster er at stille meget åbne spørgsmål og gøre dem nysgerrige. Hvis ikke selv de føler at de har været med til at få ideen om at det er det de skal, så er det ikke nødvendigvis deres eget ønske. Hvis vi bare siger at de skal gøre sådan og sådan, kan vi ikke få dem til at gøre det. Men hvis vi fx stiller spørgsmålet: ”Hvor mange af jeres online kunder kommer egentligt fra Frankrig?”. Så siger de: ”Vi ved ikke engang om vi har det tal i analytics!” Så kan vi svare, at det tror vi nu nok de har. Skal vi prøve at finde et link til jer så i kan se det tal. Det vil de selvfølgelig rigtig gerne. Så kan vi så spørge, har i tænkt over hvor mange i har i Tyskland. På den måde ruller det stille og roligt. 448 Q: Så i har bygget et værktøj og prøver så at presse dem til at få interessen? 449 450 451 452 A: Det er meget ligesom at opdrage børn. Jeg skal ikke være den der rydder op på barnets værelse, jeg skal få barnet til selv at rydde op på værelset. Det er svært, men man lærer hurtigt at man skal give fredagsslikken når der er ryddet op! Det er den proces man skal ind i, men stadig med respekt for hinanden. De skal selv finde vejen. 453 454 Q: Hvad med mere administrative opgaver, som fx at lægge et nyt møbel ind i systemet. Har i været ude og uddanne dem? 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 A: Ja, det har vi gjort rigtig meget og de har meget svært ved det. Det er blevet mere og mere sofistikeret. De har fået styr på hvordan de lægger nye produkter ind, men det tog rigtig lang tid for dem. Når man arbejder med markedsføring har man ikke samme sans for detaljer, som man har som systemudvikler. Hvis der er en aftale om nogle bestemte farvekoder i systemet, som skal være i produktdatabasen. Så kan det godt være at man skriver at den her stol fås i rød i stedet for at den findes i modeverdenens svar på hvad rød hedder. Problemet er at hvis det de har skrevet i databasen ikke matcher det, som vi har kaldt farven i systemet. Så vil man, når man søger på stolene med den her farve, kun få de tilfælde hvor farven er stavet som den er i systemet. Det kan godt være fejlstavninger, men det kan også være nogle der har skrevet en farve, der ikke er gyldig. Sådan nogle problemer har der været mange af. Dem er vi dog kommet ud af nu. Hver eneste gang der har været et problem med visningen af produkt, har vi fundet ud af at systemet faktisk fungerede godt nok, men at der var en sjuskefejl med datakvaliteten fra deres side. De ar altid startet med at sige: ”Jeres system virker ikke!” og vi har svaret: ”Hvis du nu rettet det her felt og skriver det her i stedet for det der står nu, så vil du se at systemet faktisk virker”. Det er vi ude over nu, men nu skal vi i gang med Side 97 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 470 471 472 473 474 konfiguratoren som er sindssygt kompleks, men bliver fantastisk for brugerne. Så er vi nød til at uddanne dem i hvordan man benytter den. Samtidigt er konfiguratoren forsøgt bygget på en måde, hvor man ikke kan vælge noget som ikke giver mening. Det er rigtig svært, fordi der er en masse i brugergrænse der er lavet af javascript og så skal man tage højde for at det her må du ikke vælge. Det er en svær opgave. 475 476 Q: Dem i har brugt i projektet, som er fløjet hertil. Er det nogle i har udvalgt eller er det nogle de selv har valgt at tage med? 477 478 479 480 481 482 A: Det følger den organisation som de har. De bestemmer hvem de sende og de har en rollefordeling som de følger. Den rollefordeling bliver måske også lavet om i forbindelse med projektet, fordi de finder ud af at nogle folk måske skal opgraderes eller flyttes lidt. Der er masser af nye opgaver hos Gloster, som skal fordeles. Hvem har fx ansvar for de sociale profiler. Alle de ting er opgaver der endnu ikke er fordelt hos dem. Det er dog dem der styrer det hele og vi hjælper de mennesker som Gloster sender. 483 Q: Okay, så i siger ikke at den der står for det og det skal herover. 484 485 486 487 488 489 490 A: Nej. Vi laver en fælles planlægning. Faktisk plejer vi at have skype møde her om fredagen. Det er dog aflyst i dag fordi de to der skal med fra deres afdeling er syge. Normalt i det her projekt har vi skypemøde hver tirsdag og fredag og derudover løbende kommunikation hver eneste dag. Skypemøderne indeholder statusupdate. Det tager typisk mellem 15-­‐30 min og der deltager de mennesker som der er brug for fra vores side. Det kan fx være at jeg, som ansvarlig for levering af konfiguratoren, er med i de første 10 min for at snakke herom. Derefter bliver Jesper som er hovedansvarlig i hele mødet. 491 A: Kommer kunden herover i løbet af senere sprints? 492 493 494 495 496 497 498 499 500 Q: Det er ekstremt at der er så langt mellem os og kunden, som der er i det her projekt. Rent faktisk så er der også nogle fra USA kontoret som flyver til Bristol, når vores man flyver derover om nogle uger. Så folk kommer fra Virginia og flyver herover for at være med til møder. Det er meget seriøst. Hvis det er et projekt, hvor kunden er tæt på, vil man altid have fælles sprintmøder hver anden uge. Her har man et review, der bliver vist ting frem. Man kigger retrospektivt og snakker om hvordan processen kører og man har planning, hvor man planlægger næste sprint. Det er et fast ritual som tager typisk 2 timer. Det kan dog være kortere eller længere afhængigt. Det kan være med 9 deltagere der tager 5 timer. Andre gange tager det 30 min for 3 mand at gennemgå det hele. 501 A: I er meget bevidste om at i bruger Scrum som udviklingsmodel, ikke? 502 503 504 505 506 507 Q: Det gør vi i nogle projekter, men det kræver en vis størrelse. Hvis det er et lille projekt, så gør vi det ikke. Det kunne fx være et projekt, hvor der bagefter er noget vedligehold. Der har vi en agil måde at arbejde på, som bare ikke er Scrum. Det er fordi Scrum er en fastlagt metode med et sæt af værktøjer og metoder. Ift. Scrum er det sådan at man rigtig tit snakker om Scrum, men alligevel ikke helt. Man bruger udvalgte principper herfra. Der findes et begreb der hedder ScrumBut. Det er når man sidder sammen med en udviklingsafdeling og Side 98 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 spørger, hvordan de arbejder. Så siger de: ”We use Scrum, but…” og så begynder de at forklarer, hvorfor de alligevel ikke bruger Scrum. ScrumBut er når man kun gør tingene halvt. Det svarer til at man har halsbetændelse og går til lægen. Han siger at du skal tage din medicin i 14 dage. Man tager så medicinen hver anden dag i 5 dage og siger bagefter til lægen at han godt nok ikke er ret dygtig til at gøre mig rask. Det er udfordringen med Scrum. Det er ikke bare noget, hvor man kan vælge frit fra alle hylder. Der er nogle ting der skal til for at det kommer til at virke. Fx er retrospektivt ofte overset. Man tænker at man ikke behøver at tale om processen. Det man egentligt får ud af at tale om processen er at jeg siger til dig, ”det er noget fin kode du leverede, men næste gang, må du gerne lave et eksempel inden, så du opdager at der lige mangler en enkelt ting.” På den måde slipper man får at der er noget der misser en release dato, fordi udvikleren forsømte at lave tilstrækkelig selvtest inden det blev sendt videre. Hvis man i sprintet har 4 udviklere der begik den fejl og alle submittede koden til test 24 timer før test skulle leverer til Scrum masteren. Så sidder testeren med 32 cases, som alle er lavet utilstrækkeligt. Det er umuligt at nå at teste og fejlrette. Så kikser hele sprintet og det startede egentligt blot med en lille ting som kunne løses ved at holde et retrospektivt møde. Man udlader det tit fordi folk har svært ved at sidde i rundkreds og det bliver tit sådan noget navlepilleri. Det handler simpelthen bare om at vi skal blive gode til at arbejde sammen med hinanden go vi skal undgå at lave fejl.Når man laver Scrum uden at have retrospektivt med, så laver man ikke Scrum! 527 Q: Hvad har i så brugt i dette projekt, har det været stort nok til Scrum? 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 A: For dele af projektet kører vi Scrum. Det vi fx laver på social media, som er noget der starter nu, der kører vi i virkeligheden ikke Scrum. Fordi det i virkeligheden er en redaktionel proces. Der er ikke noget systemudvikling i det. Der bygger vi en backlog og aftale milestones. Vi har en måde at arbejde på, hvor vi hele tiden flytter noget fremad. Men det er ikke Scrum, fordi vi mangler hele det der systemudviklingsaspekt. Så kan man i stedet bruge Kanban. Det har vi også gjort nogle gange. Det er især velegnet til drift. Kanban er meget simpelt. Man har en masse aktiviteter som deles op i faser. Lad os sige at vi er en driftsorganisation og vi har noget der hedder incidents, afklaring, fix, test, godkendelse, deployment og verifikation. Så kan vi dele Kanban kortet op i søjler som lige beskrevet og derefter sætte en begrænsning (en VIP limit – Work in Progress limit) Fx kan det være på deployment, hvor man siger at man aldrig må deploye mere end en ting ad gangen. Så har man de her ting i vores Kanban, og hver eneste gang man gennemfører en aktivitet kan man flytte den hen i næste fase. Så kan man være en stor driftsorganisation som alle ved, hvad der bliver lavet på tværs af alting. På det tidspunkt hvor man kommer dertil hvor man gerne vil have noget deployet. Hvis der i forvejen er en aktivitet i deployment, må man vælge om man vil trække den tilbage, for at føre den anden frem. Eller om man vil lade den klare deployment klare aktivitet vente på at den anden aktivitet har gennemført deployment. Dette fordi man af erfaring ved at hvis man deployer to ting samtidigt, kan det gå galt. På den måde får man noget som ikke har milestones ligesom Scrum. Det er dog stadig agilt og der er en proces for det hele. Det er egentligt det der er forskellen. Kanban er på mange måder ligesom Scrum, men det har ikke Side 99 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 548 549 550 milestones. Det kører bare hele tiden. Derfor er det ofte godt i en driftsorganisationen og Scrum kan være rigtig godt i en udviklingsorganisation. Scrum er typisk meget mere projektbaseret. 551 Q: Okay, så i har brugt Scrum ca. hertil? 552 553 554 A: Gloster projektet er i virkeligheden delt op i ti delprojekter. Nogle af dem kører Scrum og nogle af dem gør ikke. Man kan godt sige om Social Media projektet at det i virkeligheden kører Kanban. Det gør vi dog ikke helt endnu. 555 556 Q: Du snakkede om at i have en buffer i jeres sprints. Arbejder i på andre måder med risikostyring? 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 A: Jo mindre et projekt er, jo mindre er risikoen. Hvis man har et højrisikoprojekt, hvad kan man så gøre for at dele risikoen op. Hvis du fx gerne vil lave en app der kan interagere med rejsekort appen fra DSB. Så ved vi med det samme at alle lamper lyser. Dem hos rejsekortet ved ikke hvordan man laver software og det kan kun gå galt det her. Så kan man lave et forprojektet. Det handler om at finde ud af om der findes et API til rejsekortet og hvordan kan man bruge det? Så sætter man en timebox af på 100 timer og ser hvor langt man kan nå på de 100 timer. Det er nu et lavrisikoprojekt, fordi man ved at man i de 100 timer finder ud af et eller andet, men ved bare endnu ikke hvad. Så har vi også kun sat 100 timer af, det er ikke en kontrakt på 100 millioner med tusindevis af timer. Det næste vi gøre er at vi tager de learnings der kommer ud af de 100 timer. Hvis de ikke har noget API, kan vi så gøre noget andet. Så kan man lave en masse små delprojekter med et afklaret formål og en lav risiko. På den måde kan man afgrænse risikoen ved at undgå at planlægge noget der ikke kan planlægges. Hvis det var sket i Gloster, så måtte jeg sige til direktionen at man ikke kan sige hvor lang tid noget tager. I bliver nød til at få lavet en undersøgelse af hvad det egentligt går ud på og vi vil ikke være med til at leverer det her, for dybest set aner i ikke hvad der er i skal. Så må de forholde sig til det som virkeligheden er. Det er noget af det der mangler i it-­‐
branchen, nogle der tør sige til kunderne at det her kan man ikke sige noget om. 574 Q: Så jeres risikostyring ligger også i at i ikke estimerer noget i ikke ved noget om. 575 576 577 578 579 580 A: Nemlig og vi er meget dygtige til at estimerer. Vi er lynhurtigt til det og typisk kan vi estimerer 1000 timer op 4 timer. Ikke i detaljer, men som et rammeestimat. Jeg vil også garanterer at estimatet det er best in business. Det kan godt være det ikke er 100% perfekt, men vi er fandeme gode til at estimerer. Kom med en opgave der ikke kan estimeres og så skal jeg nok sige at det kan vi ikke estimerer, det er sort magi, glem det! Så må man forholde sig til at man kun får et estimat på det man kan forholde sig til. 581 A: Okay, så det er egentligt et realitetstjek? 582 Q: Ja, det kan man godt sige. 583 A: Hvor mange har i arbejder på Gloster ptojektet? Side 100 af 101 Simon Berg Andersen Stefan Bay-­‐Hahn 584 585 Q: Alt i alt har vi været 15 mennesker involveret, men i meget varierende arbejdsomfang. Nogle med 20 timer, andre med hundredevis af timer. 586 587 A: Kan du komme med en dårlig historie, eller noget som du her på bagkant ville have gjort anderledes? 588 589 590 591 592 593 594 595 596 597 Q: Det er egentligt ikke noget vi ville have gjort anderledes, men jeg ville have været glad hvis Gloster havde været mere modige ift. at gå i luften med websitet på et tidligere tidspunkt. Man er van til at, når man laver en tryksag skal den være 100% perfekt, for man kan ikke lave om i den bagefter. Det her er software, man kan sådan set lave en rettelse dagen efter. De har gang på gang udsat deadline, fordi der lige var noget mere de gerne ville have med. Det gør at den effekt de får af det nye website indtræffer senere. De ville have fået mere for pengene, hvis de havde gået i luften med det tidligere. Nu er havemøbler meget sæsonbetonede, så det når jo i luften til sommersæsonen, så det er fint nok. Men man kan sige, i Australien hade de måske solgt flere møbler hvis de var gået i luften for 0,5 år siden, fordi det var der det blev forår i Australien. Side 101 af 101