Kun je me alsjeblieft vertellen hoe ik de slack-waarde in mijn netwerkdiagram kan gebruiken om het opnieuw aan te passen (als dit van toepassing is)? Met behulp van de volgende tabel heb ik de spelingwaarde berekend en een netwerkdiagram getekend. 
Slack-waarde vinden: 
A->B->E->F = 14 weeks is the critical path A->B->D->F = 10 weeks A->C->E->F = 12 weeks Ik wil de oorspronkelijke projectduur intact houden (daarom ben ik zal het aantal weken dat in het kritieke pad wordt gebruikt niet veranderen). Maar ik wil het aantal weken dat wordt gebruikt in niet-kritieke paden verminderen. Kan ik dat doen door de slack-waarden (of een andere methode) te gebruiken?
Reacties
- Heeft dit meer te maken met projectmanagement? of een vraag hoe je de software schrijft om een strakkere tijdlijn te ontdekken?
- @MichaelT Hallo, het ' is meer gerelateerd aan projectbeheer
- Oké, bedankt. wist niet ' waar ik de vraag moest stellen. mensen bij stackoverflow vertelden me om het hier te posten.
- Het is het beste om een vraag te markeren voor migratie naar een andere site in plaats van opnieuw te plaatsen. Op die manier worden de links van " die daar hoort " duidelijker tot stand gebracht in de stack exchange. Een vraag opnieuw posten betekent dat je op de ene plek een gesloten vraag hebt en op een andere plek een open vraag. De SO-mensen zijn vaak van mening dat alles wat niet ' niet op SO hoort, op P.SE thuishoort, wat niet ' t altijd correct is . Als je vragen hebt over waar iets thuishoort, wordt het vaak aangeraden om lid te worden van een chatroom (de chatroom van P.SE ' heet het whiteboard en vraag.
- Waarom wil je dit doen?
Antwoord
TL; DR
Uw float-waarden voor subkritische taken zijn niet echt slap voor de rest van het project. U kunt de float verhogen op sub- kritieke taken met standaard projectmanagementtechnieken zoals:
- Reikwijdte verkleinen voor de subkritische taakelementen.
- Meer middelen toewijzen aan elke taak of mijlpaal.
- Elimineren van niet-essentiële mijlpalen of werkelementen.
Hoewel het niet wordt aanbevolen, kunt u ook technieken toepassen vanuit het kritieke pad zoals fast-tracking of crashing the path van subkritische taken, maar dat maakt niet echt deel uit van de officiële methodologie. Het toepassen van deze technieken los van de kritiek l chain kan de crashduur van de subkritieke taken verminderen, maar zal in het algemeen middelen van het kritieke pad kannibaliseren om dit te doen.
Waar Slack voor is
Slack in een projectplanning bereikt over het algemeen verschillende hoofddoelen:
- De-optimaliseert subprocessen om de algemeen projectplan.
- Voorkomt dat de 100% -gebruiksmisfout uw proces broos maakt.
- Geeft u veel tijd, geld of teamcapaciteit om tegen te lenen, in plaats van een herberekening van uw plan bij elke hapering.
Uw kritieke pad heeft geen speling
Uw kritieke pad heeft geen speling. U definieert het kritieke pad als:
A-> B-> E-> F = 14 weken is het kritieke pad
Geen van de koppelingen tussen kritieke paden heeft enige speling. Of dit in het echte leven waar is of niet, ik heb geen idee. Uw diagram zegt echter expliciet Slack = 0 voor elk van de kritieke paditems. Bedenk dat:
(0 float) * (4 chained milestones) = no slack on critical path Aangezien u nul speling heeft in uw kritieke keten, zullen eventuele onvolkomenheden in het echte proces uw project. Dat betekent dat geen enkel item op uw kritieke pad enige ontsporing kan accepteren zonder u te dwingen uw volledige planning opnieuw te berekenen, en kan u ook dwingen om uw budget of verzenddatums opnieuw te evalueren. Dat lijkt slecht.
Je subkritieke pad voegt geen slapte toe
Vertragingen in taken of mijlpalen die niet op je kritieke pad liggen, mogen het algehele project niet vertragen. hebben niet gedefinieerd wat deze niet-kritieke taken vertegenwoordigen, maar aangezien ze zich niet op uw kritieke pad bevinden, vertegenwoordigen ze waarschijnlijk:
- Optionele functies.
- Extra bereik.
- Nice-to-haves.
- Oefeningen voor het opnieuw schenken van fruitcake, of iets anders dat even geen verband houdt met een product dat kan worden verzonden.
Ongeacht wat ze vertegenwoordigen, en zelfs als ze essentieel zijn voor het eindproduct, met een gebrek aan subkritieke taken kunt u de start- of einddatums van die taken alleen binnen toleranties aanpassen; ze kopen u niets gerelateerd aan uw kritische keten.
Een beter model voor Slack met kritiek pad
Volgens Wikipedias vermelding op de critical path-methode :
Hoewel het activiteit-op-pijl-diagram (“PERT-diagram”) nog steeds op een paar plaatsen wordt gebruikt, is het over het algemeen vervangen door de activiteits- diagram op het knooppunt, waarbij elke activiteit wordt weergegeven als een vak of knooppunt en de pijlen de logische relaties vertegenwoordigen die van voorganger naar opvolger gaan, zoals hier wordt weergegeven in het “Activiteit-op-knooppuntdiagram”.
Het voordeel van dit model ten opzichte van het model in uw vraag is dat u hiermee variantie kunt modelleren op het kritieke pad, iets dat uw steekproef momenteel niet biedt. Het kan daarom de moeite waard zijn om opnieuw te evalueren wat u probeert te modelleren en of Activity-on-node een betere planningstool zal bieden voor uw specifieke gebruikssituatie .
Antwoord
Maar ik wil het aantal weken dat wordt gebruikt in niet-kritieke paden verminderen.
Ik lees dit omdat je wilt dat de totale duur van je niet-kritieke padnetwerk afneemt, waardoor de speling op die paden toeneemt. Om dit te doen, hoeft u alleen de doelduur van die pakketten die buiten het kritieke pad zijn, te verkorten.
Ik weet echter niet zeker wat de waarde is om dit te doen. De aanvankelijke veronderstelling is dat u, binnen de probabilistische verdeling van de duur van elk van uw pakketten, streeft naar een duur die ergens rond de MODUS van die verdeling ligt, een doel dat een realistische mogelijkheid vertegenwoordigt, maar ook mager genoeg om geen overbuffering te vormen. Wanneer u die duur verkort, verhoogt u het risico en, om dit te beperken, verhoogt u het gebruik van middelen en / of het aantal werkuren om de agressievere streefduur te halen. Duur = Werk / Resourcegebruik.
Dit vormt dan een bedreiging voor de werkactiviteit op die pakketten op het kritieke pad, wat direct een bedreiging vormt voor uw algehele duur.
Aan de andere kant vergroot je natuurlijk je speling, zodat je een aantal cycli hebt om met ongunstige schema-afwijkingen om te gaan. Op papier ziet dit er echter allemaal super uit, maar uw realiteit zal heel anders zijn.
Uw andere risico is dat uw kritieke pad bij planning alleen geldig is bij planning. Op het moment dat u op go drukt en aan het werk gaat en uw pakketten volgens het schema verder gaat, ZULLEN uw kritieke pad (en) veranderen en veranderen en veranderen en veranderen. Die pakketten waarvan u de duur willekeurig hebt verkort, kunnen en zullen waarschijnlijk in de nieuwe kritieke pad (en) vallen, en aangezien u de duur heeft verkort en uw dreiging heeft vergroot, heeft u nu een grotere bedreiging voor uw algehele planningsduur gecreëerd.
Al met al kan ik de logica niet zien in wat u probeert te doen vanuit een planning- / planningsperspectief. Dat betekent niet dat er geen logica is, ik kan het gewoon niet zien en ik heb nog nooit iemand hierover horen praten.