A regulatory deadline is the one date that does not negotiate
Everything else in the plan can move. Build the plan around the thing that cannot.
Most project dates are commitments between people, which means they can be renegotiated between people. A regulatory date is not one of those. It was set elsewhere, by someone who will not be in the room.
That single property should reorganise the entire plan around it, and usually does not.
Plan backwards from the immovable
The temptation is to plan forwards from today and discover in month four that the deadline is tight. Planning backwards from the date surfaces the squeeze in week one, while the options are still cheap — descope, more people, an earlier integration window.
Dependencies are the actual risk
On this kind of programme the technical work is rarely what slips. What slips is a decision waiting on a global team in another time zone, a vendor's release calendar, an environment that only one group can provision, a legal reading that has not come back.
Those are not status-report items. They are the plan. Track them by name and by owner, with the date you need the answer, not the date you asked.
Keep an incident queue beside the project
Programmes of this size generate incidents while they are still being built. If those compete informally with delivery work, delivery always loses quietly. A separate, visible queue with its own capacity keeps the trade-off explicit instead of accidental.
What executives need
Not the plan. The two dependencies that could move the date and what you need from them this week. Everything else is detail they will not act on, and detail they cannot act on erodes their attention for the parts they can.
