Projekter og rapporter på tekniske uddannelser (i-bog) [2 ed.] 9788702339543 [PDF]

Zitiervorschau

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Indledning

Denne håndbog er til dig, der er studerende på en teknisk uddannelse. Bogen kan anvendes på alle tekniske uddannelser, hvor projektarbejde indgår, både universiteter, erhvervsakademier og professionshøjskoler. Bogen passer til alle semestre på en uddannelse og til både større gruppeprojekter og mindre projekter med en eller to personer. Bogen bygger på princippet om, at teknikere designer løsninger. For eksempel designer maskiningeniører maskiner, bygningsingeniører bygninger, produktionsingeniører produktionssystemer, og softwareingeniører programmer og apps. Det gode løsningsdesign er baseret på en analyse, og når løsningen er designet, så følger implementering. Rækkefølgen analyse, løsningsdesign og implementering er kernen i tekniske projekter og er illustreret i figur 0.1.

Figur 0.1. Rækkefølgen af kerneaktiviteterne i et teknisk projekt

Bogens anvendelse på tekniske uddannelser i Danmark projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Landskabet for tekniske uddannelser i Danmark er bredt og mangfoldigt og afspejler de mange forskellige kompetencebehov, som private virksomheder og offentlige organisationer har. Tabel 0.1 giver et overblik over de store kategorier af tekniske uddannelser i Danmark. Kategori

Eksempler på uddannelser i kategorien

Tekniske universitetsuddannelser

Diplomingeniør, civilingeniør, landinspektør, digitale medier, data science, software design og miljøvidenskab

Tekniske professionsbacheloruddannelser

Bygningskonstruktør, bachelor i produktudvikling og teknisk integration, maskinmester

Tekniske erhvervsakademiuddannelser

Automationsteknolog, el-installatør, laborant, jordbrugsteknolog og klinisk tandtekniker

Tekniske erhvervsuddannelser

Industritekniker, procesoperatør, automationstekniker, elektriker og smed

Tabel 0.1. Tekniske uddannelser i Danmark En række tekniske uddannelser kombinerer tekniske fagområder med forretningsforståelse (business). Blandt disse er diplomingeniøruddannelserne og en række tekniske bacheloruddannelser. Bogen her henvender sig til samtlige af disse uddannelser, der på trods af forskellige traditioner og succeskriterier alle arbejder med at designe løsninger.

Brug af bogen på efteruddannelser og på ikke-tekniske uddannelser projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Alle uddannelserne i tabel 0.1 er tekniske, anvendelsesorienterede uddannelser, der henvender sig til unge mennesker, der har afsluttet en adgangsgivende uddannelse som fx STX, HTX eller ingeniøruddannelsernes adgangskursus. I Danmark findes også en række tekniske masteruddannelser, der henvender sig til medarbejdere i job. Eksempler på denne type uddannelser er master i bygningsfysik og master i brandsikkerhed. Studerende på disse uddannelser vil ligeledes kunne anvende bogen til deres afgangsprojekter. Ud over de tekniske uddannelser så arbejder mange andre uddannelser også med design af løsninger. Selvom alle eksempler i denne bog kommer fra tekniske uddannelser, er bogen også anvendelig på ikke-tekniske anvendelsesorienterede uddannelser som fx professionsbacheloruddannelser inden for sundhed og sociale fag. På ikke-tekniske uddannelser arbejdes ofte med projekter, der kaldes innovationsopgaver. Disse projekter handler ofte om at designe en løsning på et problem. På en samfundsfaglig uddannelse kunne en innovationsopgave fx handle om at udvikle en politik, der nedbringer antallet af fraværsdage på skolerne i en kommune.

Samarbejdet med virksomheder og andre organisationer projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Langt hovedparten af de tekniske uddannelser i Danmark lægger op til et samarbejde mellem de studerende og relevante virksomheder eller organisationer. Dette sker ofte gennem praktikforløb og projektarbejde. I projekter arbejder de studerende (enkeltvis eller i grupper) med konkrete problemstillinger hos virksomhederne. På de fleste uddannelser er det en tradition, at især afgangsprojekter sker i samarbejde med en virksomhed. Bogen behandler indgående interaktionen mellem studerende og virksomhed lige fra udformningen af problemformulering og indsamling af data til implementering af projektets løsning i virksomheden. Bogen bruger konsekvent ordet virksomhed som betegnelse for den organisation, studerende samarbejder med om projektet. For tekniske studerende er det ofte en privat virksomhed (fx en produktionsvirksomhed, et energiselskab eller et softwareudviklingshus), men det kan lige så godt være andre typer organisationer (fx kommuner, fagforeninger, regioner, NGO'er, styrelser eller ministerier).

Bogens vidensgrundlag projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Bogen beror dels på min egen erfaring som projektvejleder på DTU og Aalborg Universitet og dels på en lang række samtaler og interviews med undervisere og censorer. Min egen erfaring dækker projekter fra første semester til kandidatafhandlinger, og jeg har de sidste 12 år vejledt og eksamineret hundredvis af studerende i projektarbejde. Dette gælder både gruppeprojekter, afgangsprojekter, kandidatafhandlinger og projekter med alskens særlige rammer og udfordringer. Jeg har gennem flere år været ansvarlig for udvikling af projektbaseret undervisning på flere forskellige ingeniøruddannelser. Ud over min egen erfaring er bogen baseret på viden fra de fleste diplomingeniørretninger på DTU, interviews med censorer (herunder censorformændene for en række uddannelser), studieledere og undervisere fra Syddansk Universitet, Aarhus Universitet og Aalborg Universitet, og en række samtaler med undervisere fra universiteter i andre lande og verdensdele.

Bogens indhold | Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Bogens indhold

Bogen er inddelt i fem hovedtemaer: Tema

Kapitler

Temaets indhold

Gennemførelsen af projektet

2-8

Kapitlerne i første (og største) del af bogen handler om gruppedannelse, problemformuleringer, brug af litteratur og teori, metodevalg, hvordan projektet rent praktisk planlægges og styres, hvordan data indsamles og analyseres, hvordan løsninger designes, og hvordan løsningerne testes og implementeres.

Samarbejde, kommunikation og interessenter

9-11

Kapitlerne i anden del af bogen handler om samarbejde i projektgruppen, håndtering af projektets interessenter og samarbejdet med den ofte vigtigste interessent, nemlig den virksomhed, som projektgruppen samarbejder med. Kapitlerne behandler også den gode vejledning.

Projektrapporten

12-13

Denne del af bogen handler om projektrapporten. Kapitlerne beskriver, hvordan rapporten bør struktureres, og hvordan projektgruppen sikrer sig læsers forståelse af projektet, herunder den vigtige røde tråd. Kapitlerne dækker derudover sprog og skriftlig formidling i tekniske rapporter samt rapportens praktiske udformning (fx forside, bilag, fodnoter og kildeangivelser).

Projekteksamen

14-15

Fjerde del af bogen handler om projekteksamen. Kapitlerne i denne del behandler, hvordan projektgruppen kan levere den bedst mulige præsentation af projektet til eksamen, og hvordan studerende bedst håndterer eksaminators og censors spørgsmål. Kapitlerne giver også råd til, hvordan man håndterer utilfredshed med karakteren og processen for formelle klager over karakter og forløb.

Kandidatafhandlinger

16

Sidste del af bogen henvender sig til studerende, som skal skrive tekniske kandidatafhandlinger. Kapitlet beskriver, hvad kandidatafhandlinger er, og giver konkrete anvisninger til, hvordan kandidatafhandlinger kan gennemføres og skrives.

Tabel 0.2. Bogens opbygning

To arketyper af projekter på tekniske uddannelser projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Grundlæggende så handler de fleste projekter på tekniske uddannelser enten om at forbedre noget eksisterende eller designe noget nyt. Der findes således to arketyper af projekter på tekniske uddannelser: 1. Forbedre noget eksisterende 2. Designe noget nyt. Disse to arketyper behandles løbende igennem hele bogen. For eksempel hvad problemformulering er for hver af de to arketyper, hvordan et projekt struktureres for hver arketype, til hvilke formål litteratur anvendes for hver arketype, etc. I bogen fortæller afsnitsoverskrifterne, om et givent afsnit handler om den ene arketype eller den anden.

Bogens understøttelse af CDIO og problembaseret læring (PBL) projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

En lang række førende tekniske universiteter, herunder DTU og Aarhus Universitet i Danmark, anvender uddannelseskonceptet CDIO, hvilket står for Conceive, Design, Implement og Operate. CDIO er et åbent koncept for udvikling og kvalitetssikring af ingeniøruddannelser. CDIO er baseret på, at ingeniøruddannelsen tager udgangspunkt i den professionelle ingeniørs virkelighed. Det betyder bl.a., at studerende skal gennemføre mindst to frie projekter, hvor problem, metode eller begge dele er valgt selvstændigt af de studerende. Denne bog understøtter CDIO ved at give konkrete råd og vejledning i gennemførelsen af de frie projekter. Aalborg Universitet og Roskilde Universitet har længe anvendt problembaseret læring (PBL) som en integreret del af uddannelser fra første til sidste semester. Denne bog understøtter PBL og vejleder studerende i problembaseret projektarbejde.

Forretningsforståelse og professionelle kompetencer på tekniske uddannelser projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

På mange tekniske uddannelser, fx diplomingeniøruddannelser, indgår forretningsforståelse som et konstituerende element. Dette betyder, at studerende skal lære at anvende en række almene forretningsmæssige og professionelle metoder. Blandt disse er følgende metoder, som bogen dækker indgående: Projektplanlægning med Gantt-diagrammer Udarbejdelse af interessentanalyser Vurdering af en løsnings økonomi.

Kapitel 1. Projekter på tekniske uddannelser projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Denne bog handler om, hvordan I som studerende på tekniske uddannelser bedst kan gennemføre projektarbejde og skrive projektrapporter. Bogen beskriver projektarbejdets enkelte dele, udarbejdelse af en projektrapport, projekteksamen og meget mere. Inden da skal vi se på følgende: Formålet med projektarbejde på tekniske uddannelser Typer af projekter på tekniske uddannelser Typiske kendetegn ved projekter på tekniske uddannelser De problemtyper, som tekniske projekter løser Den typiske proces i tekniske projekter.

Formålet med projektarbejde på tekniske uddannelser projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Projektarbejde er en af de mest effektive metoder til at skabe langtidsholdbar læring. Derudover ruster projektarbejde dig til arbejdslivet, fordi projektarbejde understøtter udviklingen af dine professionelle kompetencer (nogle gange kaldt "bløde" kompetencer, på engelsk: soft skills). Figur 1.1 viser fem vigtige professionelle kompetencer. Undersøgelser påviser igen og igen, at disse kompetencer er blandt de vigtigste egenskaber hos ingeniører. Om du får succes i dit arbejdsliv, kommer lige så meget an på dine professionelle kompetencer som på dine teknisk-faglige kompetencer (fx evner i matematik og fysik) (Lippman et al., 2015).

Figur 1.1. Fem vigtige professionelle kompetencer hos en ingeniør

Tekniske uddannelser i Danmark har som eksplicit mål, at studerende tilegner sig professionelle kompetencer, således at de færdige dimittender kan fungere godt allerede i deres allerførste job. Projektarbejde er den mest udbredte læringsmetode i det danske uddannelsessystem til at sikre tilegnelsen af professionelle kompetencer. Særligt de frie projekter fremmer læringen af professionelle kompetencer. I frie projekter skal I som studerende selv foretage problemanalyse, formulere problem og vælge metode. Succesfulde frie projekter kræver (a) samarbejde i jeres projektgruppe, (b) kritiske evalueringer af metodevalg og data og (c) udvikling af innovative løsninger – alt sammen noget, der fremmer de vigtigste professionelle kompetencer.

Fra tid til anden stiller studerende kritiske spørgsmål til undervisere, der anvender projektarbejde som læringsmetode. De kritiske spørgsmål tager ofte udgangspunkt i de studerendes følelse af, at de ikke rigtigt bliver undervist i et kursus, der bruger projektarbejde som pædagogisk metode. En erfaren underviser på biolog-uddannelsen på et amerikansk universitet fortalte på en undervisningskonference på DTU i 2015 om en episode, hvor en studerende kritiserede underviserens brug af projektarbejde. Den studerende spurgte: "Hvorfor underviser du os i projektarbejde? Dit job er da at lære os biologi." Dertil svarede underviseren: "Nej, mit job er ikke at lære jer biologi, men at lære jer at være biologer." Underviserens fokus er altså ikke blot på biologifagligheden, men på den studerendes professionelle evner i at arbejde som biolog efter endt uddannelse. Projektarbejde kan generelt siges at fremme studerendes evner til at: Identificere og forstå et problem Finde og anvende relevant teori og anden ekspertise Identificere årsager til problemer og krav til løsninger Designe, specificere og vurdere løsninger Teste og implementere løsninger. Projektarbejde på en uddannelse sker ofte i samarbejde med virksomheder, der kan anvende projektets løsninger. Dette samarbejde fremmer de studerendes evne til at forstå den verden, de kommer ud i efter endt uddannelse, hvilket er et vigtigt element i projektarbejdets brobygning mellem teori og praksis.

Typer af projekter på tekniske uddannelser projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Tekniske uddannelser indeholder ofte flere typer af projekter: 1. Projekter inden for rammen af ét kursus 2. Tværfaglige semesterprojekter 3. Det afsluttende afgangsprojekt 4. Projekter, der går på tværs af studieretninger. Projekter inden for rammen af ét kursus bruges til at facilitere en dybere og mere anvendelsesorienteret læring, end det er muligt med forelæsninger, gruppeøvelser og fiktive opgaver. Tværfaglige semesterprojekter handler ofte om at anvende fagligheden fra flere kurser i et tværfagligt projekt, der enten kan være en bunden opgave eller et projekt, der adresserer et problem i en virksomhed. Det afsluttende afgangsprojekt udføres ofte af en til tre studerende og fokuserer på et afgrænset problem. Projekter, der går på tværs af flere studieretninger, kan fx handle om virksomhedsopstart og innovation.

Typiske kendetegn ved projekter på tekniske uddannelser projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Nedenstående liste præsenterer en række typiske kendetegn ved projekter på tekniske uddannelser. Projekter på tekniske uddannelser handler ofte om anvendelsen af faglighed i virkelighedsnære situationer Projektgrupper arbejder med løsninger på aktuelle og specifikke problemer Problemstillingerne er enten rent tekniske eller handler om en kombination af teknologi og mennesker Det problem, som projektet skal løse, findes hos en virksomhed og skal løses inden for virksomhedens kontekst Løsningen skal være implementerbar hos virksomheden Projektet gennemføres individuelt eller i grupper Projektet har minimum to interessenter (universitetet og virksomheden) og har derfor ofte to målgrupper med hver deres sæt af krav. Listen sammenfatter kendetegnene for de mest typiske "frie" projekter, dvs. projekter, hvor projektgruppen er ansvarlig for (a) at identificere og nedfælde den problemformulering, som projektet skal arbejde med, og (b) selv at vælge metoden for, hvordan projektgruppen udvikler en løsning. Ud over de frie projekter så indeholder tekniske uddannelser også bundne projektopgaver, særligt i uddannelsernes første semestre. Problemstillingerne i bundne opgaver er givet af underviseren. Problemstillingen kan involvere en fiktiv virksomhed, der har behov for en løsning på et (af underviseren specificeret) problem. Eksempler er planlægningen af en fiktiv produktion, optimering af et kemisk procesanlæg beliggende på universitetet og design af en bygning baseret på beskrivelser fra en nyligt afholdt arkitekturkonkurrence. Projekter resulterer oftest i en projektrapport, som de studerende bliver eksamineret mundtligt i. En projektrapport har typisk to slutresultater: en konklusion, der besvarer problemformuleringen ved at sammenfatte projektets løsning, og en anbefaling til virksomheden om løsningens implementering. Anbefalingen til virksomheden kan nemt forstås af virksomhedens medarbejdere og giver mening i virksomhedens kontekst. Nedenfor gives et eksempel på et teknisk projekt i en virksomhed. Dette projekt er udført af studerende fra flere forskellige studieretninger.

Eksempel på et tværfagligt projekt på diplomingeniøruddannelsen

Virksomheden FOOD Measurement Systems (fiktiv virksomhed) udvikler, producerer og sælger måleapparater til fødevarevirksomheder. FOOD Measurement Systems vil udvikle et måleapparat til virksomheder i en ny branche, nemlig medicinalbranchen. Virksomheden har indledt et samarbejde med en gruppe ingeniørstuderende. Formålet med projektet er et konkret forslag til design af måleapparatet, herunder funktioner og udformning. 1. En undersøgelse af, hvilke krav den nye kundegruppe har til måleapparater, og en analyse af, hvordan disse krav påvirker den tekniske udformning af det nye måleapparat 2. Et konkret forslag til måleapparatets funktioner, software og fysiske udformning samt anvisninger til apparatets drift. Projektgruppen indsamler først data, bl.a. gennem en række interviews med potentielle kunder i medicinalbranchen og gennem et besøg på en medicinalfabrik, hvor et af de nye måleapparater kunne stå. Undersøgelsen resulterer i følgende to krav: Måleapparatet skal have fysiske dimensioner, der passer til medicinalproducenternes produktionslinjer Måleapparatet skal kunne kommunikere direkte med medicinalproducenternes ITsystemer, således at det løbende kan levere måleresultater til de rapporter, hvori medicinalproducenterne skal dokumentere produkternes kvalitet. På baggrund af disse to krav samt specificeringen af, hvilke konkrete målinger apparatet skal udføre, udarbejder projektgruppen en løsning. Løsningen består af et sæt tekniske tegninger af det redesignede måleapparat og en række diagrammer, der specificerer softwareprogrammet i apparatet. Det færdige apparat passer ind i medicinalproducenternes produktionslinjer og kan kommunikere direkte med deres ITsystemer. Eksemplet viser, hvordan projektgruppen først forsøger at forstå situationen og nedfælde en problemformulering. Dernæst indsamler og analyserer gruppen data, og til sidst designer de løsningen. Det naturlige skridt herefter vil være implementering af løsningen, hvilket i dette eksempel vil være et samarbejde med virksomhedens produktionstekniske afdeling omkring fremstillingen af hele serier af apparatet. Se mere om implementering i kapitel 8.

De problemtyper, tekniske projekter løser projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Grundlæggende handler projekter på tekniske uddannelser enten om 1) at forbedre noget eksisterende eller 2) at designe nyt fra bunden. Et projekt, der forbedrer noget eksisterende, kan fx handle om at forbedre en maskines holdbarhed, mens et projekt, der designer noget nyt fra bunden, kan handle om at designe en ny bygning ud fra en defineret række krav. De to typer projekter udgør de to kolonner i figur 1.2. Rækkerne i figur 1.2 viser, at tekniske projekter typisk handler om at designe en struktur (fx et produkt eller en bygning) eller en proces (fx en kvalitetsstyringsprocedure eller en matematisk algoritme). Kolonnerne og rækkerne udgør en matrix, der illustrerer fire arketyper af projekter på tekniske uddannelser.

Figur 1.2. Typer af problemer i tekniske projekter

"Problemet" i projekter i venstre kolonne er, at noget enten er for dårligt eller har et klart forbedringspotentiale. I højre kolonne er problemet, at noget, som en virksomhed gerne vil have, ikke eksisterer. Et teknisk projekt løser dette "det findes ikke"-problem ved at designe løsningen (fx bygningen, produktet, det kemiske stof, proceduren eller planlægningsmetoden). Se mere om problemtyper i kapitel 3 om problemformuleringen i tekniske projekter.

Processen i tekniske projekter projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Når problemet er defineret og problemformuleringen nedfældet, så følger projektets kerneaktiviteter: analyse, design og implementering (se figur 1.3). Selvom der er forskel på, hvilken tyngde de enkelte uddannelser lægger på hvert af disse tre skridt, er alle tre skridt oftest en del af et teknisk projekt.

Figur 1.3. Processen i tekniske projekter

Kapitel 2. Projektopstart – begyndelsen er ofte kaos og virvar projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I dette kapitel lærer du: At du i begyndelsen af en projektperiode vil opleve projektarbejdet som et kaotisk virvar. Du lærer, at det med erfaring bliver nemmere at arbejde i dette kaotiske virvar, og at gode ideer ofte opstår i denne del af projektperioden. At forstå, hvordan projektet er den pædagogiske metode i et kursus, der har en række læringsmål. Du lærer, at projekter kan have projektbeskrivelser, og at underviserne kan strukturere et projektforløb med en række milepæle. Hvordan du og din projektgruppe hurtigt kan blive klogere på projektets faglige tema, så den problemanalyse, der leder frem til jeres problemformulering, bliver god og effektiv. Hvordan du kan gennemføre en problemanalyse, så den ender med en specificeret problemformulering. At en problemanalyse ofte begynder med et ønske fra virksomheden, som du og din projektgruppe skal forholde jer kritisk til ved at stille de rette spørgsmål. At bruge semistrukturerede interviews og et problemtræ til at gennemføre en problemanalyse. Dette kapitel behandler tiden fra projektperiodens begyndelse, til at I som projektgruppe har nedfældet jeres problemformulering. Kapitlet beskriver først, hvordan I som projektgruppe skaber de bedste forudsætninger for projektet, og derefter, hvordan I kommer frem til en problemformulering, der tilfredsstiller både universitet, virksomhed og jer selv. Kapitel 9 og 10 behandler også temaer, der er relevante i opstartsfasen af et projekt. Kapitel 9 behandler gruppedannelse, samarbejdskontrakter og gode forudsætninger for samarbejde internt i jeres gruppe. Kapitel 10 behandler det gode virksomhedssamarbejde, og herunder hvordan I kan finde en virksomhed at samarbejde med.

Den første tid i projektperioden projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Begyndelsen af en projektperiode er oftest præget af kaos og virvar. Det er svært at gennemskue, hvad det hele skal munde ud i, og man har intet overblik over noget. Det er vigtigt, at du er bevidst om dette og holder hovedet koldt. Projekter i dit arbejdsliv efter endt uddannelse er også præget af kaos og virvar, fordi et projekt typisk først er aktuelt, når der opstår et problem, som ingen medarbejder kan løse alene. I arbejdslivet efter endt uddannelse føles opstartsfasen dog oftest knap så uoverskuelig, fordi du hurtigt bliver en erfaren og professionel deltager i projektarbejde. Fra semester til semester vænner du dig langsomt til at "være til" i den kaotiske opstartsperiode. Nogle personer ender endda med at kunne lide den første tid, fordi rammerne for projektet her stadig er brede. Denne periode er nemlig den mest åbne, særligt i de frie projekter på din uddannelse, og derfor opstår gode ideer typisk her, midt i kaosset.

De faglige mål med projektet projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Alle kurser på moderne danske uddannelser har (eller bør have) et specifikt sæt af læringsmål. Det er læringsmålene, der udgør grundlaget for evalueringen af kurset og derfor også eksamenskaraktererne. For projektbaserede kurser er der også læringsmål. Det er den kursusansvarlige undervisers opgave at sikre, at læringsmålene opfyldes gennem projektarbejdet, og at formidle disse læringsmål til hele klassen.

Formidling af projektets læringsmål og de aktiviteter, der indgår i projektet På projekter på uddannelsens tidlige semestre er læringsmålene ofte integreret i projektbeskrivelser, der kan være ganske lange og komplicerede. Projektbeskrivelserne konkretiserer læringsmålene, og det er derfor vigtigt for dig at forstå projektbeskrivelsen helt ned i detaljen. Et projekt kan være delt ind i en række faser, der er adskilt af milepæle. Hvis det er tilfældet, er det ikke nødvendigt at have styr på hele projektbeskrivelsen fra første færd, men i stedet arbejde sig frem – fase for fase. Hvis I som klasse eller projektgruppe er i tvivl om formuleringer i projektbeskrivelsen, fx om aktiviteternes præcise indhold, er det undervisernes ansvar at afklare alle spørgsmål. I skal dog som gruppe eller klasse finde ud af, hvad I konkret mangler svar på. Et godt tip er derfor at have "Gennemgang af projektbeskrivelse" som et punkt på dagsordenen på de første to-tre projektgruppemøder. Her kan I sammen sikre, at I har forstået hele projektbeskrivelsen til punkt og prikke. I visse tilfælde kan I risikere at få et projektkursus uden en skriftlig projektbeskrivelse. Her er det vigtigt at lytte godt efter, når underviseren mundtligt forklarer læringsmål og indhold af projektet. I frie projekter, der typisk ligger senere på uddannelsen, er der ofte ingen projektbeskrivelse. Der har I kun læringsmålene og underviserens mundtlige forklaring. Når underviser forklarer projektindholdet, er det vigtigt at spidse ører og tage grundige noter. Et godt råd er at aftale med de andre projektgrupper i klassen at stille eventuelle opfølgende spørgsmål skriftligt og aftale med underviseren, at han eller hun besvarer disse spørgsmål skriftligt på kursets side på intranettet. På den måde får alle grupper glæde af hinandens spørgsmål.

De første skridt i et frit projekt projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Det første, I som studerende skal gøre, når I skal i gang med et frit projekt, hvor I som projektgruppe selv skal formulere jeres problem og selv vælge metode, er at vælge et projekttema. Nogle studerende er målrettede og ved præcist, hvilket fagligt tema de gerne vil lave projekt om, mens andre bare er glade for, at nogen vil vælge for dem. Når det faglige tema er på plads, skal I (1) begynde at løfte vidensniveauet om projektets faglige tema i jeres projektgruppe og (2) finde en virksomhed at samarbejde med. Sidstnævnte behandles i kapitel 10. Vidensniveauet kan I løfte ved at læse litteratur om det faglige tema og tale med de undervisere, der ved noget om temaet (dette er ofte jeres vejleder). Her er en række anbefalinger til, hvordan I kan lokalisere relevant litteratur og få gode ideer: Lån lærebøger, der behandler jeres faglige tema Se efter bøger og artikler om temaet i litteraturlisterne i lærebøgerne Anvend grovkornede søgninger i universitetets digitale bibliotek Få vejlederens umiddelbare ideer Tal gerne med andre undervisere, der måske har større erfaring med jeres tema end jeres vejleder. I den tidlige fase af et projekt er det den brede søgning og læsning af litteratur, der er i fokus. Denne læsning giver jer ideer til både problemer, som I kan arbejde med, og mulige løsninger. Den viden, I opnår ved at læse litteratur om projektets faglige tema, er et godt grundlag for jeres evne til at foretage en problemanalyse i den virksomhed, I samarbejder med.

Problemanalysen Problemanalysen er rejsen fra den første kontakt med virksomheden, til problemformuleringen er fundet. Når emnet er besluttet, og vidensniveauet er på plads, så er jeres første egentlige opgave at finde projektets problem og nedfælde problemformuleringen. Udgangspunktet for denne aktivitet er ofte ganske rodet.

Figur 2.1. Problemanalysen

Typisk har den virksomhed, I samarbejder med, et ønske om, at I skal levere noget. Nedenfor ses to eksempler.

Eksempler på virksomheders ønsker til en projektgruppe 1. En virksomhed, der udvikler og producerer væskeblandingsmaskiner, siger til jer: "Vi kunne godt tænke os, at I så på de maskiner, der blander væsker." Her er der ingen forklaring på, hvorfor maskinerne trænger til at blive "kigget på". Jeres opgave i problemanalysen er derfor at identificere, hvad der er problemet med maskinerne. 2. En anden virksomhed, der producerer medicin i pilleform, fortæller jer, at de gerne vil have automatiseret den pakkeproces, der pakker de færdige pilleæsker på paller. I problemanalysen er det jeres opgave at identificere det problem, som en automatiseret proces løser. Ingen af eksemplerne peger på et problem, men tværtimod peger de på en løsning. Virksomhederne ønsker sig altså en løsning uden at have specificeret det problem, som løsningen afhjælper. Når den medarbejder, I har den indledende dialog med, har udtrykt virksomhedens ønske til projektet, er det jeres opgave at finde frem til problemet. Dette gør I ved fx at spørge: "Hvorfor lige netop [løsning]?". Svaret på dette spørgsmål er ideelt set det problem, virksomheden har. "Det er, fordi [problem]", eller "Vi mangler løsningen, fordi … [problem]". Figur 2.2 illustrerer de typiske skridt fra virksomhedens ønske og frem til et verificeret problem, som kan indgå i jeres problemformulering. At verificere problemet betyder at sikre sig, at problemet faktisk findes.

Figur 2.2. Nærmere specificeret problemanalyse

Det er ikke altid nemt at finde frem til det problem, som virksomheden ønsker sig en løsning på. Faktisk er det ganske almindeligt, at en virksomhed slet ikke ved, hvilket problem de ønsker sig en løsning til. Det kan være, at en af virksomhedens medarbejdere har været til en konference og set, at en konkurrent har en given løsning, og tænkt "Sådan en vil jeg også have!". Det kan også være, at virksomheden bare vil hjælpe jer med et projekt uden at have tænkt så meget over, hvad projektet skal handle om. Hvis en virksomhed ikke umiddelbart kan forklare, hvilket problem deres ønskede løsning løser, er det jeres opgave kritisk at vurdere, om der i det hele taget er et problem, hvor stort det er, og hvordan den løsning, som virksomheden ønsker sig, udgør en faktisk løsning på problemet. Dialogen med virksomheden omkring, hvorfor virksomheden ønsker sig en given løsning, kan være svær, særligt på dette tidlige tidspunkt i forløbet, hvor jeres personlige relationer til jeres kontaktperson i virksomheden ikke er særligt dybe. I tænker måske, at virksomhedens kontaktperson er dygtig og erfaren og derfor må vide, hvorfor den ønskede løsning er vigtig at få designet og implementeret. Som studerende kan man nemt tro, at hvis man ikke selv kan se, hvilket problem løsningen afhjælper, er det nok, fordi man ikke er dygtig og erfaren nok. Sådan er det dog ikke altid, så sørg for selv at identificere og forstå problemet. Jeres eksaminator og censor forventer, at I forholder jer kritisk til en virksomheds ønske. Nedenfor gives to råd til samtaler med virksomheder omkring problemanalysen.

Forslag til samtaler om problem og løsning med virksomhed 1. Anvend den bløde formulering "Hvordan kan det være, at I ønsker jer lige netop [løsning]?" Denne formulering fremstår knap så kritisk som "Hvorfor …?" 2. Foreslå selv et muligt problem, som den løsning, virksomheden ønsker sig, afhjælper. Spørg fx: "Vil I gerne have løsningen, fordi [muligt problem]?" Hvis I rammer plet med det foreslåede problem, så har I fundet problemet, og hvis I ikke rammer plet, vil jeres spørgsmål få jeres kontaktperson til selv at tænke over, hvad problemet er. Kan jeres kontaktpersonen hurtigt og præcist beskrive problemet, så har problemet sandsynligvis været diskuteret før i virksomheden. Kan kontaktpersonen derimod ikke beskrive problemet under samtalen, er det jeres opgave at identificere det.

Verificering og kvantificering af problemet Den dialog, I har med jeres kontaktperson i virksomheden, foregår typisk på møder, under virksomhedsbesøg og gennem mailkorrespondance. Gennem dialogen får I langsomt gravet jer frem til det problem, som jeres projekt skal designe en løsning på.

Når kontaktpersonen beskriver problemet, kan der være konkrete data, der viser problemet. Disse data kan være en kvantitativ analyse, fx et scatter-diagram, der viser, at udviklingen i returneringer af et produkt har en opadgående trend med flere og flere returneringer. Data om problemet kan også være kvalitative, fx en række samtaler med sælgere, der fortæller om kunders utilfredshed med produktet og deres returneringer. Samtaler er ikke lige så sikre data som et scatter-diagram, men de giver dog en stærk indikation af, at problemet findes. Som studerende kan man godt komme ud for, at kontaktpersonen i en virksomhed hævder, at der er et problem, som ved nærmere eftersyn viser sig ikke at være et problem.

Eksempler på et ikke-eksisterende problem En projektgruppe taler med en virksomhed om et projekt. Virksomhedens kontaktperson fortæller, at maskinerne i produktionen "altid står stille", og at virksomheden ønsker en større udnyttelse af maskinerne. 1. Projektgruppen taler med operatører og produktionsplanlæggere og finder ud af, at maskinerne kun står stille en gang imellem, og at dette ikke giver leveringsproblemer fra produktionen. Problemet findes ikke. 2. Projektgruppen finder ud af, at maskinerne faktisk står stille det meste af tiden. Gruppen finder dog også ud af, at det er, fordi maskinerne kun producerer noget, når der er brug for, at de producerer noget. Problemet findes ikke. Hvis virksomheden er klar over problemet, har de måske konkrete data, der dokumenterer problemet. Det kan også være, at de blot har en række historier, der indikerer, at problemet findes. Hvis der ikke er dokumentation for problemet, er det en del af jeres arbejde at dokumentere det og at kvantificere dets størrelse (se mere herom i kapitel 6). I skal kende til problemets størrelse, fordi I senere i projektforløbet skal vurdere, hvor stor en effekt jeres løsning vil have på problemet.

Eksempel på, hvordan man anvender den kvantificerede problemstørrelse til vurdering af løsningens effekt En virksomhed har en fabrik i Danmark og distributionscentre rundt omkring i verden, bl.a. i Kina. Fra distributionscenteret i Kina sender virksomheden varer til alle deres kinesiske kunder. Virksomheden mener, at alt for mange af deres ordrer til de kinesiske kunder leveres forsinket. En projektgruppe af studerende undersøger situationen og finder ud af, at 42 % af ordrerne til kinesiske kunder bliver leveret for sent. Størrelsen på projektets problem er således 42 %. Når løsningen er designet, kan projektgruppen foretage vurderinger af, hvor meget den reducerer de 42 % med.

De studerende undersøger, hvorfor ordrer leveres forsinket. Årsagen er, at distributionscenteret i Kina alt for ofte venter på forsyninger fra fabrikken i Danmark. De studerende udvikler en løsning bestående af to løsningselementer: 1. En ny politik for genbestillinger fra distributionscenteret i Kina til fabrikken i Danmark 2. Nye gennemberegnede sikkerhedslagre på det kinesiske distributionscenter. Projektgruppen vurderer løsningselementernes effekt på de 42 %. Løsningselement 1 vil reducere andelen af forsinkede ordrer med 24 %, så den falder fra 42 til 18 %. Løsningselement 2 forbedrer leveringsevnen med yderligere 14 %, så andelen af forsinkede ordrer falder fra 18 % helt ned til 4 %. Den samlede effekt af løsningen på projektets problem er altså en reduktion af andelen af forsinkede ordrer fra 42 til 4 %. Mange tekniske projekter handler ikke om at forbedre noget eksisterende, men om at designe noget nyt fra bunden. I sådanne projekter er opgaven ikke at identificere et problem, men at definere og specificere et behov. Nogle gange er behovet dog et symptom på et underliggende problem, som I som projektgruppe bør identificere og forstå. En virksomhed siger fx, at de har et behov for en ny maskine. Projektgruppen spørger, hvordan det kan være. Virksomheden fortæller, at deres aktuelle maskine kræver for meget vedligehold. Problemet i dette projekt er derfor et stort vedligeholdelsesbehov på deres aktuelle maskine snarere end et behov for en ny maskine. Andre gange er der et behov, som det ikke giver mening at spørge ind til. Hvis en entreprenør fx gerne vil have designet en bygning, fordi en klient gerne vil have bygningen, er det uden for en projektgruppes scope at forholde sig kritisk til behovet. Det er dog altid vigtigt at forstå og specificere behovet.

Værktøj til brug i problemanalysen projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Problemanalysen er en iterativ proces, hvor I som projektgruppe løbende taler med virksomheden og jeres vejleder, samtidigt med at I læser litteratur og konsulterer jeres egne ønsker til projektindhold. Hvis I sammen med virksomhed og vejleder hurtigt kan se og definere problemet, er der ofte blot brug for en enkelt iteration. I den iterative proces kan I anvende semistrukturerede interviews til indsamling af information og et problemtræ til strukturering af information. De semistrukturerede interviews anvendes i samtaler med virksomheden. Inden interviewene nedfælder I ved hjælp af den litteratur, I har læst, en række spørgsmål, der afsøger terrænet. Interviewene kaldes semistrukturerede, fordi de dels indeholder samtale struktureret omkring jeres på forhånd nedfældede spørgsmål, og dels samtale, der flyder frit og giver plads til at udforske ukendte problemer og årsager. Problemtræet er et konkret værktøj, som I kan anvende til at strukturere analysen og alle de indsamlede informationer. Hvis det faglige område har simple og endimensionelle årsagssammenhænge, er det ofte nok at spørge "Hvorfor …?" (som beskrevet tidligere i kapitlet), men er det mere komplekst, har man brug for værktøj til få overblik over de årsagssammenhænge, der er relevante i problemanalysen.

Figur 2.3. Problemtræ

Figur 2.3 illustrerer et problemtræ. Linjerne mellem boksene viser årsagssammenhængene i træet. Se evt. kapitel 4 og 6, der viser to konkrete eksempler. Det er ofte op til jer som projektgruppe at vælge, hvilken boks i træet der skal være jeres projekts problem. Det valgte problem udgør udgangspunktet for jeres analyse. I figur 2.4 repræsenterer den grønne baggrund jeres projekt. Den øverste kasse inden for det

grønne felt udgør projektets valgte problem, og kasserne umiddelbart under projektets problem udgør problemets årsager. Årsagerne finder I frem til gennem projektets årsagsanalyse (ikke problemanalysen, men årsagsanalysen, der ligger senere i projektet). Se mere om anvendelsen af problemtræer i årsagsanalyser i kapitel 6.

Figur 2.4. Det valgte problem i problemtræet

Projektet som delprojekt i et større projekt projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Nogle projekter indgår som en del af et større projekt i virksomheden. Disse overordnede projekter, der indeholder delprojekter, kaldes nogle gange for program- eller projektportefølje. En projektportefølje kan fx handle om at gennemføre en større række forbedringer af en virksomheds drift. Nogle delprojekter i projektporteføljen handler om salg, andre om logistik og igen andre om produktudvikling. En virksomhed kan fint bruge jer som tekniske studerende til at arbejde med et delprojekt og give jer et selvstændigt ansvar. I så fald vil I referere til lederen af projektporteføljen, der som regel er en erfaren projektleder. Der er en række fordele ved at få lov at stå for sådan et delprojekt: 1. I har gennem hele processen virksomhedens opmærksomhed 2. I har adgang til data, og medarbejderne i virksomheden er helt med på, at I får data udleveret 3. I får erfaring med projektledelse og at være del af en projektorganisation. Der er dog også to vigtige faldgruber ved denne type projekter. For det første kan I være meget bundne. Det er vigtigt, at I får frihed til at gennemføre projektet, uden at projektporteføljelederen løbende laver om i jeres problemformulering eller inkluderer nye emner i jeres projekt. Et godt projekt er fokuseret og tager ikke nye ting med på må og få. For det andet kan det være svært for eksaminator og censor at afgøre, hvilke dele af projektrapporten der er jeres arbejde, og hvilke der er virksomhedens. Dette skal være klart, når jeres projekt skal bedømmes. Er det jer, der har gennemført en given analyse, eller kommer den udefra? Hvis eksaminator og censor er i tvivl, er der en betragtelig risiko for, at I ikke får "credit" for jeres arbejde, idet de kan tro, at andre har udført opgaven.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Opsummering

I dette kapitel har du lært, hvordan I som projektgruppe i begyndelsen af en projektperiode vil opleve projektarbejdet som et kaotisk virvar. Gennem erfaring bliver du mere vant til at arbejde i dette kaotiske virvar, og du begynder måske endda at sætte pris på denne tid med frie rammer til kreativ tænkning. I begyndelsen af et projekt arbejder I med jeres problemanalyse, der munder ud i problemformuleringen. Du har lært, at denne problemanalyse tit begynder med et ønske til en løsning fra den virksomhed, som I samarbejder med. Jeres opgave er at forstå, hvilket problem problemløsningen adresserer. Dette problem bliver ofte jeres projekts problem, som I indskriver i jeres problemformulering. Kapitlet beskriver, hvordan I til problemanalysen kan anvende semistrukturerede interviews til indsamling af information og et problemtræ til strukturering af informationen.

Kapitel 3. Problemformuleringen projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I dette kapitel lærer du: At et projekt på en teknisk uddannelse handler om at løse et problem Hvad et problem i det hele taget er i et teknisk projekt At problemer i tekniske projekter typisk handler om at forbedre noget eksisterende eller opfylde et behov ved at designe noget nyt fra bunden Hvordan problemformuleringen konkret kan formuleres Hvilke komponenter en god problemformulering består af At gode problemformuleringer demonstrerer fokus og kvantificerbarhed Hvordan man ud fra problemformuleringen kan udlede underspørgsmål, og hvad der udgør acceptable og ikke-acceptable underspørgsmål Afgrænsninger fra problemformuleringen. Et projekt på en teknisk uddannelse handler om at designe en løsning på et problem. Ordet 'problem' betyder her ikke det samme som i dagligdags brug (fx at man har glemt sine nøgler eller er kommet for sent til et møde). I tekniske projekter er et problem oftest en af følgende to muligheder: 1. Noget eksisterende er for dårligt og kan forbedres (fx et produkts holdbarhed, opstartshastigheden på en app eller effektiviteten af en kemisk proces) 2. Nogen ønsker sig noget, der endnu ikke findes (fx en bygning, et produkt eller en algoritme). I projekter af type 1 vil et projekt, der fx adresserer et produkts lave holdbarhed, løse problemet ved eksempelvis at redesigne produktet eller ændre i produktets materiale. I projekter af type 2 er problemet, at nogen (fx i den virksomhed, som I samarbejder med) ønsker sig et eller andet, der endnu ikke findes. Hvis fx en producent af motorcykler ønsker sig en ny type udstødningsrør, så løser I problemet ved at designe denne nye type udstødningsrør. Generelt kan man sige, at projekter med problemtype 1 forbedrer noget eksisterende, og projekter med problemtype 2 designer noget nyt fra bunden. Arbejdet med at finde frem til det problem, I ønsker at arbejde med, er beskrevet i det foregående kapitel. Dette kapitel beskriver, hvordan I udarbejder selve problemformuleringen, der skal agere styrmand for hele jeres projekt. Kapitlet redegør

først for fire generelle typer af problemformuleringer. Dernæst beskriver kapitlet sammenhængen mellem problemformulering og metode, karaktertræk ved gode problemformuleringer og brugen af underspørgsmål til problemformuleringen.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Problemtyper

Figur 3.1 viser en matrix med fire generelle problemtyper i tekniske projekter. De to kolonner i matrixen svarer hhv. til projekter, der forbedrer noget eksisterende, og projekter, der designer noget nyt fra bunden. Figurens to rækker deler tekniske projekter op i projekter, der omhandler en struktur, og projekter, der omhandler en proces.

Figur 3.1. Typer af problemer i tekniske projekter

Ordet struktur betyder den logiske opbygning af noget. I et teknisk projekt kunne dette "noget" være et produkt, en komponent, en maskine eller en bygning. En proces er en sekvens af skridt, fx en produktionsproces eller en kvalitetsprocedure. Det er forskelligt fra den ene tekniske uddannelse til den anden, hvilke projekter der er flest af. For eksempel ligger de fleste projekter på bygningsingeniøruddannelsen i øverste højre hjørne og på produktionsingeniøruddannelsen i nederste venstre hjørne. I det følgende vil vi se nærmere på opbygningen af problemformuleringer i tekniske projekter.

Problemformuleringer i projekter, der forbedrer noget eksisterende projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Tabel 3.1 viser problem, metode og konklusion i projekter, der forbedrer noget eksisterende. Konkrete eksempler på problemer er: Projekter, der forbedrer noget eksisterende Problem

Noget er for dårligt eller kan forbedres. For eksempel et produkt, der ikke holder længe nok, eller en produktionslinje med alt for høj kassationsrate.

Metode

Trin 1: En analyse af årsagerne til problemet. Trin 2: Udvikling af løsninger til eliminering af problemets årsager eller reducering af årsagernes effekt på problemet.

Konklusion

En sammenfatning af løsningen, som virksomheden kan implementere for at afhjælpe problemet. Løsningen kan med fordel testes, inden den anbefales af projektgruppen.

Tabel 3.1. Projekter, der forbedrer noget eksisterende en produktionslinje, der producerer for mange produkter af lav kvalitet en komponent til en vindmølle, der for ofte skal serviceres lageromkostninger i et logistiksystem, der er for høje et produkt, der returneres for ofte fra kunder i et nyt marked. Et problem kan være en "det er for dårligt"-situation (fx at kvaliteten på en produktionslinje er gået ned ad bakke de sidste 6 måneder og skal op igen). Det kan blot også være et potentiale for forbedring ("Vi har hørt, at konkurrentens vindmøller kun behøver servicering én gang om året, hvor vores vindmøller skal serviceres to gange om året"). I skal betragte et uforløst potentiale som et problem.

Problemformuleringens sproglige opbygning Når I som projektgruppe har valgt og nedskrevet problemformuleringen, skal alle jeres fremtidige valg ske i lyset af denne. Eksaminator og censor vil vurdere jeres valg ud fra problemformuleringen. Derfor er det essentielt, at den er meningsfyldt formuleret.

I projekter, der forbedrer noget eksisterende, er problemformuleringer ofte opbygget af en række faste sproglige komponenter. Her er et eksempel på en problemformulering på et teknisk projekt. Hvordan kan Hansen A/S reducere kassationsraten af produktet AB1280 på produktionslinje 10? Problemformuleringen i sådanne projekter, der handler om at afhjælpe det, der er for dårligt, begynder typisk med ordene "Hvordan kan …?". Derefter følger ofte virksomhedsnavnet (fx Hansen A/S). Dette navn behøver ikke være et virksomhedsnavn, men bør være navnet på den aktør, der har problemet og har engageret projektgruppen til opgaven. Efter virksomhedsnavnet følger den handling, virksomheden ønsker. Denne handling udtrykkes ved et af de to verber øge eller reducere. Efter verbet følger den variabel, som projektet vil forbedre. Alt afhængigt af teknisk felt kan variablen fx være leveringsevnen, gennemstrømningen, holdbarheden, sporbarheden, hastigheden, vægten, nøjagtigheden, variationen, omkostningen, volumen, viskositeten, længden, dybden eller kapaciteten. Efter variablen følger ofte en eller flere specificeringer af, hvor og hvornår problemet findes. I eksemplet ovenfor ses to specificeringer, nemlig "af produktserien AB1280" og "på produktionslinje 10". Andre eksempler på specificeringer kunne være "af produktionen af aktivt stof" (på kemiingeniøruddannelserne), "af motoren i måleapparatet" (på maskiningeniøruddannelsen) eller "af dronens batteri" (på elektronikingeniøruddannelsen). Problemformuleringen kan indeholde væsentlige forudsætninger. For eksempel kan et projekt, der handler om reduktion af et produkts vægt, indeholde specificeringen "under forudsætning af, at produktets styrke forbliver den samme". Forudsætningerne omhandler de variable, der er logisk eller naturligt knyttet til den variabel, der ønskes ændret. Der er fx et naturligt forhold mellem vægt og styrke (alt andet lige er forholdet således: jo stærkere, jo tungere). Her er tre andre eksempler på naturlige sammenhænge, der alt andet lige gælder mellem variable: 1. Jo højere grafikkvalitet et program kører med, jo større er kravene til processorkraft 2. Des hurtigere en forbrændingsmotor kører, des mere støjer den 3. Jo højere kvaliteten er på et seriefremstillet produkt, jo højere er fremstillingsomkostningerne. Problemformuleringen kan indeholde en metodeafgrænsning. Man kan fx tilføje "gennem [metodens navn]" i problemformuleringen. Eksempelvis kan et projekt ville reducere materialeomkostninger "gennem valg af nyt materiale". En sådan afgrænsning betyder, at projektet ikke vil bevæge sig ind i redesign af emnet, men kun skal arbejde med materialevalg. Tabel 3.2 sammenfatter det samlede sæt af komponenter i problemformuleringen.

Komponenter i problemformuleringen på tekniske projekter, der forbedrer noget eksisterende Spørgeord

Hvordan kan …?

Aktør

Den organisation, afdeling eller enhed, der ønsker problemet afhjulpet

Handling

Et af de to verber øge eller reducere

Variabel

Den variabel, der ønskes forbedret

Specificeringer

Fortæller, hvor og hvornår problemet findes

Forudsætninger

Fortæller, hvilke andre variable der ikke må forringes

Metodeafgrænsning

Afgrænser projektet til at anvende en bestemt metode

Tabel 3.2. Komponenter i problemformuleringen Som et eksempel på en problemformulering, der indeholder alle disse komponenter (undtagen den sidste), kan nævnes følgende: Hvordan kan Jensen A/S reducere servicebehovet på elektriske convertere i vindmøller af typen VB1400 under forudsætning af, at det salte miljø inde i møllen forbliver uændret? Her er Jensen A/S den aktør, der ønsker problemet afhjulpet. Problemet er et for højt servicebehov af elektriske convertere, hvilket Jensen A/S ønsker reduceret (handlingen). Variablen er servicebehovet. Problemformuleringen specificerer, at der er tale om convertere i vindmøller af typen VB1400, og at projektet skal reducere converternes servicebehov under den forudsætning at det miljø, som converterne arbejder i, forbliver uændret. Der kan således ikke arbejdes med ændring af det salte miljø, fx gennem bedre isolering af møllehuset. Problemformuleringen kunne have indeholdt en metodeafgrænsning, fx "gennem redesign af converterne". Der er dog god mulighed for at beskrive afgrænsninger af projektet i det afsnit, der følger problemformuleringen (mere herom senere). Da problemformuleringen om Jensen A/S allerede er lang, er det en god ide at beskrive metodeafgrænsningen separat.

De to rækker i figur 3.1 deler tekniske projekter op i projekter, der omhandler hhv. en struktur og en proces. En struktur er en logisk opbygget enhed, fx et produkt, en bygning eller en app. En proces er en sekvens af skridt, fx en produktions- eller kvalitetssikringsproces. I strukturprojekter er virksomhedsnavnet ofte ikke så direkte relevant, idet projektets omdrejningspunkt ikke er driften eller udviklingen af virksomhedens processer, men derimod den pågældende struktur (fx en produktopbygning). Derfor er virksomhedsnavnet typisk ikke en del af problemformuleringen. To eksempler på denne type problemformulering er: Hvordan kan vægten af et håndholdt kamera reduceres under forudsætning af fuld funktionalitet og holdbarhed? Hvordan kan hastigheden af målingerne udført af instrumentet AU3000 øges?

Problemformuleringen i projekter, der handler om at designe noget nyt projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Projekter, der designer noget nyt fra bunden Problem

Det, som virksomheden ønsker udviklet (fx et kemikalie, en algoritme, en maskinkomponent eller en ny planlægningsprocedure). Problemet er således et behov.

Metode

Trin 1: Fastlæggelse af krav til løsningen. For en maskine kan disse krav fx være fysiske dimensioner og belastningsevne, og for en bygning kan de omhandle varmekilde, lysindfald, ind-/udgange, m.m. Kravene kan også være mere bløde, fx at en bygningsfacade skal tilfredsstille en kundes ønsker til æstetik. Trin 2: Udvikling af løsning. For en maskine kunne dette være tekniske tegninger. Løsningen er således et design, der opfylder det behov, som problemformuleringen har defineret.

Konklusion

En sammenfatning af den udviklede løsning samt eventuelle anbefalinger til implementering.

Tabel 3.3. Projekter, der designer noget nyt fra bunden Problemformuleringen i denne type projekter er en præcis beskrivelse af det behov, virksomheden har til en løsning. I det arbejde, der går forud for behovsbeskrivelsen, bør I som projektgruppe forholde jer kritisk til, hvorfor virksomheden har behovet. I bør stille direkte spørgsmål om, hvorfor virksomheden har det pågældende behov. Svaret herpå kan nemlig lede frem til et andet behov end det, virksomheden oprindeligt gav udtryk for. Se mere om den proces, der går forud for problemformuleringen, i kapitel 2.

Problemformuleringens sproglige opbygning Problemformuleringen i projekter, der designer noget nyt fra bunden, er en behovsbeskrivelse. Introduktionen, der går forud for problemformuleringen, skal klargøre, hvem der har behovet (fx en organisation eller en afdeling i en virksomhed), og evt.

hvorfor de har behovet. I problemformuleringsteksten kan det være nødvendigt at genopridse dette, så det står klart og friskt for læser. Herefter kan I give en præcis beskrivelse af selve behovet. I beskrivelsen af behovet bør I gøre det klart for læser, hvad det særlige er ved behovet. Er behovet en bygning, hvilke særlige krav er der så til denne bygning. Er det en app, hvad kan så denne app, som andre eksisterende apps ikke kan. Dette særlige ved behovet kan være relateret til en specifik variabel. Her er tre eksempler (variabel er kursiveret): En ny rengøringsprocedure med mindre kemikalieforbrug En ny bygning med lavere varmeudledning En ny version af en maskine med lavere energiforbrug. Ofte er behovet knyttet til økonomi. En rengøringsprocedure, der gennemføres med færre kemikalier, betyder reducerede kemikalieomkostninger. Behovet kan også handle om nye krav til bæredygtighed eller arbejdsmiljø. For eksempel kan behovet om en bygning med lavere varmeudledning komme fra opdaterede krav til nybyggeri. Behov kan også handle om kundekrav. Kapitel 1 beskriver et eksempel herpå (en ny version af et måleapparat til en ny kundegruppe med andre krav end de hidtidige kunder). Problemformuleringens behovsbeskrivelse kan være mere vagt formuleret end de tre eksempler ovenfor. Her er to eksempler: (a) en bygning med bedre adgang for borgere med funktionsnedsættelse og (b) et program, der er mere brugerorienteret. Disse to behovsbeskrivelser skal specificeres nærmere (altså hvad "bedre adgang" eller "mere brugerorienteret" konkret betyder). Denne nærmere specificering kan I ofte først gøre senere i projektet, når I har indsamlet og analyseret data. I problemformuleringen er det er vigtigt, at I beskriver behovet ud fra virksomhedens forretningsmæssige syn og ikke ud fra tekniske krav. Hvis et projekt handler om at reducere et produkts produktionsomkostninger gennem redesign og materialeændringer, så bør problemformuleringen forklare behovet om reducerede omkostninger. Senere i projektet kan I så beskrive, hvordan redesign og materialeændringer kan realisere omkostningsreduktioner. I projekter, der designer noget nyt, udgør behovsbeskrivelsen således projektets problemformulering. Behovsbeskrivelsen danner baggrund for identificeringen af de konkrete og målbare tekniske krav til løsningen, der ofte står sammenfattet i en kravspecifikation. Nøglen til en god løsning i et teknisk projekt, der designer noget nyt fra bunden, er at identificere og forstå alle relevante krav til løsningen. I skal gennem en grundig analyse forstå løsningens brugssituation, hvordan løsningen teknisk integrerer med sin omverden, og hvilke love, normer, regler og faglige standarder løsningen skal overholde. Se kapitel 6 om dataindsamling og -analyse og kapitel 7 om løsningsdesign for nærmere vejledning om gennemførelsen af en grundig analyse og specificering af krav til projektets løsning.

Fokus og kvantificerbarhed projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

To vigtige karaktertræk ved tekniske projekters problemformuleringer er fokus og kvantificerbarhed.

Fokus Uagtet om projektet er struktur- eller procesorienteret, er det vigtigt, at det har ét fokus. Det kan være svært for jeres projektvejleder at udtrykke præcist, hvad fokus betyder i et konkret projekt, fordi en indledende vejledningssamtale indeholder mange facts og informationer, som vejlederen skal forstå hurtigt og holde fast i hovedet samtidigt. I projekter, der forbedrer noget eksisterende, betyder fokus, at projektet skal forbedre én (og kun én) variabel. En underviser på maskiningeniørretningen har udtalt følgende om gode problemformuleringer: De studerende kommer tit og siger, at deres projekt skal optimere et eller andet. Det kan jeg ikke bruge til noget. Tilbage i tænkeboksen. Jeg vil have én variabel, der skal enten maksimeres eller minimeres, og så, under hvilke forudsætninger dette skal ske. Problemanalysen, som I udfører i begyndelsen af et projekt (se kapitel 2), skal lede til identifikationen af den rette variabel. Ofte vil en virksomhed gerne have optimeret noget, jf. ovenstående citat. For eksempel kan en virksomhed udtrykke ønske om at optimere et produkt eller en proces. Selvom dette er et fint udgangspunkt for en problemanalyse, er det netop kun et udgangspunkt og altså ikke konkret og fokuseret nok til en problemformulering. Jeres opgave i problemanalysen er at arbejde jer frem til, hvad det præcist er for en variabel, der bør forbedres. Underviseren, som er citeret ovenfor, fortæller, at variablen skal enten maksimeres eller minimeres. En lidt mere blød formulering er, at variablen skal enten øges eller reduceres. Om variablen skal øges eller reduceres, kommer an på, hvilken variabel der er tale om. For eksempel skal holdbarhed og produktivitet som regel øges, mens omkostninger som regel skal reduceres. Fokus' fjende nummer 1 er ordet og. Hver gang og får lov at snige sig ind i en problemformulering, reduceres fokus, fordi projektet vil to ting samtidigt. Bid mærke i, at ingen problemformuleringseksempler i denne bog vil forbedre to ting samtidigt. To (eller flere) ting samtidigt er ufokuseret, og manglende fokusering får hele projektet til at vakle. Det bliver sværere at afgrænse søgninger efter litteratur, identificere relevante data, foretage analyser, kommunikere klart og præcist og foretage entydige konklusioner.

Eksempel på, at vejleder ikke er enig i, at problemformuleringen skal

handle om at forbedre kun én variabel Hvis I oplever, at jeres vejleder ikke er enig i, at jeres problemformulering skal handle om at forbedre kun én variabel, kan det bero på, at jeres problem og jeres aktuelle arbejde ligger på to forskellige niveauer i jeres problemtræ (se figur 2.3). Lad os sige, at jeres projekt handler om at redesigne et produkt for at reducere produktets kostpris. I præsenterer jeres vejleder for reglen om, at jeres problemformulering skal handle om forbedring af kun én variabel. Hertil siger jeres vejleder måske følgende: Én variabel? Hmm … Et ingeniørprojekt arbejder sjældent med kun én variabel. I jeres projekt arbejder I jo både med vægtreduktion, ændring i materiale og ændring i udformning. Det er tre ting. Jeres vejleder har helt ret i, at I arbejder på flere ting samtidigt. Men grunden til, at I gør dette, er, fordi alle tre ting bidrager til at sænke kostprisen. Kostprisen er jeres ene variabel i problemformuleringen. At reducere vægt, ændre materiale og ændre udformning er med i projektet for at reducere kostprisen. I problemtræet ligger jeres ene variabel øverst; vægt, materiale og udformning ligger længere nede. Underviseren, der er citeret øverst på siden, afslutter med at sige, at projektet skal gøre det klart, under hvilke forudsætninger et projekt skal øge eller reducere variablen. I den endelige projektrapport bør denne række forudsætninger være klargjort. Identifikationen og forståelsen af de relevante forudsætninger er dog en aktivitet, der sker løbende gennem projektperioden.

Eksempel på, hvordan et projekts forudsætninger løbende kommer i spil Et projekt handler om at reducere et produkts vægt under forudsætning af, at produktets funktionalitet forbliver den samme, og at indkøbsprisen på materialet ikke bliver højere end den nuværende. Projektgruppen undersøger muligheden for at skifte materiale og foreslår et nyt materiale til samme indkøbspris. Det viser sig dog, at materialet er meget dyrere at forarbejde, så produktets produktionsomkostning stiger. Projektgruppen tilføjer derfor endnu en forudsætning om, at produktionsomkostningen heller ikke må stige.

Multikriterievariabel På nogle tekniske uddannelser anvendes multikriteriebeslutninger, der integrerer flere beslutningsvariable i én variabel. På den måde kan et projekt have én variabel i problemformuleringen, men alligevel forbedre to eller tre ting samtidigt. For eksempel kan

et projekt samtidigt handle om at 1) forbedre et produkts holdbarhed, 2) reducere produktets størrelse og 3) øge ydelsen på produktets primære funktion. Projektet vægter de tre variables relative vigtighed og integrerer så alle tre variable i én variabel. I arbejdslivet efter endt uddannelse er det helt normal praksis at forbedre fx et produkt eller en proces på flere parametre samtidigt. I et projekt på en uddannelse er det dog ikke ufarligt. At have en multikriterievariabel i problemformuleringen medfører stort set de samme faldgruber som en problemformulering med flere variable. Hvis et projekt fx handler om samtidigt at øge holdbarhed, reducere størrelse og øge ydelse, stiller det store krav til projektets vidensgrundlag, dataindsamling, datakilder samt analysearbejdet. Det bliver også svært at kommunikere klart i projektrapporten, fordi læseren hurtigt bliver forvirret. På uddannelser, hvor multikriterievariable er traditionen, er alle parter vant til at håndtere de ekstra udfordringer, så her er det naturligvis fint og forventet, at I som projektgruppe bruger multikriterievariable. På uddannelser, hvor multikriterievariable ikke er almindelig praksis, bør I konsultere anvendelsen grundigt med jeres vejleder.

Kvantificerbarhed Den variabel, I vælger at forbedre, bør være kvantificerbar og målbar. For eksempel kan holdbarhed måles i år, bæreevne i ton og kassationsrate i procent. I begyndelsen af et projektforløb arbejder I måske med en variabel, der ikke har en oplagt målbar enhed som fx ton eller kr. Eksempler herpå er kvalitet, effektivitet og flow. Det er helt fint som udgangspunkt for en problemanalyse, men prøv at gøre den målbar igennem jeres arbejde i problemanalysen. Problemanalysen kan fx udskifte den forståelige, men vagt definerede variabel kvalitet med "antal godkendte produkter i timen". Indsæt så vidt muligt den målbare, specifikke variabel i problemformuleringen. Måske er I så heldige, at virksomhedens aktuelle performance på variablen i problemformuleringen allerede er kendt inden projektopstart. Det kan være, at virksomhedens dårlige performance måles dagligt, og at det netop er disse målinger, der er årsagen til, at virksomheden samarbejder med jer om projektet. Hvis variablen er kendt, behøver I selvfølgelig ikke selv kvantificere og måle den. I de tilfælde, hvor variablen hverken er præcist defineret, kvantificeret eller målt, er det jeres opgave (typisk i analysen, der går forud for design af løsning) at måle den nuværende performance. Hvis et projekt fx handler om at nedbringe lageromkostninger, som virksomheden tror er store (men dog ikke har målt), er det jeres opgave at måle de aktuelle lageromkostninger. Hvis I har målt den aktuelle performance, så er det muligt at vurdere den effekt, som jeres løsning vil have på den aktuelle performance. Hvis

lageromkostningerne fx er 23 mio. kr. per år, og I foreslår implementering af en løsning, bør I vurdere, hvor stor en reduktion af de 23 mio. kr. løsningen vil resultere i (fx 30 eller 50 %). Se mere om måling af problemets størrelse i kapitel 6. Hvis virksomhedens aktuelle performance på variablen er kendt, kan det være en god ide at indsætte et konkret måltal i problemformuleringen. For eksempel "Hvordan kan Larsen A/S reducere spildmateriale med 20 %?" Hvis I sætter et måltal ind, så husk at forklare, hvorfor I har valgt netop det tal. I eksemplet, hvorfor lige 20 % og ikke fx 25 % eller blot 5 %?

Undgå miks mellem de to projektarketyper projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Det er ikke umuligt at arbejde med projekter, der mikser de to projektarketyper, dvs. projekter, der forbedrer noget eksisterende, og projekter, der designer noget nyt fra bunden. Forestil dig fx, at du og din projektgruppe samarbejder med en producent af betalingsterminaler (Dankort-terminaler). Lad os antage, at I har identificeret problemet, nemlig at transaktionshastigheden, når en kunde bruger sit VISA-kort, er alt for lang. I vil derfor reducere den gennemsnitlige transaktionshastighed fra de nuværende 8 sekunder per transaktion. Jeres projekt handler altså om at forbedre noget eksisterende. I løbet af projektets første måned får jeres kontaktperson i virksomheden imidlertid den gode ide, at terminalen skal vise kunden hans eller hendes saldo (ligesom på DSB's Rejsekort). Jeres kontaktperson beder jer derfor om at inkludere denne nye funktion i jeres projekt. Pludseligt er projektet en blanding af at forbedre noget eksisterende (transaktionshastigheden) og udvikle noget nyt fra bunden (ny funktion til terminalen, der viser kunden hans eller hendes saldo). At blande arketyperne betyder, at projektets fokus skrider. I kan risikere til eksamen ikke at kunne forklare eksaminator og censor, hvad problemet i projektet er, fordi problemet pludseligt er mangt og meget samtidigt. Optimalt bør I derfor vælge enten at forbedre noget eksisterende eller designe noget nyt fra bunden. At mikse arketyperne bør kun ske i tæt samråd med vejleder. Det er meget almindeligt, at en virksomhed løbende vil have mere med i projektet ("Kan I ikke også se på …?"). Kapitel 10 om det gode virksomhedssamarbejde adresserer denne situation som en af de klassiske faldgruber i virksomhedssamarbejdet. Kapitlet giver en række råd til, hvordan I kan håndtere en sådan situation og bevare projektets fokus.

Faldgrube ved ændringer i problemformuleringen projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Det er ikke utænkeligt, at problemformuleringen ændrer sig i løbet af projektperioden. Efterhånden som I bliver klogere på jeres projekt, begynder I bedre og bedre at forstå de årsagssammenhænge, der er relevante for jeres projekt. Det, I har nedfældet efter to-tre uger, skal derfor måske justeres og omformuleres hen ad vejen. Selvom det er en ganske nødvendig og god proces at forholde sig kritisk til projektets problemformulering, udgør ændringer i problemformuleringen også en mulig faldgrube, der kan fastholde jer unødigt i en alt for langsommelig problemanalyse. Denne faldgrube er illustreret i figur 3.2 og består i, at I begynder at betragte årsagerne til problemet, som I har identificeret i jeres analyse, som "det egentlige problem". Når I har fundet dette egentlige problem, ændrer I problemformuleringen, så den nu handler om det egentlige problem. Derefter begynder I at finde årsagen til det nye problem, og denne årsag betragter I så derefter igen som det egentlige problem. Og sådan kan processen fortsætte, indtil panikken sætter ind, fordi tiden går, og afleveringsdatoen nærmer sig.

Figur 3.2. Faldgruben i problemanalyse

Det gode råd er her ganske enkelt at fastholde den oprindelige problemformulering og betragte årsagen til problemet som årsagen til problemet og ikke som "det egentlige problem".

Eksempel på faldgruben Virksomheden KRUS A/S producerer en række moderne og "hippe" krus af plastic. Virksomheden sælger disse krus til distributører af service og større varehuse i store partier. Til produktionen anvendes støbeforme, og virksomheden oplever, at

støbeformene ikke holder særligt længe. Virksomheden skal derfor alt for ofte købe nye støbeforme. Projektgruppen udarbejder som følge heraf denne problemformulering: Hvordan kan KRUS A/S øge holdbarheden af støbeformene anvendt til produktion af plastickrus? Derefter påbegynder projektgruppen analysen af, hvorfor disse støbeformes holdbarhed er så lav. Den viser følgende: Virksomheden producerer og leverer først ordrer til kunder, når disse er bestilt. Mange ordrer er meget store (ofte mellem 4.000 og 8.000 krus). Når produktionen påbegynder et parti krus, kører den for fuld skrue, indtil hele ordren er færdigproduceret. Hvis ordren fx er 8.000 krus, kører produktionen, til der er 8.000 færdige krus. Produktionen anvender de samme støbeforme til alle ordrer, uagtet ordrens størrelse. Støbeformene kan ikke tåle at blive brugt til for store ordrer (de har en maks.grænse). Produktionsplanlæggerne tager ikke højde for støbeformenes maks.-grænser. Produktionsplanlægningen er i det hele taget usystematisk. Projektgruppen mener nu at have fundet "det egentlige problem", nemlig den usystematiske produktionsplanlægning. De studerende ændrer derfor deres problemformulering og begynder at lede efter årsagen til, at produktionsplanlægningen ikke anvendes systematisk. Holdbarheden af støbeformene er således ikke længere problemet. Halvdelen af projektperioden er nu gået, og projektgruppen er kommet unødigt i tidsnød. I ovenstående eksempel kan projektgruppen principielt vedblive med at ændre deres problemformulering og derfor komme i tidsnød. Det gode råd er at fastholde problemformuleringen om støbeformenes lave holdbarhed og opfatte den usystematiske produktionsplanlægning som årsagen til problemet og ikke som "det egentlige problem". Når projektgruppen har dokumenteret, at den usystematiske produktionsplanlægning er årsagen til problemet, kan den begynde at designe en løsning, nemlig en ny og bedre politik for virksomhedens produktionsplanlægning, der tager højde for støbeformenes maks.-grænser. Nogle gange kan det være fornuftigt at ændre problemformuleringen, men det bør ske af andre grunde, end at årsagen opfattes som "det egentlige problem". Og i alle tilfælde bør I konsultere vejledere, eftersom det er en vigtig beslutning.

Underspørgsmål til problemformuleringen projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Det er ofte en god ide at bryde en problemformulering ned i en række underspørgsmål, som I nemmere kan besvare. Det er dog ikke hvad som helst, der kan udgøre et underspørgsmål til en problemformulering. Princippet for, hvad der udgør et "acceptabelt" underspørgsmål, er, hvorvidt underspørgsmålet er et spørgsmål, der absolut skal besvares, for at hovedproblemformuleringen kan besvares. Man kan også sige, at underspørgsmål skal "udfolde problemformuleringen". Tabel 3.4 giver et eksempel på en problemformulering med acceptable og ikke-acceptable underspørgsmål. Hovedproblemformulering Hvordan kan FISK A/S reducere det gennemsnitlige lager af færdigt fileterede fisk uden at reducere leveringstiden til kunderne? Acceptable underspørgsmål

Ikke-acceptable underspørgsmål

Hvad er FISK A/S?

Kan FISK med fordel outsource lageret?

Hvad er et lager?

Kan ny fileteringsteknologi hjælpe?

Hvordan beregnes et gennemsnitligt lager?

Hvad er kundernes krav til leveringstid?

Hvad er leveringstid?

Kan FISK A/S vælge at sælge andre typer fisk?

Hvordan påvirker lagerstørrelse leveringstiden?

Hvordan ser FISK A/S's ledelse på lageret?

Hvordan kan et lager reduceres?

Er FISK A/S's salg stagnerende eller stigende?

Hvordan kan lageret hos FISK A/S reduceres?

Kan FISK A/S anvende nogle nye pakkemetoder til lageret?

Hvad er leveringstiden til kunderne hos FISK A/S?

Kan lageret deles op i kategorier?

Tabel 3.4. Problemformulering med acceptable og ikke-acceptable underspørgsmål De acceptable underspørgsmål handler om elementer, der allerede er i problemformuleringen (fx leveringstid og gennemsnitligt lager). At besvare disse er nødvendigt for at kunne besvare hovedproblemformuleringen. For eksempel kan hovedproblemformuleringen ikke besvares, hvis projektgruppen ikke ved, hvad leveringstid eller lager er. De acceptable underspørgsmål kan være simple (fx "Hvad er et lager?"), og de kan være mere komplekse (fx "Hvordan påvirker lageret leveringstid?"). Ingen af underspørgsmålene er dog så komplekse som hovedproblemformuleringen, der handler om at bringe alle elementer i spil samtidigt. De ikke-acceptable underspørgsmål bringer nye elementer i spil (fx outsourcing, salgstendenser og pakkemetoder). Det kan godt være, at analysen og løsningen vil omhandle outsourcing eller pakkemetoder, men disse elementer hører ikke hjemme i problemformuleringen, for på dette tidspunkt i rapporten ved I formelt set ikke, om disse elementer er relevante. Se nærmere om inddragelsen af mulige løsninger i kapitel 4 om projektets vidensgrundlag. Det er nemlig gennem anvendelse af viden, fx faglige vejledninger eller handleanvisninger, at I bliver klogere på, hvad der kan indgå i projektets løsning, og I skal først bringe den faglige viden på banen langt efter problemformuleringen.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Afgrænsninger

At afgrænse betyder, at I fravælger noget i projektet, som man egentligt kunne forvente var med. Tænk over, om jeres introduktion og problemformulering giver læser grund til at tro, at I vil komme ind på emner, som I ikke behandler. Hvis der er sådanne temaer, så afgræns jer fra dem. I rapporten bør I beskrive afgrænsninger lige efter problemformuleringen, så læserens forventninger til jeres projekt er "skåret til" fra første færd. Det er vigtigt ikke at forveksle afgrænsninger med andre typer fravalg, fx fravalg af mulige løsninger, som I ender med ikke at arbejde med. Man kan fx forestille sig, at et projekt, der handler om at minimere materialespildet i produktionen, har identificeret fire mulige redesignede produkt-prototyper. Projektgruppen vurderer efter nogle udvalgte kriterier, hvilken prototype projektet går videre med. At vælge én prototype blandt de fire er ikke en afgrænsning, der skal beskrives efter problemformuleringen. Det er derimod blot et valg, som der forekommer mange af i et projekt.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Opsummering

I dette kapitel har du lært, at et projekt på en teknisk uddannelse handler om at løse et problem. Et problem er enten, at noget eksisterende ikke er godt nok, eller at noget, som virksomheden ønsker sig, ikke findes. Du har lært, at en problemformulering består af en række komponenter, nemlig spørgeord, aktør, handling, variabel, specificeringer, forudsætninger og metodeafgrænsninger. Kapitlet beskriver, at gode problemformuleringer demonstrerer fokus og handler om kvantificerbare variable. Ud fra problemformuleringen kan I som projektgruppe udlede underspørgsmål. Disse underspørgsmål skal kunne udledes direkte af hovedproblemformuleringen uden at bringe nye elementer i spil (fx mulige løsninger).

Kapitel 4. Projektets faglige vidensgrundlag projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I dette kapitel lærer du: Hvad der udgør det faglige vidensgrundlag for tekniske projekter Hvordan I finder den relevante viden til jeres projekt blandt al tilgængelig viden Hvordan og hvor I identificerer den relevante viden Hvordan I anvender viden til at forstå jeres projekts problem, til jeres analysearbejde og til designet af jeres løsning Hvordan man operationaliserer teori Hvad I kan gøre, hvis I hverken har en vejledning, standard, regel, norm eller teori. Vidensgrundlaget for et teknisk projekt, der ligger sent på en uddannelse, er stort set det samme som det, ingeniører og andre teknikere anvender i deres arbejde i praksis. Denne viden er beskrevet i en række praksisorienterede typer af litteratur, fx: normer for byggeri (fx Bygningsreglement 2020) EU-direktiver (fx WEEE-direktivet om genbrug af elektronisk affald) regler for programmering (fx syntaksregler for programmering i Java) standarder for korrekte tekniske tegninger (fx Geometriske produktspecifikationer) principperne i effektiv produktion (fx LEAN-principperne) handleanvisninger (fx Kotters otte trin for organisatoriske forandringer) regler for patentering og IPR-rettigheder (fx regler for EU-patentering) vejledninger (fx ståbier fra forskellige felter) reglerne for en korrekt udført investeringskalkule fra driftsøkonomien huskeliste for en fyldestgørende forretningsmodel (fx Business Model Canvas). Den praksisorienterede faglige litteratur er baseret både på erfaring fra praksis og på den forskning, der betegnes "anvendt forskning" (på engelsk applied science). Forskningsverdenen sondrer mellem anvendt forskning og grundforskning. Anvendt forskning udvikler teori, der er tættere relateret til praksis end grundforskning. Figur 4.1 illustrerer, hvordan den praksisorienterede litteratur bygger på anvendt forskning, der igen bygger på grundforskning.

Figur 4.1. Vidensgrundlaget for tekniske projekter

To eksempler på vidensgrundlag for tekniske projekter Konstruktion af energiruder Et projekt skal udvikle en ny type energirude. Projektgruppen anvender en vejledning til konstruktion af vinduer, hvori der er to anbefalinger: a) En energirude skal have flere lag glasruder, og b) der skal være en fugtfri gas mellem glasruderne. Disse to anbefalinger bygger på anvendt forskning om, hvordan varme bevæger sig igennem materialer. Den anvendte forskning bygger på grundforskningen i termodynamik. Udvikling af software til virtuelle møder Et andet projekt skal udvikle software til virtuelle møder. I udviklingen anvendes et programmeringssprog, der indeholder en række syntaktiske regler. Disse syntaksregler er baseret på anvendt forskning i informationsvidenskab, som bygger på grundforskningen i den algebraiske matematik. Anvendt forskning og grundforskning (fx i matematik, fysik og økonomi) omfatter både formler, metoder, modeller og grundlæggende teorier om naturen, mennesket og samfundet. Forskningen er beskrevet i lærebøger eller akademiske tidsskrifter (på engelsk scientific journals). Som det ses i figur 4.1, er der en lille buet stiplet linje. Linjen fortæller, at vidensgrundlaget for projekter på de længerevarende og mere dybdegående tekniske uddannelser kan række ud over de praksisorienterede typer af litteratur. På ingeniøruddannelserne forventes det fx, at I som projektgruppe dykker ned i både anvendt forskning og grundforskning efter behov. "Efter behov" betyder, når I har brug for viden, der ikke er tilgængelig i en operationel (umiddelbart brugbar) form som fx i en vejledning eller et regelsæt. Ingeniører griber tit til grundforskning. For eksempel Ohms lov i elteknikken, Bernoullis ligning i termodynamikken, Newtons love og Kirchhoffs elektriske kredsløbslove. Se nærmere om den praktiske brug af anvendt forskning og grundforskning i afsnittet om operationalisering af teori senere i kapitlet.

Denne bog betegner alle typer af litteratur i figur 4.1 som faglig litteratur. Det gælder såvel den praksisorienterede litteratur (fx normer, vejledninger og standarder) samt lærebøger og videnskabelige tidsskrifter.

Den faglige litteratur udgør ekspertisen i et teknisk projekt projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I et projekt bruges faglig litteratur til flere ting, fx: at kvalificere valg at foretage korrekte beregninger at identificere krav til løsninger at sikre, at projektets analyse beror på det rette datagrundlag at sikre, at analyser udføres korrekt at sikre, at løsninger er holdbare, brugbare og korrekt designet. Den faglige viden er jeres projekts ekspertise. Ekspertisen udgøres hverken af medarbejderne i den virksomhed, I samarbejder med, eller jeres vejleder. Jeres vejleder eller virksomhedens kontaktperson (der ofte er en færdiguddannet person på den uddannelse, som I aktuelt går på) fortæller tit, hvordan I kan løse en opgave, men deres forståelse og færdigheder er også baseret på områdets faglige viden.

Hvad er relevant faglig litteratur projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Der findes uendelige mængder af faglig litteratur, og det er jeres opgave at vælge netop den litteratur, der er relevant for jeres projekt. Grundlæggende er det problemformuleringen, der afgør, hvad relevant faglig litteratur er. Problemformuleringen indeholder et eller flere begreber, som fortæller, hvilken litteratur I har behov for. Det er jeres opgave at udlede behovet for faglig litteratur ud fra problemformuleringen.

Eksempel på relevant litteratur til et projekt Et projekt handler om at designe et nyt energibesparende vindue fra bunden. Projektgruppen er kommet til det tidspunkt i projektet, hvor den relevante faglige litteratur skal indhentes til analyse og senere til løsningsdesign. Medlemmerne beslutter sig for at indhente den litteratur, der behandler følgende spørgsmål, som er relevante for deres projekt: Hvad et energisparende vindue er Hvilke tekniske krav et sådant vindue skal overholde Hvilke funktioner et energisparende vindue bør have (fx om og hvordan det skal kunne åbnes) Hvordan vinduets konstruktion sikrer funktionalitet, tæthed og holdbarhed mod vind og vejr. Litteraturen består bl.a. af love, faglige standarder og vejledninger for vindueskonstruktion. Projektgruppen finder ud af, at et energivindue har flere lag glasruder, at der er en fugtfri gas mellem disse ruder, og at vinduet har flere rækker gummilister, der sikrer tæthed. Projektgruppen finder ydermere frem til, hvordan et vindues karme fastholder ruderne, hvilke krav der stilles til karmenes mekaniske egenskaber, hvordan den fugtfrie gas mellem ruderne bibeholdes, og hvilke typer gummilister mellem vindue og karme der kan sikre den fornødne tæthed.

Argumentation for valg af faglig litteratur projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Nogle gange er valget af litteratur oplagt og selvindlysende for alle parter. I sådanne tilfælde vil eksaminator og censor ikke forvente argumentation for, hvorfor I har valgt, som I har. Ofte skal I dog foretage et egentligt valg, og her bør I argumentere for jeres valg. Jo vigtigere valg, der ikke er selvindlysende for alle parter, jo grundigere bør jeres argumentation være. En nem huskeregel er at svare på "de to HV-spørgsmål": 1. Hvorfor er netop denne metode, teori eller model valgt (og evt. hvorfor ikke andre)? 2. Hvordan skal denne metode, teori eller model anvendes i projektet? Svaret på det første spørgsmål forklarer, hvordan den valgte metode, teori eller model hænger sammen med de forrige dele af projektet (fx problemformuleringen), mens svaret på det andet spørgsmål binder metode, teori eller model sammen med de kommende dele af projektet (fx til brug i analyse eller løsningsdesign).

Figur 4.2. De to HV-spørgsmål

Besvarelsen af HV-spørgsmålene ligger nogle gange implicit i teksten og behøver ikke altid at blive formuleret eksplicit. (Se mere om valg af metode i kapitel 5 og om beskrivelsen af faglig litteratur i projektrapporten i kapitel 12).

Identificering af relevant faglig litteratur projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Bundne projektopgaver har som regel en række krav til brugen af faglig litteratur (fx at I skal anvende den teori, der er listet i pensum). I frie projekter er det derimod op til jer selv at vælge og identificere den rette faglige litteratur. Dette kan bl.a. gøres på følgende måder: Spørg projektvejleder eller andre undervisere på uddannelsen Spørg kontaktpersonen i virksomheden Spørg bibliotekaren på universitetets bibliotek om, hvor I selv kan lede Søg i universitetets digitale bibliotek Søg i relevante online kilder (fx materialedatabaser) Tjek relevante lærebøgers referencer Anvend almindelige internetsøgninger på emnet for at få et generelt kendskab Tjek referencers referencer (og bliv eventuelt ved med dette, indtil den rette faglige viden er fundet) Tjek Wikipedia-artiklers kildeliste (men anvend aldrig Wikipedia-artiklen selv som kilde). I kan også tage udgangspunkt i litteraturlister fra jeres kurser. Husk dog, at jo længere I er på jeres uddannelse, jo mindre sandsynligt er det, at litteraturen i jeres kursers pensum tilfældigvis også skulle være den relevante litteratur for jeres projekt. Tjek derfor diverse lærebøgers referencer for at komme et skridt dybere. Lån eller download disse referencer, og se, om de er anvendelige. Hvis ikke, så tjek evt. referencernes referencer – en teknik, der kan gentages og kan være ganske effektiv. Husk dog, at jo flere gange man går tilbage, jo ældre bliver kilderne. Hvis en bog, der ikke er digitalt tilgængelig, forekommer relevant, så lån den på universitetets bibliotek eller gennem bibliotek.dk. Amazon.com er en god måde at finde relevante engelsksprogede lærebøger på. Brug nogle relevante søgetermer. De bøger, I gerne vil bruge, bestiller I så efterfølgende på universitetets bibliotek eller på bibliotek.dk. Tjek evt. Google Scholar, der ofte har bøger digitalt tilgængelige. Nøglen til at finde den rette litteratur er at være skarp omkring projektets vidensbehov. Jo mere konkret et vidensbehov er defineret, jo nemmere er det at identificere den rette faglige viden. Boksen i afsnittet Hvad er relevant faglig litteratur viser, hvordan I med udgangspunkt i problemformuleringen kan stille jer selv de spørgsmål, I skal finde svar på.

Den faglige litteraturs anvendelse i projektet projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Den faglige litteratur tjener især tre formål: 1. Til at forstå problem og centrale begreber 2. Som grundlag for jeres analysearbejde 3. Som redskab i jeres design af projektets løsning Projekter, der forbedrer noget eksisterende, anvender især faglig viden til første og andet formål, fordi de (ud over at forstå og definere centrale begreber) skal finde årsagerne til det formulerede problem samt mulighederne for at afhjælpe det. Projekter, der udvikler noget nyt fra bunden, anvender især faglig viden til første og tredje formål, fordi de (ud over at forstå og definere centrale begreber) skal identificere alle relevante krav til den løsning, som de søger at udvikle. Herunder gives en nærmere beskrivelse af de tre formål.

Forståelse af problemet i problemformuleringen samt projektets centrale begreber Ethvert projekt anvender en række faglige begreber (fx styrke, densitet, elasticitet, korrosionsdygtighed, effekt, hastighed, omkostning og kvalitet). I bør anvende begreber, der er klare og eksplicitte for jer selv og siden for læseren. I nogle projekter er det nemt at sikre forståelse for den variabel, projektet vil forbedre. Hvis et projekt fx handler om at øge målingshastigheden for et måleapparat, er det forholdsvist hurtigt at forklare, at målingshastigheden er "antal minutter, fra en måling er foretaget, til måleresultatet foreligger". Omvendt kræver variablen i andre projekter en nærmere specificering.

Eksempel på brug af faglig litteratur i definitionen af projektets problem Et projekt handler om at øge plukkeproduktiviteten på et færdigvarelager. Kort fortalt handler plukkeproduktivitet om, hvor hurtigt medarbejderne plukker de varer på et lager, der skal pakkes og transporteres til firmaets kunder, og det skal projektgruppen gøre klart. Hertil kan gruppen anvende faglig litteratur, der kan fortælle, hvad et færdigvarelager er, hvad det vil sige at plukke fra et lager, og endeligt hvordan man kan definere begrebet plukkeproduktivitet (fx som "antal plukkede varer per medarbejdertime").

For et projekt, der handler om at forbedre noget eksisterende, indeholder problemformuleringen typisk ét begreb, der er særligt vigtigt at definere. Det er den variabel, projektet vil forbedre (fx holdbarheden på et produkt, CO2-udledningen fra et produktionssystem eller varmeudstrålingen fra et typehus). Hertil anvendes også faglig litteratur. Hvor vigtigt det er at definere et begreb eksplicit, afhænger af en række faktorer: Om fagområdet og fagområdets underliggende videnskaber anvender bredt anerkendte begreber, som alle forstår som det samme (fx flydespænding og densitet) Om begrebet rummer en teknisk kompleksitet, som læseren ikke kan forstå uden specificering og forklaring Om begrebet kan fortolkes forskelligt (begrebets "blødhed") Om begrebet er opfundet af jer selv til lejligheden. Det er meget almindeligt, at fagområder, der har lange traditioner, gennem tiden har udviklet en række standardbegreber, som alle fagpersoner kender til. Eksempler er byggeri og elteknik. Disse fagområder er begge tæt knyttet til videnskaber med en lang historie som fx styrkelære, materialevidenskab og Newtons fysik. Her handler begrebsdefinitioner derfor ofte blot om at præcisere, hvilke måleenheder projektet anvender. Eksempler er kW/m2 for varmeforbrug og liter/minut for vandflowet i et rør (fx på et kraftvarmeværk). Hvis jeres projekt anvender teknisk komplekse begreber, som I ikke kan forvente, at læseren af rapporten kender til, skal de specificeres tydeligt. Nogle begreber kan fx opfattes som meget abstrakte og svære at få tankemæssigt greb om. Mange begreber, der umiddelbart lyder som ligetil at forstå, kan fortolkes forskelligt. Tag fx begrebet kvalitet. Betyder kvalitet, at et produkt virker efter hensigten, at brugeren kan finde ud af at bruge produktet, eller at fabrikanten producerer produkter med meget få defekte emner? Den rette definition kommer helt an på projektet. Hvis projektet handler om produktudvikling, handler kvalitet ofte om brugerens oplevelse af produktet og brugen af produktet. Beskæftiger projektet sig derimod med produktionen af produktet, handler kvalitet typisk om, hvor stor en andel af produkterne, der består en funktionstest, eller hvor mange produkter der må genbearbejdes. Hvis I arbejder med et problem, hvor der ikke findes standardbegreber, er det helt og aldeles lovligt selv at opfinde begreber. Disse skal dog defineres grundigt.

Eksempel på et selvopfundet begreb En virksomhed forhandler og distribuerer materialer og komponenter til VVS-branchen. Et projekt handler om at reducere den tid, som lagermedarbejderne bruger, når de (i deres gaffeltrucks) kører rundt på lageret for at pakke ordrer. Projektgruppen har identificeret en

række tilfælde, hvor lagermedarbejderne dels skal køre uhensigtsmæssigt lange ture for at indsamle selv små ordrer, og dels kører forgæves, enten fordi der mangler komponenter på hylderne, eller fordi de sedler, der specificerer de komponenter, medarbejderne skal hente, er fejlbehæftede. Projektgruppen skal nu definere den konkrete variabel, de vil forbedre. Gruppen låner en række lærebøger om logistik og finder frem til en definition, der lyder: "den gennemsnitlige plukke- og pakketid per fuldstændigt og korrekt pakket ordre". Denne definition specificerer de yderligere til at blive målt med enheden "minutter per ordre". Gruppen finder deres eget navn for denne variable, nemlig pluk-pak-hastighed, forkortet PPH. Projektgruppen kan derefter identificere virksomhedens aktuelle PPH-performance (fx 7,48 minutter per ordre) og siden effekten af projektets løsninger (fx en reduktion i PHH på 30 %). Anvender I bløde eller selvopfundne begreber, kan I med fordel basere jeres definitioner (mere eller mindre løst) på den faglige litteratur. Hvis I selv vil definere et begreb (fx kvalitet) til netop jeres projekt, er det god skik at låne en række lærebøger og fortælle læseren, hvordan disse bøger definerer begrebet. Herefter kan I så lave jeres egen definition, der enten inkorporerer elementer fra lærebøgernes definitioner eller er helt jeres egen. Anvender I egne definitioner, så gentag dem et par gange, så I sikrer jer, at læseren er med. Der kan være en vis risiko ved selv at definere et begreb, selvom I eksplicit definerer det tidligt i jeres projektrapport. Jeres eksaminator og censor er mennesker som alle andre og kan have svært ved at skifte forståelsen af et begreb. Hvis I fx vælger at definere begrebet omkostningseffektivitet som "kr. per stk.", og eksaminator og censor er vant til at tænke på omkostningseffektivitet som "kr. per kg", er det naturligt, at de tænker med deres egen vante definition og derfor bliver forvirret, når de læser jeres rapport. I minimerer denne risiko ved at nævne jeres definition flere gange i rapporten.

Vigtig regel om definitioner Til defineringen af jeres projekts vigtigste begreber bør I aldrig anvende generelle ordbøger som fx ordbogen.com eller Gyldendals ordbøger. Det kan være helt tilfældige personer, der har skrevet disse definitioner. Som Booth, Colomb og Williams skriver i deres anerkendte bog The Craft of Research (2008: 238): "If a word is important enough to define in a report, it is too complex for a dictionary definition." Ud over et navn, så husk eksplicit at angive målenheder på jeres begreber. Måleenheder kan fint gælde specifikt for jeres projekt. Ét projekt måler fx densitet som ton/m3, mens et andet projekt måler den som kg/liter. Angivelse af enhed er derfor centralt for læserens forståelse.

Grundlaget for projektets analysearbejde Det andet formål med den faglige litteraturs anvendelse i et projekt er, at den hjælper jer til at identificere de generisk mulige årsager til projektets problem og de generiske forbedringsmuligheder. Den anvendes med andre ord som basis for en grundig analyse. I et projekt, der udvikler noget nyt fra bunden, bør I bruge litteraturen til at få et grundigt overblik over de krav, der generelt er til den type af løsning, I vil designe. (Se nærmere herom i kapitel 6, som bl.a. opstiller en række kategorier af typiske krav til løsninger). I projekter, der søger at forbedre noget eksisterende, består analysen typisk af to aktiviteter: 1. At identificere årsager til projektets problem 2. At identificere muligheder for at afhjælpe projektets problem, som virksomheden aktuelt ikke anvender. Den første aktivitet handler om at dykke ned i årsagerne til projektets problem. Hvis projektet fx handler om at øge et produkts holdbarhed, vil årsagsanalysen identificere årsagerne til, at holdbarheden er lav. Den anden aktivitet handler om at undersøge, om der findes muligheder, der i dag ikke anvendes, men som kan afhjælpe projektets problem. Hvis et projekt fx handler om at øge en kemisk proces' evne til at separere to væsker, så kan projektgruppen forsøge at identificere mulighederne for at ændre processen. Til at identificere årsager og nye muligheder, der kan afhjælpe projektets problem, skal I benytte den viden, der er til stede i den faglige litteratur. Som hjælp til at identificere den rette faglige litteratur kan I anvende nedenstående to spørgsmål: 1. Hvad er de generiske årsager til, at projektets problem findes? (Svaret er en liste med generiske årsager) 2. Hvilke generiske muligheder er der for at afhjælpe problemet? (Svaret er en liste med generiske muligheder). I parenteserne står der lister med hhv. generiske årsager og generiske muligheder. Tillægsordet "generisk" er i familie med "generel" og betyder i denne sammenhæng teoretisk mulig. Med andre ord er en generisk årsag en årsag, der kunne være mulig i jeres projekt. Hvorvidt den faktisk er aktuel, vil jeres analyse senere i projektet afsløre. Når I har nedfældet de to lister, er næste skridt at organisere årsager og muligheder i et generisk, hierarkisk problemtræ. Dette problemtræ udgør resultatet af jeres arbejde med den faglige litteratur og dermed grundlaget for jeres analyse. Som et eksempel kan vi tage et projekt, der handler om at øge outputtet fra en produktionsmaskine. Inden opbygningen af problemtræet anvender projektgruppen relevant faglig litteratur til at identificere en række generiske årsager til, hvorfor maskiners

output helt generelt kan være lavere end det nominelle output (dvs. outputtet "på papiret"), og en række generiske muligheder for at afhjælpe problemet, jf. tabel 4.1. Generiske årsager

Generiske muligheder

Tiden, operatørerne bruger på at opstille og klargøre en maskine til at producere en ordre, kan være for lang Maskiner, der er klar til produktion, kan risikere at vente unødigt på materialer og komponenter Maskiner kan have mange nedbrud og pludselige stop, der løbende skal fejlrettes Maskiner kan have øgede produktionstider, hvis fiksturer og værktøjer er slidte Maskiner, der betjenes forkert, kan resultere i længere produktionstider Maskiner kan have lavt output per udnyttet time selv med høj udnyttelsesgrad Uklare betjeningsvejledninger kan resultere i mindre effektiv drift

Gennem den rette planlægning kan man forudse behovene for materialer og komponenter og dermed reducere antallet af tilfælde, hvor en maskine venter unødigt Gennem tilstandsbaseret forebyggende vedligehold kan man reducere antallet af nedbrud og pludselige stop på en maskine Gennem klare betjeningsvejledninger og operatørtræning kan man sikre korrekt betjening af maskiner Hvis operatører har den rette træning, kan de køre maskinen med maksimal effektivitet

Tabel 4.1. Eksempler på generiske årsager og muligheder De syv årsager og fire muligheder arrangeres herefter logisk i et problemtræ, der tager udgangspunkt i projektets problem, jf. figur 4.3. Træet udgør resultatet af en stor del af projektgruppens arbejde med den faglige litteratur.

Figur 4.3. Eksempel på et generisk, hierarkisk problemtræ

Problemtræet viser fire niveauer (fra venstre mod højre). Første niveau er projektets problem. Andet niveau er to af de generiske årsager, som projektgruppen har identificeret, og som udgør to logiske kategorier af mere konkrete årsager. Den første kategori handler om, at maskinen ikke kører i nok timer (øget nedetid), mens den anden handler om, at maskinen producerer for få emner i de timer, den kører (reduceret output per driftstime). Inden for hver af de to årsagskategorier har projektgruppen placeret de øvrige generiske årsager og de fire muligheder. Træet er opbygget logisk (fx hænger "nedbrud" i niveau tre sammen med "vedligehold" i niveau fire).

En ikke-anvendt mulighed er en årsag I litteratursøgningen støder man som regel ikke blot på generiske årsager til et problem, men også på muligheder for at afhjælpe problemet. Problemtræet i figur 4.3 viser en produktionsmaskine, der ikke producere nok emner. Litteraturen fortæller, at årsagen "mange nedbrud" kan afhjælpes gennem "tilstandsbaseret forebyggende vedligehold". Hvis virksomheden ikke anvender denne vedligeholdelsesmetode, udgør denne ikke-anvendte mulighed en årsag til projektets problem. Husk derfor, når I konstruerer det generiske problemtræ: En ikke-anvendt mulighed er en årsag.

Figur 4.4. Relationen mellem generisk, hierarkisk problemtræ og projektets analysearbejde

Figur 4.4 viser det samme problemtræ som figur 4.3. Figuren har fået tilføjet de analyser, der er relevante for projektgruppen at gennemføre. Hvis lange opstillingstider er en generisk årsag til projektets problem, så bør projektgruppen analysere de aktuelle opstillingstider for at vurdere, om de også rent faktisk er for lange. Hvis det forholder sig sådan, skal projektets løsningsdesign handle om at reducere disse opstillingstider. Bemærk, at det generiske problemtræ er begrænset til, hvad I kan finde i litteraturen om årsager og muligheder, samt jeres egen erfaring med problemfeltet. Husk desuden, at hvis I har gennemført den arbejdstunge opgave at opbygge et generisk problemtræ, så bliver jeres analyse alt andet lige mere grundig. En grundig analyse, der identificerer de rigtige årsager, er grundlaget for udviklingen af den helt rigtige, effektive løsning.

Faglig viden i designet af projektets løsning Det sidste formål med den faglige litteraturs anvendelse i et projekt er, at den er et redskab i designet af projektets løsning. Tidligere i dette kapitel så vi et eksempel på et projekt, der handler om at designe et nyt energibesparende vindue fra bunden (se side 58). Projektgruppen har fundet frem til, at energivinduet skal have flere lag glasruder, at der er en fugtfri gas mellem ruderne, og at vinduet sikrer tæthed ved anvendelse af gummilister. Projektgruppen skal nu i gang med at designe vinduet og har behov for faglig viden omkring 1) hvordan vindueskarmene skal fastholde lagene af glasruder, 2) hvordan den fugtfri gas mellem ruderne bibeholdes, og 3) hvordan gummilisterne skal sikre den fornødne tæthed. Denne viden findes ofte i litteraturen. For eksempel kan projektgruppen i forbindelse med det første punkt finde regler for sammenhængen mellem rudernes vægt og vindueskarmenes mekaniske egenskaber.

Operationalisering af teori fra anvendt forskning og grundforskning projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Den faglige litteratur i tekniske projekter udgøres som beskrevet i kapitlets indledning hovedsageligt af praksisorienteret litteratur. Dette er viden, der ofte kan anvendes uden videre i projektet. Benytter I teori fra anvendt forskning eller grundforskning, så skal denne teori først gøres klar til jeres praktiske brug. Teorien skal med et andet ord 'operationaliseres'. Operationalisering sker ved, at I trækker de relevante spørgsmål ud af den teori, projektet skal bruge. Disse spørgsmål anvendes fx i dataindsamlingen.

To eksempler på operationalisering af teori Et projekt handler om at designe den bærende stålstruktur i en etageadskillelse mellem kælder og stueetage i en bygning. Projektgruppen finder teori om stålstrukturer og ståls egenskaber. I teorien findes variablen godstykkelse (størrelsen af stålemnet). Projektgruppen operationaliserer teorien om stålstrukturer ved at indsætte variablen godstykkelse i et spørgsmål, der kan hjælpe til at få designet etageadskillelsen. Spørgsmålet lyder: Hvor stor skal godstykkelsen være af de tværgående stålbjælker i etageadskillelsen? Variablen godstykkelse er trukket ud af teorien om stålstrukturer, og anvendelsen af variablen i spørgsmålet udgør således en teori-operationalisering. Et andet projekt handler om at nedbringe omkostningerne til en produktionsvirksomheds råvarelager. De studerende finder teori om lageromkostninger, hvor variablen ordrestørrelse optræder. Ordrestørrelse er en fastlagt mængde, i hvilken virksomheden bestiller leverancer fra deres råvareleverandører. Denne variabel er udslagsgivende for råvarelagerets størrelse. Projektgruppen skal derfor vide, hvilke ordrestørrelser der giver de laveste omkostninger. Projektgruppen operationaliserer teorien om lageromkostninger ved at indsætte variablen ordrestørrelse i deres spørgsmål: Hvad er den ordrestørrelse, der giver de laveste omkostninger?

Hvad nu, hvis den relevante faglige viden ikke findes? projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I tekniske projekter er der ikke altid en fin vejledning eller handleanvisning til stede, som I kan bruge til en konkret opgave. Nogle gange er der heller ikke forskning at operationalisere. Lad os sige, at I skal beregne det maksimale moment på en metalstang med en H-form.

Figur 4.5. Metalstang med en H-form

Dette moment kommer an på bjælkens længde, godstykkelse og metaltype, og det kan beregnes ved at slå op i en bygningsnorm. Men hvad nu, hvis arkitekten vil dreje Hbjælken om sin egen akse af æstetiske grunde? I dette tilfælde kan bygningsnormen ikke hjælpe, fordi bjælkens facon nu er en helt anden. Her må I ty til eksperimentering: i dette tilfælde vride og teste momentet på bjælken (evt. en mindre version af bjælken og ud fra dette forsøge at konkludere, om en tykkere bjælke også vil holde). Tekniske studerende, særligt ingeniørstuderende, forventes at kunne udvikle egen projektspecifik viden. Denne vidensudvikling kan ske ved at trække logiske konklusioner fra kendt viden over i den aktuelle situation (deduktion) og ved at trække viden ud af projektets egne eksperimenter og tests til en bredere anvendelse (induktion). Deduktion betyder at trække logisk gyldige konklusioner fra et sæt af præmisser. Sættet af præmisser skal udgøres af viden, teorier, udtryk og tilstande, som alle relevante parter i projektet betragter som sande. At deducere kan simpelt udtrykkes således: "Hvis A og B begge er sande, så må C også være sand". For eksempel: "Hvis regn gør jorden våd, og det har regnet hele dagen, så er jorden våd" eller "hvis a = 2 og b = 4, så må a + b = 6".

I et teknisk projekt kan en deduktion lyde: "Hvis der står X i en vejledning om projektets generelle type, må det betyde Y i vores konkrete projekt." De to simple deduktioner om hhv. regn og abc vil alle opfatte som rimelige. I tekniske projekter er deduktioner dog ofte mere uklare. I disse tilfælde må I argumentere for, hvorfor I mener, det er logisk gyldigt at trække jeres konklusioner. Til tider må I også argumentere for, hvorfor jeres præmisser er sande. Induktion betyder at trække logiske konklusioner fra enkeltobservationer til en større population. Et eksempel fra den farmaceutiske industri lyder: "Denne medicin virker på 80 % af de 200 patienter i vores test. Derfor virker den også på 80 % af alle øvrige patienter." I et teknisk projekt anvendes induktive slutninger, når projektgruppen har foretaget en række tests. Dette kunne fx være, om en maskine fejler mindre efter indførelse af en ny vedligeholdelsespolitik, eller om en større andel af produkter består en funktionstest efter implementering af en ny montagevejledning.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Opsummering

I dette kapitel har du lært det faglige vidensgrundlag for tekniske projekter at kende. Som projektgruppe har I lært, hvordan og hvor I finder den relevante viden til jeres projekt blandt al tilgængelig viden. Kapitlet beskriver, hvordan I anvender viden til at forstå jeres projekts problem, som grundlag for jeres analyse og til designet af jeres løsning. Hvis I anvender teori fra den anvendte forskning, skal denne teori operationaliseres, så den er direkte brugbar i jeres projekt. Kapitlet beskriver også, hvad I kan gøre, hvis I ikke har hverken en vejledning, standard, regel, norm eller anvendt forskning at operationalisere.

Kapitel 5. Metodevalg og praktisk projektplanlægning projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I dette kapitel lærer du: Hvad begrebet "metode" betyder Hvorfor videnskabsteori ikke fylder meget i tekniske projektrapporter Hvordan et projekt sikrer en rød tråd mellem projektets aktiviteter Hvordan projektets metodevalg både er et valg af de overordnede skridt, som I udfører projektet i, og et valg af faglige værktøjer, redskaber og metoder til konkrete projektaktiviteter Til hvilke formål et teknisk projekt anvender faglige redskaber, værktøjer og metoder Hvilke kategorier af valg et projekt tager, og hvilke argumenter der kan overbevise læser om, at projektets valg bidrager til en god løsning og konklusion Hvordan I som projektgruppe kan planlægge jeres projekt ved brug af et Ganttdiagram. Ordet metode kommer af græsk (met hodos) og betyder "vejen ad hvilken". Metoden kan således siges at udgøre vejen, ad hvilken I vil løse projektets problem. Valget af metode er aktuelt, så snart I har jeres problemformulering på plads. Metoden afhænger nemlig helt og aldeles af, hvilket problem I vil løse. Når man har læst jeres metodeafsnit, skal det stå helt klart, hvordan projektet kommer fra problemformulering til løsning.

Videnskabsteori på tekniske uddannelser og i tekniske rapporter projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Et projekt kan være rent teknisk eller arbejde i samspillet mellem teknologi og mennesker. Et rent teknisk projekt kunne fx handle om at øge antallet af leveår af et metal-emne, før det begynder at ruste. Dette projekt er rent teknisk og anvender naturvidenskabens viden og love. Et projekt, der arbejder i samspillet mellem teknologi og mennesker, involverer en eller flere persongrupper. Det er afgørende for projektets videnskabsteoretiske grundlag, om projektet er rent teknisk eller handler om både teknologi og mennesker. Hvor de rent tekniske projekter som regel beror på naturvidenskabelig, positivistisk videnskabsteori, så kan projekter om teknologi og mennesker baseres på flere videnskabsteoretiske retninger. Her er fire eksempler på projekter med problemstillinger, der involverer persongrupper. De to første eksempler er projekter, der forbedrer noget eksisterende, og de to sidste eksempler er projekter, der designer noget nyt: At reducere antallet af fejl i en manuel produktionsproces, hvor operatører monterer færdige produkter At øge levetiden på en maskine gennem mere simple vedligeholdelsesinstruktioner til brugerne At designe en ny bygning til en virksomhed og alle dens medarbejdere At planlægge en ny udvidelse af en banestrækning til en stor gruppe trafikanter. Projekter om teknologi og mennesker handler om samspillet mellem naturvidenskabsbaseret teknologi og persongrupper (fx brugere, kunder, medarbejdere, borgere og ledere). At udvikle teknologiske løsninger til disse persongrupper kan kræve forståelse for menneskers holdninger, meninger, værdier og adfærd. Denne forståelse opnår man typisk gennem samtaler med enkeltpersoner eller små grupper. Som studerende sætter man sig selv ind i et andet menneskes tilværelse. Denne form for undersøgelse beror ikke på positivisme, men på videnskabsteorien hermeneutik. Hermeneutik handler om at fortolke og derigennem forstå det enkelte menneskes opfattelser, holdninger og værdier. Vær bevidst om, at jeres projekt kan bero på et denne sammensatte videnskabsteori, hvor alt ikke altid kan måles og vejes, men skal forstås, fortolkes og opfattes, og nogle gange føles og mærkes. Figur 5.1 sammenligner positivisme og hermeneutik, der begge meget ofte indgår i det videnskabsteoretiske grundlag i tekniske projekter om teknologi og mennesker.

Figur 5.1. Positivisme vs. hermeneutik

Videnskabsteori er sjældent et eksplicit afsnit i tekniske projektrapporter Tekniske projekter indeholder meget sjældent eksplicitte beskrivelser af projektets videnskabsteori. For de projekter, der er rent tekniske, betyder den naturvidenskabelige, positivistiske videnskabsteori, at teori om naturen og de grundantagelser, der ligger i denne teori, ikke behøver diskussion. De opfattes ganske enkelt som sande og dermed implicit indiskutable. Naturvidenskabelige love (fx tyngdekraften) og de deraf afledte tekniske love anses for gyldige. Derfor er der ikke behov for et afsnit om projektets videnskabsteori. Projekter om teknologi og mennesker følger denne tradition og har kun sjældent eksplicitte videnskabsteoriafsnit. Fraværet af eksplicitte videnskabsteoriafsnit adskiller mange tekniske uddannelser fra humanistiske og samfundsfaglige uddannelser. I disse uddannelser er det nødvendigt at bruge ganske anseelige kræfter på at anlægge en defineret og velvalgt videnskabsteori for en given undersøgelse. På disse uddannelser vælger en projektgruppe altså en bestemt måde at anskue en problemstilling på. Disse anskuelsesmåder kaldes nogle gange for perspektiver eller paradigmer. At der i det hele taget er flere muligheder at vælge imellem, adskiller disse videnskaber fra naturvidenskaben og de tekniske videnskaber, der bygger på naturvidenskaben. I tekniske rapporter ser man ikke diskussioner om, hvilket teoretisk perspektiv der bedst anvendes, fx i analysen af, om et produkts korrosionsdygtighed bevares længst ved en overfladebehandling med zink eller en overfladebehandling med en zink-nikkellegering.

På humanistiske og samfundsfaglige uddannelser er sagen en helt anden, idet svaret på problemformuleringen afhænger af perspektivet. Se et eksempel i den følgende boks.

Eksempel på valg af videnskabsteori i et projekt på en samfundsfaglig uddannelse Et projekt på sociologiuddannelsen vil undersøge, hvorfor langtidsledighed er et socialt problem. Projektgruppen skal vælge mellem flere teoretiske perspektiver, bl.a. positivisme og socialkonstruktivisme. Hvis projektgruppen vælger positivisme, kan man forestille sig, at projektet vil nå frem til, at langtidsledighed leder til lavere livskvalitet og tidlig død. Ud fra et positivistisk perspektiv er langtidsledighed således et socialt problem på grund af konsekvenserne for de langtidsledige. Vælger projektgruppen i stedet socialkonstruktivisme, kan man forestille sig, at projektet kommer frem til, at langtidsledighed er blevet til et socialt problem på grund af en længevarende offentlig diskussion mellem politikere, arbejdsgiverorganisationer, fagforeninger og andre NGO'er. Ud fra det socialkonstruktivistiske perspektiv er langtidsledighed således blevet et socialt problem, fordi de væsentlige aktører igennem en diskussionsproces langsomt fik og udbredte opfattelsen, at langtidsledighed er et socialt probl

Anvendelse af videnskabsteoretiske begreber I projektarbejdet anvender studerende implicit begreber fra videnskabsteorien som fx deduktion/induktion og kvalitativ/kvantitativ ved at følge fagområdets traditioner, som de er beskrevet i lærebøger og formidlet gennem undervisningen. Tekniske rapporters metodeafsnit fokuserer ikke på diskussionen af videnskabsteoretiske forudsætninger i projektet, men i stedet på 1) beskrivelsen af metode og 2) argumentationen for, at den beskrevne metode vil lede til en god løsning på projektets problem, en rigtig konklusion og et sæt anvendelige anbefalinger til virksomheden. Når man har læst metodeafsnittet i et teknisk projekt, skal man som læser (helst) føle sig overbevist om, at metoden faktisk vil føre til en god løsning og en rigtig konklusion.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Hvad et metodeafsnit er, og hvordan man vælger den rigtige metode, er to spørgsmål, som studerende ofte stiller deres vejleder ("Hvad skal der stå i metodeafsnittet?"). Valget af metode er ofte en uklar opgave, og den vægt, som undervisere sætter på metodevalget, varierer meget fra uddannelse til uddannelse. Lad os først slå fast, hvad en metode er. For alle projekter – lige fra bundne opgaver tidligt på et studie til afgangsprojektet – udgør metoden svaret på spørgsmålet om, hvordan I vil gennemføre jeres projekt. I projekter, der løser et problem, er metoden derfor svaret på, hvordan I planlægger at løse problemet. Når I står over for valget af metode, skal I ganske enkelt spørge jer selv: "Hvordan har vi tænkt os at nå frem til løsningen på projektets problem?" Svaret på dette spørgsmål er jeres metode. En mere konkret formulering er: "Hvad vil vi præcist gøre og i hvilken rækkefølge?" Svaret er altid en rækkefølge af på hinanden følgende aktiviteter ("først X, så Y og til sidst Z"). Det er vigtigt, at I som projektgruppe er klar over, at I ofte kan løse projektets problem på flere måder. Den måde, I vælger at udføre jeres projekt på, er således én blandt flere mulige.

Eksempel på metodevalg Et afgangsprojekt handler om at øge en produktionsvirksomheds evne til at levere kundeordrer til tiden. Projektgruppen vil undersøge årsagerne til, at ordrer leveres for sent. Gruppen har tre mulige metoder at vælge imellem: 1. At følge en række ordrer for at nå frem til de årsager, der ligger bag de forsinkede ordrer. Derefter at udvikle en løsning, der eliminerer disse årsager. 2. At spørge medarbejderne, hvor ofte og hvorfor ordrer er forsinkede. Derefter at udvikle en løsning, der eliminerer disse årsager. 3. At dele produktporteføljen ind i grupper og undersøge, hvilke produktgrupper der oftest er forsinkede. Derefter at udvikle en løsning, der adresserer disse produktgrupper. Det er også muligt at bruge to metoder samtidigt for at se, om metoderne leder frem til de samme årsager. Projektgruppen skal tage et valg om metode og argumentere for, at deres valg leder frem til pålidelige resultater og en god løsning på virksomhedens leveranceproblemer. I tekniske projekter afhænger konklusionens validitet (rigtighed) af løsningen, idet konklusionen er en sammenfatning af projektets løsning. Når I vælger metode, skal I derfor først og fremmest spørge jer selv: "Hvilken metode vil lede frem til den bedste løsning?" Derefter skal I argumentere for jeres valg og overbevise læseren og måske

virksomheden om, at jeres valg er det bedste til at nå en god løsning (og dermed en valid konklusion). Se mere om, hvordan I kan beskrive projektets metode i projektrapporten i kapitel 12.

Den røde tråd Man kan ofte høre en underviser eller vejleder tale om "den røde tråd" i forbindelse med et projekt. Den røde tråd betyder, at enkeltdelene i rapporten hænger sammen. Der er særligt fire ting, der skal være på plads: at den valgte metode vil lede til en løsning på problemet i problemformuleringen at metoden faktisk følges i analysen at analysens resultater bruges i designet af løsningen at konklusionen, der sammenfatter løsningen, besvarer problemformuleringen. Hvis vejlederen siger, at et projekt er "æbler og pærer", er det ofte, fordi et af disse fire punkter ikke overholdes. I frugtanalogien bør frugterne være samme slags. Hvis man hører ordet "frugtsalat", er den altså helt gal. En nærmere beskrivelse af den røde tråd findes i kapitel 12.

Tekniske projekters overordnede struktur Metoden i et teknisk projekt består typisk af to dele: 1. Projektets "store skridt" (disse skridt udgør tilsammen projektstrukturen) 2. De konkrete, faglige værktøjer og redskaber, et projekt bruger inden for hvert af de store skridt. Projektstrukturen kan variere, men har dog en række typiske kendetegn. Et teknisk projekts struktur adskiller sig ganske væsentligt fra grundstrukturen i den klassiske undersøgelse, som ses i figur 5.2. Denne består af en introduktion, undersøgelsesspørgsmål (problemformulering), teori og metode, analyse og resultater samt diskussion og konklusion. Hvordan de enkelte afsnit vægtes, afhænger af fagområdets art og traditioner.

Figur 5.2. Strukturen på den klassiske undersøgelse

Den klassiske undersøgelse bruges på humanistiske og samfundsvidenskabelige uddannelser, hvor formålet med et projekt oftest er at bidrage til vores alles viden ved at besvare ubesvarede spørgsmål om verden, samfundet, mennesket, kulturen, osv. Et

spørgsmål på amerikanske studier kan fx handle om, hvordan brugen af sociale medier påvirker præsidentvalgkampe i USA, og et spørgsmål på historieuddannelsen kan handle om, hvordan en stigende efterspørgsel på svensk jern påvirkede dannelsen af Hansestæderne. Disse spørgsmål kræver grundige undersøgelser, der leder til valide svar. Svar på ubesvarede spørgsmål er dog ikke løsninger på problemer, men altså svar på spørgsmål. Tekniske projekter handler nemlig oftest om at designe løsninger på problemer. Som beskrevet i kapitel 3 er problemer enten, at noget skal forbedres, eller at noget, som nogen ønsker sig, aktuelt ikke findes. Tekniske projekter har derfor en anden struktur end den klassiske undersøgelse. Figur 5.3 viser den klassiske struktur for et teknisk projekt, der løser et problem. Først introduceres læser til projektet, virksomheden og problemformuleringen. Dernæst definerer projektet de vigtigste begreber og forklarer, hvordan projektet gennemføres (metoden). Herefter følger analyse, design af løsning, test og implementering af løsninger samt til sidst en konklusion og en række konkrete anbefalinger til virksomheden. Strukturen i figur 5.3 er "engineering classic" og anvendes flittigt af studerende på de praksisorienterede tekniske uddannelser. Tekniske kandidatafhandlinger, også på ingeniørstudier, kan have en lidt anden struktur. Det beskrives nærmere i kapitel 16. De næste afsnit detaljerer forløbet i tekniske projekter, der hhv. forbedrer noget eksisterende og designer noget nyt fra bunden. Den overordnede struktur fra figur 5.3 er den samme, men analysen er forskellig. Hvor analysen i projekter, der forbedrer noget eksisterende, handler om at identificere årsagerne til, hvorfor noget kan eller skal forbedres, så handler analysen i projekter, der designer noget nyt fra bunden, om at specificere kravene til løsningen, identificere løsningens enkeltdele (her i bogen kaldt "subsystemer") og undersøge de tekniske løsningsmuligheder.

Figur 5.3. Den klassiske struktur på et teknisk projekt

Et typisk forløb for et projekt, der forbedrer noget eksisterende Figur 5.4 viser et typisk forløb for et projekt, der forbedrer noget eksisterende. Der ses fire grønne kasser, der hver indeholder en række aktiviteter og symboliserer projektets "store skridt".

Figur 5.4. Det typiske forløb i et projekt, der forbedrer noget eksisterende

Det første skridt i et projekt består i at specificere, hvilken variabel projektet vil forbedre. Næste skridt er en årsagsanalyse af, hvorfor variablen aktuelt er for dårlig. Årsagsanalysen svarer på en række hvorfor-spørgsmål, der i figuren er afbilledet med afbrudte vandrette streger. Årsagsanalysen ender med en række grundårsager (på engelsk: root causes), som I kan adressere med løsninger. Grundårsagerne er afbilledet som prikker. Hver kæde af hvorfor-spørgsmål udgør en kausal sammenhæng mellem variablen og årsag. Tredje skridt er, når I har identificeret og specificeret grundårsagerne, at designe løsningen. Hvis årsagsanalysen består af én kæde af hvorfor-spørgsmål, der leder til én grundårsag til problemet, er der typisk én løsning. Hvis årsagsanalysen viser sig at være et helt træ som i figuren og leder frem til to eller flere grundårsager, består løsningen ofte af en sammensat række enkeltelementer. Frem for at designe alle de mulige løsningselementer skal I som projektgruppe ofte prioritere og vælge et eller flere ud. Prioriteringen er illustreret i figuren med et filter. Nogle løsningsforslag går gennem filteret, andre bliver hængende og bliver altså ikke prioriteret. Fjerde og sidste skridt i projektforløbet er at teste og implementere løsningen. Implementeringen ligger dog ofte uden for projektets scope (fx at bygge huset, produktionsmodne produktet eller implementere en ny procedure).

Til alle aktiviteterne anvender I jeres fagområdes værktøjer og metoder. De anvendte metoder er jeres belæg for, at løsningen faktisk vil løse problemet. Se mere om løsningsdesign, prioritering af elementer, test og implementering i kapitel 7 og 8.

Et typisk forløb for et projekt, der designer noget nyt fra bunden Figur 5.5 viser det typiske forløb for et projekt, der designer noget nyt fra bunden (fx et nyt produkt eller en ny app).

Figur 5.5. Det typiske forløb i et projekt, der designer noget nyt fra bunden

Problemet i denne type projekter er et behov (typisk for den virksomhed, I samarbejder med, eller for en af dens kunder/kundegrupper). Første skridt i projektet er derfor gennem samtaler og indledende arbejde med virksomheden at definere dette behov. Næste skridt er, gennem en nærmere analyse af behovet, at udlede en kravspecifikation. Nogle af kravene vil være særegne for netop denne løsning, mens andre vil være aktuelle på grund af løsningens art (fx at et hus skal overholde bygningsreglementet).

Eksempel på krav til en løsning

Et projekt handler om at udvikle en app, som et medicinalfirma kan bruge til at indsamle data fra patienternes brug af medicinen. Projektgruppen skal identificere krav til bl.a. følgende elementer: Appens brugerflade Funktioner og dataindsamling Patienternes hardware (telefon, iPad eller PC) Opbevaringen af data i virksomhedens databaser Sikkerhed. Nogle af disse krav vil udspringe af virksomhedens app-behov, mens andre vil udspringe af, at løsningens art er en app, der anvender brugerdata (fx skal persondataforordningen overholdes). Succeskriteriet for analyser af krav er, hvorvidt analysen har fundet og korrekt fortolket alle de krav, som interessenter, lovgivning mv. har til det emne, der skal designes. Det sker fra tid til anden, at virksomheden allerede har en kravspecifikation, som de giver til jer. Hvis I oplever dette, så tjek, om kravspecifikationen er specifik nok på de enkelte krav, om der er modstridende krav, og om alle relevante krav er i specifikationen (se kapitel 6 om identificeringen af krav). Ud fra kravspecifikationen skal jeres analyse nedbryde emnet i subsystemer. For eksempel kunne et sæt subsystemer til et måleapparat være 1) strøm, 2) sensor, 3) kabinet, 4) kontrolenhed og 5) en hæve-sænkefunktion af sensoren. For hvert subsystem er det jeres opgave i analysen at identificere en række tekniske løsningsmuligheder. Løsningen, som I designer, skal være teknisk realiserbar og funktionsdygtig både på subsystemniveau og som et element i det samlede emne. Lad os fx sige, at ovennævnte måleapparat måler viskositeten af benzinvarianter, der forlader det brandvarme destilleri på et raffinaderi. Her kan I ikke vælge en hydraulisk hæve-sænke-løsning, fordi varmen fra destilleriet får hydraulikolien i hæve-sænke-løsningen til at ændre karakter. Et projekt vil ofte foregå som en iterativ proces. For eksempel inden for byggeri, hvor løsningsdesign og kravspecifikation løbende bliver mere specifik og detaljeret. Iterationer kan også (som i softwareudvikling) foranlediges af den læring om løsningen, der opstår gennem projektforløbet. Iterationer er i figuren vist som store sorte pile. Tredje skridt er løsningsdesignet. På nogle uddannelser er det traditionen at udvikle én løsning, mens det på andre uddannelser er traditionen at udvikle to eller flere løsningskoncepter, hvorfra der skal vælges én. Figur 5.4 viser tre mulige løsninger på det givne projekt, hvoraf projektgruppen sammen med virksomheden skal vælge én. Fjerde og sidste skridt i projektforløbet er at specificere den ene valgte løsning. Implementeringen ligger som regel uden for projektet, men hvis den ikke gør, lægges den ind som en ekstra aktivitet.

Standardmetoder som rygraden i projektets overordnede struktur projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

En praksisorienteret uddannelse handler grundlæggende om at give jer en forståelse af et afgrænset fagligt område samt en række færdigheder, som I kan bruge i jeres job efter endt uddannelse. Blandt færdighederne er evnen til at kunne bruge den faglige viden, der bl.a. består af en række metoder og værktøjer. For eksempel kan en kemiingeniør bruge en korrekt fremgangsmåde til at blande stofmængderne i et batch medicin, en bygningsingeniør kan bruge en fast metode til at designe et lovmæssigt godkendt fundament, en eksportingeniør kan anvende en metode til valg af distributionsstrategi, og en produktionsingeniør kan bruge en metode til beregning af en produktionsplans omkostninger. Inden for de fleste uddannelser findes der derfor en række standardmetoder, der anviser, hvilke skridt et projekt bør følge. Eksempler på disse metoder er DMAIC inden for procesoptimering, V-modellen inden for softwareudvikling og Rapid Prototyping inden for design af mekaniske komponenter. Disse metoder kan være med til at sikre, at I som projektgruppe ikke overser en vigtig aktivitet i projektet. DMAIC inddeler fx projektet i fem skridt: Define, Measure, Analyze, Improve og Control. Hvis denne metode bruges, glemmes ingen af de fem skridt. Standardmetoder er ofte branchespecifikke, og de forskellige uddannelser arbejder derfor typisk med en projektstruktur og -terminologi, der er udbredt i branchen.

Hvornår i projektforløbet metodevalg foretages projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Projektstrukturen vælges ofte tidligt i projektforløbet. Allerede efter at problemformuleringen er nedfældet, kan I påbegynde tankevirksomheden omkring projektstrukturen. Når I har defineret de væsentligste begreber i problemformuleringen, kan strukturen fastlægges. De konkrete faglige værktøjer vælger I løbende i projektperioden. Nogle værktøjer og redskaber kan I vælge samtidigt med den overordnede struktur, men andre kan I først vælge senere i projektforløbet. Det er ofte ikke muligt at forudse, hvilke konkrete værktøjer og redskaber I har behov for, når I påbegynder årsagsanalysen, da den kan lede i mange forskellige retninger. Derfor foregår valget af en stor del af disse værktøjer typisk senere i projektet, ofte først dybt inde i analysearbejdet (se et eksempel herunder).

Eksempel på, hvordan konkrete metoder ofte først kan vælges midt i analysearbejdet En projektgruppe undersøger, hvorfor kassationsraten fra en kvalitetskontrol er steget. Årsagsanalysen leder frem til, at produktet fejler, fordi hvert tredje produkt mangler en pakning (O-ring). Spørgsmålet er så, hvorfor disse pakninger mangler. Projektgruppen finder ud af, at medarbejderne glemmer pakningerne, fordi deres motivation er faldet. Projektgruppen vil forstå, hvorfor medarbejdermotivation falder, og inddrager en metode til analyse af motivation. Deres analyse leder frem til, at en nyansat chef i afdelingen ikke motiverer medarbejderne. Projektgruppen inddrager derfor ny litteratur om, hvordan en chefs ledelsesstil påvirker medarbejdernes motivation.

Argumentation for alle væsentlige valg – også metodevalget projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Hver gang I træffer et valg i projektet, der har betydning for, hvordan I gennemfører projektet, så har dette indflydelse på validiteten af konklusion og projektets anbefalinger til virksomheden. Hver gang I træffer et sådant valg, bør I derfor argumentere for valget. Jeres argumentation skal overbevise læseren om, at det givne valg er det rigtige. Den store udfordring er ofte at være bevidste om de valg, man træffer. Her er nogle eksempler: 1. Den måde, man definerer et begreb, er et valg, idet én definition af et begreb implicit er et fravalg af andre potentielle definitioner 2. Brugen af en teori eller faglig metode er et valg, idet andre mulige teorier/metoder er fravalgt 3. En konkret analyseteknik (fx en statistisk analyse) er et valg 4. Et bestemt måleinstrument er et valg, medmindre der intet alternativ er 5. At inddrage én eller flere af virksomhedens medarbejdere til beslutninger er et valg (forklar læseren, hvorfor de valgte personer er de rigtige til opgaven). Et argument er en forklaring på, hvorfor man har valgt, som man har. Man kan fx argumentere ud fra et formål. ("Fordi målet er X, anvender undersøgelsen metoden Y"). Man kan også argumentere ud fra projektets særlige omstændigheder (fx "Undersøgelsens data rækker ikke til en sikker konklusion, så derfor anvender analysen en estimeringsteknik"). I kan argumentere for valg i løsningsdesignet ved at henvise til de krav til løsningen, som projektet selv har udledt (ofte i projektets analyse). For eksempel således: "Tagkonstruktionens opbygning og materialevalg er valgt, så konstruktionen lever op til kravet om, at taget kan bære 70 cm sne." At argumentere ud fra projektets egne udledte krav til en løsning styrker den røde tråd, fordi jeres analyse og jeres løsningsdesign på den måde hænger godt sammen. Husk at gøre det eksplicit for læser, at kravet kommer fra analysen, ved at henvise til den side, kravet beskrives på, evt. ved at bruge ordet jævnfør. Det kan fx gøres som i denne sætning: "Jævnfør analysen side 34 …". Jævnfør kan forkortes til "jf.".

Utraditionelle valg, der afviger fra normen Det er særligt vigtigt at argumentere for de valg, der afviger fra normen inden for et fagligt felt. For eksempel hvis en projektgruppe vælger en utraditionel metode eller en metode, der som regel anvendes til andre formål end det aktuelle. Forklar for læser, hvorfor jeres valg er bedre end det traditionelle valg.

Eksempel på et valg, der afviger fra normen En projektgruppe på en uddannelse i softwareudvikling skal udvikle et program. Inden for softwareudvikling er det normen at anvende agile udviklingsmetoder (fx Scrum). Her arbejdes i iterative loops, der løbende involverer den virksomhed, der samarbejdes med, og kommende brugere af programmet. I stedet for at anvende en agil udviklingsmetode vælger projektgruppen at anvende den klassiske vandfaldsmetode. Vandfaldsmetoden adskiller sig fra agile metoder, ved at projektet kun gennemløber én stor proces i stedet for en række iterative loops. Fordi dette valg ikke er "det normale" inden for fagområdet, bør projektgruppen bruge en del energi på at forklare læseren, hvorfor vandfaldsmetoden er valgt.

Den praktiske projektplanlægning: Gantt-diagrammet projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Den praktiske planlægning af et projekt begynder ofte lige efter, at I har nedfældet problemformuleringen og defineret de væsentligste begreber i problemformuleringen. Den praktiske projektplan er en plan for, hvornår og i hvilken rækkefølge I vil gennemføre de aktiviteter, der følger efter metodeafsnittet. De forudgående aktiviteter (fx skabe kontakt til virksomhed og problemanalyse) indgår derfor typisk ikke i projektplanen. Erfarne studerende vil dog ofte udarbejde en projektplan fra første færd, således at der er styr på, hvornår problemanalyse og problemformulering skal være færdige. På nogle kurser har underviserne indlagt midtvejsmøder, milepælsmøder og lignende for at understøtte jeres fremgang. Det sker endda, at underviserne har krav til delafleveringer undervejs i processen for at sikre, at ingen projektgrupper falder for langt bagud. I dette afsnit vil vi fokusere på det såkaldte Gantt-diagram til planlægning af projektet. Gantt-diagrammet, som er illustreret i figur 5.6, er en praktisk og nemt anvendelig teknik til at skabe overblik over et projekt, uagtet hvor komplekst det er. Softwareprogrammet MS Project er bygget over Gantt-diagrammet, men teknikken kan sagtens anvendes uden særlig software. Den kan endda anvendes uden en computer og blot nedfældes på papir. I projekter på en uddannelse er MS Excel et godt redskab til at udarbejde Ganttdiagrammer.

Figur 5.6. Skitse af Gantt-diagram

Udarbejdelsen af et Gantt-diagram følger seks trin, som vil blive behandlet i det følgende. Disse trin er: 1. Identifikation af projektets aktiviteter 2. Sætte aktiviteterne i den rigtige rækkefølge 3. Identifikation af hver aktivitets forgængere 4. Estimering af hver aktivitets tidsbehov og valg af ansvarlige personer 5. Færdiggørelse af Gantt-diagrammet (indtegne streger) 6. Identifikation af den kritiske vej.

Identifikation af projektets aktiviteter Første trin er at identificere de aktiviteter, projektet skal indeholde. Det er ikke nemt, og det er heller ikke sikkert, at I kan identificere alle aktiviteter, inden projektet for alvor er i gang. Heldigvis kan projektplanlægning med Gantt-diagrammer godt begynde med et sæt af foreløbige aktiviteter. I kan så udvide dette sæt, efterhånden som I bliver klogere på jeres projekt. I projekter tidligt på uddannelsen giver underviserne ofte en beskrivelse af projektets mål, faglige indhold og eventuelle laboratorieøvelser, værkstedselementer og lignende. I kan begynde aktivitets-identifikation ved at læse projektbeskrivelsen. Hver gang projektbeskrivelsen fortæller, at I skal gennemføre en aktivitet, skriver I denne aktivitet ned på en liste. Det giver jer en lang liste. Herudover bør I forsøge at identificere aktiviteter, der rent logisk må være en del af projektet, selvom de ikke er eksplicit nævnt i projektbeskrivelsen. I kan brainstorme jer frem til meget allerede tidligt i projektforløbet.

Sætte aktiviteterne i den rigtige rækkefølge Listen af aktiviteter i et projekt fortæller ikke, i hvilken rækkefølge aktiviteterne bør gennemføres. At sætte aktiviteterne i den rigtige rækkefølge er derfor næste skridt i udarbejdelsen af Gantt-diagrammet. Her skal I bruge dels jeres viden om det aktuelle projekt og dels jeres logiske sans.

Eksempel på, hvordan almen logik anvendes til at sætte aktiviteter i rækkefølge Et projekt på maskiningeniøruddannelsen handler om at designe en ny type hydraulisk cylinder til en motor. Blandt aktiviteterne i projektet er følgende: At undersøge, hvordan cylinderen skal bruges At specificere de tekniske krav til cylinderen baseret på, hvordan cylinderen skal bruges At designe cylinderen, så den overholder de tekniske krav. Disse tre aktiviteter har en helt naturlig rækkefølge. Først aktivitet 1 (brug), så 2 (krav) og til sidst 3 (design). Rent logisk kan man ikke specificere kravene til cylinderen korrekt uden at vide, hvad cylinderen skal bruges til. Det er heller ikke logisk muligt at designe cylinderen korrekt, hvis man ikke kender kravene til dens brug. I eksemplet ovenfor er rækkefølgen temmelig simpel. Ofte kræver det dog større faglig ekspertise og megen tankevirksomhed at sætte aktiviteterne i den rigtige rækkefølge. Selv studieprojekter kan have lange lister med aktiviteter – det er ikke unormalt af have op til 50 aktiviteter i et større semesterprojekt. En praktisk måde at sætte i rækkefølge er

at skrive alle identificerede aktiviteter på små gule sedler (én aktivitet per seddel) og derefter sætte dem op på væggen. Så kan I sammen se og diskutere den rigtige rækkefølge. Denne type diskussion indeholder typisk kommentarer som "Vi kan jo ikke gøre X, før vi har gjort Y". I skal for hver aktivitet stille jer selv to spørgsmål: 1. Hvilke aktiviteter skal være færdige før den aktuelle aktivitet? 2. Hvilke aktiviteter kan først påbegyndes, når den aktuelle aktivitet er afsluttet?

Eksempel på, hvordan et projekts aktiviteter sættes i rækkefølge Et projekt handler om at designe og planlægge et produktionssystem for et nyt produkt. Projektgruppen har identificeret følgende aktiviteter og sat dem i rækkefølge: Nr.

Aktivitetsnavn

1

Fastlægge, hvilke komponenter produktet består af

2

Beslutte, hvilke komponenter der skal egenproduceres

3

Specificere produktionsmaskiner

4

Indkøbe produktionsmaskiner

5

Indrette produktionshal med produktionsmaskiner

6

Udarbejde produktionsplan

7

Hyre og træne operatører

8

Organisere det daglige arbejde

9

Indkøbe råvarer og komponenter og indrette råvarelager

10

Opstille og klargøre de enkelte arbejdsstationer

11

Indrette færdigvarelager

12

Sætte produktionen i drift

Identifikation af hver aktivitets forgængere

Planen består indtil nu af to kolonner (en kolonne med aktivitetsnumre og en kolonne med aktivitetsnavne). Tilføj nu en kolonne til højre, og kald den "Forgængere". Opgaven er så (igen), aktivitet for aktivitet, at tænke over, hvilke foregående aktiviteter der skal være afsluttet, før den pågældende aktivitet kan gennemføres. Aktivitet 1 på listen i eksemplet ovenfor ("Fastlægge, hvilke komponenter produktet består af") har ingen forgængere i det givne projekt. Det er derfor, aktiviteten står øverst på listen. Aktivitet 2 handler om at beslutte, hvilke af produktets komponenter der skal egenproduceres, og hvilke der skal købes ind hos leverandører. Denne aktivitet kan ikke gennemføres, før man ved, hvilke komponenter produktet består af. Derfor er aktivitet 1 en forgænger for aktivitet 2. Aktivitet 2 resulterer i en liste med komponenter, virksomheden skal producere på egen fabrik. Aktivitet 3 skal bestemme, hvilke produktionsmaskiner virksomheden skal bruge for at producere komponenter på egen fabrik. Til dette skal man vide, hvilke komponenter der skal produceres på produktionsmaskinerne. Altså er aktivitet 2 en forgænger for aktivitet 3. Listen herunder viser alle aktiviteters forgængere.

Eksempel på projektplan med tidsforbrug og ansvarlige personer

Nr.

Aktivitet

Forgængere

1

Fastlægge, hvilke komponenter produktet består af

Ingen

2

Beslutte, hvilke komponenter der skal egenproduceres

1

3

Specificere produktionsmaskiner

2

4

Indkøbe maskiner til produktionen

3

5

Indrette produktionshal

3 og 4

6

Udarbejde produktionsplan

3

7

Hyre og træne operatører

3 og 6

8

Organisering af arbejdet

5 og 6

9

Indkøbe råvarer og komponenter og indrette råvarelager

2, 5 og 6

10

Opstille og klargøre de enkelte arbejdsstationer

4 og 5

11

Indrette færdigvarelager

5 og 6

12

Sætte produktionen i drift

8, 9, 10 og 11

To regler er vigtige, når man skal identificere forgængere: 1. Kun direkte forgængere skal skrives på listen. En aktivitets forgængere har typisk også forgængere, men disse skal ikke angives. I eksemplet ovenfor er aktivitet 1 forgænger til aktivitet 2, og aktivitet 2 er forgænger til aktivitet 3. Man kan derfor måske fristes til at angive både aktivitet 1 og 2 som forgængere til aktivitet 3, men det ville være en fejl, da kun aktivitet 2 er direkte forgænger. 2. Man skal huske alle direkte forgængere til en aktivitet. Tag fx aktivitet 7, der består i at hyre og træne medarbejdere. For at kunne hyre og træne medarbejdere skal man vide, hvilke maskiner produktionen består af (aktivitet 3), og man skal kende produktionsplanen (aktivitet 6). Man kan måske fristes til kun at nævne aktivitet 6 som forgænger for aktivitet 7, idet aktivitet 3 jo allerede er forgænger for aktivitet 6. Men det ville være en fejl. Hvis aktivitet 3 er en direkte forgænger for både aktivitet 6 og 7, skal aktiviteten nævnes i forgængerkolonnen for både aktivitet 6 og 7.

Estimering af hver aktivitets tidsbehov og valg af ansvarlige personer Næste skridt er at estimere tidsforbruget for hver aktivitet og beslutte, hvilken person i jeres gruppe der skal være ansvarlig for aktiviteten. Tidsestimering af aktiviteter i et studieprojekt er ikke nemt. I arbejdslivet påbegynder man måske den samme type projekt for 15. gang, hvilket gør det nemmere at tidsestimere aktiviteterne, mens man som studerende typisk kaster sig over et nyt projekt hver gang. Brug derfor ikke alt for lang tid på denne opgave, men nøjes med gode gæt. En tommelfingerregel for studieprojekter er, at nemme opgaver tager en-to dage, mellemstore opgaver tre-fire dage, og svære opgaver fem-otte dage. I løbet af projektperioden får I større kendskab til aktiviteterne og kan løbende opdatere jeres plan med mere præcist estimerede tidsforbrug. Et studieprojekt fylder et antal ECTS-point (fx 10 eller 15 point) og udgør derfor ikke hele semestrets arbejdsbyrde. I har som regel andre kurser ved siden af, og derudover har mange studerende studiejobs og andre aktiviteter i løbet af en uge. Når I giver en aktivitet et antal dage og skriver dette i projektplanen, bør antallet af dage udtrykke den periode, hvori I arbejder på aktiviteten. På grund af alle jeres andre aktiviteter, der ligger uden for projektet (kurser, studiejob mv.), udtrykker en aktivitets tildelte dage ikke, at I arbejder al jeres tid på projektet (altså alle 8 timer om dagen). Den tildelte periode til en aktivitet på et antal dage (fx 4 dage) skal altså udtrykke, at aktiviteten er igangværende i denne periode og afsluttes på periodens sidste dag. Hvis I regner med, at en aktivitet kan klares på 8 timer, så tildel ikke kun én dag, men tre dage. Så kan I fordele de 8 timer på de tre dage og tage højde for jeres øvrige kurser, studiejob mv. At være ansvarlig for en opgave er ikke det samme, som at man udfører hele opgaven selv, men blot, at man er ansvarlig for, at den bliver gjort færdig. Der er dog tit sådan, at den person, der er ansvarlig for en opgave, løser størstedelen af den. Hvilke personer der får hvilke opgaver, beror på kvalifikationer, lyst og læringsbehov. At tildele ansvar for

opgaver er en balancegang. På den ene side bør I undgå at sætte de samme personer til den samme type opgave hele tiden, for så er læringen lav. På den anden side skal projektet en dag afleveres og være færdigt. En god grundregel er derfor at sætte de enkelte personer på de aktiviteter, som de har brug for at lære, og hvis der så bliver tidsnød, rotere, så alle kommer til at arbejde med deres favoritopgaver.

Eksempel på projektplan med tidsforbrug og ansvarlige personer Tidsforbruget er estimeret som antal dage. SB, GH, AO og JK er initialer på de enkelte aktiviteters ansvarlige personer. Nr.

Aktivitet

Forgængere Varighed

Person

1

Fastlægge, hvilke komponenter produktet består af

Ingen

2

SB

2

Beslutte, hvilke komponenter der skal egenproduceres

1

2

GH

3

Specificere produktionsmaskiner

2

4

AO

4

Indkøbe maskiner til produktionen

3

4

AO

5

Indrette produktionshal

3 og 4

2

JK

6

Udarbejde produktionsplan

32

GH

7

Hyre og træne operatører

3 og 6

2

SB

8

Organisering af arbejdet

5 og 6

3

SB

9

Indkøbe råvarer og komponenter og indrette råvarelager 2,

5 og 6

2

JK

10

Opstille og klargøre de enkelte arbejdsstationer 4 og 5

5

GH

11

Indrette færdigvarelager

5 og 6

3

JK

12

Sætte produktionen i drift

8, 9, 10, 11

1

Alle

Færdiggørelse af Gantt-diagrammet (indtegne streger)

Når forgængere, tidsforbrug og ansvarlige personer er på plads, kan planen færdiggøres. Markér 20-40 kolonner i dit regneark, alt efter hvor lang tid projektet må tage, og gør dem smalle (ca. 30 pixels). Hver af disse kolonner repræsenterer én dag. Marker weekender og feriedage fx med en blå nuance, så man kan se, at I ikke arbejder på disse dage. Farvelæg derefter cellerne. For hver aktivitet farvelægges det antal celler, der svarer til det antal arbejdsdage, aktiviteten tager. Husk at tage hensyn til, hvilke forgængere en aktivitet har. For eksempel har aktivitet 2 aktivitet 1 som forgænger. Derfor går aktivitet 2 først i gang, når aktivitet 1 er afsluttet.

Eksempel på det færdige Gantt-diagram

I ovenstående Gantt-diagram markerer de lyseblå celler lørdage og søndage, mens de mørkeblå celler markerer aktiviteterne. Antallet af celler, som en aktivitet fylder, viser antallet af dage, som en aktivitet er estimeret til at vare (varighed er noteret i kolonnen "V.", som står for Varighed). Det færdige Gantt-diagram viser, at projektet er færdigt på dag 26. Det viste Gantt-diagram er udarbejdet i MS Excel. Hvis I har adgang til projektsoftware som fx MS Project og har lært at bruge dette, så anvend det i stedet. Her er især den løbende opdatering af projektplanen nemmere.

Identifikation af den kritiske vej Som projektleder har man brug for at vide, hvilke aktiviteter der er kritiske at færdiggøre til tiden. Sidste trin i udarbejdelsen af Gantt-diagrammet er derfor at identificere de aktiviteter, der befinder sig på projektets kritiske vej. En aktivitet befinder sig på den kritiske vej, hvis en forsinkelse af aktiviteten på én dag betyder, at hele projekt bliver forsinket. I kan markere aktiviteterne på den kritiske vej med rødt i Gantt-diagrammet, som det ses i eksemplet på næste side.

Eksempel på det færdige Gantt-diagram med kritisk vej

Her er bl.a. aktivitet 3 markeret. For hvis aktivitet 3 forsinkes med en dag, så forsinkes aktivitet 4, der har aktivitet 3 som forgænger. Og hvis aktivitet 4 forsinkes, så forsinkes aktivitet 5, og hvis aktivitet 5 forsinkes, så forsinkes aktivitet 10, og hvis aktivitet 10 forsinkes, så forsinkes aktivitet 12 og altså hele projektet. Aktivitet 11 befinder sig derimod ikke på den kritiske vej. For selvom denne aktivitet forsinkes med en dag, forsinkes projektet som helhed ikke. Sker der imidlertid det uventede, at aktivitet 11 forsinkes med tre dage, så forsinkes hele projektet. Det betyder, at aktiviteten pludselig befinder sig på den kritiske vej og skal markeres med rødt. Den kritiske vej kan således ændre sig i løbet af projektet, og derfor bør I hver uge til projektgruppemødet gennemgå og opdatere jeres projektplan.

Tips til at gøre projektplanen hurtigere og mere robust projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Her følger en række tips til at gøre jeres projektplan hurtigere og mere robust. Tipsene handler bl.a. om, hvordan I som gruppe udnytter jeres gruppemedlemmers tid i projektet mest effektivt.

Udnyt alle personer i jeres projektgruppe En projektgruppe består ofte af 4-6 personer. Alle personer bør ikke arbejde på én aktivitet samtidigt. En projektplan bør køre flere aktiviteter samtidigt – minimum det antal aktiviteter, der svarer til halvdelen af medlemmerne i projektgruppen. Hvis I er seks personer i projektgruppen, bør projektplanen på alle tidspunkter have minimum tre aktiviteter i gang samtidigt. Man kan se, hvor mange aktiviteter der er i gang på samme dag, ved at tjekke den lodrette kolonne for dagen og tælle, hvor mange aktiviteter der er planlagt. I eksemplet ovenfor har projektplanen i perioden fra dag 1 til dag 10 kun angivet én aktivitet om dagen. Hvis der er to eller flere personer i gruppen, bør der være planlagt flere aktiviteter per dag. Hvis et projekt har for få aktiviteter i gang samtidigt, er en (hurtig) løsning at trække fremtidige aktiviteter frem i planen. På den måde udnytter I ressourcerne bedre og bliver typisk hurtigere færdige. Aktiviteterne skal dog ikke trækkes så langt frem, at der bliver problemer med ikke-afsluttede forgængere. I eksemplet ovenfor er der faktisk ikke en eneste aktivitet, der kan trækkes frem. Her bliver det næste tip (beskrevet herunder) aktuelt.

Udnyt "trekanten under aktivitetsvandfaldet" Aktiviteterne bevæger sig som et vandfald begyndende i øvre venstre hjørne og sluttende i nedre højre hjørne. Den grønne trekant under aktivitetsvandfaldet er et område, I kan udnytte. De fleste aktiviteter kan deles ind i en forberedelsesdel og en afslutningsdel. Tag fx en aktivitet, der handler om at udvikle et regneark til beregning af en række tal, der skal bruges senere i projektet. En sådan aktivitet kan ikke gennemføres, før de forgængeraktiviteter, der leverer inputtene til beregningen, er afsluttet. Og dog – I kan sagtens udvikle regnearket, lang tid før forgængerne er afsluttet. I kan bare ikke afslutte beregningerne. Lad os antage, at denne aktivitet har en estimeret varighed på fem dage. I vurderer nu, hvor mange af disse fem dage det vil tage at udvikle regnearket. Lad os sige tre dage. Disse tre dage kan gennemføres på et hvilket som helst tidspunkt tidligere i

projektperioden. Forberedelsesdelen af aktiviteter er således oplagte at hive frem og ind i "trekanten under aktivitetsvandfaldet". Det bedste er at placere forberedelsesdelene af fremtidige aktiviteter på tidspunkter, hvor der er få andre aktiviteter. Se nedenstående eksempel. Her er forberedelsesdelene udskilt og markeret med blåt.

Eksempel på hurtigere og mere robust projektplan, der udnytter projektgruppens ressourcer bedre

Estimér aktiviteters varighed uden buffer, og afslut projektplanen med én stor buffer En buffer er mer-tid, der lægges til en aktivitets reelle tid for at tage højde for uforudsete forsinkelser. Har man en buffer, er der derfor større chance for, at man har tid nok til at gennemføre aktiviteten. Det er dog et naturligt menneskeligt karaktertræk at vente med at afslutte aktiviteter til sidste øjeblik. Med en buffer på to dage ender man tit med at vente de to dage, før man går i gang, og så er chancen for at færdiggøre aktiviteten til tiden lige så stor som uden en buffer. Buffere i hver aktivitet gør derfor ikke projektet mere sikkert, men kun unødigt langt. Et projekt er helt grundlæggende usikkert, og buffertid er derfor nødvendigt. Denne buffertid skal I dog ikke lægge ind i hver enkelt aktivitet. Indsæt i stedet én lang buffer som den sidste aktivitet i projektet, lige inden projektets afslutning Note, jf. eksemplet ovenfor.

Anvend milepæle Milepæle er naturlige øjeblikke i projektperioden, hvor I har afsluttet en større række opgaver. Milepælene fungerer som mellemliggende deadlines, der skal overholdes. Hvis I overholder de løbende milepæle, bliver den sidste milepæl, altså projektafslutningen, ikke

så stor en mundfuld. Milepælene bidrager til, at projektet løbende overholder deadlines og derfor bedre holder planen. Indsæt en række milepæle i projektet, og aftal i projektgruppen, hvad I vil have færdig til hver milepæl.

Én person bør være ansvarlig for projektplanen Gør én person til gruppens projektplanlægger. Denne person "ejer" projektplanen, og det er denne persons ansvar at opdatere planen, så den hele tiden afspejler jeres aktuelle situation. Opgaven kan fint gå på skift og deles mellem gruppemedlemmerne, men der bør på ethvert givet tidspunkt kun være én ansvarlig.

Brug planen til den løbende opfølgning Projektplanen skal være på dagsordenen på alle jeres projektgruppemøder. Den ansvarlige person for projektplanen gennemgår på møderne de aktuelle aktiviteter. Personen giver (én aktivitet efter den anden) ordet til den ansvarlige for aktiviteten. Hvis aktiviteter er forsinkede, skal dette opdateres i projektplanen, og hvis en aktivitet skal have en ny ansvarlig person, skal dette opdateres.

Planen som del af projektrapporten På nogle uddannelser skal projektgrupper aflevere en beskrivelse af projektprocessen. Temaer er fx, hvordan I har håndteret konflikter og svære situationer. Et vigtigt tema er også, hvordan I har organiseret arbejdet i projektet. Til dette formål kan I vise projektplanen og beskrive, hvordan planen har udviklet sig hen over semestret, og hvordan I har brugt planen.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Opsummering

I dette kapitel har du lært, at begrebet metode er svaret på spørgsmålet om, hvordan I som projektgruppe gennemfører jeres projekt og derigennem løser projektets problem. I har lært, at videnskabsteori ikke fylder meget i tekniske projektrapporter (og at dette ikke er en fejl eller mangel). Et projekt sikrer en rød tråd i projektet ved 1) at vælge en metode, der faktisk kan lede frem til en løsning, 2) at bruge metoden i analysen, 3) at bruge analysens resultater i designet af løsningen, og 4) at konklusionen, der sammenfatter løsningen, faktisk besvarer problemformuleringen. Projektets metodevalg er både et valg af projektstruktur og en række valg af faglige værktøjer, redskaber og metoder til konkrete opgaver. Et teknisk projekt anvender faglige redskaber, værktøjer og metoder til både at identificere årsager til projektets problem, til at designe og teste løsninger og til at planlægge og gennemføre implementeringen af løsningerne. Kapitlet beskriver også, hvilke argumenter der kan overbevise læser om, at valget er godt, og hvordan I som projektgruppe kan planlægge jeres projekt ved brug af Gantt-diagrammet.

Kapitel 6. Dataindsamling og -analyse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I dette kapitel lærer du: Hvad begrebet data betyder i tekniske projekter Til hvilke formål I indsamler data i et teknisk projekt Hvor I kan lokalisere data Hvad analysen i et teknisk projekt handler om Hvordan I finder årsager til projektets problem og identificerer alle relevante krav til projektets løsning Hvordan I sikrer pålidelige data og analyseresultater Hvordan dataindsamling og -analyse hænger sammen med den løsning, I designer. Dette kapitel beskriver først, hvad begrebet data dækker over i tekniske projekter. Dernæst beskriver det, til hvilke formål et projekt indsamler data, hvor I kan lokalisere data, hvordan I kan analysere data og slutteligt, hvordan I sikrer pålidelige data, valide analyser og dermed et godt grundlag for jeres løsning, konklusioner og anbefalinger til virksomheden.

Data i tekniske projekter projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Selvom begrebet data lyder ganske simpelt og entydigt, forholder det sig langtfra sådan. På teologiuddannelsen er data skrifter fra oldtiden, på psykologiuddannelsen er data klientinterviews, og på økonomistudiet er data makroøkonomiske statistikker. Disse uddannelser er disciplinorienterede uddannelser, hvilket gør, at data typisk er af samme type inden for de enkelte uddannelser. Praksisorienterede uddannelser, heriblandt de tekniske uddannelser, adskiller sig fra disciplinorienterede uddannelser på mange måder. På praksisorienterede uddannelser er data flerfoldige. Det betyder, at mange forskellige typer af data indgår i det samme projekt. Data kan fx være: Uformelle samtaler med fx virksomhedens medarbejdere E-mails fra digitale korrespondancer Tekniske beskrivelser og tegninger Formelle interviews Rapporter fra virksomhedens IT-systemer Information fra virksomhedens hjemmeside Resultater fra laboratorieforsøg Egne observationer Egne eksperimenter, test og forsøg Makroøkonomiske facts fra fx Danmarks Statistik Opslag i materialedatabaser. Listen er lang og indikerer mangfoldigheden i tekniske projekters datatyper. Hvilke data der er relevante for det enkelte projekt, kommer naturligvis an på, hvad projektet handler om.

To eksempler på datatyper i tekniske projekter Design af tandlægebor Et projekt handler om udviklingen af den ydre plastskal på en tandlægeboremaskine. Data består her af 1) en liste med borets indhold af elektronik og hardware, 2) opslag i materialedatabaser om plasttyper og 3) interviews med tandlæger om borets brug. Reduktion af varelager Et andet projekt handler om reducering af arbejdstider på et varelager. Her består data af 1) lister med ordrestørrelser og varenumre, 2) tidsregistreringer af lagerpersonalets arbejde og 3) interviews med lagerpersonalet.

For nogle er det lidt overraskende, at samtaler, interviews og e-mails kan være en del af et projekts data. Inden for nogle fagområder betragtes talmateriale som den "rigtige" form for data, men det er vigtigt at huske på, at talmateriale ofte ikke er nok til at svare grundigt på en problemformulering i et teknisk projekt. Problemformuleringer på tekniske projekter er således oftest løsningsorienterede hvordan-spørgsmål, der ikke kan besvares med et tal, fx 45 % eller 23.000 styk. Et tal er et svar på "hvor mange?" eller "hvor meget?"; spørgsmål, der sjældent udgør en fyldestgørende problemformulering i et teknisk projekt. Hvilke data der er relevante for jeres projekt, afhænger af, hvad I har behov for til at kunne besvare de spørgsmål, der løbende opstår i jeres projekt. Der er dog et par grundregler: Hvor meget-spørgsmål besvares som regel bedst med kvantitative data (altså tal, fx databaserapporter). Interviews og samtaler kan give estimater, men tal giver mere sikre resultater. Hvordan- og hvorfor-spørgsmål besvares som regel med kvalitative data (fx interviews, egne observationer eller uformelle samtaler).

Formålet med dataindsamling i et teknisk projekt projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I den klassiske undersøgelse af et forskningsspørgsmål har man traditionelt én metode og ét datasæt, der indhentes én gang. Tekniske projekter, særligt på praksisorienterede uddannelser, har behov for data adskillige gange og til adskillige formål. Figur 6.1 illustrerer, hvor i projektet disse behov ligger.

Figur 6.1. Databehov i et teknisk projekt

Som det ses, sker dataindsamlingen altså løbende og dækker helt op til fem forskellige behov. Tekniske uddannelser og deres projekter er forskellige. For eksempel er data til test og implementering ikke relevante på nogle uddannelser, idet de løsningsforslag, som projektet har designet, ikke testes og implementeres som en del af projektet. Dette forventes gjort af virksomheden efterfølgende. Den nedenstående liste detaljerer de fem behov for data: Data til identificering af problem. Et projekt begynder som regel med en ide, et behov, et problem eller lignende, der ikke er specificeret nok til, at det kan fungere som problemformulering. At nå frem til problemformuleringen inkluderer en grundig forståelse for situationen og derfor data. Disse data indsamles ofte som uformelle samtaler (fx over telefonen), gennem e-mailkorrespondancer eller gennem semistrukturerede eller helt ustrukturerede interviews. Data til identificering af årsager til problem. Dette er det traditionelle formål for dataindsamling i et projekt. Denne dataindsamling beskrives derfor ofte formelt, og I bruger energi på at forholde jer til de klassiske metodetemaer som sikring af pålidelighed og validitet. I indsamler her typisk data om årsager til problemet i problemformuleringen eller til krav til den løsning, I vil designe. Indsamling og analyse af data til denne fase af projektet beskrives indgående senere i kapitlet. Data til løsningsdesign. Når analysen er afsluttet, skal I designe løsningen. Denne opgave kræver også data, og det er ikke nødvendigvis de samme data, som analysen har indsamlet. Se eksemplet nedenfor, der beskriver, hvordan et projekt først indsamler data til analysen og siden andre data til løsningsdesign.

Data til test af løsning. Når løsningen er designet, er der behov for at teste løsningen. Nogle løsninger kan testes med simuleringssoftware eller (som på ITuddannelser) direkte med udviklingsværktøjet. Andre løsninger kræver en real-life test, som kræver nye data fra en real-life situation. Hvis et projekt fx handler om at implementere en ny kvalitetssikringsprocedure, så kan I teste den nye procedure på en udvalgt produktionsproces over en periode for at se, om politikken giver de resultater, I forventer. Data til valg af implementering. Når I skal planlægge implementeringen af løsningen, er der bl.a. behov for informationer om, hvilke personer der skal lede implementeringen, hvilke aktiviteter implementeringen skal bestå af, og hvor lang tid hver aktivitet i implementeringen vil tage. Disse informationer til implementering er den sidste type data, et projekt har behov for.

Eksempel på dataindsamling til analyse og løsningsdesign Et projekt handler om at reducere størrelsen af et håndholdt måleapparat, der bruges i ambulancer til at tage patienters blodtryk. Projektgruppen vil reducere apparatets størrelse, så der er bedre plads til det i en tæt pakket ambulance.

I analysen vil projektet undersøge, 1) hvor meget manøvreplads der er i ambulancen, 2) hvor i ambulancen apparatet skal fastgøres, når det ikke bruges, og 3) hvor ofte apparatet tabes og falder på gulvet i ambulancen. Efter at have indsamlet data til analysen og klarlagt kravene til apparatet skal projektgruppen designe det nye apparat. Her skal gruppen bl.a. vurdere, hvor meget plads der skal være i apparatet til en udluftningssluse, som skal sikre, at apparatet ikke overophedes, når det bruges. Projektgruppen skal derfor indhente nye data, nemlig om 1) hvilke typer udluftningssluser der findes, og 2) hvor stor deres køleeffekt er på apparatets varmegenererende elementer.

Lokalisering af de relevante data projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Et projekt har behov for data til analyse og design af løsning. Data skal bruges til at finde årsagerne til projektets problem og definere kravene til en løsning. Udgangspunktet for dataindsamlingen til analysen er projektets problemformulering, begreberne fra den faglige litteratur, og evt. teori operationaliseret til projektet. Se et eksempel herunder:

Eksempel på, hvordan I bruger et projekts operationaliserede teori og begreber i analysen Et projekt handler om at designe en bærende trækonstruktion i et tag. Projektgruppen anvender teori og faglig litteratur om trækonstruktioner. Den finder frem til, at der er behov for at beregne bl.a. godstykkelsen af de tværgående træbjælker, der bærer konstruktionen. Litteraturen fortæller, at godstykkelsen afhænger af afstanden mellem de bærende vægge og densiteten i den valgte trætype (fx eg eller bøg). Det betyder, at gruppen skal indhente data om 1) afstanden mellem de bærende vægge og 2) densitet på de trætyper, virksomheden kan indkøbe og anvende. Ud fra problemformulering, begreber og teori udleder I databehov. Når databehovene er identificeret, er spørgsmålet, hvor disse relevante data findes, og hvordan de skal indsamles. Herunder ses en liste med de mest almindelige datalokationer: 1. Hos virksomhedens medarbejdere og ledere. Denne type data indsamles gennem interviews og uformelle samtaler. 2. I virksomheden, men dog uden at nogen enkeltindivider kender til dem. Data af denne type indsamles gennem jeres observationer og tilstedeværelse i virksomheden. 3. I virksomhedens digitale systemer. Oftest indhenter I dog data gennem en medarbejder, men det kan være, at en af jer i projektgruppen har adgang (fx gennem et studiejob). Denne type data fås som lister med rådata, som I selv skal bearbejde for at kunne anvende dem i jeres analyse. 4. I generelle opslagsværker, der kan tilgås digitalt eller i bogformat. Dette gælder fx materialedatabaser. 5. Hos andre organisationer end virksomheden. Det kan være kunder, leverandører (aktuelle såvel som potentielle) og brancheorganisationer. Data af denne type indsamles ofte gennem interviews og internetsøgninger. Nogle data findes og kan indsamles uden videre. Andre data skal I generere selv gennem undersøgelser, test, forsøg og eksperimenter i fx et laboratorie, et værksted eller gennem observationsstudier.

Analyse af data | Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Analyse af data

Som vi tidligere har været inde på, handler tekniske projekter om at designe en løsning på et problem, enten i form af at forbedre noget eksisterende (fx at øge holdbarhed på et produkt eller øge produktivitet for en maskine) eller designe noget nyt fra bunden (fx et nyt produkt, en ny algoritme eller en ny bærende konstruktion). Hvilken af disse to typer problemformulering et projekt har, har betydning for, hvad projektets analyse handler om.

Analysen i projekter, der forbedrer noget eksisterende projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I projekter, hvor formålet er at forbedre noget eksisterende, handler analysen om at identificere årsagerne til projektets problem. Analysen er altså en årsagsanalyse. Inden I påbegynder årsagsanalysen, har I muligvis behov for at vurdere størrelsen på projektets problem. Det er nemlig vigtigt at vide, hvor stort problemet er, så I senere i projektet kan forholde jer til, hvor stor en effekt jeres løsning vil have på problemet (fx at en løsning vil reducere antallet af returneringer af defekte produkter fra 14 % til 4 %).

Måling af størrelsen på projektets problem Et problem har en størrelse, der gerne skal kunne udtrykkes kvantitativt. Hvis et produkts holdbarhed er for lav, er spørgsmålet, hvor meget for lavt (holder produktet 80 % af den planlagte tid eller kun 30 %?). Hvis virksomheden har nemt tilgængelige og overbevisende data, der viser problemets størrelse, bør I vise dem allerede i projektets introduktion. Analysen kan så fokusere på at finde årsager til problemet. Hvis virksomheden ikke har disse data, der viser problemets størrelse, så må I indsamle dem. Virksomheden kan have et sæt kvalitative data, som ikke giver en sikker måling af problemets størrelse, men dog indikerer størrelsen. I disse tilfælde har I tre muligheder: 1. Foretag selv en række prøvemålinger, og ekstrapolér, så vidt det er muligt, til en større population, størrelse eller kontekst. 2. Foretag en række interviews for at høre, om medarbejdere og ledere deler opfattelsen af problemets eksistens og størrelse. Inddrag de relevante personer, gerne fra flere ledelseslag og afdelinger. 3. Se på andre datasæt, som I kan bruge til at måle problemets størrelse (jf. eksemplet nedenfor).

Eksempel på måling af et problems størrelse, når der ingen direkte anvendelige data er Et projekt handler om en produktionslinje hos en producent af vitaminpiller, der består af to trin. Trin 1 separerer et stof ud af en væske, og trin 2 anvender stoffet som råvare til vitaminpille-produktion. Virksomhedens kontaktperson fortæller, at der kommer for lidt stof ud af hver separation (Hun siger: "Jeg tænker, at der minimum bør komme det dobbelte ud. På papiret bør vi trække 40 kg stof ud, hver gang vi kører"). Projektets problem er altså en for lav mængde udtrukket stof per separation. Der forbliver alt for

meget stof tilbage i restvæsken. Virksomheden måler dog hverken på "udtrukket stof per separation" eller "stof tilbage i restvæsken", så der er ingen tal til at udtrykke størrelsen på problemet. Virksomheden har dog følgende data: 1. Tal på, hvor mange gange separationsprocessen kører hver uge 2. Tal på, hvor meget stof der hver uge bruges som råvare i den efterfølgende vitaminpille-produktion 3. En række interviews med operatører, der forklarer, at der som regel er masser af stof tilbage i restvæsken. Med disse tre sæt data (to sæt tal og ét sæt interview) kan projektgruppen give læseren et billede af problemets størrelse. På baggrund af de tre dataset vurderer projektgruppen, at trin 1 trækker mellem 23 og 30 kg stof ud per separation. Målingen af størrelsen er ikke særligt præcis, men viser dog, at problemet er stort, idet virksomheden jo gerne vil have trukket 40 kg ud per separation. Senere i projektet kan gruppen så (fx gennem en test) vise, hvor meget kg-antallet forbedres ved brug af den foreslåede løsning.

Identificering af årsager til projektets problem Årsagsanalysens formål er at finde årsagen (i en- eller flertal) til projektets problem. Hvis et projekt fx handler om at nedbringe antallet af produkter med fejl fra en produktionslinje, vil årsagsanalysen handle om at identificere, hvorfor produktet har fejl. Måske er der kun én årsag, der let kan elimineres, og måske er det en hel række af forskellige årsager, der hver især kræver en løsning. Når årsagerne er fundet, er det jeres opgave at designe løsninger, der enten eliminerer den enkelte årsag eller reducerer dens effekt på problemet. For at finde årsagen må I arbejde jer igennem en række årsag-virknings-stier. Disse stier går fra problem til årsag. Anvend jeres faglige litteratur, så I sikrer jer en så god analyse som mulig.

Eksempel på en årsagsanalyse Virksomheden Knudsen & Company, der producerer måleapparater til hospitaler og laboratorier, oplever, at for mange færdige måleapparater fejler den sidste funktionstest, inden apparaterne pakkes og transporteres til færdigvarelageret. Virksomheden vil gerne nedbringe antallet af apparater, der fejler, fra 23 % til 3 %. Virksomheden har derfor indgået et samarbejde med en gruppe studerende, der har til opgave at løse dette kvalitetsproblem. De studerende laver en problemformulering, der lyder: "Hvordan kan Knudsen & Company nedbringe antallet af apparater, der fejler i produktionens sidste funktionstest, fra 23 % til 3 %?". Herefter begynder de studerende at analysere årsagerne til, at apparaterne fejler. Analysen er illustreret i figur 6.2

Figur 6.2. Årsagsanalyse

Årsagsanalysen tager udgangspunkt i projektets problem (altså fejl i testen). Projektgruppen undersøger først, hvorfor der er fejl i testen, og finder frem til, at apparaterne fejler i enten 1) funktionstestens tryktest eller 2) ved den række testmålinger, som funktionstesten afslutter med. For hver af disse to årsager undersøger projektgruppen igen årsagen ved at spørge, hvorfor hhv. tryktesten og test-/prøvemålingerne fejler. Projektgruppen fortsætter årsagsanalysen med hvorforspørgsmål, indtil de finder årsager, som de kan adressere med en løsning. Disse kaldes de adresserbare årsager. Gennem brillerne i højre side af figuren kan man se fem adresserbare årsager til testfejl: 1) fejl i indkøb, 2) uklare samlingsmanualer, 3) sjusk i kanalsamlingen, 4) forkert anvendt procedure for apparatkalibrering og 5) en defekt spuler i testbakkevasken. På baggrund af denne årsagsanalyse kan projektgruppen begynde at designe løsninger til projektet, teste disse løsningers effekt på projektets problem og planlægge løsningernes implementering. Disse aktiviteter behandles i kapitel 7 og 8 her i bogen. Årsagsanalysen skal vedblive at spørge "hvorfor?", indtil den når adresserbare årsager. En adresserbar årsag er en årsag, til hvilken I kan designe en løsning. Note Man kalder nogle gange denne teknik for 5 x hvorfor (på engelsk Five Why), men som eksemplet viser, er det ikke altid fem gange, man spørger "hvorfor?". Et værktøj, der kan hjælpe med at finde frem til årsager, er fiskebensdiagrammet vist i figur 6.3.

Figur 6.3. Fiskebensdiagram

Her starter man også med projektets problem, der denne gang er vist i højre side af figuren. Herfra bevæger analysen sig mod venstre og spørger om årsagerne til problemet. Årsagerne kan ligge i virksomhedens metoder, maskiner, mennesker, management, materialer eller målinger. Disse seks kategorier kan inspirere til en brainstorm og diskussion af mulige årsager. De mindre pile indikerer årsager til årsagerne. I venstre side under kategorien "Menneske" står et 1-tal. Dette tal står ved en pil, der udgør en årsag til den lidt større pil, som den helt lille pil støder an til. Den lidt større pil (angivet med et 2-tal) udgør en årsag til stregen, der har menneske som overskrift (angivet med et 3-tal). Denne streg udgør en årsag til projektets problem. Fiskebensdiagrammet virker lidt ligesom 5 x hvorfor-metoden, men er en smule mere sofistikeret, idet det deler årsagerne ind i de seks kategorier. En ganske god metode er først at anvende fiskebensdiagrammet som basis for diskussion og brainstorm, og dernæst udvikle et problemtræ som i figur 6.2.

Tips til årsagsanalyse Det er ofte svært at arbejde sig igennem en kæde af hvorfor-spørgsmål. Her må I hente hjælp i jeres faglige litteratur, hos vejleder og andre undervisere, hos virksomhedens medarbejdere, etc. At anvende teori og faglig litteratur til at finde årsager til problemer er et af de klassiske læringsmål i projektkurser, og I bør kommunikere jeres teoribrug så tydeligt som muligt i projektrapporten. En grundregel i arbejdet med årsagsanalyser er, at alle potentielle årsager til et problem bør inkluderes i årsagsanalysen. Potentielle årsager, der kan afvises uden videre, bør I også afvise, men husk at inkludere årsager og afvisninger i jeres rapport, så læser kan følge med i jeres ræsonnementer. Hvis alle årsager ikke er taget med, risikerer I, at eksaminator og censor stiller sig kritisk over for projektet. Projektet forekommer svagere, hvis alle potentielle årsager ikke er nævnt, uagtet om de er relevante eller ej.

I begyndelsen af årsagsanalysen kan I anvende hele kategorier af årsager og derefter beskrive årsagerne inden for kategorierne. Her er det vigtigt, at kategorierne ikke overlapper hinanden. At identificere årsager til problemer er aktuelt i projekter på alle uddannelser, tekniske såvel som ikke-tekniske. På bygningsingeniøruddannelsen kan en analyse handle om at finde årsagen til for høj radioaktiv radonindstråling i en etageejendom, på kemiingeniøruddannelsen kan en analyse handle om at finde årsagen til, hvorfor et sprøjtemiddel mister sin effektivitet kort tid efter fremstilling, og på eksportingeniøruddannelsen kan en analyse handle om at finde årsagen til, at en marketingstrategi for et teknisk produkt ikke virker efter hensigten. I kapitel 4 blev det gennemgået, hvordan I opbygger et generisk problemtræ (se figur 4.3) på baggrund af den faglige litteratur. Afhængigt af om der er forsket og skrevet meget om problemet, er dette træ enten et stort, udbygget træ eller blot en række gisninger om årsagssammenhænge. Hvis I har et problemtræ, bør I gøre følgende under analysearbejdet: undersøge, om årsagerne i jeres problemtræ er aktuelle for det konkrete projekt udbygge træet, så det medtager de årsager, som jeres generiske træ ikke indeholder. Figur 6.4 viser omridsene af et problemtræ. Den blå pil illustrerer en årsag-virknings-sti mellem projektets problem og en årsag. Den røde streg går hen over fire kasser (den første kasse er projektets problem). Mellem hvert sæt af kasser på den blå streg er der en relation mellem to kasser. I skal i analysearbejdet afdække, om disse relationer faktisk er til stede i det konkrete projekt. Hvis en relation mellem problem og en årsag er til stede, beholder I årsagen i træet. Hvis relationen ikke gælder i jeres projekt, fjerner I årsagskassen.

Figur 6.4. Problemtræ

Igennem projektets analysearbejde erstatter I gradvist det generiske problemtræ med det faktisk gældende problemtræ, som I illustrerer og beskriver. Jeres fornemste opgave i analyseafsnittet er således at overbevise læseren om, at de sammenhænge, som I mener, der er mellem kasserne i det faktiske træ, er reelle.

Kvantificering af årsagernes relative virkning på projektets problem (hvilke årsager er store, og hvilke er små) Når analysen har identificeret årsagerne til projektets problem, er det væsentligt at vurdere, hvilke af disse årsager der har den største virkning på projektets problem (er årsagen stor og vigtig eller lille og uvigtig). Figur 6.2 viser fem årsager til fejl i et måleapparats funktionstest: 1) fejl i indkøb, 2) uklare samlingsmanualer, 3) sjusk i kanalsamlingen, 4) forkert anvendt procedure for apparatkalibrering og 5) en defekt spuler i testbakkevasken. Det er dog ikke klart, hvilken af disse årsager der er skyld i flest fejl. Det kan være, at 80 % af fejlene skyldes den defekte spuler i testbakkevasken, og at kun 0,005 % af fejlene skyldes sjusk i kanalsamlingen. Hvilke årsager der er vigtige, har naturligvis stor betydning for jeres løsningsdesign. Analysen bør derfor undersøge årsagernes relative vigtighed. En udbredt teknik hertil er det såkaldte Pareto-diagram. Pareto-diagrammet, der er opkaldt efter en italiensk ingeniør fra det sene 1800-tal, viser, hvordan en række virkninger (fx antal fejl) kan grupperes på en række årsager.

Figur 6.5. Pareto-diagram over årsagernes størrelse

Figur 6.5, der er et Pareto-diagram over den relative vigtighed af de fem nævnte årsager til fejl i et måleapparats funktionstest, viser for det første et typisk mønster i fejlanalyser, nemlig at 80 % af fejlene skyldes 20 % af årsagerne. For det andet viser diagrammet, præcis hvilke årsager der er vigtige at adressere i jeres løsningsdesign, og hvilke årsager der er helt og aldeles uvigtige (fx sjusk i kanalsamlingen). Som det ses, står den defekte spuler og fejlene i pakningsindkøb alene for over 95 % af alle funktionstestens fejl.

Hvorvidt I kan udarbejde et validt Pareto-diagram, beror på de data, I kan indsamle. Pareto-diagrammets bedste datagrundlag er et stort antal fejlobservationer, for hvilke I med sikkerhed kan vurdere årsagen. Det betyder som regel, at I skal have adgang til historiske data. Det er ikke sikkert, at virksomheden har indsamlet disse, og selv hvis de har, så er det ikke sikkert, at data tillader gruppering på de fejlårsager, som I har udledt af jeres årsagsanalyse. Hvis det ikke er muligt at bruge et Pareto-diagram, så må I anvende en mere grovkornet vurdering. Én metode er at dele årsagerne ind i de to grupper (a) "vigtige årsager" og (b) "ikke-vigtige årsager". Denne opdeling kan I klare med færre observationer. En lille række observationer er ikke et godt datagrundlag i sig selv, men kan I kombinere dem med interviews og andre datakilder, så får I samlet et godt datagrundlag. Generelt er det sådan, at jo flere data I indsamler, jo bedre er muligheden for at vurdere de enkelte årsagers betydning. En mellemting mellem en præcis Pareto-analyse og den simple "vigtig vs. ikke-vigtig"gruppering er at opdele årsagerne i fx fire eller fem grupper med stigende vigtighed. Fem grupper giver således en bedre basis for et løsningsdesign end blot to grupper. Når I har identificeret de vigtige årsager til projektets problem, er næste skridt at udvikle løsninger, der eliminerer årsagerne eller reducerer deres effekt på problemet. Løsningsdesign er temaet i kapitel 7.

Analysen i projekter, der designer noget nyt fra bunden projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I projekter, der handler om at designe noget nyt fra bunden, vil analysen ikke handle om at finde årsager, men i stedet om at klarlægge kravene til løsningen (fx en bygherres krav til antal etagemeter, effektkravene til en motor eller ydelseskravene til et elektronisk produkt). Jeres opgave er derfor at forstå følgende: løsningens brugssituationen og de forventninger, som interessenterne har til løsningen (de unikke krav til løsningen) hvilke love og bekendtgørelser, standarder og normer løsningen er underlagt (de generelle krav til løsningstypen). At identificere et fyldestgørende sæt af krav gælder, uagtet om løsningen er en bygning, en maskine, et kemisk stof, et program, et elektrisk anlæg eller et produktionssystem. Det er som regel nødvendigt at involvere virksomhed og vejleder i identifikationen af krav. At involvere virksomheden sikrer ejerskab hos virksomheden og reducerer risikoen for, at eksaminator og censor til eksamen siger om jeres løsning: "Jamen, det kan man ikke, fordi [et oplagt krav, I ikke har taget højde for]". Når I har identificeret, forklaret og specificeret alle krav, så har I en kravspecifikation, og en stor del af grundlaget for løsningsdesignet er på plads. Selvom der er stor forskel på et kemikalie, en bygning, et program og et produktionssystem etc., så findes der dog en række typiske områder med krav til en teknisk løsning, jf. figur 6.6.

Figur 6.6. Typiske områder med krav til en teknisk løsning

Nogle krav stilles af løsningens kommende brugere. Brugerne har således krav til funktionalitet og til, at løsningen skal kunne serviceres og drives for rimelige omkostninger. Andre krav stilles af producenten. I nogle tilfælde skal løsningen fremstilles

i et stort stykantal, og dette stiller krav til, at løsningen designes, så den kan fremstilles effektivt.

De generelle krav til en teknisk løsning For stort set alle løsninger gælder, at de er underlagt generelle krav for løsningstypen. Dette kunne være love, bekendtgørelser, EU-direktiver, regler, normer og tekniske standarder. Disse generelle krav omhandler bl.a. sikkerhed for brugerne, og hvordan løsningen interagerer med omverdenen (fx at løsningen har et stik, der kan sættes i væggen). Eksempler på generelle krav til en løsning

Uddannelse

Sikkerhedskrav til byggeriet af en dæmning

Bygningsingeniøruddannelsen

Tekniske krav til den elektriske tilslutning af en maskine

Maskiningeniøruddannelsen

Standarder og normer for en kvalitetsstyringsprocedure

Produktionsingeniøruddannelsen

Tabel 6.1. Eksempler på generelle krav til en teknisk løsning på forskellige uddannelser De generelle krav er ikke unikke for løsningen, men gælder typen af løsning. I kan identificere de generelle krav i jeres faglige litteratur. Hvis løsningen er en bygning, kan I fx begynde med at udlede krav fra byggereglementer og lokalplaner. Hvis løsningen er en kemisk proces, kan I begynde med at lede efter krav til sikkerhed og bæredygtig bortskaffelse af affald, og hvis løsningen er udstyr til fx sundhedsvæsenet, kan I lede efter krav til rengøring og vedligehold af udstyr til hospitaler, klinikker og laboratorier.

Absolutte krav og "så godt som muligt"-krav Når I har specificeret alle krav til løsningen, er det vigtigt, at I gør jeg klart, hvilke krav der er absolutte krav, som skal opfyldes helt og aldeles, og hvilke krav der blot skal opfyldes så godt som muligt. Et absolut krav til en søjle kunne fx være, at søjlen skal kunne bære 1.200 kg. Kravspecifikationen kunne indeholde endnu et krav, nemlig at materialet skal være så billigt som muligt. Materialets pris er et "så godt som muligt"-krav.

Inden I designer jeres løsning, skal I opdele kravene i de to kategorier. Virksomheden har tit en række absolutte krav, der kommer af den praktiske virkelighed, som projektet skal udføres i. For eksempel at antallet af komponenter, man indkøber fra en koreansk leverandør, skal kunne være i en 40 fods skibscontainer.

Identifikation af krav Det er vigtigt, at I får defineret alle relevante krav. Det bedste udgangspunkt for dette er at øge jeres viden om løsningstypen. I øger jeres vidensniveau effektivt ved løbende at læse teori om løsningstypen. Her er en liste med tips: Lån en stak bøger om projektets tema på universitetets bibliotek Skim jeres egne lærebøger for indhold om løsningstypen Foretag søgninger om løsningstypen på universitetets digitale bibliotek Hold uformelle samtaler med virksomhedens medarbejdere Nedfæld de identificerede krav, efterhånden som I identificerer dem, og tjek dem af med jeres vejleder.

Eksempel på proces for identifikation af krav I kapitel 4 er nævnt et projekt, der handler om at designe en etageadskillelse i en bygning, dvs. loft og gulv mellem to etager i bygningen. I dette projekt begynder projektgruppen med at læse teori om etageadskillelser (løsningstypen). Projektgruppen finder teori, normer og faglige standarder om opbygningen af den bærende konstruktion i en etageadskillelse, om materialevalg, om loftsog gulvtyper og om, hvordan en etageadskillelse integrerer med de vægge, der bærer den. Ud fra den faglige litteratur finder projektgruppen ud af, hvilke data der er relevante at indhente for at kunne definere kravene til den konkrete etageadskillelse. Gruppen indsamler de pågældende data gennem interviews og uformelle samtaler med bygningens arkitekt, konstruktør og rådgiver. Gruppen finder ud af, at materialet i den bærende konstruktion skal være af stål, at gulvet skal være af træ, at lydisoleringen skal bestå af lag af gips og stenuld, og at loftet i underetagen skal have en lyddæmpende effekt. Gruppen studerer bygningens plantegning og udarbejder en liste med de korrekte dimensioner (herunder hvor langt der er mellem de bærende vægge). Til slut læser projektgruppen i byggestandarder, normer og regelsamlinger og finder ud af, hvor stor en vægt etageadskillelser i bygninger af den pågældende type skal kunne bære. Alle disse informationer skrives ned, og ud fra informationerne udleder projektgruppen de samlede krav, der er til etageadskillelsen.

I begyndelsen af jeres analyse kan I ved almindelig brainstorming relativt hurtigt nedskrive en række krav til løsningen. Disse krav kan i begyndelsen være formuleret som områder, hvor I ved, at der vil være krav. Når den første liste er nedfældet, begynder den resterende del af opgaven med udarbejdelsen af kravspecifikationen. Her skal I være opmærksomme på især to ting: 1. I skal sikre jer at have alle krav med 2. I skal specificere alle krav nøjagtigt og (hvis muligt) kvantitativt. Krav skal specificeres i en sådan grad, at de er anvendelige i løsningsdesignet (kravene skal være operationelle). I kan bruge figur 6.6 som en slags ekstra huskeliste til identificeringen af krav. Figuren kan medvirke til, at I husker at inkludere krav, der måske ikke fremgår så tydeligt af litteraturen, men som eksaminator og censor vil forvente er taget med i projektet. Figuren er dog ikke nødvendigvis udtømmende for jeres projekt, så anvend den som inspiration og ikke som en facitliste.

Fra abstrakte til operationelle krav Mange krav er vigtige, men nogle er i en så abstrakt form, at de er svære at anvende i løsningsdesignet. For eksempel: "Bygningen skal have badeværelser med nok plads". Hvad betyder "nok plads"? Her er det en god ide at nedbryde det abstrakte krav i en række mere specifikke krav, der kan kvantificeres. I eksemplet med badeværelserne kunne man fx inkludere tre specifikke krav i kravspecifikationen: "Minimum 10 kvm", "separat bruser og badekar" og "minimum 2 meter mellem vask og dør". Husk at konsultere jeres virksomhed og i eksemplet muligvis også bygherren.

Figur 6.7. Eksempel på kravnedbrydning – fra et abstrakt krav til tre operationelle krav

Mellem krav og løsning Når kravene er specificeret, er næste umiddelbare skridt at påbegynde løsningsdesignet. På nogle uddannelser er der dog et skridt imellem krav og løsning, nemlig at udlede løsningens subsystemer og for hvert af disse subsystemer at identificere de mulige

tekniske løsninger. Et ofte anvendt synonym for subsystemer er funktioner. At identificere mulige tekniske løsninger kan ske gennem brug af morfologiske kort og diagrammer. Figur 6.8 viser et eksempel fra maskiningeniøruddannelsen. Løsningens subsystemer ligger på Y-aksen, og på X-aksen ligger en række teknologikategorier. I felterne i matrixen kan man indskrive de mulige tekniske løsninger, fx hvordan et åbne-lukke-subsystem kan være mekanisk, elektrisk, pneumatisk etc.

Figur 6.8. Eksempel på morfologisk diagram fra maskiningeniøruddannelsen

Sikring af pålidelige data og analyseresultater projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

De data, I anvender, skal være til at stole på, og de skal give rigtige og brugbare svar på de spørgsmål, I stiller. De to mest almindelige kvalitetskriterier for et projekts data er validitet og pålidelighed (kaldes med et fint ord også reliabilitet). De næste to afsnit beskriver, hvordan disse to kvalitetskriterier gør sig gældende i tekniske projekter.

Validitet i tekniske projekter Valide data er data, der faktisk kan bruges til jeres projekt. Det lyder umiddelbart ret ligetil. Hvorfor skulle man dog indsamle andet end brugbare data? At sikre indsamlingen af brugbare data kan dog til tider være uigennemskuelig.

Eksempel på indsamlingen af ikke-valide data Et projekt handler om at undersøge årsagerne til, at en virksomhed får produkter tilbage fra kunderne kun to-tre måneder efter levering. Det kunne måske være 1) at kunderne har ombestemt sig, allerede inden produktet er taget i brug, 2) at kunderne ikke mener, at produktets funktion lever op til forventningerne, eller 3) at produktet har en konstruktionsfejl. Det kunne også være andre årsager. Projektgruppen undersøger returårsagerne ved at sende et spørgeskema ud til alle medarbejdere i virksomheden, der har noget med produktet at gøre, for at spørge dem om de mulige årsager til de hurtige returneringer. Medarbejderne kommer med i alt 20 årsager, hvoraf nogle er nævnt mange gange og andre kun en enkelt gang. Projektgruppen opstiller et Pareto-diagram og begynder prompte at adressere de årsager, der er nævnt mange gange, med hensigtsmæssige løsninger. Gruppens data er pålidelige, idet medarbejderne har svaret meget nøjagtigt på, hvad de tror, årsagerne er. Data er dog ikke valide. Projektgruppen vil nemlig gerne vide, hvad de faktiske årsager til returneringerne er, og ikke, hvad medarbejderne tror Den måde, validitetsproblemer tit opdages, er, når en vejleder (eller eksaminator og censor) udbryder noget a la "Jamen, jeres data siger jo kun noget om X og ikke om Y" (hvor Y er projektets spørgsmål, og X er noget andet). Havde projektgruppen i eksemplet ovenfor holdt fast i medarbejdernes syn på returårsagerne, kunne eksaminator fx sige: "Jamen, det siger jo kun noget om medarbejdernes syn på sagen, ikke om de faktiske returårsager!"

Pålidelighed i tekniske projekter

Pålidelighed (reliabilitet) er intuitivt lidt nemmere at forstå end validitet. Pålidelige data er ganske enkelt data, der er nøjagtige og til at stole på. Nøjagtighed er relevant, når I selv foretager målinger. Eksempel: En produktionsproces er automatiseret med en robot. I vil måle det gennemsnitlige tidsforbrug per produkt i produktionsprocessen. Hvis jeres målinger hele tiden afbrydes af en række tilfældige årsager, så vil jeres gennemsnitstid ikke være nøjagtig. Når I ikke selv foretager målinger, men i stedet får resultatet af en række målinger foretaget af andre personer, fx medarbejdere i virksomheden eller en leverandør, skal I forholde jer kritisk til både nøjagtighed og pålidelighed. I eksemplet med robottidsforbruget kunne man forestille sig, at projektgruppen får det målt og oplyst af robottens leverandør eller af en medarbejder i virksomhedens udviklingsafdeling, der lever af at installere robotter. Leverandøren og medarbejderen i udviklingsafdelingen har en interesse i at få robotten installeret, og disse to personer er derfor forudindtagede (på engelsk biased). Det kan sagtens være, at de leverer nøjagtige data, men fordi de er forudindtagede, kan de (bevidst eller ubevidst) fx have undladt at tage højde for langsom opstart, tid til vedligeholdelse, og at der fra tid til anden sker nedbrud i processen. Deres data vil i sådanne tilfælde ikke være pålidelige.

Vigtigheden af at forholde sig kritisk til data projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Data i et teknisk projekt er meget andet end lister med tal og tekniske tegninger. Data er også mundtlige udsagn og interviews med fx direktører og teamledere. I bør forholde jer kritisk til alle data, uagtet datatype og uagtet datakilde. Vær bl.a. opmærksom på, at en undersøgelse sagtens kan have data, der er 100 % pålidelige og 0 % valide. Det er data, der er til at stole på og helt nøjagtige, men som ikke er brugbare i projektet. Ligeledes er det også muligt at have 0 % pålidelige og 100 % valide data. Det er data, der passer perfekt til jeres projekt, men som hverken er nøjagtigt målt eller kommer fra en pålidelig kilde. Det kan være så grelt, at personen, der er jeres datakilde, mistænkes for at have fabrikeret data, så de passer til den konklusion, personen gerne selv vil have i jeres rapport. I bør grundlæggende forholde jer kritisk til data på to forskellige måder: Vurdér nøjagtighed og pålidelighed af kilder, herunder kilders egeninteresse i projektet Vurdér brugbarheden af kildens data for projektet. De to måder matcher ganske godt begreberne pålidelighed (er data nøjagtige, og er kilden til at stole på) og validitet (kan data i det hele taget bruges i projektet). En kildes generelle pålidelighed handler om, hvorvidt kilden i det hele taget anses for at være pålidelig. For eksempel er Danmarks Statistik en kilde, der generelt anses for at være pålidelig. I indsamling af teori anses de store videnskabelige tidsskrifter for at være pålidelige, fx Nature, The Lancet, Journal of Materials Science etc. I de fleste projekter indsamler I mange data fra kilder i virksomheden, som I arbejder sammen med. I disse tilfælde skal I forholde jer kritisk i dataindsamlingen. Kapitel 11 om projektets interessenter beskriver, hvordan projektet kan være del af en magtkamp i virksomheden. Dette kan lede interviewpersoner (eller bare medarbejdere, som I tilfældigvis taler med) til at afvise jeres løsningsforslag eller give jer nye informationer, der sår tvivl om jeres analyseresultater. Det er vigtigt, at I hele tiden forholder jer til, om en person har en bagvedliggende agenda for at afvise jeres forslag, eller hvorfor personen ikke mener, at jeres analyser er korrekte. Hvis en interviewperson fx siger: "Nej, det forslag duer ikke, fordi … Prøv hellere med dette her, fordi …", så spørg ind til de konkrete årsager, og vær ikke bange for at gå ind i en diskussion. Hold blot en god og professionel tone. Efter interviewet må I så overveje, om en informants nye forslag er så godt, som det lyder, eller om informanten eventuelt har sin egen agenda med forslaget. Prøv at verificere interviewpersonens oplysninger ved (hvis muligt) selv at tjekke efter.

At vurdere brugbarheden af data for projektet er en anden måde at forholde sig kritisk på. Her skal I tænke grundigt over, om data passer til jeres spørgsmål, og om det er muligt at trække konklusioner ud at data, der faktisk besvarer de spørgsmål, I har.

Analysens sammenhæng med projektets design af en løsning projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Løsningen skal baseres på projektets analyse. Hvis projektet har identificeret en række årsager til projektets problem, skal løsningen eliminere årsagerne. Hvis projektet handler om at designe noget nyt fra bunden, skal løsningen overholde de krav, som analysen har identificeret og specificeret. Hvis en analyse er grundig, kan projektets løsning ofte ligge "lige til højrebenet".

Eksempel på et projekt, hvor løsningen ligger "lige til højrebenet" En virksomhed, der producerer hydrauliske produkter, oplever, at hydraulikolie lækker fra de færdige produkter, der er i drift hos virksomhedens kunder. Hydraulikproduktet består af en kontrolenhed, en olietank, en pumpe og en cylinder, der er sat sammen af rør. Inde i enhederne og rørene flyder olie. Mellem enhederne og rørene sidder gummipakninger. Projektgruppen har i analysen identificeret hovedårsagen til problemet: Overfladeruheden på metalemnerne får gummipakningerne mellem enhederne til at smuldre. Der lækker derfor olie de steder, hvor pakningerne er smuldret. Denne analyse har tydeligt specificeret årsagen til problemet, nemlig høj overfladeruhed. Løsningen er derfor – ganske enkelt – at reducere overfladeruheden (fx gennem en pudseproce Kompleksiteten i projekter, hvor løsningen er "lige til højrebenet", ligger ofte i de øvrige krav, der er til løsningen. I ovenstående eksempel om overfladeruhed kan det være, at den nye pudseproces ødelægger overfladebeskyttelsen, så enheden ruster hurtigere. Det kan også være, at en pudseproces er omkostningstung at drive. Hvis en projektgruppe i et projekt inden for fødevarevidenskab har fundet, at årsagen til en fødevares for hurtige fordærvelse er konserveringsmidlets ringe effekt, er "lige til højrebenet"-løsningen et stærkere konserveringsmiddel. Men det ønsker virksomheden måske ikke at bruge. Analysen, der går forud for løsningsdesignet, bør derfor have afklaret alle relevante krav til løsningen, så I ved, hvilke løsninger der er implementerbare, og ikke bruger tid på nogle, der ikke er relevante.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Opsummering

I dette kapitel har du lært, at begrebet data i tekniske projekter kan være mange forskellige ting (fx interview, lister med tal, tekniske tegninger, uformelle samtaler mv.). Du har lært, at et teknisk projekt indsamler data til helt op til fem forskellige formål og ikke kun til projektets analyse. I som projektgruppe kan lokalisere data hos en lang række datakilder både inden og uden for virksomheden. Kapitlet beskriver, hvordan analysen i et teknisk projekt oftest handler om at identificere årsager til projektets problem og krav til løsningen. I finder årsager til projektets problem igennem årsag-virknings-stier og ender ved årsager, som I kan adressere med jeres løsninger. Som del af jeres analysearbejde bør I identificere alle relevante krav til projektets løsning, herunder de unikke krav fra brugere og de generelle krav fra lovgivning, standarder mv. I skal sikre pålideligheden af jeres data ved at forholde jer kritisk til både datakilder og dataenes anvendelighed for projektet. Kapitlet fortæller, hvordan dataindsamling og -analyse hænger tæt sammen med den løsning, I designer.

Kapitel 7. Design af løsning projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I dette kapitel lærer du: Hvad en løsning er i et teknisk projekt Om sammenhængen mellem projektets analyse og løsningsdesign Om de generelle krav til en god løsning Om tre arketyper på løsningsdesign i tekniske projekter Hvordan man træffer et valg mellem flere mulige løsningsforslag Hvordan man vurderer en løsnings effekt på problemet og implementerbarhed Hvordan man måler løsningens økonomi (om den kan betale sig) Hvordan man kan kvantificere løsningens effekt på problemet og økonomi. Dette kapitel handler om et teknisk projekts kerne, nemlig designet af løsningen på det problem, der står beskrevet i problemformuleringen. Det kan lyde lidt mærkeligt, at et projekt handler om at "designe en løsning". Ordet design kan lede tankerne hen på tøjdesign eller møbeldesign, og ordet løsning kan lyde som noget, et softwarefirma sælger. Men uanset hvilket fagligt område en uddannelse dækker, "designer" tekniske projekter "løsninger". Hvis et projekt handler om at tegne et hus, udvikle en algoritme eller beskrive en kvalitetsprocedure, så udgør hhv. de færdige hustegninger, den færdige algoritme og den færdige kvalitetsprocedure projektets løsning. At tegne huset, udvikle algoritmen og beskrive kvalitetsproceduren er at designe løsningen. Dette kapitel fokuserer særligt på, hvordan I som projektgruppe sikrer en rød tråd mellem løsningsdesign og de aktiviteter i et projekt, der kommer før og efter løsningsdesignet. Først beskriver kapitlet, hvad en løsning principielt er, og hvilke generelle krav løsningen skal opfylde. Herefter beskrives tre generiske typer af løsninger i tekniske projekter samt situationer, hvor I skal vælge mellem alternative løsninger eller prioritere mellem mulige elementer til en løsning. Dernæst beskriver kapitlet, hvordan løsningen specificeres og vurderes økonomisk. Slutteligt beskriver kapitlet, hvordan løsningsdesign hænger sammen med projektets analyse, og hvordan løsningen sammenfattes i projektets konklusion og anbefalinger til virksomheden.

Hvad er en løsning i et teknisk projekt? projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

At designe en løsning betyder at tage en række beslutninger, der hænger sammen i et beslutningshierarki. Hierarki betyder, at nogle beslutninger er store og andre små. De store beslutninger er overordnede, ikke-detaljerede og bliver taget tidligt i designprocessen. De små beslutninger, der tages senere i designprocessen, er mere detaljerede, og de er underordnet de store beslutninger. Figur 7.1 illustrerer et sådant beslutningshierarki.

Figur 7.1. Beslutningshierarki

En overordnet beslutning indsnævrer beslutningsrummet for mindre beslutninger. For eksempel skal arkitekten af et hus først tage stilling til husets ydre dimensioner. Disse ydre dimensioner sætter grænser for beslutninger om planløsning (fx antal værelser). Når planløsningen er besluttet, følger beslutninger om indretning af de enkelte værelser, køkken, badeværelser osv. Til slut i løsningsdesignet er beslutninger om fx, hvor armaturer skal indbygges i væggen, og hvor køleskab og fryser skal sættes i stik. Løsninger i tekniske projekter er altid rent tekniske (fx en ny vindmøllekomponent) eller en kombination af tekniske og sociale (fx en ændret produktionsprocedure, som medarbejderne følger). Uddannelse Bygningsingeniør

Eksempler på løsninger Et spildevandssystem, der bedre kan håndtere stormfloder i en by En tagkonstruktion, der kan åbne og lukke en række glaspartier, så solens varme kan udnyttes bedre En bro, der kan åbne og lukke baner, så kapaciteten kan tilpasses biltrafikken

Maskiningeniør

En maskine, der en nemmere at vedligeholde Et ventilationsanlæg, der udnytter jordvarme til en større bygning En robotarm, der kan løfte tungere genstande i en pakkeproces

Produktionsingeniør

En procedure for hurtigere ændringer af produktionsprocesser i den farmaceutiske industri Et logistiksystem, der lever bedre op til kundekrav En vedligeholdelsesproces, der giver bedre udnyttelse af en maskine

Kemiingeniør

En opskrift på et hjælpestof til en ny type vaskepulver En kemisk produktionsproces, der blander to væsker hurtigere En kvalitetssikringsprocedure, der tillader hurtigere frigivelser af medicinprodukter

Softwareingeniør

Et program til biler, der indhenter realtidsdata fra offentligt tilgængelige databaser om vejtrafik En app, der hjælper brugere til at komme hurtigst muligt gennem en by (fx i myldretid) En app, der indsamler data fra brugerne for at gøre brugeroplevelsen mere individuel

Elektronikingeniør

Et IHC-anlæg, der leverer information til hurtigere fejlkildeidentificering En converter af vindmøllestrøm, der passer ind i en vindmølles nacelle (hus) En transformerstation med færre fejl

Tabel 7.1. Eksempler på løsninger for forskellige uddannelser Fælles for alle løsningerne i tabellen er, at de løser problemet i problemformuleringen. Den sidste løsning i tabel 7.1 beskrives som: "en transformerstation med færre fejl". Dette er en løsning til en problemformulering om reduktion af fejl på en transformerstation. Projektgruppen foretager en analyse af fejlenes årsag(er) og designer derefter en forbedret transformerstation, der fungerer med færre fejl. Denne redesignede transformerstation er derfor projektets løsning.

Projektets analyse er udgangspunktet for løsningsdesign Projekter, der handler om at forbedre noget eksisterende, har inden løsningsdesign foretaget en analyse af årsagerne til projektets problem. I denne type projekter er det jeres opgave at designe løsninger, der enten eliminerer disse årsager eller reducerer deres effekt på projektets problem. I projekter, der designer noget nyt fra bunden, har analysen identificeret alle relevante krav til løsningen, og det er derefter jeres opgave at designe en løsning, der lever op til det totale sæt af krav. I designet af løsningen skal I udnytte den samlede ekspertise og kreativitet, I har til rådighed. De primære kilder til inspiration i løsningsdesignet er: Faglig litteratur fra lærebøger fra uddannelsens pensum Faglige vejledninger, normer, regler, standarder og handleanvisninger Søgninger i akademiske artikeldatabaser Virksomhedens medarbejdere Jeres egne kreative evner til at finde på løsninger Ideer fra jeres vejleder Ideer fra uddannelsens øvrige underviserkorps Inspiration fra andre virksomheder (både i og uden for den industri, virksomheden tilhører). Første skridt er som regel, at I selv brainstormer ideer til løsning og ideer til inspirationskilder. I kan få mange ideer gennem helt basale brainstorms i gruppen. Dette sæt af ideer er et godt udgangspunkt for efterfølgende dialog med virksomhed, vejleder og søgninger efter relevant faglig litteratur.

Generelle krav til en god løsning projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Løsningsdesign er den del af et projekt, der adskiller de tekniske uddannelser mest fra hinanden. Der er dog en række fællestræk, der gælder løsninger på stort set alle tekniske uddannelser. Løsninger skal: Bygge på resultaterne af projektets analyse Opfylde de krav, virksomheden har Være både teknisk, praktisk og økonomisk implementerbar Opfylde studiets krav til en god løsning Adressere problemet i problemformuleringen. Ud over disse krav må løsningen gerne være smuk, spændende og måske lidt overraskende, men det er dog blot "nice to have".

Tre arketyper af løsninger på tekniske projekter projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Der findes tre arketyper af løsninger på tekniske projekter: enkeltløsningen, "enten-eller"løsningen og den sammensatte løsning.

Figur 7.2. Tre arketyper af løsninger i tekniske projekter

De enkelte uddannelser har forskellige traditioner mht. valg af løsning. Enkeltløsninger er almindelige på softwareingeniøruddannelsen, "enten-eller"-løsninger på bygningsingeniøruddannelsen og sammensatte løsninger på produktionsingeniøruddannelsen. I det følgende vil vi se nærmere på de tre arketyper.

Enkeltløsninger Enkeltløsninger er som sagt almindelige på bl.a. softwareingeniøruddannelsen. Her handler det ikke om at designe fx tre færdige apps, der med varierende grad lever op til en kravspecifikation, men én app, der møder alle krav. Softwareudvikling er således en proces, der løbende inddrager virksomhed og måske også kommende brugere for på den måde at matche både de nedskrevne og de usagte krav, som brugerne har til app'en. På den måde sikrer softwareudviklere, at denne ene løsning, som projektet udvikler, matcher alle parters krav og forventninger.

"Enten-eller"-løsninger "Enten-eller"-løsninger er almindelige på bygningsingeniøruddannelsen. Her udvikler en projektgruppe fx tre alternative broer, der opfylder bygherrens behov på hver deres måde. Én brotype er fx billig, en anden brotype kan håndtere mere biltrafik, og en tredje har plads til både bil- og jernbanetrafik. Det er derefter op til projektgruppen i samarbejde

med virksomheden og måske bygherre at vælge én af de tre løsninger. Valget af en endelig løsning blandt en række mulige løsninger beror på, hvor godt den enkelte løsning opfylder de krav til løsningen, som projektets analyse tidligere har defineret. Det kan være svært at vurdere, hvilken løsning der bedst overholder alle krav, idet listen med krav kan være lang og kompleks. En simpel, men effektiv måde er den vægtede faktormetode, der bryder den overordnede, komplekse vurdering af en løsning ned i en række mindre komplekse vurderinger. Denne række mindre komplekse vurderinger evaluerer en løsnings performance på alle enkeltkrav. Metoden består af følgende fire skridt: 1. List alle krav til løsningen i et Excel-ark med fire kolonner 2. Vægt den relative betydning af de enkelte krav i anden kolonne, så vægtningen tilsammen bliver 100 % 3. Indsæt de enkelte løsninger i deres egne kolonner, og giv dem en score fra 1-10 for, hvor godt løsningen performer på hvert krav 4. Gang vægtning med scoren, og se resultatet.

Eksempel på brug af den vægtede faktormetode: Bro, tunnel eller en kombination? En projektgruppe på bygningsingeniøruddannelsen arbejder med en trafikal forbindelse mellem to øer. Den trafikale forbindelse skal håndtere både bil- og togtrafik. Projektgruppen har designet tre alternative løsninger: 1. En tunnel til både bil- og togtrafik 2. En hængebro til både bil- og togtrafik 3. En kombination af skråtagsbro til biltrafik og en tunnel til togtrafik. Projektgruppen vil nu vurdere, hvilken af de tre løsninger der opfylder de krav til broen, som projektgruppen har identificeret i projektets analyse. Krav

Vægt

Løsningernes score

Vægtet score

Tunnel

Hængebro

Kombi.

Tunnel Hængebro

Kombi.

Nej

Ja

Ja

-

-

-

Budget på max kr. 12 mia.*

Abs.

Kapacitet på 2.000 biler i timen

34

10

8

340

272

Kapacitet på 20 tog i timen

23

7

10

161

230

Lavt energiforbrug under drift

12

6

4

72

48

Bygget af lokale håndværkere

22

8

5

176

110

Arkitektonisk flot

9

10

8

90

72

Total

100

-

839

732

* Budgettet er et absolut krav, der skal overholdes. Kravene fra projektets analyse er listet i første kolonne, mens kravenes relative vigtighed i procent (vægt) er listet i anden kolonne. Læg mærke til, at første krav er et absolut krav. Det vil sige, at hvis kravet ikke kan opfyldes, så udgår løsningen. Dette er tilfældet med tunnelen, der ikke kan bygges for 12 mia. kr. I tredje kolonne har projektgruppen vurderet de enkelte løsningers performance på hvert af kravene på en skala fra 1 til 10, og i sidste kolonne er vægtningen blevet ganget med scoren. Resultatet i bunden viser, at hængebroen performer bedst samlet set. At anvende den vægtede faktormetode betyder, at alle krav til løsningen vægtes indbyrdes. I ovenstående eksempel er vægtningen foretaget uden yderligere forklaring. Som studerende bør I dog argumentere for, hvorfor I vægter kravene, som I gør. Det er ofte svært, fordi krav til en løsning kan være meget forskellige. Det kan føles som at sammenligne æbler og pærer. Den samlede liste med krav står ofte i en kravspecifikation. En kravspecifikation er ofte lang. At inddrage alle kravene i en vurdering af flere løsninger kan være en stor og unødigt kompleks opgave. Det kan derfor være en ide at sammenfatte grupper af krav i en mindre række succeskriterier, som I vurderer løsninger i forhold til. Et sæt af 4-6 succeskriterier er passende (fx tre performancemål, et økonomimål og et mål om miljø/bæredygtighed).

Den sammensatte løsning Den sidste arketype er den sammensatte løsning. Et projekt kan fx handle om at øge kapaciteten på en produktionsproces. Projektgruppen identificerer og designer en række løsningselementer, der hver især øger processens kapacitet. Derefter er det jeres opgave i samarbejde med virksomheden at beslutte, hvilke løsningselementer I vil prioritere. De prioriterede løsningselementer indgår i projektets samlede løsning.

Eksempel på en sammensat løsning

Tabel 7.1 nævner nederst i tabellen en transformerstation med for mange fejl. Projektgruppen vil reducere antallet af fejl. Analysen fortæller, at anlægget ikke kan håndtere den nødvendige spænding i peak-forbrugstimerne. Dette er årsagen til fejlene. Projektgruppen skal derfor designe en løsning, der eliminerer denne årsag eller reducerer årsagens effekt på problemet. Projektgruppen udvikler to løsninger: 1. at redesigne transformerstationen, så den kan håndtere peak-forbruget 2. at indføre en elforbrugspolitik, der sikrer et mere jævnt forbrugsmønster med lavere forbrug i peak-forbrugstimerne. Løsningen kan dog også bestå af både en stærkere transformerstation og en politik for jævnere forbrugsmønster. Altså en løsning sammensat af to løsningselementer. På mange tekniske uddannelser er det ganske normalt, at projekters løsninger består af flere løsningselementer. Et eksempel fra maskiningeniørretningen er et projekt, der handler om at reducere vedligeholdelsestiden på en maskinkomponent på en skibsmotor. Løsningen i dette projekt består af både en redesignet komponent, der er nemmere at vedligeholde, og en mere effektiv vedligeholdelsesprocedure. På eksportingeniøruddannelsen, hvor et projekt fx kan handle om at øge salget af vindmøller i Kina, kunne en løsning indeholde både et nyt servicekoncept, som kinesiske kunder synes bedre om, og en ny type salgsfremstød, der bedre imødekommer de kulturelle normer, der hersker hos kinesiske indkøbere. De enkelte løsningselementer i en sammensat løsning designes på samme måde som hele løsninger. I sammensatte løsninger er det ofte sådan, at løsningselementerne først designes på et groft niveau, der gør det muligt at prioritere mellem løsningselementerne (vælge til og fra). På den måde ender man ikke med at bruge for meget tid på at specificere løsningselementer, der siden fravælges.

Prioritering mellem løsningselementer i en sammensat løsning Prioriteringsopgaven tager udgangspunkt i følgende to kriterier: den effekt, de enkelte løsningselementer har på projektets problem løsningselementernes implementerbarhed i virksomheden. Rent praktisk kan man anvende en prioriteringsmatrix som illustreret i figur 7.3. Matrixens X-akse viser løsningselementets effekt på problemet, mens Y-aksen viser løsningselementets implementerbarhed. Hvordan I konkret kan vurdere effekt og implementerbarhed, vender vi tilbage til senere i kapitlet.

Figur 7.3. Prioriteringsmatrix

Løsningselementer, der befinder sig i den grønne kasse, bør inkluderes i den samlede hele løsning uden videre. Elementer i de gule kasser kan inkluderes, men inkludering bør overvejes nøjere. Elementer i den røde kasse er de mindst attraktive at inkludere. Der kan være afhængigheder mellem løsningselementer, som man skal tage hensyn til. For eksempel kan det være, at et element i den grønne kasse ikke kan implementeres, uden at et element i den røde kasse også implementeres. I sådanne tilfælde kan I vurdere de to elementer som ét samlet løsningselement, som I så kan placere i matrixen. Når I har valgt løsningselementerne til jeres sammensatte løsning, er næste opgave at specificere jeres valgte løsningselementer. På bygnings- og maskiningeniørretningen kunne dette betyde udarbejdelse af detaljerede tegninger, og på produktionsingeniøruddannelsen kunne det betyde tegning af produktionslayout og flowcharts. Den konkrete dokumentation af løsning beror på jeres uddannelses faglige metoder, herunder metoder til at beskrive og dokumentere løsninger.

Vurdering af løsningers effekt, implementerbarhed og økonomi projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Et projekt bør indeholde en vurdering af løsningens effekt på problemet. Derudover ønsker vejledere ofte, at I forholder jer til løsningens implementerbarhed og økonomi. En løsning skal derfor evalueres på tre parametre: Effekt på projektets problem (fra problemformuleringen) Implementerbarhed i virksomheden Økonomien (om det kan betale sig at implementere løsningen). Oftere og oftere forventer vejledere også en vurdering af løsningens bæredygtighed og risiko. Hvis det gælder for jer, så inddrag bæredygtighed og/eller risiko som parameter.

Vurdering af løsningens effekt på projektets problem projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Ordet effekt adskiller sig for projekter, der designer noget nyt fra bunden, og projekter, der forbedrer noget eksisterende. For projekter, der designer noget nyt fra bunden (fx en ny bygning eller et nyt produkt), er effekt lig med 'graden af, hvor godt løsningen matcher de krav, som virksomheden og brugere har til løsningen'. For projekter, der forbedrer noget eksisterende (fx et produkts holdbarhed), er løsningens effekt lig med 'forbedringens størrelse'. Dette kunne fx være, at et produkts holdbarhed er øget med 40 %. Afsnittet her koncentrerer sig om projekter, der forbedrer noget eksisterende. Til vurdering af løsninger for projekter, der designer noget nyt fra bunden, kan I se på afsnittet om "enten-eller"løsningen (fx den vægtede faktormetode). Løsningen skal have en effekt på projektets problem. Hvis et projekt fx handler om at nedbringe antal fejl i en produktionsproces, er løsningens effekt 'reduktionen i antal fejl'. Effekt udtrykkes kvantitativt, ofte ved en procentsats, fx 24 %. Afhængigt af den konkrete løsning og de faglige metoder, I har til rådighed, kan en vurdering af effekt være en måling, en beregning eller blot et skøn. Udfordringen med effektvurderinger er præcision. I nogle brancher, fx byggebranchen, findes konkrete faglige metoder til beregning eller måling af løsningers effekt. Disse metoder anses som regel som præcise og accepterede af alle parter. Hvis I kan anvende disse metoder, er opgaven forholdsvis nem. Anderledes forholder det sig, hvis I arbejder med et problem, hvor de faglige metoder enten ikke kan bruges eller slet ikke findes. I så fald er effektvurderinger svære, og resultaterne er ofte usikre. Et konkret råd er her at angive resultaterne som sikre intervaller frem for upræcise enkeltal. Skriv fx, at reduktionen af fejl er "mellem 5 og 10 %" frem for "6,7 %".

To eksempler på vurdering af løsningselementers effekt Et projekt handler om at nedbringe varmeudstrålingen fra facaderne i en bestemt version af et typehus. Projektgruppen har udviklet de tre nedenstående løsningselementer og skal vurdere effekten af hvert løsningselement på varmeudstrålingen: at øge facadevæggenes tykkelse med 2 cm isolering at skifte fra to til tre lag ruder i vinduerne at beholde den nuværende vinduestype, men reducere vinduesarealet med 10 %. I byggebranchen findes konkrete normer, der kan bruges til at foretage præcise beregninger, der dokumenterer reduktionen af varmeudstråling. Projektgruppen kan på basis heraf beregne tre tal, der udtrykker effekten af hvert af de tre løsningselementer på varmeudstrålingen.

Et andet projekt handler om at øge brugen af offentlige bycykler. Projektgruppen vil øge brugen af bycykler ved at øge brugervenligheden på cyklernes betjeningsapp. Kunderne anvender appen til at låse cyklen op, betale for brugen af cyklen og som GPS på cykelturen. Projektgruppen interviewer potentielle brugere, herunder turister fra 5-6 forskellige lande, for at finde frem til, hvordan brugervenligheden kan øges. Interviewene giver projektgruppen otte forskellige ideer til ændring af appen. Gruppen skal nu beslutte, hvilke ideer de vil inkludere i projektets samlede løsning. Spørgsmålet er, hvor meget de otte ideer vil øge brugen af bycyklerne. Her findes ikke konkrete metoder, og projektgruppen er derfor nødt til selv at vurdere effekten. De starter med Ide 1, der handler om at gøre appens "Kom i gang"-funktion nemmere og hurtigere. Gruppen beslutter i en stikprøve at måle, hvor mange personer der går i gang med funktionen, men opgiver undervejs. Stikprøven viser, at 25 % opgiver at komme igennem "Kom i gang"-funktionen. Projektgruppen vurderer, at halvdelen af disse 25 % (altså 12,5 %) ikke ville opgive, hvis Ide 1 implementeres. Effekten af Ide 1 på problemet er altså 12,5 %. I rapporten beskriver projektgruppen effekten som "mellem 8 og 15 %".

Vurdering af løsningers implementerbarhed projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Modsat effekten af en løsning er implementerbarhed en mere abstrakt størrelse. Hvad betyder implementerbarhed egentligt? Helt basalt udtrykker implementerbarhed, hvor nemt eller svært det vil være for virksomheden at bringe den specificerede løsning i drift. At kvantificere denne størrelse er ikke så let. Implementerbarhed kan dog gøres mere håndgribelig ved at nedbryde begrebet i en række faktorer, der er relevante for en given løsning. For eksempel: om kapitalkravet for implementering er stort om den nødvendige tekniske ekspertise for at gennemføre implementeringen er til stede i virksomheden om den organisatoriske kompleksitet, som implementeringen skal overkomme, er stor (herunder den politiske modstand i organisationen mod løsningens implementering). Vurdér implementerbarheden på hver faktor sammen med virksomheden. Når I har foretaget vurderinger på hver enkelt faktor, kan I samle alle enkeltfaktorvurderinger til én samlet vurdering af løsningselementets implementerbarhed. Se det følgende eksempel.

Eksempel på vurdering af løsningers implementerbarhed En virksomhed producerer plastsprøjter til hospitaler og klinikker. En stor andel af de producerede sprøjter kasseres pga. fejl. En gruppe studerende vil reducere antal fejl i produktionsprocessen og udvikle tre løsningselementer. De vil nu vurdere implementerbarheden af hver af de tre løsningselementer. Løsningselementerne kaldes her for A, B og C. Implementerbarheden vurderes på tre faktorer: 1) den nødvendige kapital, implementeringen kræver, 2) om virksomheden har den nødvendige tekniske ekspertise til rådighed, og 3) om den forventede organisatoriske modstand mod implementering vil være stor. De tre elementers implementerbarhed vurderes hver især på de tre faktorer på en skala fra 1-10 (hvor 10 betyder nem at implementere, og 1 betyder svær at implementere). I samarbejde med virksomheden når projektgruppen frem til vurderingerne i tabellen nedenfor. For eksempel får løsningselement A et 8-tal for faktoren "Teknisk ekspertise til rådighed". Tæt på 10 er godt, og 8-tallet udtrykker, at virksomheden har næsten al nødvendig ekspertise til rådighed for at implementere løsningselement A. De tre samlede tal i bunden af tabellen udtrykker hvert løsningselements samlede implementerbarhed. Tabellen viser, at løsningselement C er nemmere at implementere end A og

Anvender man en prioriteringsmatrix, kan man indsætte de tre tal på matrixens implementerbarhedsakse. Matrixen viser, hvordan prioriteringen kommer an på både implementerbarhed og elementets effekt på projektets problem.

Vurdering af en løsnings økonomi projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Det gælder for de fleste tekniske uddannelser (særligt på de senere semestre) at løsningsspecificeringen bør indeholde en detaljeret analyse af løsningens økonomi. Økonomiske vurderinger af løsninger er en af de professionelle kompetencer, som veluddannede teknikere (særligt ingeniører) bør have. Derfor gennemgår det følgende afsnit i detaljer, hvordan I som projektgruppe kan udarbejde en sådan analyse. En løsnings økonomi afhænger af løsningens effekt og af de omkostninger, der er forbundet med at implementere og drive løsningen. Figur 7.4 viser, at løsningens effekt på problemet har en økonomisk værdi. I beregninger af en løsnings økonomi er det effektens økonomiske værdi, der udgør 'indtægterne'.

Figur 7.4. Løsning, effekt og økonomisk værdi

Tekniske løsninger kan være meget forskellige. Tabel 7.2 giver en række eksempler på løsninger og deres indtægter. Tabel 7.2 viser kun løsningernes indtægter. At designe og implementere en løsning koster noget. Denne sum penge er dels den investering, som virksomheden skal foretage for at implementere løsningen, og dels de løbende driftsomkostninger (altså de penge, det koster at drive og vedligeholde løsningen, når den er implementeret).Note Løsning

Løsningens indtægt

Øget holdbarhed af et produkt

Den øgede holdbarhed gør produktet mere værd for produktets kundegruppe. Virksomheden kan derfor tage en højere pris for produktet. Fordi prisstigningen kommer som følge af løsningen, er den løsningens indtægt. Hvis virksomheden ikke sætter prisen op, kan virksomheden i stedet sælge flere produkter (alt andet lige). Nettoprofitten fra disse ekstra solgte produkter er så løsningens indtægt.

En ny app

Appen giver virksomheden en omsætning. Denne omsætning er løsningens indtægt. Bemærk, at omkostningerne til at sælge og supporte appen ikke er trukket fra indtægten. Det gøres i den samlede beregning, se nærmere senere i afsnittet.

Reduceret lager

Et reduceret lager giver en reduktion i lageromkostningerne. Virksomheden har altså færre omkostninger til svind, ukurans, løn til lagermedarbejdere og afskrivninger på gaffeltrucks, robotter og anden teknologi. Reduktionen i lageromkostninger er løsningens indtægt.

En ny bro

For et byggefirma bliver broen betalt af en bygherre (fx en kommune eller staten). Denne sum penge er løsningens indtægt. Bemærk, at alle omkostningerne til brobyggeriet ikke er trukket fra indtægten.

Øget trafik over en brugerbetalt bro

En løsning, der ændrer antal vejbaner afhængigt af, på hvilken side af broen trafikken er tæt, øger broens kapacitet, hvilket betyder mindre kø. Mindre kø betyder større tilbøjelighed blandt kunder til at vælge broen som overfart og derfor højere omsætning. Den øgede omsætning er løsningens indtægt.

Hurtigere leveringstid af produkter

At levere produkter hurtigere betyder, at kunder, der værdsætter hurtige leverancer, er mere tilbøjelige til at købe virksomhedens produkter (og ikke konkurrentens). Nettoprofitten fra disse ekstra solgte produkter er løsningens indtægt.

Lavere væskeviskositet i kemisk procesindustri

Lavere viskositet af en væske betyder, at væsken flyder hurtigere. Hvis dette kan ske uden tab af de øvrige væskeegenskaber, der er relevante for produktionen, giver dette en hurtigere produktion og dermed højere kapacitetsudnyttelse og lavere enhedsomkostninger. Reduktionen i enhedsomkostninger er løsningens indtægt.

Tabel 7.2. Eksempler på løsninger og deres indtægter

Investeringen

Investeringen i en løsning består dels af en række håndgribelige ting, der skal indkøbes. Dette kan være maskiner, programmer, bygninger, etc. Husk dog at tænke hele vejen rundt, når I beregner investeringens størrelse. Ud over investeringer i maskiner, programmer eller bygninger, er der også en lang række mindre poster, der tit bliver glemt. Her er en række eksempler: Medarbejdertid til udvikling og deltagelse i implementering Projektledelse af implementering Tid til konsulenter eller egen IT-afdeling, hvis software skal udvikles Omkostninger til træning af medarbejdere Omkostninger til udarbejdelse af udbudsmateriale Tid til løbende kontrol af en løsnings drift Tid til diverse informations- og kommunikationsaktiviteter Omkostninger til opdatering af leverandørkontrakter Omkostninger til rejser (hotel, mad, fly, billeje, etc.) Tabt fortjeneste, fordi en proces ikke kører, mens løsningen implementeres Tid i (de tit propfulde) kalendere hos ledere og direktører. Beregningen af en løsnings økonomi skal inkludere både indtægter, investering og de løbende driftsomkostninger i løsningens levetid. Figur 7.5 illustrerer en løsnings investering, indtægter og driftsomkostninger.

Figur 7.5. En løsnings investering, indtægter og driftsomkostninger

Figurens vandrette linje viser en årrække fra år 0 til år n. Investeringen foretages i år 0, og hvert af de følgende år giver løsningen en indtægt og har en driftsomkostning. Se tre konkrete eksempler på beregning af en løsnings økonomi senere i kapitlet.

Metoder til beregning af en løsnings økonomi projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

De følgende tre metoder er de mest anvendte og kendte metoder til beregning af en løsnings økonomi: Tilbagebetalingstidsmetoden Break-even-metoden Nutidsværdimetoden. Tilbagebetalingstidsmetoden fortæller, hvor lang tid der går, før investeringen er betalt tilbage. Break-even-metoden fortæller, hvor mange styk af løsningen, der skal være solgt, før investeringen er betalt tilbage, og nutidsværdimetoden inkluderer alle nutidige og fremtidige indtægter og udgifter i én samlet beregning, der tager højde for, at 'penge i dag' er mere værd end 'penge i fremtiden'. Hvilken af disse metoder, det er mest hensigtsmæssigt for jer at bruge, handler ofte om, 1) hvilken metode virksomhedens medarbejdere og ledere bedst forstår, 2) hvilke tal I har til rådighed, og 3) om løsningens indtægt stiger som funktion af tid eller som funktion af antal solgte styk. Tilbagebetalingstidsmetoden og break-even-metoden er temmelig simple metoder. Nutidsværdimetoden er mere kompleks, men også mest retvisende. Metoden tager nemlig højde for den risiko, virksomheden tager ved at investere i løsningen. De følgende afsnit beskriver metoderne.

Tilbagebetalingstidsmetoden Tilbagebetalingstiden er den tid, det tager, for at investeringen er tjent hjem. Metoden ser matematisk således ud:

Metoden er god at anvende, hvis projektets løsning tjener penge som funktion af tid. For eksempel en løsning, der sparer en virksomhed en bestemt mængde omkostninger per år. Tilbagebetalingstiden beregnes på følgende måde: 1. Læg alle omkostninger til implementeringen af løsningen sammen. Denne sum er investeringen i løsningen. Kunsten er her at huske alle udgiftstyper og foretage rimelige estimater af udgifternes størrelse. 2. Estimér løsningens årlige indtægter (fx den besparelse, løsningen giver virksomheden). 3. Estimér løsningens årlige driftsomkostninger. 4. Træk driftsomkostningerne fra indtægterne. Denne mellemregning udgør løsningens årlige driftsoverskud.

5. Dividér investeringen med løsningens årlige driftsoverskud. 6. Resultatet er antal år, indtil løsningen er tilbagebetalt.

Eksempel på, hvordan tilbagebetalingstidsmetoden anvendes Et projekt handler om at reducere en virksomheds produktionsomkostninger ved at implementere en maskine, der kan producere emnerne til en lavere stykomkostning og er billigere at vedligeholde. Projektgruppen har indhentet følgende oplysninger: 1. Den nuværende maskine producerer emner til en stykomkostning på 340 kr. 2. Den nydesignede maskine producerer emner til en stykomkostning på 290 kr., altså 50 kr. lavere 3. Virksomhedens forecast for antal styk, der sælges per år, er 20.000 4. Den nye maskine koster 2.400.000 kr. (indkøb, installation og indkøring) 5. Den nuværende maskine koster 280.000 kr. om året i vedligeholdelsesomkostninger og den nye maskine 80.000 kr., altså 200.000 kr. mindre per år. Investeringen i maskinen er 2.400.000 kr. De årlige indtægter fra maskinen består dels af sparede stykomkostninger og sparede vedligeholdsomkostninger. Løsningens årlige driftsoverskud er indtægter minus udgifter, dvs. (50 kr. per stk. * 20.000 stk.) + 200.000 kr. = 1.200.000 kr. Regnestykket lyder altså: 2.400.000 kr. / 1.200.000 kr. per år = 2 år. Det vil sige, at tilbagebetalingstiden på denne løsning er to år.

Break-even-metoden Break-even-metoden minder en del om tilbagebetalingstidsmetoden. Forskellen er, at break-even-metoden beregner, hvor mange styk af løsningen der skal sælges, før investeringen er betalt tilbage, ikke hvor mange år der vil gå.

Break-even-metoden er hensigtsmæssig i situationer, hvor projektets løsning er et salgbart emne som fx en app eller et fysisk produkt. Den anvendes på følgende måde: 1. Estimer den samlede investering. 2. Beregn omsætningen per solgt styk (ofte salgsprisen). 3. Estimer driftsomkostningen per stk. (ofte kaldt kostprisen). 4. Træk driftsomkostningen per stk. fra omsætningen per stk. Dette resulterer i driftsoverskuddet per stk. 5. Dividér investeringen med driftsoverskuddet per stk. 6. Resultatet er antallet af emner, der skal sælges, før investeringen er tjent hjem.

Eksempel på break-even-metodens anvendelse Et projekt handler om at udvikle en app. Appen koster en sum penge at udvikle, idet en række softwareudviklere skal bruge tid på at udvikle den, og der skal betales licens for de udviklingsprogrammer, udviklerne bruger. Den samlede pengesum, som det koster virksomheden at designe og udvikle appen, udgør investeringen. I investeringen indgår også de markedsføringsomkostninger, virksomheden har ved at introducere appen på markedet. Når appen er gjort salgbar i fx App Store, begynder de løbende driftsudgifter. Salg gennem App Store koster en afgift til Apple, for hver gang appen købes og downloades af en kunde. Kunderne skal have support til deres brug af appen, og øvrige kundehenvendelser skal håndteres. Summen af alle disse udgifter er løsningens driftsomkostninger. Disse skal vurderes per solgt app. Kundernes betaling for appen udgør løsningens indtægter. Kundernes betalinger kan være engangsbetalinger eller løbende månedlige betalinger i en abonnementsordning. Vurderingen af appens økonomi skal tage højde for både investering, driftsomkostninger og indtægter. Projektgruppen skal derfor vurdere og estimere følgende: Indtægt 1. Den pris, virksomheden kan tage per app Investering 2. Antal timer, der skal bruges på at udvikle appen 3. Andre udgifter til udvikling af appen Driftsomkostninger 4. Antal timer, der skal bruges til kundesupport og teknisk support af appen 5. Afgifterne til App Store per app 6. Omkostninger til den server, der skal hoste appen. Når de nødvendige tal er estimeret så godt som muligt, kan projektgruppen foretage en konkret beregning af den værdi, løsningen har for virksomheden. Projektgruppen har fundet ud af følgende: (a) Hver app genererer en omsætning på 29 kr., (b) den samlede investering er 1,1 mio. kr., og (c) de samlede driftsomkostninger per app er 7 kr. Driftsoverskuddet per app er 29 kr. – kr. 7 = 22 kr. Break-even-punktet regnes derfor som mio. 1,1 kr. / 22 kr. per stk. = 50.000 stk. Virksomheden skal altså sælge appen 50.000 gange, før investeringen er hjemme, dvs. der er break-even ved 50.000 stk.

Nutidsværdimetoden Nutidsværdimetoden, der på engelsk kaldes Net Present Value Method eller Discounted Cash Flow Analysis, beregner, hvilken økonomisk værdi løsningen har for virksomheden, når man medregner både 'her og nu'-investeringen og alle de fremtidige indtægter og udgifter, som løsningen genererer over en årrække. Denne økonomiske værdi kalder man nutidsværdien. Nutidsværdien er én sum penge, der svarer til værdien af alle fremtidige ind- og udbetalinger sammenregnet. Metoden er god, fordi den medregner risikoen, der er ved at investere i løsningen, og bygger på princippet om at 'de penge, man har i banken nu' er mere værd end 'penge, man måske får i fremtiden'. Nutidsværdien af en investering beregnes på følgende måde: 1. Beslut antallet af år, som bør tages med i beregningen. Hvis løsningen tænkes at være i drift i fx tre år, så vælg tre år. Hvis løsningen tænkes at være i drift i 20 år, så vælg et antal år, hvor i med rimelig sikkerhed regner med, at løsningen er i drift.Note 2. Estimér den samlede investering. 3. Vurdér løsningens indtægter år for år i den årrække, som I har besluttet jer for. 4. Vurdér de løbende driftsudgifter år for år i samme årrække. 5. Hvis løsningen kan sælges, når jeres årrække er gået, så vurdér den salgsværdi, som I tror løsningen kan sælges til. 6. Indhent det krav til 'årligt afkast', som virksomheden har til investeringer i nye projekter. Afkastet måles i procent. Læg eventuelt et risikotillæg oven i afkastkravet, i tilfælde af at løsningen er mere usikker end virksomhedens sædvanlige investeringer i nye projekter. 7. Beregn nutidsværdien med nedenstående formel. Hvis nutidsværdien er 0 kr. eller større, er løsningen en god forretning.

Nutidsværdi

= Værdien af alle nutidige og fremtidige indtægter og udgifter

Investering

= Alle omkostninger til indkøb, implementering og idriftsættelse

n

= Investeringshorisonten målt i antal år (fx 4 år)

Driftsoverskud

= Det forventede driftsoverskud år for år

r

= Afkastkrav for investeringen i projektet

i

= Årene i investeringshorisonten (fx 1, 2, 3 og 4)

Scrapværdi

= Salgsværdien af løsningen i år n.

Scrapværdien indgår ikke eksplicit i formlen, men lægges i stedet oven i driftsoverskuddet i det sidste år af beregningen. Dette er år n. Nedenfor ses et eksempel på et projekt, der beregner nutidsværdien af et projekts løsning.

Eksempel på beregning af nutidsværdi for øget anlægskapacitet Virksomheden Hansen A/S udvikler og sælger den aktive ingrediens i en særlig type medicin i penicillinfamilien. Den aktive ingrediens kaldes API (active pharmaceutical ingredient). Kunderne er store medicinalfirmaer, der sammen med andre ingredienser bruger API'en som en råvare i deres færdige penicillinpiller. Virksomheden oplever øget efterspørgsel og har bedt en projektgruppe designe en løsning, der øger kapaciteten på en af firmaets produktionslinjer. En produktionslinje til en API består af en lang række tanke, der er forbundet af rør. På tankene sidder kontrolenheder, der styrer processerne. Projektgruppen har udviklet en løsning. Nogle steder på produktionslinjen foreslår projektgruppen en større tank og andre steder en tank, der installeres parallelt med produktionslinjens eksisterende tank. Ud over tankene kræver løsningen en række nye rørføringer og udskiftning af enkelte kontrolenheder. Projektgruppen estimerer herefter følgende: Antal år, der tages med i beregningen (n) Projektgruppen anvender en fireårig investeringshorisont, da behovet for virksomhedens API forventes at falde på lang sigt. Investering Investeringen, der er nødvendig for at implementere udvidelserne på produktionslinjen, løber op i 9,4 mio. kr. Disse penge dækker (a) indkøb af tanke, rør og kontrolenheder, (b) installation af de nye enheder på produktionslinjen, og (c) værdien af den tabte produktion, når produktionslinjen står stille under installationen. Værdien af den tabte produktion udgør alene 5 mio. kr. ud af den samlede investering på 9,4 mio. kr. Indtægt Løsningen øger produktionslinjens kapacitet med 15 % svarende til 12.000 kg API årligt. Værdien af denne ekstraproduktion udgør løsningens indtægt. Indtægten er 560 kr. per

kg API. Projektgruppen forventer, at kapaciteten det første år kun løftes med 7,5 % og ikke 15 %, da virksomheden kan forvente en del fejlretning og derfor en lavere udnyttelse af produktionslinjen. 7,5 % svarer til 6.000 kg API. Driftsomkostninger Projektgruppen forventer, at der vil være en række ekstraomkostninger til driften af produktionslinjen. Disse omkostninger, der dækker øget vedligehold, monitorering af driften, kvalitetssikring og dokumentation, udgør 1,8 mio. kr. per år. Derudover skal virksomheden indkøbe råvarer til den ekstra produktion. Råvaren til API'en er primært sojamel, og virksomheden forventer en materialeomkostning svarende til 120 kr. per kg færdigproduceret API. Scrapværdi Markedsværdien af de tanke, rør og kontrolenheder, der indgår i løsningen, vurderer projektgruppen til at være ca. 200.000 kr. efter fire års drift. Dette er den sum, projektgruppen forventer, at virksomheden kan få, hvis de indkøbte tanke, rør og kontrolenheder sælges på det åbne marked for brugt udstyr fra medicinalbranchen. Årligt afkastkrav Projektgruppen vurderer, at en investering i øget produktionskapacitet har en lav risiko, fordi de ekstra kg API med stor sikkerhed vil blive købt af kunderne. Der er dog tekniske risici. Den største risiko er længere tid til installation. Dette er nemlig tid, hvor produktionslinjen står stille. I samråd med virksomhedens økonomiafdeling, der ved, hvilke afkastkrav ledelsen generelt har til investeringer, fastsættes afkastkravet til 23 %. Afkastkravet tager både højde for virksomhedens generelle afkastkrav for investeringer i nye projekter og risikoen for løsningen. Nutidsværdi Nedenstående tabel viser, at nutidsværdien for investeringen i den øgede kapacitet på produktionslinjen er knap 2 mio. kr. Investeringen er altså en god forretning. Indtægterne beregnes i år 1 som 6.000 kg * 560 kr. = 4.560.000 kr. Indtægterne for år 2-4 er 12.000 kg * 560 kr. = 9.120.000 kr. Driftsudgifterne er en fast årlig udgift på 1.800.000 kr. til vedligehold og kontrol, mens materialeudgifterne regnes som 120 kr. per kg API. Første år er materialeudgifterne 120 kr. per kg * 6.000 kg = 720.000 kr. og de følgende år 120 kr. per kg * 12.000 kg = 1.440.000 kr. Scrapværdien på 200.000 kr. er aktuel i år 4 som en ekstra indtægt. Det årlige driftsoverskud fås ved at trække driftsudgifterne fra indtægterne. Derefter regnes nutidsværdien af alle fire årlige driftsoverskud. Til slut trækkes alle fire driftsoverskud (i nutidskroner) fra investeringen, der allerede er i nutidskroner. Resultatet er nutidsværdien på de knap kr. 2 mio. Da denne er over 0 kr., er løsningen en god forretning. År Indtægter (dækningsbidrag)

0

1

2

3

4

4.560.000

9.120.000

9.120.000

9.120.000

Driftsudgifter til vedligehold m.m.

1.800.000

1.800.000

1.800.000

1.800.000

Øgede materialeomkostninger

720.000

1.440.000

1.440.000

1.440.000

Scrapværdi

200.000

Årligt driftsoverskud

2.040.000

5.880.000

5.880.000

6.080.000

Årligt driftsoverskud (i nutidskroner)

1.658.537

3.886.575

3.159.817

2.656.337

Investering

9.400.000

Nutidsværdi af investering

1.961.266

Løsninger, der konstrueres og sælges projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Nogle løsninger konstrueres og sælges én gang. I beregningen af en sådan løsnings økonomi er der derfor kun én investering og én indtægt, nemlig salgsprisen af løsningen. Løsningen kunne være fx en bygning eller en maskine. Investeringen indeholder alle omkostninger til design, konstruktion og fremstilling af løsningen. Denne investering skal holdes op imod løsningens salgspris. En sådan løsnings værdi beregnes altså som: Værdi = Salgspris – Investering Læg mærke til, at der i beregningen ikke er løbende indtægter og heller ikke driftsomkostninger. Nu er det ikke sådan, at løsningen ikke har driftsomkostninger. For eksempel skal både en bygning og en maskine vedligeholdes. Men da disse driftsomkostninger afholdes af løsningens køber, indgår de ikke i beregningen. Driftsomkostningerne har bestemt indflydelse på værdien. Køber tager nemlig højde for driftsomkostningerne i vurderingen af, hvor meget køber er villig til at betale for løsningen. Driftsomkostningerne indgår altså i købers overvejelse om den rette salgspris.

Kvantificering af effekt og økonomisk værdi projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Der er ofte variable i et projekt, der er svære at kvantificere. To af dem er: 1. Løsningens effekt på problemet 2. Løsningens økonomiske værdi. At en løsning har en effekt på projektets problem, er ofte ikke rigtigt til debat. For eksempel vil en tykkere væg helt sikkert reducere støj, og stærkere materiale vil helt sikkert kunne holde til større belastning. Udfordringen er altså ikke, om løsningen har en effekt på problemet, men hvor stor effekten er. Ofte har I som projektgruppe ikke det rette talmateriale til præcist at beregne en løsnings effekt. Det samme gælder en løsnings økonomiske værdi. Hvis I ikke har talmateriale til rådighed, så er det næstbedste kvalitative data. Dette kunne fx være en central medarbejder i virksomheden, der fortæller, at et projekts løsning "vil gøre en kæmpe forskel". I sådanne situationer må I forsøge at kvantificere disse kvalitative data. Nedenfor beskrives to kvantificeringsudfordringer, en for en løsnings effekt og en for en løsnings indtægt.

To eksempler på kvantificeringsudfordringer Kvantificering af en løsnings effekt En projektgruppe arbejder sammen med en softwareleverandør, der fokuserer på IT til offentlige organisationer. Virksomheden har solgt et softwareprogram til de kommunale socialafdelinger i alle 98 kommuner. Programmet erstatter egenudviklede softwareløsninger i kommunerne. Disse egenudviklede løsninger, der primært er kombinationer af MS Excel og andre standardprogrammer, er forskellige fra kommune til kommune. Virksomhedens situation er, at selvom alle kommuner har købt softwareprogrammet, så bruger de det ikke i særligt stort omfang. Aktuelt anvender 23 af 98 kommuner alle relevante funktioner i programmet, 34 kommuner anvender nogle af funktionerne, de resterende 41 kommuner anvender slet ikke programmet. Projektgruppen arbejder sammen med virksomheden om at øge brugsraten af programmet i kommunerne. Projektgruppen har efter alle kunstens regler inddraget medarbejdere fra ti udvalgte kommuner i et udviklingsforløb. Dette forløb har resulteret i en række ændringer af programmets grafiske brugerflade og indførelse af en række genvejsmuligheder, der gør programmet hurtigere at bruge. Ændringerne i brugerfladen og genvejsmulighederne udgør projektets løsning. De udsagn, som de inddragede medarbejdere er kommet med omkring projektets løsning, sår ingen tvivl om, at softwareprogrammet (med den foreslåede løsning) nu gør brugernes arbejde nemmere og hurtigere. Løsningen gør endda også programmet nemmere at lære for førstegangsbrugere. Spørgsmålet er derfor ikke, hvorvidt projektets

løsning har en effekt på brugsraten, men hvor stor denne effekt vil være. Hvordan bør projektgruppen kvantificere de kvalitative udsagn, som aktuelle og kommende brugere er kommet med? Dette er projektgruppens udfordring. Se muligheder for kvantificering efter denne eksempelboks. Kvantificering af en løsnings økonomiske værdi En virksomhed producerer kundetilpassede bordplader til køkkener. Virksomhedens kunder er køkkenfirmaer, der sælger køkkener til private kunder og entreprenører. Virksomheden har længe haft problemer med at overholde deres leveringstider på bordplader. Aktuelt leverer virksomheden kun 62 % af deres bordplader til tiden, og 38 % af bordpladerne ankommer altså for sent. Firmaet oplever næsten dagligt telefoniske klager over forsinkede ordrer. En projektgruppe arbejder med at reducere antallet af forsinkede bordplader. Projektgruppen har designet en løsning, der består af (a) en række nye politikker for planlægning og lagerføring, (b) en udvidelse af et eksisterende IT-program, og (c) træning af en række medarbejdere. Gruppen har vurderet, at løsningen vil reducere antallet af forsinkede bordplader fra de nuværende 38 % til ned mellem 3 og 5 %. Kunderne kan derfor i fremtiden regne med at få deres bordplader til tiden. Spørgsmålet er nu, hvilken økonomisk værdi denne løsning vil have. Virksomheden formoder, at løsningen vil reducere frafaldet af eksisterende utilfredse kunder og måske også give nye kunder, der er trætte af forsinkelser hos konkurrenter. Derudover vil løsningen formentlig resultere i færre nødvendige ressourcer i virksomhedens kundeservice, idet kunder, der nu får deres ordrer til tiden, ikke ringer og spørger, hvor deres ordrer bliver af. Der er således ingen tvivl om, at løsningen har en økonomisk værdi. Størrelsen af denne værdi er dog svær at kvantificere. Se muligheder for kvantificering efter denne eksempelboks. Der findes en række generelle muligheder for at kvantificere variable. Her er fire udbredte metoder: 1. Generalisere fra få til mange observationer For eksempel fra én arbejdsstation til alle arbejdsstationer eller fra én kunde til alle kunder. 2. Anvende korrelerende variable Hvis et husbyggeri vurderes at stige 10 %, er det rimeligt at antage, at murstenssalget også vil stige 10 %. 3. Overføre resultater fra lignende cases Hvis fx et konkurrerende shippingfirma reducerer deres brændstofforbrug per container med 0,45 % ved at sejle langsommere, er det rimeligt at antage, at disse 0,45 % også vil gælde andre shippingfirmaer.

4. Transformere kvalitative data til kvantitative data Skaf så mange kvalitative data, som I kan, helst fra forskellige kilder. Få dine informanter til at foretage kvantitative vurderinger uafhængigt af hinanden (en informant siger måske 20-30 % forbedring, en anden informant siger 25-35 %, og en tredje informant siger 30-40 %). Præsentér til sidst resultatet som et interval (fx "Løsningen vil give en forbedring på 20 til 40 %"). I eksemplet omkring softwareforbrugsmønsteret i 98 kommuner kunne metode 3 fx anvendes, ved at projektgruppen spurgte firmaet om deres erfaringer med andre programmer til de samme kommuner og derefter overførte resultaterne til det aktuelle program til socialafdelingerne. Gruppen kunne også lede efter mere generelle erfaringer i litteraturen om softwareadoption i offentlige organisationer. Der er blandt vejledere delte meninger om, hvorvidt I som projektgruppe overhovedet bør kvantificere variable, hvis usikkerheden er stor. I har følgende tre muligheder: 1. Nøjes med at kvantificere de variable, der kan kvantificeres med stor sikkerhed. De variable, der ikke kan kvantificeres, beskriver I i projektet, men kvantificerer ikke. 2. Nøjes med at kvantificere de variable, der kan kvantificeres med stor sikkerhed. Nedfæld derudover retningslinjer for, hvordan virksomheden selv gennem yderligere undersøgelser kan kvantificere de svært kvantificerbare variable. 3. Kvantificér alle variable, og beskriv usikkerhederne, således at virksomheden på et oplyst grundlag kan tage (usikre) beslutninger. Fordelen ved de første to muligheder er, at alle tal og vurderinger af effekt og økonomisk værdi er præcise. Ulempen er, at vurderingerne ikke er særligt brugbare. Hvis man kun medtager de let kvantificerbare tal, kan analysens resultat hurtigt ende som blot en tilfældig og ubrugelig mellemregning. Det er vigtigt at tale med jeres vejleder om, hvilken af de tre muligheder jeres vejleder opfatter som mest "professionel". Hvis I vælger at kvantificere, er risikoen til eksamen, at eksaminator og censor brokker sig over de store usikkerheder. Hvis I omvendt vælger kun at kvantificere de sikre variable og blot beskriver de svært kvantificerbare variable med ord, er risikoen, at eksaminator og censor brokker sig over, hvor ubrugelig analysen er.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Opsummering

I dette kapitel har du lært, at en løsning i et teknisk projekt er et hierarki af beslutninger, hvor nogle beslutninger er underordnet andre beslutninger. Projektets analyse og løsningsdesign skal hænge sammen, ved at løsningen skal eliminere de årsager til projektets problem, som jeres analyse har identificeret, og opfylde de krav, analysen har fundet. Du har lært, at en god løsning skal bygge på resultaterne af projektets analyse, opfylde brugernes krav til løsningen, være implementerbar, opfylde studiets krav til en god løsning og (frem for alt) adressere projektets problem. Kapitlet beskriver tre arketyper på løsninger i tekniske projekter, nemlig enkeltløsningen, "enten-eller"-løsningen og den sammensatte løsning. Som projektgruppe skal I vurdere og helst kvantificere løsningens effekt på projektets problem samt den økonomiske værdi af denne effekt. Samtidigt skal det vurdere løsningens implementerbarhed og omkostningerne ved implementering og drift.

Kapitel 8. Test og implementering af løsning projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I dette kapitel lærer du: Hvordan test af en løsning indgår i et teknisk projekt Hvordan virksomheden bør involveres i testen Hvad implementering betyder på tværs af tekniske uddannelser Hvordan I kan planlægge løsningens implementering Hvordan implementeringsplanen kan tage højde for både den praktiske implementering og modstand mod forandring blandt virksomhedens medarbejdere (og evt. ledere) Hvordan ejerskab, der er nøglen til implementeringssucces, sikres gennem løbende involvering af virksomhedens medarbejdere og ledere i løbet af hele projektperioden begyndende længe før planlægningen af implementering. På nogle uddannelser er test og implementering af den designede løsning en forventet del af projektet, på andre uddannelser er det en "nice to have"-del af projektet, og på andre uddannelser er test og implementering helt ude af scopet. Kapitlet er derfor mest relevant for første gruppe uddannelser. Kapitlet beskriver, hvordan et teknisk projekt kan arbejde med test og implementering af projektets løsning. Kapitlet vil først kort omhandle test af løsning og dernæst implementering.

Test af løsning | Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Test af løsning

Idet en løsning er forskellig fra uddannelse til uddannelse, er testning af løsninger også forskellige. Hvis et projekt har udviklet en algoritme, skal algoritmen testes, så det kan afklares, om algoritmen leverer de rette resultater. Hvis et projekt har udviklet en ny indkøbs- og lagerpolitik, der skal reducere det gennemsnitlige lager, bør projektet så vidt muligt teste, om brugen af den nye politik giver de ønskede resultater (fx et lavere lagerniveau). Nogle løsninger er svære eller meget dyre at teste virkelighedsnært. Dette kunne være holdbarheden af en ny type tagkonstruktion. Simuleringssoftware kan være en mulighed. Nogle løsninger kan testes med varianter af rollespil. For eksempel kan en ny kvalitetsstyringsprocedure testes gennem en workshop: "Nu leger vi, at løsningen er implementeret. Først skal Jørgen indmelde en fejl, så skal jeg registrere fejlen korrekt, så skal Ebbe og Hans udfylde rapporten, og til sidst skal Bente godkende fejlrapporten." At teste løsninger i en virkelighedsnær situation kan involvere virksomhedens medarbejdere. Hvis det gælder jeres projekt, så planlæg testen i god tid, så virksomhedens medarbejdere har tid i deres kalendere. Book medarbejderne ca. en måned i forvejen med en mødeindkaldelse, der blot hedder "Test af [løsningens navn]", og skriv, at en nærmere beskrevet agenda følger.

Implementering af løsning projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Ordet implementering betyder meget forskellige ting på hver af de tekniske uddannelser. Begrebet dækker dog altid de aktiviteter i et projekt, der følger efter løsningsdesignet. På byggeriuddannelser betyder implementering som regel, at en bygning (eller anden konstruktion) bygges På maskin- og produktdesignuddannelser betyder implementering ofte, at produktdesignerne påbegynder samarbejde med virksomhedens produktionstekniske afdeling om, hvordan produktet skal produceres På produktionsuddannelser betyder implementering ofte, at løsninger sættes i drift (fx at en ny procedure påbegyndes) På IT-uddannelser betyder implementering fx, at ny kode embeddes i et apparats samlede programkode.

Figur 8.1. Implementeringsforståelser på tværs af tekniske uddannelser

Selvom ordet implementering kan betyde mange ting, så har alle faglige retninger til fælles, at implementering består af en række på hinanden følgende skridt, og hvert af disse skridt skal tages af en aktør (fx en person eller en hel afdeling i virksomheden). Implementering skal først planlægges og derefter gennemføres. Planlægningen er mest relevant for jer, idet beslutningen om, hvorvidt og hvornår implementeringen skal foretages, som regel er ude af jeres hænder. Implementering forudsætter ofte, at højerestående personer i virksomhedens hierarki godkender løsningen. Implementering betyder nemlig, at omkostningerne, som løsningen bringer med sig, skal afholdes, at en række medarbejderes tid skal afsættes til projektet, og at kunder og leverandører måske skal involveres. Kapitlet her vil derfor fokusere på planlægningen af implementeringen.

Planlægning af implementeringen projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Implementering af en løsning er et projekt. En plan for implementering består derfor typisk af tre overordnede komponenter: En projektplan 1. Hvilke aktiviteter virksomheden skal gennemføre 2. Hvilken rækkefølge aktiviteterne skal gennemføres i 3. Hvilke medarbejdere og ledere der er ansvarlige for de enkelte aktiviteter. En projektorganisation 1. Hvem der skal være ansvarlig for implementeringsprojektet 2. Hvem der skal være i styregruppen for implementeringsprojektet 3. Hvorvidt projektmedlemmers tid skal allokeres helt eller delvist til implementeringsprojektet 4. Hvor ofte styregruppen skal involveres i implementeringsprojektet. En plan for håndtering af modstand mod forandring 1. Identifikation af grupperinger og personer, som kan forventes at udvise modstand mod forandringen 2. Hvordan de implementeringsansvarlige skal kommunikere til de medarbejdere og ledere, der bliver påvirket af løsningen, således at de rigtige personer bliver informeret på den rigtige måde med det mest hensigtsmæssige niveau af information og på det rigtige tidspunkt (fx hvordan succeser skal kommunikeres) 3. Hvordan implementerede ændringer fastholdes (fx ændringer af virksomhedens måde at give bonusser på). De følgende tre afsnit går i dybden med hver af disse tre komponenter. Den sidste komponent om håndtering af modstand mod forandring er mest relevant for projekter, hvor adfærd hos personer bliver direkte påvirket af projektets løsning.

Projektplan for implementering Projektplanen kan udarbejdes med Gantt-diagrammet, som er gennemgået i kapitel 5. Planen for implementering af løsningen er dog som regel en mere grov version af Ganttdiagrammet end planen for jeres eget projekt. Anvend gerne jeres faglige litteratur i planlægningen. For eksempel til at sikre, at I har husket alle vigtige aktiviteter, at de står i den rigtige rækkefølge med nok tid og med de rigtige kompetencepersoner.

Hvis projektets løsning er sammensat af en række løsningselementer, der kan implementeres hver for sig, kan I foreslå at implementere rækken af løsningselementer i mindre bunker (sommetider kaldt "bølger"). Hvis et projekt fx består af seks individuelle løsningsforslag, kan I dele disse seks forslag ind i to bølger a tre elementer. I første bølge implementeres løsningselement 1, 2 og 3, og i anden bølge implementeres løsningselement 4, 5 og 6. I kan anvende prioriteringsmatrixen illustreret i figur 7.3 som hjælp til at gruppere løsningselementerne i bølger. Her er fire generelle råd til jeres planlægning af implementeringen: 1. Implementér de "lavthængende frugter" først, så I hurtigt kan vise effekten af løsningselementerne 2. Hvis nogle løsningselementer ikke behøver investering eller blot en meget lille investering, så kan det være fornuftigt at lægge disse løsningselementer først i planen Note 3. Hvis der er mange løsningselementer, så gruppér dem i bølger, så implementeringen er mere overskuelig for de medarbejdere, der ikke har været involveret i analysearbejdet og løsningsudviklingen 4. Husk, at der kan være afhængigheder mellem løsningselementerne, der gør, at nogle løsningselementer skal implementeres før andre.

Projektorganisation til implementering Som en del af implementeringen kan I foreslå, hvordan virksomheden skal organisere de personer, der skal foretage implementeringen. En sådan projektorganisation består ofte af en styregruppe, en projektleder og en række andre vigtige aktører. I et projekt, der handler om implementeringen af nye procedurer, kunne en projektorganisation bestå af en projektleder, en styregruppe (bestående af virksomhedens produktionschef, logistikchef, IT-chef og salgschef), en række interne projektmedarbejdere og en række eksterne konsulenter og leverandører, jf. figur 8.2.

Figur 8.2. Eksempel på en projektorganisation

Herunder er fire huskeregler til en effektiv projektorganisation (Sirkin et al., 2005; Kotter, 1998): Styregruppen skal have magt nok i organisationen til løbende at træffe vigtige beslutninger. Projektlederen, som I foreslår, bør have så meget erfaring, at organisationen tror på, at løsningen faktisk vil blive implementeret, og at det ikke bliver ved snakken. Medarbejderne til projektorganisationen bør så vidt muligt arbejde fuld tid på projektet. (Alternativet er, at medarbejdere skal lånes til projektet, fx 20 % af deres arbejdstid fra deres fuldtidsstilling. Det giver ofte problemer.) Styregruppemøder bør afholdes hyppigt (fx en gang om måneden), så implementeringen holdes i gang.

Plan for håndtering af modstand mod forandring I projekter, hvis løsninger kræver ændret adfærd hos virksomhedens medarbejdere, er det en god ide at inddrage faglig litteratur om forandringsledelse. Med denne litteratur som ballast kan I bedre sikre implementeringen imod forandringsmodstand blandt de menige medarbejdere. Det kan være en god ide at inddrage medarbejdere tidligt i processen, så I bliver klar over, hvor løsningen kommer til at møde modstand. Implementeringsplanen bør tage højde for forventelig modstand fra magtfulde personer i virksomhedens organisation. Til dette formål kan I anvende interessentanalysen beskrevet i kapitel 11. Interessentanalysen giver et overblik over, hvilke (a) personer og persongrupper der har interesser i projektet, (b) om disse interessenter fremmer eller forhindrer implementeringen, og (c) hvor stor en magt disse personer eller persongrupper har. Implementeringen kan afstedkomme modstand mod forandring fra de kommende brugere af løsningen. Denne modstand kan minimeres gennem involvering af centrale repræsentanter fra brugergruppen. Generelt er tidlig involvering af de kommende brugere en effektiv måde at minimere modstand på. Involvér gerne kommende brugere allerede i jeres analyse- og løsningsarbejde. Se mere om tidlig involvering i det næste afsnit.

Ejerskab er nøglen til implementeringssucces projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Tekniske projekter skal designe implementerbare løsninger. Nøglen til, at virksomheden faktisk implementerer projektets løsninger, er ejerskab. Hvis virksomheden føler ejerskab til projektet og dets løsninger, så er implementering langt mere sandsynlig, end hvis løsningerne pludseligt "dumper ned fra himlen". Ejerskab hos virksomheden opbygges ved at involvere virksomheden tidligt og løbende i projektets proces. En virksomhed kan sagtens vise stort engagement for et projekt i begyndelsen af processen, men fem sekunder efter det første møde kan alt være glemt. Husk derfor løbende at involvere virksomheden. En oplagt mulighed for involvering er workshops. Kapitel 10 om det gode virksomhedssamarbejde beskriver tre workshops, der har jer som værter og virksomhedens medarbejdere som de inviterede deltagere. Den første af disse workshops er analyseworkshoppen. Formålet med denne er at sikre, at virksomheden er enig i de analyseresultater, som I er kommet frem til. Hvis alle er enige i, at analyseresultaterne er korrekte, så danner analysen det bedste grundlag for løsningsdesignet. Den næste workshop er løsningsworkshoppen. Her er formålet at sikre, at medarbejderne føler ejerskab til projektets løsning. Gennem workshoppen formes og detaljeres en række skitser og ideer. Det sker med medarbejdernes input. Når medarbejderne kan se deres eget tydelige aftryk i den endelige løsning, stiger sandsynligheden for løsningens implementering. Sidste workshop er implementeringsworkshoppen. Her er formålet at udarbejde projektplanen, identificere de rette personer til ledelsen af implementeringen og udarbejde en plan for håndtering af modstand mod forandring. I løbet af workshoppen får medarbejdere og ledere ideer til, hvordan løsningerne kan implementeres på en realistisk måde, der håndterer modstand og sikrer fastholdelse af løsningen. Det er jeres opgave at sikre, at alle væsentlige emner er drøftet og håndteret i implementeringen. Det gælder fx de emner, der er indeholdt i de fire huskeregler til en effektiv projektorganisation ovenfor.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Opsummering

I dette kapitel har du lært, hvordan test og implementering af en løsning kan indgå som en del af jeres projekt. Test af løsninger kan gennemføres med simuleringssoftware eller gennem virkelighedslignende rollespil. Virksomhedens medarbejdere bør involveres i testen, og I bør arrangere deres medvirken i god tid. Begrebet implementering betyder meget forskellige ting på tværs af tekniske uddannelser. Implementering er dog altid en aktivitet, der følger løsningsdesignet og udgør et sæt af på hinanden følgende skridt. Først planlægges disse skridt, og derefter gennemføres implementeringen i de planlagte skridt. En implementeringsplan består af en projektplan, en projektorganisation og en plan for håndtering af den modstand mod forandring, der ofte må forventes. Kapitlet beskriver, hvordan virksomhedens ejerskab til løsningen er nøglen til implementeringssucces, og at dette ejerskab bedst sikres ved at involvere virksomhedens medarbejdere og ledere lige fra start og gennem hele projektperioden.

Kapitel 9. Samarbejde i projektgruppen og med vejleder projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I dette kapitel lærer du: Hvordan projektgrupper dannes, og de dynamikker, der er i klassen omkring gruppedannelsen Hvordan din indsats og dit engagement i studiets første tid påvirker dine muligheder i fremtidige gruppedannelsesprocesser Hvordan en gruppekontrakt kan understøtte engagement, tilstedeværelse og kommunikation i jeres projektgruppe Hvad en god gruppekontrakt indeholder, og hvordan I kan forebygge konflikter gennem aktiv og løbende brug af gruppekontrakten Hvordan I bedst udnytter jeres projektgruppemøder Hvordan tryghed og tillid er nøglen til det gode samarbejde i jeres projektgruppe Hvordan I håndterer konflikter i jeres projektgruppe Hvordan I bedst kan bruge jeres vejleder i projektarbejdet Hvordan et godt vejledermøde kan forløbe, og hvad der er gode emner til vejledning Betydningen af, at vejleder først er vejleder og senere eksaminator. Dette kapitel handler om samarbejde og kommunikation internt i jeres projektgruppe og om, hvordan I kan bruge jeres vejleder. Kapitlet beskriver dannelsen af projektgruppen, opstart af gruppearbejdet, den løbende proces i gruppen, koordinering af arbejdet i projektperioden (fx gennem projektgruppemøder), problemer i projektarbejdet, og hvordan I bedst benytter jeres vejleder.

Dannelsen af projektgruppen projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Når du påbegynder et projektkursus, møder du med det samme to udfordringer: at forstå projektets faglige indhold og at danne projektgruppen. Begge dele fylder ofte rigtig meget i bevidstheden, men dannelsen af projektgruppen fylder ofte mest. Første semester på en uddannelse er på mange måder særligt: 1) Projektgrupperne dannes ofte af underviserne, 2) I kender ikke rigtigt hinanden, og 3) jeres projektkompetencer er på laveste niveau på hele jeres uddannelse. Projektkompetencer opnår du på samme måde som andre fagligheder, gennem øvelse og træning. Projektkompetencer handler om at kunne deltage konstruktivt i projektarbejde, at lede og planlægge et projektforløb og at kunne løse faglige og personlige konflikter under projektforløbet. Igennem din deltagelse i uddannelsens projektarbejde oparbejder du projektkompetencer. Du lærer dig selv at kende som deltager i et projektforløb, du lærer dine egne personlige styrker og svagheder at kende, du begynder at trives mere og mere i et projekts kaotiske opstart, og frem for alt får du erfaringer i at arbejde i projektgrupper med forskellige mennesker og personlighedstyper. Disse forskelle er også til stede i dit fremtidige arbejdsliv. Måske får du dine allerførste erfaringer med projektarbejde på dine første semestre på din videregående uddannelse. Fordi dine projektkompetencer endnu ikke er helt på plads, kan projektarbejdet opleves som frustrerende og uoverskueligt. For at undgå frustrationen går studerende meget højt op i sammensætningen af projektgruppen. Særligt på andet og tredje semester, hvor klassen ofte selv danner grupper, opleves gruppedannelsen i semestrets begyndelse ofte som den vigtigste begivenhed på semestret.

Dynamikkerne i gruppedannelsesprocesser Alle klasser og hold har hver deres sociale og faglige sammensætning. Nogle af dine medstuderende er meget målrettede og har store forventninger til sig selv. Andre af dine medstuderende fokuserer ikke så meget på karakteren, men mere på at få nogle praktisk anvendelige redskaber til deres fremtidige arbejdsliv. For en tredje gruppe medstuderende handler studielivet om ikke at stresse for meget, men i det hele taget trives og have det godt. Nogle af dine medstuderende har valgt uddannelsen som sidste prioritet, andre som førsteprioritet, og nogle ved måske ikke, om de har taget det rigtige valg. Nogle af dine medstuderende har hjemlige forpligtigelser (fx børn) eller krævende studiejobs. Nogle studerende kommer direkte fra gymnasiet eller HTX, mens andre har erfaringer fra andre uddannelser, fra militæret eller et længere forudgående arbejdsliv (fx som håndværker). Nogle af dine medstuderende er gamle, og nogle er unge.

Alle disse forskelligheder gør gruppedannelsesprocessen kompliceret. Det mest almindelige i en gruppedannelsesproces er, at personer, der minder om hinanden, gerne vil være i gruppe med hinanden. Mennesker er trygge ved det kendte. På første semester kender du og dine medstuderende ikke hinanden særligt godt. Hvis underviserne ikke danner grupperne, vil du indgå i en gruppedannelsesproces, hvor I vælger hinanden baseret på det, i umiddelbart kender til hinanden eller kan afkode ved at se og høre på hinanden (fx alder, frisure, stemmeføring, tatoveringer, accent, skæg, piercinger etc.). På andet semester og frem kender I hinanden bedre. Her begynder andre parametre at betyde noget. Disse er tilstedeværelse, karakterer fra første semester, seriøsitet, humor, og om man ganske enkelt er flink og rar at være sammen med. Det er vigtigt at være klar over, at din individuelle indsats, tilstedeværelse, seriøsitet og sociale færdigheder som medlem af en projektgruppe er ganske afgørende for dine muligheder i fremtidige gruppedannelsesprocesser. Ser dine medstuderende dig som den flittige eller den knap så flittige?

Når gruppen er dannet projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Når gruppedannelsen er afsluttet, begynder projektforløbet for alvor. I skal sammen sikre jer dels en præcis forståelse af projektets formål og metoder, og dels finde den bedste samarbejdsform for jeres gruppe. En gruppe vil ofte organisere sig im- eller eksplicit med en leder og en række arbejdere. Fordi organiseringen i projektgrupperne ikke er eksplicit, vil ekstroverte personer ofte indtage lederrollen. Brug af personligheds- og præferencetests kan være en mulighed for at skabe overblik over jeres gruppes samlede evner og præferencer. Disse tests kan udgøre et bolværk mod potentielle konflikter i gruppen. Der opstår ofte situationer, hvor studerende i jeres gruppe ikke forstår hinandens prioriteringer, metodevalg, opgaveforståelser og lignende. Præferencetests kan forklare, hvorfor personer i jeres gruppe gør, som de gør. Det kan lette konfliktniveauet.

Personligheds- og præferencetest En personlighedstest består typisk af en række spørgsmål og en række personlighedsarketyper. Disse arketyper er en slags modelpersonligheder. Når du svarer på spørgsmålene i testen, viser testen dig, hvilken af disse arketyper din personlighed ligner mest. Testen har altid en beskrivelse af hver arketype, og når du får dit resultat, kan du læse om arketypen og derigennem blive klogere på dig selv (fx hvorfor du reagerer, som du gør, og hvorfor du kan lide nogle ting og ikke lide andre ting). Hvis du og dine gruppekammerater alle gennemfører den samme personlighedstest, får I overblik over, hvilke personlighedstyper I har i jeres projektgruppe. Med denne viden er I langt bedre rustet til at forstå, hvorfor I hver især agerer, som I gør. Du synes måske, at to af dine gruppemedlemmer agerer meget anderledes, end du selv gør i nogle situationer. Måske er du endda på nippet til at blive sur på dine gruppekammerater. Personlighedstesten kan hjælpe dig til at forstå, at dine medstuderende handler, som de gør, pga. deres personlighed, og ikke fordi de er uengagerede eller ligeglade med jeres projekt. Alene processen at gennemføre personlighedstesten kan give jer som gruppe en række vigtige informationer om hinanden. For eksempel kan en samtale om testen lyde således: Person A: "Hvad svarede du på spørgsmål 12?" Person B: "Jeg svarede D." Person A: "What!?! Seriøst! Hvordan kan det være?" Person B forklarer … Person A: "Nå, ja. Det giver god mening."

En anden type test, der er særligt god i projektsammenhænge, er præferencetesten. Denne test viser, hvilken rolle en person naturligt bedst fungerer i og kan lide at påtage sig (dvs. hvad ens præference er). Er man opstarteren, er man lederen eller måske afslutteren? Hvis I kender hinandens præferencer, hjælper det jer til at forstå de andres adfærd. Ud over at give jer indsigt i jeres individuelle præferencer for roller i projektarbejde hjælper en præferencetest også med at fortælle, hvilke roller I mangler præferencer for i jeres samlede gruppe. Hvis I som projektgruppe finder ud af, at I fx mangler en afsluttertype i jeres gruppe, må I alle i fællesskab huske, at I skal sætte god tid af til at afslutte. I kan finde en række forskellige personlighedstest gennem Google. Brug søgeord som fx "personality test" og "preference test" på dansk eller engelsk. Tre populære tests er Myers- Briggs personlighedstest, The Big Five personlighedstest og Belbins præferencetest.

Anvend en gruppekontrakt til at understøtte engagement, tilstedeværelse og kommunikation På mange uddannelser anbefaler underviserne, at projektgruppen nedfælder reglerne for 'den gode adfærd' i en gruppekontrakt. En gruppekontrakt er et dokument, der indeholder en række paragraffer for, hvad I som projektgruppe mener er god og professionel adfærd i projektarbejdet. En gruppekontrakt kan indeholde paragraffer om følgende temaer: 1. Hvor ofte og hvor I som projektgruppe mødes 2. Hvorvidt I tillader brugen af sociale medier under projektgruppemøder 3. Om I forventer, at alle i gruppen deltager i den undervisning, der er vigtigt for projektet 4. Hvordan og hvornår en person i jeres gruppe skal fortælle, at han/hun er forhindret i at deltage i en gruppeaktivitet 5. Hvordan I skal ytre utilfredsheder, og hvordan utilfredsheder skal behandles i jeres gruppe 6. Hvordan I vil håndtere konflikter 7. Jeres forventede ugentlige arbejdstid 8. Jeres kommunikationsmidler og kommunikationsadfærd (herunder IT-baseret kommunikation) 9. Om og hvordan I dokumenterer beslutninger og andre væsentlige issues 10. Brugen af dagsordener og referater 11. Hvorvidt I forventer fysisk tilstedeværelse på skolen, eller om hjemmearbejde er tilladt 12. Håndtering af nogle gruppemedlemmers studiejob og situationer, hvor det er svært at finde tidspunkter i kalenderen, hvor alle er ledige 13. Konsekvenser for brud på aftaler, konsekvenser for gentagne brud på aftaler, og hvad der skal til, for at et gruppemedlem på professionel vis sparkes ud af gruppen

14. Hvordan I organiserer jer (hvem er leder, hvem er planlægger etc.) 15. Hvordan I kvalitetssikrer de enkelte medlemmers arbejde, og hvordan I sikrer den røde tråd i hele projektet 16. Hvordan og hvornår gruppemedlemmer, der ikke kan nå at afslutte aftalte opgaver, skal melde ud og indhente hjælp fra gruppen som helhed. Udarbejd gruppekontrakten med det mindset, at I kommer til at bruge den – mange gange. Et projekt gennemgår ofte den samme række faser. En udbredt model af Tuckman (1965) beskriver, at et projekt har fire typiske faser:

Figur 9.1. De fire faser i Tuckmans projektmodel (Tuckman, 1965)

Forming betyder, at gruppen dannes. Storming betyder, at gruppemedlemmerne kæmper en kamp om, hvad den rette adfærd er for gruppen, hvad projektet skal handle om, og hvad det generelt er vigtigt at prioritere i arbejdet. De fleste projekter går gennem en Storming-fase, særligt hvis gruppemedlemmerne ikke kender hinanden, og hvis man ikke har stor erfaring med projektarbejde. Så pas på med at tro, at det kun er jeres projektarbejde, der føles frustrerende. Det gør projekter meget tit. At arbejde under kaos og frustration er del af jeres læringsproces på uddannelsen. Husk, at netop jeres erfaringer med kaos og frustration i studietiden gør jer til dygtige projektledere og projektdeltagere i jeres karriere. Efterhånden får I erfaring med projektarbejde, og så føles Storming-fasen ikke så frustrerende. Med erfaring lærer I at forblive rolige og cool. Storming-fasen ender ud i Norming-fasen, hvor kampene er taget, og der er fundet vindere. I Norming-fasen begynder hele projektgruppen at arbejde efter vindernes normer for den rette projektadfærd. Nogle gange dokumenteres de nye normer ved at opdatere gruppekontrakten. Når normdannelsen er afsluttet, går projektet ind i Performing-fasen, hvor gruppemedlemmerne kan arbejde mere målrettet. Her står målet klart for gruppens medlemmer og også den adfærd, der bedst leder til målet.

Projektgruppemøder – minimum en gang per uge (helst to) På 1. og 2. semester på uddannelsen er projektgruppemøder meget vigtige. Projekter på 1. og 2. semester fylder typisk 5 eller 10 ECTS-point ud af semestrets 30 point. I har derfor alle rigeligt andet at beskæftige jer med end projektet. Det er dog meget vigtigt både for projektets og for jeres eget ve og vel, at I mødes til et projektgruppemøde minimum én gang om ugen. Digital kommunikation kan ikke erstatte det ugentlige gruppemøde, hvor I fysisk er i samme rum. Kommunikation foregår generelt bedst, når I sidder i samme rum og kan se og høre hinanden, når I taler sammen. Ved at være fysisk i

samme rum kan I meget nemmere afkode hinanden, når I diskuterer. En velfungerende projektgruppe skal være i stand til at have faglige diskussioner. Disse diskussioner kan nogle gange gå højlydt for sig. Det kunne fx være, når et gruppemedlem virkelig føler, at de andre gruppemedlemmer ikke forstår, hvorfor en særlig metode er vigtig for projektet ("Come on, nu må I tage jer sammen"). Denne type diskussioner skaber hurtigt frustrationer, og det går særligt hurtigt, hvis diskussioner foregår skriftligt på et digitalt medie. Skriftlige udsagn på digitale platforme kan hurtigt misfortolkes og/eller overfortolkes, og dette er en typisk årsag til frustration og irritation. Særligt er feedback en 'højrisikoaktivitet'. På afgangsprojekter er de optimale arbejdsforhold, at man sidder i det samme rum til daglig. Dette rum skal så vidt muligt være i den virksomhed, som I samarbejder med. Gør derfor alt, hvad I kan, for at få stillet et rum til rådighed i virksomheden. Daglig tilstedeværelse i virksomheden betyder, at I løbende kan kommunikere face-to-face med medarbejdere og have mange mindre, uformelle samtaler. At kommunikere med virksomhedens medarbejdere mundtligt er meget mere effektivt end at vente på svar på mails. Mails tager lang tid, og de kan glemmes, gemmes, slettes og fortolkes forskelligt. Hvis I som projektgruppe sidder sammen, er det ikke så tvingende nødvendigt at aftale faste projektgruppemøder. I taler bare om tingene hen over bordet.

Skal vi have en ordstyrer og en talerække? Det kan være nødvendigt i begyndelsen af et projekt, og hvis I ikke kender hinanden. Det er vigtigt for alle at kunne tale uden frygt for hele tiden at blive afbrudt. Med tiden lærer I hinanden at kende, og så bliver ordstyrer og talerække naturligt ikke så aktuelt mere. Et klassisk problem til projektgruppemøder er, at et af jeres gruppemedlemmer ubevist kaprer alt for meget af den samlede taletid i diskussioner. Dette vil på lang sigt blive et problem for personen selv i sit kommende arbejdsliv. Tag derfor, både for jeres gruppes og personens egen skyld, problemet op på næstkommende gruppemøde, og aftal et "tag en lille pause"-signal, eller udnævn et gruppemedlem til ordstyrer, og anvend en talerække.

Digital kommunikation og digitale projektgruppemøder Online kommunikationsplatforme som fx en Messenger-tråd er vigtige, når I har behov for at kommunikere akut "in real time" med enten hele gruppen eller blot enkelte af gruppemedlemmerne. Men husk, at skriftlige beskeder ikke bør erstatte fysiske projektgruppemøder, hvor I diskuterer vigtige beslutninger og aftaler opgaver til hvert gruppemedlem. Skriftlige beskeder kan fortolkes forskelligt og hurtigt skabe splid. Tænk bare på bemærkninger som "Jamen, jeg troede, at du …" eller "Det aftalte vi jo i mandags". Brug kun digitale beskeder til nød eller til småting. Hvis der er flere ting, I skal

afklare, eller I skal diskutere en stor beslutning, så undgå digitale beskeder. Ring op, eller endnu bedre vent (hvis muligt) til det næstkommende fysiske møde. Der kan hurtigt opstå irritationer og vrede over digitale beskeder. Der er klare tendenser til, at ingeniører og andre teknisk uddannede professioner mødes mindre fysisk og i stedet anvender digital kommunikation. Dette er effektivt, når et projekt er kommet i gang og 'kører'. Så er risikoen for kommunikationsproblemer meget mindre end i starten af projektperioden. Folk kender hinanden og kan nemt tolke skriftlige beskeder. I de tidlige faser af et projekt er sagen dog en helt anden. Her skal takt og tone slås an, og selv hærdede projektledere kan hurtigt blive unødigt frustreret, når kommunikationen er mudret og uklar.

Tryghed og tillid er nøglen til det gode samarbejde og den gode kommunikation i projektgruppen projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Ingen er født med evnen til at samarbejde. Samarbejde er en tillært kompetence ligesom matematik, termodynamik og styrkelære. Man skal lære at samarbejde. Mange færdige diplomingeniører er "samarbejdsstjerner". De har nemlig lært samarbejdsdisciplinen indgående at kende gennem de erfaringer, de har gjort sig gennem deres uddannelse. Disse erfaringer får I gennem uddannelsens projektarbejde, hvor I med både krop og sind lærer at samarbejde. På jeres første semestre bevæger I jer op ad en stejl læringskurve, og det er svært, selv for de dygtige og flittige. I skal skabe et behageligt arbejdsklima i jeres gruppe. Nøglen til dette er tillid og tryghed. Hvis der hersker tillid og tryghed i jeres gruppe, så er: 1. risikoen for store konflikter lille 2. frustrationerne over andre gruppemedlemmers adfærd lav 3. chancen for flotte resultater og en god karakter stor. I skal vide, "hvor I har hinanden". Dette gælder både fysisk og fagligt. Hvis et gruppemedlem ikke er til stede ved et aftalt gruppemøde, hæmmer dette tilliden til gruppemedlemmet. Man stiller sig naturligt spørgsmålet, om man kan stole på, at gruppemedlemmet leverer de opgaver, man har aftalt. Tillid og tryghed er også grundlaget for lærerige faglige diskussioner i jeres gruppe. Faglige diskussioner er naturlige og nødvendige og rummer et enormt læringspotentiale. Der skal (!) derfor være plads til faglige diskussioner. Mennesker har forskellige tærskler for, hvornår en diskussion føles ubehagelig. Det sker ofte, at en eller to af medlemmerne i jeres gruppe synes, at I har gang i gode faglige diskussioner, mens andre synes, at diskussionerne bliver for personlige og måske endda ubehagelige. I sådanne situationer er det vigtigt, at I diskuterer det eksplicit ved næstkommende gruppemøde. Den eksplicitte samtale om problemet vil få alle til at forstå, at argumentation ikke er ment personligt og at samtaleniveauet skal være behageligt for alle. At have samtalen er første skridt til et bedre arbejdsklima. Andet skridt er at aftale et slags signal, der indikerer, hvornår diskussioner er for voldsomme. Det kunne fx være Star Trek-vulcanernes "live long and prosper"-håndtegn. Generelt bør I (hvis nødvendigt, og det er det meget ofte) åbent aftale, hvordan I taler sammen. Dette er især vigtigt i situationer, hvor en studerende i jeres gruppe får konstruktiv kritik af jer andre. Den studerende, der modtager kritikken, skal forholde sig professionelt og være i stand til at modtage kritikken uden at lade følelser blokere for en god konstruktiv feedback. Så kan man altid tage en faglig diskussion af de enkelte kritikpunkter efterfølgende.

Det gode samarbejde er helt generelt karakteriseret ved følgende: Tillid til og tryghed mellem gruppemedlemmer Megen faglig debat og diskussion Mange forespørgsler om hjælp fra gruppemedlemmer Megen hjælp mellem gruppemedlemmer En evne i gruppen til at lytte til hinandens ideer og udfordringer Engagement og målrettethed omkring projektet Et fælles ønske om et behageligt arbejdsklima.

Hvad nu, hvis man ikke kan nå sine opgaver? Alle medlemmer af jeres gruppe bør have tillid til, at I hver især lægger en passende arbejdsindsats i projektet. Hvis et gruppemedlem ikke kan nå at udføre en aftalt opgave, er det meget vigtigt så hurtigt som muligt (og inden deadline) at fortælle dette til hele gruppen. Hvis årsagen er, at der ikke er tid, fordi gruppemedlemmet fx akut skal passe en syg moster, så kan I andre måske træde til og opgaven alligevel nås. Hvis årsagen er, at opgaven tog længere tid end først antaget, eller at opgaven er for svær for gruppemedlemmet at løse, må resten af gruppen træde til for at hjælpe. Opgaver er ofte sværere end antaget, og ansvaret for at løse en overraskende svær opgave påhviler ikke det enkelte gruppemedlem, men derimod jeres gruppe som helhed. Det kræver tryghed at turde fortælle, at man ikke kan løse en aftalt opgave. Det er hele jeres gruppes ansvar at sikre et arbejdsmiljø, hvor I hver især tør fortælle jeres gruppekammerater, at en opgave er for svær, og at I har brug for hjælp.

Håndtering af konflikter i projektgruppen projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Konflikter og åbenlys utilfredshed er ubehageligt. Derfor får konflikter i jeres projektgruppe ofte lov at ulme og vokse sig store, inden I får håndteret dem. Når I først begynder åbent at tale om en konflikt, så har konflikten måske allerede vokset sig så stor, at I må inddrage jeres vejleder. For at undgå store konflikter bør I løbende adressere de små irritationsmomenter, der kun udgør små bølgeskvulp på overfladen. Det er disse bølgeskvulp, der kan udvikle sig til ubehagelige og frustrerende konflikter. Denne udvikling undgår I, hvis I taler om konflikterne, når de er små. En konkret metode til at undgå fremtidige konflikter er at indføre en paragraf i jeres gruppekontrakt, der beskriver, at gruppen hver uge eksplicit skal adressere aktuelle bølgeskvulp. Selvom metoden kan virke pedantisk ("Hallo, vi er jo ikke 7 år gamle!"), så er den et effektivt forsvar mod store konflikter. I nogle tilfælde kan det være nødvendigt ligefrem at fremprovokere en diskussion af bølgeskvulp, fx ved at nedfælde i gruppekontrakten, at alle gruppemedlemmer ved et ugentligt gruppemøde nævner én ting, de oplever som et irritationsmoment. Dette er især væsentligt i (a) den første måned af et projektforløb, hvor linjerne for samarbejdet (eksplicit eller implicit) fastlægges, og (b) i de arbejdstunge uger op til aflevering, hvor presset er stort, og chancen for konflikter derfor er høj.

En lille opmuntring til jer, der er midt i konflikten En konflikt er ikke kun slem. Det største enkeltstående spring i jeres projektkompetencer ligger ofte i jeres første store konflikt. Fordi frustrationerne i den første store konflikt er så store, så står det dig efterfølgende fuldkommen klart, hvad du absolut vil undgå de kommende semestre. Oplevelsen og den afledte læring tager du med dig gennem hele karrieren.

Typiske årsager til konflikter Der er mange årsager til konflikter, men ofte er problemets kerne forskelle imellem gruppemedlemmers engagement, arbejdsindsats, grundlæggende faglige evner og opfattelser af projektets faglige problem og retning.

Forskelle i engagement og arbejdsindsats Hvis en medstuderende ikke udviser seriøsitet og leverer en ordentlig arbejdsindsats, så adressér problemet eksplicit ("Vi synes ikke, din arbejdsindsats er stor nok"). Diskuter med hinanden, hvad I forventer af hinanden. Beskriv så eksplicit som muligt, hvilken

minimumsindsats I forventer af hinanden, for at jeres gruppe kan fungere uden frustrationer hos hverken de overengagerede, de middelengagerede og de knap så engagerede. Hvis en projektgruppe mener, at et enkelt medlem over en længere periode ikke leverer det engagement og den arbejdsindsats, som resten af gruppen forventer, så tal med vejleder. Vejleder taler så efterfølgende med alle parter i projektgruppen for at få et helhedsbillede. Hvis vejleder mener, at det problematiske gruppemedlems adfærd er over minimumsniveauet for at bestå projektkurset, kan vejleder kræve, at I løser problemet internt i jeres gruppe. En oplagt mulighed er at organisere arbejdet lidt anderledes. For eksempel kunne den studerende, der lægger en minimal, men dog acceptabel indsats, få en række afgrænsede opgaver med faste deadlines. Hvis vejleder mener, at gruppemedlemmets adfærd er under minimumsniveauet for at bestå projektkurset, vil vejleder kræve en ændret adfærd. Som regel giver vejleder en studerende en sidste chance for at udvise ændret adfærd. Så lover den medstuderende som regel bod og bedring, og hvis han eller hun ændrer adfærd, så er problemet løst. Gør han eller hun ikke, så kan der ske ændringer i gruppesammensætningen. For eksempel at den ene studerende fortsætter projektkurset som sin egen gruppe (evt. med et reduceret projektomfang). Et senere afsnit i kapitlet beskriver situationer, hvor forskelle i engagement leder til ønsker om at smide en medstuderende ud af gruppen.

Forskelle i gruppemedlemmers faglige evner Forskelle i faglige evner bør principielt ikke være et problem. En af grundtankerne bag projektarbejde er, at I hjælper hinanden med arbejdet. På denne måde bliver alle fagligt stærkere, uanset udgangspunkt. Hvis I som projektgruppe alligevel opfatter en eller to fagligt svage studerende som et problem, må I organisere jer ud af problemet ved fx at lade de fagligt svage studerende agere en slags underleverandør til de fagligt stærke, der kvalitetssikrer arbejdet. På den måde bidrager I alle til jeres færdige arbejde. En vejleder tillader som regel aldrig, at forskelle i faglige evner leder til opsplitning af en projektgruppe. Vejleder vil i stedet give gruppen point for at hjælpe de fagligt svage studerende med at gennemføre projektkurset. Husk, at det hjælper ens egen læring at forklare et komplekst emne til en studiekammerat. På nogle projektkurser indgår gruppens organisering, samarbejde og konflikthåndtering som en fast del af bedømmelsesgrundlaget. Der er altså point at hente, hvis I demonstrerer, hvordan I dygtigt håndterer forskelle i faglige evner. Forskelle i faglige evner mellem gruppemedlemmer er (som så mange andre forskelle) et vilkår for jeres gruppe. Se det ikke som et problem, men som en lærerig udfordring. Glæd jer over disse muligheder for at udvikle jer selv som individ, der lærer evner til et senere

arbejdsliv.

Forskelle i opfattelsen af projektets faglige indhold og retning Det sker, at der er forskelle i opfattelsen af, hvad et projekt bør handle om, eller hvordan det skal gennemføres. Problemet i en projektgruppe bunder som regel i en faglig diskussion, som I bør tage op med vejleder. Vejleder kan deltage i diskussionen, og oftest bliver problemet løst direkte på mødet, idet vejleder typisk har en holdning til problemet (og typisk har haft samme diskussion før, mange gange). En risiko er, at de enkelte gruppemedlemmer fortolker vejleders holdning på en måde, så vejleders udsagn fremstår som et argument for netop deres egen opfattelse af, hvad der er rigtigt. Lad os sige, at person A har opfattelsen X, og person B har opfattelsen Y. Person A hører, hvad vejleder siger, og anvender de dele af vejleders udsagn, der støtter opfattelsen X. Person B hører også, hvad vejleder siger, og anvender de dele af vejleders udsagn, der støtter opfattelsen Y. Dette kan nødvendiggøre endnu et vejledermøde til opklaring. For at undgå denne situation, så stil konkrete spørgsmål til vejleder, og nævn, at I har diskuteret problemet længe forud for mødet, og at I sidder fast og ikke kan komme videre. På den måde minimerer I risikoen for, at vejleder blot siger: "Det var da en god faglig diskussion. Fortsæt endelig, og fortæl, hvad I finder ud af." Mere ekstreme tilfælde af forskellige opfattelser, hvor enkeltpersoner ikke accepterer den øvrige gruppes ønsker efter vejleders indblanding, kan resultere i, at gruppen deles i to, der går hver sin vej.

De helt store konflikter Det sker (heldigvis kun sjældent), at en projektgruppes samarbejde falder helt til jorden. Forestil jer en situation, hvor ingen i en projektgruppe kan samarbejde godt, der kastes med mudder, og til de få gruppemøder, der trods alt afholdes, fyres bandeord og personlige fornærmelser af. At en sådan gruppe holder sammen de følgende semestre, er nok tvivlsomt, men på det aktuelle semester skal gruppen aflevere en projektrapport, der gerne skal bestå eksamen. Den gode nyhed er, at selv en sådan situation kan reddes. Men gruppen skal påbegynde opbygningen af tryghed og tillid fra bunden. En effektiv måde er at starte med at tale sammen to studerende ad gangen. Ulla taler en halv time med Frank, Benny med Inga og Niels med Susanne. Fordi det kun er to personer, der taler sammen, vil disse samtaler helt automatisk foregå på et mere sobert og ikke-personligt grundlag. I starten vil samtalerne sandsynligvis bestå af en del af bagtalelse og luftning af irritationer. Men langsomt begynder topersonersgrupperne at tale om løsninger, og irritationer afløses af forståelse for andres situationer. De enkelte

gruppemedlemmer begynder at forstå hinanden langt bedre, bl.a. motivationen for den adfærd, som ligger til grund for situationen. Med lidt held ender samtalerne med en række krav til det fremtidige arbejde. Efter første runde af samtaler skifter gruppemedlemmerne gruppe til anden runde (igen på en halv time). Efter denne og evt. en tredje runde sætter hele gruppen sig sammen og begynder at tale sammen igen. Herfra går det fremad, og gruppen kan begynde at se lyset for enden af tunnelen. Det kan være, at vejleder inddrages i processen, men nøglen til tillidsopbygningen findes i samtaler på tomandshånd.

At smide en medstuderende ud af gruppen Det mest udbredte problem, som vejledere indblandes i, er, når én studerende i projektgruppen ikke udviser den adfærd, som resten af gruppen mener er den rette adfærd. Gruppen har måske endda udarbejdet og underskrevet en gruppekontrakt, der fortæller, at den ene medstuderendes adfærd er uacceptabel. At én studerende ikke yder den rette indsats, er et stort problem, hvis gruppen har en størrelse, hvor der er behov for alle mands indsats for at aflevere et godt projekt. Undervisere prøver som regel at matche projektopgavernes omfang med størrelsen på projektgrupperne, så det er ikke ualmindeligt, at en medstuderendes manglende indsats er et reelt ressourceproblem. Konsekvenserne ses tit i projektrapporters manglende korrekturskrivning, bilagshenvisninger og andre afsluttende opgaver. Hvis en gruppe består af fem personer, men projektet kan gennemføres med helt ned til tre personer, så handler problemet ikke om ressourcer, men om enten uretfærdighed eller mangel på læring hos den problematiske studerende. At den problematiske studerende sandsynligvis ikke lærer kursets indhold, er resten af projektgruppen som regel ligeglad med. Det virkelige problem er uretfærdighed. Gruppen finder det ikke rimeligt, at én studerende består projektkurset med en ringere indsats end resten af gruppen. Hvis gruppen inddrager vejleder tidligt på semestret, er det første skridt som regel, at vejleder beder gruppen tage problemet op til næstkommende gruppemøde og så giver den studerende et par uger til at udvise en ændret adfærd. Hvis dette ikke sker, tager vejleder måske en "kammeratlig samtale" med den studerende, og efter denne samtale får den studerende en sidste chance. Til slut er der to udveje: 1. Vejleder deler formelt gruppen ind i to nye grupper, hvor den problematiske studerende udgør sin egen gruppe. Alt materiale, der er produceret indtil gruppeadskillelsesdatoen, tilhører begge grupper, så de studerende må sørge for, at begge grupper får kopier af alt materiale (også elektronisk materiale).

2. Vejleder kan i sjældnere tilfælde mene, at den adfærd, som projektgruppen forventer af hinanden, ikke er rimelig (fx hvis det forventes, at alle arbejder mere, end hvad rimeligt er, eller at alle skal være til rådighed i weekender). I disse tilfælde kan vejleder agere mægler i forhandlingen om en ny kontrakt, der udgør et kompromis inden for projektkursets rammer (fx den arbejdsbelastning, som ECTSantallet repræsenterer). Hvis vejleder inddrages sent i forløbet, er resultatet oftest, at gruppen må forblive sammen. En vejleder deler næsten aldrig en projektgruppe op, hvis projektperioden blot har to-tre uger til aflevering. Der er undtagelser, fx fysisk eller verbal vold, trusler om vold eller lignende mere ekstreme tilfælde. Dette hører dog heldigvis til sjældenhederne og kan involvere personer højere oppe i universitetets hierarki. Projekteksamen kan resultere i forskellige karakterer til de enkelte gruppemedlemmer. Ofte er den skriftlige projektrapport blot en del af bedømmelsesgrundlaget. Den enkelte studerendes præstation ved eksamen indgår også. En fantastisk projektrapport ender dog ofte med gode karakterer til alle, fordi eksaminatorerne ikke har så meget at kritisere og spørge ind til ved eksamen. Projekter, der eksplicit noterer, hvilke studerende der har forfattet hvilke afsnit i projektrapporten, hører til sjældenhederne på tekniske uddannelser, fordi skrivekunsten i sig selv ikke vægter så tungt som i andre faglige felter.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

På nogle uddannelser er det muligt for jer selv at vælge eller ønske vejleder til jeres projekt. Spørgsmålet er så, hvilken underviser der er den rette. Som regel er den rette vejleder den person, der underviser i det kursus, der kommer fagligt tættest på projektets problemfelt. Hvis der er flere undervisere, der er fagligt kompetente, handler valget af vejleder ofte om, hvilken underviser der er mest tilgængelig, og hvilken underviser I kender godt og er trygge ved. Hvis I har en underviser, der har den faglige kompetence, men ikke tid, så vælg en anden underviser som vejleder. Udnyt dog fortsat den første undervisers faglighed ved at aftale ét møde i løbet af projektperioden til faglig sparring. På de fleste uddannelser står hele lektorkorpset (i hvert fald principielt) til jeres rådighed for hjælp og faglig sparring. Vejledning er vigtigst i starten af projektet, hvor I skal have udstukket retningen for projektet. Vejleder kan her hjælpe jer med at afkode den situation hos virksomheden, der leder frem til problemformuleringen, og hjælpe jer med at sikre, at problemformuleringen omhandler et rigtigt problem (se kapitel 3 om, hvordan man sikrer sig et rigtigt problem og nedfælder en problemformulering). Ofte vil vejleder i løbet af det første vejledermøde aktivt "afsøge terrænet" for at finde det egentlige problem og den deraf afledte problemformulering. Terrænet udgøres af 1) den virksomhedssituation, I befinder jer i, 2) de informationer, I har om problemfeltet, og 3) virksomhedens ønsker til, hvad projektet skal handle om. Ofte starter sådanne vejledningssamtaler med, at en virksomhed ønsker en ændring eller optimering af noget uden at specificere, hvad der bliver bedre af dette. En virksomhed ønsker fx "et optimeret vareflow" eller "en redesignet motorkomponent". Vejleder vil naturligt spørge ind til, hvad formålet er. Hvis et vareflow skal optimeres, er målet så reducerede omkostninger, at øge leveringsservice eller noget tredje? Hvis en komponent skal redesignes, er formålet så at reducere produktionsomkostninger, at øge holdbarheden eller noget tredje? Disse spørgsmål skal hurtigst muligt afklares, og denne afklaring er ofte på dagsordenen ved vejledermøder tidligt i et projektforløb. I løbet af projektperioden foregår vejledning enten på vejledermøder, i telefonsamtaler eller gennem skriftlig dialog. Vejledning kan handle om tekststykker, I har sendt vejleder. Hvor store tekststykker en vejleder vil give feedback på, varierer fra uddannelse til uddannelse. Hvis I sender tekststykker på mere end 7-8 sider, bør I skrive til vejleder, hvad I konkret vil have feedback på. Hvis I ikke konkretiserer, giver vejleder måske feedback, der ikke rammer det, I har svært ved at løse. Vejleder ser kun det aktuelle tekststykke, som I har sendt, og giver derfor feedback ud fra tekststykket og fra, hvad vejleder tror, det øvrige projekt handler om. Derfor kan feedbacken forekomme tilfældig.

Undgå generelle spørgsmål til vejleder som fx: "Kan du ikke lige skimme dette og se, om det giver mening?" Det kan vejleder godt, men hvorvidt tekststykket giver mening, hænger helt og aldeles sammen med, hvad det øvrige projekt handler om. Derfor fortæl vejleder, hvad I ønsker vejledning om, når I sender et tekststykke.

Gode diskussionsemner til vejledningsmøder Ofte diskuterede emner til vejledermøder er problemanalyse, problemformulering, metode- og litteraturvalg, dataindsamling, analyse samt løsningsdesign. Disse emner er de vigtigste i projektet, og elementerne skal hænge sammen. Elementernes sammenhæng udgør projektets "røde tråd". Eksempel: Hvis metodevalget ikke passer til problemformuleringen, mangler den røde tråd. Typiske spørgsmål, der er gode at diskutere med vejleder, er: Hvad er problemet, som projektet skal løse? Hvordan argumenterer vi for valget af problemformulering? Hvordan skal vi bruge litteratur i projektet, og hvor finder vi denne litteratur? Hvordan argumenterer vi for vores valg af metoder, litteratur og data? Hvordan sikrer vi os de nødvendige data og nok af dem? Hvilke redskaber og værktøjer skal vi bruge til at indsamle og analysere data med? Hvordan sikrer vi overensstemmelse mellem analyser og løsningsdesign? Løser vores løsning faktisk projektets problem? Hvordan kan vi vurdere løsningens økonomiske præstation? Hvad er en god implementeringsplan? Denne række spørgsmål er 'klassikerne' til vejledningsmøder. Ud over klassikerne kommer en række praktiske spørgsmål om eksamensafholdelse, afleveringsdato, sidetal og indsamling af litteratur på skolens digitale bibliotek.

Kritisk refleksion over vejleders ideer Vejleder kan og må heller ikke formelt godkende hverken hele projektet eller udsnit af projektet i løbet af projektperioden. Det er en meget typisk misforståelse hos en projektgruppe, at vejleder kan godkende et tekststykke. En godkendelse betyder implicit, at vejleder til eksamen ikke må kritisere eller stille spørgsmål til tekststykket. Klagesager lyder ofte således: "Vores vejleder kritiserede et afsnit til eksamen, som han tidligere har godkendt" eller "Til eksamen fik vi kritik af et vigtigt afsnit. Men den kritik kunne han jo bare have givet os, da han var vejleder". Det er vigtigt at forstå, at den endelige rapport ikke er vejleders ansvar og heller ikke medansvar. Principielt kan vejleder komme med en ide under et vejledermøde og kritisere selvsamme ide ved eksamensbordet. Vejleder møder kun projektet sporadisk i løbet af semestret og "skyder fra hoften" til vejledningsmøder baseret på de informationer, som I giver vejleder. Fordi vejleder er

erfaren, rammer disse skud fra hoften ofte plet, men ikke altid. Under og efter vejledningsmøder er det derfor jeres ansvar som projektgruppe kritisk at reflektere over vejleders ideer for at vurdere deres relevans for netop jeres projekt. Vejleder kan ikke forhåndsgodkende afsnit, heller ikke problemformuleringen. Vejleder nikker ofte til problemformuleringen og siger, at den er god, at "den virker", eller lignende. Men dette sker i lyset af vejleders begrænsede forståelse af projektet. Når rapporten afleveres, kan en problemformulering, der for to måneder siden var god, vise sig slet ikke at passe med det resterende projekt (fx fordi projektet har taget en drejning, uden at problemformuleringen er opdateret).

Vejleder bliver til eksaminator Når projektet er afleveret, er vejleder ikke længere vejleder. Vejleder er nu blot en tilfældig underviser på uddannelsen, der senere skal eksaminere jer sammen med en censor. Det betyder ikke, at eks-vejlederen ikke kan besvare spørgsmål omkring, hvordan en god præsentation til eksamen er, men dette foregår i rollen som en tilfældig underviser på studiet. Med andre ord bør I ikke forvente detaljeret vejledning om eksamen, men holde jer til praktiske spørgsmål a la "Hvor lang tid har vi til præsentationen?" og "Bliver vi eksamineret i samme rum?".

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Opsummering

I dette kapitel har du lært, hvordan projektgrupper dannes, og om de dynamikker, der er i jeres klasse omkring gruppedannelsen. Du har også lært, hvordan din indsats og engagement i studiets første tid påvirker dine muligheder i fremtidige gruppedannelsesprocesser på din uddannelse. Kapitlet beskriver, hvordan en gruppekontrakt kan understøtte engagement, samarbejde og kommunikation i jeres projektgruppe. Kapitlet beskriver ligeledes det gode indhold i en gruppekontrakt, og hvordan I kan forebygge konflikter gennem en aktiv og løbende brug af gruppekontrakten. For at sikre det bedst mulige samarbejde bør I holde minimum ét møde per uge, hvor I er fysisk til stede i samme rum. Nøglen til det gode samarbejde i jeres projektgruppe er tryghed og tillid, og denne opbygges bedst gennem tilstedeværelse, at holde aftaler og at være ærlig omkring egne evner og behov for hjælp fra den øvrige projektgruppe. Kapitlet gør det klart, at I bør inddrage jeres vejleder i projektets store valg og spørgsmål, og lister de mest oplagte temaer op for vejledning.

Kapitel 10. Det gode virksomhedssamarbejde projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I dette kapitel lærer du: Hvordan du identificerer en virksomhed at samarbejde med, og hvordan I sælger jeres projektsamarbejde til virksomheden Hvordan den indledende fase i samarbejdet fungerer, fx hvordan I når frem til en afgrænsning af projektet og udfolder kredsen af relevante personer i virksomheden Om det løbende samarbejde med virksomheden, fx dataindsamling og involvering af virksomhedens medarbejdere i jeres analysearbejde og løsningsdesign Hvordan I sikrer jer adgang til data og mulighed for involvering af virksomhedens medarbejdere At nøglen til det gode samarbejde ofte ligger i tilstedeværelse i virksomheden og muligheden for løbende at sparre med medarbejdere omkring analyse, design og implementering Om typiske faldgruber i virksomhedssamarbejdet, fx at virksomheden mister interessen, en ekstraordinært engageret chef, eller at virksomheden hele tiden forventer mere og mere af jer, selvom problemformuleringen er på plads. Dette kapitel beskriver, hvordan I kan sikre et godt samarbejde med virksomheden fra start til slut i et projektforløb. Kapitlet fortæller, hvordan I sikrer, at både I selv og virksomheden vil være glade og tilfredse med projekts resultater. Kapitlet beskriver først, hvordan I kan finde den rette virksomhed til projektet, og dernæst den indledende fase i samarbejdet, herunder aftale om problemformulering og om, hvordan I allerede fra første færd kan indgå aftaler om dataindsamling og inddragelse af virksomhedens medarbejdere. Det løbende samarbejde og den gode afslutning på samarbejdet beskrives også. Til sidst beskriver kapitlet, hvordan I kan sikre jer, at virksomheden føler ejerskab til jeres løsninger, og hvordan I kan håndtere pludselige ændringer i virksomhedens engagement og andre faldgruber i samarbejdet.

Identifikation af den rigtige virksomhed projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Mange studerende har et netværk, de kan trække på, når de skal finde en relevant virksomhed at samarbejde med. Dette er særligt tilfældet sent på uddannelsen, hvor de fleste frie projekter er placeret. Frie projekter er projekter, hvor I som studerende selv vælger virksomhed, problem og metode. De projektgrupper, der ikke har en virksomhed i netværket, har en opgave i at identificere en virksomhed, der gerne vil samarbejde om et projekt. At finde en virksomhed er principielt nemt nok. Man googler bare løs. Det er sværere at finde de personer, som kunne være potentielle kontaktpersoner for jer i et projektsamarbejde. Det er disse personer, der kan tage stilling til, om et samarbejde med jer er relevant for virksomheden. I kan møde disse personer ved fx at deltage i arrangementer. Her er en række eksempler: Faglige messer og konferencer Seminarer i fagforeninger (hos fx Ingeniørforeningen i Danmark) Arrangementer hos dimittendforeninger (fx Maskinmestrenes forening eller De Studerendes Erhvervskontakt) Formelle faglige netværk (fx IDA Polymer eller IDA Tele) Faglige selskaber (fx Effektivitet.dk). Når I først har fundet de rette personer, så kommer opgaven at "sælge" jeres projektsamarbejde til virksomheden. Det optimale er på forhånd at vide, hvilket fagligt tema en virksomhed gerne vil bruge deres medarbejderes tid på. Så kan I foreslå præcis det tema og sikre jer et samarbejde. Man kan dog som udgangspunkt ikke vide, hvad en virksomhed har af ønsker til et tema. Det kan være temaer, som virksomheden måske ikke engang selv har tænkt kunne være interessant. Et par gode tips til denne salgsopgave er: Øg jeres viden om den pågældende virksomhed Med udgangspunkt i jeres viden udarbejd forslag til, hvad projektet konkret kan handle om. Viden kan bl.a. hentes på nettet og i medierne (fx artikler om virksomheden i Børsen eller Erhvervsbladet). Det er fra tid til anden også muligt at møde en medarbejder fra en virksomhed på en konference, en messe, et fagforeningsarrangement eller et arrangement gennem en faglig interesseorganisation. Når I som gruppe skal sælge jeres projektide til virksomheden, er målet at få modtageren af jeres forslag til at tænke noget a la: "Hmm … tjo … øh, nå, ja! Susanne arbejder da på sådan og sådan … Det kunne I da nok godt hjælpe med."

Virksomheder siger tit, at de foretrækker, når de studerende ved, hvad de gerne vil arbejde med. Når I foreslår et tema, så sigt derfor ikke for bredt (Sig fx ikke: "Vi er interesseret i hvad som helst inden for maskinudvikling, bare I gerne vil samarbejde."). Omvendt er risikoen for ikke at ramme et fagligt tema, som virksomheden har interesse i, stor, hvis I søger et samarbejde omkring meget fokuserede emner. (Sig fx ikke: "Vi vil arbejde med 3D-print af emner af legeringstypen EN AW 2024, og vi er ikke interesseret i andet."). En god strategi er at foreslå to-tre faglige temaer og så sende disse forslag til en række relevante virksomheder. Skriv gerne, at temaer, der er "relateret til de tre forslag", også er aktuelle. På den måde får I faktisk langt flere faglige temaer i spil, uden at virksomhederne synes, at I skyder med spredehagl.

Den indledende fase i virksomhedssamarbejdet projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Det allerførste møde, hvor I sidder til bords med virksomhedens kontaktperson, handler som regel om projektets tema og en afgrænsning heraf. Inden mødet har I typisk haft en kortere dialog med virksomheden (fx en mailkorrespondance), og I skal nu enes om en problemstilling, som projektet skal løse. Derudover vil mødet typisk omhandle de praktiske spørgsmål omkring fx dataindsamling, møder med relevante personer, og eventuelt om I skal have en fast, fysisk plads hos virksomheden under projektperioden. Ud over disse håndgribelige ting, der skal aftales, er der også en række implicitte mål med det første møde, nemlig at I og virksomheden ser hinanden an, tester "kemien" og skaber en fælles forståelse af, hvordan projektet kan opfylde behov hos både jer og virksomheden. Efter mødet med virksomheden mødes I med jeres vejleder og fremlægger, hvilken problemstilling I vil arbejde med, og måske også hvordan problemformuleringen kan lyde. Ofte møder vejleder en række motiverede studerende, der er klar til at kaste sig ud i projektet. Problemstillingen er på dette tidlige tidspunkt typisk vag og uklar. For eksempel kan et udkast til en problemformulering lyde: "Vi skal optimere et flow" eller "Vi skal forbedre kvaliteten af et produkt". Vejleder vil derfor ofte udfordre de studerende på problemstillingens fokus og specificitet. Hvis problemstillingen handler om optimering af flow, vil vejleder fx gerne vide, hvad det er for en variabel, der skal optimeres, og til hvilket formål. På det næste møde med virksomheden er formålet ofte at få accept af den problemformulering, I har valgt efter mødet med vejleder. Det er vigtigt at være opmærksom på, at virksomheden ofte vil sætte sit eget præg på problemformuleringen. Ofte vil virksomheden gerne udvide problemformuleringen til at inkludere flere variable ("Kan I ikke også optimere dette og dette?"). Virksomhedens ønsker om at inkludere flere ting i problemformuleringen harmonerer som regel dårligt med universitets krav om en fokuseret problemformulering, der ikke stikker i mange retninger og lige tager emne A, B og C med i projektet. Det er jeres opgave at få de to holdninger til at mødes, så alle bliver glade. De første møder med virksomheden slutter oftest med store smil og håndslag om, at projektet skal gennemføres ("Det bliver virkelig godt, det her!"). Den gode stemning fra mødet og den gode følelse, virksomhedens medarbejdere har omkring projektet, fortsætter typisk umiddelbart efter møderne, men efter nogle uger begynder "hverdagen". Virksomhedens medarbejdere, der har travlt med deres øvrige arbejde, har begrænset tid til og engagement i jeres projekt.

Netop fordi de første møder sker i god stemning, er møderne en unik mulighed for jer. Det er nemlig her, at dørene i virksomheden står åbne. Det er her, I skal indgå så mange konkrete aftaler som muligt og forsøge at få adgang til andre medarbejdere end kontaktpersonen. I skal forsøge at udfolde billedet af virksomheden allerede på første møde, således at det bliver tydeligt for jer, hvem i virksomheden der kan og bør bidrage til projektet. Spørg aktivt om muligheden for selv at kontakte de øvrige medarbejdere, der er relevante for projektet. Kontaktpersonen skal naturligvis have mulighed for at varsko sine kolleger om jeres forespørgsler, men ellers er det bedste, at kontaktpersonen ikke skal agere mellemmand i kommunikationen i hele projektperioden.

Eksempel på, hvordan man udfolder billedet af en virksomhed i løbet af den første tid To studerende på maskiningeniøruddannelsen har været i en maildialog om et afgangsprojekt med en producent af armaturer til køkkener og badeværelser. Armaturerne er lavet af stål. På overfladen af stålet lægges et tyndt lag zink, der gør armaturerne glatte og pæne og sikrer, at armaturerne kan tåle fugt uden at ruste. De studerendes problemformulering handler om at redesigne et af virksomhedens armaturer, så laget af zink bliver mere jævnt. Virksomheden kasserer nemlig for mange armaturer som følge af en ujævn (grim) overflade. Overfladebehandlingen foregår hos en leverandør. På første møde med virksomheden diskuterer de to studerende den konkrete problemstilling med virksomhedens designchef, der er de studerendes kontaktperson. Mødet forløber godt, og sammen med designchefen jonglerer de studerende med forskellige ideer til løsning af problemet. På mødet bruger de to studerende en del energi på at afsøge, hvilke personer i og uden for virksomheden der skal inddrages, for at de kan redesigne armaturet på den bedst mulige måde. I samarbejde med designchefen udarbejder de en liste over relevante personer, som bør bidrage til projektet. Blandt personerne er virksomhedens produktionschef, teamlederen i armaturproduktionsafdelingen, virksomhedens kvalitetschef og personer fra marketing og salg, der kender kundernes præferencer. Ud over personer i virksomheden skriver de studerende en række eksterne personer på listen: konsulenter inden for badeværelsesinstallationer, leverandøren af overfladebehandlingen, leverandøren af armaturmaterialet og de myndigheder, der regulerer sikkerhed i badeværelsesinstallationer. Under mødet får de studerende kontaktoplysninger på alle personerne, og designchefen lover at kontakte personerne på listen, så de ikke bliver overraskede over at bliver kontaktet af 'to tilfældige studerende'.

Eksemplet viser, at kredsen af projektrelevante personer ikke altid kun er personer inden for virksomheden, men også uden for. I eksemplet udfolder de to studerende således virksomheden i en længere række personer, der inkluderer både leverandører og offentlige myndigheder. Figur 10.1 illustrerer udfoldelsen.

Figur 10.1. Udfoldet billede af relevante personer og organisationer i projekt om redesign af armaturer

Denne type udfoldelse er typisk nemmere at få på plads under de første møder med virksomheden, fordi kontaktpersonens engagement her ofte er på sit højeste.

Aftale om problemformulering projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Efter to-tre møder har både I og virksomhed (og også vejleder) en interesse i at få en problemformulering nedfældet. I den periode, hvor de første møder pågår, er jeres problemanalyse i fuld gang (se kapitel 2). Kapitel 3 fortæller, at problemformuleringen beskriver, hvordan projektet enten skal forbedre noget eksisterende eller designe noget nyt fra bunden. I projekter, der forbedrer noget eksisterende, bør problemformuleringen handle om at forbedre én kvantificerbar variabel (fx holdbarhed, hastighed, omkostninger eller ydelse). Når I taler med virksomheden om problemformuleringen, skal I derfor fokusere på følgende to elementer: 1. Hvilken variabel skal projektet forbedre? 2. Under hvilke forudsætninger skal variablen forbedres? Spørgsmålene lyder umiddelbart simple, men at komme frem til denne ene variabel kan være en ganske kompleks opgave. Fordelen ved netop disse to spørgsmål er, at dialogen med virksomheden hurtigt fokuseres. I projekter, der handler om at designe noget nyt fra bunden, er opgaven en anden. Opgaven er her at beskrive det behov, virksomheden har, og måske også en ide eller løse skitser af den løsning, der kan opfylde behovet. Løsningen kan fx være en bygning, et produkt, en maskine eller en softwareløsning. Når I taler med virksomheden om problemformuleringen, så er følgende spørgsmål gode at afklare: 1. Hvad er det basale behov, som løsningen skal fylde? 2. Hvem skal bruge løsningen? 3. Hvordan skal løsningen bruges? 4. Hvilke krav til løsningen fra brugerne er allerede kendte? 5. Hvilke krav er der til løsningen fra virksomheden? 6. Er der krav til løsningen fra andre organisationer, fx offentlige myndigheder? Alle disse spørgsmål kan som regel ikke besvares fyldestgørende på dette tidlige stadie i projektet, men I kan fint påbegynde dialogen om spørgsmålene, når I aftaler problemformulering. I får brug for svarene på disse spørgsmål i løbet af projektet.

Det løbende samarbejde projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Et projekt på en uddannelse har ofte en varighed af et helt semester fraregnet eksamensperiode, dvs. omkring tre til fem måneder fra igangsættelse til aflevering. Efter de første 4-6 uger har I typisk afgrænset projektet, nedfældet problemformuleringen, læst relevant litteratur og arbejdet på metode til dataindsamling og analyse. Herefter begynder dataindsamlingen, analysearbejdet, løsningsdesign og implementering, hvorefter projektet afsluttes. Figur 10.2 er en eksemplarisk oversigt over de væsentligste interaktioner mellem jer og virksomheden (projektets "højtider") i projektperioden. De tidligere dele af kapitlet har beskrevet de to første interaktioner, og de følgende afsnit beskriver de næste interaktioner. Projektafslutningsmødet behandles i et særskilt afsnit, efter at vi har set på, hvordan virksomhedens engagement etableres og fastholdes over hele projektperioden.

Figur 10.2. De væsentligste interaktioner med virksomheden

Dataindsamlingen Ca. 4-6 uger efter projektopstart er I nået så langt med jeres arbejde, at der er behov for at indsamle data. Indsamlingen af data i virksomheden begynder ofte med en stor første runde efterfulgt af en række opfølgende dataindsamlinger. I projekter, hvor I arbejder på skolen, udgør den første store dataindsamling det første tidspunkt, hvor I har brug for tid med virksomhedens medarbejdere.

Enighed om analyseresultater Efter den første store runde dataindsamling og samtidigt med de opfølgende dataindsamlinger arbejder I på jeres analyse. Analysearbejdet resulterer i en række analyseresultater. Jeres opgave er løbende at involvere medarbejderne for at sikre det bedst mulige grundlag for virksomhedens accept af jeres analyseresultater. Hvis virksomheden er enig i jeres arbejde, så er sandsynligheden for at sikre virksomhedens

ejerskab til projektets løsninger større. Ejerskab er forudsætningen for implementering af løsninger, og gode løsninger, der faktisk implementeres, er målet for frie tekniske projekter. En god ide til sikring af virksomhedens accept er at indkalde til en "analyseworkshop", hvor I diskuterer jeres analyseresultater. Se et eksempel herunder.

Eksempel på en workshop om analyseresultater En projektgruppe på bygningsingeniøruddannelsen er nået frem til, at der er to primære årsager til, at en bygningsfacade slår revner. På en workshop deler projektgruppen analyseresultaterne med virksomhedens medarbejdere for at sikre sig, at der er enighed om årsagerne. Virksomhedens medarbejderne skal være enige i, at data peger på netop de to årsager, som de studerende har identificeret. Hvis der er enighed herom, kan projektgruppen begynde at designe en løsning, der eliminerer årsagerne.

Design af løsninger Processen at designe løsninger er ofte iterativ og kan føles lidt rodet. Gode ideer opstår ikke altid efter planen, og inspiration kan komme fra mange kilder. Virksomhedens medarbejdere er oplagte sparringspartnere i udviklingen af gode løsninger. Måske har en medarbejder allerede tænkt over nogle gode løsningsforslag, som I kan inddrage i jeres arbejde (tænk grundigt over, om løsningerne passer med jeres analyseresultater). Når løsningen, der kan bestå af en række selvstændige elementer, er udviklet, er det vigtigt at få virksomhedens accept af løsningen. I kan igen overveje at afslutte løsningsarbejdet med en workshop, hvor virksomheden har mulighed for enten at acceptere løsningen, som den er, eller give konstruktiv feedback og ideer til videreudvikling. Se mere om design af løsning i kapitel 7.

Udarbejdelse af implementeringsplan Når der er enighed mellem jer og virksomheden om løsningen, kan I begynde at udvikle en plan for implementering. Implementeringsplanlægningen giver anledning til igen at involvere virksomheden. Start med at spørge ind til centrale medarbejderes og lederes ideer til implementering, og udarbejd så et samlet forslag til en implementeringsplan i jeres projektgruppe. Afhængigt af implementeringsplanens tyngde i jeres projekt, kan I overveje at afholde en sidste workshop, hvor I sammen med medarbejderne diskuterer jeres forslag til implementering. Er jeres forslag realistisk, og vil planen faktisk resultere i en implementeret løsning?

Hvorvidt implementering af løsningen indgår som læringsmål på projektkurset, afhænger som tidligere nævnt af traditionerne på den enkelte uddannelse. På uddannelser, der handler om at produktudvikle (fx elektronikingeniør), stopper et projekt ofte ved udvikling af løsningen. På andre uddannelser (fx produktionsingeniør) er implementering en integreret del af projektet. Se en liste med punkter i implementeringsplanen i kapitel 8.

Etablering og fastholdelse af virksomhedens engagement Succes med projektet kræver, at samarbejdet med virksomheden fungerer. Her er god planlægning og løbende involvering af virksomhedens medarbejdere central. Det kan forebygge potentielle problemer som fx lange svartider og manglende ejerskab til løsninger.

Sikring af data i god tid og medarbejderes engagement Dataindsamling er en af de aktiviteter, der kræver mest tid og involvering af virksomhedens medarbejdere. Det sker tit, at en projektgruppe venter alt for længe på at få de data, der er behov for. Det sker endda, at et projekt får en lavere vurdering til eksamen på grund af et tyndt datagrundlag forårsaget af lange svartider fra virksomhedens medarbejdere. Det er vigtigt at vide, at virksomhedens medarbejdere konstant foretager prioriteringer af, hvad de skal bruge deres tid på. De prioriterer fx, hvilke mails de vil se igennem, og hvilke de vil svare på. Mails fra studerende rangerer ofte lavt, særligt hvis medarbejderen ikke er tæt involveret i projektet. Den mest effektive måde, I undgår lange svartider på, er at være fysisk til stede i virksomheden. Gør jer selv 'kendte' hos de medarbejdere, der er relevante for jeres projekt. Optimalt er at være fysisk til stede hver dag, at have jeres egen arbejdsplads hos virksomheden og hver dag spise frokost med den afdeling, som jeres projekt er tilknyttet. Denne optimale situation er dog som regel kun mulig på afgangsprojekter. Løsningen for jer, der ikke har jeres daglige gang i virksomheden, er at planlægge i god tid. Medarbejdere skal gerne flere uger i forvejen vide, at de bliver spurgt om interviews, dataudtræk fra ERP-systemer, milepælsmøder og fysiske rundture. Hvis de ved det, er sandsynligheden for hurtige data og positive tilsagn om møder høj. Derfor, når I har lagt jeres projektplan og fx lavet et Gantt-diagram over projektets aktiviteter og tidsforløb, så foretag straks de nødvendige bookinger i medarbejdernes kalendere. Det kan være en rigtig god ide at booke medarbejderne i deres kalendere umiddelbart efter projektets opstartsmøde, mens medarbejderne stadig husker jer. Tre uger senere kan I risikere, at medarbejderne har travlt og ikke prioriterer jeres dataforespørgsler særligt højt.

Hvis I foretager mødeindkaldelser i begyndelsen af projektperioden, er mange ting uklare, og I tænker måske, at det er alt for tidligt ("Vi ved jo ikke engang, hvad vi skal snakke om!"). Husk her, at I kender to ting: (a) I ved, at I skal tale om et eller andet, og (b) umiddelbart før mødet ved I sandsynligvis, hvad dette 'et eller andet' er. Den gyldne regel er her, at det er meget nemmere at aflyse et møde end at få et møde istandsat. Aftal allerede på projektets opstartsmøde med jeres faste kontaktperson, at projektet får brug for fx: fem-seks interviews inden for tre-fire uger en række datadumps ca. fire-fem uger inde i semestret workshops eller større møder om analyse og løsning hhv. to og tre måneder inde i projektperioden et midtvejsmøde midt i projektperioden. Når disse opgaver og møder er booket i kalenderen umiddelbart efter projektstart, er sandsynligheden for lange svartider minimeret kraftigt, og projektets kvalitet beror i mindre grad på virksomhedens hjælp til jer. Samtidig giver rækken af mødebookinger jer faste punkter til jeres Gantt-diagram. Møderne kan fungere som milepæle i jeres plan. Det er især vigtigt at booke virksomhedens medarbejdere i god tid til workshops og beslutningsmøder, hvor flere medarbejdere skal deltage samtidigt. At booke tre-fire medarbejdere inklusive en afdelingsleder til et midtvejsmøde er som regel helt og aldeles umuligt, hvis bookingen sker en uge før, mødet påtænkes afholdt. Bookingen skal gerne ske minimum en måned forinden, idet særligt afdelings- og projektledere ofte har fulde kalendere i den nære fremtid. Det er helt forståeligt at være bekymret for at booke virksomhedens personale til en workshop eller et milepælsmøde, når det stadig er uklart, hvad mødet skal handle om. ("Hvad nu, hvis vi ikke er klar til at holde mødet, når tiden kommer? Så spilder vi jo deres tid!"). Dette er prisværdige tanker, der kommer ud af respekt for medarbejderne og deres tid. Men husk: Hvis I ikke er klar til mødet, så udskyder I mødet til en ny dato længere ude i fremtiden. Dette er en helt naturlig og uproblematisk praksis, som alle virksomhedens medarbejdere er vant til fra deres kolleger og chefer. Når I booker folk i kalenderen i meget god tid, så sæt en overskrift for mødet, og fortæl, at den konkrete dagsorden for mødet bliver tilsendt senere. En overskrift som fx "milepælsmøde", "præsentation af analyseresultater" eller "diskussion af løsningsforslag" er helt fint en måned eller to forud for mødet. Book også dataindsamling i kalenderen hos den medarbejder, der skal hjælpe jer med at skaffe data. Selv hvis der blot er tale om dataudtræk til en Excel-fil. Skriv til medarbejderen to måneder før, at I tillader jer at booke en halv time i medarbejderens kalender til en samtale om de konkrete dataudtræk, projektet har behov for. Det bedste tidspunkt at booke på er umiddelbart efter projektopstartsmødet, hvor projektet stadig er friskt i medarbejdernes hukommelse.

På semesterprojekter, hvor I arbejder på skolen, udgør figur 10.2 et udgangspunkt for at planlægge jeres interaktioner med virksomheden. Selv på afgangsprojekter, hvor I har jeres daglige gang hos virksomheden, er det oftest også nødvendigt i god tid at booke møder med deltagelse af to eller flere personer. Årsagen er, at selv med de bedste intentioner hos virksomheden så udgør jeres projekt en aktivitet, til hvilken virksomheden ikke prioriterer sine egne medarbejdere, men i stedet bruger en gruppe af studerende. Derfor er interaktionerne med jer ikke topprioritet, og jeres eventuelle akutte behov for medarbejdertid kan være svære at opfylde.

Sikring af virksomhedens løbende accept og succes på beslutningsmøder, workshops og vigtige milepæle Resultatet af workshops og milepælsmøder er ofte merarbejde for jer. Det er faktisk ganske almindeligt. Virksomhedens medarbejdere har naturligt en større indsigt i virksomhedens produkter, processer, kultur, kunder, osv. og kan derfor bedre vurdere, om en løsning vil virke, og om den eventuelt har utilsigtede bivirkninger. Workshops giver derfor ofte anledning til redesign af jeres foreslåede løsninger. I jeres projektplan bør I derfor afsætte tid til jeres eget merarbejde efter beslutningsmøder, workshops og vigtige milepæle. I kan dog gøre en del for at øge chancerne for, at virksomheden accepterer jeres arbejde på møderne. Den mest effektive metode er løbende at dele information med de relevante medarbejdere og ledere. I kan fx hver uge støde "tilfældigt" ind i en vigtig medarbejder i elevatoren eller stikke hovedet forbi medarbejderens bord og høre, om der lige er to minutter til rådighed. På den måde sikrer I, at de vigtige personer er fuldt informeret om projektets forløb. Fuldt informerede medarbejdere vil typisk småkede sig lidt til milepælsmøderne og sige "ja, tak" til alle jeres forslag, fordi de er bekendt med både selve forslagene og alle detaljer, forudsætninger og argumenter forud for mødet.

Afslutning af virksomhedssamarbejdet projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Som studerende afslutter I ofte jeres projekt med en eksamination på baggrund af den rapport, I har skrevet. Se mere om eksamen i kapitel 14. Selve virksomhedssamarbejdet afslutter I dog typisk med et møde, hvor I præsenterer løsningen og drøfter implementeringen med de af virksomhedens medarbejdere, der evt. skal overtage implementeringen. For virksomheden afhænger et projekts succes således ikke af, hvor god en rapport I skriver, men at løsningen implementeres og bliver en succes.

Eksempel på et afslutningsmøde En projektgruppe har designet en ny type kabinet til en vaskemaskine. Virksomhedssamarbejdet afsluttes her ved at sikre, at de medarbejdere, der skal teste kabinettets duelighed, forberede produktion og finde leverandører af materiale, har den nødvendige information. Om virksomheden vælger at implementere jeres løsning, handler ikke kun om jeres løsnings kvalitet, men også – og nok i endnu højere grad – om virksomhedens ressourcer (tid og penge). Afslutningsmøder, hvor I overleverer arbejdet til virksomheden, kommer derfor ikke af sig selv. Mødet er kulminationen på jeres løbende involvering af virksomhedens medarbejdere i projektet. Hvorvidt I har haft succes med den løbende involvering, vil nu vise sig. Den måske mest sigende indikator på et projekts succes er, hvorvidt virksomhedens medarbejdere accepterer jeres indkaldelse til projektafslutningsmødet. Det gode projekt kan levere en agenda til dette møde, som medarbejderne kan nikke genkendende til. Hvis medarbejderne løbende er involveret, kender de nemlig både den løsning, projektet har udviklet, de problemer, som løsningen skulle afhjælpe, og planen for løsningens implementering. I de bedste situationer glæder en flok engagerede medarbejdere sig til at overtage implementeringen.

Faldgruber i samarbejdet projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Nøglen til det gode virksomhedssamarbejde er at være i virksomheden til dagligt (fx spise frokost med afdelingen 3-4 gange om ugen). På den måde skaber I relationer til de væsentligste medarbejdere for projektet. Hvis daglig tilstedeværelse ikke kan lade sig gøre, bør I på anden måde gøre jer selv kendte i virksomheden og danne netværk. Gode relationer til medarbejdere skaber adgang til data, til gode ideer, til løsning af problemer og bedre muligheder for at engagere medarbejdere i mødedeltagelse. Løbende at fortælle om projektet til virksomhedens medarbejdere reducerer chancerne for pludselige overraskelser (fx til et møde eller til jeres eksamen). Når I fortæller, at I har fundet frem til en række årsager til et problem, kan det være, at medarbejderen lytter og så fortæller jer, at I har misforstået noget. Det er langt bedre at få denne kritik i løbet af projektperioden end til eksamen. Uanset hvor godt virksomhedssamarbejdet forløber, er der dog en række klassiske faldgruber, man skal være opmærksom på. De følgende afsnit beskriver de klassiske faldgruber og kommer med anbefalinger til, hvordan de håndteres.

Virksomheden mister interessen Det mest almindelige problem er, at virksomheden mister interessen i projektet. Det første tegn er ofte lange svartider på e-mail. Den bedste måde at undgå dette problem er at fastholde det niveau af engagement, der ligger fra starten af projektet. Her er en række gode råd til at holde engagementet: Hold en løbende dialog med virksomheden Undgå for lange pauser mellem møder med virksomheden Lav aftaler med virksomhedens medarbejdere om fx dataindsamling lang tid i forvejen Skriv løbende mails, så medarbejderne ved, at mødet med jer kommer, og de ikke bliver overraskede Skriv gerne løbende statusopdateringer, så I holder gryden i kog Indflet i jeres statusmails de fordele, der er for virksomheden, og hvordan de kan materialiseres. For to-personers afgangsprojekter er den allerbedste måde at undgå, at virksomheden mister interessen, at være i virksomheden til dagligt. Hvis de relevante medarbejdere kender jer, er jeres ve og vel pludselig en grund til at fastholde engagementet i projektet, uagtet om projektet gavner virksomheden som helhed.

Kontaktpersonen vil ikke give adgang til resten af virksomheden Adgang til jeres kontaktpersons kolleger samt eventuelt leverandører, kunder og regulerende myndigheder er vigtigt i nogle tekniske projekter. Hvis jeres kontaktperson selv har initieret projektet uden særlig meget dialog med kolleger eller chefer, kan det være en overraskelse for kontaktpersonen, at I vil inddrage en række af hans kolleger fra både hans egen afdeling og andre afdelinger. En sådan situation kan potentielt være ubehagelig for jeres kontaktperson, fordi kollegernes tid skal retfærdiggøres, og projektet pludseligt skal "sælges" internt som noget, virksomheden skal satse på. I kan derfor risikere, at jeres kontaktperson 1) selv vil stå for indhentning af al data, 2) mener, at der kun er behov for at interviewe ham/hende selv og ikke nogen kolleger, og 3) mener, at der slet ikke er brug for at involvere fx en leverandør eller en kunde. Hvis I er havnet i denne faldgrube, er der tre mulige løsninger: 1. I accepterer de ringere betingelser og anvender de informationer, I trods alt kan få, og arbejder med en række antagelser, der erstatter de informationer, I ikke kan få adgang til 2. I formår at overbevise først jeres kontaktperson og siden øvrige relevante medarbejdere og ledere om projektets vigtighed 3. I afbryder samarbejdet og finder en ny virksomhed at samarbejde med. I bør konsultere vejleder, inden I træffer en beslutning. De fleste vælger løsning nummer 1, idet det ofte er muligt at erstatte en række virksomhedsspecifikke informationer med rimelige antagelser. I bør undgå at komme i denne situation ved at afstemme forventningerne til samarbejdet på de første møder. Hvis I først senere i projektet opdager denne faldgrube, så udarbejd evt. en liste med informationsbehov, og spørg jeres kontaktperson, hvordan I kan få fat i disse data. Dette kan få kontaktpersonen til at give adgang til lige netop den begrænsede mængde kolleger, som I har behov for at tale med. Hvis kontaktpersonen vedbliver med at sige, at "de spørgsmål kan jeg da godt svare på" eller "den ide er helt ude i hampen i vores virksomhed, det ved jeg bare", må I tale med jeres vejleder om, hvordan I kan anvende en række rimelige antagelser. Disse antagelser erstatter så de data, som I ikke kan få fra virksomheden. I den endelige rapport bør I både beskrive, hvad jeres originale plan var for samarbejdet, og hvordan samarbejdet rent faktisk forløb. Hvis planen ikke blev realiseret, og det var virksomhedens skyld, så giv virksomheden skylden. I skal ikke beskytte virksomheden, men tænke på jeres projekt. Husk i den forbindelse, at projektrapportens målgruppe er eksaminator og censor og altså ikke virksomheden.

Ekstra handlekraftige chefer

Jeres projekt er som regel forankret i den afdeling, hvor jeres kontaktperson er ansat. Jeres kontaktperson har en chef. Chefer er som regel dygtige og handlekraftige (det er som oftest derfor, de er chefer). Chefer er vant til, at de bidrager positivt til deres omgivelser med ideer, kritik og hjælp. De fleste chefer er vant til at vise handlekraft, og de forventer, at de har indflydelse i stort set alle de sammenhænge, de indgår i. Dette er fint for deres arbejdsgiver (virksomheden), og for jer som projektgruppe er det også godt med en afdelings- eller funktionschef, der gerne vil engagere sig i jeres projekt. Der er dog en væsentlig faldgrube ved disse ekstra handlekraftige chefer, nemlig at de vil vise handlekraft ved at dreje jeres projekt i en ny retning. Nogle gange sker dette til fordel for afdelingen på bekostning af jeres projekts akademiske kvaliteter. Hvis det sker midtvejs i projektet, kan det være meget problematisk, fordi det sætter den røde tråd i jeres projekt under pres. Det kan være svært at forklare chefen, at hans ideer skaber problemer, og ofte er der ikke meget hjælp at hente hos jeres kontaktperson, fordi det jo netop er jeres kontaktpersons chef, der vil dreje projektet. Risikoen er særligt stor, hvis chefen ikke selv har erfaring med projektarbejde fra sin uddannelse og dermed ikke kender til de krav, som universitetet stiller til et projekt. I kan forebygge problemet ved at gøre et stort nummer ud af det møde, hvor I aftaler problemformuleringen. Sørg for, at både jeres kontaktperson og chefen ved, at når problemformuleringen er aftalt, handler alt jeres arbejde om netop den problemformulering og ikke andre ting. Chefen skal vide, at en drejning af projektet udgør en kæmpestor forandring med meget spildt arbejde til følge og måske en dårligere karakter. Det er vigtigt at vide, at en ekstra handlekraftig chef oftest bare vil hjælpe jer. En chef tror tit ærligt og redeligt, at den drejning, som chefen foreslår, er til jeres bedste, og at I vil være glade og taknemmelige for drejningen. Fordi et studenterprojekt ikke er afdelingschefens førsteprioritet, kan I håndtere chefens handlekraft ved proaktivt at tænke over, hvordan I kan bruge handlekraften til jeres fordel. Medbring en række uafklarede spørgsmål til møder, som er væsentlige, og som I ved, at chefen kan svare på. På den måde kan I kanalisere chefens handlekraft til projektets bedste og udnytte den. Helt konkret kan I indlede et møde således: "Tak for din tid. Vores projekt handler om X og Y. Det, vi ikke kan finde ud af, er A, B og C. Kan du hjælpe os?". Hvis I får problemer med en ekstra handlekraftig chef, kan det også være en ide at gøre vejleder til "the bad cop". Argumentér fx således: "Vores vejleder accepterer kun et projekt med ét fokuseret problem" og "Vores vejleder siger, at den [chefens] nye ide falder uden for den røde tråd i opgaven". Et alternativt forslag, der er aktuelt i enkeltmandsprojekter, er at foreslå, at det, chefen gerne vil have løst, kan klares i en betalt studentermedhjælperrolle.

Virksomheden vil have bredde, vejleder vil have fokus Det er en klassisk problemstilling, at virksomheden vil have løst alle problemer, hvorimod universitetet vil have ét fokuseret problem i problemformuleringen (se mere om dette i kapitel 3). I begyndelsen af semestret er jeres mål at finde en virksomhed, der gerne vil bruge tid på projektet. Derfor er det her naturligt at nikke og sige ja til virksomhedens ønsker. Senere kommer vejleder på banen med sine krav, og så opstår dilemmaet om løsning af mange problemer vs. løsning af ét fokuseret problem.

Et eksempel på en indledende dialog mellem projektgruppe, virksomhed og vejleder Forestil jer et projekt om redesign af en håndholdt temperatur- og fugtmåler. Projektgruppens kontaktperson er sælger i Danmark, og han vil gerne øge brugernes komfort, når de bruger måleren. Brugeren skal kunne bruge måleren i længere tid uden at blive øm i hænderne. Problemformuleringen handler således om at øge brugslængden, inden bruger får ømme hænder [målt i tid]. Problemformuleringen diskuteres først med direktøren i virksomheden. De studerende fortæller om projektet om redesign af temperatur- og fugtmåleren. Direktøren reagerer således: "Okay, spændende. Kan I ikke også se på vægten af produktet? Den skal ned, så vi kan spare materiale. Og så jeg kunne godt tænke mig, at I lige vendte situationen med Jens og Sigurd fra marketing, fordi de har nogle spændende tanker om at trænge ind på det tyske marked. Vores måler er meget bedre end konkurrenternes. Jeg hører lige, om Jens har tid … JÆÆÆÆNS! ... [Jens kommer løbende hen til bordet] Hej Jens, kan du ikke lige fortælle de her studerende det der, du sagde om tyskerne?" Jens: "Jo æh, hvad var det, I arbejdede med?" Projektgruppen fortæller … Jens: "Megafedt projekt! ... Det, jeg egentligt tror er humlen i situationen, er, at tyskerne vil have styrke og en høj korrosionsdygtighed, så måleren kan bruges gennem længere perioder på skibe og andre offshore-enheder. Kan I tænke det med i projektet? Jeg tror virkelig, at det er her, der er noget et hente. Nå, jeg må løbe. Tak for snakken!" Projektgruppen svarer: "God ide. Vi ser på det med vægten … og også på det med styrken … og også på det med korrosionsdygtigheden …" Tre dag senere har de møde med vejleder. Her siger vejlederen til dem:

"Ja, det er et spændende projekt. Men hvad er problemet, I gerne vil løse? Husk, at et projekt skal handle om kun én variabel, der skal enten minimeres eller maksimeres. Vil I fokusere på at øge brugerens tid uden ømme hænder, vil I reducere vægten, eller er det korrosionsdygtigheden, I vil øge?" De studerende ved ikke helt, hvad de skal svare. Ovenstående eksempel skildrer en svær situation. En løsning kan være, at projektgruppen behandler det fokuserede problem (og kun dette) i projektrapporten og så fortæller virksomheden, hvad de har fundet ud af om de andre temaer uden om projektrapporten. Det er vigtigt at vide, at for eksaminatorer vil et projekt, der undersøger en hel række problemer, der kun hænger løst sammen, fremstå tilfældigt og uden en rød tråd. Grafen i figur 10.3 illustrerer den generelle regel for virksomhedens indflydelse på et projekt. Grafen har tid på X-aksen og indflydelse på Y-aksen. Den viser, at virksomhedens indflydelse bør være meget stor i begyndelsen af perioden, og så hurtigt falde og ikke stige igen. Virksomhedens indflydelse bør således være meget lav ca. midt i semestret og helt frem til aflevering.

Figur 10.3. Virksomhedens indflydelse på et projekt

I starten af perioden er virksomheden med til at afgrænse projektet, vælge problem og klargøre, hvilke forventninger og krav de har til løsningen. Midtvejs i projektforløbet, hvor I er godt i gang med arbejdet, skal I ikke tillade ændringer. Når en entreprenør bygger et hus, kan bygherren ikke vælge, at han alligevel vil have en kælder, når fundamentet er støbt. På samme måde er det med et projekt. Når metoden er valgt, og analysen gennemført, kører projektet og skal afsluttes, selvom virksomheden har fundet ud af, at den hellere vil have et andet problem løst. Hvis det er tilfældet, så foreslå eventuelt virksomheden at tage fat i vejleder og få et nyt sæt studerende til at arbejde på det nye problem, virksomheden har.

Informanter med naturlig troværdighed, passion og høj placering i hierarkiet Nogle medarbejdere og ledere i virksomheden har en naturlig troværdighed, som gør, at I som projektgruppe tager deres forklaringer for gode varer uden at forholde jer kritisk til udsagnene. Disse personer kan være højtstående ledere, medarbejdere med en stor passion for deres arbejde eller ældre, erfarne medarbejdere (fx med skæg, briller og ternet skjorte). Disse typer af informanter udstråler en troværdighed, der får jer til at tro på deres udsagn. Informanterne ved bare, at tingene er sådan og sådan. Som udgangspunkt er det herligt at have informanter, der ved, hvad de taler om. Husk dog, at i rapporten og til eksamen er det jer, der skal forklare tingenes tilstand. Eksaminatorerne er ikke tilfredse med argumenter som "Jamen, det har Mogens sagt", "Salgschefen bakker op om dette forslag", eller "Lisbeth ved det, og hun er altså rigtig dygtig!". En teknisk rapport bør argumentere for sine slutninger ud fra facts og logik og ikke ud fra informanternes troværdighed.

Virksomheden kræver alt for vidtgående fortrolighed Det kan ske, at en virksomhed pludselig ikke vil have, at I inkluderer en bestemt række data i projektrapporten, når jeres afleveringsdato nærmer sig. Det kan komme så vidt, at virksomheden gør det rigtigt svært for jer at aflevere en fyldestgørende rapport. Hvis I har underskrevet en vidtrækkende fortrolighedserklæring, kan dette være problematisk. Husk derfor følgende: Hvis I underskriver en fortrolighedserklæring, så sørg for, at der eksplicit i erklæringen står, at I som projektgruppe gerne må dele informationer og data med vejleder og censor. Hvis fortrolighedserklæringen er en standardformular, som virksomheden ikke vil ændre, så skriv eventuelt selv et stykke papir som et tillæg til fortrolighedserklæringen, og få virksomheden til at underskrive. Hvis fortrolighedserklæringen siger, at I må dele informationer med vejleder og censor, er det op til jer, hvad I vil aflevere, uagtet virksomhedens ønsker og krav. Blot sørg for at skrive "Fortrolig" på rapportens forside, og klik "Fortrolig"-knappen ved upload. I kan fortælle virksomheden, at underviser og vejleder begge har tavshedspligt, jf. forvaltningsloven. Forvaltningslovens bestemmelser fortæller, at offentligt ansatte (herunder jeres vejleder) skal holde virksomhedshemmeligheder hemmelige. Censor er som beskikket gennem censorkorpset også underlagt forvaltningsloven.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Opsummering

I dette kapitel har du lært de fleste facetter af det gode virksomhedssamarbejde. Du har lært, hvordan du identificerer en virksomhed at samarbejde med, og hvordan I som projektgruppe "sælger" jeres projektsamarbejde til virksomheden. Du har ligeledes lært, hvordan den indledende fase i samarbejdet fungerer, fx hvordan I når frem til en afgrænsning af projektet og udfolder kredsen af relevante personer i virksomheden ud over jeres kontaktperson. Kapitlet beskriver, hvordan det løbende samarbejde med virksomheden foregår, fx dataindsamling og involvering af virksomhedens medarbejdere i jeres analysearbejde og løsningsdesign. Blandt de væsentlige temaer er, hvordan I rent praktisk sikrer jer, at I får de nødvendige data i god tid, og mulighederne for at involvere medarbejdere i projektet. Nøglen til det gode samarbejde ligger ofte i fysisk tilstedeværelse i virksomheden. Denne giver jer muligheden for løbende at sparre med virksomhedens medarbejdere omkring analyse, design og implementering. Kapitlet beskriver endvidere en række faldgruber i virksomhedssamarbejdet. For eksempel hvordan I kan håndtere en lidt for engageret chef, at virksomheden kan miste interessen for jeres projekt, eller at virksomheden hele tiden forventer mere og mere af jeres projekt, selvom problemformuleringen er nedfældet og aftalt.

Kapitel 11. Projektets interessenter projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I dette kapitel lærer du: Hvem der er interessenter i et teknisk projekt Hvordan I kan analysere projektets interessenter og løbende have overblik over mulig modstand mod projektet Hvordan I tidligt opdager mulig modstand mod implementering af projektets løsninger Hvordan I strategisk håndterer projektets interessenter At et projekt har interessenter både i selve projektperioden, i implementeringsperioden og i driftsperioden Hvordan I kan håndtere 'problempersoner' for projektet Hvordan I kan håndtere løbende møder med afdelingschefer og øvrige magtfulde interessenter. Dette kapitel giver råd til at håndtere projektets interessenter (på engelsk: stakeholder management). Kapitlet indleder med at beskrive, hvad en interessentanalyse er, og giver derefter konkrete anvisninger til håndtering af de mest almindelige interessentrelaterede problemer, herunder nogle af de større (potentielt fatale) problemer.

Projektets interessenter projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Figur 11.1 giver et overblik over de klassiske kategorier af interessenter i et projekt. De største og mest komplekse interessenter er som regel aktører inden for virksomheden. En 'aktør' er en person, en afdeling eller evt. en helt anden organisation som fx en fagforening.

Figur 11.1. De klassiske kategorier af interessenter i et teknisk projekt

Som figuren viser, er virksomheden oftest den vigtigste interessent, idet projektet er afhængigt af, at virksomheden giver adgang til data og medarbejdertid. Medarbejdertiden, som I har brug for, svinger afhængigt af projektets tema, men ofte vil I have behov for adgang til flere afdelinger. Det er jeres kontaktperson, der har kontaktinformationer på kolleger, og det kan være nødvendigt, at kontaktpersonen selv skaber forbindelse mellem jer og sine kolleger. Figur 11.1 viser, at der er flere typer af interessenter uden for virksomheden. Konkurrenter og fagforeninger er oftest ikke klar over projektets eksistens før langt henne i projektperioden, hvor test og implementering er aktuelle. Offentlige organisationer og myndigheder har en interesse i, at projektets løsninger overholder love og regler. Vejleder og universitetet har en interesse i, at I opnår den læring, som projektkursets læringsmål beskriver. En vigtig interessent, som i figuren er vist som en indirekte interessent, er brugeren af projektets løsning. I mange projekter er virksomheden selv løsningens bruger, fx i et projekt om forbedring af produktionsprocesser. I projekter, der designer eller forbedrer et produkt for virksomheden (fx en maskine, et instrument eller en IT-applikation), er løsningens brugere ofte virksomhedens kunder. At forstå, hvordan projektets løsning

opfylder behov hos brugere, er en meget vigtig brik i et teknisk projekt. Både eksaminator og censor er meget opmærksomme på sammenhængen mellem en teknisk løsning og brugerens behov (uagtet om behovene er eksplicit udtrykt af brugeren eller ej). Den måske væsentligste generelle kritik af ingeniører er, at ingeniører ofte udvikler ting, der er nyskabende og teknisk komplekse, men ikke adresserer brugerens behov. Dette er et ømt kritikpunkt for ingeniørfaget som helhed, og derfor er lige netop sammenhængen mellem brugerbehov og produkt et stort tema ved eksamen.

Vejleder og universitetet som interessent Vejleder og universitetets interesse i et projekt er oftest begrænset til, at vejleder ønsker, at I skal lære noget og bestå eksamen. På den måde viser vejleder og universitetet, at de får uddannet færdige dimittender, som hurtigt får arbejde og helst en høj skattepligtig løn. Vejleders interesse kan dog være mere specifik. Dette gælder oftest ved tekniske kandidatafhandlinger, der kan indgå i et forskningsprojekt, men kan også gælde projekter på tekniske professionsuddannelser. De fleste uddannelser har en række stamkundevirksomheder, der hvert semester tager studerende i praktik. Disse virksomheder skal gerne fastholdes som stamkunder. Derudover vil uddannelsen gerne tiltrække nye virksomheder som aftagere til dimittender og stamkunder for praktikanter og afgangsprojekter. Hvis en ny virksomhed for første gang indgår i et samarbejde med jer som studerende om et projekt, er det vigtigt for uddannelsen (og dermed vejleder), at virksomheden er tilfredse med jeres arbejde. Det kan også være et innovationsprojekt, som universitetet udarbejder i samarbejde med en række partnere, og her vil vejleder gerne, at projektet udføres godt, så universitetet leverer et godt stykke arbejde til partnersamarbejdet.

Virksomheden som interessent Hvor universitetet kan være en lidt besværlig interessent, så kan virksomheden være et rent minefelt for projektet. Det er særligt tilfældet for projekter, der medfører mærkbare konsekvenser i virksomheden. I denne type projekter skal I være klar over, at jeres projekt kan være en brik i et større politisk spil i virksomheden, fx i en magtkamp mellem forskellige chefer i virksomheden. Det lyder måske usandsynligt, at et teknisk projekt er en brik i en magtkamp, men det sker oftere, end man lige regner med. Det kan fx være, at jeres egen kontaktperson har en agenda, som I ikke er bekendt med. For eksempel kan kontaktpersonen for et projekt på bygningsingeniørretningen være træt af en bestemt leverandør af vinduer og beder derfor jer om at designe en bygning med en anden type vinduer.

Nogle gange "opdager" en interviewperson midt i et interview, at han eller hun kan bruge jeres projekt til at fremme egne ønsker eller personlige karriere, hvis jeres konklusion falder i hak med interviewpersonens agenda.

Eksempel på projekter som en brik i en magtkamp En virksomhed sælger tørringsanlæg til industrielle kunder i Europa. Jeres kontaktperson er sælger og vil gerne vise ledelsen, hvor dygtig han er, ved at begynde at sælge til amerikanske kunder. Produktionschefen vil dog ikke sælge til amerikanske kunder, fordi så stiger transportomkostningerne og derfor stykomkostningerne. Højere stykomkostning betyder lavere bonus til produktionschefen selv. For at kunne få ledelsens accept af udvidelsen til USA beder kontaktpersonen (a) to produktionsingeniørstuderende om at designe et logistiksystem til distribution af tørringsanlæg til USA og (b) to eksportingeniørstuderende om at lave en markedsanalyse af Californien, Texas og Florida. Dette er begge højrisikoprojekter, for hvis produktionschefen får nys om disse projekter, er der fare for, at begge projekter bliver lukket omgående.

Interessentanalysen – den strategiske analyse af projektets interessenter projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

For nogle projekter er det hensigtsmæssigt at udarbejde en decideret interessentanalyse, der skaber klarhed over, hvilke personer i virksomheden der er projektets "venner", og hvilke personer der kan lægge forhindringer i vejen for projektets gennemførelse eller for implementeringen af løsningsforslag. Tabel 11.1 beskriver proceduren for en interessentanalyse. #

Skridt

Beskrivelse

1

Udarbejd en liste i MS Excel over navne på alle de potentielle interessenter i projektet.

Gennemtænk hele perioden for projektets gennemførelse, inklusive tiden for implementering af projektets løsningsforslag. Tag højde for både medarbejdere og ledere, relaterede afdelinger og generelt alle de aktører, der har en interesse i de løsninger, som projektet med al sandsynlighed kommer frem til (fx leverandører, kunder og fagforeninger). Listen over interessenter skal indeholde både projektets venner og fjender (både aktuelle og potentielle). Husk, at en interessent kan være både en enkeltperson, en afdeling i virksomheden og andre organisationer (fx en offentlig myndighed, en fagforening eller en af virksomhedens konkurrenter).

2

I første kolonne til højre for navnelisten beskriver I kort aktørens interesse i projektet.

Besvar spørgsmålet om, hvorfor aktøren er interesseret i projektet. En aktørs interesse i projektet kan fx være afledt af de konsekvenser, løsningsforslagets implementering har for aktøren.

3

I anden kolonne til højre vurderer I aktørens magt kvantitativt.

Vurdér aktørens magt på en skala fra 1 til 10, hvor 1 indikerer ingen magt, og 10 indikerer magt nok til egenhændigt at kunne lukke projektet fra den ene dag til den anden.

4

I tredje kolonne til højre vurderer I størrelsen og retningen af aktørens interesse.

Er aktørens interesse svag eller stærk, og er aktørens interesse i projektet i positiv eller negativ retning? Vurder størrelsen af aktørens interesse i projektet på en skala fra 1 til 10. Angiv derefter, om interessen er positiv eller negativ. En negativ interesse får et minus foran (fx -7), og en positiv interesse får et plus foran (fx +4).

5

I fjerde kolonne til højre noterer I alliancer og stærke personlige relationer mellem aktører, der er relevante.

Magt og interesse forstørres eksponentielt. Hvis tre personer "rotter sig sammen", har de større magt end de tre personer enkeltvis. Notér jer derfor (hvis muligt), hvilke personer der typisk allierer sig med hinanden i virksomheden. Notér også, hvis der er stærke personlige relationer mellem personer, der er vigtige for projektet.

6

I femte og sidste kolonne til højre for navnelisten beskriver I den strategi, I vil anvende for hver interessent.

Skal I holde personen løbende informeret, skal I undgå at gøre personen opmærksom på projektet, skal I ikke gøre noget, skal I gøre personen (en ven af projektet) opmærksom på mulige problempersoner eller andre faremomenter? Særligt for interessenter med stor magt og stor interesse i projektet bør I forholde jer til en strategi og involvere projektets "venner" i strategien.

Tabel 11.1. Interessentanalyse (tilvirket på baggrund af DeLuca, 1984) Inkluder i analysen både 1) perioden for projektets gennemførelse, 2) perioden for test og implementering af projektets løsningsforslag og 3) perioden, hvor løsningsforslaget er i drift. Chefen i den afdeling, hvor jeres kontaktperson er ansat, kan fx være ligeglad med projektets løsning, men meget opmærksom på, om hans medarbejdere bruger tid på projektet i perioden, hvor I gennemfører projektet. Andre interessenter er omvendt uinteresserede i tidsforbruget, men meget opmærksomme på projektets konsekvenser for fx arbejdsmiljø, bonusordninger og opgavefordeling. Det kunne fx være en kvalitetsafdeling, en HR-afdeling, en afdeling med ansvar for sikkerhed eller en arbejdsmiljøgruppe. Figur 11.2 illustrerer disse tre faser i et projekt, der hver især har deres sæt af interessenter.

Figur 11.2. Tre faser med hver deres sæt af interessenter

De interessenter og magtforhold, som analysen frembringer, kan I sammenfatte i en oversigt som illustreret i figur 11.3. Specifikt kan I indsætte resultaterne fra step 1 til 5 i interessentanalysen i figuren (DeLuca, 1984).

Figur 11.3. Interessentanalysens resultat (tilvirket på baggrund af DeLuca, 1984)

Figuren indeholder en række personnavne (fx Hansen og Frik), en række afdelingsnavne (fx Kvalitet og Salg) og en række navne på andre organisationer, der griber ind i magtforholdene i virksomheden (TJK er en stor kunde, og FAGFOR er en fagforening). Disse personer, afdelinger og andre organisationer er alle projektets interessenter. Vandret er figuren inddelt i to områder. I højre side er projektets venner (fx Klein, Islev, salgsafdelingen og kunden TJK). I venstre side er projektets modstandere (fx Slot og Falk og fagforeningen FAGFOR). Jo større en ven af projektet interessenten er, jo længere ud mod højre skal navnet placeres. Omvendt, jo større en modstander af projektet interessenten er, jo længere mod venstre står navnet. Lodret er figuren delt op i en lille del øverst og en stor del nederst. Den nederste del har en skala fra 1 til 10 i venstre side af figuren. Jo højere en interessent er i figuren, jo mere magt har interessenten. Hvis interessenten ligger i øverste del af figuren over den vandrette streg, har interessenten egenhændigt magt til at stoppe projektet. I figuren står navnet Sass i øverste venstre side. Det betyder, at Sass er modstander af projektet og potentielt kan stoppe det. I figuren er nogle grønmarkerede felter, der indrammer en række interessenter. Et eksempel er Yang, Islev, Klein og Bille. Det grønmarkerede felt fortæller, at interessenterne i feltet danner en alliance og oftest har den samme holdning til ting. I figuren er også nogle stiplede linjer. Disse linjer indikerer stærke personlige relationer mellem to interessenter. Disse relationer kan en interessent udnytte. Figuren viser, at der er en stærk relation mellem Sass og Hansen. Denne er vigtig, fordi Hansen er del af en alliance, der er modstander af projektet, og fordi Sass egenhændigt kan stoppe projektet.

Interessentanalysen, her sammenfattet i figur 11.3, udgør grundlaget for at tage beslutninger om, hvordan I som projektgruppe vil håndtere hver interessent. Om og hvordan I bør håndtere interessenter, kommer an på følgende: Hvor interessenten befinder sig i figuren, altså om interessenten har magt eller ej, og om interessenten er ven eller modstander af projektet Om interessenten har stærke relationer eller er med i alliancer Hvilken konkret interesse interessenten har i projektet.

Mulige strategier for interessenthåndtering projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Resultatet af jeres interessentanalyse giver jer mulighed for at undgå forhindringer og faldgruber for jeres projekt. Overvej, om det er fordelagtigt på forhånd at involvere personer, der er potentielle modstandere af projektet. Hvis I involverer disse personer fra start, er der en chance for, at de oparbejder et ejerskab til projektet og derigennem ender med at blive "venner af projektet" frem for potentielle showstoppere. Husk at udnytte jeres relationer til projektets naturlige venner, så disse kan bakke op og hjælpe jer, fx med at få adgang til data. Tænk også over, hvordan I præsenterer resultater. Ofte skal en løsning sælges til en interessent. I bør præsentere hele projektet med fordele og ulemper, men gør dette i den rigtige rækkefølge. Præsenter de aspekter af jeres løsning, der er gode for interessenten, før de aspekter, som I forventer, at interessenten vil sige nej tak til. Hvis I præsenterer de knap så fantastiske aspekter først, kan det være, at interessenten slet ikke opfatter fordelene eller måske slet og ret stopper mødet, inden I når til fordelene. Husk derfor inden et møde med en interessent at tænke grundigt over, hvilke fordele jeres projekt giver interessenten. En særlig type udfordring i selve projektperioden er, at chefen i jeres kontaktpersons afdeling egentligt er ligeglad med projektet, men ikke vil have, at I bruger medarbejdernes tid. Her kan I bruge den inkrementelle metode. Bed ikke om at få lov til at interviewe en hel liste med personer, men blot om at få en halv time med en enkel medarbejder. Derefter en halv time med en anden medarbejder og en række opfølgende spørgsmål på telefonen eller mails. Langsomt men sikkert får I jeres informationer. Hvis det går helt galt, så forsøg at få jeres information ved "tilfældigt" at rende ind i relevante personer i elevatoren eller spise ved samme bord i kantinen.

Særligt kritiske projekter For projekter, der resulterer i fyringer, ændrede arbejdsvilkår, udflytning af arbejdspladser til andre verdens- eller landsdele, nedlæggelse af produkter eller blot ændrede magtbalancer mellem funktionschefer, er det særligt vigtigt at anvende en interessentanalyse. Denne analyse bør I udføre grundigt og opdatere løbende (fx ugentligt), så I hele tiden har styr på mulige barrierer og modstand mod projektet. Den løbende opdatering over ugens udvikling bør indeholde overvejelser om, hvorvidt I skal foretage forebyggende handlinger for at reducere fremtidige risici for projektets gennemførelse. Nogle typer af projekter er naturligt brandfarlige lige fra begyndelsen. Det er typisk projekter, der handler om at reducere omkostninger, og projekter, der handler om radikal innovation, der kan lede til potentielt store og uforudseelige ændringer.

De løbende møder med afdelingschefen eller – endnu værre –

løbende møder med ledere fra flere funktioner Langt de fleste studenterprojekter skaber ingen væsentlige ændringer i virksomheden og glider nemt igennem uden problemer med chefer og medarbejdere. Der er dog nogle projekter, der er så vigtige for virksomheden, at ledelsen insisterer på løbende at blive involveret i beslutninger. Det første gode råd er her helt at undgå denne situation. Undgå at blæse projektet op til at være vildt vigtigt. Det skaber kun ballade. Hvis ledelsen insisterer på løbende orientering, sker dette typisk under milepælsmøder eller styregruppemøder. Disse møder afholdes fx en gang om måneden eller bare to-tre gange hen over semestret. Møderne kan give jer store problemer, merarbejde og frustration, fordi mødedeltagerne ofte vil noget, andet end I vil. En effektiv strategi er her at gøre denne type møder så kedelige, at ledelsen fremadrettet aflyser dem eller blot lader være at deltage. Dette kan gøres ved at sørge for, at alle vigtige personer, der deltager på disse møder, er orienteret om alt vigtigt om projektet allerede inden mødet. På den måde ender mødet med at være en kedelig "Ja, ja, kom nu videre"-affære. Jo kedeligere mødet er, jo mindre farefuldt er det for jeres projekt.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Opsummering

I dette kapitel har du lært, at et teknisk projekt ofte har en lang række interessenter både inden og uden for rammerne af den virksomhed, I samarbejder med. Du har lært, hvordan I som projektgruppe kan analysere projektets interessenter og løbende får overblik over mulig modstand mod projektet blandt interessenterne. Kapitlet beskriver, hvordan I tidligt opdager mulig modstand mod implementering af projektets løsninger, hvordan I strategisk håndterer projektets interessenter, og hvordan I løbende kan håndtere møder med afdelingschefer og øvrige magtfulde interessenter. Et projekt har interessenter både i selve projektperioden, i implementeringsperioden og i driftsperioden.

Kapitel 12. Projektrapportens indhold projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I dette kapitel lærer du: Hvilke afsnit et teknisk projekt typisk består af Om indholdet i hvert af disse afsnit Hvordan afsnittene tilsammen ender ud i den projektrapport, I afleverer til slut i projektperioden Hvordan I kan skrive afsnittene, så de understøtter hinanden og skaber en rød tråd i projektet Hvordan I kan skrive hvert enkelt afsnit med størst mulig klarhed. Dette kapitel handler om projektrapporten. Kapitlet adskiller sig således fra bogens kapitel 2 til 8, der handler om projektprocessen og projektaktiviteterne. Hvordan I skriver projektrapporten, kommer an på projektkursets læringsmål og de traditioner, der er på din uddannelse og dit fagområde. På uddannelsens tidlige semestre er projekter typisk bundne opgaver, der er beskrevet i detaljer af dine undervisere. Disse projektrapporter skal I derfor ofte udforme efter nøje fastlagte regler og eventuelt med anvendelse af særlige skemaer og skabeloner. I de ikke-bundne projekter, som denne bog handler om, er det op til jer som projektgruppe at udforme jeres projektrapport. Det er denne type projektrapporter, dette kapitel handler om.

En teknisk projektrapports generelle indhold projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

En projektrapport på en teknisk uddannelse består som regel af en række afsnit, der følger hinanden på en logisk, naturlig måde. Afsnittene kan variere en smule fra uddannelse til uddannelse, men følger dog som regel nedenstående liste: 1. Forside med titel 2. Abstract eller resumé 3. Introduktion 4. Problemformulering 5. Afgrænsninger fra problemformuleringen 6. Teori og faglig litteratur 7. Projektets metode 8. Analyse 9. Løsningsdesign 10. Test af løsning 11. Implementering af løsning 12. Konklusion og anbefalinger til virksomheden 13. Perspektivering af resultater 14. Referenceliste 15. Bilag og dokumentation af rådata. I det følgende vil vi beskrive hvert enkelt punkt på listen begyndende med forside og titel på jeres projekt.

Projektets forside med titel projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Projektets forside har tre vigtige formål: at sikre, at læsers førstehåndsindtryk passer med projektets indhold at vække læsers interesse for projektet at kommunikere praktiske detaljer om projektet (fx gruppenummer og navn på kurset). Afsnittet beskriver først den gode projekttitel, dernæst hensigtsmæssige illustrationer på forsiden og slutteligt de praktiske detaljer om projektet på forsiden.

Projekttitel Den vigtigste sætning på forsiden er (måske ikke så overraskende) projektets titel. Titlen er den første mulighed for at gøre det klart over for læser, hvad jeres projekt handler om. Titlen skal derfor være præcis. En klassisk faldgrube er, at titlen er så bred, at læser kun får et vagt billede af, hvad projektet handler om. Et tip er at bruge en omskreven version af problemformuleringen som titel. Se et eksempel her:

Eksempel på en god titel til et projekt Et projekt handler om at reducere nedetiden på en række sprøjtestøbemaskiner, der producerer plastemner i virksomheden Worldwide Plastic (fiktivt eksempel). Nedetid er den tid, hvor maskinerne ikke kører (fx på grund af teknisk nedbrud, planlagt vedligehold, eller fordi maskinen venter på råvarer, som den støber færdige emner af). Titlen på projektet lyder: "Optimering af plastproduktion hos Worldwide Plastic". Dette kan ved første blik virke som en fin titel, der fortæller, hvor projektet foregår, og at det generelle tema er optimering af plastproduktion. Titlen er dog alt for bred, og læser bliver ikke voldsomt meget klogere af at læse den. Worldwide Plastics logo fremgår formentlig allerede på forsiden, så at nævne navnet i titlen er overflødigt. Verbet optimering kan betyde mangt og meget. En titel skal være langt mere tydelig og konkret omkring, hvad projektet handler om. En bedre titel kunne være: "Reduktion af nedetid på sprøjtestøbemaskiner". Ud fra denne titel kan en erfaren læser af tekniske projekter (fx censor) med det samme udlede, at problemformuleringen i projektet er: "Hvordan kan Worldwide Plastic reducere nedetiden på deres sprøjtestøbemaskiner?".

Illustrationer på forsiden I frie projekter får I som regel lov til selv at designe forsiden. Nogle projektgrupper anvender en fast generisk Word-skabelon som forside (fx nogle streger, firkanter eller cirkler). Andre projektgrupper anvender en illustration, der mere direkte handler om projektet. Denne bog anbefaler det sidste. Brug en illustration, der rammer ind i kernen af projektet. Hvis projektet handler om at designe en bygning, så vis bygningen, og hvis projektet handler om at designe et apparat, så vis apparatet (fx en illustrativ kunstnerisk skitse). Illustrationer på forsiden understøtter to af forsidens tre formål, nemlig at sikre læsers forståelse af projektets indhold og at vække læsers interesse. Illustrationer kan være fx et foto, et kasse-pilediagram, en skitse eller en håndtegning. Undgå at bruge virksomhedens logo som illustration. Dette fortæller kun, hvor projektet udføres, og ikke noget om projektets faglige indhold.

De praktiske oplysninger på projektforsiden Projektets målgruppe er eksaminator og censor. Censor på et projektkursus skal ofte vurdere alle rapporter fra hele kurset. Det er derfor meget vigtigt, at I skriver jeres gruppenummer på rapportens forside. Hvis I afleverer både en hovedrapport og en bilagsrapport, er det vigtigt at have samme layout på begge rapporter. Nogle rapporter består af mange enkeltdele (fx en hovedrapport, en bilagsrapport, et sæt tekniske tegninger og en rapport over gruppens arbejdsproces). Hvis jeres klasse eller hold består af 10 projektgrupper, og alle grupper afleverer hovedrapport, bilagsrapport og et sæt af tekniske tegninger, har censor 30 dokumenter til vurdering. Hvis alle rapporter fra én projektgruppe har samme layout på forsiden, kan censor hurtigt se, hvilke af de 30 dokumenter der hører sammen. Det ses fra tid til anden, at projektgrupperne i en klasse afleverer tre rapporter med tre forskellige forsider. Det betyder, at censor må lægge en slags rapportkabale på en af de to-tre aftener inden eksamen, som censor har afsat til at læse rapporterne. Det giver et dårligt indtryk.

Abstract eller resumé projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Dette afsnit, der som regel fylder én side, har til opgave at kommunikere projektets væsentligste indhold. Næsten alle frie projekter kræver et abstract eller resumé. Som ingeniør eller anden tekniker er det vigtigt at kunne kommunikere projektets indhold kort og præcist til kolleger og chefer, der ikke har meget tid. Målgruppen for jeres rapport er ganske vist eksaminator og censor, der læser både abstract og hele rapporten, men I skal skrive abstractet, som om målgruppen er en af følgende: Personer, der ikke har tiden til at læse hele projektet (fx en direktør) Personer, der gerne vil vurdere, om projektet er værd at bruge tid på Personer, der kun er interesseret i projektets løsninger og ikke er interesseret i metode, analyse etc. Abstractet bør indeholde følgende punkter: En kort introduktion til projektet, herunder gerne virksomhed og projektets problem (4-6 sætninger, hvis abstractet må fylde en hel A4-side) Problemformulering og evt. en eller to vigtige afgrænsninger eller forudsætninger (2-4 sætninger) Metode (2-4 sætninger, afhængigt af fagområdets traditioner) Væsentlige resultater af analysen (5-8 sætninger) Sammenfatning af løsning og anbefalinger til virksomheden (6-10 sætninger). Tekniske projekter er ofte fortrolige, idet projekterne arbejder med informationer, som virksomheden ikke ønsker kommer i hænderne på konkurrenter. Husk derfor, hvis abstractet skal offentliggøres, at anonymisere jeres virksomhed grundigt.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Introduktionen

Introduktion forstås i dette kapitel som al den tekst, der går forud for problemformuleringen. Det inkluderer beskrivelse af baggrund og herunder beskrivelse af virksomheden. Introduktionens hovedformål er at sikre læseres forståelse af projektet og særligt at sikre forståelsen af problemformuleringen. Til dette formål bør introduktionen skrives hierarkisk. Se et eksempel her:

Eksempel på hierarkisk introduktion til projekt Projektets titel er "Reduktion af nedetid på sprøjtestøbemaskiner" hos (den fiktive) virksomhed Worldwide Plastic. Projektgruppen opbygger introduktionen hierarkisk på følgende måde: 1. Kort og præcis beskrivelse af Worldwide Plastic (maks. 1 side). 2. Præsentation af virksomhedens produkter. Dette afsnit inkluderer et billede af et produkt, der er adskilt i sine komponenter, så læser kan se eksempler på sprøjtestøbte emner. 3. Præsentation af Worldwide Plastics verdensomspændende produktion, illustreret med et verdenskort over, hvor fabrikker er lokaliseret. 4. Præsentation af Worldwide Plastic i Danmark med et kort over, hvor virksomhedens danske fabrikker ligger. 5. Kort over fabriksbygningerne i Vordingborg, hvor sprøjtestøbefabrikken ligger. 6. Plantegning over sprøjtestøbebygningen i Vordingborg, hvor sprøjtestøbemaskinerne er markeret. 7. Billeder (fotos) af sprøjtestøbemaskiner med forklaring af, hvilke komponenter disse konkrete maskiner producerer. 8. Eksemplarisk graf over maskinernes aktuelle udnyttelsesgrad (fx et cirkeldiagram, der viser, at udnyttelsen er lav). 9. Beskrivelse inklusive grafer og tal, der kvantificerer konsekvenserne af den høje nedetid. Redegørelse for, hvordan reduktionen af nedetid med fx 5 % kan reducere behovet for maskiner og millionbesparelser på vedligehold, husleje, afskrivninger m.m.

Efter denne introduktion forstår læseren, hvad problemformuleringen er, og hvorfor den er vigtig at adressere: "Hvordan kan Worldwide Plastic reducere nedetiden på deres sprøjtestøbemaskiner?" Som det ses af eksemplet, starter opbygningen af introduktionen bredt med en beskrivelse af hele virksomheden og bevæger sig langsomt ned i detaljerne omkring sprøjtestøbemaskinernes nedetid. På den måde sikrer introduktionen, at læseren forstår problemformuleringens indhold, og hvorfor problemformuleringen er vigtig for virksomheden.

Verificering af problemets faktiske eksistens Introduktionen i et projekt er et godt sted at fortælle læseren, at projektets problem faktisk eksisterer, og hvor stort det er. I ovenstående eksempel med Worldwide Plastic gøres det i de to sidste dele, 8 og 9. At problemet findes, er hele grundlaget for at påbegynde jeres projekt. Uden et problem er problemformuleringen ikke meningsfuld. Gør derfor, hvad I kan for at verificere problemets eksistens. Se mere herom i kapitel 2. Hvis virksomheden allerede har målt problemets størrelse (fx at et produkts holdbarhed er halvt så stort, som det burde), så brug disse data til at præsentere problemet i projektets introduktion. Hvis der ikke findes målinger af problemet, er det jeres opgave at finde data, der understøtter, at problemet findes. I kan fx bringe interviewudsagn, der stærkt indikerer, af at problemet faktisk findes og har en størrelse, der gør det relevant at arbejde med. Senere, i projektets analysedel, kan I foretage en uddybende dataindsamling, der dokumenterer størrelsen af problemet. Præsentér resultatet af denne uddybende analyse tidligt i analyseafsnittet. Se mere om analysearbejdet i kapitel 6.

Problemformulering projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Problemformuleringen kommer umiddelbart efter introduktionen. Hvis introduktionen er velskrevet, kan problemformuleringen nedfældes uden yderligere forklaring. Det er vigtigt, at læseren tydeligt kan se, hvad der er projektets problemformulering. Brug sidens layout til at fremhæve problemformuleringen, fx fed skrift og et linjeskift før og efter problemformuleringen. Undgå skygger, nye farver eller anden skrifttype (det virker uprofessionelt). Vigtigheden af en god problemformulering kan næsten ikke overdrives. Problemformuleringen er så vigtig, at den kræver et helt kapitel – i denne bog kapitel 3. Kapitlet beskriver indgående, hvad gode problemformuleringer i tekniske projekter er, og hvordan I kan udarbejde en god problemformulering til jeres projekt. Hvis I anvender underspørgsmål til problemformuleringen, så placér dem umiddelbart efter problemformuleringen, så det er tydeligt for læseren, at spørgsmålene udgår direkte fra problemformuleringen. Læs i den forbindelse kapitel 3's gennemgang af, hvad der udgør acceptable og ikke-acceptable underspørgsmål.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Afgrænsninger

Kapitel 3 fortæller, at afgrænsninger har to funktioner i et projekt: (a) at afgrænse problemformuleringen, så den passer med rapportens indhold, og (b) at foretage lokale afgrænsninger i rapporten. Afgrænsningerne fra problemformuleringen har sit eget afsnit lige efter problemformuleringen. Afsnittet hedder typisk "Afgrænsninger". De lokale afgrænsninger beskriver I de steder i projektet, hvor I foretager afgrænsningerne. De skal ikke flyttes frem i afsnittet "Afgrænsninger".

Afgrænsninger af problemformuleringen Afgrænsningsafsnittet i jeres projektrapport har til formål at forme læserens forventninger til rapporten. Forestil dig, at læser har læst introduktionen og problemformuleringen. Disse afsnit giver læser en række forventninger til, hvad rapporten vil indeholde. Sæt dig i læsers sted, og vurdér, hvad læseren med rette kan forvente af rapporten. Hvis læserens forventninger ikke stemmer overens med rapportens indhold, så afgræns jer i forhold til de temaer, I ikke behandler. Jeres opgave er at 'beskære' læsers forventninger, så de matcher rapporten.

Eksempel på afgrænsninger i forhold til problemformuleringen Et projekt, der handler om genanvendelse af en virksomheds brugte produkter, kan med rette forventes at komme ind på "grønne" temaer. For eksempel hvordan genanvendelse vil påvirke virksomhedens grønne image, CO2-emissioner eller evne til at understøtte FN's verdensmål for bæredygtig udvikling. Hvis projektet ikke behandler grønne temaer, er det vigtigt at fortælle dette i afgrænsningerne umiddelbart efter problemformuleringen. Undgå at afgrænse jer fra temaer, som kun er meget løst knyttet til problemformuleringen eller slet ikke hænger sammen med projektet. Afgrænsninger fra temaer, som læser ikke i sin vildeste fantasi kunne forestille sig som del af projektet, skaber mere forvirring end klarhed. Forestil dig, at læser tænker: "Hmm, hvis projektet afgrænser sig fra dette tema, har jeg vist slet ikke forstået, hvad dette projekt handler om."

Tip til afgrænsninger i projektrapporten

Få tre personer, der er universitetsuddannede (eller evt. klassekammerater) til at læse jeres introduktion og problemformulering. Spørg dem om deres forventninger til rapportindholdet. Stil fx følgende spørgsmål: Hvad tror du, rapporten kommer til at handle om? Hvilke temaer og emner tror du, rapporten kommer ind på? Hvad tror du, rapporten analyserer? Hvilke forventninger har du til projektets løsning? Hvad tror du, konklusionen beskriver? Disse spørgsmål vil afsløre, om jeres introduktion og problemformulering stemmer overens med jeres faktiske rapportindhold. Hvis der ikke er sammenfald mellem forventninger og faktisk rapportindhold, bør I enten afgrænse jer fra de temaer, rapporten ikke kommer ind på, eller revidere jeres introduktion. Jeres dialog omkring disse spørgsmål kan også afsløre, om rapporten (herunder analyse, løsning og konklusion) hænger sammen med problemformuleringen. Hvis dette ikke er tilfældet, har I en større opgave foran jer, nemlig at skabe en bedre sammenhæng mellem problemformulering, analyse og løsning.

Lokale afgrænsninger i rapporten Når I arbejder med analyse og løsningsdesign, kan der opstå behov for afgrænsninger. Disse afgrænsninger er lokale afgrænsninger, og det er vigtigt, at de har deres plads lokalt i rapporten. Træk dem ikke frem i afgrænsningsafsnittet lige efter problemformuleringen, for her vil de være uforståelige for læser, der ikke kender konteksten for afgrænsningerne endnu. Et eksempel kunne være en teori, der beskriver fire elementer, hvoraf I vil afgrænse jeres brug til kun tre af disse.

Teori og faglig litteratur projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Et teknisk projekt anvender uddannelsens faglige litteratur. Kapitel 4 fortæller, at faglig litteratur både er praksisorienteret litteratur (fx regler, standarder og normer) og teori fra den anvendte forskning og grundforskningen. Tekniske projekter bruger faglig litteratur til en række forskellige formål, herunder at definere de centrale begreber, udarbejde grundlaget for projektets analyse og identificere de generelt gældende krav til løsningstypen. Det følgende afsnit fortæller, hvordan I kan beskrive jeres arbejde med litteraturen i projektrapporten.

Det globale teoriafsnit Kapitel 4 fortæller, at et projekt definerer væsentlige begreber og evt. udvikler et såkaldt 'generisk' problemtræ. Det afsnit, hvor I gør dette, kalder denne bog for projektets "globale" teoriafsnit. Afsnittet er typisk placeret mellem problemformulering og metodeafsnit eller som en integreret del af metodeafsnittet. Det globale teoriafsnit sikrer, at læser opnår en præcis forståelse af jeres projekts væsentligste begreber, ikke mindst begreberne i problemformuleringen. Det gør læser i stand til at vurdere, om den metode, I vil bruge og præsenterer i jeres metodeafsnit, faktisk vil resultere i en god og effektiv løsning på problemet. I dette afsnit bør I beskrive og illustrere det generiske problemtræ, der danner udgangspunkt for jeres analysearbejde, hvis I har udarbejdet et sådan. Det globale teoriafsnit er i tekniske rapporter ofte ganske kort sammenlignet med opgaver og projekter på samfundsfaglige og humanistiske uddannelser.

Teoriafsnit i tekniske projekter Tekniske projekter indeholder sjældent dybere beskrivelser af teori, teoriens grundantagelser og omstændighederne omkring teoriens oprindelse. For eksempel ser man ikke et afsnit om, hvem hr. Ohm var, og hvordan hans teori om elektrisk modstand opstod (fx at hr. Ohm levede i 1800-tallets Tyskland). Naturvidenskabelig viden er oftest såkaldt nomotetisk viden, dvs. viden om alment gyldige lovmæssigheder. I projekter på samfundsfaglige og humanistiske uddannelser er diskussioner om grundantagelser og omstændigheder omkring teoriers udvikling vigtige (fx Max Webers teori om bureaukratiet og Keynes' teori om statens rolle i et samfunds økonomiske udvikling). De er vigtige, fordi en teoris grundantagelser indgår i argumentet om, hvorfor en teori er relevant og anvendelig i et givet projekt. Teorier inden for disse fagområder er sjældent nomotetiske, men i stedet ideografiske, hvilket vil sige, at de gælder for enkelthændelser. For eksempel siger en teori, at USA oplevede stor økonomisk vækst i 1960-1980 på grund af en stor og købestærk middelklasse. Denne teori forklarer fint væksten i USA i 1960-1980, men kan

den også forklare væksten i Tyskland i samme periode? Hvis et projekt handler om at forklare den tyske vækst, så må projektgruppen argumentere for, at teorien om amerikansk vækst kan bruges.

Lokale teoriafsnit Ud over det globale teoriafsnit indeholder et projekt en række lokale afsnit, der bringer faglig viden (fx modeller og metoder) ind i projektet. Det kunne være som del af projektets løsningsdesign og implementering. Disse afsnit med modeller og metoder bør placeres de steder i jeres rapport, hvor I anvender dem.

Eksempel på lokale afsnit med modeller og metoder Et projekt handler om udviklingen af en vindueskarm til en ny type energiruder. Projektet har identificeret og specificeret de relevante krav til vindueskarmen og har inddelt løsningsdesignet i en række underaktiviteter, der handler om at besvare en række væsentlige designspørgsmål: Hvordan skal vindueskarmene fastholde ruderne? Hvordan holdes gassen mellem ruderne indelukket? Hvordan skal gummilisterne sikre den fornødne tæthed? Projektet arbejder med de tre spørgsmål og anvender til dette formål faglige metoder og modeller. For eksempel konstruktionsnormer om, hvordan rudernes vægt stiller krav til rammerne (fx deres mekaniske egenskaber). Projektrapporten beskriver disse metoder og modeller lokalt i løsningsdesignets underafsnit.

De to HV-spørgsmål Kapitel 4 nævner to korte HV-spørgsmål for valget af faglig litteratur og dermed en teori, formel, standard, regelsæt, faglig norm, etc. De to HV-spørgsmål er: 1. Hvorfor er netop denne model eller metode valgt? 2. Hvordan skal denne faglige litteratur anvendes i projektet? Det er ikke altid nødvendigt at besvare disse to spørgsmål eksplicit i jeres rapport. Inddragelsen af teori kan være selvindlysende for en læser (fx brugen af Ohms lov ved beregning af elektrisk modstand). Reflektér grundigt over, om læser vil betragte et givet valg af teori som en selvfølgelighed. Hvis ikke, så besvar de to HV-spørgsmål.

Hvorfor-spørgsmålet binder den valgte teori sammen med projektets tidligere afsnit. Hvordan-spørgsmålet binder den valgte teori sammen med de senere afsnit i rapporten, hvor I bruger teorien. Svarene på de to HV-spørgsmål er dermed med til at sikre projektets røde tråd. Husk ikke at inddrage teori, som I ikke bruger aktivt, og husk, at den rene beskrivelse af en valgt teori skal være så kort som mulig. En klassisk faldgrube i projekter på tværs af næsten alle uddannelser er, at eksaminator og censor tænker: "Hvorfor er det lige, jeg læser dette?". Besvarelsen af de to HV-spørgsmål skal gøre det helt klart for læseren, hvorfor projektet beskriver en valgt teori, formel, standard, regelsæt, faglig norm, etc.

Figur 12.1. De to HV-spørgsmål

Eksempel på en teoris plads i et projekt og sikring af den røde tråd Et projekt handler om, at gummipakningerne (O-ringe), der sidder mellem to stålemner, smuldrer for hurtigt. Projektgruppen vil derfor øge gummipakningernes holdbarhed. Gruppen undersøger, hvorfor pakningerne smuldrer så hurtigt. Til denne undersøgelse anvender projektgruppen teori om (a) gummipakninger og (b) ståloverflader. Læser har to spørgsmål til anvendelsen af teori: "Hvorfor lige netop denne teori?" og "Hvordan har projektgruppen tænkt sig at bruge teorien senere i projektet?" For at svare på det første HV-spørgsmål sørger projektgruppen for grundigt at argumentere for, hvorfor de har valgt at inddrage teori om gummipakninger og ståloverflader. Argumentationen lyder således: 1. Teori om gummipakninger bruges til at forstå, hvordan gummitype og pakningsudformningen påvirker holdbarhed 2. Teori om ståloverflader forklarer, hvordan typen af stål påvirker overfladeruheden i de færdige stålemner efter overfladebehandling (galvanisering, hvor der lægges et lag af zink på overfladen). For at besvare det andet HV-spørgsmål om, hvordan teorien skal anvendes, så forklarer projektgruppen følgende: 1. Teorien om gummipakningsmateriale og -udformning skal bruges til at vurdere, om den aktuelt valgte paknings materiale og udformning er årsagen til, at pakningerne smuldrer for hurtigt

2. Teorien om ståloverflader skal bruges til at undersøge, om det aktuelle stål resulterer i en grov overfladeruhed, der får pakningerne til at smuldre hurtigt. Forklaringerne sikrer, at læseren ikke undrer sig over valget af teori og forstår teoriens plads i projektets røde tråd.

Projektets metode projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I et teknisk projekt er målet med metodeafsnittet at overbevise læser om, at metoden vil lede til udviklingen af en god og effektiv løsning på projektets problem. Konklusionen i et teknisk projekt er en sammenfatning af projektets løsning. Hvis metoden leder til en god og effektiv løsning, er projektets konklusion valid (gyldig). Metodeafsnit er ofte meget kortere i tekniske projekter end i humanistiske og samfundsfaglige projekter.

Metodeafsnittet i tekniske projekter For tekniske studerende, herunder ingeniørstuderende, er metodeafsnittet et af de mest mytiske afsnit i projektet. Mange tekniske studerende har fået et af følgende spørgsmål af en (ofte målløs) humaniorastuderende ven: "Har I ikke noget metodeafsnit?!" eller "Er jeres metodeafsnit kun to sider?!" Metodeafsnit i tekniske projekter er kortere og adskiller sig væsentligt fra metodeafsnit i humanistiske og mange samfundsfaglige projekter. Det er der flere grunde til: 1. Projekter på humanistiske og samfundsfaglige uddannelser beror på vigtige videnskabsteoretiske valg, som projektrapporten bør redegøre og argumentere for. Fordi videnskabsteori er en abstrakt disciplin med mange særegne begreber, kræver dette god plads. Tekniske projekter beskriver, jf. kapitel 5, kun sjældent videnskabsteoretiske valg. 2. Projekter på humanistiske og samfundsfaglige uddannelser handler ikke om at designe løsningen på et problem, men om at gennemføre en undersøgelse, der resulterer i svaret på et aktuelt ubesvaret spørgsmål. Fordi der er tale om én samlet undersøgelse, beskriver projektet metoden til hele undersøgelsen i ét langt metodeafsnit. Et teknisk projekt beskriver typisk metoder flere steder lokalt i rapporten, ofte som integrerede dele af andre afsnit. Derfor er metodeafsnittet, der ligger tidligt i rapporten, naturligt mindre. 3. Tekniske projekter handler om at designe løsninger på problemer, og en projektgruppe skal i projektrapporten demonstrere faglige færdigheder i løsningsdesign (fx design af en ny motor, en hurtigere app eller et mere holdbart produkt). På humanistiske og samfundsfaglige uddannelser handler fagligheden ikke om at udvikle løsninger, men om at gennemføre undersøgelser. En projektgruppe skal i deres rapport demonstrere deres evner i at designe og gennemføre en undersøgelse. Dette sker i metodeafsnittet, og derfor er afsnittet langt.

4. Projekter på humanistiske og samfundsfaglige uddannelser handler tit om "bløde" begreber (fx glæde, fred, lykke, motion, sammenhængskraft og konkurrenceevne). Projektrapporten skal definere disse begreber præcist, og dette kræver ofte lange afsnit. Tekniske begreber er ofte mere præcise og har klare måleenheder (fx energiforbrug [kWh], vægt [gram] og støjniveau [decibel]).

Praktisk måde at beskrive projektets metode En intuitivt forståelig måde at beskrive projektets metode på er først at beskrive de store afsnit, projektrapporten er inddelt i, og derefter beskrive den metode, der er anvendt i de enkelte afsnit. Rækken af 'store afsnit' er projektstrukturen. Først at beskrive de store afsnit og derefter detaljerne i disse afsnit er en hierarkisk metodebeskrivelse. Hierarkisk betyder først at starte med de overordnede linjer og derefter gå i detaljer. Bemærk, at metodeafsnittet ikke skal beskrive problemanalyse, valg af problem og afgrænsninger. Disse afsnit ligger forud for metodeafsnittet og er afsluttet, når læser når metodeafsnittet. Metodeafsnittet beskriver de kommende dele af projektet. Figur 12.2  illustrerer på en A4-side, hvordan I kan beskrive metoden i jeres rapport. Øverst på siden vises en figur af projektets overordnede struktur. Under figuren beskrives projektstrukturen med ord, og længere nede på siden beskrives hvert enkelt af skridtene i projektstrukturen.

Figur 12.2. Metodeafsnittet i et teknisk projekt

Metodeafsnittet handler særligt om jeres analysearbejde, som I kan være detaljerede omkring. Når I beskriver metoden for analysen, så husk at bruge (og referere eksplicit til) jeres faglige litteratur. Kapitel 5 fortæller, at metodeafsnittet ikke detaljerer metode for løsningsdesign, test og implementering. Valg af metoder foregår nemlig (formelt set) så tidligt i processen, at I ikke kender årsager til projektets problem eller krav til løsningen. Disse ting kender I først, når analysen er overstået, og det er først, når årsager og krav er på plads, at I kan være konkrete omkring metoden for løsningsdesign, test og implementering. Metoden for løsningsdesign, test og implementering skal også være med i rapporten. Disse beskrivelser ligger som lokale afsnit længere fremme i rapporten. Hvis I har udarbejdet et generisk, hierarkisk problemtræ, som I har præsenteret tidligere i rapporten, så anvend dette træ til at vise læser, hvad I konkret vil undersøge i jeres analyse. Lav gerne en figur, der udleder jeres konkrete analyseopgaver ud fra problemtræet, jf. figur 4.4. Vær specifik omkring, hvordan I vil indsamle data, fx indhente talmateriale, gennemføre et eksperiment, foretage interviews, til hver enkelt af jeres konkrete analyseopgaver. Kom gerne med nogle overvejelser omkring, hvordan I vil sikre, at jeres data er valide og pålidelige.

Særligt for eksperimenttunge projekter

Inden for nogle tekniske uddannelser (fx kemi og biotek), er det almindeligt, at et projekts analyse er et eksperiment. Hvis et eksperiment er det væsentlige i jeres projekt, bør I beskrive jeres metode for dette eksperiment nøje. Heri skal indgå en beskrivelse af udstyr, protokoller, kemikalier, det datasæt, eksperimentet skal resultere i, hvordan I analyserer data, og hvordan I foretager konklusioner. Eksperimenttunge projekter har meget til fælles med teknisk forskning. Det betyder, at læser typisk vil forvente et litteraturreview som en del af projektrapporten, og at projektet i et diskussionsafsnit fortæller, hvordan eksperimentets resultater bidrager til den eksisterende viden. Se mere om teknisk forskning i kapitel 16.

Metodebeskrivelser lokalt i projektet Det er ganske almindeligt, at tekniske projekter indeholder en række mindre, lokalt placerede metodebeskrivelser. Dette kan være referencer tilbage til og udbygninger af projektets metodeafsnit. Det kan også være beskrivelser af metoder, der ikke tidligere er nævnt, fx metoden for løsningsdesign og implementering. Når I beskriver metoden for løsningdesign og implementering, så husk at bruge (og referere eksplicit til) jeres faglige litteratur. Den faglige litteratur indeholder de gængse regler for, hvordan man designer en løsning inden for jeres fagområde. For eksempel, hvordan man designer en bro, udvikler en app eller konstruerer en maskine. Læser bør vide, at I udvikler løsningen med hjælp fra jeres faglige litteratur. Det giver troværdighed.

Den mytiske "røde tråd" Flere bøger om gode opgaver og projekter skriver, at en opgave skal forstås som ét langt argument for konklusionen. Dette er et ganske godt princip, der også gælder tekniske projekter. Når rapporten læses, skal læser have en følelse af selvfølgelighed. Gode rapporter får læser til at tænke følgende tanker: "Selvfølgelig er det den problemformulering, når problemanalysen viser det, den viser." "Selvfølgelig er det den faglige litteratur og teori, der inddrages, når problemformuleringen er, som den er." "Selvfølgelig er metodevalget dette, når problemformuleringen og den valgte litteratur og teori er, som de er." "Selvfølgelig er analysens resultater dette, når analysen følger den valgte metode." "Selvfølgelig er projektets løsning denne, når analysen siger det, den siger." "Selvfølgelig er konklusionen denne, når løsningen er, som den er."

Hvis læser får disse tanker, når projektet læses, fremstår løsningen og konklusionen som bundsolid. Læser er overbevist om, at den foreslåede løsning faktisk løser projektets problem, og at konklusionen derfor er valid (gyldig). Projektrapporten har med andre ord en tydelig rød tråd, der går fra problemformuleringen til løsningsdesignet. For at opnå denne sammenhæng mellem afsnittene bør projektrapporten skrives i en ideel, lineær og formel rækkefølge. Jeres faktiske projektforløb kan have været et kaotisk virvar, men rapporten skal skrives som det ideelle, lineære projektforløb, der leder til projektets konklusion.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Et teknisk projekt handler om at forbedre noget eksisterende eller designe noget nyt. Hvis førstnævnte er tilfældet, handler projektets analyse om at identificere årsagen (i ental eller flertal) til projektets problem, og hvis sidstnævnte er tilfældet, handler analysen om at definere kravene til projektets løsning. Ofte indeholder analyser i projekter, der designer noget nyt, også en analyse af emnets subsystemer, og hvilke tekniske muligheder der er inden for hvert subsystem (se mere om dette i kapitel 6). De følgende afsnit gennemgår de to typer af analyser hver for sig.

Analyseafsnittet i projekter, der forbedrer noget eksisterende Projektets afsnit om problemformuleringen har defineret projektets problem, og analyseafsnittet skal beskrive, hvordan I korrekt identificerer problemets årsag(er).

Størrelsen på projektets problem Hvis ikke størrelsen på problemet er kendt, er det jeres opgave at måle problemets størrelse. Beskrivelsen af jeres målinger og resultater skal være første del af analyseafsnittet.

Eksempel på et problems størrelse En virksomhed vil gerne reducere kassationsraten fra en produktionslinje. Virksomheden måler løbende kassationsraten, og den aktuelle måling viser, at den er på 23 %. Virksomheden vil gerne have den ned på 3 %, som er kassationsraten på en række af virksomhedens sammenlignelige produktionslinjer. Forskellen mellem 23 % og 3 %, altså 20 %, udtrykker størrelsen af projektets problem. I eksemplet måler virksomheden løbende kassationsraten, der derfor er kendt, inden I påbegynder projektet. I mange projekter mener virksomheden dog blot, at variablen er dårlig, uden at have konkrete målinger. Problemet eksisterer, men størrelsen er ukendt. Hvis I arbejder med et projekt, hvor størrelsen er ukendt, er det jeres opgave i analysen at foretage målinger, så I kan vise, hvor stort problemet er. Målingen af problemets størrelse kan tage flere ugers dataindsamling og udgør en væsentlig del af jeres analysearbejde. Indsæt resultatet af jeres undersøgelse tidligt i analyseafsnittet, og husk i metodeafsnittet at beskrive jeres undersøgelsesmetode, så læser vil opfatte størrelsen på projektets problem troværdigt.

Årsagsanalysen Analysens opgave er at identificere årsagen (i ental eller flertal) for projektets problem. I skal vise læser, hvordan I arbejder jer gennem de årsag-virknings-stier, der går mellem projektets problem og problemets årsager. Hvis I har vist læser et generisk problemtræ med konkrete analyseopgaver, så brug dette aktivt (kapitel 4 beskriver, hvordan I udarbejder et generisk problemtræ). Figur 12.3 viser et problemtræ. Den blå streg er én årsag-virknings-sti, der i figuren består af en række kasser og pile. Pilene udtrykker relationerne mellem kasserne.

Figur 12.3. Problemtræ med årsag-virknings-stier

I analyseafsnittet kan I illustrere og beskrive jeres faktisk gældende problemtræ. Jeres fineste opgave i analyseafsnittet er at overbevise læser om, at de relationer, som I mener, der er mellem kasserne i det faktiske træ, er reelle. For at gøre det klart for læser, at der er en relation mellem to kasser på en årsagvirknings-sti, kan I anvende kvantitative analyser (fx statistiske regressionsanalyser) eller kvalitative analyser (fx at to medarbejdere i virksomheden uafhængigt af hinanden har fortalt om sammenhængen mellem de to kasser, og at deres forklaringer af sammenhængen giver god logisk mening). Uagtet typen af data er det vigtigste, at læser er overbevist om, at sammenhængen er reel. Hvis I anvender kvantitative analyser, bør I bruge grafer og diagrammer til at vise resultaterne. Undgå at sætte hele og halve sider med taludtræk fra Excel direkte ind i rapporten. I analysearbejde er det jeres (og ikke læsers) opgave at trække de væsentligste resultater frem. Husk at inkludere både rådata og bearbejdede data i rapportens bilag (evt. elektronisk). Se mere om brugen af diagrammer og talpræsentation i kapitel 13.

Når problemtræet med de faktisk gældende årsag-virknings-stier er på plads, og I har styr på de adresserbare årsager (root causes), så er jeres opgave at tydeliggøre størrelsesforholdet mellem de adresserbare årsager. En "stor" årsag er en årsag, der har stor effekt på projektets problem.

Eksempel på størrelsesforholdet mellem adresserbare årsager Et projekt handler om at minimere den tid, som en bruger af en bycykel anvender på at komme i gang med at bruge cyklen. Denne tid går med at registrere navn, kreditkortoplysninger osv. på bycyklens software samt at trække bycyklen fri af stativ og lære den basale brug af cyklen at kende.

Projektgruppen har målt, at den gennemsnitlige ibrugtagning af en bycykel tager 7 minutter. Gruppen har analyseret ibrugtagningens enkelte skridt og undersøgt de mulige tekniske løsninger, der kan afhjælpe hvert skridts tidsforbrug. Deres analyse viser tre årsager til den alt for lange tid: 1. Brugeren venter unødigt længe på, at softwaren starter op 2. Brugeren venter unødigt længe på, at kreditkortoplysningerne registreres 3. Det tager brugeren unødigt lang tid at tage cyklen ud af stativet på grund de mekaniske sikkerhedsforanstaltninger (bl.a. en skrue, der skal løsnes med et svensknøglelignende redskab, og en bøjle, der skal løftes). Spørgsmålet er, hvilken af disse tre årsager, der er størst. Projektgruppen måler de tre årsagers tidsforbrug for 50 stk. ibrugtagninger af bycyklerne. De finder, at den gennemsnitlige unødige tid for softwareopstart er 2,23 minutter, for registrering af

kreditkortoplysninger 0,84 minutter og for håndtering af mekaniske sikkerhedsforanstaltninger 0,71 minutter. Disse tre tal fortæller, at årsag nummer 1 er stor, og årsag 2 og 3 er små. Dette illustrerer de grafisk på følgende måde:

Ideelt bør I anvende diagrammer, der kvantitativt demonstrerer størrelsesforholdet mellem årsagerne. Nogle gange har man dog ikke adgang til tilstrækkeligt mange kvantitative data (fx antal observationer) til at kunne fastslå størrelsen. I disse tilfælde må I kvalitativt vurdere, om årsagerne er store eller små. Husk at involvere de relevante personer i virksomheden og evt. jeres vejleder, så I får pålidelige kvalitative vurderinger. Derefter kan I dele årsagerne ind i to grupper af store og små årsager, eller evt. fire eller fem kategorier rangerende fra stor til lille. I projektrapporten skal I gøre det klart for læser, hvordan I finder størrelsesforholdet, og forklare, hvorfor læser kan være sikker på, at jeres vurderinger er pålidelige. Når I har beskrevet størrelsesforholdet, kan I argumentere over for læser, hvorfor I evt. fravælger at designe løsninger til nogle af årsagerne. Kapitel 6 beskriver et eksempel på et projekt, der handler om fejl i en produkttest. Analysen i eksemplet identificerer fem årsager, jf. figur 6.2. Projektgruppen vælger dog kun at designe løsninger til to af dem, fordi disse to årsager tilsammen står for langt hovedparten af fejlene, jf. figur 6.5.

Analyseafsnittet i projekter, der designer noget nyt fra bunden Hvis I designer noget nyt fra bunden, skal I sikre jer, at løsningen overholder alle relevante krav. Nogle krav er generelle for den type løsning, I designer (fx skal alle bygninger overholde kravene i bygningsreglementet). Andre krav er specifikke for jeres løsning (fx at bygningen skal have fire rum a 100 kvm). Kapitel 4 fortæller, hvordan I kan bruge faglig litteratur til at identificere de generelle krav til jeres løsning. De specifikke krav til jeres løsning finder I frem til gennem jeres analysearbejde. I projektrapporten kan I beskrive alle kravene et efter et i afslutningen af jeres analyseafsnit. Angiv gerne følgende: Hvad kravet konkret er. Husk at angive enhed.

Hvorfor kravet er med. Forklaringen herpå udspringer enten direkte af virksomhedens løsningsbehov eller af et generelt krav (fx en regel, faglig standard eller norm), ellers er det et specifikt krav, som I har identificeret i jeres analysearbejde. Hvordan kravet påvirker jeres løsningsdesign. Ved at forklare dette bliver I bevidste om, hvordan kravene påvirker jeres løsning, og forklaringen binder afsnittene om analyse og løsningdesign godt sammen. Om kravet er et absolut krav eller et "så godt som muligt-krav" (se mere om dette i kapitel 6). I nogle tekniske udviklingsprocesser foregår identificering af krav og løsningsdesign i en såkaldt iterativ proces, hvor projektgruppen flere gange vender tilbage til kravene. Projektrapporten skal I dog skrive som ét lineært forløb, der én gang beskriver alle krav til løsningen.

Krav bør være operationelle Kravene til løsningen skal være konkrete og operationelle. Et operationelt krav er et krav, I kan anvende direkte i løsningsdesignet uden yderligere fortolkning eller konkretisering. Et ikke-operationelt krav kan fx være, at en løsning skal "være af høj kvalitet og klare skiftende temperaturer". Denne formulering er ikke operationel og kræver yderligere analyse for at konkretisere kravet. En operationel version af dette krav kunne være, at løsningen "skal kunne fungere i 24 timers drift i temperaturintervallet -30 til +50 grader Celsius". Dette krav kan I anvende direkte, når I vælger materiale til sliddele, i designet af emnets ydre isolering og til vurderinger af vedligeholdelsesfrekvens, der sikrer mod nedbrud ved 24-timers brug.

Styr på løsningens subsystemer (funktioner) Ud over kravene til løsningen indeholder analyseafsnittet ofte en analyse af de subsystemer, emnet består af, og hvilke tekniske muligheder der er for at realisere hvert subsystem. Et ofte anvendt synonym for subsystemer er funktioner. I projektrapporten skal I beskrive: Hvilke subsystemer emnet består af De tekniske løsningsmuligheder, der er for hvert subsystem. Rækken af tekniske løsningsmuligheder for hvert subsystem er grundlaget for jeres løsningsdesign. For at understøtte læsers overblik over analysens resultater kan I fx i jeres projektrapport afbillede subsystemer og tekniske løsninger i et morfologisk diagram (se figur 6.8).

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I rapporten skal I med både ord, tegninger, illustrationer, beregninger mv. beskrive, hvad jeres løsning konkret er, og hvordan løsningen løser problemet i problemformuleringen. Et teknisk projekt tester og implementerer fra tid til anden sin løsning. Hvis dette er tilfældet, vil resultaterne fra testen og implementeringen give håndfaste beviser på, at løsningen faktisk løser problemet og implementeres i virksomheden. Mange tekniske projekter når dog ikke frem til test og implementering, og derfor beror troværdigheden af jeres løsning direkte på jeres projekts røde tråd. Læser skal derfor – afsnit for afsnit – være overbevist om, at jeres analyse leder til de rigtige årsager til problemet, og at jeres løsning faktisk vil eliminere disse årsager eller reducere deres effekt.

Beskrivelse af løsning Kapitel 7 fortæller, at en løsning oftest er en enkeltløsning, en "enten-eller"-løsning eller en sammensat løsning. En enkeltløsning er fx en app, der udvikles, så den overholder alle kravene i en kravspecifikation. En "enten-eller"-løsning er to-tre løsninger, man skal vælge imellem. Et eksempel er to typer broer og en tunnel, der alle kan forbinde en ø til fastlandet. Bygherre skal vælge "enten-eller". En sammensat løsning er en samling af løsningselementer, der hver især adresserer en årsag i et projekts problemtræ. Et projekt har fx skitseret syv løsningselementer, hvoraf projektet prioriterer løsningselement 1, 3, 4, 5 og 7 og fravælger element 2 og 6. De prioriterede løsningselementer udgør tilsammen projektets sammensatte løsning. Hvilken type løsning I arbejder med, har stor indflydelse på indholdet i rapportens løsningsdesignafsnit. Med en "enten-eller"-løsning og en sammensat løsning skal afsnittet i jeres projekt ikke blot redegøre for den endelige løsning, men også for de skitseløsninger, I fravælger, og den proces, der leder til valget af den endelige løsning. De følgende afsnit fortæller, hvad løsningsafsnittet for hver af de tre løsningstyper skal indeholde.

Enkeltløsning En enkeltløsning skal beskrives, så læser kan forstå, hvad løsningen er, hvilke funktioner løsningen har, og evt. hvordan elementerne i løsningen interagerer. Enkeltløsningen er ofte aktuel i projekter, der udvikler noget nyt fra bunden. Analysen har identificeret og specificeret et sæt operationelle krav og nedfældet dem i en samlet kravspecifikation. Løsningsafsnittet skal beskrives og illustreres, så læser klart kan forstå løsningen. Løsningen opfylder en række krav. Det er vigtigt for den røde tråd i rapporten, at I klargør for læser, hvordan løsningen lever op til de enkelte krav i kravspecifikationen.

Processen for udviklingen af en enkeltløsning kan variere. Én mulighed er den klassiske metode, hvor I først definerer alle krav og derefter udvikler løsningen. Andre metoder er iterative og arbejder i flere cyklusser, der hver især ender med udviklingen af en prototype eller elementer af en prototype. Test af prototypen kan betyde finjustering af krav eller funktioner. Iterationerne kan også resultere i nye krav eller nye funktioner. Løsningsafsnittet skal I skrive, som om I én gang har udviklet en løsning, der lever op til alle krav. Rent praktisk er det vigtigt i løsningsafsnittet at udtrykke løsningen både i skrift og figurativt med illustrationer. Ingeniører og andre teknisk uddannede kommunikerer med tekniske tegninger, diagrammer, grafer, fotos, skitser, alskens former af kasse-pilediagrammer, etc. Nogle af disse kommunikationsformer er standardiserede inden for den branche, som uddannelser uddanner kandidater til. Tekniske tegninger følger en standard, fx Geometriske Produktspecifikationer (GPS), diagrammer til software følger tit UML-standarden (Unified Modeling Language), og diagrammer af en LEAN-produktion følger reglerne for en værdistrømsanalyse (VSM: Value Stream Mapping).

"Enten-eller"-løsning Reglerne for beskrivelsen af enkeltløsningen gælder også for "enten-eller"-løsningen (fx at løsningen skal leve op til kravspecifikationen). Der er dog her en række ekstra ting at beskrive. Et løsningsafsnit om en "enten-eller"-løsning har oftest en tretrinsstruktur som vist i figur 12.4.

Figur 12.4. De typiske trin i "enten-eller"-løsningen

Første trin er at skitsere to eller flere mulige løsninger, der overholder kravene til løsningen fra analyseafsnittet. Skitsering af løsninger sker på et grovere niveau end enkeltløsningen. De fleste fagområder har standardiserede metoder til skitsering. På byggeuddannelser viser en skitse, hvordan en bygning, et vejkryds eller en togstation kan se ud. Skitseprojektet viser det færdige resultat, men uden detaljerne (fundamentet, lydisolering, placering af lamper, mv.). Selv på skitseniveau er det muligt at vurdere den enkelte løsnings effekt, økonomi og implementerbarhed. Når skitser af mulige løsninger er udarbejdet, kommer det måske vigtigste trin i projektet, nemlig valget af den ene, endelige løsning. Når I beskriver dette valg, så detaljér gerne beslutningsprocessen og de personer, der træffer beslutningen. Det kan være en god ide på forhånd at have reflekteret over, hvordan I som projektgruppe vil facilitere beslutningen

af den endelige løsning. Beslutningsprocessen bør have det mål, at personer, der skal foretage beslutningen, har et informationsgrundlag, der er så godt som muligt. De skal være informeret grundigt om følgende: Projektets problem (i "enten-eller"-projekter er dette ofte et løsningsbehov) De krav til løsningen, som I har udledt (fx de tekniske, juridiske og brugerbaserede krav) De mulige løsninger, der er specificeret på skitseniveau. Husk især de første to punkter, da disse danner grundlaget for vurderingen af løsninger. Hvis I selv har gennemført en analyse af løsningernes kravoverholdelse, så husk at inddrage denne analyse i beslutningsprocessen (se kapitel 7 for et eksempel på en sådan analyse). Beskriv beslutningsprocessen i løsningsafsnittet, så læser tydeligt kan se jeres professionelle facilitering af beslutningstagernes valg. Sidste del af løsningsafsnittet består af at detaljere og specificere den valgte løsning. Detaljeringsgraden bestemmes af uddannelsens krav. Specifikationen bør inkludere en udførlig vurdering af løsningens økonomi (se nærmere i kapitel 7).

Sammensat løsning Reglerne for beskrivelsen af enkeltløsningen gælder også for den sammensatte løsning. Der er dog ligesom ved "enten-eller"-løsningen en række yderligere ting at beskrive i løsningsafsnittet. Et løsningsafsnit om den sammensatte løsning har oftest en tretrinsstruktur som i figur 12.5.

12.5. De typiske trin i den sammensatte løsning

Først udvikler I en række løsningselementer. Analysen har specificeret årsagerne til projektets problem, og det er jeres opgave at udvikle løsningselementer, der adresserer årsagerne. Derefter prioriterer I blandt de udviklede løsningselementer og specificerer det valgte sæt af løsningselementer.

Eksempel på sammenhængen mellem årsager og design af løsningselementer En projektgruppe skal øge hastigheden på et måleinstrument, der bruger alt for lang tid på at foretage målinger. Projektgruppen vil altså reducere tiden, fra en måling påbegyndes, til målingsresultatet er klart. Projektgruppen har fundet frem til tre årsager til

det lange tidsforbrug: 1. Instrumentet tager unødigt mange enkeltmålinger for at nå et resultat. 2. Det tager lang tid for maskinens sensorer at sende signaler til den algoritme, der beregner resultatet. En række nyere sensorer er hurtigere. 3. Instrumentet kvalitetssikrer måleresultatet gennem kommunikation mellem instrumentet og en cloud-baseret testprocedure. Dette kan gøre meget hurtigere lokalt i maskinen. Projektgruppen udvikler i alt otte tiltag, som virksomheden kan implementere i produktet (blandt andet nye sensorer og lokal kvalitetssikring). Disse otte tiltag, der minimerer hastigheden mellem målinger og resultat, udgør løsningselementerne i projektet. Det næste skridt er at prioritere, hvilke af disse otte løsningselementer der skal indgå i den endelige løsning. I projektrapporten skal I redegøre for sammenhængen mellem årsager og løsningselementer og specificere de enkelte løsningselementer med et detaljeniveau, der gør det muligt at vurdere effekt, økonomi og implementerbarhed. Løsningselementerne præsenteres altså med en grovkornet detaljeringsgrad på samme måde som de alternative løsninger i "enten-eller"-løsningen. Til at give et samlet billede af løsningselementernes effekt og implementerbarhed kan I anvende en prioriteringsmatrix som illustreret i figur 7.3. Inkludér i jeres beskrivelse af prioriteringen, hvordan I inddrager virksomheden og sikrer, at virksomheden føler ejerskab til det endelige valg af løsningselementer. Til slut beskriver I de prioriterede løsningselementer på et mere detaljeret niveau.

Beskrivelse af løsningens effekt og økonomi Som en del af løsningsafsnittet er det vigtigt, at I så præcist som muligt angiver den effekt, jeres løsning vil have på projektets problem. Ofte er det svært at vurdere denne effekt præcist. I sådanne tilfælde er der to muligheder. I kan i rapporten skrive et cirka tal med få betydende cifre (fx "ca. 10 %") eller, endnu bedre, angive et interval, som effekten vil ligge inden for (fx 5-15 %). Der er selvfølgelig stor forskel på 5 % og 15%, men I fortæller dog læser, at effekten ikke er 1 % eller 50 %. Husk i løsningsafsnittet at argumentere for, hvorfor intervalgrænserne er sat, som de er. Ellers er følgende spørgsmål oplagt ved eksamen: "Hvorfor skal vi tro på minimum 5 %'s forbedring?" Når I har vurderet effekten, er næste opgave at vurdere den økonomiske værdi af effekten. Dette kalder vi i denne bog for løsningens indtægter. I løsningsafsnittet skal I angive disse indtægter. Husk at angive enheden (fx "kr./stk.", "kr./år", "kr./medarbejder", "kr./time/produkt" eller lignende).

Husk, at løsningen skal være realiserbar Når I beskriver løsningens økonomi, så vær opmærksom på, at besparelser bør være realiserbare. En løsning kan fx resultere i tidsbesparelser på 15 sekunder her og 10 sekunder der, men hvis disse sekunder ikke kan rundes op til én hel medarbejder, hvordan skal besparelsen så realiseres? Når I har redegjort så præcist som muligt for løsningens indtægter, så redegør for den nødvendige investering, driftsomkostninger og til slut løsningens samlede økonomi. Se en nærmere beskrivelse af konkrete metoder til beregning af løsningens økonomi i kapitel 7. Vis gerne en række grafer over effekt og økonomi. Det kunne være et søjlediagram over udviklingen i indtægter og omkostninger eller et lagkagediagram over omkostningsfordelingen.

Test af løsning | Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Test af løsning

Hvis det er praktisk muligt, så gennemfør en test, om jeres løsning har den effekt, I forventer. I projektrapporten beskriver I testens formål, metode, resultater og også gerne robusthed (kan man stole på testens resultater). Testafsnittet indgår enten som en del af det afsnit, der beskriver løsningen, eller som et selvstændigt afsnit, som I kan placere lige efter løsningsafsnittet. Test har en naturlig funktion i projektet og er med til at sikre den røde tråd. I projekter, der forbedrer noget eksisterende, har problemet i problemformuleringen en eller flere årsager. Projektets analyse har identificeret årsagerne. De løsninger, som projektet har udviklet, eliminerer disse årsager eller reducerer deres effekt.

Figur 12.6. Testens to funktioner

Figur 12.6 viser et problemtræ. I venstre side er projektets problem. I højre side viser figuren en grøn kasse. Dette er en løsning, der eliminerer en årsag til problemet. Testen af løsningen kan vise to ting:

Om løsningen faktisk eliminerer den årsag, den adresserer Om elimineringen af årsagen faktisk reducerer projektets problem. I projekter, der designer noget nyt fra bunden, er projektets problem ofte et behov for en løsning (dvs. et ønske om noget, der aktuelt ikke findes). I sådanne projekter specificerer analysen alle krav til løsningen og samler dem i en kravspecifikation. Når I har designet løsningen, kan I teste, om løsningen rent faktisk overholder kravene. De enkelte tekniske fagområder har hver deres metoder at teste med. På uddannelser, hvor løsningen tegnes og specificeres (men ikke konstrueres), foregår tests ofte med test- og simuleringsværktøjer. På softwareuddannelser testes apps, programmer og enkeltdele af en løsning løbende som en naturlig del af løsningsdesignet. Der kan testes for funktionalitet, robusthed, hastighed mv. På maskinuddannelser foretager projektgruppen typisk test af vigtige enkeltelementer (fx brudstyrken på et kabinet).

Implementering af løsning projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Et godt projekt designer ikke blot en løsning, men forholder sig også til, hvordan virksomheden skal implementere løsningen. En plan for implementering er derfor ofte et vigtigt afsnit i rapporten. Begrebet 'implementering' forstås forskelligt fra fagområde til fagområde og kan fx betyde at 1) bygge huset, 2) embedde programkoden i et større program, 3) produktionsmodne et nyudviklet produkt og 4) ændre processer, der involverer både tekniske ændringer og ændringer i brugeradfærd. Dette afsnit er mest relevant for implementering af løsninger, der kræver ændret adfærd. Kapitel 8 fortæller, at en implementeringsplan består af en projektplan, en projektorganisation og en plan for håndtering af modstand mod forandring. I jeres afsnit om implementering af projektets løsning kan I vise: 1. En implementeringsplan som en projektplan. Kapitel 6 beskriver, hvordan I udarbejder en projektplan med et Gantt-diagram. 2. Et organisationsdiagram over projektorganisationen. 3. En liste med kilder til modstand mod forandring og tiltag til håndtering af denne modstand.

Implementeringsafsnit i rapporter om "næsten-virkelige" projekter Nogle projekter er virkelighedsnære, men ikke forankret i en konkret virksomhed. Dette kunne fx være et projekt om designet af en bygning ud fra et virkeligt udbudsmateriale, men uden samarbejde eller kontakt med bygherre, rådgiver eller arkitekt. I disse projekter kan I (i implementeringsafsnittet) forholde jer til de mulige/typiske problemer og faldgruber for implementeringen. Hvis et projekt fx har designet en bygning ud fra bygherres udbudsmateriale, kan I (i jeres projektrapport) forholde jer til, hvilke praktiske, politiske, økonomiske og tekniske faldgruber og risici projektet kan rumme.

Konklusion og anbefalinger til virksomheden projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Konklusionen skal besvare problemformuleringen præcist og ikke være et referat af projektet. Det er næsten en klassiker, at et projekt ikke svarer på problemformuleringen, men i stedet giver et referat af, hvad projektet har gjort. Dette skal I undgå.

To gode råd til skrivning af konklusion Et praktisk råd til at sikre, at I faktisk besvarer jeres problemformulering, er at følge nedenstående procedure: 1. Åbn et nyt Word-dokument 2. Kopier problemformuleringen ind på øverste linje i dokumentet 3. Besvar problemformuleringen så præcist som muligt umiddelbart nedenunder 4. Slet problemformuleringen igen, og erstat den med overskriften "Konklusion". Et andet råd er at se på det første ord i problemformuleringen. Det første ord viser nemlig, hvad jeres konklusion skal handle om: Hvordan …

=> Sådan …

Hvilke …

=> Disse …

Hvorfor …

=> Derfor …

Hvis problemformuleringens første ord er "hvordan", forventer læseren naturligt nok et svar, der handler om "sådan", fx en ny procedure eller et nyt design på et produkt. Og hvis problemformuleringens første ord er "hvilke", forventer læseren "disse", fx en liste. I må aldrig krydse på tværs og besvare "hvordan" med "disse" eller "hvilke" med "derfor".

Konklusionens robusthed Indsæt gerne et underpunkt under konklusionsafsnittet, hvor I beskriver, hvor robust konklusionen er. Beskriv, hvor sikre I er på, at løsningen faktisk løser projektets problem. Forhold jer til mulige fejlkilder og usikkerheder i jeres data. Inkludér evt. forbehold for, at vigtige forudsætninger holder. At kunne reflektere over en konklusions robusthed viser faglig indsigt og modenhed. Robusthed udtrykker graden af, hvor sikre I er på, at den løsning, som konklusionen sammenfatter, faktisk virker.

Hellere sikre intervaller end præcise, men usikre enkelttal i

konklusionen Et løsningsforslag resulterer ofte i gevinster (fx tjente penge, forlænget holdbarhed eller højere effektivitet). I projektets afsluttende kapitler (løsningsafsnittet og konklusionen) beskriver I størrelsen af disse gevinster. Vurderingerne af størrelsen er baseret på en række input, der kan være mere eller mindre usikre. Konklusionens usikkerhed er minimum lige så stor som usikkerhederne i alle antagelserne tilsammen. Hvis I vil bygge større sikkerhed ind i jeres konklusion, så undgå at skrive et enkelttal (fx at holdbarheden stiger med 30 %). Skriv i stedet et interval (fx 20-40 %). Husk at angive, hvorfor jeres grænser er, som de er.

Perspektivering af resultater projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Perspektiveringsafsnittet giver ofte anledning til en del spørgsmål fra jer som studerende. Hvad betyder perspektivering egentligt, og hvorfor skal det med i rapporten? Et perspektiveringsafsnit har en fast plads i den klassiske undersøgelse. Det er her, forskeren indplacerer sine resultater på den hylde, hvor al den hidtidige forskning ligger. Rent praktisk fortæller forskeren her, hvilke teorier og anden forskning, som undersøgelsen understøtter, og hvilke teorier undersøgelsen modsiger. På den måde sætter forskeren sin undersøgelse i perspektiv i forhold til den øvrige forskning. Denne type perspektivering er ikke aktuel i en teknisk rapport, der løser et problem. I stedet kan I forholde jer til, om jeres løsning er brugbar i anden sammenhæng. En ny procedure kan måske anvendes i andre dele af virksomheden, en ny type bygning kan måske anvendes i andre byer, regioner eller verdensdele, og en kemisk enhedsoperation kan måske anvendes i andre typer processer. I perspektiveringsafsnittet kan I løfte hovedet lidt op fra papiret og reflektere over, hvor og hvordan jeres løsning og den øvrige viden, jeres projekt har skabt, kan bidrage til at gøre verden bedre.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Referenceliste

Lav en liste med jeres referencer (kilder), sorteret alfabetisk efter efternavnet på førsteforfatteren af kilden. Hvis kilden er en organisation, anvendes navnet på organisationen. Hvis I bruger hjemmesider som kilder, så skriv navnet på organisationen, URL og tidspunkt for, hvornår I har været på siden.

Eksempel på en referenceliste Bonnerup, B. og Jensen, B.C. (2007), Stål-konstruktioner efter DS 412, Nyt Teknisk Forlag. Bygningsreglementet (2018), §259 – Energirammer for boliger, kollegier, hoteller og lignende, http://bygningsreglementet.dk/Tekniske-bestemmelser/11/Krav, tilgået januar 2018. EU, Europa-parlamentets og Rådets Direktiv 2012/19/EU af 4. juli 2012 om affald af elektrisk og elektronisk udstyr (WEEE) (2012), http://eur-lex.europa.eu/legalcontent/DA/TXT/PDF/?uri=CELEX:32012L0019&from=EN, tilgået februar 2018. Hansen, H. (2018), Maskintimepriser, Forlaget Bautasten, København. Ingeniøren, 2. januar (2018), Eksperter splittede om bioethanol: Blindgyde eller nødvendighed?, tilgået den 16. januar 2018. Jensen, J., Knudsen, K. og Bentsen, B. (2001), "Nanotechnology for metal surface corrosion", International Journal of Corrosion, Version 34, Nummer 3, side 234-269.

Bilag og dokumentation for rådata projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Det er traditionerne på en uddannelse, der bestemmer, hvilket materiale der hører hjemme i et projekts hovedrapport, og hvilket der skal i bilagsrapporten. Der er dog et par grundregler. Hovedrapporten bør indeholde forklaringer, argumentationer for valg, metodebeskrivelser, konklusioner på analyser og beskrivelse af løsning. Bilagsrapporter bør indeholde rådata og dokumentation (fx tekniske tegninger og Excel-filer). Hvis en Excel-fil med tusindvis af rækker er et af projektets bilag, så kopier den øverste side med kolonneoverskrifter til bilagsrapporten. Fra bilagsrapporten kan I så henvise til Excel-filen. Husk sidetal i bilagsrapporten. Det kan være besværligt, fordi bilagene kommer fra mange forskellige programmer (SolidWorks, Excel, Maple etc.). Hvis rapporten skal printes, så er et smart trick at åbne et nyt Word-dokument, lave så mange sideskift, som I har bilag, indsæt sidetal, printe hele stakken kun med sidetal og derefter lægge stakken tilbage i printerens kammer til papir. I kan så printe jeres bilag på siderne med sidetal. Til eksamen bliver I ofte bedt om at slå op på specifikke sider, hvortil eksaminator og censor har spørgsmål. Hvis der ikke er sidetal i rapporten, går der dyrebar tid tabt med at finde det relevante sted – tid, som I ellers kan bruge på at svare godt på de spørgsmål, som eksaminator og censor stiller.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Opsummering

I dette kapitel har du lært, hvilke afsnit et teknisk projekt typisk består af, og hvordan jeres arbejde i løbet af projektprocessen (beskrevet i kapitel 2 til 8) bliver en del af den projektrapport, I afleverer. Kapitlet beskriver, hvordan projektrapportens enkelte afsnit skrives, så de hænger sammen og understøtter projektets røde tråd. Derudover beskriver kapitlet, hvordan I kan skrive hvert enkelt afsnit med størst mulig klarhed.

Kapitel 13. Professionel og klar formidling i tekniske projektrapporter projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I dette kapitel lærer du: Hvordan I skriver korrekt i en teknisk rapport Hvordan I kan øge klarheden og dermed læsers forståelse af jeres projektindhold Hvordan I kan sikre forståelse gennem metakommunikation og aktive sætningskonstruktioner Hvordan I mest effektivt formidler tal og kvantitative analyser Formidling gennem grafer, tabeller, illustrationer og andre grafiske virkemidler. Formidlingen i en rapport består ikke kun af sproget, men også af de grafiske virkemidler (tabeller, figurer og grafer). Dette kapitel begynder med en række råd til den skrevne tekst i en teknisk rapport. Dernæst behandler kapitlet de typiske faldgruber i formidlingen af tal og giver råd om bilag, henvisninger og fodnoter. Slutteligt handler kapitlet om præsentationen af tabeller, figurer og grafer.

Korrekt og klart sprog i en teknisk rapport projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Sproget i en teknisk projektrapport bør være neutralt, upersonligt, konkret, præcist, kortfattet og korrekt. Sprog er et tema, som er beskrevet i mange (tykke) bøger, og dette kapitel vil derfor ikke dække alle spørgsmål om korrekt sprog i rapporter. Kapitlet giver i stedet en mindre række råd målrettet sproget i tekniske rapporter.

Korrekt stavning, grammatik og tegnsætning At stave korrekt, have korrekte sætninger og anvende tegnsætning rigtigt er meget vigtigt og ofte vigtigere, end man umiddelbart tror. Hvis censor bliver irriteret over stave- og tegnsætningsfejl, så er risikoen stor for, at censor vurderer projektet dårligere, end det egentligt har fortjent. Det er sket, at en 10-talsrapport er vurderet til 02, fordi censor ikke kunne se ud over stave- eller tegnsætningsfejl. En uskreven regel, der måske ikke er helt retfærdig, men dog alligevel sidder i baghovedet på de fleste læsere, er: Den, der skriver dårligt, tænker dårligt.Note En rapport fyldt med stavefejl, grammatiske fejl og tegnsætningsfejl indikerer altså over for læser, at projektrapportens forfattere er dumme! Når studerende er dygtige og kloge, er det brandærgerligt at få en dårlig karakter på grund af en projektrapport, der ikke er sprogligt gennemarbejdet. Her er et par tips til at undgå sprogproblemer: Lad en person, der ikke er i projektgruppen, korrekturlæse rapporten. Læg hovedet i blød og tænk over, hvem du kender, som ofte retter i dit talte sprog ("Det hedder Rune og jeg drak os fulde!"). Du tænker måske på personen som en krakiler, måske endda lidt irriterende. Dette er den perfekte person. Overtal ham eller hende til trefire timers korrekturlæsning. Læs rapporten igennem igen, men denne gang bagfra – sætning for sætning. Med denne metode bliver stavefejl og grammatiske fejl pludseligt meget tydeligere end ved en almindelig "forfra-læsning".

Metatekster Metatekster er de tekster, der tager læser i hånden. De væver de enkelte afsnit sammen og er med til at skabe den røde tråd. Medmindre sammenhængen er fuldkommen klar for læser, bør der være metatekster i begyndelsen og slutningen af alle afsnit, uagtet om disse afsnit er overordnede eller underordnede i et kapitel. Det er metateksterne, der gang på gang binder projektrapporten sammen og sikrer, at læser forstår, hvordan alle dele af rapporten har del i den røde tråd.

Herunder følger nogle eksempler på metatekst. Først en række eksempler fra kapitelbegyndelser: "Formålet med dette kapitel er at planlægge løsningens implementering." "Fordi problemformuleringen handler om nedbringelsen af produktets vægt, vil dette kapitel vise, hvilke andre materialer der potentielt kunne bruges som alternativer." "Jævnfør analysen vil dette kapitel først undersøge priserne på ståltype 62 og 54 og dernæst slitagen på CNC-maskinerne, der borer hullerne i emnet." "Dette kapitel vil præsentere prioriteringen af løsningsforslag." "Kapitlet vil først sammenfatte resultaterne af analysen og dernæst beskrive de tre trin, som projektets løsningsdesign er inddelt i." "Først giver afsnittet overblik over de teoretisk mulige strategier, og dernæst beskriver afsnittet, hvordan løsningsworkshoppens deltagere vælger en konkret strategi." Den næste række sætninger er eksempler på metatekster i en kapitelafslutning. Eksemplerne viser, hvordan et kapitels afslutning bør binde afsnittets resultater sammen med fremtidige kapitler i projektet. "Kapitlet viser, at materialevalget faldt på sejjern af type KN23. I næste kapitel vil projektet vise, hvordan overfladeruheden ændrer sig som følge af det ændrede materiale." "Kapitlets resultater bruges i det følgende arbejde med løsningsdesign ved at …" "Prioriteringsworkshoppen valgte fire ud af de seks mulige løsninger. Det følgende kapitel specificerer disse løsninger." Sørg for, at alle afsnit i projektrapporten (kapitler såvel som underafsnit) begynder med minimum én sætning metatekst, fx om, hvad kapitlet/afsnittet indeholder. Det kunne være denne sætning: "Dette afsnit/kapitel viser/præsenterer/sammenfatter …". Kapitler har typisk underafsnit, og derfor bør kapitlets første sætninger beskrive, hvilke underafsnit kapitlet består af.

Eksempel på metatekst i begyndelsen af et teoriafsnit i projekt om nedbringelse af lageromkostninger "Kapitlet definerer først begrebet lager og giver en oversigt over, hvordan lageromkostninger beregnes. Dernæst sammenfatter kapitlet de teoretiske årsager til lagerhold og beskriver metoder til nedbringelse af lageromkostninger. Definition af begrebet lager Et lager er … Oversigt over, hvordan lageromkostninger konkret beregnes Lageromkostninger består dels af risikoomkostninger, husleje …

Sammenfatning af de teoretiske årsager til lagerhold I teorien om produktion og logistik findes en række årsager … Metoder til nedbringelse af lageromkostninger En produktionsvirksomhed kan nedbringe lageromkostninger på flere forskellige måder. Først … Læg mærke til to ting i eksemplet: Eksemplets øverste sætning lister de fire emner, der hver udgør et underafsnit i kapitlet. Der er sammenfald i ordvalget mellem eksemplets øverste sætning og de enkelte underafsnits titler. En god grundregel er ikke at have nogen overskrifter i en projektrapport, der er direkte efterfulgt af en underoverskrift. For eksempel således:

Skriv altid en metatekst imellem overskrift og underoverskrift. Denne metatekst skal som minimum fortælle, hvilke underafsnit det overordnede afsnit består af.

Sætningskonstruktioner Tekniske rapporter skal formidle deres indhold klart og tydeligt, og dette sker bedst med aktive sætningskonstruktioner. En redaktør på et stort internationalt videnskabeligt tidsskrift har engang udtalt følgende: Avoid the use of passive voice as much as you avoid death! (Undgå passive sætningskonstruktioner på samme måde, som du undgår døden! (Reid, 2018)) Årsagen til, at aktive sætningskonstruktioner fører til klarere sprog, er, at aktive sætninger indeholder den aktør, der udfører handlingen i sætningen. Aktøren er grundleddet i sætningen og kaldes i grammatikbøger ofte "agenten". En passiv sætning kunne fx lyde: "Komponentens holdbarhed er målt gennem gentagne prøvninger." Her er det uklart, hvilken aktør der har udført målingen. Er det mon virksomhedens QA-afdeling? Er det komponentens leverandør? Er det projektgruppen selv (altså jer selv som studerende)? Det er op til læser at udlede af sætningens kontekst. Var sætningen aktiv, kunne den lyde: "QA-afdelingen har målt komponentens holdbarhed gennem gentagne prøvninger." Her er det klart, hvem der er aktøren, dvs. hvem der har foretaget målingerne. Tabel 13.1 viser flere eksempler.

Passive sætninger

Aktive sætninger

Vinduerne blev leveret uden de nødvendige certifikater.

Producenten har leveret vinduerne uden de nødvendige certifikater.

Robotterne får testet deres operationshastighed 12 gange om året.

Produktionsteknisk afdeling tester robotternes operationshastighed 12 gange om året.

Testudstyret i udgangskontrollen kalibreres og smøres dagligt.

Operatørerne i udgangskontrollen kalibrerer og smører testudstyret dagligt.

Tabel 13.1. Eksempler på passive og aktive sætningskonstruktioner Myten om, at passivt sprog er mere objektivt end aktivt sprog, er fortsat ganske udbredt. Herfra er rådet, at hvis vejleder insisterer på passive sætningskonstruktioner, så skriv passivt, og ellers aktivt. Der er én væsentlig undtagelse for brugen af passive sætninger: Der må bruges passivt sprog ved introduktion af nye svære begreber (Booth, Colomb og Williams, 2008). Det svære begreb bør af hensyn til forståelsen stå sidst i sætningen, hvilket ofte kun kan klares med en passiv sætningskonstruktion. Eksempelvis som i følgende afsnit: Virksomheden Hansen Cremer A/S har tre produktionslinjer for hudcreme. De tre produktionslinjer kaldes P1, P2 og P3. Under produktionen flyder cremen gennem en række rør. Produktionslinje P3 blev stoppet på grund af viskositetsreduktion. Den sidste sætning bruger en passivkonstruktion. Viskositetsreduktion er nemlig aktøren, der stopper produktionslinje P3. Viskositetsreduktion står ikke som grundled i sætningen, men som del af et biled. Selvom dette alt andet lige gør sætningen mere uklar, forstår læser det komplekse begreb viskositetsreduktion bedre, fordi det først bliver præsenteret for læser på et tidspunkt, hvor læser er bekendt med begrebets kontekst.

Upersonligt sprog Tekniske rapporter skal være troværdige på grund af gode argumenter, solide beregninger og valide konklusioner, og ikke fordi det er en bestemt person, der udfører undersøgelsen. Derfor bør I skrive rapporten så upersonligt som muligt. Det vil sige undgå begreberne "vi" og "jeg" (personlige stedord) som aktør i sætningerne. Brug i stedet en række andre aktører. Nedenstående liste giver nogle eksempler: Undersøgelsen viser …

Beregningen viser … Afsnittet beskriver … Kapitlet giver … Data indikerer … Årsagen påvirker … Problemformuleringen indeholder … Figur 4 eksemplificerer … Tabel 3 sammenfatter … Bilag 5 illustrerer … Påpegende eller henførende stedord kan også bruges, fx i sætninger som "dette indikerer" eller "hvilket indikerer …". Figur 13.1 viser fire måder at skrive det samme på, afhængigt af om rapporten bruger aktive eller passive sætningskonstruktioner, og om aktøren er personlig eller upersonlig. Måden øverst til højre er den bedste, fordi her er sætningen aktiv og upersonlig.

Figur 13.1. Aktivt/passivt og personligt/upersonligt sprog

Brug de korte præpositioner (forholdsord) Mange studerende har den uvane at bruge "i forbindelse med", "i relation til" eller "i forhold til" i alt for mange sammenhænge. Disse præpositioner gør ofte sætninger unødvendigt komplekse. Brug i stedet de korte præpositioner som for, i, på, ved og om. Tag dette eksempel: "Analysen verificerer tallene i relation til produkternes performance." Her ved læser ikke, hvad relationen indebærer (viser tallene produkternes performance?!). Man bliver ikke meget klogere på, hvilke tal analysen verificerer. I stedet kan den korte præposition for bruges: "Analysen verificerer tallene for produkternes performance." Dette gør sætningen langt mere klar.

Fodnoter og henvisninger

Undervisere har forskellige holdninger til brugen af fodnoter. Denne bogs råd er generelt at undgå fodnoter. Årsagen er, at hver gang læser skal kigge ned i bunden af siden, så afbrydes læserytmen. Henvisninger til bilag bør stå i teksten, som fx i denne sætning: "Investeringen i maskinen giver et overskud på 2,3 mio. kr. over en femårig periode. Se beregningen i bilag 23." Henvisninger til kilder lægges ofte i fodnoter, men endnu bedre er at skrive dem ind i teksten, som fx i denne sætning: "Jorden er ifølge Hansen og Jensen (2017) rund." Husk dog at spørge jeres vejleder om brugen af fodnoter, og følg vejleders råd.

Særligt om tal i tekniske rapporter projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Tal udgør en stor del af kommunikationen i en teknisk rapport. Så ligesom det er vigtigt at bruge korrekt og klart sprog i en projektrapport, er det vigtig at være præcis i brugen af tal.

Brug af enheder på alle tal Husk at anføre enheder på alle tal i hele rapporten. Dette gælder også i bilagsmateriale, og når tal indsættes i matematiske udtryk i hovedrapporten. I tabeller kan enheden skrives ind i kolonneoverskriften, fx i firkantede parenteser ([DKK], [hPa], [K]). Alternativt kan man indsætte en række umiddelbart under rækken med kolonneoverskrifter og anføre kolonnens enheder her. Tabel 13.2 viser et eksempel. Forbrug [stk./år]

Pris [DKK]

Vægt [kg]

Maks. temperatur [°C]

Massefylde [kg/dm3]

10.000

345,70

2,34

1.670

4,69

2.000

576,80

1,25

1.980

4,87

5.000

456,12

5,79

1.670

4,13

Tabel 13.2. Eksempel på tabel med korrekt angivelse af enheder

Brug et rimeligt antal betydende cifre Et klassisk kritikpunkt til et projekt er, at beregningsresultater angives med alt for mange betydende cifre. En beregning kan fx vise, at et løsningsforslag giver 3.483.657,89 kr. i gevinst over en femårig periode. Dette tal er alt for præcist angivet. Tallet beror på stor usikkerhed, alene fordi det er beregnet over en femårig periode, og derfor bør man angive et tal med langt færre betydende cifre, fx "ca. 3,5 mio. kr." Der er en klar regel for, hvor mange betydende cifre et resultat af en beregning må have. Kig på alle beregningens inputtal, og find det inputtal, der har det laveste antal betydende cifre (fx 3 cifre). Dette antal er, hvad resultatet af beregningen maksimalt må have. Lyder en

beregning fx således: 34,82 liter i timen * 6,56 timer = 228,4192 liter. Så må resultatet ikke angives med mere end tre cifre, dvs. 228 liter, idet timetallet (6,56 timer) kun har tre betydende cifre. Mange betydende cifre indikerer stor præcision, og ingeniører og andre teknikere bør vide, at unødvendig høj præcision giver unødvendigt høje omkostninger, fx til fremstilling af et emne. Angiv derfor kun det antal betydende cifre, som beregningen kan stå inde for. En klassisk sjuskefejl i et teknisk projekt er at angive tal af samme type (fx i samme kolonne i en tabel) med et forskelligt antal betydende cifre. Hvis en tabel indeholder en række resultater af samme art, bør tallene have det samme antal betydende cifre (fx som i tabel 13.2).

Tabeller, figurer og grafer i tekniske rapporter projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Tabeller, figurer og grafer er meget almindelige virkemidler til formidling i tekniske rapporter. De udgør tit essensen i både projektets analyser og løsningsdesign. En rapport præsenterer ofte analyseresultater med grafer, tabeller og diagrammer (fx søjlediagrammer, lagkagediagrammer eller scatter-diagrammer). Løsningsdesign sker naturligt med figurer, tegninger og skitser. Det kunne være "kasse-pile"-figurer, skitser af konstruktioner eller 3D-tegninger. En generel regel for, hvordan en teknisk rapport effektivt kan præsentere alle former for visuelle virkemidler, er først at beskrive formen og dernæst indhold. Tabel 13.3 giver en række eksempler på, hvordan en rapport kan forklare formen på en graf, tabel eller figur. Type

Forklaring af form

Koordinatsystem

Forklar enhederne på X- og Y-aksen.

Søjlediagram

Forklar enheden på diagrammets Y-akse, og hvad søjlernes højde i diagrammet skal udtrykke.

Kasse-pile-figur

Forklar, hvilke typer af kasser figuren indeholder, og hvordan disse typer fremgår (fx gennem angivelse af forskellige farver eller former).

Tabel

Forklar de relevante søjler i tabellen, og hvad en række udtrykker (fx et produkt, en ordre eller et materiale). Forklar evt. også, hvordan information flyder mellem kolonnerne.

Tabel 13.3. Forklaringer af formen på forskellige typer fremstillinger Først når læser er bekendt med formen, bør I forklare indholdet. Indholdet er de resultater, som rapporten vil have, at læser skal se ud af tabellen eller figuren.

Eksempel på en projektrapport, der først forklarer form, dernæst indhold En projektrapport omhandler fejl på produktionen af to typer måleinstrumenter (kaldet produkt A og produkt B). Rapporten forklarer først den givne figurs form og derefter figurens indhold.

Først form … "Figur 12 viser, hvordan fejlene på måleinstrumenter fordeler sig på fejlårsager. De blå søjler repræsenterer produkt A og de grønne søjler produkt B. Søjlernes højde udtrykker, hvor stor en procentandel af alle fejl årsagen står for." … og så indhold "For begge produkter viser figuren, at omkring 80 % af alle fejl skyldes revner i instrumentets skal eller upræcise testmålinger. For produkt A står revner i skallen for 68 %. Øvrige årsager står for omkring 20 % af alle fejl. Heraf forårsager fejl i tryktest og software kun omkring 5 %."

Figur 13.2. Fordeling af fejl på fejlårsager

Præsentation af kvalitative data, fx interviewdata, sammenfattes typisk i tabeller. For eksempel fem informanter i hver deres kolonne og de fire temaer, som interviewene handler om, i fire rækker. En given celle i tabellen sammenfatter så en informants udsagn om et tema. Her er det væsentligt at huske, at tabellen udgør et analyseresultat på samme måde som en graf med kvantitative data. Forklar derfor først tabellens form og dernæst, hvad læser skal tage med sig fra tabellen (fx et sammenfaldende mønster i informanternes udsagn om et givet tema).

Tabel 13.4. Resultaterne fra et kvalitativt interviewstudie

Indsæt henvisninger til alle figurer, grafer og tabeller i selve teksten

En projektrapports analyse består tit af mange diagrammer og tabeller, og løsningsdesignet består tit af mange illustrationer. Rapportens skrevne tekst skal henvise aktivt til alle figurer, tabeller og grafer. Dette gælder også alle bilag. Når projektet er tæt på afleveringsdatoen, så tjek efter, om der er henvisninger til alt i teksten. Hvis man læser rapporten helt formelt, så er det henvisningen fra teksten, der inkluderer en figur i rapporten. Sagt lidt firkantet, så er figuren slet ikke med i rapporten uden en henvisning fra teksten. Når I henviser, så brug gerne aktive formuleringer som "Tabel 1 viser", "Figur 7 demonstrerer" og "Bilag 3 dokumenterer". Undgå passive formuleringer som "I figur 3 vises …".

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Opsummering

I dette kapitel har du lært, hvordan I skriver korrekt i en teknisk rapport, og hvordan I kan øge klarheden og dermed læsers forståelse af jeres projektindhold. Kapitlet demonstrerer brugen af metatekster, og hvordan aktive sætningskonstruktioner giver størst klarhed for læser. Tekniske rapporter indeholder mange tal, grafer, tabeller, illustrationer og andre grafiske virkemidler. Kapitlet viser, hvordan en rapport kan anvende disse virkemidler på mest effektiv vis.

Kapitel 14. Projekteksamen projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I dette kapitel lærer du: Hvordan I som projektgruppe effektivt kan præsentere jeres projekt mundtligt ved eksamen Hvordan I kan designe de enkelte slides i en præsentation, så de ser professionelle ud og effektivt kommunikerer jeres budskaber Hvordan I kan sammensætte en præsentation med en tydelig rød tråd Hvordan I kan "indtage scenen" med jeres kropssprog, øjne, hænder og stemme Hvordan I (enkeltvist) kan performe godt til en mundtlig eksamination i et projekt Hvad en eksaminatorstyret eksamination i et projekt egentlig er for noget Hvordan I kan håndtere nervøsitet Hvordan man professionelt håndterer eventuel utilfredshed med bedømmelsen og eventuelle klager over eksamen Hvordan man afklarer sin egen situation, hvis man ikke består eksamen. Eksaminationen af et projekt kan foregå på forskellige måder. Ofte består eksaminationen af et projekt af en præsentation af projektet og efterfølgende gruppevis eller individuel eksamination. Den efterfølgende eksamination er ofte en dialog baseret på eksaminatorspørgsmål. Dette kapitel er inddelt i følgende afsnit: 1) præsentation af projektet, 2) diskussion baseret på eksaminatorspørgsmål, 3) nervøsitet ved eksamensbordet, 4) utilfredshed og eksamensklager, og 5) reeksamener.

Præsentation af projektet projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Ved gruppeprojekter er det ofte hele jeres projektgruppe, der sammen gennemfører præsentationen. Præsentationen foregår typisk ved, at eksaminator og censor sidder bag et bord, og foran bordet står I som projektgruppe med en PowerPoint-præsentation. Nedenfor følger en række råd til, hvordan I kan designe gode slides, sikre en rød tråd i jeres præsentation, bruge jeres kropssprog til at indtage scenen og i det hele taget give en god præsentation af indholdet.

Professionelle slides til præsentationen projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Bullets

PowerPoint-programmet lægger op til, at man bruger bullets. Men bullets er ikke gode til professionel og effektiv formidling. Gode præsentationer er visuelle og ikke en række tekststykker. Gør det til en regel for jer selv, at der ingen steder i præsentationen er bullet-slides. Hellere én slide per bullet, hvor I præsenterer den enkelte bullets budskab visuelt.

Tekst på slides

Ingen lange tekststykker på slides. Fortæl jeres pointer verbalt. I stedet for tekst, brug en god figur at tale ud fra. Tænk over, hvordan jeres budskab kan illustreres.

Figurer

Jeres præsentation bør helt generelt være proppet med illustrationer, fx kasse-pile-figurer, fotos, flow-charts, tegninger, "post it"-kasser, 2X2-matrixer, tankebobler, tændstiksfigurer og traditionelle diagrammer som fx kurve-, søjle- og lagkagediagrammer.

Slide-overskrifter

Overskrifter bør placeres øverst i venstre hjørne og altid starte på samme sted på sliden, så de ikke hopper frem og tilbage, når præsentationen skifter mellem slides. Skriftstørrelse 28 er passende for overskrifter. Titlen på præsentationens forside må gerne være større. Se et eksempel senere i kapitlet.

Skygger og farver

Undgå at bruge skygger på figurer, og anvend kun farver i begrænset omfang. Udvælg gerne tre farver, der passer til hinanden, og brug så disse farver i hele præsentationen. En af disse tre farver kan oplagt være farven på virksomhedens eller universitetets logo. Nogle virksomheder har faste PowerPoint-skabeloner, som I kan anvende.

Placering af figurer

Hvis figurerne er små, skal de placeres i midten af sliden. Hvis de er store, bør I gå efter, at venstre side af figuren flugter med venstre side af overskriftens første bogstav. Højre side af figuren bør have samme afstand til slidens højre kant som i figurens venstre side. I mere kreative præsentationer kan I bruge illustrationer (fx fotos), der fylder hele sliden kant til kant. Dette kan virke forfriskende, men bør bruges med omtanke (hvad der virker godt i reklamebranchen, kan virke uprofessionelt i fx et skibsrederi eller en bank).

Skrifttyper

Anvend samme skrifttype i hele præsentationen. Nogle personer (bl.a. undertegnede) vil sige, at Arial er den eneste brugbare skrifttype i PowerPointpræsentationer, men vigtigst er at anvende den samme skrifttype på alle slides. Anvend også samme skriftstørrelse på hele sliden med undtagelse af slideoverskriften, kildeangivelser og fodnoter (se nedenfor).

Kildeangivelse

Det er god skik at angive kilder på alle slides. Dette gøres ved at skrive "Kilde:" efterfulgt af kildens navn, fx: "Kilde: Danmarks Statistik, november 2017". Hvis kilden er projektet selv, kan I skrive fx "Kilde: Projektrapport, s. 35". Kilder bør angives i nedre venstre hjørne af sliden, således at K'et i ordet Kilde flugter med overskriftens første bogstav øverst på sliden. Kilder kan passende angives med skriftstørrelse 14.

Fodnoter

Fodnoter markeres med * i sliden. Ved flere fodnoter anvendes **, *** etc. Fodnoter bør placeres under kildeangivelsen med samme skriftstørrelse som kildeangivelsen. Venstre side af * bør flugte med venstre side af bogstavet K i Kilde, så venstre kant flugter i alt indhold på sliden.

Indholdsfortegnelsesslide

Indsæt en indholdsfortegnelses-slide umiddelbart efter forsiden. Indsæt den samme indholdsfortegnelsesslide, hver gang præsentationen skifter til et nyt indholdspunkt. Hvis præsentationen har 12 indholdspunkter, indsættes indholdsfortegnelses-sliden altså 12 gange. Hver gang sliden kommer, så marker, hvilket indholdspunkt i nu er nået til. Dette kan I fx gøre ved at indsætte en kasse bag ved indholdspunktet (se figur 14.2).

Excel-tabeller

Undgå Excel-tabeller direkte i slidene. Brug hellere diagrammer til at illustrere de centrale pointer i jeres talmateriale.

Slide-budskaber

Alle slides bør have en pointe. Nogle gange er denne lidt vag, fx hvis en slide skal give overblik over et produkt eller et landområde. De fleste slides (fx diagram-slides) vil dog have et specifikt budskab. Disse budskaber bør stå på sliden, enten ved at overskriften indeholder pointen (se figur 14.3) eller ved at anvende fx en "mega-pil" til at adskille slidens data og budskab (se figur 14.1).

Præsentationer, der skal "tale for sig selv"

Præsentationer, der ikke præsenteres mundtligt, men blot sendes afsted per mail, skal kunne tale for sig selv. I disse præsentationer er forklarende tekststykker derfor nødvendige. Hvis en chef vil gå videre med jeres indhold, så siger chefen: "Send mig lige præsentationen". Inden I sender, så tilføj forklarende tekststykker. Ellers forstår modtagerne af præsentationen måske kun halvdelen af præsentationen.

Sidetal

Husk at indsætte sidetal på slidene, så læser kan følge med. Anvend gerne den sidetalsangivelse, der viser sidetal således: "23/50" eller "23 ud af 50".

Opbygning af den røde tråd (præsentationens "historie") projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Den langt mest almindelige opbygning af en præsentation i et projekt på en uddannelse følger rækken af afsnit i projektrapporten (se fx indholdsfortegnelses-sliden i figur 14.2). Det er den sikre metode. Ligesom i projektrapporten bør præsentationen vise den røde tråd i projektet, så tilhørerne forstår sammenhængen mellem de enkelte afsnit, og hvorfor projektets løsning og konklusion er, som de er. Præsentationer, der handler om at give en anbefaling, kan dog også bygges op på en anden måde, nemlig hierarkisk. Figur 14.4 viser en hierarkisk struktur. Nogle forfattere kalder denne måde for pyramideprincippet (fx Minto, 2009).

Figur 14.4. Hierarkisk opbygning af en præsentation

Pyramiden i figur 14.4 har tre lag: (a) en anbefaling, (b) et sæt argumenter for anbefalingen og (c) en række analyser, der bakker argumenterne op. Den blå slangeformede pil viser rækkefølgen i præsentationen. Læg mærke til, at præsentationen hele tiden vender tilbage til anbefalingen.

Eksempel på hierarkisk opbygning af en præsentation Et projekt handler om at finde frem til, hvordan et produkt bør redesignes, for at det er nemmere at skille ad, når et brugt produkt lander på fabrikken efter endt anvendelse af brugeren. Virksomheden har fundet ud af, at brugte produkter indeholder en række komponenter, som virksomheden kan bruge som reservedele til at servicere produkter, der er i brug. Projektgruppen har fundet frem til en anbefaling, nemlig at skifte montagemetoden ud. Konkret foreslår projektet at skifte fra at lime produktet sammen, til at produktet skrues sammen. Et sammenskruet produkt er nemt at skille ad.

Projektet og præsentationen bør argumentere for, hvorfor dette "skruer-i-stedet- for-lim"redesign er den rette beslutning. Det første argument er, at limen gør det meget dyrt og langsommeligt at skille produktet ad, hvis de værdifulde komponenter ikke skal ødelægges i processen. Det andet argument er, at en proces, der samler produktet med skruer, er nem at implementere og omkostningseffektiv at drive. Det tredje argument er, at skruer ikke gør produktet ringere rent æstetisk eller holdbarhedsmæssigt. Med disse tre argumenter mener projektgruppen, at virksomheden vil godtage anbefalingen af et "skruer-i-stedet-for-lim"-redesign. Hvert af de tre argumenter er underbygget med en række analyseresultater. En fysisk demonstration af, hvordan det oprindelige produkt skilles ad, bakker fx op om det første argument. En test af skrueprocessen viser, hvor nemt denne montageproces kan foretages, hvilket bakker op om det andet argument. Det tredje argument bakkes bl.a. op af en prototype af et sammenskruet produkt, der viser, at produktet fortsat er flot at se på og er holdbart. Princippet for, hvordan en pyramideformet eller hierarkisk præsentation gennemføres, er at starte med det store billede og så bevæge sig ned i detaljen. I skal hele tiden genbesøge det store billede, så tilhørerne oplever, at der er en klar og tydelig rød tråd i præsentationen. Efter introduktionen af problemformuleringen dykker præsentationen, jf. figur 14.4, ned i det første af argumenterne, dernæst ned i den første analyse, der bakker det første argument op. Derefter går præsentationen tilbage til argumentet og ned i næste analyse. Efter tredje analyse går præsentationen fra første til andet argument og gennemgår analyserne, der bakker dette argument op, på samme måde som ved første argument. Når det tredje argument er præsenteret med de tilhørende analyser, er præsentationen færdig.

At indtage scenen – kropssprog, øjenkontakt og stemmeføring projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Ved en eksamenspræsentation er det vigtigt at bruge sin krop, sine øjne og sin stemme hensigtsmæssigt. Her er en række klassiske råd: Plant fødderne solidt i gulvet, og rank ryggen Tal højt og tydeligt Se eksaminator og censor i øjnene, og undgå at stirre på PowerPoint-slidene Stå stille, og brug armene som en slags levende taktstokke Når det er din tur til at præsentere, så "indtag scenen" ved at bevæge dig tættere på enten slidene eller eksaminator og censor. Eksaminator og censor veksler mellem at se på PowerPoint-slidene og på dig som den præsenterende studerende. Kig ikke på dine slides, men i stedet se på eksaminator og censor. Ved den professionelle præsentation kender man sine slides så godt, at man ikke behøver hjælp ved hele tiden at kigge på slidene. Anvend i stedet noter på papir, eller stil computeren, så du kan se slidene på skærmen, når du præsenterer.

Særligt om din stemmeføring Hvis du taler meget lavt, kan det få eksaminator og censor til at tro, at du er usikker og implicit ikke så dygtig. Hvis du har dette problem, så træn din stemmeføring ved at øve dig i at tale højt og tydeligt. Prøv at tjekke YouTube for videoer om stemmetræning (på engelsk: "vocal exercises"). Her er en lille intro: Gå ind i en tomt rum, hvor ingen kan høre dig Start med at fylde lungerne med luft, rank ryggen og træk hagen bagud Begynd med en dyb OOOOO-lyd, hvor du lader luften strømme jævnt ud gennem munden (styr den jævne strøm af luft med din mave, og forestil dig, at du laver dit halsrør så bredt som muligt) Fortsæt med LÅ-LÅ-LÅ-LÅ-LÅ-LÅ-LÅ-LÅ-LÅÅÅÅÅÅÅÅÅÅ Øv dig dernæst med nogle sætninger, og anvend samme teknik med at lade luften strømme jævnt ud gennem munden, mens du taler. Det er generelt en rigtigt god ide at træne præsentationsteknik og (hvis uddannelsen ikke tilbyder det) gå til småkurser, fx hos Ingeniørforeningen i Danmark (IDA) eller hos andre udbydere. At præsentere med lethed og elegance kræver øvelse og skal læres. Selvom nogle mennesker er bedre til at skjule nervøsitet og har det bedre i rampelyset end andre, så er ingen født til at præsentere, og alle bliver bedre med træning.

Præsentationsindhold projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Den gode fremlæggelse indeholder en kort, præcis præsentation af projektets hovedlinjer samt en række "andre ting". Husk ved præsentationen af projektets hovedlinjer både at præsentere problemformuleringen og konklusionen, så eksaminator og censor ikke er i tvivl om, at projektet har svaret grundigt på problemformuleringen. De "andre ting", en præsentation kan bestå af, varierer fra uddannelse til uddannelse, men typiske temaer er: De næste skridt i implementeringen af projektets løsninger Virksomhedens udfordringer ved implementeringen Løsningens almene relevans for fx andre virksomheder i branchen Løsningens bredere samfundsmæssige eller miljømæssige relevans Jeres egen læringsproces gennem projektet Refleksioner over jeres arbejdsproces som projektgruppe Oplagte nye projekter, der er afledt af jeres projekt.

Fejl i projektrapporten fundet mellem aflevering og eksamen Projekteksamen foregår nogle uger efter projektaflevering, og i den mellemliggende tid finder man ofte småfejl i rapporten og fra tid til anden større fejl. Skal man fremlægge disse fejl? Det kommer an på fejlens størrelse og indflydelse på konklusionen. Tabel 14.2 giver mere præcise svar. Fejltype

Handling

Store fejl, der har afgørende betydning for konklusionen

Fortæl om fejlene i første del af præsentationen, og fortæl, hvordan I skulle have udført opgaven i stedet. På den måde beror den resterende præsentation på de korrekte beregninger og forudsætninger.

Mellemstore fejl, der har mindre betydning for konklusioner og løsning

Nævn disse fejl til slut i præsentationen uden at bruge meget tid på dem. Hvis I nævner fejlene forud for eksaminationens diskussion, kan det tage noget af luften ud af nogle af eksaminators og censors spørgsmål.

Fejl, der er næsten helt ubetydelige

Nævn ikke fejlene i fremlæggelsen, men håb i stedet på, at eksaminator og censor spørger til dem. Så får I nemlig lejlighed til at forklare, hvordan opgaven skulle være løst.

Tabel 14.2. Håndtering af fejl fundet mellem projektaflevering og eksamen Uagtet størrelsen på fejlene er det vigtigste, at I kender fejlene og kan fortælle, hvordan opgaven skulle eller burde være løst.

Diskussionen baseret på eksaminatorspørgsmål projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Studerende eksamineres ofte individuelt i en projektrapport, men det er også ganske almindeligt, at en hel projektgruppe eksamineres samlet. Der kan være elementer af individuel eksamination selv i en gruppeeksamen, og de fleste af denne bogs råd vil være med udgangspunkt i en dialog mellem en enkelt studerende og eksaminator/censorer. Selvom eksaminator og censor er forskellige, og uddannelserne har forskellige forventninger til de studerende, er den mest effektive måde at flytte en karakter på at svare godt på eksaminators og censors spørgsmål. Gode svar i den individuelle eksamination er som regel langt vigtigere for jeres individuelle karakter end en god gruppepræsentation. Den individuelle eksamination i et projekt handler om at vurdere din forståelse af projektet, herunder problem, analyse og løsningsdesign.

Hvordan foregår diskussionen omkring eksamensbordet? Eksaminator og censor læser projektet op til eksamen med et kritisk mindset. Karakterskalaen (12-skalaen) betyder, at en studerende, der lever fejlfrit op til projektkursets læringsmål, skal have karakteren 12. Jo flere fejl, og jo større fejlene er, jo lavere bliver karakteren. Det betyder, at eksaminator og censors opgave langt hen ad vejen er at finde fejl. Til eksamen medbringer eksaminator og censor derfor et sæt spørgsmål, hvoraf mange spørgsmål handler om fejl. Ved dårlige rapporter handler spørgsmålene næsten kun om fejl. Ved gode projekter har eksaminator og censor svært ved at finde fejl og mangler. Enkelte fejl finder eksaminator og censor altid, men ved gode projekter er der ofte ikke nok fejl og mangler i rapporten, til at hele eksaminationen kan gå med spørgsmål til disse fejl eller mangler. I disse situationer spørger eksaminator og censor derfor tit ind til helt korrekt udførte elementer i projektet. Eksaminator og censors opgave til eksamen er nemlig at vurdere de enkelte studerendes niveau i forhold til kursets læringsmål. Når eksaminator og censor under en eksamen spørger ind til korrekte elementer i rapporten, er det altså for at vurdere, om lige netop den studerende, der er til eksamen, kan forstå spørgsmålene og de elementer, der spørges ind til. Vurdér så godt og hurtigt som muligt, om eksaminator og censor spørger til en fejl eller til noget, der er helt korrekt. Hvis der er tale om en fejl, kan du score point således: 1. Anerkende, at der er en fejl 2. Forklare, hvad I skulle have gjort i projektet i stedet for fejlen. Anerkend fejlen fx ved at sige "Godmorgen, selvfølgelig er det der da en fejl" eller "Ja, det kan jeg godt se". På den måde overbeviser du eksaminator og censor om, at du har forstået fejlen. Dernæst (og helst i næste sætning) kan du score point ved overbevisende

at fortælle, hvad der skulle være skrevet eller beregnet i stedet for fejlen. For eksempel således: "Jeg kan se, at vi har glemt at dividere med pi", eller "vi skulle have ganget med arealet". Disse to svar indikerer over for eksaminator og censor, at du bør bedømmes højere end den fejlfyldte rapport. Endnu bedre (men også sværere) er, hvis du kan se, at eksaminator og censor har overset noget, der gør, at fejlen faktisk ikke er en fejl alligevel. Så kan du sige: "Jeg kan høre, at dit spørgsmål forudsætter en traditionel brug af projektets metode. Vi har imidlertid arbejdet under en række særlige omstændigheder [forklar omstændighederne], og derfor har vi anvendt metoden på utraditionel vis, sådan og sådan." Allervigtigst er, at hvis fejlen er reel (hvilket oftest er tilfældet), så undgå at kæmpe til sidste blodsdråbe. Det giver eksaminator og censor et indtryk af, at du ikke forstår fejlen, selvom eksaminator og censor forklarer fejlen tydeligt. Så sig hellere "Det ved jeg ikke", og håb på bedre held med næste spørgsmål. Hvis man ikke forstår spørgsmålet til fejlen eller ikke kan svare på det, kan man prøve i stedet at tale om spørgsmålets bredere tema. Hvis fx fejlen handler om, hvordan projektet har beregnet tyngdepunktet, kan man starte sit "svar" med at tale om formålet med at lave beregningen og derefter en generel snak om tyngdepunktsberegninger. På den måde viser du dit generelle kendskab til temaet, og det kan give nogle få point. Husk dog, at du bruger af din korte eksamenstid. Den kunne du måske bruge bedre med præcise svar på andre spørgsmål. Pas på ikke at frasige dig ejerskabet til dele af rapporten. Medmindre studieordningen angiver det anderledes, står alle i projektgruppen for alle dele af rapporten. Undgå formuleringer som: "nu er det ikke mig, der har lavet den del af projektet" "det, der måske menes …" "jeg tror, at de [andre i gruppen] har antaget, at …" Forhold dig til spørgsmålet, og ret fejlen, hvis du kan.

Nervøsitet ved eksamensbordet projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

En nervøs studerende, der går til eksamen med et dårligt projekt, er en uheldig cocktail. Ved et dårligt projekt har eksaminator og censor fundet mange fejl, og de spørger typisk ind til dem fra første øjeblik. Som nervøs studerende begynder man måske at tro, at projektet er langt under dumpegrænsen, også selvom projektet er på den rigtige side (fx til 02 eller 4). Det er uheldigt, fordi den ekstra nervøsitet giver eksaminator og censor et endnu dårligere indtryk af den studerendes evner, end rapporten viser. Tricket her er at huske, at selv ved gode projekter spørger eksaminator og censor ind til projektets fejl, fordi karakterskalaen er bygget op omkring, hvor mange og hvor store fejlene er ved et projekt. Sørg for at have is i maven, og forhold dig i første omgang til, hvorvidt spørgsmålet handler om en fejl. Hvis det er tilfældet, så anerkend fejlen, og ret den med det samme, hvis du kan. Husk også, at karaktererne 02 og 4 tillader dig at bestå, selvom eksamen ikke gik godt. For eksempel gives karakteren 4 for præstationer med "adskillige væsentlige mangler".

Utilfredshed og eksamensklager projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Det sker ganske ofte, at en studerende mener, at karakteren er (alt) for lav. Frustrationen over karakteren opstår med det samme, og den kan være så stor, at den er svær at holde tilbage. Det kan give sig udtryk i, at en studerende forlader lokalet i protest og vrede. En anden udgang er, at når eksaminator og censor påbegynder kritikken af projektet, så modargumenterer den pågældende studerende voldsomt og prompte. En sjælden gang kan diskussionen være så ophedet, at eksaminator og censor helt må opgive at give feedback. Det er vigtigt at forstå, at når karakteren er givet, er eneste mulighed for ændring en klageproces. At modargumentere ved eksamensbordet er nytteløst for karakteren. Et godt råd er derfor at tage grundige noter, når eksaminator og censor giver feedback, for senere at kunne udarbejde en velargumenteret eksamensklage. Start med at tage en uformel snak med din eksaminator (din nu tidligere vejleder) for en mundtlig afklaring. Hvis du derefter beslutter dig for at klage, er her en række råd: En klassiker inden for eksamensklager er: "Det burde vejleder have sagt til vejledning". Dette argument er oftest en blindgyde, idet et projekt er de studerendes ansvar. Hvis I bruger dette argument, skal I have belæg for, at jeres vejleder spontant burde have påpeget jeres fejl ved et vejledermøde eller under læsning af jeres materiale. Det er ikke nemt at skaffe, fordi appelkomitéer ved, at mange fejl først kan opdages, når rapporten læses i sin helhed. På nogle universiteter kan studerende indgive en klage over enten projektvejledningen eller eksamenskarakteren. Det er sket, at en studerende, der føler sig snydt af vejleder, klager over vejledningen for at få en bedre karakter. Dette er dog uheldigt, fordi en klage over vejledning oftest ikke kan føre til en bedre karakter. Derfor: Hvis du er utilfreds med karakteren, så klag over karakteren, uagtet at dine argumenter handler om vejledningen under projektforløbet. Klag over processen i stedet for bedømmelsen. Denne er uafhængig af eksaminators og censors faglighed. Argumentér fx for, at karakteren 02 på et specialkursus i stedet burde have været B for bestået, pga. tvetydigheder i studieordningen. Et B har nemlig ingen indflydelse på karaktergennemsnittet.

"Men jeg svarede jo rigtigt på alle spørgsmål" Nogle gange føler en studerende sig uretfærdigt behandlet, fordi karakteren ikke var 10 eller 12, selvom alle spørgsmål blev korrekt besvaret. Der er to (og måske flere) mulige forklaringer på dette scenarie:

Den studerende taler sig varm til hvert spørgsmål. En typisk mundtlig eksamination i et projekt varer ca. 15-20 minutter. Her er der tid til, at eksaminator og censor stiller omkring 7-10 spørgsmål. Det sker fra tid til anden, at en studerende bruger meget lang tid på at få en præcis forståelse af hvert enkelt spørgsmål. I sådanne tilfælde er der kun tid til omkring 4-5 spørgsmål. Selvom den studerende i sidste ende får svaret korrekt på alle 4-5 spørgsmål, er den samlede præstation ikke særligt god, fordi de korrekte svar sker på baggrund af al for meget hjælp. Den studerende oplever, at der blev svaret korrekt. Det er ganske naturligt at føle, at hvis diskussionen indeholder de rigtige svar på spørgsmål, så har man gjort det godt. Denne følelse kan dog også opstå, når de korrekte svar kommer fra eksaminator og censor. Eksaminator stiller et spørgsmål, den studerende ikke kan besvare præcist. Efter nogle sætninger frem og tilbage fortæller eksaminator det korrekte svar, til hvilket den studerende siger "Nå, ja selvfølgelig" og så tilføjer nogle ekstradetaljer til svaret. Husk, at eksaminator og censor laver noter og er helt klar over, hvorvidt svarene er kommet fra eksaminator og censor eller fra den studerende. Hvis du overvejer at klage, så husk, at der er risiko for, at en appelkomité finder den karakter, som du klager over, for høj, og derfor giver projektet en endnu lavere karakter og uden mulighed for at anke. Risikoen betyder dog ikke, at du skal afholde dig fra at klage, hvis du mener, du har en reel sag.

Hvad nu, hvis jeg dumper? projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Der er mange grunde til, at en studerende ikke kan formidle sin viden ved en projekteksamen. Den mest almindelige er dog, at pensum ikke er forstået. At "klappen gik ned", har alle hørt om, men det sker sjældent i praksis. På alle kurser er der omkring 5-10 %, der dumper, og på nogle kurser er dumpeprocenten helt oppe på 40-50 %. Det er altså ikke unormalt at dumpe – faktisk er det helt almindeligt. Her er et godt råd: Betragt en dumpet eksamen som en generalprøve, der gik i vasken, og at den virkelige eksamen er reeksamen. Når du én gang har været til eksamen og dumpet, har du hele oplevelsen og nuancerne af eksamen på rygraden, og du ved nu langt mere præcist, hvad eksaminator og censor efterspørger. Nu kan du så påbegynde forberedelsen til reeksamen med større præcision i dit arbejde. Til en projekteksamen er det vigtigt, at du finder ud af, hvilke dele af det skriftlige arbejde du eventuelt skal genbearbejde for at få lov til at gå til reeksamen. Skal hele projektet udarbejdes igen eller kun enkelte dele? Det ved din underviser. Ud over genbearbejdelsen af det skriftlige materiale bør du også læse det pensum, der kan være knyttet til projektkurset. Så er du klar til reeksamen.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Opsummering

I dette kapitel har du lært, hvordan I som projektgruppe effektivt kan præsentere jeres projekt ved en mundtlig eksamen. Kapitlet fortæller, hvordan I kan udarbejde professionelle slides, der effektivt kommunikerer jeres budskaber, og hvordan I kan sammensætte en samlet præsentation, der tydeligt viser jeres rapports røde tråd. Jeres kropssprog, øjenkontakt, hænder og stemme kan I bruge til at "indtage scenen" og understøtte jeres præsentation. Kapitlet beskriver, hvordan I (enkeltvist) kan performe godt ved en mundtlig eksamination i et projekt, I som gruppe har udarbejdet. Eksaminationen er styret af eksaminator. Kapitlet beskriver, hvordan dette foregår, og hvilken dialog der foregår omkring eksamensbordet. Kapitlet beskriver også, hvordan du kan håndtere nervøsitet, utilfredshed med karakteren, og hvordan du kan afklare din egen situation, hvis du ikke består eksamen.

Kapitel 15. Censors 12-talskriterier projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I dette kapitel lærer du: Hvilke forventninger censor har til det gode projekt At censors fokus officielt er fejl og mangler i en projektrapport Censorers sæt af kvalitetskriterier Hvilke kvalitetskriterier der er særligt vigtige, og hvilke der er mindre vigtige Censorers "don't do"-liste Det særlige ved den akademiske censor, der ikke kommer fra industrien, men fra et andet universitet. Dette kapitel stiller skarpt på censorernes kriterier for at give en god karakter til jeres projekteksamen. Kapitlet beskriver, hvad censorer ser efter både i projektrapporten og til den mundtlige eksamen. Kapitlet behandler også elementer, der kan skabe forvirring for en censor, og som du kan undgå. Kapitlet er baseret på samtaler med censorer på ingeniøruddannelser i Danmark. Udtryk og sætninger i dette kapitel, der er skrevet i citationstegn, kommer fra disse samtaler med censorer.

Censorers forventninger til det basale indhold i et projekt projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Der er forskellige traditioner omkring, hvilke indholdselementer et godt teknisk projekt skal have. Fælles for alle tekniske projekter er dog følgende fire indholdselementer: 1. En problemstilling af en vis kompleksitet 2. Et tilstrækkeligt vidensgrundlag af faglige begreber og metoder 3. En analyse (fx af problemets årsager eller krav til løsningen) 4. En løsning, der faktisk og troværdigt kan løse problemet. Disse fire elementer er især vigtige i de sidste semestre på jeres uddannelse, hvor underviserne forventer selvstændighed i jeres projektarbejde. Selvstændighed betyder (lidt firkantet sagt), at I selv vælger problem og metode. På jeres tidlige semestre er projekter ofte bundne og handler derfor om underviservalgte problemer og metoder. Ud over disse fire grundlæggende indholdspunkterer er der fire yderligere indholdspunkter i et projekt, der på mange uddannelser også er "must-haves": 5. En egentlig analyse af problemfeltet, der går forud for valget af problem til problemformulering 6. En detaljeret beskrivelse af metodevalg, materialer, udstyr og fagligt grundlag for projektets analyse 7. En økonomisk vurdering af løsningen (ikke blot løsningens effekt på problemet) 8. En plan for implementeringen af løsningen. Samlet set repræsenterer disse otte indholdspunkter et godt projekts indhold.

Censorers fokus på fejl og mangler projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Karakterskalaen fra -3 til 12 bygger på princippet om, at jo flere og større fejl og mangler, der er i et projekt, jo lavere er karakteren. Udgangspunktet er karakteren 12. Fordi karakterskalaen fokuserer på antallet og størrelsen af fejl og mangler, betragter mange censorer, særligt nyere censorer og regelfokuserede censorer, deres opgave som at lede efter netop fejl og mangler. Fejl og mangler i et projekt kan være mangt og meget. Nogle fejl er simple og indiskutable (fx at man har indtastet et minus i stedet for et gangetegn i en formel). Andre fejl handler om, hvorvidt I som projektgruppe har foretaget vurderinger eller skøn, som censor mener er forkerte. Disse fejl kan være helt indlysende, men de kan også være diskutérbare. Tabel 15.1 giver en række eksempler på fejl og mangler i en projektrapport. Simple fejl og mangler* Der er brugt en forkert formel En variabel i en formel har forkert fortegn Fejl i brugen af et program (fx at en funktion i Excel kun medregner ½ af de tiltænkte data) Tal mangler enhedsbetegnelser eller har et unødigt stort antal betydende cifre Forkert forståelse eller anvendelse af et begreb, en teknik eller et måleinstrument Rapporttekniske fejl (fx at figurnumre er forkerte, eller at rapporten ikke henviser til bilag) Vurderingsmæssige fejl og mangler Det er valgt et forkert problem (problemanalysen fortæller åbenlyst, at noget andet er vigtigere) Den valgte metode kan ikke lede til en komplet løsning (uagtet om den er korrekt anvendt)

Den valgte testmetode kan ikke give et brugbart resultat (uagtet om den er korrekt anvendt) Analysen giver ikke brugbare resultater (uagtet om den er korrekt gennemført) Der er valgt noget materiale, der ikke er holdbart i længden To eller flere valg er ikke kongruente (kan ikke indgå i samme løsning) Forkert vurdering af årsagers effekt på projektets problem *En simpel fejl kan sagtens have store konsekvenser, men selve fejlen er fortsat simpel ("der skulle have stået et minus og ikke et plus"). Tabel 15.1. Fejl og mangler i projektrapporter

Censorers kvalitetskriterier projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Fejl og mangler er ikke lige store. Nedenstående afsnit giver indblik i, hvordan censorer mere eller mindre eksplicit rangordner deres kvalitetskriterier. Figur 15.1 viser et hus med tre etager (stuen, 1. sal og et loftsrum), svarende til hierarkiet i censors kvalitetskriterier. Jo bedre jeres projekt er, jo højere oppe i huset foregår samtalen til eksamen.

Figur 15.1. Hus, der illustrerer hierarkiet i censorers kvalitetskriterier

Vi begynder i stuen. At et projekt har en rød tråd, er det allervigtigste kvalitetskriterie. Når censor læser et givent afsnit midt i rapporten, må censor ikke tænke: "Hvad handler denne her rapport egentligt om?" Følgende tre ting skal være tydeligt for censor: at projektet har ét problem (og ikke to eller flere eller eventuelt slet ikke noget problem) at projektets analyse handler om dette ene problem (og ikke om andre problemer) at projektets løsning faktisk er en løsning på projektets problem (og ikke på alle mulige andre problemer eller måske endda ikke noget problem). Et projekt kan kun nå 1. sal i huset ved at have en stærk og tydelig rød tråd. Projektrapporten skal være opbygget logisk og lineært begyndende med en problemformulering, hvorefter der skal komme en analyse, løsningsdesign og en konklusion. Rapporten er ikke en historisk fortælling om jeres projekt, der beskriver jeres faktiske arbejdsproces. Derudover skal projektet, for at nå 1. sal, demonstrere, hvordan I har forholdt jer kritisk i både jeres indsamling af data (kvantitative og kvalitative data) og ved beregninger af analyseresultater. Censor forventer, at I vurderer, om en datakilde i et projekt er pålidelig, og at I kvalitetssikrer jeres data, hvis nødvendigt (fx at interviewe to eller tre personer om samme problem, hvis jeres første informant kan tænkes at have sin egen agenda). Censorer forventer også, at I vurderer, om jeres analyseresultater er virkelighedsnære og

realistiske, eller om de er "helt ude i hampen". Læg mærke til, at et projekt, der når 1. sal, godt kan have fejl i brugen af faglige metoder og modeller. Sammenhængen i projektet er vigtigere end fejl hist og her i anvendelsen af uddannelsens faglighed. For at gå fra 1. sal til loftsrummet skal projektet demonstrere korrekt anvendelse af uddannelsens faglige metoder, modeller og redskaber. Derudover forventer censor, at I anvender realistiske forudsætninger i jeres beregninger og designer løsninger, der er implementerbare (og ikke som amerikanerne siger: "Pie in the sky"). Hvis jeres projekt demonstrerer, at I har styr på både stueetagens og 1. salens kvalitetskriterier, bærer eksamen ofte præg af faglig "hyggesnak". Censor og eksaminator har allerede inden eksamen vurderet rapporten til 12 og altså ikke fundet væsentlige fejl og mangler. I disse tilfælde handler eksaminationen ikke om fejl og mangler, men om 1) muligheder, 2) emner, der ligger uden for for projektet (fx generelle anvendelsesmuligheder af teknologier i løsningen) og 3) jeres arbejdsproces (fx samarbejdet med virksomhed).

Censorers vurdering af rapportens formidlingsevner projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

To gyldne regler (den bibelske og en regel opfundet til lejligheden) ved formidling er: 1. Skriv, så censor, der møder projektet for første gang, forstår projektet fra første færd 2. Skriv, som om censor er en "åndelig undermåler", der skal have tingene forklaret uden forkundskaber til andet end den generelle faglighed i projektet. Det sker fra tid til anden, at censor fortæller, hvordan han/hun først på side 35 forstod, hvad projektet gik ud på. Det er oftest, fordi rapporten er beskrevet indforstået. Rapporten bruger ord, der først introduceres senere i rapporten (eller slet ikke), glemmer nødvendige forklaringer og omtaler emner, som om censor allerede kender til dem. At aflære jer selv at skrive indforstået er ikke nemt, men kan lade sige gøre med et par tricks. Lad en anden person læse jeres projekts introduktion. På den måde får I et førstehåndsindtryk fra en ny person, der (ligesom censor) læser projektet for første gang. Skriv projektets introduktion i god tid før aflevering, og lad teksten ligge en uges tid eller to. Når tiden er gået, læser I introduktionen igen med 'nye øjne'. I vil så opdage, hvis introduktionen er skrevet for indforstået. Se også kapitel 12, der beskriver, hvordan man sikrer læsers forståelse gennem en hierarkisk opbygget introduktion. Det er vigtigt for censorer, at de opfatter sig selv som projektrapportens målgruppe. Projektrapportens målgruppe er altså ikke kontaktpersonen, ledelsen eller diverse medarbejdergrupper i den virksomhed, I har samarbejdet med. Censorer kan godt lide, at en projektrapport "taler lige ud af posen", også hvis I som projektgruppe ikke har samme forståelse af verden som virksomheden. Hvis I fx finder frem til, at ineffektiviteten af en proces beror på umotiverede medarbejdere, og at årsagen til dette er dårlig ledelse, bør det fremgå tydeligt og præcist i projektrapporten, selvom det ikke vil falde i god jord i virksomheden (fx hos jeres kontaktperson, der har været flink og rar over for jer hele semestret). Lille advarsel: Censorer kan som sporhunde ofte snuse sig frem til denne type problemstillinger mellem linjerne i jeres rapport. Stavefejl, grammatiske fejl, mangel på figurtitler og bilagshenvisninger samt dårlig kvalitet af bilag (fx tegninger og fotos) tæller ofte meget mere, end I måske tror. Censorer kritiserer tit en "manglende gennemskrivning" af rapporten. En sådan manglende gennemskrivning indikerer over for censor, at I ikke er så kvalitetsbevidste, og dette kan censor hurtigt overføre til de faglige emner i rapporten.

"Don't do"-listen | Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

"Don't do"-listen

Herunder følger en liste med "don't do's", som trækker ned i censorers vurderinger: 1. At undskylde en fejl eller mangel med tidsnød. ("Hvis vi havde haft mere tid, ville vi …"). 2. At arbejde med ufuldstændige datasæt. Hvis I mangler data, så foretag egne målinger. Hvis det tager for lang tid, så anvend en række realistiske antagelser, som I har afklaret med virksomhed og vejleder. 3. Brug af nyopfunde begreber, hvor der allerede eksisterer et begrebsapparat. Brug de ord, som man må kunne forvente, at I har lært i jeres undervisning. 4. En problemformulering, der vil to eller flere ting samtidigt. (Censor kan her tænke: "Det virker, som om det er to rapporter, der i løsblade er kastet på gulvet og tilfældigt samlet igen."). 5. At udtrykke jer upræcist og indforstået, så læser skal gætte sig til jeres pointer. 6. Indsættelse af figurer og illustrationer uden henvisning i den skrevne tekst. (Censor kan her tænke: "Hvad var lige pointen med den figur?"). 7. At skrive virksomhedsvenlige konklusioner. Skriv de konklusioner, som I mener er de rigtige, og forsøg ikke at "please" virksomheden. Målgruppen for jeres rapport er censor og eksaminator og altså ikke virksomheden. Hvis nødvendigt, så aflever en redigeret version af rapporten til virksomheden, hvor I har taget de afsnit ud, som virksomheden ikke skal se. Virksomheden har ikke et officielt krav på at se den version af rapporten, som I afleverer. 8. Forsøg på at imponere censor ved at fortælle, hvor tæt I har samarbejdet med virksomhedens administrerende direktør eller diverse vice presidents. (Det er indsigt, der betyder noget, ikke titler).

9. Forsøg på at imponere med besøg i udlandet og andre besværlige omstændigheder. Besøg i udlandet er som regel ikke blandt et projektkursus' læringsmål. Jeres vejleder kan godt argumentere for jeres engagement ved fx at sige: "Jamen, de [projektgruppen] har brugt meget tid på at rejse land og rige rundt". Men hertil kan censor nemt svare: "De burde ikke have gjort det så besværligt for sig selv."

Særligt om den akademiske censor projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

En censor kan være både en erfaren praktiker fra erhvervslivet eller en underviser fra et andet universitet eller læreanstalt. En censor kan også være noget midtimellem (fx ekstern lektor samtidigt med job i erhvervslivet). For akademiske censorer fra andre læreanstalter er det mindre vigtigt, om en løsning er innovativ og "godt tænkt". I stedet er det vigtigt, at projektets analyse ekspliciteres, så det er muligt at følge den logiske sammenhæng mellem problem, analyse og løsning. Akademiske censorer oplever ofte, at et teknisk projekt hopper meget hurtigt fra problem til løsning uden at redegøre tydeligt for de enkelte skridt i den analyse, der identificerer årsagerne til problemet og klart beskriver de krav, der er til løsningen.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Opsummering

I dette kapitel har du lært, hvilke forventninger censor har til det gode projekts indhold. Censors fokus er officielt fejl og mangler i en projektrapport, og derfor foregår dialogen med censor ofte om fejl og mangler. Censorer har et sæt af kvalitetskriterier, som kapitlet gennemgår. Disse kvalitetskriterier er ikke lige vigtige, og kapitlet fortæller om hierarkiet. Kapitlet afslutter med en sammenfatning af censorers "don't do"-liste og karaktertrækkene ved akademiske censorer, dvs. censorer, der er undervisere ved andre læreanstalter.

Kapitel 16. Tekniske kandidatafhandlinger projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I dette kapitel lærer du: At tekniske kandidatafhandlinger kan være problemløsende projekter, som denne bogs øvrige kapitler handler om, eller akademisk orienterede projekter, som dette kapitel handler om Hvordan kandidatafhandlinger adskiller sig fra problemløsende projekter Hvordan du som studerende, der skriver en kandidatafhandling, bør forholde dig til universitetet som en tungere vejende interessent end ved problemløsende projekter At kandidatafhandlingers problemformulering er undersøgelsesspørgsmål, hvis besvarelse bidrager til videnskaben Hvordan kandidatafhandlinger anvender en opbygning, der følger den traditionelle opbygning i akademiske papers Hvordan kandidatafhandlinger lokaliserer og anvender teori samt foretager metodevalg Hvordan kandidatafhandlinger beskriver metode, analyse, diskussioner og konklusioner. De fleste tekniske kandidatafhandlinger i Danmark er civilingeniørernes afsluttende 30 ECTS-point kandidatafhandling. Ud over civilingeniørspecialer skrives også tekniske kandidatafhandlinger på fx IT-universitetet og de traditionelle universiteters naturvidenskabelige fakulteter.

Der hersker en ganske stor forskel på tekniske kandidatafhandlinger både mellem universiteter og imellem institutterne inden for et universitet. På nogle institutter er der næsten ingen forskel på kravene til de problemløsende projekter på tekniske professionsbacheloruddannelser (som fx diplomingeniør) og tekniske kandidatafhandlinger. På andre institutter er der store forskelle. Figur 16.1 viser tre hovedtyper af tekniske kandidatafhandlinger som et kontinuum.

Figur 16.1. Tre typer af tekniske kandidatafhandlinger

Hvis kandidatafhandlingen er et problemløsende projekt uden ekstra krav, vil dette kapitel være helt og aldeles irrelevant. Til gengæld er alle andre kapitler i bogen relevante. Er kandidatafhandlingen af typen i midten, adskiller projektet sig fra det problemløsende projekt ved at inkludere et studie af problemnær litteratur og teori. Hvis emnet fx er målingspræcision på apparater, der måler antallet af levende celler i mælk, forventes projektet at demonstrere indsigt i den specifikke litteratur omkring cellemåling i mælk og ikke blot den generelle litteratur omkring målinger i væsker, der (måske) har været pensum på uddannelsen. Hvis projektet er af typen i midten, er alle kapitler i denne bog relevante, og i dette kapitel er afsnittet om litteraturstudiet relevant. Er afhandlingen af typen til højre i figuren, er der tale om et akademisk orienteret projekt, der er en anden genre end det problemløsende projekt. Dette akademisk orienterede projekt har til formål at bidrage til videnskaben. Det akademisk orienterede projekt kan fint løse et problem for en virksomhed, men det store mål er at bidrage til den generelle videnskab og ikke blot til den virksomhed, som projektet udføres i samarbejde med. Det er denne type akademisk orienterede projekt, dette kapitel handler om. At bidrage til videnskaben handler om at undersøge ubesvarede spørgsmål om, hvordan verden hænger sammen. Besvarelser af denne type spørgsmål skal have generel relevans og ikke kun gavne en virksomhed, som du eventuelt udfører projektet i samarbejde med. Kandidatafhandlingen kan stå alene eller indgå som et led i et større forskningsprojekt på det af universitetets institutter, hvor du får din uddannelse.

Håndtering af både virksomhed og universitet som interessenter projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Selvom en teknisk kandidatafhandlings fineste kvalitet er bidraget til den generelle videnskab, udføres projektet ofte i samarbejde med en virksomhed. Du som studerendes skal derfor matche både universitetets og virksomhedens interesser i projektet. Det kan være en stor udfordring, fordi din vejleder, der er forsker på universitetet, ofte har en større egeninteresse i en teknisk kandidatafhandling (end i et problemløsende projekt). At matche begge interessenters forventninger er dog almindelig praksis på universitetet.

Eksempel på, hvordan et projekt kan matche både virksomhedens og universitetets interessenter i en teknisk kandidatafhandling En studerende vil arbejde med en aktuel problemstilling hos en virksomhed, der overfladebehandler deres kunders metalemner for at modstå rustdannelse. Virksomheden vil gerne have undersøgt, hvordan et overfladebehandlet emne ruster under en særlig række betingelser, der gælder hos en af virksomhedens største kunder. Den studerendes vejleder, der er professor i metallurgi, har også en interesse i projektet. Vejlederen ønsker, at afhandlingen bidrager til metallurgividenskaben og måske kan omskrives til en artikel til et videnskabeligt tidsskrift. Den studerende udformer i samråd med virksomhed og vejleder en problemformulering, der handler om, hvordan en udvalgt metaltype ruster under den særlige række betingelser, der hersker hos virksomhedens kunde. Problemformuleringen tager således afsæt i en bestemt virksomheds aktuelle udfordring, men bidrager også til den generelle viden om rustdannelse, nemlig til, hvordan en eller flere bestemte betingelser påvirker rustdannelsen på en udvalgt metaltype.

Kandidatafhandlingens opbygning projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Den generelle opbygning i kandidatafhandlinger følger den traditionelle opbygning i akademiske papers. Denne opbygning ses i figur 16.2.

Figur 16.2. Opbygningen af akademisk orienterede tekniske kandidatafhandlinger

De følgende afsnit beskriver den tekniske kandidatafhandlings enkelte kapitler i samme rækkefølge som illustreret i figuren.

Kandidatafhandlingens introduktion projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Hvor et problemløsende projekt på fx diplomingeniøruddannelsen tager udgangspunkt i en virksomheds aktuelle problem, tager en teknisk kandidatafhandling typisk udgangspunkt i litteraturen. Afhandlingen beskriver for læser, hvordan den bidrager til den eksisterende viden ved at adressere et spørgsmål, der endnu ikke er besvaret (et hul i videnskaben). Introduktionen til et projekt fungerer godt med en hierarkisk struktur, der starter bredt og ender fokuseret med et konkret undersøgelsesspørgsmål. Som beskrevet i kapitel 12 starter introduktionen i et diplomingeniørprojekt ofte bredt ved fx at fortælle læseren om den virksomhed, hvori problemet findes, og slutter med problemformulering og afgrænsninger. Den akademisk orienterede tekniske kandidatafhandling begynder i stedet med at beskrive problemet mere generelt (altså ikke specifikt for virksomheden). I denne problembeskrivelse inddrages den eksisterende litteratur, dels for at understøtte, at problemstillingen har relevans og bør undersøges, og dels for selvstændigt at udpege det hul i videnskaben, som projektet vil fylde.

Eksempel på en introduktion til et projekt om reduktion af servicebesøg på havvindmøller Et projekt handler om at reducere antallet af servicebesøg til en særlig elektrisk komponent, der sidder i havvindmøller og producerer strøm i et salt miljø. Teknikerne på virksomheden mener, at den salte luft påvirker komponentens holdbarhed, og projektets undersøgelsesspørgsmål lyder: "Hvordan påvirker saltholdigheden i komponentens miljø antallet af servicebesøg over komponentens livslængde?". Hvor et diplomingeniørprojekt ville begynde med at introducere virksomheden, bør kandidatafhandlingen i stedet lægge ud med at fortælle helt generelt om saltholdigt miljø og dettes påvirkninger. I introduktionen bør stå, hvad den videnskabelige litteratur fortæller om salte miljøers påvirkning af elektriske komponenter, og at det undersøgelsesspørgsmål, som projektet har valgt, endnu ikke er besvaret til fulde.

Kandidatafhandlingens problemformulering projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

I eksemplet ovenfor, der handler om servicebesøg hos havvindmøller, ville et diplomingeniør-projekt arbejde med en problemformulering, der lyder: "Hvordan kan [virksomhed X] reducere antallet af servicebesøg til den elektriske komponent i virksomhedens havvindmøller?". En kandidatafhandling bør i stedet vælge en problemstilling, hvis besvarelse bidrager til den generelle videnskab frem for kun den specifikke virksomhed. At bidrage til videnskaben betyder (sagt lidt firkantet) at bidrage til vores alles fælles forståelse af, hvordan verden hænger sammen. Kandidatafhandlinger er det tætteste på forskning inden for uddannelsessystemet. De handler ligesom forskning om at berige forståelsen af sammenhænge mellem ting. Ordet ting lyder umiddelbart ikke særligt akademisk, og de enkelte fagområder erstatter da også ordet ting med begreber såsom entitet eller variabel. På engelsk er construct populært. På tekniske fagområder er variabel det mest almindelige. Variabel implicerer oftest kvantitativ målbarhed. At bidrage til videnskaben betyder at bidrage til viden omkring variablers sammenhæng, dvs. hvordan og hvorfor én variabel påvirker en anden variabel. Den påvirkede variabel kaldes ofte for den afhængige variabel, og den påvirkende variabel kaldes den uafhængige variabel. Tabel 16.1 præsenterer en række eksempler på undersøgelsesspørgsmål, der handler om sammenhængen mellem to variable. Kolonne 1 viser uafhængige variable og kolonne 2 afhængige variable. Kolonne 3 viser, hvilken videnskab de to variable hører til. Den uafhængige variabel (variabel 1)

Den afhængige variabel (variabel 2)

Den videnskab, der undersøger sammenhængen mellem de to variable

Godstykkelsen på en bjælke af et særligt nyt materiale

Bjælkens brudstyrke

Byggerividenskaben

Mængden af en særlig type pesticider

Ukrudtsmængden i et landbrug

Landbrugsvidenskaben (agronomi)

Mængden af konserveringsmiddel i en bestemt type fødevare

Fødevarens holdbarhedstid

Fødevarevidenskaben

Ankomstrate til en kø

Den gennemsnitlige køtid

Managementvidenskaben

Opfattelsen af Gudmenneskerelationen hos Martin Luther

Martin Luthers foretrukne styreform

Religionsvidenskab eller teologi

Den gennemsnitlige mængde af D-vitamin i blodet

Livslængde

Medicinvidenskaben eller farmakologi

Tiden brugt på sociale medier, fx Facebook og Instagram

Ensomhed hos brugerne af de pågældende medier

Psykologi eller sociologi

Tabel 16.1. Sammenhængen mellem to variable i forskellige undersøgelsesspørgsmål Tabellen viser, at ønsket om at forstå, hvordan ting hænger sammen, findes på tværs af videnskaber. Fordi kandidatafhandlinger handler om tings sammenhæng, er der især tre problemformuleringer, der går igen i tekniske kandidatafhandlinger (og forskning i øvrigt). Disse ses i tabel 16.2. Nr.

Problemformulering

Bemærkninger

1

"Hænger A sammen med B?"

Svaret på denne problemformulering kunne være "Ja!". Den gode kandidatafhandling uddyber dette med en række refleksioner omkring sikkerheden i ja'et, om mulige fejlkilder og forbehold samt en afgrænsning af, under hvilke omstændigheder ja'et gælder.

2

"Hvordan hænger A sammen med B?"

Denne problemformulering er aktuel i tilfælde, hvor det allerede er kendt, at de to ting hænger sammen, men hvor karakteren af sammenhængen er ukendt. Svaret på denne problemformulering er en beskrivelse af, hvordan A påvirker B; fx "Hvis A øges, reduceres B". I byggerividenskaben kunne svaret lyde: "Hvis densiteten af et byggemateriale til vægge mellem to rum øges, reduceres støjniveauet mellem de rum, som væggen adskiller."

3

"Hvorfor hænger A sammen med B, som den gør?"

Denne problemformulering er oftest den sværeste at besvare. Tages der udgangspunkt i eksemplet ovenfor, ville kandidatafhandlingen således handle om at finde en forklaring på, hvorfor materialedensitet påvirker støjgennemstrømning.

Tabel 16.2. Typiske problemformuleringer i tekniske kandidatafhandlinger Der findes selvfølgeligt andre typer spørgsmål. De kan fx handle om at identificere en bestemt række faktorer, at udvikle en metode, at optimere en metode eller at afdække et nyt og ukendt område for første gang. Når problemformuleringen er nedfældet, er næste skridt kritisk at definere projektets begreber og beskrive den litteratur, der kommer tættest på projektets problemformulering. På den måde anvender og bygger projektet på den tidligere publicerede litteratur.

Kandidatafhandlingens teori- og litteraturanvendelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Kandidatafhandlingens kapitel om teori følger typisk lige efter undersøgelsesspørgsmålet og kaldes ofte litteraturstudie eller på engelsk literature review. Hvor anvendelsen af teori fra uddannelsens obligatoriske kurser er almindelig praksis i mange tekniske projekter, kræver kandidatafhandlinger som regel, at studerende anvender den mest relevante teori for problemstillingen, uagtet om denne teori er pensum i et af uddannelsens kurser. Principielt er det således helt tilfældigt (og altså usandsynligt), hvis den mest relevante teori skulle være i uddannelsens obligatoriske pensum. Hvis man forestiller sig et projekt, der handler om reduktion af leveringstiden på ordrer fra en fiskefileteringsfabrik ud til butikkerne i detailhandlen, vil et diplomingeniørprojekt typisk anvende generel teori om produktion og logistik fra uddannelsens obligatoriske pensum. En kandidatafhandling vil derimod søge efter teori, der er udviklet særligt om fiskefiletering. Hvis denne teori ikke findes eller ikke er fyldestgørende, kan man anvende teori om generel fødevareproduktion, og først hvis denne teori heller ikke findes eller er brugbar for problemstillingen, kan man anvende den helt brede teori, der gælder for leveringstidsreduktion i alle sammenhænge. Det er som regel et krav til kandidatafhandlinger, at litteratursøgningen er dokumenteret, og at projektet argumenterer tilstrækkeligt for, hvilken litteratur projektet anvender. Selvom du anvender den helt brede teori, er det som regel forventet, at du har dokumenteret søgeprocessen og også gerne argumenteret for dit eventuelle fravalg af mere specifik, men ikke fyldestgørende eller brugbar teori. I eksemplet om fiskefiletering skal du altså argumentere for fravalget af teori om fiske- eller fødevareproduktion, således at eksaminator og censor kan sikre sig, at dit teorivalg er det rette. Gode argumenter er fx, at den specifikke teori om fiskeproduktion ikke findes eller handler om andre ting end leveringstidsreduktion, der er projektets problemstilling. Kandidatafhandlingen dokumenterer litteratursøgningen ved at beskrive den proces, du har gennemgået for at finde den relevante teori. Denne proces indledes typisk ved at søge efter relevant litteratur på universitets digitale bibliotek. Dette gøres ved at anvende søgestrenge. En søgestreng indeholder alle de relevante nøglebegreber (key words), der afgrænser søgningen til at finde kun den litteratur, der er mest relevant for projektet. Et universitets søgemaskine leder typisk i alle bøgers og artiklers titler, abstracts og key words. Nedenstående boks beskriver, hvad søgestrenge konkret er, og hvordan de opbygges.

Eksempel på opbygning af søgestrenge

En kandidatafhandling handler om udviklingen af en overfladebehandling til hydraulikkomponenter, der anvendes i salte miljøer (fx i havvindmøller). Søgningen af relevant teori påbegyndes med følgende søgestreng: "surface treatment" AND hydraulic* Denne søgestreng indeholder en række elementer, der afgrænser en søgning. Ordet AND er en såkaldt boolsk operator (efter den engelske matematiker George Bool). AND fortæller søgemaskinen, at ordene både til venstre og højre for AND skal indgå i alle de artikler og bøger, der er i søgningens resultat (kaldet søgningens hits). Denne søgning stiller altså krav om to begrebers tilstedeværelse i enten titel, abstract eller key words i de artikler, der ligger i det digitale bibliotek. Citationstegnene omkring "surface treatment" betyder, at søgemaskinen kun returnerer hits, hvor surface og treatment står lige efter hinanden. Asterisken (*) fortæller, at søgestrengen returnerer hits, hvori ord, der begynder med hydraulic, indgår, uagtet om ordet slutter af med flere bogstaver (fx ordet hydraulics med et ekstra s på). Resultatet af søgning er ca. 1.000 hits (i DTU's universitetsbibliotek). Blandt hittene er en artikel i tidsskriftet Materials Research Innovations med overskriften "Analysis of antiwear for hydraulic relief valve under different surface treatment processes", der handler om sammenhængen mellem ventiloverfladehandling og ventilslitage. Søgningen er således på rette vej. Hvis antallet af hits er uoverskueligt stort, kan søgestrengen gøres mere specifik. For eksempel kan søgestrengen udbygges således: "surface treatment" AND hydraulic* AND ("high salinity" OR "high saltiness") OR er også en boolsk operator og fortæller, at søgemaskinen returnerer hits, der indeholder enten begrebet til venstre for OR eller begrebet til højre for OR. Litteraturkapitlets indhold bør som nævnt være en beskrivelse af den litteratur, der kommer tættest på projektet. Kapitlet bør inkludere en redegørelse for, hvordan projektet adskiller sig fra den tidligere litteratur, dvs. hvordan projektet bidrager til feltet. Kapitlet om litteratur benyttes ligeledes til at definere de væsentligste begreber og operationalisere teori, således at projektets kapitel om metoden, der følger litteraturkapitlet, kan specificere teoriens anvendelse i projektets analyse. Se nærmere i det følgende afsnit.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Metoden

Når undersøgelsesspørgsmålet er på plads, og teorien i litteraturen er behandlet, er det muligt at vælge den rette metode. I tekniske kandidatafhandlinger kan første skridt være en beskrivelse af det videnskabsteoretiske standpunkt, som projektet anlægger. Om videnskabsteori behandles eksplicit i rapporten, er dog højst forskelligt de tekniske uddannelser imellem. Som nævnt i kapitel 5 beror mange tekniske projekter på en positivistisk naturvidenskabelig videnskabsteori, hvis beskrivelse mange vejledere ikke vægter højt i et projekt. Efter et eventuelt videnskabsteoriafsnit beskrives "det store metodevalg". Det store metodevalg handler om at vælge den rigtige metode til projektets analyse. I et teknisk projekt er det store valg ofte en af følgende: matematisk modellering, et casestudie, en survey, et eksperiment eller en kombination af disse. Senere kommer en række mindre metodevalg, der fx handler om at vælge en måde at opstille data på eller sikre pålidelige data. En metode kan være enten rent kvantitativ eller et miks mellem kvantitativ og kvalitativ. Væsentligt er at argumentere for projektets metodevalg ud fra undersøgelsesspørgsmålet. Læser skal helst sidde med mavefornemmelsen af, at "selvfølgelig er det den korrekte metode – alt andet ville lede til en mindre valid eller decideret nonsenskonklusion". Har læser den mavefornemmelse, er argumentationen perfekt. Ofte er der en sammenhæng mellem metodevalg og fagområdets modenhed. Hvis fagområdet er relativt uudforsket, er casestudier, der afdækker landskabet og identificerer relevante variable og undersøgelsesspørgsmål, ofte den mest passende metode. Hvis området er velbeskrevet i litteraturen, kan forskningen og kandidatafhandlinger udvikle konkrete matematiske udtryk, der binder variable sammen, eller udsende surveys med spørgsmål, man kan forvente, at læser forstår. Udvikling af nye teknologier bygger også på veldokumenterede forskningsresultater.

Analyse og resultater projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Analyse- og resultatkapitlet bør placeres umiddelbart efter metodekapitlet. Analyse og resultatkapitlet bør koldt og nøgternt beskrive de resultater, analyserne viser. Resultater kan beskrives med ord, men også gennem diagrammer, tabeller, matematiske udtryk, tegninger, en række interviewcitater eller en kombination af flere af disse resultattyper. Hvilke resultattyper der er de rette, kommer helt an på, hvilket spørgsmål undersøgelsen adresserer. Analyse- og resultatkapitlet bør ikke prøve at forklare resultaterne eller fortolke resultaternes betydning. Dette bør i stedet beskrives i projektets diskussion.

Diskussion og konklusion projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Kandidatafhandlingens to afsluttende kapitler udfører en række funktioner i projektet. Diskussionen skal diskutere resultaterne. At diskutere betyder at forholde sig til to specifikke spørgsmål: 1) Hvorfor blev resultaterne, som de blev, og 2) hvilke dele af den litteratur, som projektet har bragt i litteraturkapitlet, understøtter projektets resultater, og hvilke dele understøtter de ikke? I diskussionen kan du relativt frit frembringe mulige forklaringer af resultaternes art. I diskussionen bør du forholde dig til resultaterne set i lyset af den litteratur, som projektet har beskrevet i litteraturkapitlet eller i introduktionen. Hvis litteraturkapitlet er grundigt, bliver diskussionen alt andet lige bedre. I konklusionen sammenfattes projektets resultater og eventuelt væsentlige diskussionspunkter. Ud over dette bør konklusionen 1) redegøre for projektets bidrag til teori og praksis, 2) redegøre for og diskutere projektets begrænsninger og 3) give forslag til fremtidig forskning. Disse tre punkter kan være deres egne selvstændige kapitler i projektrapporten, men de kan også fint være underpunkter under konklusionen. Et ofte anvendt teknik er at udlede forslag til fremtidig forskning ud fra projektets begrænsninger ("Projektet er begrænset af … Fremtidig forskning kan bidrage ved at …").

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Opsummering

I dette kapitel har du lært, at tekniske kandidatafhandlinger kan være problemløsende projekter, som denne bog handler om, eller akademisk orienterede kandidatafhandlinger, som dette ene kapitel handler om. Du har lært, at kandidatafhandlinger adskiller sig fra problemløsende projekter i deres formål og struktur. Kandidatafhandlingers problemformulering er undersøgelsesspørgsmål, hvis besvarelse bidrager til videnskaben, og deres opbygning følger den traditionelle opbygning i akademiske papers. Som studerende, der udfører kandidatafhandlingen, skal du håndtere universitetet som en tungere vejende interessent end ved problemløsende projekter. Kapitlet beskriver de væsentlige karaktertræk ved tekniske kandidatafhandlinger, og hvordan kandidatafhandlinger lokaliserer og anvender teori, foretager metodevalg og beskriver metode, analyse, diskussioner og konklusioner i projektrapporten.

Projekter og rapporter på teknisk uddannelse projekterograpporterpaatekniskeudd-2udg.digi.hansreitzel.dk

Referencer

Booth, W.C., Colomb, G.G. og Williams, J.M. (2008), The Craft of Research, 3. udg., The University of Chicago Press. DeLuca, J. (1984), "Managing the Socio-political Context in Planned Change Efforts. Elements of a Framework for Practitioners", i: Kakabadse, A. og Parker, C. (red.), Power, Politics, and Organizations: A Behavioral Science View, Wiley. Kotter, J.P. (1998), I spidsen for forandringer, Peter Asschenfeldts Nye Forlag. Lippman, L.H., Ryberg, R., Carney, R. og Moore, K.A. (2015), Workforce connections – Key "soft skills" that foster youth workforce success: Towards a consensus across fields, Washington, DC, refereret i Golinkoff, R.M. og Hirsh-Pasek, K. (2016), Becoming brilliant – What science tells us about raising successful children, APA, Washington, DC. Maylor, H. (2017), Project Management, 4. udg., Pearson Education Limited. Minto, B. (2009), The Pyramid Principle – Logic in Writing and Thinking, 3. udg., PrenticeHall. Reid, N. (2018), Getting Published in International Journals, 2. udg., Professional Publications Press. Rienecker, L. og Jørgensen, P.S. (2017), Den gode opgave, 5. udg., Samfundslitteratur. Sirkin, H.L., Keenan, P. og Jackson, A. (2005), "The Hard Side of Change Management", Harvard Business Review, October. Tuckman, B. (1965), "Development sequence in small groups", Psychological Bulletin, Volume 62, No. 6, pp. 384-399.