Kan du venligst fortælle mig, hvordan kan jeg bruge slapværdien i mit netværksdiagram til at justere det (hvis det er relevant)? Ved hjælp af følgende tabel har jeg beregnet den slakke værdi og tegnet et netværksdiagram. 
Find slak værdi: 
A->B->E->F = 14 weeks is the critical path A->B->D->F = 10 weeks A->C->E->F = 12 weeks Jeg vil have den oprindelige projekts varighed intakt (derfor er jeg vil ikke ændre antallet af uger, der er brugt i den kritiske vej). Men jeg vil reducere antallet af uger, der bruges på ikke-kritiske veje. Kan jeg gøre det ved at bruge slakke værdier (eller en anden metode)?
Kommentarer
- Er dette mere relateret til projektstyring? eller et spørgsmål om, hvordan man skriver softwaren for at finde en strammere tidslinje?
- @MichaelT Hej, det ' er mere relateret til projektledelse
- Ok, tak. vidste ' ikke, hvor han skulle stille spørgsmålet. folk ved stackoverflow fortalte mig at sende det her.
- Det er bedst at markere et spørgsmål til migration til et andet sted i stedet for at genindlægge det. På den måde er linkene til " dette hører hjemme der " tydeligere etableret i stack-udvekslingen. Genudsendelse af et spørgsmål betyder, at du har et lukket spørgsmål et sted og et åbent på et andet. SO-folk er ofte af den opfattelse, at alt, hvad der ikke hører til ' t, hører til P.SE, hvilket ikke er ' t altid korrekt . Hvis du har spørgsmål om, hvor noget hører hjemme, tilrådes det ofte at deltage i et chatrum (P.SE ' s chatrum kaldes det hvide tavle og spørg.
- Hvorfor vil du gøre dette?
Svar
TL; DR
Dine floatværdier til underkritiske opgaver er faktisk ikke slap for resten af projektet. Du kan øge float på sub- kritiske opgaver med standard projektstyringsteknikker som:
- Reducering af omfanget af de underkritiske opgaveelementer.
- Forøgelse af ressourcer tildelt hver opgave eller milepæl.
- Fjernelse af ikke-essentielle milepæle eller arbejdselementer.
Selvom det ikke anbefales, kan du også anvende teknikker fra den kritiske vej såsom “hurtigsporing” eller “nedbrud af stien” til underkritiske opgaver, men det er ikke rigtig en del af den officielle metode. Anvendelse af disse teknikker væk fra kritikken Kæden reducerer muligvis nedbrudsvarighed for de underkritiske opgaver, men vil normalt cannibalisere ressourcer fra den kritiske vej til at gøre det.
Hvad Slack er til
Slack i en projektplan opnår generelt flere hovedmål:
- De-optimerer delprocesser for at udjævne overordnet projektplan.
- Forhindrer 100% -udnyttelsesfejl i at gøre din proces sprød.
- Giver dig spande med tid, penge eller holdkapacitet til at låne imod snarere end at tvinge en genberegning af din plan ved hvert problem.
Din kritiske sti har ingen slap
Din kritiske sti har nul slaphed. Du definerer den kritiske sti som:
A-> B-> E-> F = 14 uger er den kritiske sti
Ingen af forbindelserne mellem kritisk sti har noget slap. Hvorvidt dette er sandt i det virkelige liv, aner jeg ikke. Imidlertid siger dit diagram eksplicit Slack = 0 for hver af de kritiske styposter. Overvej at:
(0 float) * (4 chained milestones) = no slack on critical path Da du har nul slaphed i din kritiske kæde, vil enhver ufuldkommenhed i den virkelige proces skabe træk på din projekt. Det betyder, at ingen varer på din kritiske sti overhovedet kan acceptere nogen glidning uden at tvinge dig til at genberegne hele din tidsplan, og kan også tvinge dig til at revurdere dit budget eller leveringsdatoer. Det virker dårligt.
Din underkritiske sti tilføjer ikke slap
Forsinkelser i opgaver eller milepæle, der ikke er på din kritiske sti, bør ikke forsinke det samlede projekt. Du har ikke defineret, hvad disse ikke-kritiske opgaver repræsenterer, men da de ikke er på din kritiske vej, repræsenterer de sandsynligvis:
- Valgfrie funktioner.
- Yderligere anvendelsesområde.
- Dejligt at have.
- Frugtkage-givningsøvelser eller noget andet, der ikke er relateret til et produkt, der kan sendes.
Uanset hvad de repræsenterer, og selvom de er væsentlige for det endelige produkt, giver slæk i underkritiske opgaver kun mulighed for at justere start- eller slutdatoer for disse opgaver inden for tolerancer; de køber ikke dig noget relateret til din kritiske kæde.
En bedre model til slap med kritisk sti
Ifølge Wikipedias post på kritisk sti-metode :
Selvom aktivitets-på-pil-diagrammet (“PERT-diagram”) stadig bruges nogle få steder, er det generelt blevet erstattet af aktivitets- on-node diagram, hvor hver aktivitet vises som en boks eller node, og pilene repræsenterer de logiske relationer, der går fra forgænger til efterfølger som vist her i “Activity-on-node diagram”.
Fordelen ved denne model i forhold til den i dit spørgsmål er, at den giver dig mulighed for at modellere varians på den kritiske vej, hvilket er din prøve i øjeblikket ikke giver. Det kan derfor være værd at revurdere, hvad du prøver at modellere, og om aktivitet-på-node vil give et bedre planlægningsværktøj til din specifikke brugssag .
Svar
Men jeg vil reducere antallet af uger, der bruges i ikke-kritiske stier.
Jeg læser dette, da du vil have den samlede varighed af dit ikke-kritiske stienetværk til at falde, hvilket øger slapheden på disse stier. For at gøre dette er alt hvad du skal gøre, at reducere målvarigheden for de pakker, der er uden for den kritiske vej.
Jeg er dog ikke sikker på, hvad værdien er ved at gøre dette. Den oprindelige antagelse er, at inden for den sandsynlige fordeling af varigheden af hver af dine pakker målretter du mod en varighed, der er et eller andet sted omkring MODE for denne distribution, et mål, der repræsenterer en realistisk mulighed, men også magert nok til ikke at udgøre for buffering. Når du reducerer denne varighed, øger du risikoen, og for at afbøde, ender du med at øge ressourceudnyttelsen og / arbejdstiden for at opfylde den mere aggressive målvarighed. Varighed = Arbejde / ressourceudnyttelse.
Dette truer derefter arbejdsaktivitet på disse pakker på den kritiske sti, hvilket direkte vil true din samlede varighed.
Selvfølgelig øger du din slaphed på den anden side, så du har nogle cyklusser derinde for at klare ugunstige tidsplanafvigelser. Alt dette ser dog super ud på papiret, men din virkelighed vil være meget anderledes.
Din anden risiko er, at din kritiske vej til planlægning kun er gyldig ved planlægning. I det øjeblik du trykker på gå og begynder arbejdet og begynder at udvikle dine pakker i tidsplanen, vil din (de) kritiske sti (r) ændre og ændre og ændre og ændre. De pakker, som du vilkårligt reducerede varigheden, kan og vil sandsynligvis falde i de nye kritiske stier, og da du reducerede varigheden og øgede din trussel, har du nu skabt en større trussel mod din samlede tidsplanvarighed.
Alt i alt kan jeg ikke se logikken i, hvad du forsøger at gøre fra et planlægnings- / planlægningsperspektiv. Det betyder ikke, at der ikke er nogen logik, jeg kan bare ikke se den, og jeg har aldrig hørt nogen diskutere dette før.