Ny uddannelse i projektledelse skal give it til tiden

Syddansk Universitet vil undervise i projektmageri, som ikke ender i tårer.

En ny masteruddannelse i projektledelse på Syddansk Universitet skal give it-projekter, som ikke ramler ned over ørene på virksomheder og institutioner.

Der er plads til 40 studerende på masteruddannelsen i projektledelse på Syddansk Universitet, når det første hold begynder i september i år.

Uddannelsen er den første i Danmark, som fokuserer på projektledelse i denne kaliber.

»Gang på gang bliver store projekter i virksomheder og det offentlige forsinkede. De bliver dyrere eller dårligere end planlagt, og årsagen er ofte, at der er for få kompetente projektledere herhjemme,« siger Martin Toft Hansen, som er projektleder inden for it samt områdedirektør i konsulenthuset IPTeams, der leverer projektledere til store og forretningskritiske it-projekter i den private og offentlige sektor.

»Den nye masteruddannelse vil føre til et højere kompetenceniveau i Danmark og føre til mere effektivt gennemførte projekter,« mener Martin Toft Hansen.

Masteruddannelsen er udviklet i tæt samarbejde med repræsentanter fra en række store virksomheder og det offentlige, hvilket afspejles af uddannelsens referencegruppe, som består af ledere og konsulenter fra blandt andet Danfoss, KMD, Nordea, Skat og TDC.

Ifølge lektor Pernille Eskerod fra Syddansk Universitet stilles der høje krav til projektledere på højt niveau:

»De skal både være bevidste om personlig lederadfærd, være i stand til at kommunikere hensigtsmæssigt, kunne analysere projektet og den konkrete situation og fungere i en dynamisk og kompleks situation. Det er til denne virkelighed, vi uddanner kandidater,« forklarer Pernille Eskerod.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (29)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Steen Krøyer

Hvis problemet med projekter der overskrider budget og tidsplaner kunne løses ved at uddanne projektledere bedre, var det løst for længe siden. Men de bagvedliggende årsager til de højtprofilerede fiaskoer vi så tit læser om, er som regel hinsides projektlederens kontrol. Sorry, så kald mig kynisk, men nu har jeg været i gamet for længe til at tro på hvide kaniner der hives op af en hat og løser denne type af problemer. Uddannelse af projektledere er helt fint, men det gavner primært hele "projektleder-uddannelsesindustrien".

  • 0
  • 0
Jon Loldrup

Det er jo kendt at der er stor forskel på gode og dårlige programmører, og at det er svært at uddanne sig væk fra at være en dårlig programmør - at være en god programmør er mere noget der kommer indefra.
Ved vi om det at være en god god programmør korrelerer (stærkt) med det at være en god projektleder?
Og ved vi om gode projektledelsesevner primært kommer indefra, ligesom det gælder for gode programmørevner?

  • 0
  • 0
Jacob Christian Munch-Andersen

Det er faktisk ikke så svært, lidt sund fornuft kan flytte bjerge.

  1. Lad være med bare at hælde penge i projektet, selvom begrebet EDB-system kan lyde stort, og selvom systemet måske får mange 1000 brugere og en kæmpe database så er det ikke nødvendigvis så skide svært at lave. KMD og den slags tøplere vil gerne overbevise deres kunder om det modsatte, jeg behøver næppe at forklare motivet. Problemet er så at når leverandøren har fået en masse penge så skal projektet også ligesom afspejle beløbet, og så bliver det bloated.

  2. Få brugerne med. At bestille systemet, og så bare vente på at det bliver færdigt er ikke helt godt nok, kan man få egne medarbejdere til jævnligt at afprøve systemet og hjælpe udviklerne med at rette uhensigtsmæssigheder ja så har man rent faktisk en chance for at systemet er i en tilstand der kan betegnes som "klar til brug" når det rulles ud.

  • 0
  • 0
Poul-Henning Kamp Blogger

Når folk der ikke har erfaring i IT branchen bliver sat på som projektledere, hvadenten de er grønne eller garvede fra andre brancher, så er det første de skal lære at standarden for kvalitet og præcision i IT branchen er utrolig lav.

Når de så har lært det og derved oparbejdet den kynisme der gør at de kan holde et projekt indenfor budget og tid, vil de som regel ikke have noget med en så snusket branche at gøre, hvis de på nogen måde kan undgå det.

Nej, jeg giver ikke en nyuddannet projektleder store chancer for success.

Poul-Henning

  • 0
  • 0
Peter Corneliussen

@ Søren Hilmer
Hvorfor er det meningsløst at undervise i andet end agile metoder? I mine øjne er det (og har altid været) en misforstået holdning at agile metoder per definition er den bedste indgangsvinkel, det afhænger vel af typen af systemer/applikationer?

  • 0
  • 0
Jacob Christian Munch-Andersen

Ej ok, det var måske sat lidt for sort hvidt op. Men det er til tider utroligt hvad folk med mange penge overser.

Gode (og præcise) kravspecifikationer kan jo være et værktøj til at undgå at blive taget alt for meget i røven, men jeg har svært ved at forestille mig at de kan gøre det ud for en leverandør som rent faktisk ønsker at levere et godt produkt. Så ja, hvis man først har fået fat i en ordentlig leverandør burde det ikke være nødvendigt at fluekneppe med specifikationerne.

  • 0
  • 0
Kristian Thy

Jeg kan oplyse at Søren Lauesen kører et glimrende kursus i Kravspecifikation på ITU :)

Hvis der er én ting man tager med sig derfra, så er det at det vigtigste er at sige hvad man vil have produktet skal kunne, ikke hvordan det skal implementeres.

  • 0
  • 0
Søren Hilmer

@Peter Corneliussen

Det korte svar er at de andre metoder generelt ikke virker :-)

Med agile metoder kan man nå at sadle om inden tingene går (rigtigt) galt, hvilket er vanskeligt med de traditionelle metoder. Denne faktor er uafhængig af system/applikation og faktisk meget væsentlig for at sikre success.

  • 0
  • 0
Søren Hilmer

Jeg er ret sikker på at det at være en god programmør korrelerer meget svagt med at være en god projektleder.

De gode programmører "gider" typisk ikke alt det projekledelses-fis med administration, møder,planlægning,... og det er sjældent man bliver god til noget man ikke gider.

  • 0
  • 0
Lars Hansen

Jeg opfatter det på den måde, at der klart er et behov for at blive bedre, både på leverandør og på kundeside. Hvis man læser Bonnerup rapporten om erfaringer med offentlige IT-projekter, så er det ikke noget kønt billede der tegnes af hverken (offentlige) kunder og leverandører.

  • 0
  • 0
Jacob Christian Munch-Andersen

Helt enig, en ændringsforespørgsel fra en slutbruger har lang vej til programmørerne hvis der kun er ledelse til ledelse kontakt, ikke blot er der en sandsynlighed for at nogen finder på at skrive lidt mere på regning på vejen, sikkerheden for at programmøren forstår problemet og ikke bare slavisk ændrer efter ordre er stærkt reduceret.

Noget som jeg fik hintet ved at læse på Wikipedia var at nogle tilsyneladende bruger antallet af omskrivninger af koden som et mål for effektivitet (altså jo mindre man skriver om, jo bedre). Jeg gad nok se en succesfuld romanforfatter med den indstilling. Personligt synes jeg at sammenligningen er god, jeg har det ihvertfald sådan at jeg kan da godt lave et program uden at skrive om, men skal det være sådan at man virkelig føler at det er et stykke kvalitetshåndværk med alle detaljerne på plads så skal der omskrivninger til, og såvel kode som grafiske elementer der ellers tog lang tid at lave må skrottes og erstattes af nyt.

Dejligt hvis man kunne rette i sine indlæg.

Ja, men vi har ikke direkte kontakt med sidens skaber, vi kan kun kontakte de lokale ansvarlige og håbe at de kan videreformidle forespørgslen til de rette personer. Selvom de fleste af os sikkert kunne implementere den funktion før frokost så er det ikke så let at få den lavet.

  • 0
  • 0
Peter Corneliussen

@Søren Hilmer

Nu er det ikke fordi jeg vil bringe debatten ud på et sidespor, det er jo ikke fordele og ulemper ved agil udvikling vi skal debattere, MEN; jeg vil nu stadig postulere at valget imellem agil/traditionel i nogle situationer ikke er givet på forhånd. I mine øjne afhænger det bla. af, hvorvidt man implementere en markeds-dreven eller "udviklings"-drevet strategi, og ISÆR hvilken type system/applikation man udvikler. Det er klart at man, hvis man udvikler applikationer til et marked der tit og ofte ændres, så er man nok bedst stillet med et element af agilitet, men der findes jo også virksomheder der udvikler software hvor det sagtens kan lade sig gøre at implementere en klassisk analyse-design-implementation-debugging-deployment -metode, det afhænger af typen og kontektsten. Noget helt andet er, at det vel er de færreste (faktisk ingen) virksomheder der i sandhed ER agile..selvom de måske nok vil postulere noget andet ;)

  • 0
  • 0
Jan Keller Catalan

Ja, men vi har ikke direkte kontakt med sidens skaber, vi kan kun kontakte de lokale ansvarlige og håbe at de kan videreformidle forespørgslen til de rette personer. Selvom de fleste af os sikkert kunne implementere den funktion før frokost så er det ikke så let at få den lavet.

Det mener jeg nu ikke er helt korrekt - jeg synes nok vi er nogle stykker, som kan give lidt feedback fra tid til anden.

Det er naturligvis ikke selve rediger-funktionen, som er særligt svær at lave, men i stedet for at patche på et uhensigtsmæssigt udformet debat-system, har vi samlet input sammen til en omskrivning fra bunden af - det varer nok ikke længe, inden I kan høste frugten af dét arbejde.

On-topic, så er det vel lige så forkert at sige

Er det mon Agile metoder, der undervises i?
Ellers er det jo IMO meningsløst.

som det vil være at sige

Er det mon vandfaldsmodel-metoder, der undervises i?
Ellers er det jo IMO meningsløst.

Der bør vel undervises i at lede projekter - heri vil så være gennemgange af de tilgængelige værktøjer, hvoraf agile udviklingsmetoder er nogle af dem. Men ultimativt bør uddannelsen vel sætte fokus på det rette værktøj til den rette opgave og give dem, der tager uddannelsen, evnen til at være åben overfor nye metoder - også dem, der til sin tid vil efterfølge de agile.

/Jan Keller Pedersen, Version2
Projektleder (og ansvarlig for, at version2.dk kan det, det skal og bør)

  • 0
  • 0
Ole Jepsen

Efter at have arbejdet med indførsel af Agile metoder i forskellige virksomheder i Danmark igennem adskillige år må jeg herfra melde: AGILE METODER VIRKER ALTSÅ!!! Så jeg håber virkelig meget at den nye uddannelse af projektledere vil træne de nye håbefulde i den tætte kommunikationsform og de hyppige demoer/leverancer som Agile metoder dyrker. Jeg håber også, at de personer der tilrettelægger uddannelsen skeler til de kompetencer for Agile og succesfuld projektledelse, som DSDM ligger til grund for en nyskabelse: Certificering af Agile Projektledere (se mere på www.dsdm.org).

Men virker Agile så altid? Et spørgsmål, som jeg tit får stukket ud... Jeg kan kun svare med en serie mod-spørgsmål: Hvornår gavner det IKKE et udviklingsprojekt at have et tæt og tillidsfuldt forhold til sine brugere? Hvornår er det mere effektivt at kommunikere via (ofte alenlange) kravspecifikationer og andre dokumenter - end det er at sikre dyb fælles forståelse gennem et tæt samarbejde og en rig face-to-face dialog? Hvornår er det IKKE en god ide at demonstrere færdige dele af systemet for brugerne/kunderne undervejs i projektforløbet, så eventuelle misforståelser kan fanges og korrigeres undervejs i projektet?

Dette betyder ikke, at Agile løser alle problemer. Selvfølgelig ikke! Agile byder bare på løsninger på nogle af vandfaldsprojetkernes udfordringer. F.eks. er der færre misforståelser i Agile projekter p.g.a. den stærke fokos på tillid, kommunikation og samarbejde. Og Agile projekter er bedre i stand til at reagere på ændringer i krav - p.g.a. den indbyggede regelmæssige reflektion over om vi nu også er på rette vej.

For at imødegå argumentet om, at der altid er nogen der kender et Agile eller xP eller Scrum projekt, der er gået galt må jeg sige: Ja - selvfølgelig. IT projekter går nogengange galt. Men hvis man kender de faldgruber der ligger i Agile projekter - og hvis man fokuserer på at undgå at havne i disse faldgruber, så giver Agile en STØRRE CHANCE FOR SUCCES end traditionelle metoder. Eksempler på faldgruberne, som nye og uerfarne projektledere og projektteams ind i mellem falder i er:

Man undlader at analysere krav og behov i dybden efter udviklingen er igangsat i den første iteration - fordi vanen fra vandfaldsprojekterne byder os af fokusere på implementering, når vi nu engang er startet på at implementere. Løsningen er naturligvis holde fast i det tætte samarbejde med brugerne og fortsætte analysearbejdet igennem hele projektet.

Man undlader at holde regelmæssige og hyppige demoer af den udviklede funktionalitet. Ledelse og sponsorer, som tidligere var vant til at få flere statusrapporter end Agile teams normalt skriver, mister tilliden til projektet fordi man nu slet ikke hører noget fra projektgruppen. Løsningen er naturligvis at man sørger for at holde hyppige demoer, hvilket ofte kræver en ret "bestemt" projektleder og/eller sponsor.

Så jo - Agile har nogle børnesygdomme som beskrevet i ovenstående faldgruber. Men AGILE VIRKER ALTSÅ når man kender og undgår disse faldgruber. Det er den entydige melding fra teams, projektledere og virksomheder, som har givet Agile metoder en ærlig chance.

Så "Go for it" Syddansk.

Go Agile når I skal undervise de nye super-projektledere!!!

  • 0
  • 0
Michael Rasmussen

Kan du nævne nogen typer af projekter, hvor agile metoder vil være mindre velegnet?

Min erfaring fortæller mig, at agile metoder har sin styrke i små og mellem store projekt teams, men går vi op i helt store projekt teams, kræver det en mere fasttømret struktur. Man kan dog sagtens inddele større projekt teams i mindre teams, og her anvende agile metoder på delprojekter.

  • 0
  • 0
Peter Corneliussen

Jeg betvivler overhovedet ikke at agile metoder indeholder elementer der kan løse nogle af de klassiske problemstillinger traditionelle metoder som e.g. vandfaldsmodellen til tider slås med. Min pointe er blot at agil udvikling ikke som standard er svaret på alt.

@Jan Keller Pedersen
Jeg vil give dig fuldstændig ret, begge postulater er forkerte. Min hovedpointe er at diskussionen om, hvorvidt agile eller traditionalle udvilingsmetoder er bedst efterhånden er kørt så langt at den nærmer sig det samme små-religiøse niveau som f.eks Windows Vs. Linux.

Og så vil jeg gerne igen komme med mit postulat om, at selvproklamerede "agile" virksomheder/udviklingsafdelinger, sjældent er det 100%, måske fordi der stadig er brugbare elementer i traditionelle udviklingsmetoder?

  • 0
  • 0
Jon Loldrup

Her er lige et par artikler som jeg godt kan anbefale - jeg har lige læst dem, og de var, for mig, øjenåbnere:

The new methology:
http://www.martinfowler.com/articles/newMethodology.html

Is design dead?:
http://www.martinfowler.com/articles/designDead.html

oversigt over koncepterne i extreme programming:
http://www.cutter.com/content-and-analysis/resource-centers/agile-projec...

  • 0
  • 0
Ole Jepsen

Hej Michael

Jeg tror som sagt, at visse elementer fra de Agile metoder altid er til gavn.

Men jeg tror slet ikke på, at alle projekter skal køres på samme måde - for alle projekter er jo forskellige.

Der er f.eks. brug for mere dokumentation og planlægning jo større og mere geografisk spredt projektet er. Og der er brug for mere QA og test jo større konsekvenser fejl har. O.s.v.

Men det omvendte er også tilfældet - og det synes mange at glemme. Det ER nu engang hurtigere med en face-to-face diskussion (gerne ved et white board) direkte eftefulgt af programmering af den pågældende funktionalitet - end det er med møder og referater og kravspecifikationer som kommunikationsform.

Og det ER mere effektivt at teamet rejser sig og samles omkring tavlen og aftaler hvem der laver hvad i dag - end det er at projektlederen udarbejder og rundsender en projektplan efter at have indhentet input fra alle de involverede.

Derfor bør vi altid - så vidt det kan lade sig gøre - stræbe efter mindre teams, der sidder sammen. Jeg mener faktisk, at man gå rigtig langt for at dele store projekter op i mindre teams - fordi mindre teams har brug for mindre overhead og fordi mindre teams dermed er langt mere effektive end større projektgrupper. Så det bør være en af vores mål som projektledere - at få (om?)organiseret projektet i mindre selvkørende teams.

Kun hvis det ikke kan lade sig gøre må vi kompensere med flere dokumenter og mere projektleder-planlægning.

Så er det nogle projekter, hvor Agile ikke virker...?

Det kommer an på hvordan man opfatter Agile. Hvis man som jeg synes, at et vigtigt element i Agile er, at man tilpasser sig til situationen (som det også fremgår af den Agile projektleders manifest - Declaration Of Interdependence - http://pmdoi.org/), så kan jeg ikke komme i tanker om nogen projekter hvor man ikke kan have glæde af elementer fra Agile metoder.

  • 0
  • 0
Kristian Haugaard

Det er jo fristende at besvare Michael's (lidt retoriske) spørgsmål med: "Ja, der findes da projekter hvor agile metoder er mindre egnede". Det synes i hvert fald at være det implicitte svar.

Når andre skriver at "agil udvikling ikke som standard er svaret på alt" er man vel på samme bølgelængde.

Jeg har været med til at lede mange projekter. Nogle har været ganske små (projektgruppe på 3 mand i mindre end ½ år). Andre har været ganske store (projektgruppe på over 20 mand i adskillige år). Jeg har aldrig nogensinde stået i en situation hvor agile metoder ikke ville have løst de fleste af projektets problemer.

For hvornår er det lige, at det er uhensigtsmæssigt at gøre kommunikationen i teamet hurtigt og effektiv (så problemer fx aldrig kan leve i mere end 24 timer), at vise fremdrift med færdigtestet og produktionsklar kode (og at lade kunden og brugerne reagere på det!) samt at facilitere muligheden for at skifte kurs undervejs i projektet??

Jeg får lyst til at spørge Michael selv: Kan du nævne nogen typer af projekter, hvor agile metoder vil være mindre velegnede?

Og til Per: Ja, der findes masser af virksomheder som påstår at være agile uden at være det, men er det fordi man har prøvet begge dele og fundet frem til at det traditionelle virker bedre - eller er det mon fordi man ikke har kunne vride sig ud af kløerne på sin egen vanetænkning?

Jeg tror på det sidste!

P.S. Det er da interessant, og glædeligt, at vi med det samme diskuterer Agile når talen falder på at gøre fremtiden for IT-projekter bedre…

  • 0
  • 0
Jacob Christian Munch-Andersen

Grunden til at jeg ikke kan tage udtalelser som Søren Hilmers seriøst er at uanset hvor smart det måtte være, så er Agile et buzzord. Det er et enkelt ord med en enormt bred og ikke specielt veldefineret betydning, der findes så mange forskellige definitioner og implementationer at det ikke giver mening at lovprise Agile uden at fremhæve specifikt hvad der er godt. I sidste ende er det jo ikke et spørgsmål om hvad man kalder sin metode, men hvad man rent faktisk gør.

Den ekstreme konsevens af brugen af buzzord kan være at nogen henter "10 steps for implementing Agile methods" på nettet og så følger denne "brugsanvisning" slavisk, så er det at folk glemmer at tænke selv og det alene at det står i denne brugsanvisning bliver grund nok til at gøre tingene på den måde. Og så går det galt, uanset hvor genialt konceptet har været for mennesker som har brugt det med den rette mængde kritiske tilgang.

Har man sat det op som en enten eller ting så er man allerede godt på vej til at dumme sig.

  • 0
  • 0
Jacob Christian Munch-Andersen

Er "Internet" også et buzzword... ;-)

Ikke nødvendigvis, men det kan godt bruges på den måde. Ex: "Vi er en Internetvirksomhed", "Vi satser på Internettet", "Internettet er fremtiden". Der er som du kan se masser af floskel potentiale i ordet.

Grunden til at man normalt ikke vil betegne "Internet" som et buzzord er at det har en meget veldefineret og relevant betydning, og de fleste mennesker har efterhånden fundet ud af at Internettet er et værktøj, ikke en løsning.

Om 5 år er der ikke nogen der siger Agile mere, for så har den styringsform der hitter et nyt navn. Et sted hvor man så på det tidspunkt benytter sig af Agile lignende metoder kan man på almindelig dansk sige at man bruger en projektstyringsform som er baseret på at man snakker med hinanden. Det lyder bare ikke specielt opfindsomt, så hvis man ikke har et buzzord til at beskrive det så bliver det ikke noget godt samtaleemne. Hvis et emne ikke kan tåle at blive oversat til almindelige termer er det et rimeligt godt tegn på at der er tale om noget buzz.

Selvom der kan være mange gode ting at hente ved at kigge på det der kaldes Agile, så er det altså hovedsageligt et nyt ord for den dybe tallerken.

Og specifikt til dig Ole, pas på med brugen af store bogstaver og udråbstegn, man får let det indtryk at du har problemer med at argumentere rationelt og forsøger at kompensere for dette ved at sætte ekstra fokus på dine postulater.

  • 0
  • 0
Peter Corneliussen

@ Jacob Christian Much-Andersen

hehe, det er ganske og aldeles off-topic men din slutbemærkning minder mig om en af Terry Pratchet's Dicsworld-bøger hvor det blev slået fast at tre eller flere udråbstegn er ensbetydende med "a psychotic and twisted mind" (og her hentyder jeg på INGEN måde til Ole!)

:)

  • 0
  • 0
Kristian Haugaard

Jacob Christian Much-Andersen skriver: "Et sted hvor man så på det tidspunkt benytter sig af Agile lignende metoder kan man på almindelig dansk sige at man bruger en projektstyringsform som er baseret på at man snakker med hinanden."

Hmmm... hvis det bare var så enkelt har du måske nok ret i at "Agile" er et buzzword (noget tyder nu på at vi i hvert fald ikke definerer "buzzword" på samme måde).

Det kunne være spændende at høre om de agile projekter du har deltaget i og under hvilke omstændigheder?

Og mht. den dybe tallerken så har du formentlig ret hvis vi holder os på et teoretisk niveau. Nogle vil da måske endda hævde at Royce forsøgte at beskrive en iterativ proces (men blev misforstået). Jeg har endda hørt teoretikere trække sporene fra Agile helt tilbage til Sun Tzu.

Men helt ærligt; er det så relevant for det vi debatterer her?? Der er mange eksempler på at virksomheder har haft stor succes med en agil tilgang (ups, dér har Jacob Christian Much-Andersen i øvrigt sit ønskede almindelige danske ord :-), ligesom der er eksempler på at indførelsen har været vanskelig. Sådan er det jo! (med kun ét udråbstegn…)

  • 0
  • 0
Jacob Christian Munch-Andersen

Nej altså egentlig behøver det jo ikke at gøre så stor forskel om man kalder et ord buzz eller ej.

Det som et buzzord som Agile gør er at polarisere debatten, man kommer let til at diskutere det som en enten eller ting, i stedet for at diskutere hvilke Agile elementer der er gode så bliver spørgsmålet Agile eller ej? Det er ikke gået galt i den her debat, men andre gange er det frygteligt.

Der er mange eksempler på at virksomheder har haft stor succes med en agil tilgang

Det er en ren fordanskning, hvis du ikke kender buzz betydningen af det tilsvarende engelske ord så er den sætning tågesnak. I den sammenhæng er det derfor ikke et almindeligt ord, og du kan godt pakke din barnlige skadefrohed sammen.

  • 0
  • 0
Log ind eller Opret konto for at kommentere