14 kvalitetskontroller for IT-prosjektplanen din

IT-prosjektledelseskonsulenter og Project Management Office (PMO) -ledere ser prosjektplaner som varierer i kvalitet. En PMP-sertifisert prosjektleder (PM) kan ha 10 års erfaring med å lede prosjekter, men det er ikke en indikator på PMs mulighet til å lage en god timeplan.

Evaluering av en prosjektplan kan være subjektiv med mindre det er et sett med objektive kriterier å følge. Godt strukturerte PMO-organisasjoner kan ha retningslinjer for kvalitet i prosjektplanene, men med mindre det foreligger en tidsplangjennomgang, kan planen fortsatt ha betydelige mangler som påvirker realistisk prosjektlevering. (Husk: Prosjektplanen er en prognostisert modell av fremtidige hendelser, så du vil at modellen skal gjenspeile virkeligheten så mye som mulig.)

Defense Contract Management Agency (DCMA) gir en 14-punktsvurdering som kan brukes for å evaluere prosjektplanens kvalitet. DCMS er en Department of Defense (DoD) avdeling som samarbeider med leverandører for å administrere tid, kostnader og ytelse for den amerikanske føderale regjeringen.

Forhåndsvurderingsberegninger

Du må beregne disse beregningene før du bruker kvalitetskontrollene.

  1. Totaloppgaver er en telling av oppgavene på det laveste nivået, eksklusivt sammendrag, delprosjekt, null grunnlinjevarighet og milepæloppgaver.
  2. Fullfør oppgaver er et antall totalt oppgaver med en faktisk sluttdato.
  3. Ufullstendige oppgaver er et antall totalt oppgaver uten en faktisk sluttdato.
  4. Baseline Count er en telling av alle de totale oppgavene som skal ha fullført på eller før prosjektstatusdatoen.
  5. BEI Baseline Count er en telling av alle de totale oppgavene som skal ha fullført på eller før prosjektstatusdatoen og alle oppgavene som mangler en start- og sluttdato for baseline.
  6. Forholdstelling er en telling av alle avhengighetene til Finish-Start (FS), Start-to-Start (SS), Start-Finish (SF) og Finish-to-Finish (FF) i timeplanen.

De 14 kvalitetskontrollene

  1. Logic Check evaluerer om noen oppgaver mangler en etterfølger eller en forgjenger i timeplanen. Logisk sett skal alle aktiviteter ha minst en forgjenger- eller etterfølgeroppgaver, ellers risikerer du å lage en foreldreløs oppgave. En kvalitetsplan skal ikke ha mer enn 5% av oppgavene mangler logikk. Formelen for logisk sjekk er (antall oppgaver mangler logikk) / (antall ufullstendige oppgaver) * 100.
  2. Leads Check ser etter negative forsinkelser (dvs. kundeemner) i timeplanen. En kvalitetsplan skal ha null ledninger, da de kan påvirke prosjektets kritiske vei.
  3. Lags Check sikrer at bruken av etterslep minimeres i prosjektplanen, ettersom etterslep kan påvirke den kritiske banen. En kvalitetsplan vil ha mindre enn 5% av oppgavene med etterslep. Formelen for etterslep er (antall oppgaver med forsinkelse) / (ufullstendige oppgaver).
  4. Forholdstyper Sjekk validerer 90% av oppgavene har Fullfør for å starte relasjoner. Bruk av Finish to Start-relasjoner gir en logisk flyt til timeplanen.
  5. Kontroll av harde begrensninger er enhver aktivitet som må fullføres på, må starte på, starte ikke senere enn, eller fullføre ikke senere enn begrensning. Du ser ofte disse begrensningene i "pick-a-date" prosjektledelse. Du ønsker ideelt at planen din skal være en dynamisk plan som flyter lett når prosjektet blir oppdatert. Kontrollen med harde begrensninger identifiserer enhver ufullstendig oppgave som har en hard begrensning. Et kvalitetsskjema vil ikke ha mer enn 5% av oppgavene med harde begrensninger.
  6. High Float Check identifiserer alle oppgaver med en total flottør på mer enn 44 arbeidsdager. En oppgave med så høyt flyter indikerer vanligvis at en forgjenger eller en etterfølger manglet. Formelen er (# av High Float-oppgaver) / (# of Involplete Tasks). Prosentandelen skal ikke overstige 5%.
  7. Negativ Float Check identifiserer alle oppgaver som har en flottør som er mindre enn null. Denne sjekken hjelper deg med å identifisere eventuelle oppgaver som kan hindre fullføringen av andre oppgaver i timeplanen. Det skal være null oppgaver med negativ flyt.
  8. Kontroll av høy varighet identifiserer alle oppgaver som har en grunnleggende varighet over 44 dager. Som kompetente representanter, vet vi at slike oppgaver bør deles inn i mer diskrete oppgaver. Formelen er (# oppgaver med høy varighet) / (# ufullstendige oppgaver) og bør ikke overstige 5%.
  9. Ugyldige datoersjekk identifiserer den totale oppgaven som har en planlagt start- eller sluttdato før prosjektstatusdatoen og en faktisk start- eller sluttdato etter prosjektstatusdatoen. Prognoserte start- og sluttdatoer skal alltid vises etter prosjektstatusdatoen. Planen kan heller ikke inneholde en faktisk start- eller sluttdato i fremtiden. Det skal være null oppgaver som faller inn i denne kategorien i en kvalitetsplan.
  10. Ressurssjekk identifiserer alle oppgavene som ikke er tildelt ressurser (personer eller kostnader). En kvalitetsplan har alle ressurser tildelt oppgaver i timeplanen.
  11. Missed Tasks Check brukes til å identifisere alle oppgavene som var planlagt fullført etter prosjektstatusdatoen og ble avsluttet etter grunnlagets sluttdato. Realiteten er at prosjekter vil ha sene oppgaver, men du vil forsikre deg om at den nåværende timeplanen samsvarer med grunnplanen. Formelen er (antall oppgaver med prognostisert finish før statusdato og faktisk eller prognostisert finish etter baseline-plandato) / (grunntelling).
  12. Test for kritisk sti test vurderer integriteten til plannettverket ved å bruke den kritiske banen. En forsettlig forsinkelse på 600 dager legges inn i den gjenværende varigheten av en kritisk banetest. Det forventede resultatet er at prosjektet er forsinket med 600 dager siden du la til en forsinkelse direkte på den kritiske banen. Planen består testen hvis prosjektets sluttdato stemmer overens med den endte dato for lagt til varighet.
  13. Critical Path Length Index (CPLI) bestemmer om prosjektets sluttdato er realistisk gitt den forventede sluttdatoen. Den kritiske banelengdeindeksen beregnes ved å bruke formelen (Critical Path Length + Total Float) / (Critical Path Length). Verdien bør være større enn 1, 0 for å bestå testen.
  14. Baseline Execution Index (BEI) ligner på Earned Value's Schedule Performance Index, fordi den sammenligner antall gjennomførte aktiviteter til dags dato med antall oppgaver som er planlagt fullført innen prosjektstatusdatoen. BEI beregnes # for fullstendige oppgaver / BEI-grunntelling og bør være større enn 1, 0.

Sammendrag

Du kan bruke disse kvalitetskontrollene som et rammeverk for å evaluere og gjennomgå prosjektplaner. Kriteriene kan også hjelpe deg med å evaluere hvor godt en leverandør kan bygge og utføre en meningsfull plan.

Som prosjektleder har jeg sett min del av dårlige timeplaner, og jeg er sikker på at jeg har bygget en dårlig timeplan nå og da. DCMA-kriteriene fungerer som en nyttig måleplan for kvalitet som eliminerer subjektive evalueringer.

I min neste artikkel skal jeg vise hvordan du kan automatisere noen av disse kvalitetskontrollene i Microsoft Project-planen din.

© Copyright 2021 | pepebotifarra.com