THE CRITICAL PATH METHOD OF THE PREVIOUS TOPIC MAKES AN ASSUMPTION IT NEVER STATES: THAT WHATEVER RESOURCES AN ACTIVITY NEEDS ARE AVAILABLE WHEN IT WANTS TO START. That is false in every real project. Scheduling every activity at its early start typically produces a resource profile with sharp peaks and deep troughs — demanding twenty carpenters in week 3 and four in week 7 — which is both unachievable and, if achieved, wasteful. THE RESOURCE HISTOGRAM makes the problem visible: plot, for each day, the total resource required by all activities in progress. WORKED, using the network from the scheduling topic with a labour requirement added to each activity: ACT ES EF DUR LABOUR TOTAL FLOAT ──────────────────────────────────────── A 0 4 4 6 0 B 0 6 6 4 1 C 4 7 3 8 0 D 4 9 5 5 5 E 7 14 7 6 0 F 14 18 4 7 0 G 18 20 2 3 0 ──────────────────────────────────────── AT EARLY START, the daily requirement is: days 1–4 : 10 (A 6 + B 4) days 5–6 : 17 (B 4 + C 8 + D 5) ← PEAK day 7 : 13 (C 8 + D 5) days 8–9 : 11 (D 5 + E 6) days 10–14: 6 (E) days 15–18: 7 (F) days 19–20: 3 (G) PEAK = 17, TOTAL = 173 person-days, AVERAGE = 173/20 = 8.65 THE PEAK IS NEARLY TWICE THE AVERAGE — the classic signature of an unlevelled schedule. Hiring for the peak means paying for idle capacity most of the time. ── THE TWO TECHNIQUES, AND THE DIFFERENCE BETWEEN THEM ───── RESOURCE SMOOTHING (also called TIME-CONSTRAINED scheduling) THE PROJECT DURATION IS FIXED AND MUST NOT CHANGE. Activities are shifted WITHIN THEIR FLOAT ONLY, to even out the profile. THE CRITICAL PATH IS UNTOUCHED, because critical activities have no float to move within. OUTCOME: a smoother histogram, SAME END DATE, and the peak reduced only as far as the available float permits. RESOURCE LEVELLING (also called RESOURCE-CONSTRAINED scheduling) A RESOURCE LIMIT IS FIXED AND MUST NOT BE EXCEEDED. Activities are delayed as far as necessary to respect the limit — INCLUDING BEYOND THEIR FLOAT, AND INCLUDING CRITICAL ACTIVITIES. OUTCOME: the limit is respected, and THE PROJECT DURATION USUALLY INCREASES. THE DISTINCTION IN ONE LINE, and this is the examinable point: SMOOTHING PROTECTS THE DATE AND ACCEPTS AN IMPERFECT RESOURCE PROFILE. LEVELLING PROTECTS THE RESOURCE LIMIT AND ACCEPTS A LATER DATE. They answer different questions, and which applies depends on which constraint is genuinely binding. If the deadline is contractual with liquidated damages, smooth. If there are only twelve carpenters in the district, level. ── SMOOTHING THE WORKED EXAMPLE ──────────────────────────── Activity D has 5 days of total float. Delaying it from ES = 4 to start at day 9 (its latest start) gives: days 1–4 : 10 (A 6 + B 4) days 5–6 : 12 (B 4 + C 8) ← new peak day 7 : 8 (C 8) days 8–9 : 6 (E 6) days 10–14: 11 (E 6 + D 5) days 15–18: 7 (F) days 19–20: 3 (G) PEAK FALLS FROM 17 TO 12 — a 29% reduction — WITH THE SAME 173 PERSON-DAYS OF WORK AND THE SAME 20-DAY DURATION. THAT IS THE WHOLE ARGUMENT FOR THE TECHNIQUE: THE PEAK DEMAND FELL BY NEARLY A THIRD AT NO COST IN TIME OR LABOUR — purely by starting one non-critical activity later than it strictly had to. NOTE ALSO WHAT DID NOT CHANGE: the total area under the histogram is fixed by the work itself. LEVELLING AND SMOOTHING REDISTRIBUTE DEMAND; THEY NEVER REDUCE IT.

THE LEVELLING PROCEDURE, as done by hand: 1. Build the network, compute floats, and draw the resource histogram at EARLY START. 2. Identify the periods exceeding the limit (or the peaks to be reduced). 3. Among activities in those periods, DELAY THE ONE WITH THE GREATEST TOTAL FLOAT FIRST — it costs least in schedule risk. 4. Recompute the histogram and repeat. 5. If the limit still cannot be met using float alone, delay critical activities and accept the extension. THE COMMON PRIORITY (HEURISTIC) RULES when several activities compete for a scarce resource: · LEAST TOTAL FLOAT FIRST — protects the end date · SHORTEST DURATION FIRST — clears the queue quickly · GREATEST RESOURCE DEMAND FIRST · EARLIEST LATE START FIRST — the most widely used THESE ARE HEURISTICS, NOT OPTIMISATION. Exact resource- constrained scheduling is NP-HARD, so software uses heuristics too, and DIFFERENT RULES GIVE DIFFERENT SCHEDULES — none of them provably best. An exam answer should say so, because it is the honest statement of the method's status. ── WHY A SMOOTH PROFILE IS WORTH MONEY ───────────────────── · HIRING AND FIRING COSTS: recruitment, induction, severance, and the learning curve repaid each time a new crew arrives. · RETENTION: skilled workers who are laid off go elsewhere, and the best of them do not come back. · PLANT AND EQUIPMENT: a peak fixes the fleet size, and equipment is paid for whether it works or not. · ACCOMMODATION, transport, canteen, supervision and site facilities are all sized for the peak. · SUPERVISION QUALITY falls when a crew doubles suddenly, and accident rates rise with unfamiliar labour. · LEARNING CURVE: a stable crew becomes faster at repeated work; a churning crew never does. ── RESOURCE AGGREGATION AND ALLOCATION, the related terms ── AGGREGATION — simply totalling the requirement over time, which is the histogram itself. ALLOCATION — assigning specific resources to specific activities. LEVELLING / SMOOTHING — adjusting timing, as above. ── THE RESOURCE-CONSTRAINED CRITICAL PATH ────────────────── A subtlety worth knowing, because it surprises people: ONCE RESOURCES ARE CONSTRAINED, THE LONGEST PATH IS NO LONGER NECESSARILY THE BINDING ONE. Two activities may be forced into sequence not by any logical dependency but because they need the same crane. That creates a RESOURCE DEPENDENCY, and the chain of activities linked by logic AND resources is the CRITICAL CHAIN — the concept behind Goldratt's critical chain project management. Under resource constraints, delaying a "non-critical" activity CAN delay the project, which the classical critical path would deny. ── MULTI-PROJECT RESOURCE MANAGEMENT ─────────────────────── In a firm running several projects from one pool of engineers and equipment, levelling happens ACROSS projects, and the conflicts are political as well as technical. THE COMMON FAILURE IS TAKING ON TOO MANY CONCURRENT PROJECTS: everything then runs slowly because everyone is multitasking, and multitasking across projects adds set-up time to every switch while delivering nothing sooner. THE COUNTERINTUITIVE REMEDY IS TO START FEWER PROJECTS AT ONCE — finishing them sequentially delivers the first ones earlier and the last no later.