Kan du fortelle meg hvordan kan jeg bruke slakkverdien i nettverksdiagrammet mitt for å justere det på nytt (hvis det er aktuelt)? Ved hjelp av følgende tabell har jeg beregnet den slakke verdien og tegnet et nettverksdiagram. 
Finne slak verdi: 
A->B->E->F = 14 weeks is the critical path A->B->D->F = 10 weeks A->C->E->F = 12 weeks Jeg vil beholde den opprinnelige prosjektvarigheten intakt (derfor er jeg kommer ikke til å endre antall uker som brukes i den kritiske banen). Men jeg vil redusere antall uker som brukes i ikke-kritiske baner. Kan jeg gjøre det ved å bruke slakke verdier (eller en annen metode)?
Kommentarer
- Er dette mer relatert til prosjektledelse? eller et spørsmål om hvordan man skriver programvaren for å oppdage en strammere tidslinje?
- @MichaelT Hei, den ' er mer relatert til prosjektledelse
- Ok, takk. visste ikke ' hvor jeg skulle stille spørsmålet. folk på stackoverflow ba meg om å legge det ut her.
- Det er best å merke et spørsmål for migrering til et annet nettsted i stedet for å legge ut på nytt. På den måten er koblingene til " dette hører hjemme der " tydeligere etablert i stabelen. Å legge ut et spørsmål betyr at du har et lukket spørsmål på ett sted og et åpent på et annet. SO-folket er ofte av den oppfatning at alt som ikke hører til ' t på SO hører til på P.SE som ikke er ' t alltid riktig . Hvis du har spørsmål om hvor noe hører hjemme, anbefales det ofte å delta i et chatterom (P.SE ' chatterom kalles tavlen og spør.
- Hvorfor vil du gjøre dette?
Svar
TL; DR
Flyteverdiene dine for underkritiske oppgaver er faktisk ikke slappe for resten av prosjektet. Du kan øke flyte på under- kritiske oppgaver med standard prosjektledelsesteknikker som:
- Redusere omfanget for de underkritiske oppgaveelementene.
- Øke ressursene som er tildelt hver oppgave eller milepæl.
- Eliminering av ikke-essensielle milepæler eller arbeidselementer.
Selv om det ikke anbefales, kan du også bruke teknikker fra den kritiske banen som «hurtigsporing» eller «krasjer banen» for underkritiske oppgaver, men det er egentlig ikke en del av den offisielle metoden. Bruk av disse teknikkene borte fra kritikken Kjeden kan redusere krasjvarighet for de underkritiske oppgavene, men vil vanligvis kannibalisere ressurser fra den kritiske veien for å gjøre det.
Hva Slack er for
Slakk i en prosjektplan oppnår vanligvis flere hovedmål:
- De-optimaliserer delprosesser for å jevne ut overordnet prosjektplan.
- Forhindrer at 100% -utnyttelsesfeil gjør prosessen din sprø.
- Gir deg bøtter med tid, penger eller teamkapasitet til å låne mot, i stedet for å tvinge en omberegning av planen din ved hvert problem.
Din kritiske vei har ingen slakk
Den kritiske banen din har ingen slakk. Du definerer den kritiske banen som:
A-> B-> E-> F = 14 uker er den kritiske banen
Ingen av koblingene mellom kritisk sti har noe slakk. Om dette er sant i det virkelige liv, aner jeg ikke. Imidlertid sier diagrammet eksplisitt Slack = 0 for hver av de kritiske banepostene. Tenk på at:
(0 float) * (4 chained milestones) = no slack on critical path Siden du har null slakk i din kritiske kjede, vil eventuelle ufullkommenheter i den virkelige prosessen skape drag på prosjekt. Det betyr at ingen varer på den kritiske banen din kan godta noen glid i det hele tatt uten å tvinge deg til å beregne hele tidsplanen din, og kan tvinge deg til å evaluere budsjettet eller leveringsdatoene dine også. Det virker dårlig.
Din underkritiske bane legger ikke til slakk
Forsinkelser i oppgaver eller milepæler som ikke er på din kritiske vei, burde ikke forsinke det samlede prosjektet. Du har ikke definert hva disse ikke-kritiske oppgavene representerer, men siden de ikke er på din kritiske vei, representerer de sannsynligvis:
- Valgfrie funksjoner.
- Ekstra omfang.
- Hyggelig å ha.
- Fruktkake-gavegaver, eller noe annet som ikke er relatert til et produkt som kan sendes.
Uansett hva de representerer, og selv om de er essensielle for det endelige produktet, gir slakk i underkritiske oppgaver deg bare muligheten til å justere start- eller sluttdatoen for disse oppgavene innenfor toleranser. De kjøper ikke deg noe relatert til din kritiske kjede.
En bedre modell for slakk med kritisk vei
I følge Wikipedia sin oppføring på kritisk sti-metode :
Selv om aktivitets-på-pil-diagrammet («PERT-diagram») fortsatt brukes noen få steder, har det generelt blitt erstattet av aktivitets- on-node diagram, der hver aktivitet vises som en rute eller node og pilene representerer de logiske forholdene som går fra forgjengeren til etterfølgeren som vist her i «Activity-on-node diagram».
Fordelen med denne modellen i forhold til den i spørsmålet ditt er at den lar deg modellere varians på den kritiske banen, noe som utvalget ditt foreløpig ikke gir. Det kan derfor være verdt å revurdere hva du prøver å modellere, og om aktivitet-på-node vil gi et bedre planleggingsverktøy for din spesifikke brukssak .
Svar
Men jeg vil redusere antall uker som brukes i ikke-kritiske baner.
Jeg leser dette ettersom du vil at den totale varigheten av ditt ikke-kritiske banenettverk skal reduseres, og dermed øke slakken på disse banene. For å gjøre dette er alt du trenger å redusere målvarigheten til de pakkene som er utenfor den kritiske banen.
Jeg er imidlertid ikke sikker på hvilken verdi det er å gjøre dette. Den innledende antagelsen er at innen den sannsynlige fordelingen av varigheten til hver av pakkene dine, målretter du mot en varighet som er et sted rundt MODUSEN for den fordelingen, et mål som representerer en realistisk mulighet, men også mager nok til ikke å utgjøre for buffering. Når du reduserer varigheten, øker du risikoen, og for å redusere, ender du med å øke ressursutnyttelsen og / / arbeidstiden for å oppfylle den mer aggressive målvarigheten. Varighet = Arbeid / ressursutnyttelse.
Dette truer deretter arbeidsaktiviteten på disse pakkene på den kritiske banen, noe som direkte vil true din totale varighet.
Selvfølgelig øker du slakken på den andre siden av det, slik at du har noen sykluser der inne for å takle ugunstige tidsplanavvik. Imidlertid ser alt dette supert ut på papir, men virkeligheten din vil være veldig annerledes.
Din andre risiko er at din kritiske vei til planlegging bare gjelder ved planlegging. I det øyeblikket du trykker på start og begynner arbeidet og begynner å utvikle pakkene dine i timeplanen, VIL din kritiske bane (r) endre og endre og endre og endre. Disse pakkene som du vilkårlig reduserte varigheten, kan og vil sannsynligvis falle i den / de nye kritiske banene, og siden du reduserte varigheten og økte trusselen din, har du nå opprettet en større trussel mot den totale varigheten din.
Alt i alt kan jeg ikke se logikken i det du prøver å gjøre fra et planleggings- / planleggingsperspektiv. Det betyr ikke at det ikke er logikk, jeg kan bare ikke se den og jeg har aldri hørt noen diskutere dette før.