Kan du snälla berätta för mig hur kan jag använda slackvärdet i mitt nätverksdiagram för att justera om det (om det är tillämpligt)? Med hjälp av följande tabell har jag beräknat slackvärdet och ritat ett nätverksdiagram. 
Hitta slackvärde: 
A->B->E->F = 14 weeks is the critical path A->B->D->F = 10 weeks A->C->E->F = 12 weeks Jag vill behålla den ursprungliga projekttiden intakt (därför är jag kommer inte att ändra antalet veckor som används i den kritiska vägen). Men jag vill minska antalet veckor som används i icke-kritiska vägar. Kan jag göra det genom att använda slackvärdena (eller en annan metod)?
Kommentarer
- Är detta mer relaterat till projektledning? eller en fråga om hur man skriver programvaran för att upptäcka en kortare tidslinje?
- @MichaelT Hej, det ' är mer relaterat till projektledning
- Okej, tack. visste ' inte var du skulle ställa frågan. personer på stackoverflow sa att jag skulle lägga upp det här.
- Det är bäst att flagga en fråga för migrering till en annan webbplats istället för att lägga om. På så sätt är länkarna till " detta hör hemma " tydligare etablerade i stackbytet. Att lägga om en fråga innebär att du har en stängd fråga på en plats och en öppen på en annan. SO-folket är ofta av den uppfattningen att allt som inte ' t hör hemma på SO tillhör P.SE vilket inte är ' t alltid korrekt . Om du har frågor om var något hör hemma rekommenderas det ofta att gå med i ett chattrum (P.SE ' s chattrum heter tavlan och fråga.
- Varför vill du göra det?
Svara
TL; DR
Dina flottörvärden för underkritiska uppgifter är faktiskt inte slacka för resten av projektet. Du kan öka flyta på under- kritiska uppgifter med standardprojektledningstekniker som:
- Minska omfattningen för de underkritiska uppgiftselementen.
- Öka resurserna som tilldelas varje uppgift eller milstolpe.
- Eliminera icke-väsentliga milstolpar eller arbetselement.
Även om det inte rekommenderas kan du också använda -tekniker från den kritiska vägen som ”snabbspårning” eller ”kraschande väg” för underkritiska uppgifter, men det är inte riktigt en del av den officiella metoden. Tillämpa dessa tekniker bort från kritik Kedjan kan minska kraschvaraktigheten för de underkritiska uppgifterna, men kan i allmänhet cannibalisera resurser från den kritiska vägen för att göra det.
Vad Slack är för
Slack i ett projektschema uppnår i allmänhet flera huvudmål:
- De-optimerar delprocesser för att jämna ut övergripande projektplan.
- Förhindrar att 100% utnyttjandefel gör din process spröd.
- Ger dig pengar, tid eller teamkapacitet att låna mot snarare än att tvinga en omberäkning av din plan vid varje hicka.
Din kritiska väg har ingen slack
Din kritiska väg har ingen slack. Du definierar den kritiska sökvägen som:
A-> B-> E-> F = 14 veckor är den kritiska vägen
Ingen av länkarna mellan kritisk väg har något slack. Huruvida detta är sant i verkliga livet har jag ingen aning om. Ditt diagram säger dock uttryckligen Slack = 0 för var och en av de kritiska sökobjekten. Tänk på att:
(0 float) * (4 chained milestones) = no slack on critical path Eftersom du har noll slack i din kritiska kedja, kommer alla brister i verkliga processer att dra projekt. Det betyder att inga artiklar på din kritiska väg kan acceptera någon glidning alls utan att tvinga dig att räkna om hela schemat, och kan tvinga dig att omvärdera din budget eller leveransdatum också. Det verkar dåligt.
Din subkritiska sökväg lägger inte till slack
Fördröjningar i uppgifter eller milstolpar som inte är på din kritiska väg bör inte försena det totala projektet. Du har inte definierat vad dessa icke-kritiska uppgifter representerar, men eftersom de inte är på din kritiska väg representerar de förmodligen:
- Valfria funktioner.
- Ytterligare räckvidd.
- Trevligt att ha.
- Övningar med fruktkakor, eller något annat som inte är relaterat till en leveransbar produkt.
Oavsett vad de representerar, och även om de är väsentliga för slutprodukten, kan slack i underkritiska uppgifter bara göra att du kan justera start- eller slutdatum för dessa uppgifter inom toleranser, de köper dig inte någonting relaterad till din kritiska kedja.
En bättre modell för slack med kritisk väg
Enligt Wikipedia: s post på kritisk sökmetod :
Även om aktivitets-på-pil-diagrammet (”PERT-diagram”) fortfarande används på några få ställen har det i allmänhet ersatts av aktivitets- on-node-diagram, där varje aktivitet visas som en ruta eller nod och pilarna representerar de logiska förhållandena som går från föregångare till efterträdare som visas här i ”Activity-on-node diagram”.
Fördelen med den här modellen jämfört med den i din fråga är att den låter dig modellera varians på den kritiska vägen, vilket är något som ditt urval för närvarande inte ger. Det kan därför vara värt att omvärdera vad du försöker modellera och om aktivitet-på-nod kommer att ge ett bättre planeringsverktyg för ditt specifika användningsfall .
Svar
Men jag vill minska antalet veckor som används i icke-kritiska vägar.
Jag läser detta eftersom du vill att den totala varaktigheten för ditt icke-kritiska bannätverk ska minska och därmed öka slaken på dessa vägar. För att göra detta är allt du behöver göra att minska målvaraktigheten för de paket som är utanför den kritiska vägen.
Jag är dock inte säker på vilket värde det är att göra detta. Det ursprungliga antagandet är att du inom den probabilistiska fördelningen av varaktigheten för vart och ett av dina paket inriktar dig på en varaktighet som är någonstans runt LÄGE för den distributionen, ett mål som representerar en realistisk möjlighet men också tillräckligt lutad för att inte utgöra över buffring. När du minskar den varaktigheten ökar du risken och, för att mildra, slutar du öka resursutnyttjandet och / arbetstiden för att möta den mer aggressiva mållängden. Varaktighet = Arbets- / resursutnyttjande.
Detta hotar sedan arbetsaktiviteten på dessa paket på den kritiska vägen, vilket direkt hotar din totala varaktighet.
Naturligtvis ökar du din slack på den andra sidan så att du har några cykler där inne för att klara ogynnsamma schemanvariationer. Men allt detta ser supert ut på papper, men din verklighet kommer att vara väldigt annorlunda.
Din andra risk är att din kritiska väg till planering endast gäller vid planering. I det ögonblick du trycker på starta och börja arbeta och börja utveckla dina paket i schemat, kommer dina kritiska vägar att förändras och förändras och förändras och förändras. De paket som du godtyckligt minskade varaktigheten kan och kommer sannolikt att falla i den / de nya kritiska banorna och eftersom du har minskat varaktigheten och ökat ditt hot har du nu skapat ett större hot mot din totala schemaläggningstid.
Sammantaget kan jag inte se logiken i vad du försöker göra ur ett planerings- / planeringsperspektiv. Det betyder inte att det inte finns någon logik, jag kan bara inte se den och jag har aldrig hört någon diskutera detta tidigare.