Here is the claim that reframes the whole course. Almost everything you configured in Modules 3 through 17 exists so that a project template can carry it.
THE TEMPLATE IS WHAT A PROJECT MANAGER TOUCHES. EVERYTHING ELSE IS PLUMBING.
What a template packages. Project type. Plan structure. Planning RBS. Project plan type. Financial plan types. Task structure. Team roles. Classifications. Billing defaults. And more.
With a good template, creating a project is: pick the template, name it, set the dates, go. Without one, it is a forty-field form and forty chances to get it wrong.
DESIGNED FIRST. BUILT LAST. Designed first, because the template design tells you what configuration you need. Built last, because a template can only assemble what exists. That is why Module 1 told you to design the template on day one even though you build it at the end. It is not a paradox; it is the only way to know what you are configuring for.
CAN A PROJECT MANAGER CREATE A CORRECTLY-CONFIGURED PROJECT IN UNDER TWO MINUTES WITHOUT ASKING ANYONE A QUESTION? If not, the template is not finished. That is the quality test, it is the lab's acceptance criterion, and it is timed.
And the maintenance point. Templates need an owner. When a project type changes or a new financial plan type is added, somebody updates the templates. Without that, templates drift from configuration — and new projects are subtly wrong. Subtly is the problem. Nothing fails; projects are simply created slightly incorrectly, one at a time, for as long as nobody notices.