A workback plan built forward from today is a wish. Built backward from the launch date, it is a diagnostic. Those are different tools with different outputs.
Start with the date and work left. What has to be true the week before launch? The week before that? Keep going until you hit today. If you run out of weeks before you run out of work, the date is not real. That is what the plan is trying to tell you, and most teams ignore it because they built the plan in the other direction.
At Roku, the payment gateway migration had a hard contract deadline. I built the workback and it came up six weeks short. I had two choices: reduce scope or tell the partner early. I reduced scope and told the partner about the reduction early. Both conversations were uncomfortable. Neither was as bad as missing the deadline would have been.
The other thing workback plans do is expose dependencies you didn't know you had. When you map backwards, you find the work that has to finish before the work that everyone thinks is the bottleneck. Those upstream dependencies are where programs actually die.
Update the workback every week. Not because the dates change, but because the gaps do. A weekly update forces you to look at the distance between where you are and where the plan said you would be, which is information you need before it becomes a problem.