Danmarks Tekniske Universitet

Projektledelse (42430)

Projekt: DFDS

Dato: 14/05/2013

I denne rapport er følgende kapitler fra [1] anvendt:

Malsætning (Kapitel 3)

Interessenthandtering(Kapitel 4)

Planlægning(Kapitel 5)

Organisation(Kapitel 6)

Projektlederen(Kapitel 7 og 9)

Kommunikation og forandring(Kapitel 8)

Skrevet af:

Kasper Fønss Bach - s072797

Isa Duran - s083190

Sadik Gok - s093541

Simon Benfeldt Jørgensen - s103182

Sune Thonesen - s072721

Tanja Gyde - s113199

Ulrik Uhre Brink - s081830

1

Indhold

Indledning 3

1 Malsætning 41.1 DFDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Perspektivering til teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Delkonklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Interessenthandtering 72.1 Generel beskrivelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Perspektivering til Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Delkonklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Planlægning 93.1 DFDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Projektplanen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3 Delkonklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Organisation 134.1 DFDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Perspektivering til teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3 Delkonklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Projektlederen 155.1 Rekruttering af gruppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2 Arbejdet med projektet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.3 Planen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.3.1 Styring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.3.2 Opfølgning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.4 Delkonklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6 Kommunikation og forandring 186.1 Kommunikation i DFDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186.2 Teorien bag forandring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186.3 Fejl i kommunikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196.4 Malrettet kommunikation, Branding og kommunikation der understøtter

forandringer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.5 Delkonklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Kildekritik 21

Konklusion 216.6 Egne erfaring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Logbog 24

A Bilag 26

B Bilag 27

2

Indledning

DFDS A/S

I aret 1866 fusionerede tre daværende damskibsselskaber sammen til en virksomhed, somfik navnet DFDS A/S (Det Forenede Damskibs-Selskab). Siden 1866 har DFDS væreinvolveret i national savel som international fragt- og passagertransport. Geografisk liggerDFDS´ shipping aktiviteter hovedsageligt i nordeuropæisk farvand med over 25 ruter ogen flade pa over 40 skibe.

Projekt SERTICA

I 2009 blev DFDS gennemgaet af eksterne konsulenter, som havde til opgave at kom-me med forslag til, hvordan DFDS kunne blive optimeret. De foreslog blandt andet, atden tekniske drift af skibene blev samlet i et fælles IT-system. Situationen var den, atder i teknisk afdeling blev brugt hele fire forskellige systemer i den daglige drift. I slut2009 stod den tekniske afdeling over for udfordingen at udvælge det system, der bedstkunne leve op DFDS´ krav. Der blev udvalgt tre forskellige leverandører, der alle kunnelevere en færdig grundpakke men, som ogsa havde mulighed for, at DFDS kunne fa la-vet specielle funktioner til systemet. Valget faldt pa leverandøren Logimatic med deresfleet management system ved navn SERTICA. Efter valg af leverandører stod tekniskeafdeling sammen med Logimatic over for den store udfordring, at fa skabt et ordenligtsystem, der kunne bruges mange ar frem i tiden. Derudover skulle det hele implementerespa over 35 skibe uden, det pavirkede skibenes kommercielle arbejde. Til sidst skulle altpersonale uddannes i brugen af programmet. SERTICA-projektet vil blive betegnet somet IT-projekt, men det er en stor del af vejen ogsa et forandrings-projekt pa grund af denstore organisatoriske pavirkning. I resten af denne rapport vil det omtales som SERTICAeller projektet.

Projektlederen

Vi har gennem dette projektforløb haft to interviews med Jakob Steffensen. Jakob haringen projektlederuddannelse men er blevet projektleder pa projektet efter at have enbaggrund som skibsfører. Som person er Jakob energisk og brænder for det, han laver,og var meget glad for at vi stillede ham spørgsmal, som var relateret til teorien. Efterprojektet er endt har Jakob faet meget ros for at køre projektet pa hans made med pro-jektgruppen. Inden interviews havde vi forberedt spørgsmal ud fra teorien i bogen, hvor viblandt andet benyttede os meget af de opsummerede spørgsmal sidst i kapitlerne. Desu-den var Jakob meget behjælpelig med fremskaffelse af dokumentation omkring projektet.Herfra omtales Jakob Steffensen som projektlederen.

3

1 Malsætning

1.1 DFDS

DFDS har en klar strategi om at vækste, og med mange skibe og en række havnetermi-naler, var der brug for et nyt overordnet it-system, som positivt kunne støtte op omkringderes vækststrategi som Kasper Moos fra Teknisk organisation forklarer i bilag A. Sombeskrevet i indledning brugte teknisk afdeling fire IT-systemer til den daglige drift. Ud afde fire systemer var der kun to, hvis data blev replikeret ind til land. Manglen pa data-replikering gjorde det svært for inspektørerne at skabe et overblik over driften pa skibene,samt tjekke om tingene blev udført korrekt. Den manglende datareplikeren gjorde detogsa umuligt at kunne sammenligne skibenes interne performance rent økonomisk. Detoverordnede mal var derfor, at fa skabt et overblik over den nuværende situation, samtat fa samlet de fire eksisterende systemer til et samlet system, som skulle rette op pa defejl, der var fundet, samt at optimere op omkring vækststrategien.

Et delmal i projektet var datavask, hvor al data blev vasket rent og navngivet efter nyestandarder. Pa denne made ville gamle og forskellige benævnelser pa eksempelvis motorerblive navngivet pa samme made. Et eksempel pa dette var, at en hovedmotor i et systemhed f.eks.

”610“, hvor det i et andet hed

”ME“1.

Et andet mal for systemet var, at det skulle kunne fungere pa alle skibe selvom der ikkevar en internetopkobling. Projektlederen forklarer i bilag A, at samtlige skibe hos DFDShar internetforbindelse og er derfor i princippet altid online. Der kan dog forekomme smaudfald, langsomme forbindelser og dermed timeout. Det nye system skal derfor ikke væreafhængig af en forbindelse med en oppetid pa 100%. Systemet skal derfor bygges pa ensadan made, at nar der ingen internetforbindelse er, sa bliver data gemt lokalt pa skibetog synkroniseret med land, sa snart der igen er forbindelse.

Det tredje mal og en meget væsentlig parameter for DFDS er brugervenligheden. Herforklarer Thomas Mørk, Director of Marine Standards i bilag A, at programmerne, sommedarbejderne om bord pa skibene skal anvende, skal være nemme og enkle at anvende,sa arbejdstiden bliver optimeret og dermed undgar spildtid. Jo bedre de enkelte systemerer skræddersyet til medarbejdernes behov, jo bedre udnyttelse far de ogsa af dem.

Projektleder Jakob Steffensen forklarer i et interview, at de anser projektet som væren-de en succes idet følgende emner er veludført:

• Implementering af systemet pa samtlige skibe i DFDS

• Data er blevet vasket rent og er af ens navngivning

• Systemet lever op til de ønsker, som tidligere er defineret

• Alle medarbejdere skal være bekendt med brugen af systemet

Idet det nye system helt skulle erstatte de fire eksisterende systemer, var der ingensynlige krav til hvordan det nye system skulle kommunikere med de eksisterende. Deri-mod skulle det nye system fungerer i samarbejde med deres nuværende kommercielle- ogindkøbssoftware.

Det er alment kendt, at der i større projekter bliver udarbejdet en kravspecifikation,som beskriver kravene til systemet ned til den mindste detalje. I forbindelse med detteprojekt blev der ikke udarbejdet en decideret kravspecifikation, men derimod en formfor guidelines, der i brødtekst beskriver hvordan systemet skal arbejde. Derudover er derudarbejdet flowdiagrammer for hvordan systemet skal arbejde og samarbejde med deneksisterende software osv.

1Main Engine

4

1.2 Perspektivering til teori

Nar der pabegyndes et nyt projekt, uanset størrelse, sa er en af de helt store udfordrin-ger, at fa udarbejdet en malfast og klar malsætningen. Jf. teorien [1, s. 87] ved vi, atmalsætningen skal være velkendt for samtlige deltagere i projektet pa en sadan made,at alle deltagere i projektet har kendskab til malsætningen, men ogsa for at skabe op-bakning fra de vigtigste deltagere, herunder ledelsen og projektejerne. Hvis projektetundervejs skulle begynde at skride, sa er det vigtigt, at deltagerne kan kigge tilbage pamalsætningen for at fa projektet tilbage pa sporet igen.

Jf. teorien omkring malsætningen, sa skal malsætningen opdeles i tre typer af mal. Herhar projektlederen ramt teorien præcist, idet projektejeren først har udarbejdet formalmed projektet. Herefter var det sa projektlederen og den valgte projektgruppes opga-ve, at kunne beskrive de sidste to typer af mal, herunder de leverancer de skal levere iprojektforløbet, og til sidst effekten af de succeskriterier for de afsluttede leverancer.

En ting man fra teorien kunne savne i projektet, var anvendelsen af projekttrekanten(figur 1). Projekttrekanten illustrerer aftalen mellem projektejerne og projektgruppen iform af tre punkter - ressourcer, leverancer og tid. Under projektet stod projektejer formængden af ressourcer til radighed og projektgruppen for at levere de aftalte leverancerinden for den aftalte tid. Hvis et eller flere af projekt-trekantens tre punkter skulle ændres,sa skal man jf. teorien genforhandle den aftalte kontrakt. Hvis man fulgte teorien ogprojekttrekanten sa ville man have faet et overblik over, at bade tiden og leverancernevar fastlagt, men at man i løbet af projektet kunne ændre ressourcerne og dermed ændreprojekttrekanten.

Figur 1: Projekttrekanten

Nar en malsætning skal udarbejdes er det vigtigt, at brainstorme omkring emnet ogfor hvert mal man finder, far oplyst hvorfor man skal gøre det, og hvordan man gørdet. Jf. teorien omkring udarbejdelse af et malhierarki [1, s. 101] ved vi, at netop dettevil give et større overblik over projektet som helhed og forøge indsigten i de forskelligedelmal. De burde, jf. teorien, have først opstillet det overordnede mal og spurgt dem selv,

”hvordan opnar vi dette?“. Dette ville sa have givet dem de første delmal, som ville løse

det overordnede mal. Herefter kan disse delmal blive udspecificeret ved igen at spørge indtil, hvordan de opnar disse delmal.

Det er illustreret pa figur 2 hvordan et malhierarki kunne se ud, hvor der er tagetudgangspunkt i det eksisterende overordnede mal og delmal. Ved vækst og optimeringhar vi spurgt os selv, hvordan man vil opna det, og det kan man opna eksempelvis vedbedre gennemsigtighed og mere effektive arbejdsgange. Dette er sa gentaget for de tofundne delmal, som resulterer i de tre eksisterende formal som DFDS ogsa var kommetfrem til. Det endelige malhierarki viser netop et udpluk af formalene over stregen og detder skal leveres (nyt IT-system) under stregen.

5

Figur 2: Eksempel pa et malhierarki

Det er vigtigt for enhver deltager i projektet, at malsætningen samt de enkelte delmaler defineret sa præcist som muligt, saledes at der er fokus pa opgaven og at den ikke læggerop til diskussion. Vi ved jf. teorien [1, s. 109], at malsætningen skal være S.M.A.R.T - spe-cifik, malbar, accepteret, realistisk og tidsfastsat. De forskellige delmal i projektet er ikkesærlig specifikke, og der kan derfor lægges op til en diskussion om, hvordan man planlæg-ger sig frem til en løsning. Delmalene ma antages at være malbare, idet de efter projektetsafslutning, faktisk kunne følge samtlige skibe og skabe sig et overblik. Delmalene var ac-cepteret af de vigtigste deltagere af projektet, herunder ogsa projektejerne, som hele tidenblev underrettet omkring projektets gang. Malsætningen og delmalene ma siges at væreyderst realistiske givet, at de undervejs i projektet kunne fa flere ressourcer til projektar-bejdet, for at na den til dels fastsatte tidsplan. Hvis delmalene var helt urealistiske at na,ville det ikke skabe motivation blandt deltagerne i projektgruppen, det har dog ikke værettilfældet her. Delmalene har gennem projektet været tidsfastsat, men hvis projektgruppenhar oplevet tilbagegang pa et delmal, sa har man flyttet om pa arbejdsopgaver, saledesman hele tiden har kunnet na deadline for det enkelte delmal. Hvis delmal blev forsinkede,ville det givetvis have ændret pa den planlagte malsætning, hvis man antageligvis ikkehavde kunnet løse et delmal.

1.3 Delkonklusion

For at opsummere pa malsætningen, der blev udført i forbindelse med projektet, sa skinnerdet igennem, at projektlederen ikke har en baggrund inden for projektledelse, men doghar en indgaende kendskab til DFDS og hvordan hele virksomheden arbejder sammen.Det ses pa den made hvorpa malsætningen er blevet fastlagt, da den anses for megetløs og ikke særlig specifik. Især den manglende kravspecifikation kan fa ethvert projekttil at fejle, idet man nemt overser sma detaljer, som kan eskalere og ende op som størreproblemer.

Hvis man havde fulgt teorien jf. projektledelse og havde udarbejdet et malhierarki samtanvendelsen af S.M.A.R.T, ville de være endt op med en meget mere præcis malsætning.Anvendelsen af et malhierarki havde givet dem et større overblik over projektet og dermedgivet mulighed for en mere præcis og gennemarbejdet malsætning. Sammensat med enS.M.A.R.T malsætning, ville den endelige malsætning have fokus pa det arbejde, derskulle udføres, og ikke lægge op til diskussion, om hvordan opgaverne skulle løses.

Selvom malsætningen fra deres side har været relativ generel, har projektlederen stadigformaet at kunne forventningsafstemme projektet for projektejerne, og vise vejen gennemprojektet for projektgruppen.

6

2 Interessenthandtering

2.1 Generel beskrivelse

I forbindelse med projektet var der ikke blevet udarbejdet en interessentanalyse fra pro-jektlederens side. Vi har gennem vores møder med projektlederen kunne udarbejde enliste over interessenter samt deres medvirken og indvirken pa projektet. Fordelen ved atudarbejde denne analyse er, at det vil skabe et overblik over, hvem der har en højereprioritet og pa denne made finde frem til de vigtigste interessenter og om disse er tilfredsemed projektet. Interessenterne er valgt ud fra interviews og beskrivelse af projektgruppen.Der er nogle interessenter som er mere overordnede, hvor man igen kunne dele dem op isegmentering af interessenterne, men i dette projekt er interessenterne blevet afgrænsettil tabel (1).

2.2 Perspektivering til Teori

Interessent analysen kan bidrage til fire hovedpunkter som beskrevet [1, s.117]: malformuleringen,risikoanalyse, organisering og kommunikationsplanen. Til analysen bliver der anvendt te-orien fra bogen, som indeholder fire trin for udarbejdelse af en interessentanalyse.

TRIN 1: Her tegnes landskabet op af interessenterne

Type Interessent Beskrivelse af interessent

Opgavestiller Projekt ejer: Kasper Moos Kasper Moss har ansvaret for projektet.

Opgavestiller DFDS ledelse Ledelsen

Intern Medarbejdere Medarbejdere, dækker over de ansatte som er idriften.

Intern Superbrugere Her er oftest tale om en overstyrmand som kenderIT-systemerne pa skibene rigtig godt.

Intern Afdelingsledere Lederne i f.eks. IT, Marine osv.

Intern Skibe med mandskab DFDS rader over 38 skibe.

Eksterrn Analyse Konsulenter Konsulenter som har ekspertise i PMS og somhar en en viden om skibstransport var med til atvurdere atSertica var den bedste løsning.

Eksterne Andre rederier Da DFDS er en del af MÆRSK var de ogsa re-præsenteret.

Projektgruppen Data Team Holdet som kan datavaske fra tidligere systemer.

Projektgruppen Maritime Dækker over repræsentanter for de 4 test-skibe:Begonia,Pearl, Petunia og Ficaria.

Projektgruppen Supply Chain Management Stefan Nielsen (SCM)

Projektgruppen IT Chris Mason (DFDS IT Projektleder) og RasmusHansen (Logimatic Projektleder - leverandør)

Tabel 1: Interessenter

TRIN 2: Her er formalet at prioritere interessenterne ud fra indflydelse og medvirken.Denne indflydelse/medvirken matrix har fokus pa de vigtigste interessenter i projektet, ogbaseret pa deres indflydelse samt medvirken til projektet, er de blevet tilføjet i matricen.Herefter er det muligt, at kunne fa vist hvem der er størst prioriteret, for pa den madeat projektlederen har helt styr pa hvem der er at gøre med og pa den made eksempelvisoptimere kommunikationen.

7

Baseret pa de fundne interessenter fra Trin 1, har vi kunnet bestemme deres indflydelseog medvirken i forbindelse med projektet, hvilket er illustreret i følgende indflydelse/medvirken-matrix:

Figur 3: indflydelse/medvirken-matrix

TRIN 3: Her er formalet at danne sig et bedre overblik over, hvordan de vigtigsteinteressenter forholder sig til projekt og mest vigtigt, hvad man kan forvente de bidragermed. En interessent kan bidrage bade med positive og negative input til projektet, beggeer velovervejet i dette trin.

For hver interessent har vi vurderet og undersøgt deres interesse i forhold til projektetsamt deres fordele og ulemper iht. projekt Sertica ved bruge svarene fra Jacob til følgendespørgsmal:

• Hvad er deres interesse i projektet?

• Hvordan er deres indstilling mht. projektet?

• Hvad er motiv og malet for interessenten i forbindelse med projektet?

• Hvad bidrager interessenten med? Herunder bade positive samt negative bidrag.

Baseret pa disse har vi kunnet udarbejde en samlet vurdering, samt hvordan man børhandtere kommunikationen med interessenterne, saledes de opretholder en overvejendepositiv indstilling til projektet.

Tabellen i bilag B afspejler kun de aller vigtigste interessenter, da de findes mestgivende at lave analyse pa.

TRIN 4: Da dette er en analyse efter at projektet er endt, sa nævnes her de vigtig-ste opgaver som projektet har gennemgaet: Der er ingen tvivl om at kommunikationenmellem Logimatic, som er den eksterne leverandør og DFDS’s projektgruppens IT ogData-Team, har været en vigtig del for at projektet fik de løbende krav opfyldt. Hvisman havde ansat flere mand til Datateamet og IT-teamet og eventuelt opdelt dem i seg-menteret grupper med en ansvarlig person for indkøbsdelen i starten af projektet kunneintegrationen mellem indkøb og sertica maske havde lykkedes.

2.3 Delkonklusion

Hvis projektlederen havde udarbejdet en interessentanalyse, sa kunne Sertica-projektetsinteressenter fra start havde haft en klar ide om hvem der var de vigtigste og mest indfly-delsesrige, hvilket kunne have gavnet specielt data-teamet men ogsa for at give ledelsenet overblik over hvem der var med i projektet.

8

3 Planlægning

Projektplanen er et af de vigtigste redskaber i et projekt. Projektplanen er et redskab derbruges til at give en ide om hvor projektet burde være pa et givet tidspunkt. Grundlæg-gende skal planen skabe overblik og systematik i fremgangsmaden og dermed en forstaelsefor projektets sammenhænge. Planen bruges ogsa som kommunikationsmiddel, der skalinformere bade ledelse, interessenter og projektdeltagere om, hvad der ligger forud, hvader status, kritiske datoer osv. God planlægning er selvfølgelig en forudsætning for ordenligstyring og opfølgning i projektet, og i dette kapitel vil DFDS´ handtering af planlægnin-gen blive sammenlignet med korrekt projektledelses planlægning med udgangspunkt i [1,s. 145-201].

3.1 DFDS

Som nævnt tidligere er projektlederen for dette projekt ikke uddannet projektleder, ej hel-ler har han deltaget i nogen form for projektlederuddannelse. Projektet er derfor blevetstyret udelukkende ved brug af erfaring fra tidligere opgaver/projekter. Projektplaneni dette projekt blev lavet pa en workshop, hvor hele projektgruppen var samlet, der-udover var der et par repræsentanter fra leverandøren af softwaren. I samarbejde medleverandørerne (som havde erfaring fra et lignende projekt tidligere), lavede projektgrup-pen en 1-arig gantt-tidsplan2 baseret pa deltagernes erfaringer og estimater. Gantt-planenindholdte tidsvinduer for hvornar der skulle arbejdes med programmeringen, udvikling afspecielle DFDS-funktioner, installering pa skibe, implementering og træning af personaleosv.

Figur 4: DFDS´ projektplan

2Værktøj 5.4 fra CD i [1]

9

3.2 Projektplanen

I bogen [1, s. 149] nævnes der ti overordnede krav til den gode projektplan:

• Er udarbejdet af projektdeltagerne for at skabe kvalitet og accept.

• Skaber fælles forstaelse og accept af fremgangsmaden.

• Viser sammenhængen mellem slutleverancerne og vejen til at na dem.

• Sammenhæng mellem leverancer, den enkeltes indsats og ansvar skal sta klart.

• Skal kunne anvendes til opfølgning og styring pa flere niveauer, ogsa indga i program-og portføljeledelse.

• Er opdelt i niveauer sa det vigtigste kan være pa en A4-side.

• Skal være robust over for erkendte usikkerheder, sa den ikke hele tiden skal justeres.

• Skaber intensitet og tempo i projektet.

• Viser hvornar store risici og beslutninger skal afklares.

• Ma kun have en kritisk vej.

For at sikre at en projektplanen lever op til disse krav, foreslar [1, s.149] at projektplanenopbygges pa følgende made:

1) Opdeling af projektet i indsatsomraderNar en projektgruppe sætter sig ned og sammen skal skabe en projektplan for et nytprojekt, er det malsætningen oftest det eneste der er fastlagt sa tidligt i projektstadiet.Malsætningen er som regel opdelt i en form for malhierarki hvori der er bestemt forskelligeleverancer. Det første trin i planlægningsprocessen er derfor at bestemme, hvordan pro-jektet kan opdeles i nogle hovedopgaver med udgangspunkt i disse leverancerne (se figur5) - de opdelte hovedopgaver bliver ogsa kaldt indsatsomrader. Fordelen ved at opdeleplanen i indsatsomrader er, at det giver en god struktur pa projektet og at hver ind-satsomrade kan være et ansvarsomrade for en delprojektleder. Indsatsomrader er oftestinddelt i fagomrader f.eks. programmering, budgettering og dokumentering, hvis det eret IT-projekt eller murerarbejde, tømrerarbejde og VVS hvis det er et byggeri projekt.

2) Definition af milepæle indenfor det enkelte indsatsomradeDet næste skridt af at bestemme hvilke delresultater der skal opnas i hver enkelte indsats-omrade før at det er muligt at levere de tilhørende leverancer. Delresultaterne, som kaldesmilepæle, er fastlagt pa et bestemt tidspunkt og kan være en rapport, en beslutning, engennemført analyse, en afklaring, en godkendelse, et velfungerende testresultat, et nytdesign, en bruger accept, osv. Kort sagt er en milepæl altid et resultat som kan malesom det er naet eller ej. Grunden til at der bruges milepæle istedet for aktiviteter, er atmilepæle fokuserer pa hvad der skal være opnaet, istedet for at fokusere pa hvordan detopnas. Milepæle er derfor ogsa mere robuste overfor ændringer end aktiviteter. Milepælekan som nævnt altid males om de er naet eller ej og netop den egenskab gør at de let kanbruges til at følge op pa, hvilket ogsa var hele meningen med projektplanen. Pa figur 6 ermilepælene angivet for hver eneste indsatsomrade i form af en trekant.

3) Definition af afhængigheder mellem indsatsomraderEn ting er at definere de enkelte milepæle i hvert enkelte indsatsomrade, en anden ting erat de forskellige indsatsomrader sjældent kører helt uafhængigt af hinanden i et projekt.Det sker ofte at en milepæl ikke kan opnas før en milepæl i et andet indsatsomrade er

10

opnaet - f.eks kan elektrikerne ikke trække ledninger i et byggeri før, at murerne har byg-get selve huset. Det er derfor vigtigt at der skabes et overblik over hvilke milepæle der erafhængige af hinanden saledes, at projektplanen let kan bruges til styring af projektet. Pafigur 6 ses pile imellem nogle af milepælene (trekanterne). De indikerer hvilke milepæleder skal udføres før at de selv kan udføres.

4) Opdeling af planen i faserNar indsatsomrader, milepæle og afhængigheder alle er blevet bestemt, skal projektetopdeles i forskellige faser. Opdelingen i faser har til formal at dele projektet op i noglerelevante hovedafsnit rent tidsmæssigt. Projektet skifter fase, nar opgaven skifter karak-ter, f.eks. er der ofte en analyse fase i starten af projektet efterfulgt af en design fase ogtil sidste en afsluttende fase hvor alle terminer skal falde pa plads. Faserne introduceresogsa for at give ledelse m.m. mulighed for at følge projektet pa overordnet niveau. Detbemærkes at faseskift kan ske pa forskellige tidspunkter i forskellige indsatsomrader. Op-deling af faser kan ses pa projektplanen pa figur 6

5) Fastlæggelse af væsentlige beslutningsmøderVæsentlige beslutnings møder fastlægges, som minimum, til at ligge ved faseskift. Beslut-ningsmøderne bruges grundlæggende til at styregruppen kan give accept til at projekteter foregaet som forventet og at de nu kan starte pa den næste fase. Derudover kan beslut-ningsmøderne ogsa bruges til at træffe beslutninger, der ikke var mulighed for tidligerepga. manglende viden i projektet.

6) Definition af aktiviteterAktiviteterne for at opna de forskellige milepæle skal nu defineres. Som sagt er milepæledelleverancer, de skabes af aktiviteter. En milepæl kunne være at der skal et gulv skullevære støbt i et byggeprojekt. For at opna den milepæl skal skal der udføres en masseteknisk arbejde(opmaling, blanding af støbemateriale, etc.). Det tekniske arbejde vil savære aktiviteterne der skulle planlægges i dette tilfælde. De nødvendige aktiviteter for atopnar hver enkelte milepæl i projektet defineres.

7) Estimering af tidsforbrug i aktiviteterneNar aktiviteterne er blevet defineret skal tidsforbruget af hvert enkelte aktivitet estimeres.Der skal vurderes hvor lang tid hver enkelte aktivitet tager, hvor meget det koster, osv.Estimeringen skal ogsa hjælpe projektlederen og deltagerne med at fa et billede af, hvilkeaktiviteter der er usikre i projektet, og hvor det kan ga galt.

8) Risikoanalyse og justering af planenTil sidst skal der udføres risikoanalyse pa projektet. Hvad er de ti vigtigste risici pa nu-værende tidspunkt? Hvad skal man undga sker og hvordan? osv. Meningen med risikoanalyse er at give indsigt i projektet og de kritiske elementer, samt gøre projektplanenmere robust.

11

Figur 5: Indeling af projektet i indsats-omrader Figur 6: Projektplanen

3.3 Delkonklusion

Det ses at projektet i DFDS ikke har fuldt den samme teori som beskrevet i litteratu-ren brugt i denne rapport [1]. Den projektplan der er brugt i projektet er en sakaldtgantt-plan. Gantt-planen er en form for søjlediagram der viser datoer for start- og slut-tidspunkter for de forskellige delopgaver i projektet. Gantt-planen har den ulempe, at dener svær at bruge til løbende opfølgning af projektet, da hver delopgave kun har et start-og et sluttidspunkt, og ingen malpæle derimellem. Dvs. hvis projektgruppen afholdte etstatusmøde mellem et start- og sluttidspuntet i en delopgave, var det ikke muligt forgruppen at male hvor langt de var i projektet. Derudover besværliggør det ogsa kom-munikationen op til ledelsen, idet ledelsen ikke løbende kan se hvordan projektet kører.Projektlederen vil derfor være nødsaget til at forklare og argumenter for projektets statusi stedet for bare at sende et par malbare milepæle op til ledelsen. Generelt er den størstefejl i planlægningen hos DFDS, at de har brugt tidsvinduer istedet for malbare milepæle.Ved at bruge milepælbaseret planlægning ville dokumentationen og rapportering havdeværet væsentlig lettere for projektlederen.

12

4 Organisation

Det er ligegyldigt hvor godt malsætningen og projektplanen er lavet hvis der ikke liggerden rette organisation bag projektet. En virksomheds normale organisationsstruktur erdesignet til at løse driftsopgaver med stor præcision og effektivitet. Men et projekt erikke en standard driftopgave, men derimod en tidsbegrænset udviklingsopgave, som oftepa tværs af afdelinger og fagomrader i en organisation. En organisation, der understøtterhver enkelt projekt optimalt, er derfor fundamentalt for at et projekt opnar succes. Pro-jektorganisationen skal derfor være designet til det enkelte projekt. Organiseringen af etprojekt er en af de mest afgørende opgaver i opstartsfasen, da det er her at de helt rigtigepersoner skal involveres i projektet pa den mest hensigtsmæssige made.

4.1 DFDS

Til dette projekt blev der oprettet en separat projektorganisation, som havde til opgaveat sikre optimale forhold for projektet. Projektejeren Kasper Moos, som er chef for tek-nisk afdeling, valgte projektlederen, som derefter valgte projektgruppen ud for personligeerfaringer og abenhed over for et nyt projekt. Projektets organisation er opbygget medKasper Moos øverst, derefter kommer projektlederen med fire undergrupper under sig.De fire undergrupper er: PMS manager, Marine, IT og SCM. PMS manageren, hvis jobvar at oplære andre medarbejde i SERTICA, havde et hold pa fem personer under sig,som udelukkende skulle beskæftige sig med datavask. Marinegruppen bestod af kaptajner,maskinmestre samt inspektører fra forskellige skibe, og havde til opgave at fa input frade fremtidige bruger af systemet. IT gruppen bestod af en IT-projekt manager fra DFDSog en projekt manager fra Logimatic som star bag grund softwaren til SERTICA. SCMgruppen bestod af to folk fra supply-chain-management-afdelingen hos DFDS, og havdetil formal at fa indkøbsafdelingens syn pa programmet, da det var planlagt at skibeneskulle kunne købe ind via SERTICA. Hele projektorganisationen kan ses pa figur 7. Rentpraktisk var der ikke forskel pa hvilken gruppe de var i, da alle var med til de vigtigemøder. Gruppernes opdeling er udelukkende for at give et overblik over repræsentationeni projektgruppen.

Figur 7: Organisering af projektet

4.2 Perspektivering til teori

For at en projektorganisation kan præstere optimalt er der visse grundregler der skalvære opfyldt: 1) Organisationen skal være beslutningsdygtig pa rette niveau. Det vil sigeat projektejeren skal være pa et vist niveau i firmaets organisation, saledes at han harrettigheder til at trække de vigtige beslutninger i projektet. 2) Kunne levere ressourcertil projektet. Folk øverst i projektorganisationen skal være i stand til at kunne allokere

13

ressourcer til projektet. 3) Vær faglig kvalificeret. Deltagerne i projektgruppen skal ha-ve de nødvendige faglige kvalifikationer. Der er ingen grund til at have ikke-kvalificeredemedarbejdere i projektgruppen. 4) Sikre involvering af interessenter. Det er vigtigt at in-volvere vigtige interessenter i projektet, saledes at der sikres opbakning omkring projektetog interessenterne føler ejerskab.DFDS har ubevist opfyldt hver eneste af de grundlæggende krav til en god projektorga-nisation. De har en projektejer, i form af Kasper Moos, der er chef for teknisk afdeling oger i stand til at trække de nødvendige beslutninger i projektet. Derudover er han i standtil at allokere nødvendigt mandskab eller penge hvis dette bliver nødvendigt, selvfølgeligtil et hvis niveau. Projektorganisationen bestar af en fagligt kvalificeret projektleder, derved præcis hvad han vil opna med projektet. Projektgruppen af faglig kvalificeret med-arbejdere i form af kaptajner, maskinmestre og inspektører med mange ars erfaring i denoperationelle drift. Derudover er der ogsa en repræsentant fra Logimatic, der har erfaringfra tidligere lignende projekter. Organisationen er desuden blevet samlet saledes at derer involvering fra fremtidige brugere af systemet, nemlig marine gruppen. Det skal dognævnes er der mangler involvering af ledelsen i DFDS.Selve opbygningen af projekt organisationen ligger ogsa tæt op af modellen fra [1] somses pa figur 8. Hvis der skulle tilføjes eller ændres noget pa projektets organisations dia-gram, ville det være at sætte ledelsen øverst, saledes at der ikke er i tvivl om hvem derer den ultimative øverste i organisationen, idet ledelsen ugentlig fik mail opdateringerfra projektet og derfor burde være pa organisationsdiagrammet. Derudover var projektetforholdsvis lille set med DFDS øjne, og derfor var det ikke nødvendig med en styregruppe,idet projektet næsten udelukkende involverede teknisk afdeling.

Figur 8: Projektorganisationens roller og beslutningsstruktur

4.3 Delkonklusion

Overordnet set har DFDS fuldt teorien omkring organisering af projekt i [1] til næstenpunkt og prikke. De har fra start defineret en projekt ejer samt projektleder saledes,at der ingen tvivl var i projektgruppen. Derudover var der defineret en projektgruppe idetaljer, saledes at projektejeren havde et overblik over deltagere i projektet. Projektetvar et forholdsvis lille projekt, og det er derfor svært at kommentere manglen pa referencegrupper og styregruppe, idet det umiddelbart ville være unødvendig i sadanne projekt.

14

5 Projektlederen

Nar et projekt skal søsættes, er det vigtigt, at det styres i den rigtige retning. Projektle-deren skal derfor fungere som skibets kaptajn og sørge for, at skibet nar dets destinationinden for de fastlagte rammer. Som kaptajn skal han derfor udvælge de rette personerat have med ombord og kunne tage beslutninger, hvis der er behov for at ændre kursundervejs.

5.1 Rekruttering af gruppen

Hvis et projekt skal lykkes er det vigtigt, at det er de rette folk pa opgaven, men de rettefolk kan ikke bringe skibet sikkert i havn alene. De er nødt til at arbejde sammen. Derforer det vigtigt, at projektlederen formar at sammensætte et team, som bade er fagligtdygtige og som sammen kan gennemføre projektet.

Hos DFDS er projektleder Jakob Steffensen udpeget af DFDS’ ledelse. Han har, eftermøde med ledelsen om malet for projektet, faet forholdsvis frie hænder til at sammensætteen projektgruppe til implimentering af det nye IT-system. Der er derfor blevet afholdtsakaldte hyggedage, hvor folk fra de involverede afdelinger hos DFDS har deltaget. Her harprojektlederen haft mulighed for at tale med de personer som gerne ville deltage i projektetsamtidig med, at han har kunne vurdere, hvordan de enkelte gar i spænd med hinanden.Som udgangspunkt har det været vigtigt for ham, at projektgruppen bestar af personersom er open minded over for projektet, da implimenteringen af SERTICA ikke kun er etIT-projekt men ogsa organisatorisk forandrende. Af denne grund er gruppen valgt til atbesta af blandt andre IT-folk, søfolk, folk fra indkøbsafdelingen samt de repræsentanterfra Logimatic.

Set fra et teoretisk synspunkt har rekutteringen af denne gruppe foregaet efter bogen.Jf. teorien [1, s. 318] er opstartsfasen i projektet vigtigt for, hvordan resten af projektet vilforløbe. Som projektleder er det derfor væsentlig at det er de rigtige folk, der udvælges tilopgaven. Hos DFDS har projektlederen selv valgt sin gruppe og dermed ikke faet tildelten række personer af ledelsen. Dette betyder, at han selv har haft mulighed for udvælgefolk, der dels er fagligt dygtige og dels har kunne fungere godt i gruppen.

5.2 Arbejdet med projektet

Nar først projektet er igang, er projektlederens vigtigste opgave at holde styr pa alleimplicerede parter. Han skal sørge for at holde sammen pa gruppen, saledes at alle føler,at de er en del af projektet, sa skibet følger den fastlagte kurs og nar sikkert i havn tilrette tid.

For at opna det mest effektive samarbejde hurtigst muligt er der hos DFDS valgt, atprojektgruppen er taget ud af den daglige drift saledes, at deltagerne har kunne fokuserepa projektet og arbejde fuld tid. Derudover har der været afholdt workshops af fa ugersvarighed samt seminarer hos leverandøren af SERTICA. Alle disse indledende øvelser ermed til at forkorte den process en gruppe gennemgar, nar de skal arbejde sammen forførste gang og sørge for, at gruppen performer hurtigst muligt. Nar først gruppen nartil dette stadie, er det vigtigt, at projektlederen formar at motivere gruppen til fortsatat arbejde effektivt og malrettet. Dette gøres jf. teorien [1, s. 329] ved at vedligeholdegruppens sociale del via forskellige aktiviteter. Hos DFDS har dette blandt andet væretsom nævnt workshops for projektgruppen.

For at en gruppe kan arbejde godt sammen skal gruppen først gennem en udviklings-proces for at kunne yde optimalt. Denne proces blev beskrevet af Lenneer-Axelson i 1993og ses pa figur 9.

15

Figur 9: Gruppens udvikling [2]

De fem faser beskriver de enkelte trin i gruppens udvikling. Som projektleder fore-trækkes det, jf. teorien [1, s. 329], at gruppen befinder sig i Performing-fasen, hvor derarbejdes mest effektivt, men beklageligvis kan de indledende faser ikke springes over. Dogkan de forkortes, hvis der bliver gjort en indsats fra projektlederens side.

Noget der kan virke demotiverende pa en gruppe er afholdelse af for mange og for langemøder. Samtidigt er det vigtigt at ajourføre gruppen, sa alle ved, hvor langt projekteter kommet samt om milepælene er opnaet. Som projektleder er det derfor afgørende atfinde en balance mellem for meget og for lidt information til gruppen. Hos DFDS hardet betydet, at styregruppen heriblandt projektlederen efter fa opfølgningsmøder i star-ten af projektet er gaet over til sakaldte ugerapporter. I disse rapporter er der beskrevetmalene for den pagældende uge, opfølgning pa forrige uge, planen for den følgende ugesamt bekymringer for projektets videre forløb.

Under arbejdet med projektet er det vigtigt, at gruppen hele tiden er motiveret ogdermed arbejder mest effektivt. Som det fremgar har DFDS været gode til dette ved atryste gruppen sammen og fastholde motivationen igennem workshops og seminarer, derer med til at bringe gruppen tætter sammen.

5.3 Planen

Som skibets kaptajn er det naturligvis vigtigt at kunne lægge en kurs og dernæst styre efterden. Men det er lige sa vigtigt at kunne ændre kursen, hvis der skulle ske noget uforudsetundervejs. En projektplan kan lægges pa mange mader med kræver som regel lidt erfaringfra andre projekter for, at planen bliver realistisk. DFDS har ikke før gennemført etlignede projekt og har derfor ikke den nødvendige erfaring til at lægge en projektplan.Derfor har projektlederen lagt planen i samarbejde med projektgruppen og leverandørenaf IT-systemet, som har erfaring fra lignende opgaver.

5.3.1 Styring

Nar først kursen er lagt og skibet er søsat, skal projektlederen lede gruppen saledes, atskibet nar sikkert frem. Dette gøres ved at bruge den fastlagte plan, men det er vigtigt, jf.teorien [1, s. 227], at projektlederen formar at se planen i forhold til projektet. Dette vilsige, at projektlederen skal have overblik nok til, at holde øje med projektets nuværendestatus i forhold til planen, være opmærksom pa forhindringer forude, sikre, at projektet

16

stadig er relevant for omgivelserne samt lede gruppen aktivt for at skabe fremdrift iprojektet.

Ledelse af gruppen kan forega pa flere mader. Nogle ledelsetyper minder om diktatur,hvor projektlederen skærer igennem og tager beslutninger udenom gruppen. Hos DFDShar de primært valgt en anden model, som de kalder den kinesiske model. Ved hjælp afdenne ledelsetype formar de at holde projektgruppen engageret i projektet. Denne ledel-setype handler om at motivere gruppen og skabe en ejerskabsfornemmelse af projektet.Her er det afgørende, at lederen formar at være inspirerende og motiverende, sa gruppensmedlemmer tror, at beslutningen er deres egen.

5.3.2 Opfølgning

Nar skibet er naet sikkert i havn - eller sunket undervejs - er det tid til at se tilbage og læreaf rejsen. Pa denne made kan projektlederen finde ud af hvad der fungerede i projektetog hvad der absolut ikke fungerede. Men der skal ogsa ses fremad. Projektlederen skalpa forhand have besluttet, hvad der skal ske med gruppen, nar projektet er naet til vejsende.

Hos DFDS anser man dette projekt for en succes og anvender det som eksempel tilfremtidige projekter, da de ønsker at videreudvikle Sertica. De nye projekter vil blivevaretaget af en ny projektgruppe, da medlemmerne af den gamle gruppe er avanceretindenfor DFDS og ikke længere kan fjernes fra den daglige drift. Dog er der enkeltesuperbrugere tilbage som kan supervise, hvis der skulle opsta problemer.

5.4 Delkonklusion

Selvom projektlederen ikke har erfaring inden for planlægning af et projekt, fremgar det,at han er erfaren inden for ledelse. Som nævnt er det afgørende for et projekts succes,at projektlederen formar at udvælge de rigtige personer til opgaven. Herefter skal hansørge for, at gruppen arbejder effektivt og malrettet under hans ledelse. Hos DFDS sesskoleeksemplet pa dette, da projektlederen formar at samle en gruppe med vidt forskelligebaggrunde og far dem til at arbejde sammen samtidig med, at han er i stand til at motiveregruppen.

17

6 Kommunikation og forandring

6.1 Kommunikation i DFDS

Kommunikation i projektet er en vigtig faktor, nar det omhandler et forandringsprojekt.For at kommunikere projektets formal ud til projektgruppen, arrangerede projektledereni starten af projektet en workshop-weekend. For at sikre en løbende kommunikation ud tilinteressenterne, blev der hver uge udsendt en ugerapport af projektlederen, indeholdendestatus pa projektet samt de største bekymringer.

6.2 Teorien bag forandring

I forandringer hos en virksomhed er der altid nogen der bliver nødt til at ændre adfærd.Der vil altid være mennesker som er for eller imod forandringer. Det er vigtigt at faalle involverede parter til at arbejde sammen for at forandringen finder sted og sikre atalle har en motivation. Derfor skal det defineres klart og tydeligt, hvem der bliver ramt afdenne forandring og pa hvilket niveau. Projektlederen skal derfor være i et tæt samarbejdemed de involverede, sa det er klart for dem hvorfor denne ændring er vigtig. Nar mangennemgar en forandring, er timing et af de mest afgørende aspekter. Nogle gange kaninitiativer ikke indføres før andre har fundet sted. Der skal desuden ogsa tages højde forom medarbejdere har vænnet sig til det nyindførte, før det næste finder sted. Derfor skalalt overvejes taktisk, før implementeringen finder sted:

Figur 10: Implementering

Som illustreret pa figur 10 er der fire forskellige teoretiske metoder for en implemen-tering. Der skal laves en risikoanalyse af virksomheden og derfra vurderes hvordan detbedst kan betale sig at indføre forandringen i virksomheden.Domino metoden gar ud pa at den fulde ændring finder sted i en enkelt afdeling ad gan-gen. Man indfører ændringen som en testpilot i en afdeling og ser hvordan forandringenforløber samt lærer af fejlene undervejs.Sma trin metoden handler om at indføre ændringerne trinvist i en afdeling ad gangen, imodsætning til domino metoden hvor alle ændringerne indføres pa en gang. Denne me-tode kan være meget brugbar, hvis det drejer sig om en kritisk ændring i virksomheden,som kræver, at man er omhyggelig med de enkelte ændringer, der skal indføres. Her erudfordringen, at det kræver et stort tidsforbrug over en længere periode og metoderne

18

hele tiden bliver justeret.Tredje metode er Big Bang. Denne metode gar ud pa, at alle ændringer finder sted sam-tidig i hele virksomheden pa en gang. Der kan dog forventes en stor effektivitetsnedgangi en bestemt periode, og det kan være vanskeligt at følge med i adfærdsændringen hosmedarbejderne. Den sidste metode er Kaskade. Denne metode gar ud pa at ændringenfinder sted, trin for trin. I modsætningen til metoden Sma trin, sa indføres forandringeni dette tilfælde pa hele virksomheden, i stedet for det lokale omrade. Overordnet set harDFDS brugt Sma trin for at indføre SERTICA, men som implementeringen pa de enkelteskibe har det fungeret som Domino. Der er blevet lagt en plan over hvor mange skibe adgangen man skulle indføre systemet pa, sa der var system i implementeringen.

6.3 Fejl i kommunikationen

Kommunikation er ikke det store spørgsmal i hverdagen, nar det gælder projekter læn-gere, da der er alt den tilgængelige information tilstede i form af rapporter og e-mails.Kunsten er mere at kommunikere det rigtige ud til den rette malgruppe med de relevanteoplysninger og mere fokus dertil. I store projekter er der ofte medarbejdere der føler, atde ikke far nok kommunikation fra oven, det er derfor vigtigt at sørge for kommunikationogsa foregar ned i hierarkiet.

De hyppigste fejl der kan forekomme i kommunikation er følgende:

• Big Bang, efterfulgt af stilhed. Alt bliver indført pa en gang med god kommunikationi starten, men efterfølgende hører interessenterne intet.

• Abstrakt og uvedkommende sprog kan betyde at kommunikationen ikke malrettesefter de bestemte interessenter sa alle stadig har et stort spørgsmal i hovedet omhvorvidt projektet gavner eller skader dem.

• Man glemmer at der skal to til en dialog, og kommunikationen sker derfor kunenvejs.

• Handling betyder mere end ord. Hvis kommunikationen har fundet sted med ek-stremt meget omtale, uden nogen form for handling, formindskes opbakningen ogøget skepsis blandt interessenterne.

• Det er ligeledes vigtigt at det er den rigtige budbringer der siger de rigtige ting.

DFDS har umiddelbart ikke lavet nogle af disse fejl da der har været en erfaren projekt-leder.

19

6.4 Malrettet kommunikation, Branding og kommunikation der understøtterforandringer

Figur 11: Effektiv kommunikation

Der kan ses pa figur 11, at det kræver tre aspekter er opfyldt for at et projekt far succes.Før et projekt startes er det vigtigt at forsta hvilke behov de forskellige interessenter har.Derfor er kommunikationen til interessenterne særdeles vigtig, sa de er indforstaet medhvorfor disse ændringer finder sted og hvad det kommer til at betyde for dem. Med andreord skal interessenterne defineres nøje og de forskellige kommunikationsmetoder skal væretaget i betragtning fordi de forskellige interessenter aldrig har samme kommunikationsbe-hov. I kommunikation skal man derfor ikke kun fokusere pa hvad man selv finder vigtigt,da det kan risikere at kommunikationen skyder lige forbi og budskaber ikke rammer in-teressenterne. Hos DFDS har projektlederen haft mange kaffemøder samt hyggedage medinteressenterne i starten af projektet, for at forhøre sig om interessenternes holdning tilprojektet internt i organisationen. Udover introduktionsweekenden som nævnt tidligerehar DFDS ikke gjort det store ud af at brande deres projekt. Det har dog sørget for atprojektet har en klar status i organisationen. Branding af et projekt internt er vigtigt forat sikre opbakning, tiltrække kompetente medarbejdere, motivere projektgruppen, samtat udelukke skepsis og modstandere af projektet. Typisk kan medarbejdernes holdning tilet projekt inddeles i følgende grupper:

Entusiasterne: en gruppe, der altid er klar pa nye udfordringer. Imødekommende ogklar til at ga igennem enhver modstand.

Modstandere: En gruppe, som star foran de nye udfordringer og tager dem i betragt-ning om hvorvidt det er muligt, om det kan lade sig gør eller om det er en god ide. Debeslutter sig ofte for at de ikke vil ga ind for de nye udfordringer og opfinder en masseundskyldninger.

Tvivlerne: En gruppe som mest tænker pa at sikre sig selv. De er usikre pa om de helstvil beholde det gamle system eller tage imod de nye udfordringer. Oftest sidder de bareog venter pa hvilken side der vinder mellem modstanderne og entusiasterne og tager deresbeslutning derfra.

20

6.5 Delkonklusion

DFDS har pa alle mader i kommunikation fulgt teorien fra [1]. Projektlederen har sørgetfor kommunikationen er naet ud til alle i hierarkiet, saledes at alle har følt sig involveret.Der har været uddannet superbrugere der har kommunikeret vigtig information omkringSERTICA ud i organisationen. Derudover har man overordnet brugt Sma trin metodentil forandring, men pa hvert skib er der blevet domino metoden. Informationen til devigtigste interessenter er desuden blevet udført ugentlig for at sikre en kontinuerlig strømaf updates.

Kildekritik

Generelt set, er det altid fornuftigt at forholde sig kritisk overfor informationer, manindhenter fra forskellige kilder. Gennem projektet har vi haft interviews udelukkende medprojektlederen, selvom det optimalt set havde været optimalt, at indhente interviews medandre deltagere fra projektgruppen, men dette var desværre ikke en mulighed.

Selvom projektlederen har været aben overfor vores spørgsmal og svaret pa dem efterbedste evne, sa er projektlederen stadig partisk omkring projekt og dermed alt andet ligevil vise projektet fra dets bedste side. Dette betyder bestemt ikke, at vores indhentedeinformationer ikke er tilstrækkelige, men blot at vi ikke har faet projektet forklaret fraflere sider, og derfor skal vi forholde os kritiske over disse.

Konklusion

Overordnet har SERTICA været et vellykket projekt. Ud fra teorien i dette kursus harvi dog lært at man ifølge teorien har kunne gjort nogle ting anderledes. I afsnittet om-handlende malsætningen fandt vi ud af at en mere specifik kravspecifikation kunne havehjulpet i visse faser af projektet. I interessentanalysen blev interessenterne defineret ogderes indflydelse tildelt. Her kunne man fra DFDS? side segmenteret datateamet til enindkøbsdel-undergruppe med en leder.

I analyse af projektplanen ses det, at DFDS har anvendt en sakaldt gantt-plan tilplanlægning af projektet. Det kunne med fordel være blevet gjort med milepælsplanlæg-ning i stedet saledes, at opfølgningen kunne være mere malbar og effektiv.

Som beskrevet i afsnittet om projektlederen ses det, at en positiv ting var at projekt-lederen selv havde udvalgt deltagerne i projektgruppen hvilket gjorde, at motivation ogarbejdsindsatsen var høj.

En anden positiv ting som DFDS kan tage med fra projektet var de ugentlige opdate-rings mails (ugerapporter) som var et godt redskab til at informere interessenterne, badeopad og nedad i hierarkiet, om hvilke aktuelle problemer der kunne opsta samt planenfremadrettet.

I kommunikations-delen blev det nævnt at implementerings-workshops?ne for SERTI-CA var en succes, idet det skabte ejerskab i projektgruppen. Dette var ogsa med til atøge motivationen og viden omkring SERTICA projektet.

Implementeringsplanen hvormed man fra DFDS? side brugte sma trin metoden harogsa fungeret rigtig godt, idet implementeringen pa en hel flade er blevet er blevet gjortgradvist og erfaringerne fra de første implementeringer kunne bruges til de næste skibe.

21

En af de største opdagelser ved dette projekt er, at projekt SERTICA har vist sigat være et forandringsprojekt lige sa meget som et IT-projekt. Grunden til dette er atimplementering af SERTICA har ændret datahandteringen i DFDS samt skabt nye ar-bejdsgange og rutiner.

Generelt har arbejdet med dette projekt abnet øjnene for hvordan man arbejder pa etprojekt i en stor virksomhed og hvordan et IT-/forandringsprojekt kan styres og hvilkeaspekter som er vigtigt at have styr pa. Nogle af de vigtigste pointer vi har lært er, at:

• Teori er ikke en facitliste, og man kan godt opna et succesfuldt projekt uden at følgeden.

• Erfaring inden for branchen kan medfører gode resultater.

• Sammensætning af projektgruppe grundet tidligere erfaringer medføre resultaternemed sig.

• En detaljeret malsætning gør projektet mere fokuserede pa malet.

6.6 Egne erfaring

Som det ses af logbogen er vores arbejde ikke blevet planlagt og kørt som et decideretprojekt. Grunden til dette er efter vejledning af hjælpelæren som mente at vi skullefokusere pa DFDS projektet i stedet. Dog har vi gjort os nogle erfaringer i gruppearbejdet.Her er de vigtigste erfaringer beskrevet:

• Openspace: Her blev vores gruppe dannet hurtigt, idet vi alle havde interesse forprojektet. Kasper havde lavet en poster som var god til at danne et overblik overhvad SERTICA-projektet gik ud pa. Vi er har erfaret at det er vigtigt at alle igruppen har samme ambitionsniveau, saledes at der ikke opstar konflikter.

• Grøn- og rød-leder: Vi har anvendt os af de to lederroller til hver møde (mandagmorgen). Det har medført at alle er blevet hørt til møder og at der er blevet truffetbeslutninger effektivt.

• Milepæle: Vi har fra kursusgang til kursusgang haft klare milepæle. Milepælenehar været brugt til at skabe et fælles overblik over hvad der skulle laves til næstekursusgang. Milepælene har ogsa pa længere sigt været brugt til deadlines, saledesat alle vidste hvornar vigtige afleveringer skulle være lavet.

• Kommunikation og vidensdeling: Vi har anvendt Google Drive (online drev) somværktøj til vidensdeling og som dokumenthandtering. Dette har gjort det muligt foralle i gruppen at følge med hvad der er blevet skrevet og arbejdet med løbende.

• Kontakt til DFDS: Vi har løbende haft en god kontakt til Jakob. Det har vist sigat være vigtig med en god kontakt til virksomheden, da der ogsa efter interviewsvar ting vi var i tvivl om. Jakob har hele tiden været aben over for udleveringeraf materiale samt opfølgende spørgsmal, hvilket har gjort projektarbejdet betydeliglettere.

• GURU-fremlæggelse: Her fik vi god feedback, blandt andet vores kritiske syn paprojektplanen og vores interessentanalyse.

22

Litteratur

[1] Mette Lindegaard Attrup & John Ryding Olsson, ”Power i projekter & portefølje”, 2.udgave, 2010

[2] Camilla Kring, ”Powerpoint: Projektledelse”, 2013

23

Logbog

Kursusgang 01 - 04.02.2013

• Introduktion til kurset

• Gruppen er pa nuværende tidspunkt ikke dannet endnu

Kursusgang 02 - 11.02.2013

• Gruppen dannes

• Samarbejdskontrakt er skrevet - printes og underskrives ved næste møde

• Projektbeskrivelse afsendt

Kursusgang 03 - 18.02.2013

• Første møde i projektgruppen

• Alle gruppemedlemmer er til stede

• Der er aftalt et interview med Jakob Steffensen, kontaktperson i DFDS, den 21.februar 2013

• Der er brainstormet og skrevet skrevet spørgsmal til interviewet

• Tilføjelser til spørgsmalene skal ske senest den 19. februar 2013

• Projektbeskrivelsen af DFDS’ projekt fremskaffes til næste møde

• Gruppens medlemmer forbereder kapitel 5 og 6 til næste kursusgang

Interview 01 - 21.02.2013

• Interview med Jakob Steffensen hos DFDS

• Tilstede er Kasper Fønss Bach, Isa Duran og Sune Thonesen

• Mødet optages og deles med resten af gruppen

Kursusgang 04 - 25.02.2013

• Sune er tildelt ’rød leder’-rolle

• Simon er tildelt ’grøn leder’-rolle

• Interviewet evalueres

Kursusgang 05 - 04.03.2013

• Sadik er tildelt ’rød leder’-rolle

• Tanja er tildelt ’grøn leder’-rolle

• Interviewets enkelte dele fremlægges

• De spørgsmal som ikke blev besvaret gemmes til næste interview

• Til næste gang forberedes kapitel 7 og 8 samt interviewspørgsmal til disse kapitler

Kursusgang 06 - 11.03.2013

• Til stede er Simon, Ulrik, Isa og Tanja

24

• Brainstorm over interviewspørgsmal

• Kasper uploader slides og dokumenter inden 18. marts 2013

• Til næste gang forberedes interviewspørgsmal fra kapitel 9 og 10

• Næste interview ønskes afholdt inden Paske

Kursusgang 07 - 18.03.2013

• Til stede er Simon, Ulrik, Isa og Kasper

• Der blev gennemgaet spørgsmalene til næste interview omkring kap. 9/10.

• Ulrik er tildelt ’rød leder’-rolle

• Kasper er tildelt ’grøn leder’-rolle

Interview 02 - 21.03.2013

• Gennemgang af andet interview vedr. kap 9 og 10

• Sadik, Tanja og Simon deltog i dette interview.

• Udover spørgsmalene til kap 9/10, blev der fulgt op pa manglende svar pa tidligerestillede spørgsmal.

Kursusgang 08 - 08.04.2013

• Alle deltagere er til stede

• Hver især har faet uddelt hver deres emne

• Emnerne er aftalt færdige til d. 22.04.2013

Kursusgang 09 - 15.04.2013

• Projektarbejde hver for sig

Kursusgang 10 - 22.04.2013

• Delelementerne i rapporten forventet færdig dags dato.

• Fremlæggelse for GURU

Kursusgang 11 - 29.04.2013

• Alle deltagere er tilstede.

• Gennemgang af rapport

• Rapporten forventes færdig dags dato.

Kursusgang 12 - 06.05.2013

• Alle deltagere er tilstede.

• Der blev fundet fejl i rapporten

• De sidste fejl er rettet dags dato

• Aftalt er, at der d. 13.05.2013 bliver printet, underskrevet og afleveret projektrap-porten.

Kursusgang 13 - 13.05.2013

• Projekt er printet, underskrevet og afleveres i dueslag.

25

Gearet til vækstDFDS

DFDS har en klar strategi: Vækst. Og eftersom de driver ikke mindre end 38 skibe, en række havneterminaler og Danmarks største hotel på vand, er den tekniske drift ikke en bagatel. I 2009 stod DFDS over for den udfordring at udvælge det sys-tem, der bedst kunne bidrage til at realisere og støtte en am-bitiøs vækststrategi.

Kasper Moos, VP Technical Organisation, fortæller: ”For at støtte vores vækststrategi, som både omfatter rationaliserin-ger, organisk vækst og opkøb, så havde vi brug for ét system, som kunne blive den fremtidige platform på flere områder”. På daværende tidspunkt havde virksomheden hele fire forskel-lige systemer til systematisk vedligehold (PMS), der var spredt på flåden og de landbaserede operationer – målet for det nye system var, at det skulle være i stand til at samle de fire eksis-terende i et nyt, femte system.

DFDS valgte Sertica - det system, der har den stærkeste tekno-logi til dataudveksling mellem skib og land.

Udfordringen: Vækst og optimering

Projektet var tiltænkt at være kickstart til en større datavask, og for at kunne fokusere hensigtsmæssigt i valget af system, prioriterede DFDS allerede i begyndelsen af processen deres ønsker og krav: ”Vi valgte at skære ind til benet og finde det suverænt stærkeste system til PMS og med en klippe stabil motor til udveksling af data mellem skib og land. Vi vidste at et sådan system ville være det perfekte fundament til at un-derstøtte vores ambitiøse planer for optimering og vækst, og valgte derfor Sertica,” konstaterer Kasper Moos.

Jakob Steffensen, Project Manager, tilføjer: ”Alle vores skibe har internetforbindelse og er i princippet online hele tiden.

Men i praksis konstaterer vi at der kan være små udfald, lang-somme forbindelser og andre problemer som jo naturligvis kommer når man sejler 100 sømil fra land. Vi kan IKKE være afhængige af en 100% online forbindelse.”

Tidligere havde DFDS fire forskellige systemer, der hver især havde en replikeringsmotor til dataudveksling. En primær år-sag til, at Sertica har stor succes i hele organisationen er imid-lertid, at der kun er én motor, og at den virker og er stabil – hele tiden. Sertica minimerer således den unødvendige nede-tid, hvilket er en væsentlig fordel. Jacob Steffensen uddyber: ”Derfor er det også genialt at Sertica jo netop er bygget til at fungere på netværksforbindelser, der ikke er perfekte. Det har sparet os for mange bekymringer. Ikke mindst vores besætnin-ger er glade for systemet. De skal ikke ’bøvle’ med dataover-førsler, som i praksis bare sker automatisk.”

En anden og væsentlig parameter for DFDS er brugerven-lighed. Programmerne om bord på skibene skal være nemme og enkle at anvende, så spildtiden minimeres: ”Der er mere en 10 forskellige software systemer som besætningen benyt-ter dagligt, det siger sig selv at jo mere brugervenlige syste-merne kan være, jo bedre udnyttelse får vi af systemerne, og jo nemmere er det at leve op til myndighedskrav”, siger Thomas Mørk som er Director of Marine Standards i DFDS.

Teknisk afdeling - et cost-center

Den tekniske afdeling i et rederi er en nødvendighed. Imid-lertid er det ofte svært at forbinde den med andet end om-kostninger. Sertica er med til at lokalisere problemer, højne produktiviteten og forbedre metoder, for derigennem at re-ducere udgifterne: ”Vores afdeling er reelt et cost-center. Vi er faktisk kun en omkostning, og har derfor kun én parameter at forbedre os på, det er optimering. Sertica driver vores optime-rings og forandringsprojektet ud fra et datamæssigt synspunkt. Vi har konstateret 100 % på egen krop, at måling skaber resul-tater,” siger Kasper Moos, mens de øvrige i teamet fortsætter: ”Sertica er vores data repository. Sertica er det værktøj, som vi benytter til at samle data og udveksle det med til og fra land. Vi benytter f.eks. Dashboardet i Sertica, en slags dynamisk opslagstavle på skibet”, forklarer de. ”Dashboardet kan være en kilde til problemsøgning og kan på den måde drive grundlaget for endnu et forbedringsprojekt”, uddyber Kasper Moos. ”Det handler alt sammen om optime-ring!” Thomas Mørk bryder ind: ”Vi tænker altid over, hvordan vi vender det man skal i forhold til myndighederne, til hvad man KAN opnå med de rigtige ideer og systemer. På den måde opnår vi meget mere end ”bare” en klassifikation eller god-kendelse, vi opnår reelle forbedringer, optimering og dermed besparelser.”

“Udover at vi naturligvis har Sertica på alle vores egne skibe, så har vi også en aftale med Logimatic, som gør at vi kan in-stallere en ’Sertica Light’ på alle de skibe som vi har inde i time-charter”, forklarer projektleder Jakob Steffensen. ”Det er en kæmpe fordel for os som teknisk afdeling, at vi har mulighed for det, det er jo en kæmpe effektivisering, at alle

“Vi har en ambitiøs vækststrategi i DFDS, og den kan vi føre ud i livet med de værktøjer vi har. Sertica er bestemt en meget vigtig brik i det puslespil”

Kasper Moos, VP Technical Organisation

A Bilag

26

B Bilag

Interessent Fordele ved Serti-ca

Ulemper vedSertica

Samlet vurde-ring af inter-essenternes bi-drag/position

Handtering afinteressenten-fra projektle-deren

Projekt ejer:Kasper Moos

Et effektivt projekt,der kan bidrage posi-tivt til mere vækst ivirksomheden

Mulighed for atprojektet ikke op-fylder alle krav ogdermed ikke bli-ver en succes.

Ønsker etveludført projekttil prisen ogindenfor tidsram-men.

Skal holdes un-derrettet omkringde emner, som bi-drager positivt tilprojektet.

DFDS ledelse Der er konsensus omet samlet system tilvedligeholdelse ogdrift pa skibene somogsa kan anvendesfremover pa andreskibe.

Projektets økono-mi ikke vil hol-de og integratio-nen vil give pro-blemer.

Støtter opomkring ideen ogvisionen for pro-jektet.

Ledelsen blandersig ikke i selveudførelsen men erorienteret omproblemer og ud-fordringer

Medarbejdere,superbrugereog mandskabpa skibene

Mere detaljeretinformation vedr.vedligeholdelsesdata.Bedre overblik oggennemsigtighed.

De skal lære etnyt system atkende. De farendnu et system,som ikke inde-holder samtligefunktioner manefterspørger.

Input med ideerog funktioner tilprogrammet.

Holdes hele ti-den orienteretomkring hvad sy-stemet vil kunnehjælpe demmed i dagligda-gen.

Aktionærer Ved et samlet sy-stem pa alle skibe,vil opkøb af nye re-derier blive lettere atovertage fremover.

Et uanvendeligtprojekt, der ska-ber mere kaos endoverskuelighed =lavere aktiekurs.

Positiv overfornye tiltag ogsystemer somkan optimerevirksomheden.

Sørge for de harkendskab til deovervejende suc-cesrige elementeriprojektet.

Leverandør(Logimatic)

Er interesseret i atudvide horisonternefor hvordan et ma-ritimt IT-system kanforbedres.

Udfordringer forat man ikke kanlevere varen ogdermed darligomtale.

Logimaticopfattes hele vej-en rundt som sta-bil og kan levereet godt resultat.

Leverer de funk-tioner som DFDSefterspørger.

Maritime (re-præsentant forhvert skib)

Hvert skib har enindflydelse i forholdtil funktioner i pro-grammet.

At de far end-nu et system, somikke kan dannesamlingspunkt for?alle? systemer.

Positiv over atfa et mere detal-jeret vedligehol-delsessystem medfælles reference.

De skal have enopdatering omhvilke nye funk-tioner som manhar tænktsig at tilføje.

Supply ChainManagement

Har det forkrome-de overblik over heleprojektet og dets re-lationer.

Kan miste over-blik og mulighedfor at nogle skibeikke nar oplæringinden tidsfrist

Positiv overfornye systemer somkan optimerearbjedsgangen formange.

Informeres omnye personereller grupper iprojektet.

Data-team Kender til de tidli-gere systemer og kandermed se en fordeli at have 1 systemfremover.

At data integra-tionen ikke villykkedes. fx. medindkøbs delen.

Meget vigtig rol-le i startfasen afprojektet hvor da-ta skal være til-gængelige fra tid-ligere systemer.

Opdateres omændringeri softwarenvedr.data specifikindflydelse.

Projektgruppen Data Team At data integra-tionen ikke villykkedes. fx. medindkøbs delen

Meget vigtig rol-le i startfasen afprojektet hvor da-ta skal være til-gængelige fra tid-ligere systemer.

Opdateres omændringeri softwarenvedr.data specifikindflydelse.

27