planning-scheduling-applied-s01-q01
The A-then-B chain takes 5 days and C takes 4 in parallel, so the project is 5 days long. The 9-day answer adds the chains together, which is what happens if you forget that C runs alongside rather than after.
This is untimed educational practice for one applied skill. It is not a clinical, diagnostic, employment, or professionally recognized assessment, it does not produce a score or credential, and for the judgement and safety families it is not a substitute for your employer's own policies, training, or legal duties.
The A-then-B chain takes 5 days and C takes 4 in parallel, so the project is 5 days long. The 9-day answer adds the chains together, which is what happens if you forget that C runs alongside rather than after.
Finish-to-start is the ordinary dependency type and the one most schedules are built from. A lag is different: it is a mandatory wait inserted between two linked tasks, such as concrete curing, and it modifies a dependency rather than being one.
The constraint is real and will lengthen the plan, but it comes from the rig rather than from the work, which matters because buying rig time removes it while a logical dependency cannot be bought away. Calling it a dependency is the tempting simplification and hides the cheapest available fix.
Overlapping buys calendar time by accepting that some of the second task may be built on assumptions the first task later changes. Extra people is the plausible cost to name, but that describes adding resource to compress a task, which is a different technique with a different price.
Milestones have zero duration and exist to make progress checkable at a specific moment. Calling it an externally imposed deadline is the everyday usage, but plenty of milestones are internal, and a milestone with no work behind it is a date rather than an achievement.
Effort divided by headcount assumes perfect divisibility and zero communication overhead, and neither holds for real work. '2 days plus a small margin' is the sophisticated-looking version of the same error: it acknowledges friction while still treating the task as almost perfectly parallel.
Three full-time assignments in one week is three hundred per cent allocation, and a plan that requires it will miss dates no matter how the person behaves. 'If they prioritise well' is the reasonable-sounding rescue and simply moves the decision about which task slips from the planner to the individual, without telling anyone which one it will be.
Approved leave is a fixed constraint like any other, so the plan moves around it and the commitment moves with the plan. Shortening the task to make it fit is the tempting compromise and changes nothing real: the work still takes as long as it takes, and the shortfall now appears somewhere less visible.
With scope and quality held, time can only be bought with resource, and if no resource is available the honest output is that the date is unachievable. Extending hours is the option that appears to create capacity from nothing, and sustained overtime reliably repays the borrowed time with defects and turnover.
A central, visible contingency can be pointed at whichever risk actually materialises, and its balance tells you how exposed the project still is. Padding every estimate is the intuitive alternative, protection where the work is, and it is the version that always gets spent: hidden buffer is invisible, so nobody defends it and every task expands to fill it.
It is defined by duration and dependency, and everything on it has zero float by construction. The riskiest-activities answer is the most seductive because those tasks do deserve attention, but a risky task with a fortnight of float can slip a week without moving the end date, and a dull one on the critical path cannot slip a day.
Float absorbs the slip, so the date holds, but the protection is now nearly gone, which is a change worth acting on. 'Nothing changes' is the tempting reading of the same fact and treats float as a permanent property rather than a consumable one.
The critical path is a property of the current network, not a fixed list, so it moves whenever a chain runs out of slack. 'Only critical tasks affect the end date' is true at the moment it is said and stops being true the instant a non-critical chain overruns its float.
A pooled buffer at the end is available to whichever task actually overruns, and statistically it can be smaller than the sum of the individual pads it replaces. Padding each task is the intuitive local protection and wastes most of it: a task that finishes early rarely hands its spare days on, so the buffer is consumed whether or not it was needed.
Attention follows exposure: a day lost on the zero-float chain moves the milestone, and a day lost on the other one does not, until six have gone. Treating both equally is the even-handed-sounding policy and spends scarce management attention where it currently cannot change the outcome.
Gains on the critical path only become real if the successor starts earlier; otherwise they evaporate while everyone waits for the original date. Holding the plan is the stability-flavoured option, and it is why projects absorb every early finish and pass on every late one.
A slip changes the earliest start of everything downstream, and some of those tasks have resource or calendar constraints that a simple week-shift will not respect. Adding a week to the end date is the quick arithmetic and usually understates the impact, because it assumes every successor can simply move sideways.
Pricing the request keeps the project changeable while keeping the date honest, and the sponsor is the right person to decide the trade. Absorbing it is the accommodating option and is how a schedule accumulates a month of unattributed additions that nobody ever approved.
A self-reported percentage is an opinion; remaining days plus a named blocker is a forecast that can be checked and helped. Escalating straight away is the decisive-looking response and arrives at the sponsor with no information beyond the same unreliable number.
The failure was maintenance, so the fix is a plan cheap enough to keep current and a rhythm that keeps it so. Adding detail is the instinctive response to a plan that is not working, and it makes the actual problem worse: the more granular the plan, the more expensive every update becomes and the sooner it is abandoned again.