Twelve Days of Float That Weren't
You are managing a 240-activity ERP data migration and cutover project. The approved baseline schedule has a 96-day critical path through data cleansing, legacy extraction, transformation, and two mock cutovers. A separate integration-testing path has 92 days of duration and 4 days of total float. Two shared database administrators are assigned at 60% to both paths. To reduce multitasking, you level the resource so each DBA works 100% on one path at a time. After leveling, the integration-testing path becomes 101 days. Separately, the vendor's extraction tool has a contractual five-day lag before acceptance, and the vendor has just told you the lag may become ten days. Your project sponsor wants to "recover the lost four days" by fast-tracking data cleansing and transformation in parallel. The steering committee meets tomorrow, and the cutover date is fixed by a regulatory reporting deadline.
1. Explain what happened to the schedule when you leveled resources, and why the original four days of float was misleading. What should you do before proposing recovery?
Read the worked answer
Resource leveling changes the timing of activities and can therefore change the network's critical path. Before leveling, the integration-testing path had only four days of total float relative to a 96-day critical path. When the DBAs were forced to work sequentially rather than at 60% on both paths, the integration path lost its concurrency and grew to 101 days. The path did not "consume" float in a mysterious way; the leveling changed the logical resource constraints, and the formerly near-critical path became critical. Four days of float on a 92-day path was thin protection, especially with shared resources and a vendor lag. The original baseline also likely treated the DBAs as infinitely available at 60%, which was never realistic.
Before proposing recovery, recompute the critical path and near-critical paths after leveling, including the vendor lag as a defined activity or constraint. Confirm which activities are truly critical and how much total float remains elsewhere. Then evaluate recovery options against cost, risk, and the fixed regulatory date: crashing specific critical activities, fast-tracking only where dependencies permit, adding a second DBA, or negotiating the vendor lag. Do not simply accept the sponsor's instruction to parallelize cleansing and transformation; that pairing may create rework if transformation depends on clean data. Present the steering committee with the revised network, the new critical path, and two or three recovery scenarios with costs and risks.
2. The sponsor directs you to fast-track data cleansing and transformation to save four days. How do you respond, and what analysis supports your recommendation?
Read the worked answer
Respond by reframing the request as a trade-off decision rather than a compliance issue. Fast-tracking cleansing and transformation may save calendar time, but only if the dependency between them is discretionary. In most migrations, transformation rules depend on the cleansed data profile, so overlapping them can cause rework, reconciliation defects, and a second mock cutover. Quantify that risk: estimate the rework effort if the data profile changes after transformation starts, the probability of a failed mock cutover, and the cost of an additional test cycle. Compare that with the value of four days against the regulatory deadline.
Also check whether four days is the real problem. If the vendor lag grows from five to ten days, recovering four days on cleansing will not protect the cutover date. The higher-leverage actions may be enforcing the vendor's acceptance commitment, adding a DBA, or reducing the scope of the first mock cutover. Present the sponsor with a clear recommendation: fast-track only the low-dependency subset of transformation, hold the high-risk rules until cleansing sign-off, and use the saved time as contingency for the vendor lag. Document the sponsor's decision if overruled, and update the risk register and schedule baseline accordingly. The professional obligation is to make the trade-off explicit, not to silently absorb it.