Software til kvalitetssikring af tidsplaner

Enhver god planlægger, der arbejder med større projekter, har et antal kontroller, som gennemføres med et vist interval for at sikre tidsplanens kvalitet. Afhængig af projekternes kompleksitet, kan det være enkle kontroller, som at kontrollere at der sat en ansvarlig på alle aktiviteterne, til mere avancerede analyser, som f.eks. om der er forsvundet aktiviteter siden sidste opdatering af tidsplanen. Analyserne kan laves med forskellige views, eller ved at trække data ud i Excel og jonglere rundt med disse data. Drømmen er selvfølgelig, at man kan trykke på en knap, og så har man alle svar. Der bliver derfor udviklet flere og flere værktøjer, der kan minimere analysearbejdet.

Software til kvalitetssikring af tidsplaner bliver således mere og mere almindelige; det kan være værktøjer, der er en del af beregningen af tidsplanen (scheduling), det kan være værktøjer til at analysere kvaliteten af tidsplanerne og det kan være værktøjer til at sammenligne to tidsplaner. Eksempler på kontroller er:

Direkte i tidsplanen – loop analyser, der sikrer at man har linket aktiviteter på en måde så projektet kan afsluttes (altså at man ikke har linket aktiviteterne på en sådan måde at man kører i loops og aldrig bliver færdig).
Kvaliteten af tidsplanen – er alle aktiviteter i tidsplanen linket, så de afsluttes inden projektet er færdigt?
Sammenligning af to tidsplaner – hvilke nye bindinger er til kommet og hvilke er forsvundet siden sidste opdatering?

Værktøjerne kan være indbygget som en del af projektstyringsværktøjet, eller det kan være tredjeparts produkter som er gratis eller kan købes. Nedenfor har vi forsøgt at skabe et overblik over mulighederne med, og nytten af, funktionaliteten i værktøjerne. Målet er at I som brugere får en bedre forståelse af mulighederne og begrænsningerne med disse værktøjer, og dermed får et bedre grundlag for at vurdere om det er noget I generelt kan have nytte af, samt en hjælp til at vurdere de enkelte værktøjer.

Vores opfattelse er, at de enkelte funktioner i værktøjerne varierer, fra funktioner der er utrolig nyttige til funktioner der er ubrugelige. Ja det kan til og med være risikofyldt at bruge funktionerne, fordi de kan fjerne fokus fra det væsentlige eller drage konklusioner, der er decideret forkerte.

Vi har arbejdet med værktøjer af ovenstående type, vi har testet enkelte værktøjer og vi har qua vores tidligere job udviklet denne type værktøjer. Vi har ikke lavet en analyse af værktøjer på markedet, men følgende er eksempler:

Primavera – P6 Schedule Log
Primavera – P6 Claimdigger (kaldet “Schedule Comparison” i nyere udgaver af Primavera).
MSP – Project Guardian

Funktionalitet direkte i tidsplanerne:

I projektstyringsværktøjernes beregningsmoduler findes der altid en kontrol af om der er såkaldte Loops -Loops betyder at aktiviteterne er bundet sammen på en måde, så man kan køre rundt og rundt og aldrig bliver færdig med projektet. De gode værktøjer angiver hvor den eller de aktuelle loops findes, så det er enkelt at finde og rette fejlene.

En anden vigtig analyse der normalt udføres ved en beregning er lokalisering af såkaldte ”Out of sequence aktiviteter”, aktiviteter af tre typer:

Aktiviteter der enten ikke er afsluttet som planlagt inden den aktuelle rapporteringsdato. I nogle værktøjer flyttes disse aktiviteter automatisk, i andre værktøjer må aktiviteterne flyttes manuelt
Aktiviteter der er rapporteret færdige med datoer ud i fremtiden. Nogle værktøjer rapporterer denne type aktiviteter, i andre værktøjer må dette analyseres manuelt
Aktiviteter med låsninger der er umulige at overholde. Nogle værktøjer rapporterer denne type aktiviteter, i andre værktøjer må dette analyseres manuelt. Denne type aktiviteter vil selvfølgelig føre til negativt slæk i tidsplanerne

Kvalitetsanalyse af den enkelte tidsplan

Mange af værktøjerne til analyse af tidsplaner bygger på ” DCMA 14-point schedule assessment checking”, en liste der er udviklet af ” Defense Contract Management Agency” i USA. Vi har derfor, for at illustrere denne type værktøjer, benyttet denne liste og kort kommenteret de enkelte punkter nedenfor:

1) Checking the Logic – Dette er en analyse af, om aktiviteterne er bundet sammen på en måde, så det er muligt at lave en beregning af projektets slæk og projektets kritiske linje. Denne analyse skal man efter vores opfattelse være meget varsom med – får man et negativt svar, så er kvaliteten af tidsplanen dårlig. Får man et positivt svar, er det en indikation på at dem der har lavet tidsplanen sandsynligvis ved en del om planlægning, men tidsplanen kan stadig være ekstremt dårlig! Denne kontrol kan altså ALDRIG stå alene.

2) Looking for Leads – Man kan få aktiviteter til at overlappe hinanden, ved at angive en negativ tidsforskydning på de enkelte bindinger. Man skal være varsom med at bruge denne funktion, da man ofte skaber praktiske problemer og forvirring. Kontrollen er absolut fornuftig, og målet er iflg. DCMA at ”Leads” ikke forekommer.

3) Looking for Lags – Man kan skabe mellemrum mellem aktiviteter, ved at angive en positiv tidsforskydning på de enkelte bindinger. Denne kontrol er absolut fornuftig, og målet er, at max. 5% af aktiviteterne må have ”Lags”.

4) The Right Relationship Types – De fleste planlægningssystemer supporterer 4 typer af bindinger – start-start, start-slut, slut-start og slut-slut. Kontrollen foreskriver, at 90% af bindingerne eller mere, skal være af typen slut-start.

5) How about those Hard Constraints – Aktivitets låsninger (f.eks. start på en konkret dato) kan I høj grad fjerne fleksibiliteten i tidsplanerne. Kontrollen foreskriver, at der ikke må findes ”hårde låsninger” på mere ned 5% af aktiviteterne – det er vores opfattelse at 5% er en alt for høj værdi.

6) Rein-in your Total Float – Aktiviteter med et stort slæk indikerer, at aktiviteterne ikke er linket korrekt. Kontrollen foreskriver, at der ikke må findes mere end 5% af aktiviteterne med et stort slæk.

7) Negative Float is Never Good – Negativt slæk er ikke tilladt, da det dokumenterer at projektet ikke kan færdiggøres til tiden.

8) Break Down Those Long Durations – Aktiviteter er for lange hvis de er længere end 2 måneder. Kontrollen foreskriver, at antallet af lange aktiviteter bør begrænses til 5%. Det er vores opfattelse at længden på 2 måneder er helt projektafhængig og afhængig af projektets fase. F.eks. bør grænsen for gennemførelse af et shut-down projekt være langt lavere.

9) Check for Invalid Dates – Der må ikke være fremtidige aktiviteter der er rapporteret færdige, da dette ikke giver nogen mening.

10) Load it up with Resources and Costs – DCMA anbefaler at der tilknyttes ressourcer og økonomi til aktiviteterne.

11) Subvert Activity Slippage – Her kontrolleres hvor mange aktiviteter der er forsinket i forhold til baseline planen (denne kontrol burde beskrives under afsnittet ”Sammenligning af to tidsplaner”).

12) Critical Path Integrity – Dette check tester kvaliteten af den kritiske linje og dermed kvaliteten af sammenhængen mellem aktiviteterne.

13) Critical Path Length Index (CPLI) – Denne kontrol analyserer størrelsen af det aktuelle slæk for projektets aflevering i forhold til den resterende tid – faktoren bør være mindre end 0,95.

14) Baseline Execution Index (BEI) – Denne kontrol analyserer hvor mange aktiviteter der bliver færdige til tiden, i forhold til baseline. Det bør være mere end 95% af aktiviteterne, der er færdige til tiden (denne kontrol burde beskrives under afsnittet ”Sammenligning af to tidsplaner”).

Ovenstående liste giver et godt billede af muligheden for at lave automatiske kontroller. Det er dog vores opfattelse, at mange af de anførte grænser, giver et unuanceret billede af kvaliteten af tidsplanenerne. Men HUSK at der er mange af de vigtigste kontroller, der kun kan udføres, mere eller mindre manuelt, af de aktivitets ansvarlige. Så selv om alle ovenstående kontroller viser at tidsplanen er god, så kan man i praksis alligevel have en frygtelig dårlig tidsplan!

Sammenligning af to tidsplaner

Værktøjer til sammenligning af tidsplaner er rigtigt nyttige værktøjer; nedenstående skærmbillede fra Primavera Claimdigger (Schedule Comparison) illustrerer på udmærket vis mulighederne:

Ovenstående analyser kan også laves ved at lave forskellige views, filtre, dataudtræk til Excel osv., men flere af punkterne er besværlige og tidskrævende, f.eks. er analysen ”Added/Deleted Activities” faktisk ofte vanskelig at lave.

En sammenligning af to tidsplaner i f.eks. Claimdigger (Schedule Comparison) giver lynhurtigt svar på alle disse spørgsmål. Man får en detaljeret rapport der ofte er meget lang – der kan f.eks. være 200 aktiviteter, som har fået tilføjet en ny sorteringskode, hvilket genererer 200 linjer. Men kender man sit projekt, er det hurtigt at gennemgå rapporten og slette alle uvæsentlige punkter, så man har en koncentreret rapport over væsentlige ændringer.

Et konkret eksempel på nytten af denne type analyser, vedrørte en ombygning af et kraftværk. I forbindelse med udførelse af de nye fundamenter, fandt man nogle ukendte gamle fundamenter, der skulle fjernes og dermed forsinkede projektet. Entreprenøren skulle selvfølgelig have betalt for det ekstra arbejde, men stillede derudover krav om et større tocifret millionbeløb, for at indhente forsinkelsen (knock-on effekten som han kaldte det). Efterfølgende kunne man påvise, at der havde været flere ugers luft mellem aktiviteterne med at fjerne de gamle fundamenter og de efterfølgende aktiviteter, hvilket betød, at kravet blev tilbagevist.

OBS! For at man kan sammenligne to tidsplaner, er det en forudsætning, at der arbejdes med unikke numre på aktiviteter og strukturer. Dette betyder i praksis, at man ikke genbruger numre, ikke omdøber aktiviteter osv., hvilket kan være et problem, hvis man ikke på forhånd har stillet krav om dette i de kontrakter, der findes med leverandørerne. En leverandør kan altså bevidst sabotere opfølgningen ved at om-nummerere aktiviteter, ændre på indholdet, ændre strukturer m.m.