Der er sikkert mange, som har oplevet meget strenge deadlines i projekter.
Nogle gange kan det være fint med en deadline, og ofte vil det måske hjælpe til at skabe fremdrift at man ved man skal være færdig på et bestemt tidspunkt.
Men andre gange kan deadlines virke irriterende og måske endda helt ødelægge et projekt.
Her er et blogindlæg af Duncan Riach, hvor han mener at deadlines ofte gør et projekt værre (advarsel - langt indlæg):
https://medium.com/@duncanr/deadlines-are-killing-us-and-almost-everythi...
Artiklen handler om meget mere end det. Den handler bl.a. om 'micro-management' og hvordan god ledelse kan forbedre processen. En interessant observation er at han mener at agile metoder og især Scrum gør at man kan arbejde uden deadlines, selv om det han kalder en agil kontrakt netop baserer sig på en deadline.
Hvad siger læserne? Har I tit været ude for vilkårlige deadlines, som virker demotiverende på et projekt, eller er det bedst at man har en tidsmæssig bagkant, sådan at man har noget at arbejde ud fra?
Oplever I ofte at deadlines bare er der for at projektledelsen har noget at kunne måle på? Eller kan deadlines være et plus, også selv om de måske er opfundet uden at der er et forretningsmæssigt behov?
Deadlines kan til tider være afgørende for at levere en given løsning til en kunde.
Men for at kunne levere kræver det de rette ressourcer, med den rette viden og erfaring.
Om det så er agilt og/eller SCRUM ændrer ikke meget.
Hvis der i ledelsen ikke er vilje til at sætte de rette personer sammen, bliver løsning nok lavet til deadline, men i en kvalitet der efter deadline skal bruges en hel del tid på at stabilisere.
Hele businesscasen kan gå fløjten hvis der ikke leveres på en given deadline eller tidligere.
...på den ene side er det årsagen til at man ikke kan levere den perfekte løsning, “det bliver bedre i næste version”-problemet.
...på den anden side kører projekterne uendeligt for “det kan jo altid blive bedre”.
Hvis jeg aflevere min bil hos mekanikeren, så vil jeg da også gerne vide hvornår jeg kan hente den igen. Men hvis mekanikeren siger i morgen og der så ender med at gå yderligere 3 dage, så bliver jeg nok lidt knotten...
Og moralen? Deadlines kan være en nødvendighed. Og et projekt kan godt fungere med deadlines. Men det skal være realistisk og velovervejet. Og hvis en deadline overskrides, skal man prøve at forstå hvorfor og ikke bare på hvis skyld det er.
Hvis der er en høj grad af usikkerhed i et projekt, så er deadlines destruktive. Så bliver leverancen ikke det bestilte, men det som kunne laves inden for de opstillede rammer. Utzons operahus blev ikke til på deadlines, men Sydney ville være et fattigere sted hvis deadlines havde dræbt projektet.
Omvendt - hvis det hele er rutinearbejde og projektet kan brydes ned i forudsigelige milestones med realistisk tidsallokering, så kan deadlines være nyttige, så stakeholders har noget at planlægge efter.
Som sidebemærkning hader jeg ordet deadline. Det er jo sjældent folk afgår ved døden som konsekvens af forsinkelse. Det bliver mere spiseligt hvis man afdramatiserer og kalder fænomenet det som det er - nemlig leveringsdato. Og i stedet for at frygte at man overskrider en deadline, så vend det til noget positivt og sæt en ære i et gennemføre en leverance på den aftalte leveringsdato.
Og beslutningstagere: Lad være med at lave alting i sidste øjeblik. Rettidig omhu - uanset om man har dødslinjer eller ej.
Og beslutningstagere: Lad være med at lave alting i sidste øjeblik. Rettidig omhu - uanset om man har dødslinjer eller ej.
Så slipper man også for alvorlige kattepiner, når deadlinen er hængt op på en kontrakt hvor man skifter fra leverandør A til leverandør B. Leverancen kan jo trække ud - uden at det nødvendigvis er leverandøres skyld. Så kan det være rigtig dyrt at "forhandle" drift et par måneder ekstra af det gamle system.
Der er brug for afleveringsfrister som det vel hidder på almindeligt dansk. Det der er problemet er når de misbruges. Når der laves afleveringsfrister der ikke har hold i virkeligheden.
Et af de store problemer idag er positivitisk (urealistisk) planlægning. Når man kommer med indvendinger bliver man ofte beskyldt for at være "negativ" og bagstræberisk. Jeg synes der er rigtigt mange eksempler på dette i øjeblikket.
Det engelske udtryk "the perfect is the enemy of the good" indikerer også at man normalt har brug for en frist, så man undgår evige "forgyldninger".
Deadlines er ikke problemet, misbruget er.
Der er brug for afleveringsfrister som det vel hidder på almindeligt dansk. Det der er problemet er når de misbruges. Når der laves afleveringsfrister der ikke har hold i virkeligheden.
Et af de store problemer idag er positivitisk (urealistisk) planlægning. Når man kommer med indvendinger bliver man ofte beskyldt for at være "negativ" og bagstræberisk. Jeg synes der er rigtigt mange eksempler på dette i øjeblikket.
Det engelske udtryk "the perfect is the enemy of the good" indikerer også at man normalt har brug for en frist, så man undgår evige "forgyldninger".
Ja, jeg tror du rammer hovedet på sømmet. Der findes mange situationer, hvor man har en reel afleveringsfrist. Et godt nyligt eksempel er 25. maj 2018, da GDPR (persondataforordningen) blev effektueret. Mange GDPR-projekter har helt sikkert haft den dato som den endelige frist, fordi man så kunne sige at man var lovmedholdelig (compliant).
Men ofte ser man i projekter at man har en frist, som virker vilkårlig, og som måske ikke har rod i et reelt behov.
Hvad med Scrum og agil udvikling? Der har man jo også en frist, hvis man f.eks. bruger et 14-dages sprint. Er det også et problem? Der har man jo typisk selv haft indflydelse på hvad man tror man kan nå i den periode.
(Svar på dansk).
"Hvad med Scrum og agil udvikling? Der har man jo også en frist, hvis man f.eks. bruger et 14-dages sprint. Er det også et problem? Der har man jo typisk selv haft indflydelse på hvad man tror man kan nå i den periode
En agil sprint er en frekvens, ikke en deadline. Det er en status på hvad der er leveret, ift. hvad man forventede at kunne nå - samt en revurdering af kompleksistet på det der ikke kunne nås.
Valget står sædvanligvis mellem kvalitet, pris og tid (deadline) - og bør ikke være svært, men er det åbenbart ofte alligevel. Med agile kender du prisen på din development pipeline og bliver så ved til du har den nødvendige funktionalitet i brugbar kvalitet.
Deadlines kan være udmærkede til at undgå overforgyldte løsninger. Det klassiske spørgsmål er her: Hvornår er det godt nok.
Deadlines kan også være ødelæggende ved at gennemtvinge en minimumsløsning, som senere i forløbet viser sig uholdbar, fordi den er uegnet til at bygge videre på. Så er man slået helt hjem.
En agil sprint er en frekvens, ikke en deadline. Det er en status på hvad der er leveret, ift. hvad man forventede at kunne nå - samt en revurdering af kompleksistet på det der ikke kunne nås.
Interessant. Jeg er nu ikke helt enig med dig. Når man først har bestemt hvad der skal leveres i et sprint, må slutdatoen for sprintet svare meget til en deadline. Men jeg vender nok tilbage til det i et senere indlæg.
Valget står sædvanligvis mellem kvalitet, pris og tid (deadline) - og bør ikke være svært, men er det åbenbart ofte alligevel. Med agile kender du prisen på din development pipeline og bliver så ved til du har den nødvendige funktionalitet i brugbar kvalitet.
Ja, her har vi fat i projekttrekanten, som er ret essentiel i alle projekter. Det vil jeg også vende tilbage til på et senere tidspunkt. I øvrigt er der mange som lægger flere parametre ind, så det ikke længere er en trekant, f.eks. scope, risiko og ressourcer.
Man får en stakket frist.
Pointen med sprints er netop at det ikke er een deadline, men løbende afrapportering så man sikrer at det man så i krystalkuglen nu også holder i den virkelige verden.
Men altså, man har ikke ved projektstart fastsat hvornår man stopper, det er en funktion af det leverede (= kvaliteten) - som i sagens natur kræver en produktejer der forstår sin forretning.
Scope og risiko er en del af kvaliteten også, ressourcer er ret præcist definerende for projektets pris - så ingen grund til at komplicere eller udvande tingene yderligere.
Pointen med sprints er netop at det ikke er een deadline, men løbende afrapportering så man sikrer at det man så i krystalkuglen nu også holder i den virkelige verden.
Det kan man sagtens gøre også uden at køre sprints. Fasemodellen, som f.eks. PRINCE2 lægger op til, anvender netop disse principper for at sikre den bedst mulige styring igennem hele projektet.
Et godt nyligt eksempel er 25. maj 2018, da GDPR (persondataforordningen) blev effektueret. Mange GDPR-projekter har helt sikkert haft den dato som den endelige frist, fordi man så kunne sige at man var lovmedholdelig (compliant).
Hvad skete der så hvis man var en uge forsinket?
I bund og grund handler det om mennesker og gensidig respekt.
Problemet er vel mest at de fleste deadlines, intet har med en deadline at gøre. I min verden findes der 2 slags valide deadlines.
Den ene er rent tidsbaseret. Hvis jeg skal give en præsentation kl. 13.00 på mandag, så er det min deadline for den præsentation. Hvad end jeg har klar der, er hvad jeg kan præsentere. Kl. 13.00 er det bedre at have 100% af en acceptabel præsentation end at have 50% af en exceptionel præsentation. Uanset hvad, efter kl. 13 giver det ingen mening at arbejde videre på præsentationen.
Den anden er et givent mål til en givent tidspunkt. Nogen muligheder er generelt tidsbegrænsede i natur. Hvis man kan levere en tilfredsstillende løsning før det givne tidspunkt, så har det en betydelig værdi, men hvis løsningen er for dårlig, eller klar for sent, giver det ingen værdi. Derfor kan det være praktisk at vide om man skal forfølge den deadline eller ej.
I realiteten kommer deadlines jo fra avis-verdenen. Hvis man kunne levere en vigtig nyhed før dagens avis skulle i trykken kunne man sælge væsentligt mere af sit oplæg. Men hvis historien ikke nåede frem før deadline ville en anden avis nok har dækket det samme dag og derfor så var historien reelt død hvis den missede trykkeren.
