WEBVTT 00:00:00.750 --> 00:00:04.900 The contractor proposes to recover the week: back from the twenty seventh of 00:00:04.900 --> 00:00:06.638 November to the twentieth. 00:00:06.638 --> 00:00:08.775 Good news, if it is real. 00:00:08.775 --> 00:00:12.050 The useful question is what will change on site to make that date 00:00:12.050 --> 00:00:13.125 possible. 00:00:14.175 --> 00:00:15.988 Start on the critical path. 00:00:15.988 --> 00:00:20.413 Finishing the temporary access works early does nothing for the reopening. 00:00:20.413 --> 00:00:24.500 Recovering a week means recovering it on the marine foundation works or the 00:00:24.500 --> 00:00:27.975 pier structure, where the finish is actually decided. 00:00:29.015 --> 00:00:30.653 Make the change concrete. 00:00:30.653 --> 00:00:32.453 A second crew on the piles? 00:00:32.453 --> 00:00:34.928 A different sequence for the deck segments? 00:00:34.928 --> 00:00:39.828 Each option carries assumptions about access, calendars and dependencies that the 00:00:39.828 --> 00:00:42.715 team must be able to explain and test. 00:00:43.800 --> 00:00:48.900 In Kairos a recovery schedule is reviewed like any other submission: imported, 00:00:48.900 --> 00:00:53.763 compared with the current plan, tested for quality, and recorded in OnPoint. 00:00:53.763 --> 00:00:57.950 The record here is the monthly review, with the same fields: which meetings 00:00:57.950 --> 00:01:01.150 were held, the recommendation, the letter issued. 00:01:02.150 --> 00:01:05.575 A credible plan names who will do what by when, and says what 00:01:05.575 --> 00:01:07.700 the next update should show. 00:01:07.700 --> 00:01:11.025 If the thirtieth of September update does not show the piles ahead of 00:01:11.025 --> 00:01:13.525 plan, the recovery is a hope. 00:01:14.575 --> 00:01:16.500 An earlier date is the goal. 00:01:16.500 --> 00:01:20.825 The work, recorded and tested update by update, is what makes it credible. 00:01:20.825 --> 00:01:21.737 Know sooner. 00:01:21.737 --> 00:01:23.050 Act faster.